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 X-Spam-Level: X-Spam-Status: No, score=-13.3 required=3.0 tests=BAYES_00,DKIMWL_WL_MED, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED,USER_IN_DEF_DKIM_WL autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 9AE0FC49EA3 for ; Mon, 14 Jun 2021 04:47:50 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 29C19611CE for ; Mon, 14 Jun 2021 04:47:50 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 29C19611CE Authentication-Results: mail.kernel.org; dmarc=fail (p=reject dis=none) header.from=google.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id C1F6D6B006E; Mon, 14 Jun 2021 00:47:49 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id BF6BD6B0070; Mon, 14 Jun 2021 00:47:49 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id ABEF36B0071; Mon, 14 Jun 2021 00:47:49 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0161.hostedemail.com [216.40.44.161]) by kanga.kvack.org (Postfix) with ESMTP id 79A616B006E for ; Mon, 14 Jun 2021 00:47:49 -0400 (EDT) Received: from smtpin36.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay04.hostedemail.com (Postfix) with ESMTP id 1373C5DE0 for ; Mon, 14 Jun 2021 04:47:49 +0000 (UTC) X-FDA: 78251096658.36.248B077 Received: from mail-lf1-f43.google.com (mail-lf1-f43.google.com [209.85.167.43]) by imf03.hostedemail.com (Postfix) with ESMTP id 54DBDC0091AE for ; Mon, 14 Jun 2021 04:47:40 +0000 (UTC) Received: by mail-lf1-f43.google.com with SMTP id j2so18756873lfg.9 for ; Sun, 13 Jun 2021 21:47:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=DivavMZT0DB2lVtUmC7mfKuI7ok3bEvks33og/PTQuY=; b=Y3A66Aj51d6devffT4DrhfOmQDaaJSZwLeMBQmUZGi0XNSY4n4PmYsEuW6bcb8qukh 7H4Ohj/Vl6bEUCIa05VyiKYnSoyzsRfc2WRik9uYHX0Bv4X8/vcSqmjJeUFuYc92Y6Gk vyLmc3poDD0GGX+/EyWeZoQ+hXaaxGw4YikQeTWKNon7FYicGD3C0z4/hmyZXomxs8l3 y4475d5ROQmeAXL6EAhMJllWd5I+gOWnYsXz21xvSXvUXgcHJOb5ygCk4U21kPEhbBGG 6czLZcgYdWiWaw4D19aFu6MRi6Y2nudO0Chh+/bA7i3MXAlh53Evh0VnRMHQhtiVtTQn KNBA== 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=DivavMZT0DB2lVtUmC7mfKuI7ok3bEvks33og/PTQuY=; b=fDxwq4x80kccBNXSU1n6QSt+f6w487CkbUkq9OatY+uI5yBj9ROByFaSzMskJ02wB0 rLTSNxsCuUwmUVoZHrp5HPKtLEh21myqejnomEb8rw237hMAjDBZwnB/PUqspoxMyE1/ OSPJz9lGOwXlqH7lufe4Zb+jd/eVpHKAE+80a8/TKM3Tk9H5uGw1sCe+CIJ3ZkZfwA2I QLKEst0KFLT6kKNxs39TcRn2YOb/06AzxmVGOi0Q/wlJ4idvtT5YtHX72/LLO+6Z9/k+ jLHJU5DHtfLbCs2uhfpjAC96TUgvhv3wHB8Hk8oxCf2dGk+1BvLdw8U33aiashZaNKrN n3jQ== X-Gm-Message-State: AOAM531E/r1f0IZLQ2Omi0r+GKE70GXFkQz3hTZqIn5qltSVUJMnVjme ToIRgcMMkX5YPJXu1tF1gPiqGfEUFyFP5mcm1YNCQg== X-Google-Smtp-Source: ABdhPJxezLRUpsDqbMvqKsqU8sSDXkc3WSFS/MgS11uY8Z0jxCWrHVN+P6xbSagXIWj26zJBpWhhgZXgDVEeprgUdGs= X-Received: by 2002:a05:6512:754:: with SMTP id c20mr10540300lfs.356.1623646066877; Sun, 13 Jun 2021 21:47:46 -0700 (PDT) MIME-Version: 1.0 References: <20210611161545.998858-1-jannh@google.com> <20210611153624.65badf761078f86f76365ab9@linux-foundation.org> <9041f85d-515d-576d-21a9-6f10b6e1279e@nvidia.com> In-Reply-To: <9041f85d-515d-576d-21a9-6f10b6e1279e@nvidia.com> From: Jann Horn Date: Mon, 14 Jun 2021 06:47:20 +0200 Message-ID: Subject: Re: [PATCH resend] mm/gup: fix try_grab_compound_head() race with split_huge_page() To: John Hubbard Cc: Andrew Morton , Linux-MM , kernel list , Matthew Wilcox , "Kirill A . Shutemov" , Jan Kara , stable Content-Type: text/plain; charset="UTF-8" X-Rspamd-Server: rspam01 X-Rspamd-Queue-Id: 54DBDC0091AE Authentication-Results: imf03.hostedemail.com; dkim=pass header.d=google.com header.s=20161025 header.b=Y3A66Aj5; spf=pass (imf03.hostedemail.com: domain of jannh@google.com designates 209.85.167.43 as permitted sender) smtp.mailfrom=jannh@google.com; dmarc=pass (policy=reject) header.from=google.com X-Stat-Signature: py5jsr8cze4rmx87pusinszhpud9wp5t X-HE-Tag: 1623646060-830743 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 Sat, Jun 12, 2021 at 12:17 PM John Hubbard wrote: > On 6/11/21 3:49 PM, Jann Horn wrote: > > On Sat, Jun 12, 2021 at 12:36 AM Andrew Morton > > wrote: > >> On Fri, 11 Jun 2021 18:15:45 +0200 Jann Horn wrote: > >>> +/* Equivalent to calling put_page() @refs times. */ > >>> +static void put_page_refs(struct page *page, int refs) > >>> +{ > >>> + VM_BUG_ON_PAGE(page_ref_count(page) < refs, page); > >> > >> I don't think there's a need to nuke the whole kernel in this case. > >> Can we warn then simply leak the page? That way we have a much better > >> chance of getting a good bug report. > > > > Ah, yeah, I guess that makes sense. I had just copied this over from > > put_compound_head(), and figured it was fine to keep it as-is, but I > > guess changing it would be reasonable. I'm not quite sure what the > > best way to do that would be though. > > > > I guess the check should go away in !DEBUG_VM builds? > > > > Should I just explicitly put the check in an ifdef block? Like so: > > > > #ifdef CONFIG_DEBUG_VM > > if (VM_WARN_ON_ONCE_PAGE(...)) > > return; > > #endif > > > > Or, since inline ifdeffery looks ugly, get rid of the explicit ifdef, > > Agreed: VM_WARN_ON_ONCE_PAGE(), at least at the API level, seems like > the best thing to use here. However, as you point out below, it needs a > little something first. > > > and change the !DEBUG_VM definition of VM_WARN_ON_ONCE_PAGE() as > > follows so that the branch is compiled away? > > > > #define VM_WARN_ON_ONCE_PAGE(cond, page) (BUILD_BUG_ON_INVALID(cond), false) > > > > That would look kinda neat, but it would be different from the > > behavior of WARN_ON(), which still returns the original condition even > > in !BUG builds, so that could be confusing... > > > > The VM_WARN_ON_ONCE_PAGE() is not implemented exactly right > in the !CONFIG_DEBUG_VM case. IMHO it should follow the WARN*() > behavior, and return the original condition and keep going > in that case. But the point of the existing definition is that the compiler can avoid generating code for the condition in !DEBUG_VM builds, even if it can't prove that the condition is free of side effects, right? If VM_WARN_ON_ONCE_PAGE() was changed as you propose, then I think that in mem_cgroup_page_lruvec(), the compiler would have to generate code for mem_cgroup_disabled(), which calls static_branch_likely(), which ends up in "asm volatile" statements; so the compiler probably won't be able to eliminate the condition. > Then you could use it directly here. Depending on whether the intended behavior here is to skip the check in !DEBUG_VM builds (which was the case before) or also perform the check in DEBUG_VM builds. And if DEBUG_VM is a config option because it might have some performance impact, isn't the cost of the check probably quite large compared to the cost of printing the warning on a codpath that should never execute?