From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 10606 invoked by alias); 17 Dec 2012 09:20:03 -0000 Received: (qmail 10405 invoked by uid 48); 17 Dec 2012 09:19:33 -0000 From: "daniel.stodden at gmail dot com" To: glibc-bugs@sourceware.org Subject: [Bug libc/14958] Concurrent reader deadlock in pthread_rwlock_rdlock() Date: Mon, 17 Dec 2012 09:20:00 -0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: glibc X-Bugzilla-Component: libc X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: daniel.stodden at gmail dot com X-Bugzilla-Status: NEW X-Bugzilla-Priority: P2 X-Bugzilla-Assigned-To: unassigned at sourceware dot org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: X-Bugzilla-URL: http://sourceware.org/bugzilla/ Auto-Submitted: auto-generated Content-Type: text/plain; charset="UTF-8" MIME-Version: 1.0 Mailing-List: contact glibc-bugs-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Post: List-Help: , Sender: glibc-bugs-owner@sourceware.org X-SW-Source: 2012-12/txt/msg00140.txt.bz2 http://sourceware.org/bugzilla/show_bug.cgi?id=14958 --- Comment #5 from Daniel Stodden 2012-12-17 09:19:31 UTC --- Rich, I pushed a candidate fix to https://github.com/dns42/glibc/commit/b7725621b5e2101d4218be0d09bd55a67b4d3512 It explores variant 1 for upstream. Code presently looks correct to me, but I won't get to test it before later. I'll post an update accordingly :) Additional comments for discussion: - Note that prerequisites can be checked comparatively precisely. Possibly more precisely than you anticipated, taking __nr_readers_queued, __nr_writers_queued and __nr_readers into account, all at the same time. - This works because both queues need to come together, then preempted, any other case looks clean to me. All queued loops take the ll lock and atomically decrement, then succeed. So the whole combination of __nr_*_queued and __nr_readers can work as a discriminant. - As you mentioned, the timedlock cases indeed deserve special attention. I think the way they've been written would render the assumptions made by the above patch correct as well. But only if rwlock_timedlock calls are really correct. Can it be that lll_futex_timed_wait does *not* leave an inherent race between timeout and a (too-)late wakeup call? In the same way pthread_cond_timedwait must? I'm not a futex-expert, but the problem here is that I currently don't believe this is even possible. In other words: How does present pthread_rwlock_unlock tell that any of __nr_writers_queued have been woken up before timing out? I almost suspect it can't, doesn't, and -- since timedrwlock makes no attempt to restart the queue on timeout either, suffers from a similar race. But this would probably belong into another ticket. Apologies in advance if I'm mistaken. -- Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.