Re: [PATCH 03/10] linux: Add __readdir_unlocked

[Florian Weimer <fw@deneb.enyo.de>]

* Adhemerval Zanella:

> On 21/04/2020 07:41, Florian Weimer wrote:
>> * Adhemerval Zanella via Libc-alpha:
>> 
>>> And use it on readdir_r implementation.
>> 
>> I think __readdir_unlocked will not really be async-signal-safe if we
>> have to call malloc during readdir, to allocate the long-to-off64_t
>> translation table for the real fix for bug 23960 (when the kernel does
>> not provide 32-bit off64_t values).
>> 
>> That's why I think this change does not go in the right direction, sorry.
>> 
>
> I am not following, the whole set explicit avoid malloc by using a reserved
> space in the allocated but on opendir.  Even on mips64, which requires
> a special getdents64 implementation, avoid memory allocation.

The fix for bug 23960 needs to introduce some kind of memory
allocation to store the mapping.  We can avoid it in most cases, but I
think the readdir interface has too much baggage to make it
async-signal-safe.

> And it is for both non-LFS and LFS interfaces.  The only issue for 
> async-signal-safeness is on telldir for non-LFS mode which might require
> to extend the dynamic array internal buffer if the entry could not be
> added in the internal pre-allocated buffer (and this could be mitigated
> if we added a mmap variant of dynamic array). 

telldir cannot allocate because there is no way to return error.  The
allocation has to happen in readdir.

We should be able to optimize out allocations if telldir is never
called (basically, pre-allocate one slot to be used for telldir).  But
all this is really tricky.  I do wonder if it makes more sense to call
getdents64 directly if one needs async-signal-safety.