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 4122DC5B549 for ; Wed, 4 Jun 2025 15:42:54 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id D65C66B060F; Wed, 4 Jun 2025 11:42:53 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id D3D816B0611; Wed, 4 Jun 2025 11:42:53 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id C539F6B0612; Wed, 4 Jun 2025 11:42:53 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0012.hostedemail.com [216.40.44.12]) by kanga.kvack.org (Postfix) with ESMTP id AD84B6B060F for ; Wed, 4 Jun 2025 11:42:53 -0400 (EDT) Received: from smtpin23.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id 6F1561218FA for ; Wed, 4 Jun 2025 15:42:53 +0000 (UTC) X-FDA: 83518136226.23.9C22FBE Received: from mail-ej1-f50.google.com (mail-ej1-f50.google.com [209.85.218.50]) by imf26.hostedemail.com (Postfix) with ESMTP id 2A5BE14001C for ; Wed, 4 Jun 2025 15:42:50 +0000 (UTC) Authentication-Results: imf26.hostedemail.com; dkim=pass header.d=linux-foundation.org header.s=google header.b=T75BIJFf; spf=pass (imf26.hostedemail.com: domain of torvalds@linuxfoundation.org designates 209.85.218.50 as permitted sender) smtp.mailfrom=torvalds@linuxfoundation.org; dmarc=none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1749051771; 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=72BR0mnOxHdy2FcQxO8/Op0YCccM3iuq7r9CRzFPZg4=; b=PLWLU50rg+AF/N3R+DXCMyLYLHrtiBVvmCvxN1xB6sWKzUqBmUFmvpYIXJ6sYEQGxOxuQM rwLP2JKrm1/5uBPY1gxYZJUyga3OvZRG0bMcCB2Rbal9dbnGVzXH5aRB4QloXtf+ShuCN5 DqGLvCcX6v64z2GWRU+S7eLcApmRnbk= ARC-Authentication-Results: i=1; imf26.hostedemail.com; dkim=pass header.d=linux-foundation.org header.s=google header.b=T75BIJFf; spf=pass (imf26.hostedemail.com: domain of torvalds@linuxfoundation.org designates 209.85.218.50 as permitted sender) smtp.mailfrom=torvalds@linuxfoundation.org; dmarc=none ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1749051771; a=rsa-sha256; cv=none; b=OR3WD6gKraYdr9hgRPLDIVXhdjbKOHcAQaQVBw3nBGu0XhZ1U2btbpoq4tkcNsfJW4QtGF O3Kwfw616x+i641bnWWM7XHJ4AyldBtOD/sApArA6oTuWdwRQk4Kb/BGdMHhCJe5jIewQT 8FqNyDXve1sRqm/qjDD7vyGtTWqzVJo= Received: by mail-ej1-f50.google.com with SMTP id a640c23a62f3a-ad88d77314bso1249614566b.1 for ; Wed, 04 Jun 2025 08:42:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux-foundation.org; s=google; t=1749051769; x=1749656569; darn=kvack.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=72BR0mnOxHdy2FcQxO8/Op0YCccM3iuq7r9CRzFPZg4=; b=T75BIJFf04jDb8fGFcPS+TZ0i4X+yZZlc46Y6qCQJMf5TVITA8DjVuu2MsUGhrLhrN ZiPAS+swVaGKRfXiaDbQNJP1YrFVQj7ydLvpx03rmX/rR3fMESLiz+AlT/Qb2w53ea1c bFMwWeBPc2jjAyZvvGzcq7YoQAkc0p1VFcX2g= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1749051769; x=1749656569; h=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=72BR0mnOxHdy2FcQxO8/Op0YCccM3iuq7r9CRzFPZg4=; b=ANsPdKAn8OYUZ0WGRQHzDM4A3QFbeu5IBD3vzmbtAXUmuosd2VTh61gJ347sVGtSav QCiAdfFwkNFxW548v/uUTQz4A94cprZov3zBB91XVyhgwo/c+giOIvZPel4uuWUXw/t1 yIA47Yu9NikayArwTxnaBH6pZmQiuf8+RuqovZXAQo2eBwMPCYvTAlT6TV0Kf2JpfpvZ jX6PjFmSQKNysxziwqTGikxQuM3Ol7jyjzX7dlI2nBi/ImiEnqA0X7Dogqch/D4xUNMb A2x+lXN11wfzbHLUNTWgWFPGbsvCIBeMXGvvHckC/h3ffPttuY7Lar4XrkVPx8xSgNXQ Tytw== X-Forwarded-Encrypted: i=1; AJvYcCWSCKmXK0fxQA/q0vS5XlvxVPA9heU2yH2ezPLMOW14wyKnWW7P+UnMlQk4FprFitjK3rkq+b1MFA==@kvack.org X-Gm-Message-State: AOJu0YyixikkV4i1QEw8K/7tnAgubHiYhFZ/o/mfWRfcyayHC5+A3lJT G7JLdv/j8lJthNeur9otK6Qr+qiyfglP/Ww5AOQy2ROr2VoDQFfSMxfZeX+MXQ6KWW/Lt283iV2 VrOr9L7j9RQ== X-Gm-Gg: ASbGnctP14DWkWz2lj2stet56rvBDRPGH1S2ke6pWFU3ohTT1ESJl8E1Y8skftzSpx3 jr5vvBngA8zlLfZ/0N+lFv5Dtj5tM7VhhWVzuOwJBySaLo/XbKYpLhmXoyS8h7NnC+NlQ3hyX47 XLQIKoVMwV3qCLaEDMHYBsIR1x/i9ymLxIzg+WxG0fjU5I2bRKmSNg/QixcH53S1itaHE0vh50z ILS82iavAXFvfhvc65+qGgygJ/+v6MvHbvUxhkrchDrErX8HXpP5tv25AuaM2gxlkMktzWDr3Qb /FqOYHZ0omsm9hAjnURz1Ua0L7/MSibS28EiPLqMT21Q0Go6P8NBj1AlMhat6XIF57pInuo0cnO nUidVPagQTpD/VRcB1Yjax7nx1g== X-Google-Smtp-Source: AGHT+IEi96Di7rHOcuMYZKyY+KJRuBE7m04Mj9Y02SlyDqvQCFT4BQNO84fzutIP2jRTj7+B+jbYSA== X-Received: by 2002:a17:907:6d02:b0:ad5:45d6:5fd5 with SMTP id a640c23a62f3a-addf8ed689fmr313832166b.30.1749051769261; Wed, 04 Jun 2025 08:42:49 -0700 (PDT) Received: from mail-ed1-f45.google.com (mail-ed1-f45.google.com. [209.85.208.45]) by smtp.gmail.com with ESMTPSA id a640c23a62f3a-ada6ad394e5sm1114113666b.137.2025.06.04.08.42.47 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 04 Jun 2025 08:42:47 -0700 (PDT) Received: by mail-ed1-f45.google.com with SMTP id 4fb4d7f45d1cf-60410a9c6dcso3457660a12.1 for ; Wed, 04 Jun 2025 08:42:47 -0700 (PDT) X-Forwarded-Encrypted: i=1; AJvYcCWvoaOM/DtOUXJWwTFlBG4ZT+E5Cj1jAP0Nwz74dE9P3k9dh+bNtPHoq0pKpwjrLV6vns+n0R+gAw==@kvack.org X-Received: by 2002:a05:6402:50cd:b0:602:ddbe:480f with SMTP id 4fb4d7f45d1cf-606e944ffdbmr3318338a12.9.1749051767165; Wed, 04 Jun 2025 08:42:47 -0700 (PDT) MIME-Version: 1.0 References: <20250604140544.688711-1-david@redhat.com> In-Reply-To: From: Linus Torvalds Date: Wed, 4 Jun 2025 08:42:30 -0700 X-Gmail-Original-Message-ID: X-Gm-Features: AX0GCFsf8ms4gV6ZUTVFCM9XPKVFpcGv2mCqTXaG91B4GGR1O9kNamR8xKRlH28 Message-ID: Subject: Re: [PATCH v1] mm/gup: remove (VM_)BUG_ONs To: Lorenzo Stoakes Cc: David Hildenbrand , linux-kernel@vger.kernel.org, linux-mm@kvack.org, Andrew Morton , "Liam R. Howlett" , Vlastimil Babka , Mike Rapoport , Suren Baghdasaryan , Michal Hocko , Jason Gunthorpe , John Hubbard , Peter Xu Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: 2A5BE14001C X-Stat-Signature: mah6yaksenn93mzta9gdichfpim7kmas X-Rspam-User: X-Rspamd-Server: rspam04 X-HE-Tag: 1749051770-146892 X-HE-Meta: U2FsdGVkX19TZtByLWWq4VGMZEfugpO21L4l4UDVb7fB/V9frA+6LCE+ae8CF+NfBdlewzecIKYfGa3HkRYUgKHvTmsLm2BdVIQvPY120oLBos/qHRrST4xlO1w2g6LsrC1pSunldEHTLRsHSrEEe3Kd2JgLzJHetwNuoRbezeySz5UMOFcG8TT9LfCoMNJ+8QwjiYQc0NAHe1CRS37pIsu03BIdiULTUvvG/ACT5SzYsOd7j9zOnENRuqdq+M+VpyKjKDNsUk3r5f8tyQs3X9As6O6ZYcFtKHQIBVJDVBUJmSlREh8mD+K9af9h2pUsS9TSET0jMZilaUnpsuiM1sYGE2+RHy78JGL2NeSVyFkVw+5rMl2LOryYR2yn9IHmteY3ZnjJCfEq6xTjlKwza7xwT7wjRbNE9tauzXhwiSFMjCIaeRLCwyGu0v7WZMaj4ZXqyyB+Lp+jyngXd7dNz9teXpSzJWeTkwywD7qtJdd/fQI1LtOcIvFqFzMeaSTAeYbIYU4NpbtbZL35AbtzA5u/LwnvS+LSLkch7exCrtPJBpI55d11AWisuJTqfKPDWfuSbbhZX20uGq0fGA9kfcJ08WKG92koQ4byVJfpsrxzuUeQk6OEz5mDSvk//ot1c49tT4i3e9OaBXkjgRXyBGjKA/8P9fsRWJT1RtwnfwmXksk3HBYIu/eYpvj611Nm+bOpGnBxkAQiaapx5jvz2Y41BBC2n4IJGCbmRLT/EKlj/pQ2IuvJAar1GucGeUZbRujvfc26r6+n2107BrU/V/6IH6bCmHvC52ZLlQyK4Cz36E3Bv8U+RCdO0Ux8aRhB6NC2UaEffVmNWmntPoFszLbdW1CnhEt3+DbymMnIfaIRSPXXa+CFye1D/+rTMhXzfe7rO+fcX3ysxB3VrcoUCIwGwAaWjBmECls7tIpdfKKFQj4GpbSOVNQbT20XDt/A2AM2Lpa0s0zP1iN2V0k IjutplEz BnLqIoSa569CT3mohPB1CjrrX/Ibmk6Ctepi1xWpOo+32f2NhPkAFISlL/q+vD8U0UEX0EkDro0iEw4st55eS5mm9uUHpA4G1DowvgXtb3sOTVnqTq4Jovg6OsxV5kvlfEnoHcn3Ju/YZTdy1pQhGUT2sduuSeENxIqmWO3NVLtEqGOcQS3++CPbzjURTUdZr3D5RdTY5EaJG5e4uVHXP07v6LTdEeOu6JNTCQC41MLGL/rNlzoQCRcB7YKcx/WwubyO0dUwqckBzm3N5mHOoMHJF7O/k1sWAnnRRw9KAg1Sd5UIjGwT8M4Q2SM+OYrvjh6NYYXnAD0CYetbr804l1VYNlfpHkDC4lJ4WhJYVw4a+CNrqhakM0vkWrwnIFN9xdbNk/SkwPVtiozuifJ/IHofjmcU9tOYNdkydn1LfQqM5K/YZ5bPVo+sHyBpIpUBFPxrqfaPZ1+ZKchP3l6ga3T0qBZFhXABSRYQepIqjdoCbJ2Pw8iFAvA5BpP0TkR+lVh+t4c6Py9QVhBDXZDkrdauJmLOzZRemlD65iP8l3F7Jel5vxgzeo5excaX9Fshz5bWolHhK8wh47vM= 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: List-Subscribe: List-Unsubscribe: On Wed, 4 Jun 2025 at 07:49, Lorenzo Stoakes wrote: > > Linus's point of view is that we shouldn't use them _at all_ right? So > maybe even this situation isn't one where we'd want to use one? So I think BUG_ON() basically grew from (a) laziness. Not a good reason. (b) we historically had a model where we'd just kill processes on fatal errors, particularly page faults That (b) in particular *used* to work quite well for recovery - a couple of decades ago ago. A kernel bug would print out the backtrace, and then kill the process (literally with do_exit()) and try to run something else. It was wonderfully useful in that you'd get an oops, and the system would continue, but that *thread* wouldn't continue. And decades ago, it worked quite well, because the system was much simpler, and the likelihood that we held any critical locks was generally pretty low. But then SMP happened, and at first it wasn't a huge deal: we had one special lock, and the exit path would just clean *that* lock up, and life continued to be good. But that was literally over two decades ago, and none of the above actually ever used BUG_ON(). The page fault code would literally do die("Oops", regs, error_code); on a fatal page fault. A "BUG_ON()" didn't even exist back then, and die() looked like this: console_verbose(); spin_lock_irq(&die_lock); printk("%s: %04lx\n", str, err & 0xffff); show_registers(regs); spin_unlock_irq(&die_lock); do_exit(SIGSEGV); which tried to simply serialize the error output, and then kill the process. When it worked, it worked quite well. (And yes, page faults are very relevant, because this is what BUG looked like back then: #define BUG() *(int *)0 = 0 so it all depended on that page fault printing out the state and exiting) But as you can well imagine, it worked increasingly badly with increasing complexity and locking depth. When you come from that kind of "kill the process on errors" and you then realize that you can't really do that any more, you end up with BUG_ON(). The BUG_ON() thing was introduced in 2.5.0, and initially came from debug code in the block layer rewrite. And in that particular context, it actually made sense: this was new code that changed the block elevator, and if that code got it wrong, you were pretty much *guaranteed* disk corruption. But then it became a pattern. And I think that pattern is basically never good. I really think that the *ONLY* situation where BUG() is valid is when you absolutely *know* that corruption will happen, and you cannot continue. Very much *not* some kind of "this is problematic, and who knows what corruption it might cause". But "I *know* I can't continue without major system because the hardware is broken sh*t". In other words, don't use it. Ever. Unless you can explain exactly why without any handwaving. Cloud providers or others can do "panic-on-warn" if they want to stop the machine at the first sign of trouble. Linus