On Tue, Oct 09, 2012 at 03:47:42PM -0700, Eric W. Biederman wrote: > "J. Bruce Fields" <bfie...@fieldses.org> writes: > > > On Tue, Oct 09, 2012 at 01:20:48PM -0700, Eric W. Biederman wrote: > >> "Myklebust, Trond" <trond.mykleb...@netapp.com> 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. > > 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. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
