[PATCH] libio: Remove special-case reference count
Gedare Bloom
gedare at rtems.org
Tue Sep 12 13:56:07 UTC 2017
On Tue, Sep 12, 2017 at 1:04 AM, Sebastian Huber
<sebastian.huber at 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.huber at 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.huber at embedded-brains.de
> PGP : Public key available on request.
>
> Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
>
More information about the devel
mailing list