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

From: Stanislav Kinsbursky
Date: Wed Oct 10 2012 - 06:33:10 EST

10.10.2012 05:23, J. Bruce Fields ÐÐÑÐÑ:
On Tue, Oct 09, 2012 at 03:47:42PM -0700, Eric W. Biederman wrote:
"J. Bruce Fields" <bfields@xxxxxxxxxxxx> writes:

On Tue, Oct 09, 2012 at 01:20:48PM -0700, Eric W. Biederman wrote:
"Myklebust, Trond" <Trond.Myklebust@xxxxxxxxxx> writes:

On Tue, 2012-10-09 at 15:35 -0400, J. Bruce Fields wrote:
Cc'ing Eric since I seem to recall he suggested doing it this way?

Yes. On second look setting fs->root won't work. We need to change fs.
The problem is that by default all kernel threads share fs so changing
fs->root will have non-local consequences.

Oh, huh. And we can't "unshare" it somehow?

I don't fully understand how nfs uses kernel threads and work queues.
My general understanding is work queues reuse their kernel threads
between different users. So it is mostly a don't pollute your
environment thing. If there was a dedicated kernel thread for each
environment this would be trivial.

What I was suggesting here is changing task->fs instead of
task->fs.root. That should just require task_lock().

Oh, OK, got it--if that works, great.


The main problem with swapping fs struct is actually the same as in root swapping. I.e. routines for copy fs_struct are not exported.
It could be done on place, but I don't think, that Al Viro would support such implementation.
Trond?

Sorry, I don't know much about devtmpfs, are you suggesting it as a
model? What exactly should we look at?

Roughly all I meant was that devtmpsfsd is a kernel thread that runs
with an unshared fs struct. Although I admit devtmpfsd is for all
practical purposes a userspace daemon that just happens to run in kernel
space.

Thanks for the explanation.

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