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

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

On 07/05/2018 03:58 PM, Adhemerval Zanella wrote:
> 
> 
> On 05/07/2018 16:56, Carlos O'Donell wrote:
>> 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.
>>
> 
> Sorry, I forgot to sent a [committed] message.  I already fixed it 
> upstream [1].
> 
> [1] https://sourceware.org/git/?p=glibc.git;a=commit;h=7279af007c420a9d5f88a6909d11e7cb712c16a4
> 

Thanks. Just trying to cross check what's fixed or not
fixed for 2.28.

Cheers,
Carlos.


-- 
Cheers,
Carlos.