| Message ID | 20180630122621.GZ4418@port70.net |
|---|---|
| State | New, archived |
| Headers |
Received: (qmail 119586 invoked by alias); 30 Jun 2018 12:26:26 -0000 Mailing-List: contact libc-alpha-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: <libc-alpha.sourceware.org> List-Unsubscribe: <mailto:libc-alpha-unsubscribe-##L=##H@sourceware.org> List-Subscribe: <mailto:libc-alpha-subscribe@sourceware.org> List-Archive: <http://sourceware.org/ml/libc-alpha/> List-Post: <mailto:libc-alpha@sourceware.org> List-Help: <mailto:libc-alpha-help@sourceware.org>, <http://sourceware.org/ml/#faqs> Sender: libc-alpha-owner@sourceware.org Delivered-To: mailing list libc-alpha@sourceware.org Received: (qmail 119573 invoked by uid 89); 30 Jun 2018 12:26:26 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-11.1 required=5.0 tests=AWL, BAYES_00, GIT_PATCH_2, GIT_PATCH_3, SPF_HELO_PASS, SPF_PASS autolearn=ham version=3.3.2 spammy= X-HELO: port70.net Date: Sat, 30 Jun 2018 14:26:21 +0200 From: Szabolcs Nagy <nsz@port70.net> To: Adhemerval Zanella <adhemerval.zanella@linaro.org> Cc: libc-alpha@sourceware.org Subject: Re: [PATCH v4] Fix Linux fcntl OFD locks for non-LFS architectures (BZ#20251) Message-ID: <20180630122621.GZ4418@port70.net> References: <1529530993-20897-1-git-send-email-adhemerval.zanella@linaro.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1529530993-20897-1-git-send-email-adhemerval.zanella@linaro.org> User-Agent: Mutt/1.9.1 (2017-09-22) |
Commit Message
Szabolcs Nagy
June 30, 2018, 12:26 p.m. UTC
* 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...
Comments
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.
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.
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
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.
--- ../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