[Linaro-mm-sig] Memory Management Discussion

[Laurent Pinchart]

On Thursday 21 April 2011 20:43:33 Rebecca Schultz Zavin wrote:
> On Thu, Apr 21, 2011 at 5:55 AM, Marcus Lorentzon  wrote:
> > On 04/21/2011 02:15 PM, Arnd Bergmann wrote:
> >> On Wednesday 20 April 2011, Marcus Lorentzon wrote:
> >>> On 04/20/2011 06:19 PM, Arnd Bergmann wrote:
> >>>> File descriptors have a number of very nice properties that we can
> >>>> use:
> >>>> 
> >>>> * Efficient lookup in system calls
> >>> 
> >>> If both use the idr I don't see how fds are faster than ints.
> >> 
> >> File descriptors don't use idr.
> > 
> > My mistake, but still, ints could use an array too, and idr or lookup in
> > general should not be an efficiency problem anyway.
> > 
> >  * Established ways to pass them around
> >  
> >>> What could be easier than passing an int? I just don't like the
> >>> "feature" of passing fds where they are dup-ed without driver knowing
> >>> so. If you want to store process specific info associated with the fd
> >>> you have to use a list since you don't know if the app sends the fd to
> >>> another process. Probably not a big deal, but I don't like it ;)
> >> 
> >> The problem with passing an integer is that it doesn't have any
> >> concept of ownership or lifetime rules.
> > 
> > The idea of passing global ids should not affect lifetime. These ints are
> > still lifetime controlled by the "fd" device that created them. So I
> > think they do have a defined lifetime, that of whatever device this int
> > is registered in. And if the process is shut down, all buffers
> > registered in the drm/v4l2 device fd will be released and even freed if
> > it was the last ref.
> > And if you mean lifetime while process is still alive, even fds has to be
> > closed, and ints has to be closed/unregistered using ioctl. And this is
> > not something that is used by applications either, these refs and allocs
> > are handled by the user space drivers, like libEGL / libGL / X-drivers
> > etc, so ioctl vs. close should not matter.
> 
> The problem isn't managing their lifetime in the side that created the
> buffer, it's managing it while they are in flight.  What happens if process
> 1 passes a buffer to process 2 and before process 2 takes a reference to
> it, process 1 crashes?  Some central clearing house has to handle that. 
> I'm guessing that's the X server in the X case.  In my proposal that's
> handled by the extra reference being held by the passed fd itself (ie the
> kernel has a reference as long as the file struct exists in either
> processes file descriptor table).

I don't see a real problem here. Buffers would be ref-counted in the kernel. 
If process 1 crashes before process 2 gets to take are reference to the 
buffer, the reference count will be decreased to 0 and the buffer will be 
freed. Process 2 will then receive an error when it will try to take a 
reference to the buffer.

-- 
Regards,

Laurent Pinchart