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 X-Spam-Level: X-Spam-Status: No, score=-0.8 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id EB0F9C2BA18 for ; Mon, 6 Apr 2020 07:54:30 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id ABAD72054F for ; Mon, 6 Apr 2020 07:54:30 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org ABAD72054F Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=suse.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 1CFD18E000E; Mon, 6 Apr 2020 03:54:30 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 159448E000D; Mon, 6 Apr 2020 03:54:30 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 020D08E000E; Mon, 6 Apr 2020 03:54:29 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0032.hostedemail.com [216.40.44.32]) by kanga.kvack.org (Postfix) with ESMTP id D79A38E000D for ; Mon, 6 Apr 2020 03:54:29 -0400 (EDT) Received: from smtpin13.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay04.hostedemail.com (Postfix) with ESMTP id 966F8499603 for ; Mon, 6 Apr 2020 07:54:29 +0000 (UTC) X-FDA: 76676667858.13.hand36_6164f472a0209 X-HE-Tag: hand36_6164f472a0209 X-Filterd-Recvd-Size: 2618 Received: from mx2.suse.de (mx2.suse.de [195.135.220.15]) by imf41.hostedemail.com (Postfix) with ESMTP for ; Mon, 6 Apr 2020 07:54:29 +0000 (UTC) X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.220.254]) by mx2.suse.de (Postfix) with ESMTP id 7D0F4AE07; Mon, 6 Apr 2020 07:54:26 +0000 (UTC) Date: Mon, 6 Apr 2020 09:54:25 +0200 From: Michal Hocko To: David Hildenbrand Cc: qiwuchen55@gmail.com, akpm@linux-foundation.org, willy@infradead.org, richard.weiyang@gmail.com, pankaj.gupta.linux@gmail.com, yang.shi@linux.alibaba.com, cai@lca.pw, bhe@redhat.com, linux-mm@kvack.org, chenqiwu Subject: Re: [PATCH] mm: use VM_BUG_ON*() helpers to dump more debugging info Message-ID: <20200406075425.GJ19426@dhcp22.suse.cz> References: <1586145321-23767-1-git-send-email-qiwuchen55@gmail.com> <70055cf8-165f-9e64-045d-617f02bdde9a@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <70055cf8-165f-9e64-045d-617f02bdde9a@redhat.com> 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 06-04-20 09:40:05, David Hildenbrand wrote: > On 06.04.20 05:55, qiwuchen55@gmail.com wrote: > > From: chenqiwu > > > > This patch use VM_BUG_ON*() helpers instead of simple BUG_ON() > > in some of the main mm codes. If CONFIG_DEBUG_VM is set, we can > > get more debugging information when the bug is hit. > > > > The "issue" in this context of VM_BUG_ON*() is that, without > CONFIG_DEBUG_VM, there won't really be any runtime checks anymore, > meaning a production system would not stop and BUG_ON() (which would be > disruptive, but there is a chance to debug this), instead it would > happily continue to run, eventually messing up something else. > > This is a clear change introduced in this series. > > My gut feeling is that we want to convert this on a per-case basis instead. This definitely should be done on per-case basis. Many of those bug ons are historical and they wouldn't be allowed these days. So I would definitely recommend going through each of them and re-evaluate whether they are really needed and whether they serve any purpose. A rule of thumb is that if we can handle the situation more gracefully then the BUG_ON should be simply dropped. If a verbatim output in a debugging mode would serve a good purpose then WARN{_ONECE} would serve a good purpose and if a crash is would help debugging in a DEBUG_VM mode then use the VM_BUG_ON instead. -- Michal Hocko SUSE Labs