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

[Stanislav Kinsbursky]

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 won't affect 
other kthreads by root swapping.
But would be great to hear Trond's opinion about this approach.

Trond, could you tell us your feeling about all this?

> Is there any other hazard to doing this that people can think of?
>
> --b.


--
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/