From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 62DAAC433F5 for ; Fri, 4 Feb 2022 18:58:42 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 7DF726B0072; Fri, 4 Feb 2022 13:58:41 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 78F6A6B0073; Fri, 4 Feb 2022 13:58:41 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 658146B0074; Fri, 4 Feb 2022 13:58:41 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0001.hostedemail.com [216.40.44.1]) by kanga.kvack.org (Postfix) with ESMTP id 57AAB6B0072 for ; Fri, 4 Feb 2022 13:58:41 -0500 (EST) Received: from smtpin10.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay02.hostedemail.com (Postfix) with ESMTP id 1035189929 for ; Fri, 4 Feb 2022 18:58:41 +0000 (UTC) X-FDA: 79106008842.10.C168CD0 Received: from smtp-relay-internal-1.canonical.com (smtp-relay-internal-1.canonical.com [185.125.188.123]) by imf11.hostedemail.com (Postfix) with ESMTP id 8473F40003 for ; Fri, 4 Feb 2022 18:58:40 +0000 (UTC) Received: from mail-pl1-f200.google.com (mail-pl1-f200.google.com [209.85.214.200]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by smtp-relay-internal-1.canonical.com (Postfix) with ESMTPS id 3ACD93F1A1 for ; Fri, 4 Feb 2022 18:58:38 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=canonical.com; s=20210705; t=1644001118; bh=QC1X2RM71Awb1moshBsuaGTei8lAkzyYiOUHcrb832I=; h=MIME-Version:References:In-Reply-To:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=cOGC16owCFsP+cYPY4PacamEBe8rQIbIn+Qjyw4On1ZnhFoTa3741La5wmrIHP64/ CGoZWaoHbf+76zeuLNkbsQgY0rNw3IOVApNXkbKdxCm4xTf7alrphN2PYwsdLIK1MX CN46QHX9IuigW9TTW3gP/Q+X1KG0R/xZ6nBMATeRCDppGLZcvr0qt5qvzDxf76UX6v b23okqhgqX1J4Gojb6/Z9LuK9qV9kY4BzO6exqdWUy1t+XP6hH9cXcjCRBVaaE5blj NDGsLJ9SUW8b3/MMOlFkFXGg1lm5lpqHEP+jJrgzhJgY+V7hrTiNViQlzx8ZIrtHaz MgJA7hcbwiDYA== Received: by mail-pl1-f200.google.com with SMTP id y13-20020a170902d64d00b0014cea2afd46so3509278plh.12 for ; Fri, 04 Feb 2022 10:58:38 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=QC1X2RM71Awb1moshBsuaGTei8lAkzyYiOUHcrb832I=; b=CLc+/KqhrSjVU4fXXTbXT/R6hQHc2SOHli4pImvKafCa6TQ6usFwCusdNXQGurAQv1 Qa0gr8fY5g1YRrnWErXHVwSAGUmbv0tFQYkHLMM8Zfa7p7M05foRlSDAcG7YylyxDdBt NziRKid7p3Hv9bMS9oyjQ+FZ7gQmMI7V9MO1HodDd/XNp8RBmviXKK55X4+AuwpMzaO1 KnVqwXAPJ9PfmpZZzuoP3e2WQXHqPaCt4e2OYrbUGrZY3Kh3IwSa4T+ldi6TEKLYTpQY WNkDe1Z9B0j0IrvwNCpbeEonBOeh5K4ohTuuK1MdaNJOGL0Dj6fVbYt7U4EorqC8txnI Pbig== X-Gm-Message-State: AOAM533LyyLzZuw/J/ThgXfZC+Yz9gVH8yvJ+rjCQ/wnISCslptPsRZu iq79XZdol5vQ3c0mOuqTbRNNSGMs/I+NwrS9XNP0UXPIc1EMachgUSjJ4tk3mFVMuFyhmpZTL5/ ePYTkPQEv4mKA5G6QiOdb1uFlgSFGmlbX19XGIDTfAWcM X-Received: by 2002:a17:902:b189:: with SMTP id s9mr4485542plr.112.1644001116753; Fri, 04 Feb 2022 10:58:36 -0800 (PST) X-Google-Smtp-Source: ABdhPJzuk7oKvRr5g5rTmO/g4zY0rk6mbprl0xb/vtL7A7Epg/efssaXqnqWVn9eorBVMSJVXU29JHGqszbnckbLPqY= X-Received: by 2002:a17:902:b189:: with SMTP id s9mr4485508plr.112.1644001116472; Fri, 04 Feb 2022 10:58:36 -0800 (PST) MIME-Version: 1.0 References: <20220131230255.789059-1-mfo@canonical.com> In-Reply-To: From: Mauricio Faria de Oliveira Date: Fri, 4 Feb 2022 15:58:24 -0300 Message-ID: Subject: Re: [PATCH v3] mm: fix race between MADV_FREE reclaim and blkdev direct IO read To: Yu Zhao Cc: John Hubbard , Minchan Kim , "Huang, Ying" , Andrew Morton , Yang Shi , Miaohe Lin , Linux-MM , linux-block@vger.kernel.org Content-Type: text/plain; charset="UTF-8" X-Rspamd-Server: rspam04 X-Rspamd-Queue-Id: 8473F40003 X-Rspam-User: nil Authentication-Results: imf11.hostedemail.com; dkim=pass header.d=canonical.com header.s=20210705 header.b=cOGC16ow; dmarc=pass (policy=none) header.from=canonical.com; spf=pass (imf11.hostedemail.com: domain of mauricio.oliveira@canonical.com designates 185.125.188.123 as permitted sender) smtp.mailfrom=mauricio.oliveira@canonical.com X-Stat-Signature: fiee98tfkm7dxp1j18hrf1jndqa4kpd5 X-HE-Tag: 1644001120-159237 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Fri, Feb 4, 2022 at 2:57 AM Yu Zhao wrote: > > On Thu, Feb 3, 2022 at 3:17 PM Mauricio Faria de Oliveira > wrote: > > > > On Wed, Feb 2, 2022 at 6:53 PM Yu Zhao wrote: [...] > > > Got it. IIRC, get_user_pages() doesn't imply a write barrier. If so, > > > there should be a smp_wmb() on the other side: > > > > If I understand it correctly, it actually implies a full memory > > barrier, doesn't it? > > > > Because... gup_pte_range() (fast path) calls try_grab_compound_head(), > > which eventually calls* atomic_add_unless(), an atomic conditional RMW > > operation with return value, thus fully ordered on success (atomic_t.rst); > > (on failure gup_pte_range() falls back to the slow path, below.) > > > > And follow_page_pte() (slow path) calls try_grab_page(), which also calls > > into try_grab_compound_head(), as the above. > > > > (* on CONFIG_TINY_RCU, it calls just atomic_add(), which isn't ordered, > > but that option is targeted for UP/!SMP, thus not a problem for this race.) > > > > Looking at the implementation of arch_atomic_fetch_add_unless() on > > more relaxed/weakly ordered archs (arm, powerpc, if I got that right), > > there are barriers like 'smp_mb()' and 'sync' instruction if 'old != unless', > > so that seems to be OK. > > > > And the set_page_dirty() calls occur after get_user_pages() / that point. > > > > Does that make sense? > > Yes, it does, thanks. I was thinking along the lines of whether there > is an actual contract. [...] Ok, got you. > [...] The reason get_user_pages() currently works as > a full barrier is not intentional but a side effect of this recent > cleanup patch: > commit 54d516b1d6 ("mm/gup: small refactoring: simplify try_grab_page()") > But I agree your fix works as is. Thanks for bringing it up! That commit and its revert [1] (that John mentioned in his reply) change only try_grab_page() / not try_grab_compound_head(), thus should affect only the slow path / not the fast path. So, with either change or revert, the slow path should still be okay, as it takes the page table lock, and try_to_unmap_one() too, thus they shouldn't race. And the spinlock barriers get values through. Thanks, [1] commit c36c04c2e132 ("Revert "mm/gup: small refactoring: simplify try_grab_page()"") -- Mauricio Faria de Oliveira