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 E21A1C433EF for ; Thu, 27 Jan 2022 19:42:49 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 4728C6B0071; Thu, 27 Jan 2022 14:42:49 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 422276B0072; Thu, 27 Jan 2022 14:42:49 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 2E9826B0073; Thu, 27 Jan 2022 14:42:49 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0106.hostedemail.com [216.40.44.106]) by kanga.kvack.org (Postfix) with ESMTP id 203C56B0071 for ; Thu, 27 Jan 2022 14:42:49 -0500 (EST) Received: from smtpin24.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay02.hostedemail.com (Postfix) with ESMTP id D7A9E82766 for ; Thu, 27 Jan 2022 19:42:48 +0000 (UTC) X-FDA: 79077089616.24.0FCF89D Received: from mail-ej1-f49.google.com (mail-ej1-f49.google.com [209.85.218.49]) by imf17.hostedemail.com (Postfix) with ESMTP id CB5D440004 for ; Thu, 27 Jan 2022 19:42:47 +0000 (UTC) Received: by mail-ej1-f49.google.com with SMTP id j2so8239467ejk.6 for ; Thu, 27 Jan 2022 11:42:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=soleen.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=SlWIcHy/3XR7mwnK/GHpmwHwVvr/nhApahfqBZocrNU=; b=YqCrznekqjJGqxJTiBCV9J98MH4sLOY2AlzJgugPm5/1S+vb4pcJxV9Zwm2mcVL5sq yOPmh7MmaQfsM0y7I43NHEJJesuDa7jaPzANYVQYPXe/kubBYmv+/msm7zagHrutr6QN L7Wk9Blrv1JS4QjFiEsYcfIxdd0N+UgCW6sZnnqKNn/vsbb5p9+SNSzu+Udg2f4pR2e3 4S5keBjy2zohERuHuVzADnODSIZMZiT7cky9vprdIm74ZstoTdru90283pSzQttQs+Ei b8XtsBlGpgPnU5l+YQK4dP3TUw8HDrLnTPZfGGDMvRpNvYln48idGU1LpLbjXwhw5/5R u9dA== 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=SlWIcHy/3XR7mwnK/GHpmwHwVvr/nhApahfqBZocrNU=; b=gLmxeJnw1vq0Vw7ofpTkhSv44Cni86wi4uEKBb58ykIISaDih5ftIXE9fGbnP7j7Qo SdAHp8PggTh2DKPOQ+54nD2HSQMDOCz/YA2RP+G18Ari4TIgSzOW+Ikxni5/Oy+1FYje YIDU28aCRU1NdFEzghLOJViY5MV14DR3l6V6VCUuGAE/XoDYFd2RTXW+bnEg//G9g0cf MLhmlSVx52ZJn2om6q4l+uuezFiqBS0bGgHiylfkh22hd8ska8nywUuGTXOVVt9TEB4f Nnfs7maY8uSBAxp6qPmkGTnroNK8bAdWLcxOPUi6L0NY3fuUvkWjviNfMAybDOc4sFsK nnyQ== X-Gm-Message-State: AOAM532acbrE22E2EnARtYiHyqIpCodU6U4nFoAkzdIKhusB+ZlhWQ0j RPQ8LWlCMuQnab2gVfpWrXROIIzPjm2MWaz4RdETQg== X-Google-Smtp-Source: ABdhPJyRYphRCJufijT8nLWfSafgBSzq7ruAzTjmpKHgO1/ZkxNEN0MqTxVHWccur1KVci8YLBBrAKSYGIwvmUfOKJE= X-Received: by 2002:a17:907:2d92:: with SMTP id gt18mr3911682ejc.579.1643312566461; Thu, 27 Jan 2022 11:42:46 -0800 (PST) MIME-Version: 1.0 References: <20220126183429.1840447-1-pasha.tatashin@soleen.com> <20220126183429.1840447-2-pasha.tatashin@soleen.com> <72cae3c0-e06e-4fe5-24d5-a2c94d99780f@suse.cz> In-Reply-To: <72cae3c0-e06e-4fe5-24d5-a2c94d99780f@suse.cz> From: Pasha Tatashin Date: Thu, 27 Jan 2022 14:42:09 -0500 Message-ID: Subject: Re: [PATCH v3 1/9] mm: add overflow and underflow checks for page->_refcount To: Vlastimil Babka Cc: LKML , linux-mm , linux-m68k@lists.linux-m68k.org, Anshuman Khandual , Matthew Wilcox , Andrew Morton , william.kucharski@oracle.com, Mike Kravetz , Geert Uytterhoeven , schmitzmic@gmail.com, Steven Rostedt , Ingo Molnar , Johannes Weiner , Roman Gushchin , Muchun Song , Wei Xu , Greg Thelen , David Rientjes , Paul Turner , Hugh Dickins Content-Type: text/plain; charset="UTF-8" X-Rspamd-Server: rspam06 X-Rspamd-Queue-Id: CB5D440004 X-Stat-Signature: rk1e3irqgmieujwikqc7mw9k4fzgpc45 Authentication-Results: imf17.hostedemail.com; dkim=pass header.d=soleen.com header.s=google header.b=YqCrznek; dmarc=none; spf=pass (imf17.hostedemail.com: domain of pasha.tatashin@soleen.com designates 209.85.218.49 as permitted sender) smtp.mailfrom=pasha.tatashin@soleen.com X-Rspam-User: nil X-HE-Tag: 1643312567-438506 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: > > diff --git a/include/linux/page_ref.h b/include/linux/page_ref.h > > index 2e677e6ad09f..fe4864f7f69c 100644 > > --- a/include/linux/page_ref.h > > +++ b/include/linux/page_ref.h > > @@ -117,7 +117,10 @@ static inline void init_page_count(struct page *page) > > > > static inline void page_ref_add(struct page *page, int nr) > > { > > - atomic_add(nr, &page->_refcount); > > + int old_val = atomic_fetch_add(nr, &page->_refcount); > > + int new_val = old_val + nr; > > + > > + VM_BUG_ON_PAGE((unsigned int)new_val < (unsigned int)old_val, page); > > This seems somewhat weird, as it will trigger not just on overflow, but also > if nr is negative. Which I think is valid usage, even though the function > has 'add' in name, because 'nr' is signed? I have not found any places in the mainline kernel where nr is negative in page_ref_add(). I think, by adding this assert we ensure that when 'add' shows up in backtraces it can be assured that the ref count has increased, and if page_ref_sub() showed up it means it decreased. It is strange to have both functions, and yet allow them to do the opposite. We can also change the type to unsigned. Pasha