From: Cyril Hrubis <chrubis@suse.cz>
To: "Ricardo B. Marlière" <rbm@suse.com>
Cc: Linux Test Project <ltp@lists.linux.it>
Subject: Re: [LTP] [PATCH] open_posix: Update pthread_rwlock_rdlock 2nd assertion
Date: Fri, 19 Sep 2025 13:54:30 +0200 [thread overview]
Message-ID: <aM1EdqFm48EyjtWz@yuki.lan> (raw)
In-Reply-To: <20250520-fixes-pthread_rwlock_rdlock-v1-1-402ee45114cc@suse.com>
Hi!
> The pthread_rwlock_rdlock/2-*.c tests are broken because they rely on an
> old version of the POSIX standard which says:
>
> If the Thread Execution Scheduling option is supported, and the threads
> involved in the lock are executing with the scheduling policies
> SCHED_FIFO or SCHED_RR, the calling thread shall not acquire the lock if
> a writer holds the lock or if writers of higher or equal priority are
> blocked on the lock; otherwise, the calling thread shall acquire the
> lock.
>
> Whereas the new version says:
>
> If the Thread Execution Scheduling option is supported, and the threads
> that hold or are blocked on the lock are executing with the scheduling
> policies SCHED_FIFO or SCHED_RR, the calling thread shall not acquire the
> lock if a writer holds the lock or if the calling thread does not already
> hold a read lock and writers of higher or equal priority are blocked on
> the lock; otherwise, the calling thread shall acquire the lock.
I wouldn't say that these tests are broken because of the change in
POSIX. The change in POSIX only fixed the specs in the case of recursive
locking that is situation where we have a thread that has rdlock and
attempts to do rwlock while there is higher priority thread that
attempts rwlock. In that situation the previous definition would caused
deadlock.
But as far as I can see these tests do not attempt recursive locks, so
that part of POSIX wasn't really problem.
> This behaviour is not supported by default on GNU/Linux, so add a call to
> Glibc pthread_rwlockattr_setkind_np() to set the correct lock kind as a
> prerequisite to the 2-1.c and 2-2.c tests.
This is where the problem is, glibc decided to deviate from the POSIX
since they think that the standard is not well designed. That is a glibc
design choice. I'm not againts working around that with requesting POSIX
confirming variant on glibc, but the patch should clearly say this
instead.
Also we should split this into two patches, one that adjusts the specs
and one that adds glibc workaround.
--
Cyril Hrubis
chrubis@suse.cz
--
Mailing list info: https://lists.linux.it/listinfo/ltp
prev parent reply other threads:[~2025-09-19 11:54 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-05-20 18:10 [LTP] [PATCH] open_posix: Update pthread_rwlock_rdlock 2nd assertion Ricardo B. Marlière via ltp
2025-05-20 18:13 ` Ricardo B. Marlière via ltp
2025-09-19 11:54 ` Cyril Hrubis [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=aM1EdqFm48EyjtWz@yuki.lan \
--to=chrubis@suse.cz \
--cc=ltp@lists.linux.it \
--cc=rbm@suse.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox