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 A5181C433EF for ; Thu, 3 Mar 2022 09:31:08 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 2AC328D0002; Thu, 3 Mar 2022 04:31:08 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 2330A8D0001; Thu, 3 Mar 2022 04:31:08 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 0FB058D0002; Thu, 3 Mar 2022 04:31:08 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (relay.hostedemail.com [64.99.140.25]) by kanga.kvack.org (Postfix) with ESMTP id 003C48D0001 for ; Thu, 3 Mar 2022 04:31:07 -0500 (EST) Received: from smtpin09.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay13.hostedemail.com (Postfix) with ESMTP id CBABE6177F for ; Thu, 3 Mar 2022 09:31:07 +0000 (UTC) X-FDA: 79202556174.09.242CD8C Received: from mail-yb1-f172.google.com (mail-yb1-f172.google.com [209.85.219.172]) by imf22.hostedemail.com (Postfix) with ESMTP id 3D3AEC0009 for ; Thu, 3 Mar 2022 09:31:06 +0000 (UTC) Received: by mail-yb1-f172.google.com with SMTP id j2so9056330ybu.0 for ; Thu, 03 Mar 2022 01:31:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=w3iW8OgIGRJkwzf0fEpKvBUUqPlzMNEZGmdG3QGabg4=; b=URDf26+dNOI4zWZjXx4GWjlI4pZuP/MYcrhtyADZ9dTEPdKCNsoxBXS5WkZdP4DtgO +j0t5agvsO1Oe7MkM26noei61tmQvfeOR2A+2DUmd0muSEGvolKTFhtL/VFr0391jA6m jniyMZM4rk35SblfZTv3DtZY4fucvqIGl6+fYr11J2Nq7FJSiaM5vlkWeADBj2EWGDb1 2ryEBwyA0qd5YUyDon7mzlhJMLO+FhBOWrsHZj+c+c1/Atgpf3LIbRfitjyZMXna2iHc sqbMSWQF0hg48zetjwTaHtTWlPaXDnhL90D2nDuJNJwy/FWqFYwQstftKDud11EaAITb qC7Q== 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=w3iW8OgIGRJkwzf0fEpKvBUUqPlzMNEZGmdG3QGabg4=; b=2IWBOJqoTHPSu7gnsn2B0nftq2c5KdmU8jpIDxa4Tt8fx3bum614bgPTaSTvZQhUSv 89xCPwQFiMoRUf44fhjnIEd3gJPsjpc9C4IBGtExpZzRnhOzcQPosIBXjGewthKcrsLo eJTwenOjvl02+kZ8RqBhQFHEhBkE84u2DnnCAxktX2AvLHvohHttX9Jv9JZxvq/HO9xF 0cJ5Q0HYbNdDVOza9v0q6YpI02sE0IXNFHa2vFTMP3EWrrUY6Njazoar+KzfltNl00XI qm9UwTn6Aatq6JL3omu7vY1O0BQZVyy8FbDZt3q84GaRRhX2IIvEU7SOg+SWZzWp06nb Rb1w== X-Gm-Message-State: AOAM533OFpTCOHVDJegHRhtNiiMqtsb/wLNIjHXr6YGuviMzxLDwq7pJ MpZNgT7fWG5G2pa9kNQirZqGf51cZUFUParK4bNVow== X-Google-Smtp-Source: ABdhPJwydE0RMxCm9gwQXxiITojXHEgR91W45yVq0qi5hlhxGLYhhtzcXuK/rGpMLDEJtYwE/kYLODI0InSLgkv5plY= X-Received: by 2002:a25:a4e8:0:b0:61e:1eb6:19bd with SMTP id g95-20020a25a4e8000000b0061e1eb619bdmr34271771ybi.168.1646299866132; Thu, 03 Mar 2022 01:31:06 -0800 (PST) MIME-Version: 1.0 References: <20220303031505.28495-1-dtcccc@linux.alibaba.com> In-Reply-To: From: Marco Elver Date: Thu, 3 Mar 2022 10:30:30 +0100 Message-ID: Subject: Re: [RFC PATCH 0/2] Alloc kfence_pool after system startup To: Alexander Potapenko Cc: Tianchen Ding , Dmitry Vyukov , Andrew Morton , kasan-dev , Linux Memory Management List , LKML Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: 3D3AEC0009 X-Stat-Signature: ifd3s6wgac8omix4g3in7ge9fpok3dke X-Rspam-User: Authentication-Results: imf22.hostedemail.com; dkim=pass header.d=google.com header.s=20210112 header.b=URDf26+d; spf=pass (imf22.hostedemail.com: domain of elver@google.com designates 209.85.219.172 as permitted sender) smtp.mailfrom=elver@google.com; dmarc=pass (policy=reject) header.from=google.com X-Rspamd-Server: rspam07 X-HE-Tag: 1646299866-757474 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 Thu, 3 Mar 2022 at 10:05, Alexander Potapenko wrote: I share Alex's concerns. > On Thu, Mar 3, 2022 at 4:15 AM Tianchen Ding wrote: >> >> KFENCE aims at production environments, but it does not allow enabling >> after system startup because kfence_pool only alloc pages from memblock. >> Consider the following production scene: >> At first, for performance considerations, production machines do not >> enable KFENCE. > > What are the performance considerations you have in mind? Are you running KFENCE with a very aggressive sampling rate? Indeed, what is wrong with simply starting up KFENCE with a sample interval of 10000? However, I very much doubt that you'll notice any performance issues above 500ms. Do let us know what performance issues you have seen. It may be related to an earlier version of KFENCE but has since been fixed (see log). >> However, after running for a while, the kernel is suspected to have >> memory errors. (e.g., a sibling machine crashed.) > > I have doubts regarding this setup. It might be faster (although one can tune KFENCE to have nearly zero performance impact), but is harder to maintain. > It will also catch fewer errors than if you just had KFENCE on from the very beginning: > - sibling machines may behave differently, and a certain bug may only occur once - in that case the secondary instances won't notice it, even with KFENCE; > - KFENCE also catches non-lethal corruptions (e.g. OOB reads), which may stay under radar for a very long time. > >> >> So other production machines need to enable KFENCE, but it's hard for >> them to reboot. >> >> The 1st patch allows re-enabling KFENCE if the pool is already >> allocated from memblock. Patch 1/2 might be ok by itself, but I still don't see the point because you should just leave KFENCE enabled. There should be no reason to have to turn it off. If anything, you can increase the sample interval to something very large if needed.