Received: by 2002:ac0:a5a6:0:0:0:0:0 with SMTP id m35-v6csp374906imm; Thu, 27 Sep 2018 23:22:55 -0700 (PDT) X-Google-Smtp-Source: ACcGV60qo2gukNzzL1BWvZ18prfsYa/OD1NrSxXEG2mNshj+uSDyQvDmAp8fHZbOYhnevyYY0mrt X-Received: by 2002:a62:411a:: with SMTP id o26-v6mr15199171pfa.111.1538115775683; Thu, 27 Sep 2018 23:22:55 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1538115775; cv=none; d=google.com; s=arc-20160816; b=gVC9KoRq8dgKLb4yGAm1upSYuSGcfHwaCgBE98Jz0ws89Ar200gCMnSo1ybTBmhv+q XcWpc31fztTyuCKEMI1KQuGoonh7W7PNEZqgn/CE0BC8OIpy9heVLOPNzrESyGeuYwcI S1287YlQ7bgmYUWh/Gr2+nAY/+WbWhiIARaCpUM6bFWccl0rzGrIxOp5qnJihggTp0oz fLxXFOyT4vna0Yx27Cx8cnJY/KX+2gmTFjee2gag+yjcJXCXcHrOfbsq2Vc6g98Ssscs NRdV6nGQgYqlkYs0kYKYb5Fo15OpcDYrI38/Wg328bzOQDPR7U9Np5QJRt6ekdvQy4Lu lz6g== 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=t+LhnWzJhlDe373VHrzaRdujQU9g5ZocFtz7eoQFbG0=; b=LuhyE14O5OSSnQFvOQhxvOJ/E3dX+jomif3teNZvYa+hiNEswwEmRUkiXst0BMeGPn aJMA0pZ/dLTz2MKsoXWzndPVe78G70Pnqj0yFp4GMVTsM+0q23h7t1gRLiDhIR7zJJ/U W1o3fpFXlgFoYCINFi0ixreTqU5pj/9iASKd5Nwz/vyX4fvNkax6nBtDyomM4O2FSFXs rvArCBqKvnA/Kd7dOS3bcZkwuiDklC0KJHeBYSC1Fowi3igODcIsW2pWbdbBJ3lTVBgg bJ74cnK2BGJ3nfZrCJ+J9cXLnXOoCe4/Mg3BbwbtmCHt62xnFNUj1WQ9COpczS0498Gp 1IcA== 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 y8-v6si3863011pfm.141.2018.09.27.23.22.37; Thu, 27 Sep 2018 23:22:55 -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 S1728499AbeI1MnL (ORCPT + 99 others); Fri, 28 Sep 2018 08:43:11 -0400 Received: from Galois.linutronix.de ([146.0.238.70]:53451 "EHLO Galois.linutronix.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726473AbeI1MnL (ORCPT ); Fri, 28 Sep 2018 08:43: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 1g5m8z-0001LT-A8; Fri, 28 Sep 2018 08:20:54 +0200 Date: Fri, 28 Sep 2018 08:20:52 +0200 (CEST) From: Thomas Gleixner To: Andy Lutomirski cc: x86@kernel.org, Peter Zijlstra , Ingo Molnar , Darren Hart , LKML , linux-s390@vger.kernel.org, Martin Schwidefsky , Heiko Carstens , Finn Thain , Geert Uytterhoeven Subject: Re: [PATCH] futex: Set USER_DS for the futex_detect_cmpxchg() test In-Reply-To: <74fb6ce22f62e0fb48b91ca9918b74cedbcecaf1.1538096323.git.luto@kernel.org> Message-ID: References: <74fb6ce22f62e0fb48b91ca9918b74cedbcecaf1.1538096323.git.luto@kernel.org> 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, 27 Sep 2018, Andy Lutomirski wrote: > I have a couple questions here: > > - Is this actually okay on all architectures? That is, are there > cases where we'll screw up if we fail a USER_DS access this early? > s390 stands out as the obvious special case (where USER_DS is not > than just a subset of KERNEL_DS), but s390 opts out. > > - Why doesn't x86 set HAVE_FUTEX_CMPXCHG? Or do we still support > some 32-bit configurations that don't have cmpxchg and don't know > about it at compile time? I'm not entirely sure. Have to dig into the details. I assume S390 just can set it though. Thanks, tglx > kernel/futex.c | 4 ++++ > 1 file changed, 4 insertions(+) > > diff --git a/kernel/futex.c b/kernel/futex.c > index 11fc3bb456d6..16bd3e72602a 100644 > --- a/kernel/futex.c > +++ b/kernel/futex.c > @@ -3593,6 +3593,7 @@ static void __init futex_detect_cmpxchg(void) > { > #ifndef CONFIG_HAVE_FUTEX_CMPXCHG > u32 curval; > + mm_segment_t old_seg; > > /* > * This will fail and we want it. Some arch implementations do > @@ -3604,8 +3605,11 @@ static void __init futex_detect_cmpxchg(void) > * implementation, the non-functional ones will return > * -ENOSYS. > */ > + old_seg = get_fs(); > + set_fs(USER_DS); > if (cmpxchg_futex_value_locked(&curval, NULL, 0, 0) == -EFAULT) > futex_cmpxchg_enabled = 1; > + set_fs(old_seg); > #endif > } > > -- > 2.17.1 > >