Received: by 2002:ac0:adb2:0:0:0:0:0 with SMTP id o47-v6csp4995imb; Thu, 30 Aug 2018 06:57:43 -0700 (PDT) X-Google-Smtp-Source: ANB0VdYlF9C8R4T5t9X8G5zCaHRPJwZLZNtL1XJCZBzvShi4vXDNPU2gLvVvPzQ5Ovpnv1kEGM/j X-Received: by 2002:a62:cfc6:: with SMTP id b189-v6mr10690413pfg.224.1535637463045; Thu, 30 Aug 2018 06:57:43 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1535637463; cv=none; d=google.com; s=arc-20160816; b=PiqWw8p39JbWE941eCTlT1ZlrrKYyXX+nwCT4gcgHxGGnowh/ebRU6meLX9ZMWhWbs xDr8rk82/wYQYYYGrFBmLcMLPsWP0G26si4WMijG0YEst52flWO+xj1KYkX60424iiK3 v6WB+FdYOr+Ls3MlPR1xlTYfT4JBTJPAcKI27ZK4bweIAiTw5MEfBZz4EyJUqt5pfOJK XtdDRCNr6ODZwZIK2sEvBwr0JzDyM/4pL/55Yq2Kgb+coa9+t3ThOEj9kKQRgSruO5w/ 5G1wvP1PiIxQTTyNCs3rcm7S+FuGhBFD41c9tFVAlf2TxEWchBnhkRRDtu3nfzEhzRMB aIog== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date:arc-authentication-results; bh=KT7pT+RvHTeoq91sLkYixKhvrreGB9zrS2878EYSaa4=; b=z6XuVWfORTtpAKoxZdR/T5SkePPLK509VVR9ItS1Jf1dnrycxaPgfbq/Rv/ciHkMzK dUSNrqBhpudNzi2bEfWwUSoCIDL5bhNDPsfEyNiu8OtLhvLCUQKIOkvE1qQ5DGlh0uG7 6QGj9SO7WRLSaD7lUVIOwULw+uLXqx1SU8jfNKavIUNxWTdMECGgWZDRk6HbBoDxCUvP vtPVt9revLZ6xu0cCML49NepgLkGTuy3IcMIdLPs/r5cPpooCQLNAJ3F3TlMAhBsT8ig ctSiyV9GrJHB2tRldB7nsmfejDbbHxO4MSuhK+/fANo9sqoc7Au3d4BHY6z/dixMwD9i g5qw== 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 i35-v6si5037669plg.306.2018.08.30.06.57.28; Thu, 30 Aug 2018 06:57:43 -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 S1729084AbeH3R5r (ORCPT + 99 others); Thu, 30 Aug 2018 13:57:47 -0400 Received: from 216-12-86-13.cv.mvl.ntelos.net ([216.12.86.13]:56698 "EHLO brightrain.aerifal.cx" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728925AbeH3R5r (ORCPT ); Thu, 30 Aug 2018 13:57:47 -0400 Received: from dalias by brightrain.aerifal.cx with local (Exim 3.15 #2) id 1fvNPz-0004Cz-00; Thu, 30 Aug 2018 13:55:27 +0000 Date: Thu, 30 Aug 2018 09:55:27 -0400 From: Rich Felker To: Thomas Gleixner Cc: LKML , Peter Zijlstra , Ingo Molnar Subject: Re: futex_cmpxchg_enabled breakage Message-ID: <20180830135527.GT1878@brightrain.aerifal.cx> References: <20180829222221.GA22017@brightrain.aerifal.cx> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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. > > 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". > > 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. 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. > > 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. Rich