Received: by 2002:ac0:e350:0:0:0:0:0 with SMTP id g16csp2020117imn; Mon, 1 Aug 2022 08:20:46 -0700 (PDT) X-Google-Smtp-Source: AA6agR6wqZlq6I7FjW2TY2bSbXHXRWWvMJlmmWNs7sZSspQwBkw+OHs4zc8DYkcSsChNFDBS7yGP X-Received: by 2002:a17:906:5a4e:b0:730:8f6a:6cc5 with SMTP id my14-20020a1709065a4e00b007308f6a6cc5mr2890205ejc.405.1659367246526; Mon, 01 Aug 2022 08:20:46 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1659367246; cv=none; d=google.com; s=arc-20160816; b=W/5w+McRf/e2/EcKhwnEZa4FYN2OZFee00SXGq8RSSDN9GFxe+tB5hpfiiaxal6lKw Z9u0kHO57kerPTobDofJmT7erQLeZK7xS41i9I5u2FotWCTbMgYYfoYvDVhg8thUsWcV FEkAt7Q1+GRyC+kSnL+Yfte5RTmzMii4l9oT9/rRfOg8MjTMcN46eDrLkBhBVOdvBhO7 7lGQOiaPDgfiD35PHgsZkiIW48YHDUO834bMITlVF7npc36xm3q7GyT6P0U/4DET7NIP /dCp0qGgALqrYShGAfY0aVP5YF1lnjNzlu4THrOEp6yh9uGLef9VVKCEoIw4kz/9/6bW 4tYA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:mime-version:user-agent:references:message-id :in-reply-to:subject:cc:to:from:date:dkim-signature; bh=iiba4+W7jZLYO1ySi5qFdgb2HBH/IsPBRLKYnq1fXIY=; b=BQgOwCARdjI+mC9KRZOjhEKflF3T939V1yAzNTvoeSrcW7PFX9OLaG038wDjga1BLV 5jQMI9a+/z2W882cHGSn8FeurbrvPj1jEDcQTdMFPcoOS3zB2aY6geLQNezKaOM0ExJI YGkFSTLBWeO22/YPvibUNahgGbTDT7py2bjQKv4kdSwRqnCP6b7eE+evzJxcrhFB8Kuq 894Rt2NR51wKt2H9mOd8EDvHL17tdp+5tieK3y7wScKLOEg7jHgEe0h5dd4mieMPWnsF 1oj9JwDMRL6sYQM5Ahk+aytPjjFSNXP0Pc4qMwHa0reHEkEjnkCYfbL8ufnGKY86mnRq +nrw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b="E/9uFwkj"; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id dm3-20020a170907948300b0072faa2118dbsi10511290ejc.219.2022.08.01.08.20.19; Mon, 01 Aug 2022 08:20:46 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b="E/9uFwkj"; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S233081AbiHAPCA (ORCPT + 99 others); Mon, 1 Aug 2022 11:02:00 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:42118 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231876AbiHAPBx (ORCPT ); Mon, 1 Aug 2022 11:01:53 -0400 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id 8C3A424955 for ; Mon, 1 Aug 2022 08:01:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1659366111; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=iiba4+W7jZLYO1ySi5qFdgb2HBH/IsPBRLKYnq1fXIY=; b=E/9uFwkjVi1U4SKMJ21bEGHNlvd8piJUUjxtp/nkv3fxJP++YJEbz5BOQDIIknWcnYmr7Y J61F7V7Cj/MrRu058FtthTiZQ6xf4mheYkpQ8jVE7JXe8R0SZWZpkA1kGfflDvRGL8HPwn z4QyIvZN1jYVQE4Ob9zVXUoircMqRyM= Received: from mimecast-mx02.redhat.com (mimecast-mx02.redhat.com [66.187.233.88]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-399--nIrmDyMNk-h82Qyrwe4lQ-1; Mon, 01 Aug 2022 11:01:47 -0400 X-MC-Unique: -nIrmDyMNk-h82Qyrwe4lQ-1 Received: from smtp.corp.redhat.com (int-mx08.intmail.prod.int.rdu2.redhat.com [10.11.54.8]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id 3B02F801585; Mon, 1 Aug 2022 15:01:41 +0000 (UTC) Received: from file01.intranet.prod.int.rdu2.redhat.com (file01.intranet.prod.int.rdu2.redhat.com [10.11.5.7]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 257C1C27D95; Mon, 1 Aug 2022 15:01:41 +0000 (UTC) Received: from file01.intranet.prod.int.rdu2.redhat.com (localhost [127.0.0.1]) by file01.intranet.prod.int.rdu2.redhat.com (8.14.4/8.14.4) with ESMTP id 271F1f8v028288; Mon, 1 Aug 2022 11:01:41 -0400 Received: from localhost (mpatocka@localhost) by file01.intranet.prod.int.rdu2.redhat.com (8.14.4/8.14.4/Submit) with ESMTP id 271F1eJk028270; Mon, 1 Aug 2022 11:01:40 -0400 X-Authentication-Warning: file01.intranet.prod.int.rdu2.redhat.com: mpatocka owned process doing -bs Date: Mon, 1 Aug 2022 11:01:40 -0400 (EDT) From: Mikulas Patocka X-X-Sender: mpatocka@file01.intranet.prod.int.rdu2.redhat.com To: Matthew Wilcox cc: Linus Torvalds , Will Deacon , "Paul E. McKenney" , Ard Biesheuvel , Alexander Viro , Alan Stern , Andrea Parri , Peter Zijlstra , Boqun Feng , Nicholas Piggin , David Howells , Jade Alglave , Luc Maranget , Akira Yokosawa , Daniel Lustig , Joel Fernandes , Linux Kernel Mailing List , linux-arch , linux-fsdevel@vger.kernel.org Subject: Re: [PATCH v4 2/2] change buffer_locked, so that it has acquire semantics In-Reply-To: Message-ID: References: User-Agent: Alpine 2.02 (LRH 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Scanned-By: MIMEDefang 2.85 on 10.11.54.8 X-Spam-Status: No, score=-3.4 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_LOW, SPF_HELO_NONE,SPF_NONE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, 1 Aug 2022, Matthew Wilcox wrote: > On Mon, Aug 01, 2022 at 06:43:55AM -0400, Mikulas Patocka wrote: > > Let's have a look at this piece of code in __bread_slow: > > get_bh(bh); > > bh->b_end_io = end_buffer_read_sync; > > submit_bh(REQ_OP_READ, 0, bh); > > wait_on_buffer(bh); > > if (buffer_uptodate(bh)) > > return bh; > > Neither wait_on_buffer nor buffer_uptodate contain any memory barrier. > > Consequently, if someone calls sb_bread and then reads the buffer data, > > the read of buffer data may be executed before wait_on_buffer(bh) on > > architectures with weak memory ordering and it may return invalid data. > > > > Fix this bug by changing the function buffer_locked to have the acquire > > semantics - so that code that follows buffer_locked cannot be moved before > > it. > > I think this is the wrong approach. Instead, buffer_set_uptodate() > should have the smp_wmb() and buffer_uptodate should have the smp_rmb(). > Just like the page flags. As I said last night. Linus said that he prefers acquire/release to smp_rmb/smp_wmb. So, sort it out with him :) In most cases, the buffer is set uptodate while it is locked, so that there is no race on the uptodate flag (the race exists on the locked flag). Are there any cases where the uptodate flag is modified on unlocked buffer, so that it needs special treatment too? Mikulas