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-nfs" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
