Received: by 2002:ac0:a5a6:0:0:0:0:0 with SMTP id m35-v6csp426616imm; Thu, 30 Aug 2018 02:21:35 -0700 (PDT) X-Google-Smtp-Source: ANB0Vdbyg7xTdYG/NTwmCf9HsezUfagfrBvRWbksT87+9frdguC1VSUhbFUE9f9T2wGXv//uDPef X-Received: by 2002:a63:3587:: with SMTP id c129-v6mr9004930pga.290.1535620895711; Thu, 30 Aug 2018 02:21:35 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1535620895; cv=none; d=google.com; s=arc-20160816; b=oQpjRhefTCFUzgXeVRBE7REqIAV8dmb9VgwMBClRTawJbvx2cc2PZ7LksVN2F6+VoM Iapi2HQdYM54PMbJyC7o3ALMSZFGW1VpTSgrHPajrsajwIHtVAcXL+6UGRDGD9jPEHic OKxntvsR0F4FFvXEGjzznkfhV7Ln1hpkVVJGzfgVu4zRaJYd7cxEOAsna/BbNvKB1RIZ YXRi0cLLDQgG04XmaCm3MUZE/JP31MWQiYkeD9eXD5hzPQ9/feB6IRA1lvybiXpl+lCZ guDvVAjQn+pkwsxL4XZ5FLy/Hmhq4wtMkcsg5vhjFTV/frWv96GGAZpHhuAYX8JxZAFC JIdQ== 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 :arc-authentication-results; bh=b2+Dc26cMefr+zOrvilWtRSQOQDyYNZ0vzid564bRro=; b=eC3GKZMDxG/0e+oetE1XSXqkZlgPvihZPaJ4voTyWek/pySDO2mFBgthhAfzUTT/rj 99yUEDbEhbIxHsw49toQze/EmDNtcwSWOZYvHS62sPGaJVE41tJYyON/AUL50RsN477z GevTFJXAyvVAfgFOXqCG2KsUu4mmSYqU1bdHejfFXIlUrfHVz7XSt+UrLUMFG2hKbIYa cjM5RRyiSUodGzHHCXvKkacm299gnuuk6SboWZkVhRAQ0pT25wDRfmY8EpTIvS3b+L9M O8UHUNS7rLNFvCJ45aXVF5EOde5UbKFMv2gPYsjewiA07zbZ1nsjWb4FFAWgc6AdG5Z1 IhNw== 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 q126-v6si6877595pfb.277.2018.08.30.02.21.20; Thu, 30 Aug 2018 02:21:35 -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 S1728181AbeH3NVP (ORCPT + 99 others); Thu, 30 Aug 2018 09:21:15 -0400 Received: from Galois.linutronix.de ([146.0.238.70]:49712 "EHLO Galois.linutronix.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727089AbeH3NVP (ORCPT ); Thu, 30 Aug 2018 09:21:15 -0400 Received: from hsi-kbw-5-158-153-52.hsi19.kabel-badenwuerttemberg.de ([5.158.153.52] helo=nanos.tec.linutronix.de) by Galois.linutronix.de with esmtpsa (TLS1.2:DHE_RSA_AES_256_CBC_SHA256:256) (Exim 4.80) (envelope-from ) id 1fvJ7R-0007vd-B7; Thu, 30 Aug 2018 11:20:01 +0200 Date: Thu, 30 Aug 2018 11:19:58 +0200 (CEST) From: Thomas Gleixner To: Rich Felker cc: LKML , Peter Zijlstra , Ingo Molnar Subject: Re: futex_cmpxchg_enabled breakage In-Reply-To: <20180829222221.GA22017@brightrain.aerifal.cx> Message-ID: References: <20180829222221.GA22017@brightrain.aerifal.cx> User-Agent: Alpine 2.21 (DEB 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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. > 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. > Ultimately from an API perspective, the functionality that depends on > futex_cmpxchg_enabled is non-optional, and the current approach of > treating it as something that can be disabled via detection at runtime > is fragile and wrong. 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. > 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? > 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. Thanks, tglx