Re: [PATCH v3] SUNRPC: set desired file system root before connectinglocal transports

From: Stanislav Kinsbursky
Date: Thu Nov 15 2012 - 03:35:28 EST


15.11.2012 01:01, J. Bruce Fields ÐÐÑÐÑ:
On Mon, Nov 12, 2012 at 12:37:54PM +0400, Stanislav Kinsbursky wrote:
07.11.2012 22:33, J. Bruce Fields ÐÐÑÐÑ:
On Tue, Nov 06, 2012 at 08:36:05AM -0500, J. Bruce Fields wrote:
On Tue, Nov 06, 2012 at 08:10:18AM -0500, Christoph Hellwig wrote:
On Tue, Nov 06, 2012 at 08:07:06AM -0500, J. Bruce Fields wrote:
So you're worried that a bug in the nfs code could modify the root and
then not restore it?

At least the link you pointed to earlier never sets it back.

This? http://thread.gmane.org/gmane.linux.kernel/1259986/focus=47687

+ get_fs_root(current->fs, &root);
+ set_fs_root(current->fs, &transport->root);
+
status = xs_local_finish_connecting(xprt, sock);
+
+ set_fs_root(current->fs, &root);
+ path_put(&root);

Instead
of messing with it I'd rather have the sunrpc code use vfs_path_lookup
and not care about current->fs->root at all.

The annoyance is that the lookup happens somewhere lower down in the
networking code (net/unix/af_unix.c:unix_find_other, I think). So we'd
need some new (internal) API. We'd likely be the only user of that new
API.

So, if the only drawback is really just the risk of introducing a bug
that leaves the fs_root changed--the above seems simple enough for that
not to be a great risk, right?


If we unshare rpciod fs struct (which is exported already), then we

I'm not sure what you mean by that. Do workqueues actually have their
own dedicated set of associated tasks? I thought all workqueues shared
a common pool of tasks these days.


Any kernel thread is cloned in kthreadd context with CLONE_FS flag.
I.e. all of them shares same fs struct, and changing fs->root in one of kthreads will affect all others.
That's why either fs struct have to be unshared to swap fs->root or fs->cwd, or the whole fs struct have to swapped.


--
Best regards,
Stanislav Kinsbursky
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/