On Tue, Sep 12, 2017 at 1:04 AM, Sebastian Huber <sebastian.hu...@embedded-brains.de> wrote: > > > On 11/09/17 20:34, Gedare Bloom wrote: >> >> On Fri, Sep 8, 2017 at 1:04 AM, Sebastian Huber >> <sebastian.hu...@embedded-brains.de> wrote: >>> >>> On 08/09/17 00:08, Gedare Bloom wrote: >>> >>>> I understand the motivation. I need to look carefully at whether this >>>> breaks the special case, and how to otherwise fix it. >>> >>> The change didn't introduce test suite failures. >>> >> Yeah, I neglected to create a test case for this. When I can, I will. >> The language at issue here from the standard is: >> "The mmap() function shall add an extra reference to the file >> associated with the file descriptor fildes which is not removed by a >> subsequent close() on that file descriptor. This reference shall be >> removed when there are no more mappings to the file." > > > Yes, this sounds reasonable especially since it says > > "... shall add an extra reference to the file associated with ..." > > It doesn't say > > "... shall add an extra reference to the file descriptor ..." > Aha. I was a bit careless in my reading it seems. Thanks for pointing this out. I guess my interpretation of the edge case here is wrong, and that a close() followed later by a munmap() should assume the fd can be recycled in between.
> This is in line with the IO library (without your mapping specific file > descriptor reference counting) which delegates the file (node) specific > reference counting to the file system support. You do this for example in > your share memory support via POSIX_Shm_Control::reference_count. > I think I understand most of the issues you point out now. We need a proper Object for mappings (e.g., a POSIX_Mmap_Control), and that needs to have a reference on the file rather than file descriptor, which may be reaped and recycled despite that a mapping exists. Push this patch, and create a new ticket (for me) to refactor the mmap and fix these problems. Hopefully I can get to it soon. Meanwhile, a program that mmaps a file and closes it before munmapping it could have problems. -Gedare > > -- > Sebastian Huber, embedded brains GmbH > > Address : Dornierstr. 4, D-82178 Puchheim, Germany > Phone : +49 89 189 47 41-16 > Fax : +49 89 189 47 41-09 > E-Mail : sebastian.hu...@embedded-brains.de > PGP : Public key available on request. > > Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG. > _______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
