On Mon, Mar 15, 2021 at 10:44 PM Christian Brauner <christian.brauner@xxxxxxxxxxxxx> wrote: > > On Mon, Mar 15, 2021 at 05:46:43PM +0800, Yongji Xie wrote: > > On Mon, Mar 15, 2021 at 5:08 PM Christoph Hellwig <hch@xxxxxxxxxxxxx> wrote: > > > > > > On Mon, Mar 15, 2021 at 01:37:11PM +0800, Xie Yongji wrote: > > > > Export __receive_fd() so that some modules can use > > > > it to pass file descriptor between processes. > > > > > > I really don't think any non-core code should do that, especilly not > > > modular mere driver code. > > > > Do you see any issue? Now I think we're able to do that with the help > > of get_unused_fd_flags() and fd_install() in modules. But we may miss > > some security stuff in this way. So I try to export __receive_fd() and > > use it instead. > > The __receive_fd() helper was added for core-kernel code only and we > mainly did it for the seccomp notifier (and scm rights). The "__" prefix > was intended to convey that message. > And I agree with Christoph that we should probably keep it that way > since __receive_fd() allows a few operations that no driver should > probably do. > I can see it being kinda ok to export a variant that really only > receives and installs an fd, i.e. if we were to export what's currently > available as an inline helper: > > static inline int receive_fd(struct file *file, unsigned int o_flags) > > but definitely none of the fd replacement stuff; that shold be > off-limits. The seccomp notifier is the only codepath that should even > think about fd replacement since it's about managing the syscalls of > another task. Drivers swapping out fds doesn't sound like a good idea to > me. > Thanks for the explanation, I got it. I will switch to use receive_fd() in the next version. Thanks, Yongji
