Received: by 2002:a05:6a10:206:0:0:0:0 with SMTP id 6csp3276610pxj; Mon, 14 Jun 2021 19:43:21 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxTIp8FYdnjiZZSAin/21hO/mkcH/VvygdKunpfe82D8M6vyTS9/21u49huuCDwzCR7pCRR X-Received: by 2002:a17:907:3d8e:: with SMTP id he14mr18861926ejc.178.1623725001605; Mon, 14 Jun 2021 19:43:21 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1623725001; cv=none; d=google.com; s=arc-20160816; b=vRn7eeppmST241dhKsKZwUj1kFNXhUbnfvrm2accyHQ7EiRTVw9EL8DZbL3anRzFTY uNk/N1jHdavD2PVq0APCLCBlpheygzrh5zAecTWytBR/BvwuhW0v5g9ggoloQIolKSp4 0Cb3rpTuJto7ExP/mHTpEozIE5OJyhwkWM3UOjLwvwW5Yes0VvhhB7/Haa83nk3kSxzu vEkjQ5Iyx2phTW68/O5fKV1l/ndqlQehTFFVxmMgAN1wl6miIoDuF2quin+s+gKfsrBd hPAFWrpuW0UcG+BCvAJFOxUqQeDYBQopwPgaAW5NTkBbA/HD4zFOMgHzizB0uGN3waGx NwPw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:dkim-signature; bh=SFi/PESNY2XSZin92wkim2B0LZCDsgyMMnEnAZQIW7I=; b=Wp3dg4cS9SJZrj9l3iAvOiiPJyXJQ96taFTn/Bhw0b191WKSwvYH8do47KtQBfULta WS0iJKNNcvvLWdE2ejkEVSOAyRnfZk9iX1JryzGpDVdL3H+gqeXiOsYaBIo8Ydm4wrs0 Ny1l0Gy/Af2SkWXPydtniHDR0xUnGcMXvDtq9LjutWZPZj6mvaMUJp2/X3z34x1kcT0m B7H0IPZx4mc2pLWBQX6znN4GLsguJ20vM2EL3pxGoBo4ylV/QCYaD/JtBQtW4fCpxven C29cZex9m+YS1gJRIpTURBwTMW56m6hr1PDVds5c6ewy502WuDmiVbwLjBC1/xIafaA5 JM/g== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20161025 header.b=mMeDPg+6; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id ga21si12817514ejb.24.2021.06.14.19.42.59; Mon, 14 Jun 2021 19:43:21 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@google.com header.s=20161025 header.b=mMeDPg+6; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231249AbhFOCjN (ORCPT + 99 others); Mon, 14 Jun 2021 22:39:13 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:46570 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230302AbhFOCjG (ORCPT ); Mon, 14 Jun 2021 22:39:06 -0400 Received: from mail-lf1-x12c.google.com (mail-lf1-x12c.google.com [IPv6:2a00:1450:4864:20::12c]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 7FF02C061574 for ; Mon, 14 Jun 2021 19:37:02 -0700 (PDT) Received: by mail-lf1-x12c.google.com with SMTP id q20so9515601lfo.2 for ; Mon, 14 Jun 2021 19:37:02 -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=SFi/PESNY2XSZin92wkim2B0LZCDsgyMMnEnAZQIW7I=; b=mMeDPg+6+57U2DKhGXBPf7UuJ7VxGkYjJYFJsx1UEL7vvoJ78od1BcqWFXUJ//QZcB 5eCSb3mpjkABlGvAfmdz3BFYfLJ6UkJkPB5bEqPXsAW3ZShbx4z2Hq5+j4XwLBbAFwd1 puipJO5qVZwaq+C7ydPd60pNBaYwLIM08pYY/7E646HsgOXkaUC570FSj1y0C5INir+X LWd8ekf7FuAaPgqcOslVyJMHqu7LqgHftXlv00cJY7oAiqMEbbgs4qfZ8Ml2NnE5yZkC OJCo7xUvuIPUcZJPwSWpAG7tcN762iJNWKWmh8vZTTDJGgl22uO/JcrZjZJXfdf028m9 HJ6A== 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=SFi/PESNY2XSZin92wkim2B0LZCDsgyMMnEnAZQIW7I=; b=W6gXOWTefx6D1qAzUvw//LWAS7VS54+p9C+fx16JFb2FYIEX5Jo9+Ngc2nJqLrg0bH IdIjZhUjHLlaeEl7yahPM+CkZPXbMX8Ff8m+vhiHS8t60eCfWjzr936t0jUPID8RwNFi Og5nuZP55RFJG5CKQRVE7XDhh6gBAesmJSPWwWrl9XUoupAAnof5AujVOazzFTiKWU2W SO7KgQIDrUI63g1VyqK62XLXi7+ql0979RN429BWyTaEaNGN27kZLFdJV8+FeOPuDDnd YO7YqSbnTP23OW2viunR8oYaJYjR1IpsS60DZcMgq0fazI+3FcYwpiCFKKbMayrgDp8L +v2g== X-Gm-Message-State: AOAM533rPRbILkht1HhnLwA9yMWk1TiBaiYALjyhereKwUKv1UcTasVW sENK4i18fyCE2K3Nf8Wd5HCF0qqkB+Wxx+/aox5W6w== X-Received: by 2002:a19:ef0a:: with SMTP id n10mr13670605lfh.352.1623724620645; Mon, 14 Jun 2021 19:37:00 -0700 (PDT) MIME-Version: 1.0 References: <20210615012014.1100672-1-jannh@google.com> <20210614190032.09d8b7ac530c8b14ace44b82@linux-foundation.org> In-Reply-To: <20210614190032.09d8b7ac530c8b14ace44b82@linux-foundation.org> From: Jann Horn Date: Tue, 15 Jun 2021 04:36:34 +0200 Message-ID: Subject: Re: [PATCH v2] mm/gup: fix try_grab_compound_head() race with split_huge_page() To: Andrew Morton Cc: Linux-MM , kernel list , Matthew Wilcox , "Kirill A . Shutemov" , John Hubbard , Jan Kara , stable , Michal Hocko Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Jun 15, 2021 at 4:00 AM Andrew Morton wrote: > On Tue, 15 Jun 2021 03:20:14 +0200 Jann Horn wrote: > > --- a/mm/gup.c > > +++ b/mm/gup.c > > @@ -43,8 +43,25 @@ static void hpage_pincount_sub(struct page *page, int refs) > > > > atomic_sub(refs, compound_pincount_ptr(page)); > > } > > > > +/* Equivalent to calling put_page() @refs times. */ > > +static void put_page_refs(struct page *page, int refs) > > +{ > > +#ifdef CONFIG_DEBUG_VM > > + if (VM_WARN_ON_ONCE_PAGE(page_ref_count(page) < refs, page)) > > + return; > > +#endif > > Well dang those ifdefs. > > With CONFIG_DEBUG_VM=n, this expands to > > if (((void)(sizeof((__force long)(page_ref_count(page) < refs)))) > return; > > which will fail with "void value not ignored as it ought to be". > Because VM_WARN_ON_ONCE_PAGE() is an rval with CONFIG_DEBUG_VM=y and is > not an rval with CONFIG_DEBUG_VM=n. So the ifdefs are needed. > > I know we've been around this loop before, but it still sucks! Someone > please remind me of the reasoning? > > Can we do > > #define VM_WARN_ON_ONCE_PAGE(cond, page) { > BUILD_BUG_ON_INVALID(cond); > cond; > } > > ? See also . I see basically two issues with your proposal: 1. Even if you use it without "if (...)", the compiler has to generate code to evaluate the condition unless it can prove that the condition has no side effects. (It can't prove that for stuff like atomic_read() or READ_ONCE(), because those are volatile loads and C says you can't eliminate those. There are compiler builtins that are more fine-grained, but the kernel doesn't use those.) 2. The current version generates no code at all for !DEBUG_VM builds. Your proposal would still have the conditional bailout even in !DEBUG_VM builds - and if the compiler already has to evaluate the condition and generate a conditional branch, I don't know whether there is much of a point in omitting the code that prints a warning under !DEBUG_VM (although I guess it could impact register spilling and assignment). If you don't like the ifdeffery in this patch, can you please merge the v1 patch? It's not like I was adding a new BUG_ON(), I was just refactoring an existing BUG_ON() into a helper function, so I wasn't making things worse; and I don't want to think about how to best design WARN/BUG macros for the VM subsystem in order to land this bugfix. (Also, this patch is intended for stable-backporting, so mixing in more changes unrelated to the issue being fixed might make backporting more annoying. This v2 patch will already require more fixup than the v1 one, because VM_WARN_ON_ONCE_PAGE() was only added recently.)