Received: by 2002:ac0:a5a6:0:0:0:0:0 with SMTP id m35-v6csp108767imm; Wed, 29 Aug 2018 15:24:41 -0700 (PDT) X-Google-Smtp-Source: ANB0VdYuMq8pKVlb7+z3e5qp1DhrH1xAEO6rcCxJe4X1sTzw1u61cSusjQtQfPEj0g2Ev9Zb0T5j X-Received: by 2002:a63:1f0a:: with SMTP id f10-v6mr7164611pgf.66.1535581481370; Wed, 29 Aug 2018 15:24:41 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1535581481; cv=none; d=google.com; s=arc-20160816; b=BPoauc27irr8j2eB/kNGSTrkMNoK/wPwN2l4eqcgSjrr9tfWccwjVDKiAD3iaTCmyF 3wqM6TPqx3n9jvl0a5M4nFyBmndHFrzo+a3eZrrSkGUJi/z8Her4QczfF5W3dKV/iGdZ JTDQMwSQtHjO5IpTdvJrAs0CSmnV5eL6qJV/E/Da2WQv/GM41hMRjar68YgwYKxxuiKL m1Q6+06z9Fj4W4e3u/DR4j7wBJikxHeaDuPLlQIsUNQ6jCBCvy5uXMqqW+E/CEWROwP2 j+Dx4uN1GR+mNnKIbXqe8Ca+YwUkn4PQBSx05H+RKtAZxWNoJ98hVGunQgl7JLLxzgqP ZFxw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:content-disposition :mime-version:message-id:subject:cc:to:from:date :arc-authentication-results; bh=fg2pTnZag8nxEDZRzNggzPwerLvwT2fhwMizRe22hi0=; b=tFYy2jUK0IKeSmZq/bk3dbtzZMxqoPRElsu+8jTIKBFkH3vANTCrs3kS30fdCGxEHX lhhAA5Mi3QV0woMmCIqxC5pxLkJHg6e/spuPCXF373eI+SsJSFsSbk399TO1RCOXY3TY md8TKs7DFQbtVba/mormdEaDmv7nohpcXX5+CYmd7vGzzxFowdf8VCtGeC3tNpKlfDYd Vg8juRq0b5QM423kBirfVkYjEU+6ie+EWs+PU6B1JCGo2wFX5KaZlpdjPtXbHUOC2nk4 JrXjQxYUvZA519Nnds52LWQ+sg+8JzbQ3x9XKEIjojbNccP3+5EXPDyuhMS0/vJb8GtZ TLbA== 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 d31-v6si4897620pla.479.2018.08.29.15.24.26; Wed, 29 Aug 2018 15:24:41 -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 S1727742AbeH3CVY (ORCPT + 99 others); Wed, 29 Aug 2018 22:21:24 -0400 Received: from 216-12-86-13.cv.mvl.ntelos.net ([216.12.86.13]:56686 "EHLO brightrain.aerifal.cx" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727294AbeH3CVX (ORCPT ); Wed, 29 Aug 2018 22:21:23 -0400 Received: from dalias by brightrain.aerifal.cx with local (Exim 3.15 #2) id 1fv8qz-0005lZ-00; Wed, 29 Aug 2018 22:22:21 +0000 Date: Wed, 29 Aug 2018 18:22:21 -0400 From: Rich Felker To: Thomas Gleixner Cc: linux-kernel@vger.kernel.org Subject: futex_cmpxchg_enabled breakage Message-ID: <20180829222221.GA22017@brightrain.aerifal.cx> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline 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 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. 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. 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. 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. 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? Rich