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 44DD8ECAAA6 for ; Fri, 26 Aug 2022 17:02:14 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 57A986B0074; Fri, 26 Aug 2022 13:02:13 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 52AEF6B0075; Fri, 26 Aug 2022 13:02:13 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 3CBD0940007; Fri, 26 Aug 2022 13:02:13 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0013.hostedemail.com [216.40.44.13]) by kanga.kvack.org (Postfix) with ESMTP id 2E3006B0074 for ; Fri, 26 Aug 2022 13:02:13 -0400 (EDT) Received: from smtpin11.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id EBE211609BF for ; Fri, 26 Aug 2022 17:02:12 +0000 (UTC) X-FDA: 79842361704.11.DD8C7C0 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by imf15.hostedemail.com (Postfix) with ESMTP id 7D3C6A002F for ; Fri, 26 Aug 2022 17:02:11 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1661533331; h=from:from: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; bh=jD7hXmOLkBQH1CWMlWymLxkZmC0QqnhEG6nyPcsh0A4=; b=GN6vhlrnJCF4yQiQ+szDDuz2v1lFmn41zSF3pBzrx99rKNyCHLfCz+xNHExmwUaieY6GoB zaLcByoN+8KMNIuSfcgccbl6Tfv3k/ssub/+5b6A4Gv7bde26Cvq7k/lWd9GExqm9Wfx2M YFiEP4xauiPwJJhI/QaFbO0bEb/yeck= Received: from mail-wm1-f70.google.com (mail-wm1-f70.google.com [209.85.128.70]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_128_GCM_SHA256) id us-mta-619-SUjLoXEtNqe-uBijRAwMlA-1; Fri, 26 Aug 2022 13:02:09 -0400 X-MC-Unique: SUjLoXEtNqe-uBijRAwMlA-1 Received: by mail-wm1-f70.google.com with SMTP id j36-20020a05600c1c2400b003a540d88677so1244605wms.1 for ; Fri, 26 Aug 2022 10:02:09 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:in-reply-to:subject:organization:from :references:cc:to:content-language:user-agent:mime-version:date :message-id:x-gm-message-state:from:to:cc; bh=jD7hXmOLkBQH1CWMlWymLxkZmC0QqnhEG6nyPcsh0A4=; b=ag+1FX6QTemX0T/lZw7N5t1lWq5YT55Bm3oRG1qeyLEAt8nJ06vALXTj/etKI5zQN1 G/N1PBPJXbzbHgUUQju++YVm4qGt9VA9tpkiqvvfFv/ayIQn/XIpwC//Nt6Lcq4lSFJE YuNQgyUTyjzkC8ntjsEuGs3BeN4kbmnyqnTttlNT9W9EcxmBTwLX3VEwupnI0iDXRbyz FPrbwAieYGDWyhpFsDt9WxKvjpsObSphCqrKOfiVn+b8TR3KYbTG+E2/tjJKjFPRuM3B P425nUymXaG7Qo6ZclfF2TPY0KAdCZeh9aLu/g3ss9+FLBbCsp4Mh1xR1HQW5ji++Jy6 DbfQ== X-Gm-Message-State: ACgBeo0+pmlfqZAttoqa0FTe2Ym4FnQsPpVtNdYtWAQd/HHNzOIxlTOI dzE8zYQCOKnERSL8ow1d8guF2WF6nOHisPZo53to+exf1sM+lZ5Kskn1YG/iQpfaWTLyouA9SKQ nH2d+FlziCd8= X-Received: by 2002:a05:600c:8a7:b0:3a6:85b1:2275 with SMTP id l39-20020a05600c08a700b003a685b12275mr360780wmp.30.1661533328596; Fri, 26 Aug 2022 10:02:08 -0700 (PDT) X-Google-Smtp-Source: AA6agR4qNFSQdWdKklLyf6JGMNF43WaQ/tj38zI60Lf4fb7qD47lrMKlJqT7hUbr1HvAPU4X99wkqw== X-Received: by 2002:a05:600c:8a7:b0:3a6:85b1:2275 with SMTP id l39-20020a05600c08a700b003a685b12275mr360750wmp.30.1661533328294; Fri, 26 Aug 2022 10:02:08 -0700 (PDT) Received: from ?IPV6:2003:cb:c708:f600:abad:360:c840:33fa? (p200300cbc708f600abad0360c84033fa.dip0.t-ipconnect.de. [2003:cb:c708:f600:abad:360:c840:33fa]) by smtp.gmail.com with ESMTPSA id l3-20020a1ced03000000b003a32251c3f9sm277131wmh.5.2022.08.26.10.02.07 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 26 Aug 2022 10:02:07 -0700 (PDT) Message-ID: Date: Fri, 26 Aug 2022 19:02:06 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.12.0 To: Dave Young Cc: John Hubbard , linux-kernel@vger.kernel.org, linux-mm@kvack.org, linux-doc@vger.kernel.org, kexec@lists.infradead.org, Linus Torvalds , Andrew Morton , Ingo Molnar , David Laight , Jonathan Corbet , Andy Whitcroft , Joe Perches , Dwaipayan Ray , Lukas Bulwahn , Baoquan He , Vivek Goyal , Stephen Johnston , Prarit Bhargava References: <20220824163100.224449-1-david@redhat.com> <20220824163100.224449-2-david@redhat.com> <0db131cf-013e-6f0e-c90b-5c1e840d869c@nvidia.com> From: David Hildenbrand Organization: Red Hat Subject: Re: [PATCH RFC 1/2] coding-style.rst: document BUG() and WARN() rules ("do not crash the kernel") In-Reply-To: X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Language: en-US Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1661533331; a=rsa-sha256; cv=none; b=pEKFcws5n5vw1tqEO9F5dVt/h7I2vE9BXb1Zln5Vd+xvqwxa42ZIh3IyhvdF13QUJ73WZ3 czb4JOpeAoVNZ9hj5D01AHa99+k6wlgSaYJdhALbLasn2nHAeN3YB2cEI3gi96ZsaaAT7o kUfb3/q5W/xQPc8k+qKEyrqXE7lzbRw= ARC-Authentication-Results: i=1; imf15.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=GN6vhlrn; dmarc=pass (policy=none) header.from=redhat.com; spf=pass (imf15.hostedemail.com: domain of david@redhat.com designates 170.10.129.124 as permitted sender) smtp.mailfrom=david@redhat.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1661533331; 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=jD7hXmOLkBQH1CWMlWymLxkZmC0QqnhEG6nyPcsh0A4=; b=MUcFeBgcg+3P+uZWIksx6JKrvpdsy0fLG838W0+9TRYyTwVRp3YhUpdCdRitr0Eb2KbulD NHoKsjhnfpi0SOj18usqnEqhuFlAiKw6vKrlKjQRRgCnVo6mnacAynrOpS3KbFJ8SkEgow kFQs/slZA/uj7Zk3tCWERutznM0rKUc= Authentication-Results: imf15.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=GN6vhlrn; dmarc=pass (policy=none) header.from=redhat.com; spf=pass (imf15.hostedemail.com: domain of david@redhat.com designates 170.10.129.124 as permitted sender) smtp.mailfrom=david@redhat.com X-Rspam-User: X-Rspamd-Server: rspam04 X-Stat-Signature: whwdthbkbjbibwx9sifronjo3sqeautd X-Rspamd-Queue-Id: 7D3C6A002F X-HE-Tag: 1661533331-741773 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 26.08.22 03:43, Dave Young wrote: > Hi David, > > [Added more people in cc] > Hi Dave, thanks for your input! [...] >> Side note: especially with kdump() I feel like we might see much more >> widespread use of panic_on_warn to be able to actually extract debug >> information in a controlled manner -- for example on enterprise distros. >> ... which would then make these systems more likely to crash, because >> there is no way to distinguish a rather harmless warning from a severe >> warning :/ . But let's see if some kdump() folks will share their >> opinion as reply to the cover letter. > > I can understand the intention of this patch, and I totally agree that > BUG() should be used carefully, this is a good proposal if we can > clearly define the standard about when to use BUG(). But I do have Essentially, the general rule from Linus is "absolutely no new BUG_ON() calls ever" -- but I think the consensus in that thread was that there are corner cases when it comes to unavoidable data corruption/security issues. And these are rare cases, not the usual case where we'd have used BUG_ON()/VM_BUG_ON(). > some worries, I think this standard is different for different sub > components, it is not clear to me at least, so this may introduce an > unstable running kernel and cause troubles (eg. data corruption) with > a WARN instead of a BUG. Probably it would be better to say "Do not > WARN lightly, and do not hesitate to use BUG if it is really needed"? Well, I don't make the rules, I document them and share them for general awareness/comments :) Documenting this is valuable, because there seem to be quite some different opinions floating around in the community -- and I've been learning different rules from different people over the years. > > About "patch_on_warn", it will depend on the admin/end user to set it, > it is not a good idea for distribution to set it. It seems we are > leaving it to end users to take the risk of a kernel panic even with > all kernel WARN even if it is sometimes not necessary. My question would be what we could add/improve to keep systems with kdump armed running as expected for end users, that is most probably: 1) don't crash on harmless WARN() that can just be reported and the machine will continue running mostly fine without real issues. 2) crash on severe issues (previously BUG) such that we can properly capture a system dump via kdump. The restart the machine. Of course, once one would run into 2), one could try reproducing with "panic_on_warn" to get a reasonable system dump. But I guess that's not what enterprise customers expect. One wild idea (in the cover letter) was to add something new that can be configured by user space and that expresses that something is more severe than just some warning that can be recovered easily. But it can eventually be recovered to keep the system running to some degree. But still, it's configurable if we want to trigger a panic or let the system run. John mentioned PANIC_ON(). What would be your expectation for kdump users under which conditions we want to trigger kdump and when not? Regarding panic_on_warn, how often do e.g., RHEL users observe warnings that we're not able to catch during testing, such that "panic_on_warn" would be a real no-go? -- Thanks, David / dhildenb