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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Tue, Nov 06, 2012 at 04:11:11PM +0400, Stanislav Kinsbursky wrote:
> 06.11.2012 16:06, J. Bruce Fields пишет:
> >On Tue, Nov 06, 2012 at 02:14:50PM +0400, Stanislav Kinsbursky wrote:
> >>09.10.2012 23:35, J. Bruce Fields пишет:
> >>>Cc'ing Eric since I seem to recall he suggested doing it this way?
> >>>
> >>>Seems OK to me, but maybe that swap_root should be in common code?  (Or
> >>>maybe we could use set_fs_root()?)
> >>>
> >>
> >>This patch is not good since, as Eric mentioned, all kernel threads
> >>share same fs struct.
> >>We can swap whole fs struct. Or we can unshare fs struct
> >>(unshare_fs_struct() is exported) and swap root in this case.
> >>But this approach is to close to set_fs_root() logic, which is not
> >>exported and seems there are some valid reasons for it.
> >
> >What are those reasons?
> >
> 
> I don't know them.
> Trond told, that Al doesn't like the idea of set_fs_root() exporting.
> 
> >Googling found one previous thread:
> >
> >	http://thread.gmane.org/gmane.linux.kernel/1259986/focus=47687
> >
> >There Trond requests an ACK from Al or Cristoph for the export, but I
> >don't see either an ACK or any objection.
> >
> 
> Cristoph told me on LSF something line "No ... way", when I asked
> him about set_fs_root() exporting.
> But I had no opportunity to ask why.

So, Al or Christoph: NFS calls up to rpcbind from the kernel using
AF_LOCAL, so it looks up a path when it connects.  We'd like to export
set_fs_root() so we can temporarily put our task in the right namespace
around the connect call.  Is that reasonable?

I just want to get a reason on record so we stop going in circles here.

--b.
--
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


[Index of Archives]     [Linux Filesystem Development]     [Linux USB Development]     [Linux Media Development]     [Video for Linux]     [Linux NILFS]     [Linux Audio Users]     [Yosemite Info]     [Linux SCSI]

  Powered by Linux