This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: Fix Linux fcntl OFD locks for non-LFS architectures (BZ#20251)
- From: Adhemerval Zanella <adhemerval dot zanella at linaro dot org>
- To: Samuel Thibault <samuel dot thibault at gnu dot org>, libc-alpha at sourceware dot org
- Date: Thu, 15 Nov 2018 09:45:15 -0800
- Subject: Re: Fix Linux fcntl OFD locks for non-LFS architectures (BZ#20251)
- References: <20181115012457.ssscem7zfceifykq@function> <20181115012939.il77yr2gxkxyswu6@function> <20181115013648.xcxewlolirj35o3d@function>
On 14/11/2018 17:36, Samuel Thibault wrote:
> Samuel Thibault, le jeu. 15 nov. 2018 02:29:39 +0100, a ecrit:
>> Samuel Thibault, le jeu. 15 nov. 2018 02:24:57 +0100, a ecrit:
>>> In login/utmp_file.c you have replaced calling __fcntl_nocancel by
>>> __fcntl64_nocancel, but shouldn't struct flock be replaced by struct
>>> flock64 too?
>>
>> Ah, no, applications *have* to use F_SETLK64 to use struct flock64, is
>> that it?
>
> Mmm, no, as I read the Linux implementation, when calling fcntl(), one
> has to use F_SETLK64 to be able to use struct flock64, but when calling
> fcntl64(), struct flock64 is always used,a and thus login/utmp_file.c
> should really be useing struct flock64?
>
> Samuel
>
At least for Linux this specific usage is supported. For 32-bit architectures,
Linux fcntl64 does:
471 #if BITS_PER_LONG == 32
472 SYSCALL_DEFINE3(fcntl64, unsigned int, fd, unsigned int, cmd,
473 unsigned long, arg)
474 {
[...]
492 switch (cmd) {
[...]
511 default:
512 err = do_fcntl(fd, cmd, arg, f.file);
513 break;
514 }
Which in turn will call fcntl_setlk. The issue that BZ#20251 is using
this same scenario but with Linux-specific OFD locks (which is not
supported).
However I agree that this is confusing and I think it would be an
improvement if we explicit avoid use non-LFS interfaces within glibc.