Re: [PATCH 1/4] file: export __alloc_fd()

[Christian Brauner <christian@brauner.io>]

On Tue, Jul 31, 2018 at 10:44:33AM +0200, Martijn Coenen wrote:
> On Mon, Jul 30, 2018 at 10:36 PM, Matthew Wilcox <willy@infradead.org> wrote:
> > I'm not entirely sure I understand the binder code (... does anyone?)
> > but from what I can see, it intends to open a file descriptor in the
> > process which is the target of the message being sent.
> 
> You're right.
> 
> > That strikes
> > me as wrong-headed; it should be allocating a struct file and passing
> > that file to the other process.  When that process receives the message,
> > *it* allocates a file descriptor for itself.ho
> 
> We're looking into cleaning this up (historically it was done this way
> because VIVT caches made this not very efficient), and this is indeed
> a very good candidate for fixing it.

Ah, this wasn't brought up in the original thread when discussing to
turn this into a module. If using internal functions like this is going
away it makes sense to wait for this work to happen first. Is there a
time-frame for this?

Thanks!
Christian

> 
> >
> > But I think the binder user-space API relies on this.  The userspace API
> > seems to rely on passing fd numbers around ... but I'm having trouble
> > figuring most of this user API out.  Perhaps Martijn can help here.
> 
> The UAPI does expect a file descriptor, but we may be able to do the
> mapping from fd to struct file (and vice-versa) in the kernel driver,
> so userspace wouldn't notice.
> 
> Thanks,
> Martijn