This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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



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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]