From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 6751 invoked by alias); 16 Aug 2014 16:54:09 -0000 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 Received: (qmail 6706 invoked by uid 48); 16 Aug 2014 16:54:05 -0000 From: "fweimer at redhat dot com" To: glibc-bugs@sourceware.org Subject: [Bug libc/17252] getrandom and getentropy syscall Date: Sat, 16 Aug 2014 16:54: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-Version: unspecified X-Bugzilla-Keywords: X-Bugzilla-Severity: enhancement X-Bugzilla-Who: fweimer at redhat 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-Flags: security- X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: http://sourceware.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-SW-Source: 2014-08/txt/msg00068.txt.bz2 https://sourceware.org/bugzilla/show_bug.cgi?id=3D17252 --- Comment #2 from Florian Weimer --- (In reply to Cristian Rodr=C3=ADguez from comment #0) > Ideally, if the system call is not found in the running kernel, fallback = to > emulation by reading /dev/urandom in the default case or /dev/random if=20 > GRND_RANDOM is used. If GRND_NONBLOCK is not set and the buffer is proper, the system call cannot fail. It is impossible to achieve that with emulation. --=20 You are receiving this mail because: You are on the CC list for the bug. >>From glibc-bugs-return-25986-listarch-glibc-bugs=sources.redhat.com@sourceware.org Sat Aug 16 22:19:28 2014 Return-Path: Delivered-To: listarch-glibc-bugs@sources.redhat.com Received: (qmail 11857 invoked by alias); 16 Aug 2014 22:19:28 -0000 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 Delivered-To: mailing list glibc-bugs@sourceware.org Received: (qmail 11812 invoked by uid 48); 16 Aug 2014 22:19:23 -0000 From: "bugdal at aerifal dot cx" To: glibc-bugs@sourceware.org Subject: [Bug nptl/13165] pthread_cond_wait() can consume a signal that was sent before it started waiting Date: Sat, 16 Aug 2014 22:19:00 -0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: glibc X-Bugzilla-Component: nptl X-Bugzilla-Version: 2.14 X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: bugdal at aerifal dot cx X-Bugzilla-Status: ASSIGNED X-Bugzilla-Priority: P2 X-Bugzilla-Assigned-To: triegel at redhat dot com X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: security- X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: http://sourceware.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-SW-Source: 2014-08/txt/msg00069.txt.bz2 Content-length: 879 https://sourceware.org/bugzilla/show_bug.cgi?id=13165 --- Comment #38 from Rich Felker --- I just read the source for pthread_cond_wait and the cause of the bug is obvious: the mutex is being unlocked before the current thread acquires the internal lock in the cond var and adds itself as a waiter. Simply moving the mutex unlock to somewhere after this point (e.g. right before the futex wait loop) should fix the problem. This is necessary to meet the requirement that formally becoming a waiter is atomic with unlocking of the mutex, rather than happening at some time after unlocking the mutex with a race window in between. If someone else could test this fix, I would appreciate it since I don't have an environment setup for building and testing new glibc builds. -- You are receiving this mail because: You are on the CC list for the bug.