[PATCH] Always check lockf64 return value

Florian Weimer fweimer@redhat.com
Sun Jun 15 05:03:46 GMT 2025


* H. J. Lu:

> On x86-64, when GCC 14.2.1 is used to build:
>
> commit f3c82fc1b41261f582f5f9fa12f74af9bcbc88f9
> Author: Radko Krkos <krkos@mail.muni.cz>
> Date:   Sat Jun 14 11:07:40 2025 +0200
>
>     io: Mark lockf() __wur [BZ #32800]
>
>     In commit 0476597b28 flock() was marked __wur in posix/unistd.h, but not
>     in io/fcntl.h, the declarations must match.
>
>     Reviewed-by: Florian Weimer <fweimer@redhat.com>
>
> I got
>
> programs/locarchive.c: In function ‘open_archive’:
> programs/locarchive.c:641:18: error: ignoring return value of
> ‘lockf64’ declared with attribute ‘warn_unused_result’
> [-Werror=unused-result]
>   641 |           (void) lockf64 (fd, F_ULOCK, sizeof (struct locarhead));
>       |                  ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> programs/locarchive.c:653:14: error: ignoring return value of
> ‘lockf64’ declared with attribute ‘warn_unused_result’
> [-Werror=unused-result]
>   653 |       (void) lockf64 (fd, F_ULOCK, sizeof (struct locarhead));
>       |              ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> programs/locarchive.c:660:14: error: ignoring return value of
> ‘lockf64’ declared with attribute ‘warn_unused_result’
> [-Werror=unused-result]
>   660 |       (void) lockf64 (fd, F_ULOCK, sizeof (struct locarhead));
>       |              ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> programs/locarchive.c:679:14: error: ignoring return value of
> ‘lockf64’ declared with attribute ‘warn_unused_result’
> [-Werror=unused-result]
>   679 |       (void) lockf64 (fd, F_ULOCK, sizeof (struct locarhead));
>       |              ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>
> Update locarchive.c to always check lockf64 return value.  This fixes
> BZ #33089.

The best way to fix this would be to make __wur conditional on the
second argument.  For F_ULOCK, __wur is not needed.  The problem is
F_LOCK, which may return with an error without actually locking
anything, due to deadlock detection.

(Note that this is only visible with fortified builds, I think.)

Thanks,
Florian



More information about the Libc-alpha mailing list