Received: by 2002:a25:ab43:0:0:0:0:0 with SMTP id u61csp4578134ybi; Mon, 3 Jun 2019 13:27:09 -0700 (PDT) X-Google-Smtp-Source: APXvYqziNjJKHKincV6xJspQdy/QYyDjAB5tDaqP0yeZRKlrnUBB2QEUWmr/U2MbRN8MDzhWhPIW X-Received: by 2002:a63:6848:: with SMTP id d69mr31498663pgc.0.1559593629618; Mon, 03 Jun 2019 13:27:09 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1559593629; cv=none; d=google.com; s=arc-20160816; b=y0CrqE2xC8pUTch1AZ5iY7fOIzT7B3V8u0XKIjxOVI94aM9UQywkVndzQ2yCOdhvEn W5CyBOGW+K+Z8BgnjZbJrnxiESZp3RUL92ejz6X5EbFY/tLuliQ4rTfJ44/PtNVVQ4UP avyac97d2YoQB40xy/wG7UkE67qB5YzQ9nK6mbljosYxsIB/AcMJSmBqn609FrtBQzOE 7SpU8cD/BNkh30kXQLHBnKQ2Lckoz0gjhYQUJNBTNVoJS0PauySIOF4N3JCAmQyczv09 k+TfMjz97TkYz8yaqyEwGaOjzLJJyAK2Vawzd6kjIVXZhsbQOltTKqnfcUNMSBa0Ptjf JPvQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:dkim-signature; bh=u0bj5eMak8sMBiIk5v+RdqesL6i06Wpjl4vzJ82RYKU=; b=0yLCOdEri2R1a6xBjCxt63dESSLDXz1HaJa0bL7nsXuicrdpkQDGD7yCKEuFaScKA/ f7AYefVQfipKfRv0PvRPKfkVcETmftGgI/YwrsP9u7FV3YcVd17Go3elEfQMkC3XsFMD Jtzt+WdHcI6zxuhlhS0kWTYjWdh5sUuorrJ2DA4rjhynYwH4eevLrlCPSHOQCRBQj3x+ Y6XenqmytZRzA6NK+xU+6JGnNBPOGOpcZTKsCUZirMZwc7rAySaljT8Gr1F4QXzFZ8R2 xO951ihsmFyd3n3YrYy8yTI4lfSAvVAbCBAiO+oUDBc240JIndnyeEBBDWd7c+1bfAZ1 mPeg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linux-foundation.org header.s=google header.b=bGsk3ApG; 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 o6si14857274pgk.52.2019.06.03.13.26.53; Mon, 03 Jun 2019 13:27:09 -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; dkim=pass header.i=@linux-foundation.org header.s=google header.b=bGsk3ApG; 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 S1726867AbfFCUYx (ORCPT + 99 others); Mon, 3 Jun 2019 16:24:53 -0400 Received: from mail-lj1-f180.google.com ([209.85.208.180]:39881 "EHLO mail-lj1-f180.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725956AbfFCUYw (ORCPT ); Mon, 3 Jun 2019 16:24:52 -0400 Received: by mail-lj1-f180.google.com with SMTP id a10so14278941ljf.6 for ; Mon, 03 Jun 2019 13:24:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux-foundation.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=u0bj5eMak8sMBiIk5v+RdqesL6i06Wpjl4vzJ82RYKU=; b=bGsk3ApGDZofDzGKFHvgiBN2+VdwbPx2ArHRIU4LNh7QQIwKy63JvZxImcCbDKyk8G kc4WjI69EAIRouwHENLzyO0GCNo2pwNo6/G88NTI5GZj89b/vNeksbJhCNhCr38YYv3C uPimuKUBbplSefi7zlDLj8BRg9cyvXFjvK5Lg= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=u0bj5eMak8sMBiIk5v+RdqesL6i06Wpjl4vzJ82RYKU=; b=eITw3Smc8METUi8ZHnxTr2WnrAxXp1JZ+/pCyjlVOKF8S/Qj6TwfvkabTt7bZPjuP9 VVnPvDzsWsTWFXSZgY10W7baQN920pf2V/rs8wygyeYnsod3p1C0qt/RhKDvyLkKlvNl 1b87Rl7Xs9gnczx7aTLq7QfjXCRi+oT67IZp6wYlB9MxRvTtzbgrQRKGEP+Kv7ATIbcd sUwInq0+5xMqMi8LCX4mumffOZ1pe8XmXfnA/32bOW1bq+6SnXkx1u3eG1f3/2Y9/p/B z3l7xTTdl2RgaPG6lKhDkLZPGcHeP76FoL4Io/UcGzuzpc7PwdI2m6pZZ7n1MwtpVwLl bzjQ== X-Gm-Message-State: APjAAAWzZQX+Q+8v9vCxBKvi/H7kqdzEJP5DdQ4JtE32Z8DLiraOdonm 0wAiWpMFSCCXj/985RS1jtDM/0ldd1U= X-Received: by 2002:a2e:9f41:: with SMTP id v1mr8434141ljk.66.1559593489647; Mon, 03 Jun 2019 13:24:49 -0700 (PDT) Received: from mail-lj1-f171.google.com (mail-lj1-f171.google.com. [209.85.208.171]) by smtp.gmail.com with ESMTPSA id a4sm3342214lfj.31.2019.06.03.13.24.48 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 03 Jun 2019 13:24:48 -0700 (PDT) Received: by mail-lj1-f171.google.com with SMTP id j24so17548603ljg.1 for ; Mon, 03 Jun 2019 13:24:48 -0700 (PDT) X-Received: by 2002:a2e:85d1:: with SMTP id h17mr14759938ljj.1.1559593488055; Mon, 03 Jun 2019 13:24:48 -0700 (PDT) MIME-Version: 1.0 References: <20150910102513.GA1677@fixme-laptop.cn.ibm.com> <20150910171649.GE4029@linux.vnet.ibm.com> <20150911021933.GA1521@fixme-laptop.cn.ibm.com> <20150921193045.GA13674@lerouge> <20150921204327.GH4029@linux.vnet.ibm.com> <20190602055607.bk5vgmwjvvt4wejd@gondor.apana.org.au> <20190603000617.GD28207@linux.ibm.com> <20190603030324.kl3bckqmebzis2vw@gondor.apana.org.au> <20190603195304.GK28207@linux.ibm.com> In-Reply-To: <20190603195304.GK28207@linux.ibm.com> From: Linus Torvalds Date: Mon, 3 Jun 2019 13:24:32 -0700 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: rcu_read_lock lost its compiler barrier To: "Paul E. McKenney" Cc: Herbert Xu , Frederic Weisbecker , Boqun Feng , Fengguang Wu , LKP , LKML , Netdev , "David S. Miller" Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Jun 3, 2019 at 12:53 PM Paul E. McKenney wrote: > > I agree that !PREEMPT rcu_read_lock() would not affect compiler code > generation, but given that get_user() is a volatile asm, isn't the > compiler already forbidden from reordering it with the volatile-casted > WRITE_ONCE() access, even if there was nothing at all between them? > Or are asms an exception to the rule that volatile executions cannot > be reordered? Paul, you MAKE NO SENSE. What is wrong with you? I just showed you an example of where rcu_read_lock() needs to be a compiler barrier, and then you make incoherent noises about WRITE_ONCE() that do not even exist in that example. Forget about your READ_ONCE/WRITE_ONCE theories. Herbert already showed code that doesn't have those accessors, so reality doesn't match your fevered imagination. And sometimes it's not even possible, since you can't do a bitfield access, for exmaple, with READ_ONCE(). > We can of course put them back in, Stop the craziness. It's not "we can". It is a "we will". So I will add that barrier, and you need to stop arguing against it based on specious theoretical arguments that do not match reality. And we will not ever remove that barrier again. Herbert already pointed to me having to do this once before in commit 386afc91144b ("spinlocks and preemption points need to be at least compiler barriers"), and rcu_read_lock() clearly has at a minimum that same preemption point issue. Linus