Bug 66013 (suse51013)

<!-- SBZ_reproduce  -->
Run attached test program.

Created attachment 28607 [details]
pthread_rwlock_rdlock/2-1.c

. 

And this sounds like a duplicate of #66052 

Scheduler is implemented in kernel. 

Hello!

Due to the proposal from Andreas Jaeger, this bug will be closed as WONTFIX,
because there was no change to this bug for more than 2 months by now which
indicates a very low activity. 

If this bug is of relevance for the current release or should be kept open due
to another (not obvious reason), please reopen it ans state a reason for your
decision.

Please also check if the status-information for this bug is correct at all
correct if you reopen it. Generally the product-version should be elevated to
the current release in this case. Sorry if this causes you any inconvenience.

Kind regards,
the BNC-Screening-Team

re-opening as the LTP test: .../pthread_rwlock_rdlock/2-1 clearly demonstrates that the issue still exists in (at least) OS-11.3.  

POSIX clearly states that if a writer is blocked, an additional reader entering into the lock must block until the writer has released the lock.  pthread_rwlock_rdlock() does not implement that behavior.  The additional reader obtains the lock while a thread wanting the write mode is blocked.

The behavior of the 2-1 test is:

main thread:   -> obtain read lock
writer thread: -> attempt to obtain write lock - block
reader tread:  -> attempt to obtain read lock - succeeds. 

The reader thread must block, since another thread wants a write lock.

There are, quite possibly, a lot of broken programs out there if they are dependent upon documented behavior.

Peter, I'd blame LTP, otherwise how was this test ever supposed to pass?

Is it file-system dependent?  Still an issue in openSUSE 11.4?

(In reply to comment #8)
> Peter, I'd blame LTP, otherwise how was this test ever supposed to pass?
> 

:-)  The LTP code is functionally correct, unless I missed something.  Note I was testing with the current LTP version of this test, unsure whether anything changed from the original posting of this bug.

> Is it file-system dependent?  Still an issue in openSUSE 11.4?

Not that I'm aware of.  Not entirely sure how a file system would play into this.

Fails identically on OS 11.4

Greg, we are actually fixing the LTP testcases and proved many of them wrong and fixed them, we just couldn't find anything wrong with this one (minus some coding style). So it would be great if somebody else could look at this as well.

The test source wasn't most likely touched since 2002 (besides some minor whitespace cleanup), at least the git history says so.

And as far as I understand the POSIX threads the read lock should not be obtained if there is writer locked or blocked on the lock and the writer has higher or equal priority. Unfortunately the reader gets the lock here.

So has this test ever worked?  If so, that's good perhaps we have a regression somewhere.

If not, I'd blame the test :)

(In reply to comment #11)
> So has this test ever worked?  If so, that's good perhaps we have a regression
> somewhere.
> 
> If not, I'd blame the test :)

Unsure whether this has ever worked, given that the original bug report was 6 years ago, probably not.

And there were tests that Newer Worked but still were correct and resulted in kernel or glibc patches.

And as we are on the noble and difficult path of making LTP stable testsuite, we still need either to prove the test wrong or fix Linux.

Proving LTP wrong, or fixing it, or the kernel, is on the _very_ low list of things we need to work on at the moment.

Have you brought this issue up on the upstream LTP mailing list?  What do the developers there say about this?  Have they asked the kernel community about this issue?

Okay, given that we are LTP upstream for some time now (I tend to say we, but it's more like I do most of the upstream work now). This leaves us the kernel community, do you think that I should bring this to LKML?

If you have an LTP test that has _never_ worked, and no one has ever noticed it before now, then odds are, the test is incorrect.

And read/write locks are a glibc thing, not a kernel thing, right?  So this might not even be a kernel issue in the first place...

Argh, you are right these locks are implemented in glibc using futexes. And I think I've pinpointed the problem, it seems that Single Unix Specification and POSIX contradicts in this case. The first one says it's undefined while the latter defines it's behavior. I'll move this to glibc upstream.

Reopen to set needinfo

Michael, can assign one of your guys to support Cyril on fixing the test case.

Cyril, please post the upstream bug id here, once you have one.

Here it is:

http://sourceware.org/bugzilla/show_bug.cgi?id=13701

Getting this out of the "unassigned kernel bugs" queue. Thanks for tracking it.

Assigning to Jan.  Jan: this is fairly low priority.

Moving to Tumbleweed.

Does this still happen?

Upstream bug has been closed.