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

login
register
mail settings
Submitter Szabolcs Nagy
Date June 30, 2018, 12:26 p.m.
Message ID <20180630122621.GZ4418@port70.net>
Download mbox | patch
Permalink /patch/28170/
State New
Headers show

Comments

Szabolcs Nagy - June 30, 2018, 12:26 p.m.
* 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


but i don't know if hurd is supposed to work...
Adhemerval Zanella Netto - July 2, 2018, 12:44 p.m.
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.
Carlos O'Donell - July 5, 2018, 7:56 p.m.
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.
Adhemerval Zanella Netto - July 5, 2018, 7:58 p.m.
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
Carlos O'Donell - July 5, 2018, 8:13 p.m.
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.

Patch

--- ../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