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 D6C3DC7EE23 for ; Wed, 24 May 2023 00:53:06 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 006F5900005; Tue, 23 May 2023 20:53:06 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id EF960900002; Tue, 23 May 2023 20:53:05 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id D99AD900005; Tue, 23 May 2023 20:53:05 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0015.hostedemail.com [216.40.44.15]) by kanga.kvack.org (Postfix) with ESMTP id C663E900002 for ; Tue, 23 May 2023 20:53:05 -0400 (EDT) Received: from smtpin03.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay03.hostedemail.com (Postfix) with ESMTP id 819D9A0819 for ; Wed, 24 May 2023 00:53:05 +0000 (UTC) X-FDA: 80823324330.03.3FBD539 Received: from mail-pl1-f180.google.com (mail-pl1-f180.google.com [209.85.214.180]) by imf22.hostedemail.com (Postfix) with ESMTP id B1FE6C0014 for ; Wed, 24 May 2023 00:53:03 +0000 (UTC) Authentication-Results: imf22.hostedemail.com; dkim=pass header.d=google.com header.s=20221208 header.b=DSSILEKw; spf=pass (imf22.hostedemail.com: domain of rientjes@google.com designates 209.85.214.180 as permitted sender) smtp.mailfrom=rientjes@google.com; dmarc=pass (policy=reject) header.from=google.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1684889583; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=R73rQupbGo8gxIgqNUbzX7tFkfS3FdlbSDCX+v9GPFU=; b=edp7tzIybmJQ9G/xqc0rj6DSgKlxvjvVmXl7hBz8viJZaKjgfapyOSiZ+OStVERC0vWu6T fBhjXPuJ9WYG8JkgEqOxNrcl/RLbaPkcYuInMcNu3C70pAAoOWxdSUUNvsjb93q/m3kxTa q8fkSxxDFamFnCHFhnU3AcN2Imn2kBs= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1684889583; a=rsa-sha256; cv=none; b=7gibpJKswICHfIjc86cenZ09H2uhOObXs4cZ02t9XhTBsnOmK3RTgbhjb1gRXong+0Mj/f D9V3FWBXmcq1UCYBbFLZ+tR52VQ2Fy2hbjBmSvoLLrZQ7fXULtohy8OkfVoik/lruYlAjN nNrZmoKrN6R6rFt2Ii6vGE4NIBlQAos= ARC-Authentication-Results: i=1; imf22.hostedemail.com; dkim=pass header.d=google.com header.s=20221208 header.b=DSSILEKw; spf=pass (imf22.hostedemail.com: domain of rientjes@google.com designates 209.85.214.180 as permitted sender) smtp.mailfrom=rientjes@google.com; dmarc=pass (policy=reject) header.from=google.com Received: by mail-pl1-f180.google.com with SMTP id d9443c01a7336-1ae3f74c98bso8695ad.1 for ; Tue, 23 May 2023 17:53:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20221208; t=1684889582; x=1687481582; h=mime-version:references:message-id:in-reply-to:subject:cc:to:from :date:from:to:cc:subject:date:message-id:reply-to; bh=R73rQupbGo8gxIgqNUbzX7tFkfS3FdlbSDCX+v9GPFU=; b=DSSILEKw2P3DdNCdeOp5B3aoyrmq0ppDsVUFp5fFDhGbt7ZxTpi0cCUJuiVGww+So5 Vu6jPfkMFhdAoLq5xrc2DEVBGTvy/WT+LQQ5aUEmVfdthzYNZUL4/5lMUPHwZkZ2959Q AWN0hu4WIaCF6Lb/FI0NjFr6kjVnCDjGBOXdnCClavOxu0u06cRn8NmUvf4nCSrApzVI 5ixgebMSLc6ewH9vw5dOVhRVUp2q1EVXFEur32rfm5RHyrQHXTh3tGMM96WaiLoExUX1 +FXHnum3I4dnd5eKabCsTMxQOtqT1UVnzEt4kp6CRDoInHkbUCJ6S7DQ2GsMm+N1x/vu Vbeg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1684889582; x=1687481582; h=mime-version:references:message-id:in-reply-to:subject:cc:to:from :date:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=R73rQupbGo8gxIgqNUbzX7tFkfS3FdlbSDCX+v9GPFU=; b=OrJAPbUADeaL7QRqI9S3GDDZQL0hJEOejbXRnRshFL4O+kpSSyKiVm7xSKRgx4DpkX oXk8+i4ACOVasWb25aO8q4TlVcBiGk49noE7g5hPA1VYlYRWREoHyaMVQZ83RAWT4PcS QY7lB3AP+ShF84ldh2HBLzMaKQ8h1dVy7401zryK28mz11j+0gIbSldNA/d0ZxU+zZ1s khYnI7fCPHNnUmsBnBlJaC3quiBJaUXeLcgg+Sgvb2Sx15Y5yjkzVIkWnOKkaS5M3K2B vVWCOjp8Q2RLBnRqNyD3JfrAvAcbMpN1RdPfI1Hny6zd3pvf8dPicI120P1KUzkDV74K asHg== X-Gm-Message-State: AC+VfDxugTSUvV1GMNOpDHV9zK7AlT7fbGJCLhxn5vDWuYCh3sczJzXG 8quwVGc3GZoBsfPqkQzhIJ5DLQ== X-Google-Smtp-Source: ACHHUZ6I8qmYZZpMAWacH6DVYzOZb4ptlZVkc9+WNlpK45yZCweyu1ykaPvSNL11GDYOfC6N/jYtbQ== X-Received: by 2002:a17:902:d4c2:b0:1aa:ea22:8043 with SMTP id o2-20020a170902d4c200b001aaea228043mr42900plg.7.1684889582328; Tue, 23 May 2023 17:53:02 -0700 (PDT) Received: from [2620:0:1008:11:c789:c1fb:6667:1766] ([2620:0:1008:11:c789:c1fb:6667:1766]) by smtp.gmail.com with ESMTPSA id 19-20020aa79213000000b00639eae8816asm6282579pfo.130.2023.05.23.17.53.01 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 23 May 2023 17:53:01 -0700 (PDT) Date: Tue, 23 May 2023 17:53:00 -0700 (PDT) From: David Rientjes To: Linus Torvalds cc: David Hildenbrand , Andrew Morton , Michal Hocko , Alex Shi , Johannes Weiner , Matthew Wilcox , Alexander Duyck , linux-kernel@vger.kernel.org, linux-mm@kvack.org Subject: Re: [patch] mm, debug: allow suppressing panic on CONFIG_DEBUG_VM checks In-Reply-To: Message-ID: <494440e9-b73f-2445-5b1f-0e4d2ab5f487@google.com> References: <53dd9df8-e88f-f466-89f9-3fa141a10267@google.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="2003089352-194657390-1684889581=:163077" X-Rspamd-Queue-Id: B1FE6C0014 X-Rspam-User: X-Stat-Signature: khsp1uwj63dbpd7exy4h5j3rs8j7k85u X-Rspamd-Server: rspam03 X-HE-Tag: 1684889583-930333 X-HE-Meta: U2FsdGVkX1+CZSMtSiH0zr3EW+7BU3i1MJ2s4ju/C82RkLqi4J4ap4qxaCWZsl+zpRNEhoDhDCU5uZHYkcjY01LZIn8UK0WiCrqe1TtKs5uRlTva1nEq1FpVcCEKqPtjufUXsX0fcMfTpOhYAl2WBd2qJC7rxpJlyYAhaeUuLWtzRmIb5SgdKnFhLX4pJJnvQ7R4bfGilM+7GNZQlEKdho2g46SmXoypBsjSbjEoxsWSCBfTcOm2C5i6qlzSKBylEoEGU4Jq+N5qhtTEMqNtCJ223vKrPQr79GfvTcSlq2hRIVyg5p41yu/UqH6RInZBznm5qbX+TsD6mJYG3oPwx5a+dF+1MDHggAJfYJcOlYwQZfS/Sgi5sNc/0j/ZG8oAC2gVK6x9u1AsiGo5PPYmJjb4ARAErNkiHpp35UZE2FbMUEBTQ/cdQkdddcbjWvpH+2vfNOfaUCFxUsT85I6wGosAjIKE0r9xzBsZ9VDSu4cCefQOZJ5UGzSj902rTQUCHV+YyG/hHwVXi6aNDoN1Hn4VANc2tWv5pg1ZylL+YLJQ0J4IVgF4Ag5TRgyVDb4gOcF9UqXly1lwLj5UbhLrmQBhaLFsf3qLiwp/KnOKi2xxyQ8rmA71+h/97Ku8vXW59CH+k6ChpdgeXq6VkmCpmmrkbmJpgOu/cW42DC6/6HAE3CpHUoGS35zSlZhzKjrL7oq5nBkWEMQLPevzdrBXKA9ndOCrOu+Ptt6EW/vHb7OHWeyZdZO+9PsJetIveQXJQyS/4GWf6cbYIbw2EWBNEUgDAK5eAmo4VObD4teKrWWZsAYtiHry5kH0cbPE1Gmg/q88BQnMmfc/wUIHaKmTmkfjhv/49hxAMr7uJrMjbqPt9WrGL/7TTBOvC7eynqUM0zbSjCgjSM8wC5KOcDRiULGTH+z+b5q9TgA9F205SdzlJVViDTjGJoeETthHaT5R9oAL5/Uxc0J4xfhzAPU XI0L7hZm 6jHBw7czgMlBJzoTkgSxkBpNzjZvET/nJ1nqZ/L8MODHqzaqe5xqA7eZUMxqtB8R9Ko6gU4lNQtNBf/tDzT6eZEQoJ/PRyEH7CkdT60zB3Sm1T2tEo7papDJYs1ffKBLjOlZuVVaEsg4/9HhoU4DO3wTFKAZEJ+QYIcR5wNsbGlX4bCYrD8JUpcACiODfB+5Ln00rEO0Ag4BrNNJp4daMwXGKgdDkagwC9g52VJC3Cw8n7hRB74LX+VlyZ9N2IC1cvVYF1Zo+5LxclZ/s2EdOus2HwWnCm5oSHMpxHR4ryUSpX6nWhhDM/C7wHpBkRAU4Mvy8Y/qZjqDj8XRIopSmQRWo4ehobXy1zby15fOskbKsSDgh0rROeTYuRfU9zr2W52VkA4f0dxGxvo7rGzs2cglZTPc/JN/LqWpA1gWd9sYBtLiEE3a8PRv0kvghGBkeWv6X8Ss4YyQi0IMSMA61cxrR45zRm+tcuGj6NV5UvhdqOmzHhgzuYewGKMxfW9Ize4KKvabK4pYcDr8= 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: This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --2003089352-194657390-1684889581=:163077 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8BIT On Mon, 22 May 2023, Linus Torvalds wrote: > On Mon, May 22, 2023 at 5:52 PM David Rientjes wrote: > > > > Right now kernel.panic_on_warn can either be 0 or 1. We can keep the > > lowest bit to be "panic on all warnings" and then bit-1 as "panic on debug > > VM warnings." When CONFIG_DEBUG_VM is enabled, set the new bit by > > default so there's no behavior change. > > So right now CONFIG_DEBUG_VM being off means that there's nothing at > all - not just no output, but also no code generation. > > I don't think CONFIG_DEBUG_VM in itself should enable that bit-1 behavior. > > That may be what *you* as a VM person wants, but VM people are not > exactly the common case. > > So I think we've got several cases: > > (a) the "don't even build it" case (CONFIG_DEBUG_VM being off) > > (b) the "build it, and it is a WARN_ON_ONCE()" case > > (c) the *normal* "panic_on_warn=1" case, which by default would panic > on all warnings, including any warnings from CONFIG_DEBUG_VM > > (d) the "VM person" case, which might not panic on normal warnings, > but would panic on the VM warnings. > > and I think the use-cases are for different classes of kernel use: > > (a) is for people who disable debugging code until they feel it is > needed (which I think covers a lot of kernel developers - I certainly > personally tend to not build with debug support unless I'm chasing > some issue down) > > (b) would probably be most distros - enable the warning so that the > distro can report it, but try not to kill the machine of random people > > (c) would be most cloud use cases, presumably together with reboot-on-panic > > (d) would be people who are actual VM developers, and basically want > the *current* behavior of VM_BUG_ON() with a machine that stops > > and I think (d) is the smallest set of cases of all, but is the one > you're personally interested in. > If we want to change the behavior from today toward something that we think is the more common case for enabling CONFIG_DEBUG_VM, that works too. If we fully remove VM_BUG_ON() in favor of VM_WARN_ON() + kernel.panic_on_warn=1, then anybody relying on getting kernel panics when they qualify new kernels with CONFIG_DEBUG_VM will start getting WARNINGs but not panics unless they are already using kernel.panic_on_warn. I think that's fine, but is a change in behavior. My use cases work both ways. If we don't set the bit-1 behavior by default on CONFIG_DEBUG_VM then I just won't need to clear it. I'm personally interested in (d) for debugging issues, but the intent of this patch was actually to allow for (b) too. I want to deploy CONFIG_DEBUG_VM with WARN_ON_ONCE() behavior to a small set of production machines to catch latent kernel issues we don't know about, but without impacting the workloads. That's also very valuable because I want to surface CONFIG_DEBUG_VM checks that would never get hit because we panic before it can be, just because of some other VM_BUG_ON(). Your idea of WARN_ON_ONCE() will be great for that because we can make forward progress and not be too spammy to the kernel log. There seems to be some agreement in the thread for removing VM_BUG_ON() and friends in favor of VM_WARN_ON(), so I'll wait a couple days for anymore feedback and then send a patch along. This seems like it will be very clean and allow for (b), which is great. --2003089352-194657390-1684889581=:163077--