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 C8252C77B75 for ; Tue, 23 May 2023 01:48:00 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 0FD08900002; Mon, 22 May 2023 21:48:00 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 0AC9C6B0075; Mon, 22 May 2023 21:48:00 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id EB710900002; Mon, 22 May 2023 21:47:59 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0011.hostedemail.com [216.40.44.11]) by kanga.kvack.org (Postfix) with ESMTP id D9E9A6B0074 for ; Mon, 22 May 2023 21:47:59 -0400 (EDT) Received: from smtpin04.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay03.hostedemail.com (Postfix) with ESMTP id A7605A05FB for ; Tue, 23 May 2023 01:47:59 +0000 (UTC) X-FDA: 80819833878.04.7545A2F Received: from mail-ed1-f47.google.com (mail-ed1-f47.google.com [209.85.208.47]) by imf10.hostedemail.com (Postfix) with ESMTP id 93AB1C0014 for ; Tue, 23 May 2023 01:47:57 +0000 (UTC) Authentication-Results: imf10.hostedemail.com; dkim=pass header.d=linux-foundation.org header.s=google header.b=ZJaxkpAs; dmarc=none; spf=pass (imf10.hostedemail.com: domain of torvalds@linuxfoundation.org designates 209.85.208.47 as permitted sender) smtp.mailfrom=torvalds@linuxfoundation.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1684806477; 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:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=oOGZYEghKs3nn4mexef6OEUtQ/86KDKLq99QlVJ/owA=; b=GfF46/zxx0GA/184cR3HhM7N1PXxIf3guedi5P3+8Lff+JQHRXYfJwfTwmQJgaRTJuSiGM ijfkYfUoph+p3HGJbwiRcXgahZQXms1oHufHEKhqYghNPMLeDNzwDk3dikLOslEI2a5WJj hGK3T85z6q/YCVSSZ0jI1sP8v+tIOD8= ARC-Authentication-Results: i=1; imf10.hostedemail.com; dkim=pass header.d=linux-foundation.org header.s=google header.b=ZJaxkpAs; dmarc=none; spf=pass (imf10.hostedemail.com: domain of torvalds@linuxfoundation.org designates 209.85.208.47 as permitted sender) smtp.mailfrom=torvalds@linuxfoundation.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1684806477; a=rsa-sha256; cv=none; b=Eb8+OVjVVZxbCbUcfrnqqemszWrUqtaVu62S6knnCJHfkt59+oWLRN15YnkLKn9Wox6Lgk UITVPxDZDGal31Kh1p34KWp3i6Gfzcf96in/mz+hPrNvnXsMMqIwtokSszn5rse//4hlT2 l6GlxEbhyvUvYf/t92WzD+//Xlmoqfg= Received: by mail-ed1-f47.google.com with SMTP id 4fb4d7f45d1cf-510dabb39aeso440599a12.2 for ; Mon, 22 May 2023 18:47:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux-foundation.org; s=google; t=1684806476; x=1687398476; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=oOGZYEghKs3nn4mexef6OEUtQ/86KDKLq99QlVJ/owA=; b=ZJaxkpAsmW2osgbozhA2kQz7mhYMPQ69oEqBCw3bFnsGfVq2QIkVEuINdNTL5UW2Zc YgR6DUSAMrP1Ncl5QZ3K1IxUbrNwOmY3C64uD0a16QbuFHRzdILQaUdDCHoEPHApFpX3 rdFkKRwgXCwHucwvwNiciuUh0VaUq3X71sIMA= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1684806476; x=1687398476; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=oOGZYEghKs3nn4mexef6OEUtQ/86KDKLq99QlVJ/owA=; b=JLK+M0GnWzfFu1I47nwHaa9DBYVShAvQ25rIO688pGeku/yhosiq9iflybOtXSynSG hdcOQN8a/Wclf/7Rbdon1w1gKvzCzfs9/v7hcoS8wco6Qf6UUbUbJ1tPEiN5sHfqL22p iMD6CHNJGbT9LjprbuvMurxunD/0xTZ8D9CvyVBVvW7FypZZXaFU/g9+PJh5x8m3Hdsi aB0357WwkCHfK/UPD+mfr/WGrTjrBm+50kJP3L1p9YUhdKzTIaJItPQj8Ch8v8mknM3J Bk9l+/t650omTCICiTkQY2JfXau1UkHQWFYGDHyFnezB9p7+B9K0PWhWdDgTiN2Ik6PU sZ4Q== X-Gm-Message-State: AC+VfDzonKLyuLaaXhYQTYh0m9dmPiq5EkkblJf/F1Qakgo4sABL7tWc nznhREQmNf0fbWoiLfyBimslnk/5rim0utwE0FyAw/VG X-Google-Smtp-Source: ACHHUZ4w3ZwkzpTELgm8T3QNxM6aG2XtLQFvan5+qnDg9e5MMGwtQOXfHR6aVjjXju0axsM3+J+Sjw== X-Received: by 2002:a17:907:a4b:b0:96f:4ee4:10d4 with SMTP id be11-20020a1709070a4b00b0096f4ee410d4mr11115768ejc.43.1684806475886; Mon, 22 May 2023 18:47:55 -0700 (PDT) Received: from mail-ej1-f48.google.com (mail-ej1-f48.google.com. [209.85.218.48]) by smtp.gmail.com with ESMTPSA id s22-20020a170906961600b0096f89c8a2f7sm3755083ejx.90.2023.05.22.18.47.54 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 22 May 2023 18:47:54 -0700 (PDT) Received: by mail-ej1-f48.google.com with SMTP id a640c23a62f3a-96f683e8855so624535166b.2 for ; Mon, 22 May 2023 18:47:54 -0700 (PDT) X-Received: by 2002:a17:907:86a2:b0:96f:a39c:86d6 with SMTP id qa34-20020a17090786a200b0096fa39c86d6mr9081820ejc.8.1684806474318; Mon, 22 May 2023 18:47:54 -0700 (PDT) MIME-Version: 1.0 References: <53dd9df8-e88f-f466-89f9-3fa141a10267@google.com> In-Reply-To: From: Linus Torvalds Date: Mon, 22 May 2023 18:47:37 -0700 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [patch] mm, debug: allow suppressing panic on CONFIG_DEBUG_VM checks To: David Rientjes Cc: David Hildenbrand , Andrew Morton , Michal Hocko , Alex Shi , Johannes Weiner , Matthew Wilcox , Alexander Duyck , linux-kernel@vger.kernel.org, linux-mm@kvack.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspam-User: X-Stat-Signature: crbrzyuckrducjcead8y4zw4srbkug8x X-Rspamd-Server: rspam07 X-Rspamd-Queue-Id: 93AB1C0014 X-HE-Tag: 1684806477-43615 X-HE-Meta: U2FsdGVkX18j47YpICOKRUwjNXJcDAEjbyMrVbI5QVorA/v8o5fVraXKzGxhRrmuaiIOZjlJwC4jUwTSPz/KeJ0o7duBME880KXZJewtBQd5O/gak5FUpm4Dkcnv3trEsSBRlFwRYb9HgPU8YSj2TGBQxDm1oT6OcbfweRAX9OnmartDj1/o7XL6QMRcU/ceyMffe9vJkcYSDfvgRClV9LH2XAf1UY0EsEqRkw0I/ffsxY3NQW2btff13jQ9MKK29KLTzxUnd4mkKo0JUPCvNjqVw4w1PxEvNmeP4nU3++j6cyTljRqifejVnY5PfDiGEtZu8AVPVT/ZqLjesVl+HoJvR4vq0V22ryd1W9sLhtSeDOHodMs8PCWAjSp+2TyYW3u4mBughIaH+jZSDLd+KMv/z5vT7NgMsNB0ZDqz0sc4JY6+hBfLMJPA1FhuwS7k1Fesl9xEeif4Iihtzk/oSdibdYXZFTuSzh30AXq0wfn7I3CZPDFRzzg0oDauSI+AvXIMFTbYvOHBm6s23LqG7BYM7q1OX3V1alNATtTkfutyrLKcqynq94twWuOMggPzW+3NZtjkAbMzB376ZiN4CevbXOeE1jHFn2BTcs840CQAZaGqdGxGXq066jZ2kCgwsKIu7kDHmhxa5GHsDDi1wnUIfh8oQj77QMJIkgvDiCJ+fnTlPG7vJhHQ+vKzc9CbLtx3PpVwajKxvwG3RtgkoStuKWeJGLEEEYC3xvo06POu6eM56MNleCChzDvY6zxYsB5Xkt33SeNyNR4Zy/4lHkjkR9631jXMKwFiRKmw0lmgWDcXcKDkeiyo9V4D9qd4BuDhqNbd2U6fjXMOLih84Puf2rk+uZsBXF7tkUecL1SRK8W9SyNYrBO/Jfyf/ivNX/W3qbRpheUA1a23AcfjbIGtS7CYvqb4oMYG6/6v+8BNPb4ZJN2YFssJHFukM7yCIjQiRVowgy3z0wbafiY wJqzcABg 9IO14Lr210/jLIWBTWVbxJovb4/613U4vqz7v+7EuopK1I+s9TS6esTHxAZSHOTW4VYU9EKYMTFa98RQ4ggwM0GfHBxsZb0s8azMdlBoNJU0ZNDyCc4z74sysj8bEtcrj81S1UdI2BfVlRF8SoUzvHFNsareLlxinXUs9BfG5F26pegRTT8guVynqH8Uk0zvVTCRPWvCSgYBds3qwWAMe55lawPwG9aSuuXfRoACtWdJQH0ae4OFDRUz9w33kjk6fH6L0NJJ1wApKbR8+vZlfEIVvDlI9Z/WaxEiwCvOE0ul/iSItQro86q3paATKcML/GgFgpYGlB4FRNvjK8jkFICf8Ah+rKWFRiE9xJSbcV5oVxlFpANRvGjmVMlmHZOW9O1X+mML9yDUNXNfqflNcENKJyLCUMDGBtUc22uLs5DMg5kambDN5EPwQiTT9EWTDCvTQ+QljJ2T31P+V47xdOnXIMceo5FlSpWRmOiriNcaJXFohr/nbcgJJGTdVtN/HrwEwGic6J1KTzP4kJAjaeFDWL6T7ADydWp7fOeZCmQgHGtxFtLsHD3aZU/A4egmb3IQJ 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 Mon, May 22, 2023 at 5:52=E2=80=AFPM 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 debu= g > 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=3D1" 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-pani= c (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. Linus Linus