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 2B629C433F5 for ; Thu, 9 Dec 2021 01:24:25 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 6D66E6B0071; Wed, 8 Dec 2021 20:24:14 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 6867C6B0073; Wed, 8 Dec 2021 20:24:14 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 527356B0074; Wed, 8 Dec 2021 20:24:14 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0240.hostedemail.com [216.40.44.240]) by kanga.kvack.org (Postfix) with ESMTP id 42A936B0071 for ; Wed, 8 Dec 2021 20:24:14 -0500 (EST) Received: from smtpin05.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay02.hostedemail.com (Postfix) with ESMTP id 1370089D5C for ; Thu, 9 Dec 2021 01:24:04 +0000 (UTC) X-FDA: 78896509608.05.170D47F Received: from mail-ed1-f50.google.com (mail-ed1-f50.google.com [209.85.208.50]) by imf03.hostedemail.com (Postfix) with ESMTP id 5129020002 for ; Thu, 9 Dec 2021 01:24:03 +0000 (UTC) Received: by mail-ed1-f50.google.com with SMTP id t5so14612664edd.0 for ; Wed, 08 Dec 2021 17:24:03 -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=djkd7kU0HKK9P5mJFWg35mLxaEd3Gn4ggjL+YYI2Fxg=; b=CdUQEtuDKMWi8LMopTU1N0gv5eoDqcN5kA9XghxcUH5sLhkkJBBRAbBMdyOKEV/ylv 5x4WBjP+lfP1qFdPvkL7Hrrw0DHKy4r/JoIrcdODrR0HRGzpPk+cKuq6g6KpXaS/Xt8n giXoxnG6YXHtLfXeNQhgpjXz8UhMZ4MIO+j64lptb20F+ed4FSeigpswpZNSl3ZpRoZb tivmE4apjrS/j782YmiikjiIf836Jm8RU26RN0fvQNvUUGM1o1HFUdOpCGoxnDHwBnxp jJJmYxfA0pcLB+elptbTQTb5bvCrRGQC6FOjXTs544NPN/4n0i2dwIct+K5kySTizYin Bo3w== 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=djkd7kU0HKK9P5mJFWg35mLxaEd3Gn4ggjL+YYI2Fxg=; b=VEManJNocrjJIacYCydFwnGknEV3G3SjqzQqE1lPbjVXyaP2xvFYcT+do1gBZYfKZb gsORcFHA3w/w5fNBVcs3VP/Y71rEh1li/TBZfstkYT8knRsWoT9kyqJk/d8M3FpZ0FTR kBlTkxvrE2Y+cF10Mm+tzU01Q9OgnavOKYawQYpEmA3nt7epg1zTrVpJcsnjJlnmsneH 5+mwLuI9Qj1pG7dlFbR4nTCKzlMDxKrMPFYWwovS2AJlsCeKSFPglIZ48MBIOgpb3z0N hPtuFSgUHixPaGGoJJyZRzTuoWKyxiMxtfyDAduznc6UMpFEOnchNLDhyST8OvufykzL 2mgA== X-Gm-Message-State: AOAM5324vWKnlsjqlFju/a4B2WpGQ9rnbFCfyFI/vXpgNpwq/1uRjZba rHADsSyCkEFB5J7hjTf2//tGjCmyoA+DPhaK+2dO9Q== X-Google-Smtp-Source: ABdhPJzSKZQOBcRJ8636EiVUcNbp0iqM5adP6qAINVTurdqH+v8qFVpv2I212KR9BQDiBuJREbJg4zul5yOj9bL1PXY= X-Received: by 2002:aa7:d34c:: with SMTP id m12mr24849425edr.269.1639013041984; Wed, 08 Dec 2021 17:24:01 -0800 (PST) MIME-Version: 1.0 References: <20211208203544.2297121-1-pasha.tatashin@soleen.com> In-Reply-To: From: Pasha Tatashin Date: Wed, 8 Dec 2021 20:23:24 -0500 Message-ID: Subject: Re: [PATCH 00/10] Hardening page _refcount To: Matthew Wilcox Cc: LKML , linux-mm , linux-m68k@lists.linux-m68k.org, Anshuman Khandual , Andrew Morton , william.kucharski@oracle.com, Mike Kravetz , Vlastimil Babka , Geert Uytterhoeven , schmitzmic@gmail.com, Steven Rostedt , Ingo Molnar , Johannes Weiner , Roman Gushchin , Muchun Song , weixugc@google.com, Greg Thelen , David Rientjes , Paul Turner Content-Type: text/plain; charset="UTF-8" X-Rspamd-Server: rspam07 X-Rspamd-Queue-Id: 5129020002 X-Stat-Signature: dqx8oszukeyy654nd991m6saxo4m9yaw Authentication-Results: imf03.hostedemail.com; dkim=pass header.d=soleen.com header.s=google header.b=CdUQEtuD; spf=pass (imf03.hostedemail.com: domain of pasha.tatashin@soleen.com designates 209.85.208.50 as permitted sender) smtp.mailfrom=pasha.tatashin@soleen.com; dmarc=none X-HE-Tag: 1639013043-866908 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 Wed, Dec 8, 2021 at 4:05 PM Matthew Wilcox wrote: > > On Wed, Dec 08, 2021 at 08:35:34PM +0000, Pasha Tatashin wrote: > > It is hard to root cause _refcount problems, because they usually > > manifest after the damage has occurred. Yet, they can lead to > > catastrophic failures such memory corruptions. There were a number > > of refcount related issues discovered recently [1], [2], [3]. > > > > Improve debugability by adding more checks that ensure that > > page->_refcount never turns negative (i.e. double free does not > > happen, or free after freeze etc). > > > > - Check for overflow and underflow right from the functions that > > modify _refcount > > - Remove set_page_count(), so we do not unconditionally overwrite > > _refcount with an unrestrained value > > - Trace return values in all functions that modify _refcount > Hi Matthew, Thank you for looking at this series. > You're doing a lot more atomic instructions with these patches. This is not exactly so. There are no *more* atomic instructions. There are, however, different atomic instructions: For example: atomic_add() becomes atomic_fetch_add() On x86 it is: atomic_add: lock add %eax,(%rsi) atomic_fetch_add: lock xadd %eax,(%rsi) On ARM64, I believe the same CAS instruction is used for both. Have you > done any performance measurements with these patches applied and debug > disabled? Yes, I have done some performance tests exactly as you described with CONFIG_DEBUG_VM disabled and these patches applied. I tried: hackbench, unixbench, and a few more benchmarks; I did not see any performance difference. > I'm really not convinced it's worth closing > one-instruction-wide races of this kind when they are "shouldn't ever > happen" situations. If the debugging will catch the problem in 99.99% > of cases and miss 0.01% without using atomic instructions, that seems > like a better set of tradeoffs than catching 100% of problems by using > the atomic instructions. I think we should relax the precise catching of bugs only if there is indeed a measurable performance impact. The problem is that if there is a __refcount bug, the security consequences are dire as it may lead to leaking memory from one process to another. Thanks, Pasha