Re: [PATCH v4] Fix Linux fcntl OFD locks for non-LFS architectures (BZ#20251)

[Carlos O'Donell <carlos at redhat dot com>]

On 07/02/2018 08:44 AM, Adhemerval Zanella wrote:
> 
> 
> On 30/06/2018 09:26, Szabolcs Nagy wrote:
>> * Adhemerval Zanella <adhemerval.zanella@linaro.org> [2018-06-20 18:43:13 -0300]:
>>> This patch fixes the OFD ("file private") locks for architectures that
>>> support non-LFS flock definition (__USE_FILE_OFFSET64 not defined). The
>>> issue in this case is both F_OFD_{GETLK,SETLK,SETLKW} and
>>> F_{SET,GET}L{W}K64 expects a flock64 argument and when using old
>>> F_OFD_* flags with a non LFS flock argument the kernel might interpret
>>> the underlying data wrongly.  Kernel idea originally was to avoid using
>>> such flags in non-LFS syscall, but since GLIBC uses fcntl with LFS
>>> semantic as default it is possible to provide the functionality and
>>> avoid the bogus struct kernel passing by adjusting the struct manually
>>> for the required flags.
>>>
>>> The idea follows other LFS interfaces that provide two symbols:
>>>
>>>   1. A new LFS fcntl64 is added on default ABI with the usual macros to
>>>      select it for FILE_OFFSET_BITS=64.
>>>
>>>   2. The Linux non-LFS fcntl use a stack allocated struct flock64 for
>>>      F_OFD_{GETLK,SETLK,SETLKW} copy the results on the user provided
>>>      struct.
>>>
>>>   3. Keep a compat symbol with old broken semantic for architectures
>>>      that do not define __OFF_T_MATCHES_OFF64_T.
>>>
>>> So for architectures which defines __USE_FILE_OFFSET64, fcntl64 will
>>> aliased to fcntl and no adjustment would be required.  So to actually
>>> use F_OFD_* with LFS support the source must be built with LFS support
>>> (_FILE_OFFSET_BITS=64).
>>>
>>> Also F_OFD_SETLKW command is handled a cancellation point, as for
>>> F_SETLKW{64}.
>>>
>>> Checked on x86_64-linux-gnu and i686-linux-gnu.
>>>
>>
>> build-many-glibcs fails for me on i686
>> in logs/glibcs/i686-gnu/010-glibcs-i686-gnu-check-log.txt i see
>>
>> FAIL: elf/check-abi-libc
>> FAIL: elf/check-execstack
>> FAIL: hurd/check-installed-headers-c
>> FAIL: hurd/check-installed-headers-cxx
>> FAIL: mach/check-installed-headers-c
>> FAIL: mach/check-installed-headers-cxx
>>
>> the libc abi failure is
>>
>> --- ../sysdeps/mach/hurd/i386/libc.abilist      2018-06-29 18:53:06.105524353 +0100
>> +++ /B/build/glibcs/i686-gnu/glibc/libc.symlist        2018-06-30 13:02:53.044456983 +0100
>> @@ -2036 +2035,0 @@ GLIBC_2.27 wcstof64x_l F
>> -GLIBC_2.28 fcntl F
>>
>> but i don't know if hurd is supposed to work...
>>
> 
> I will look into it.
> 

If you don't have time to look into this please put this on the
release blocker list for 2.28 so we can look into this.

Having an ABI failure like this for release would be bad.

Thanks!

Cheers,
Carlos.

-- 
Cheers,
Carlos.