Received: by 2002:ac0:a5a6:0:0:0:0:0 with SMTP id m35-v6csp2214337imm; Sat, 15 Sep 2018 11:42:10 -0700 (PDT) X-Google-Smtp-Source: ANB0VdZS69hp1lEDI/XSbeve2IvtniPi/CFbgf/HUcWJ/A5fZYfim53Bav9J3o3V9yyMDRfuJUJZ X-Received: by 2002:a63:5660:: with SMTP id g32-v6mr16498346pgm.227.1537036930430; Sat, 15 Sep 2018 11:42:10 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1537036930; cv=none; d=google.com; s=arc-20160816; b=KPPsV8XxUp6cxrneEDQKCYQfdJwWQo2Smej1Xh1w0husWgplmKd3WbNjDCenedmx64 CyGSXPbiZ9buWVsMuictyTJdqsYwCgmNKRz0FOMU10Nm4upKyevkYjjKiI6N5B411lG9 SI7dq4Y9RWeAkQrr9Ewy08soXK0u5S1MLmNTgMO53rqvbpzXAlWzS87998rlYrVn3fMC T2RDaj0xrJLKqKqj7Ik5olpV1EFiKR0Yc86iIVt6xuQ38cHYIP0QDTnlkOD88LpFnUpx A+w41Q8EX1tzcTvcCCM0JW25QihzvUxsTydwEU6o1HF1DxnIL5cK9tG+sz4ZHSiq1fRy vvKw== 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=7b6sQQ03GGcvERh6T2+OgK2FI+QB50fn3VxFBDC6Tuo=; b=Lh/EaHxmuFf99iuWuUPL8YwAVnqnfWNPUoCHx9xxMvyYLGx8XrGaBpGzP8Msi9rLaM zjoV2TnGrXvvR/vpCDMnOw17eUD2GnMeN0vgJQs6QCwn4yQq+k1GikIxVnKutqDL7c7+ 98sdQVxbQNf8Q0XpFb/CkAY+z9q456qd+b+1mVNrfR8LpbCCu++ONd2zbB93fTd+t55y gT2PcwgiWgTo/iPWyVF2HE/PJt0UD8jWT9aK4zUGEZ9wVGhYoV5vnyKb3jCVdst212e/ 4PFM5xuBNDoJEpRYIy5bkMjzt5BoCx47sAc3C97ubVIC0Xf9lkFQxHCLrstffvf8pGl+ 0ZPw== 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 38-v6si566172pgn.612.2018.09.15.11.41.54; Sat, 15 Sep 2018 11:42:10 -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 S1727866AbeIOX7M (ORCPT + 99 others); Sat, 15 Sep 2018 19:59:12 -0400 Received: from Galois.linutronix.de ([146.0.238.70]:52047 "EHLO Galois.linutronix.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727842AbeIOX7L (ORCPT ); Sat, 15 Sep 2018 19:59:11 -0400 Received: from p5492e4c1.dip0.t-ipconnect.de ([84.146.228.193] helo=nanos) by Galois.linutronix.de with esmtpsa (TLS1.2:DHE_RSA_AES_256_CBC_SHA256:256) (Exim 4.80) (envelope-from ) id 1g1FTM-0003uR-WD; Sat, 15 Sep 2018 20:39:13 +0200 Date: Sat, 15 Sep 2018 20:39:12 +0200 (CEST) From: Thomas Gleixner To: Rich Felker cc: LKML , Peter Zijlstra , Ingo Molnar Subject: Re: futex_cmpxchg_enabled breakage In-Reply-To: <20180915161554.GS1878@brightrain.aerifal.cx> Message-ID: References: <20180829222221.GA22017@brightrain.aerifal.cx> <20180830135527.GT1878@brightrain.aerifal.cx> <20180915161554.GS1878@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 Sat, 15 Sep 2018, Rich Felker wrote: > On Sat, Sep 15, 2018 at 05:34:24PM +0200, Thomas Gleixner wrote: > > 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. > > The bug, if it's a bug (lack of memory protection on a system that > explicitly does not have memory protection is not a bug), is unrelated > to futexes, so having futex functionality break is not a very > intuitive way of leading people to find the bug. If kernel developers > really want to consider 0-address-is-mapped a bug (conditional on > CONFIG_MMU) there should be some test separate from futex that does > BUG_ON(attempt to access *0 != EFAULT). Fair enough. > > Cool, so you can have a NULL pointer dereference without noticing it. > > Yes, you can also clobber arbitrary kernel memory from userspace. Fun, eh? I was assuming that the mmu-less CPUs Linux runs on at least have a MPU nowadays. > > That's hardly a kernel issue, right? > > It's an issue of mismatched assumptions about the contract of these > interfaces. ENOSYS is a general contract. > > 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. > > I agree, but it would have been nice for that to be caught by BUG_ON, > not subtle failures in robust mutex functionality that would go > completely unnoticed in production until something broke horribly if > not for the affected user having been running conformance tests. > > For musl I will probably add code to pthread_mutexattr_setrobust that > probes whether SYS_get_robust_list fails, and errors out on attempts > to produce an attribute object with the robust flag set if the kernel > cannot support it, since there is no way to safely make forward > progress if the SYS_set_robust_list call fails later. But I was not > aware of the possibility of failure here, and apparently the glibc > folks were not either. They surely were when robust list and PI futex were introduced. That check got removed somewhere on the way for whatever reason. > In any case, morally it "should not" be able to fail -- some sort of > working cmpxchg is needed all over the place, at least in userspace > and likely also in kernelspace, and if the cpu lacks a direct way of > implementing it, whatever form of emulation is used elsewhere should > be used here. There is some history behind this test. In the early days when robust futexes and PI futexes were introduced we still had 386 around which did not have cmpxchg and there was no real requirement to emulate it. Other archictures like MIPS followed that and aside of the NOMMU/NOMPU case it simply should just work. We surely can revisit this on technical grounds, but I really fail to see any moral issues with a syscall returning -ENOSYS. Futexes can be compiled out completely and futex_pi is conditional as well. Thanks, tglx