From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754512AbcDTHJu (ORCPT ); Wed, 20 Apr 2016 03:09:50 -0400 Received: from www.linutronix.de ([62.245.132.108]:42772 "EHLO Galois.linutronix.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753593AbcDTHJt (ORCPT ); Wed, 20 Apr 2016 03:09:49 -0400 Subject: Re: [PATCH] kernel/futex: handle the case where we got a "late" waiter To: Davidlohr Bueso References: <1460723739-5195-1-git-send-email-bigeasy@linutronix.de> <20160419222737.GA27058@linux-uzut.site> Cc: Thomas Gleixner , linux-kernel@vger.kernel.org From: Sebastian Andrzej Siewior Message-ID: <57172B3A.2000205@linutronix.de> Date: Wed, 20 Apr 2016 09:09:46 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Icedove/38.7.0 MIME-Version: 1.0 In-Reply-To: <20160419222737.GA27058@linux-uzut.site> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-Linutronix-Spam-Score: -1.0 X-Linutronix-Spam-Level: - X-Linutronix-Spam-Status: No , -1.0 points, 5.0 required, ALL_TRUSTED=-1,SHORTCIRCUIT=-0.0001 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 04/20/2016 12:27 AM, Davidlohr Bueso wrote: > On Fri, 15 Apr 2016, Sebastian Andrzej Siewior wrote: > >> futex_unlock_pi() gets uval before taking the hb lock. Now imagine >> someone in futex_lock_pi() took the lock. While futex_unlock_pi() waits >> for the hb lock, the LOCK_PI sets FUTEX_WAITERS and drops the lock. >> Now, futex_unlock_pi() figures out that there is waiter and invokes >> wake_futex_pi() with the old uval which does not yet have FUTEX_WAITERS >> set. This flaw lets cmpxchg_futex_value_locked() fail and return -EINVAL. > > Hmm but if we're calling futex_unlock_pi() in the first place, doesn't that > indicate that the uval already has FUTEX_WAITERS and therefore failed the > TID->0 transition in userland? That or the thread is bogusly unlocking a > lock that it doesn't own. I hacked a testing tool which always did the syscall for LOCK_PI / UNLOCK_PI and this popped up. > > This is of course different than the requeue_pi case which can specify > set_waiters but also gets the value via get_futex_value_locked(). > > Is this a real issue or did you find it by code inspection? real issue. https://breakpoint.cc/mass-futex2-rl.c > Thanks, > Davidlohr Sebastian