Received: by 2002:ac0:a5a6:0:0:0:0:0 with SMTP id m35-v6csp2069826imm; Sat, 15 Sep 2018 08:34:47 -0700 (PDT) X-Google-Smtp-Source: ANB0VdZrvqBeq4y4CNsd8XN/bijPSG+nYpx2/kPZ5W/0+XFqXYkHBRVg10Sclxqe9+IX12jV+mUX X-Received: by 2002:a62:e511:: with SMTP id n17-v6mr17744038pff.210.1537025687126; Sat, 15 Sep 2018 08:34:47 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1537025687; cv=none; d=google.com; s=arc-20160816; b=bKtQZHWCJXOtAYfjeFB0cWgSeh4a91POD3OydySSSaEPAK1ZLoJb+PVkTs4HIa+85B quTz4UAB1cuvrSg3ZV1yo2gFxpPZCWaYlx4umqGKMrX5w4KXXiRhvFqtYZijoUWkxosd sWRnBYdNlizbF5qbilzhqzF4SP7OnaAeStFlR+tolxZ8FqsBeFaGjHTilSMjLgIYC8x5 LJiYRAjqjR3Q+OcE0xK0VGF1dWELgArSTIY1dxNzVkNi1NW+3QYyhfnJpfLZVqyQlikD b5dyE2FxGDt5PKrA87ZgWC+WTu/KyO8BPhPwuLZr4i1aIt+G214Pq2PZEknrhmQEH3RG O+0w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:mime-version:user-agent:references :message-id:in-reply-to:subject:cc:to:from:date; bh=UVmxOqh+hh/eG8iEwWDtHyjfwMbhqF0P9E3WmyWlEzU=; b=dnQquNTsrxHJc2innELQNbAm9YxVdld3sGZiCaf0EjXkn3Exw8NdTetCOS1cg5l8ja eBDAZQ8xtzT/U3X9y+X8BhSZyK946id+wN1Xd0A/LewG2Km4DGKdZD/TLqfa2pPQRNkX QFcwTPgycBOYPMpVJzSZKbkX0XDn1Cuo3AQYXPYjZoDfbAdxHsud6F+uaZYA0LkwvFOx NcHZxTcPJBIm6yOz+tnojTkqZHrUOryhGKqRetuSWdSdDz2m3rVv5FziLsamCJmm1FfO 9p1Re+AJe2rqgUBr7Ka5IFWT+7cE/UGECnA14d0FpkiA9lZh3kYSaIIYIjtASnm/60gv wf/w== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id q17-v6si9457994pgc.464.2018.09.15.08.34.31; Sat, 15 Sep 2018 08:34:47 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727571AbeIOUxs (ORCPT + 99 others); Sat, 15 Sep 2018 16:53:48 -0400 Received: from Galois.linutronix.de ([146.0.238.70]:51864 "EHLO Galois.linutronix.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727065AbeIOUxs (ORCPT ); Sat, 15 Sep 2018 16:53:48 -0400 Received: from p4fea45ac.dip0.t-ipconnect.de ([79.234.69.172] helo=nanos) by Galois.linutronix.de with esmtpsa (TLS1.2:DHE_RSA_AES_256_CBC_SHA256:256) (Exim 4.80) (envelope-from ) id 1g1CaW-0001PK-Jo; Sat, 15 Sep 2018 17:34:24 +0200 Date: Sat, 15 Sep 2018 17:34:24 +0200 (CEST) From: Thomas Gleixner To: Rich Felker cc: LKML , Peter Zijlstra , Ingo Molnar Subject: Re: futex_cmpxchg_enabled breakage In-Reply-To: <20180830135527.GT1878@brightrain.aerifal.cx> Message-ID: References: <20180829222221.GA22017@brightrain.aerifal.cx> <20180830135527.GT1878@brightrain.aerifal.cx> User-Agent: Alpine 2.21 (DEB 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII 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 Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, 30 Aug 2018, Rich Felker wrote: > On Thu, Aug 30, 2018 at 11:19:58AM +0200, Thomas Gleixner wrote: > > On Wed, 29 Aug 2018, Rich Felker wrote: > > > > > I just spent a number of hours helping someone track down a bug that > > > looks like it's some kind of futex_cmpxchg_enabled detection error on > > > powerpc64 (still not sure of the root cause; set_robust_list producing > > > -ENOSYS), and a while back I hit the same problem on sh2 due to lack > > > of EFAULT on nommu, leading to commit 72cc564f16ca. I think the test > > > (introduced way back in commit a0c1e9073ef7) is fundamentally buggy; > > > if anything, it should be checking for !=-ENOSYS, not ==-EFAULT. > > > > Errm? This does a futex_cmpxchg() on NULL which has to return EFAULT if > > it's available. There is nothing fundamentally buggy about it at all. > > I'll let you know when if/when we finish figuring out how this > happened on powerpc64, but it's an arch that most certainly has a > working cmpxchg where these syscalls ended up returning -ENOSYS. This > is an error condition that should not be able to happen. At the very > very least all the archs that actually have a working cmpxchg > unconditionally should be updated with: > > select HAVE_FUTEX_CMPXCHG if FUTEX > > so that whatever caused this for powerpc64 doesn't happen again. By doing that you paper over a non functional fixup which could cause other really hard to decode runtime failures. If that fails there is a bug somewhere else and that runtime check is not to blame at all for it. > > > Presumably it could also fail to produce -EFAULT if mmap_min_addr is 0 > > > and page 0 is mapped (a bad idea, but maybe someone does it...). And > > > of course other nommu archs are possibly still broken. > > > > If NULL is mapped in the kernel then a lot of other things are broken. The > > futex thing is then the least of your worries. > > For nommu NULL is always "mapped". Cool, so you can have a NULL pointer dereference without noticing it. > > The availibility of the interfaces which depend on futex_cmpxchg_enabled > > has been runtime detectable forever and it's documented that way. I have no > > idea why you think it's non-optional. If you made it unconditional in your > > lib, then it's hardly the kernels problem. > > Modern glibc also defines: > > #define __ASSUME_SET_ROBUST_LIST 1 > > It's then #undef'd for some archs (mips, m68k, sparc, arm), but not > all archs that lack HAVE_FUTEX_CMPXCHG, so glibc seems to be assuming > set_robust_list actually works on some where the kernel is treating > failure as a possibility. That's hardly a kernel issue, right? > > > If there are no archs that support SMP but don't provide their own > > > asm/futex.h (as opposed to the asm-generic one that does -ENOSYS on > > > SMP), the detection code should just be removed, and the SMP case in > > > asm-generic/futex.h should be made into #error. > > > > And why so? Just because? > > To prevent inadvertent introduction of this issue on new archs (if the > porters don't realize asm-generic/futex.h doesn't actually work for > SMP). > > > > If there are archs that support SMP but don't provide their own > > > working asm/futex.h, then asm-generic/futex.h's SMP case should be > > > enhanced to perform a stop-the-world IPI and then do the same thing as > > > the non-SMP case (disable preemption[/interrupts?], perform the > > > cmpxchg non-atomically). > > > > > > Thoughts? Would a patch to do this be acceptable? > > > > No. There is nothing at all in the world which requires that PI futexes and > > robust list are provided and even if you implement that hack in the kernel > > then the user space side still does not work because the user space part of > > those interfaces has a hard dependency on working cmpxchg as well. > > Of course there's a working cmpxchg; this is a hard requirement for > userspace. You cannot implement pthread primitives without one. On > archs/ISA-levels that lack an insn it's already provided as a syscall, > a vdso/khelper, or trap-and-emulate. The problem I'm complaining about > here is that, despite already needing and having working ways to > achieve this, the kernel is not using them, and breaking functionality > that should work. I kinda agree for the nommu case, but for power64 you are barking up the wrong tree. If that check fails something very fundamentaly is broken and that breakage is _NOT_ in the futex code. This has to work independent of the futex code, really. Thanks, tglx