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 mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id B6990C433FE for ; Tue, 26 Oct 2021 18:22:33 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 31A2960F9D for ; Tue, 26 Oct 2021 18:22:33 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org 31A2960F9D Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=soleen.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=kvack.org Received: by kanga.kvack.org (Postfix) id 90BB680007; Tue, 26 Oct 2021 14:22:32 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 8BA16940007; Tue, 26 Oct 2021 14:22:32 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 7A8C280007; Tue, 26 Oct 2021 14:22:32 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0174.hostedemail.com [216.40.44.174]) by kanga.kvack.org (Postfix) with ESMTP id 6CE93940007 for ; Tue, 26 Oct 2021 14:22:32 -0400 (EDT) Received: from smtpin18.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay03.hostedemail.com (Postfix) with ESMTP id 15C458249980 for ; Tue, 26 Oct 2021 18:22:32 +0000 (UTC) X-FDA: 78739408944.18.0DEBF27 Received: from mail-lj1-f181.google.com (mail-lj1-f181.google.com [209.85.208.181]) by imf23.hostedemail.com (Postfix) with ESMTP id F21D99000387 for ; Tue, 26 Oct 2021 18:22:23 +0000 (UTC) Received: by mail-lj1-f181.google.com with SMTP id 205so300722ljf.9 for ; Tue, 26 Oct 2021 11:22:31 -0700 (PDT) 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=65K7xPMB5++D+E7Bfsj7avhsV6qayGu5o858lBV5Elw=; b=UFCHSPeXcQuOwM5lLBzpQb7MmItFB4AO1roGO3y4q5yr/hBmA5lT1VpaEAmhdJ8z/+ VYkqEAMbuPAv1Cp8LsRycDDHtNvQeQFx8ipOaDHKl6uW/BQM+UY8gkxeKK1rD6gGr5b5 UAPtkFa0BJoq6WvAzcEI5zbTFwjaDAQ8x976/sWxF14aJK3ZMtLOU5YZnYmTm2KtHcma 4yfclS5UycC8vhPriGnuQqwzjvOB6HwPARWPA5QDSSGLIZFoGvvzuROAIiV0JbwyFpH2 9ePnPpndZLepd6EXRifaI8NVaGxubCB3QnHbqqrjvdu4maqR49+vJ1T4iBJe7KGvwG0v ZgHw== 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=65K7xPMB5++D+E7Bfsj7avhsV6qayGu5o858lBV5Elw=; b=vIxSksCgnoIj+9/ZApIv8Y1OcveyoE67EmN5UQfyAvDcZnjLfQN5u6wejVwJlnTRh+ crDX2SufPPqM3OPvr2Hh1XZHZjh7JOW8vnOvte/PB+q3nofkorELIAmWjG5y59YsYkv1 yKy08ytbY+sBcZ7ikYx4Znjp/88q/brrofZEqFPQpC9UCT/23lm0OKQvakIu5/HXhYRg sdlMbf2tlvFeMzH7JbtHuzZAyputBAlUUUfIhwsp1Sajx9v3ZtinJLGfI0xAUz36gdLk MU8tyo7T4iJB1UaCR5uf7/mesDuWCI+uGoMjK5oPm29OsYnyPCkk46jRrIjUx6QS82uy BEBA== X-Gm-Message-State: AOAM532Fpiev/YtGlaEu6gnngBl2IP3ylxC4cbo/pWnTxyi4cDZ1KB5C shidYTIlhQe35yAcArblbAjrbTfqO8upeXLrKSX8LQ== X-Google-Smtp-Source: ABdhPJx2JuH49fJWhpgoI/t0B9ikgzBgjsyHaYVav9e1A/WZ3jrkA/+aZNOAoOH5hm2JJV0+jzgrKdz/brNyOdRDdIo= X-Received: by 2002:a2e:b794:: with SMTP id n20mr149553ljo.313.1635272550203; Tue, 26 Oct 2021 11:22:30 -0700 (PDT) MIME-Version: 1.0 References: <20211026173822.502506-1-pasha.tatashin@soleen.com> <20211026173822.502506-4-pasha.tatashin@soleen.com> <7b131cb1-68d8-6746-f9c1-2b01d4838869@nvidia.com> In-Reply-To: <7b131cb1-68d8-6746-f9c1-2b01d4838869@nvidia.com> From: Pasha Tatashin Date: Tue, 26 Oct 2021 14:21:53 -0400 Message-ID: Subject: Re: [RFC 3/8] mm: Avoid using set_page_count() in set_page_recounted() To: John Hubbard Cc: LKML , linux-mm , linux-m68k@lists.linux-m68k.org, Anshuman Khandual , Matthew Wilcox , Andrew Morton , william.kucharski@oracle.com, Mike Kravetz , Vlastimil Babka , Geert Uytterhoeven , schmitzmic@gmail.com, Steven Rostedt , Ingo Molnar , Johannes Weiner , Roman Gushchin , songmuchun@bytedance.com, weixugc@google.com, Greg Thelen Content-Type: text/plain; charset="UTF-8" X-Rspamd-Server: rspam05 X-Rspamd-Queue-Id: F21D99000387 X-Stat-Signature: e8bw5h1n5xxgqygu7ny557zotmb1ytc1 Authentication-Results: imf23.hostedemail.com; dkim=pass header.d=soleen.com header.s=google header.b=UFCHSPeX; spf=pass (imf23.hostedemail.com: domain of pasha.tatashin@soleen.com designates 209.85.208.181 as permitted sender) smtp.mailfrom=pasha.tatashin@soleen.com; dmarc=none X-HE-Tag: 1635272543-586934 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: Hi John, Thank you for looking at this series. > > static inline void set_page_refcounted(struct page *page) > > { > > + int refcnt; > > + > > VM_BUG_ON_PAGE(PageTail(page), page); > > VM_BUG_ON_PAGE(page_ref_count(page), page); > > - set_page_count(page, 1); > > + refcnt = page_ref_inc_return(page); > > + VM_BUG_ON_PAGE(refcnt != 1, page); > I am acutely uncomfortable with this change, because it changes the > meaning and behavior of the function to something completely different, > while leaving the function name unchanged. Furthermore, in relies upon > debug assertions, rather than a return value (for example) to verify > that all is well. It must return the same thing, if it does not we have a bug in our kernel which may lead to memory corruptions and security holes. So today we have this: VM_BUG_ON_PAGE(page_ref_count(page), page); -> check ref_count is 0 < What if something modified here? Hmm..> set_page_count(page, 1); -> Yet we reset it to 1. With my proposed change: VM_BUG_ON_PAGE(page_ref_count(page), page); -> check ref_count is 0 refcnt = page_ref_inc_return(page); -> ref_count better be 1. VM_BUG_ON_PAGE(refcnt != 1, page); -> Verify that it is 1. > > I understand where this patchset is going, but this intermediate step is > not a good move. > > Also, for the overall series, if you want to change from > "set_page_count()" to "inc_and_verify_val_equals_one()", then the way to > do that is *not* to depend solely on VM_BUG*() to verify. Instead, > return something like -EBUSY if incrementing the value results in a > surprise, and let the caller decide how to handle it. Actually, -EBUSY would be OK if the problems were because we failed to modify refcount for some reason, but if we modified refcount and got an unexpected value (i.e underflow/overflow) we better report it right away instead of waiting for memory corruption to happen. Thanks, Pasha