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 04495C19F2D for ; Tue, 9 Aug 2022 19:00:15 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 5CDF48E0002; Tue, 9 Aug 2022 15:00:15 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 57EE08E0001; Tue, 9 Aug 2022 15:00:15 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 444B58E0002; Tue, 9 Aug 2022 15:00:15 -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 336B98E0001 for ; Tue, 9 Aug 2022 15:00:15 -0400 (EDT) Received: from smtpin25.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay04.hostedemail.com (Postfix) with ESMTP id 01F421A11A6 for ; Tue, 9 Aug 2022 19:00:14 +0000 (UTC) X-FDA: 79780969590.25.81772AA Received: from mail-ej1-f50.google.com (mail-ej1-f50.google.com [209.85.218.50]) by imf10.hostedemail.com (Postfix) with ESMTP id 9A82DC015E for ; Tue, 9 Aug 2022 19:00:04 +0000 (UTC) Received: by mail-ej1-f50.google.com with SMTP id tl27so23861755ejc.1 for ; Tue, 09 Aug 2022 12:00:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux-foundation.org; s=google; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc; bh=VVV8GGpoeLc6+MwlCT0V9dvKeeRB3XD+JQNEfU5zFB4=; b=XS74q4C+R/RkerpK/v956xeICTISjlZPR7ZGmhz92t1i3i7F2m/3inQg+aj3m+m6dr M77s0vBeprURuoen9lVmJrVsTNMEMY6A9xIYseaKhApwnfZEJpAmNH7oRlfDEbFcQVug aYGLct1cvKUeJSKUfVfOlQcwDiMP9ep2ky3lI= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc; bh=VVV8GGpoeLc6+MwlCT0V9dvKeeRB3XD+JQNEfU5zFB4=; b=jqB8RbNHi9GW5czpd0UPSGb8sSLg8rA2mDC67myco4U8WVJ0m7fMS/o7y581wAyViU uAuaMnUmJx4NCEbFhHyaaHEw+U8J0ot+Il6a6mQvEsHRogCbGbuf07ZMjCqqc6wxAnz9 j9TWgPStYvsgDS36pMzv87PTbZENvYLiQ220dkGJW5bQ/1lFvuvK4lxLeYeTEc6IlWjI NE6aLXYRSU05evKCa8f/ENr7cIy7FCBZNJc1EpngXqU5FEd2Y6ecM9+xtQ1UAZbUSfrc cUvaAksZaHSSgh/5GWtYq4WBFXra9ffe7FOkMf6rJkcGZkiI2JUguXwMXRp9IS3xMDdD WU2g== X-Gm-Message-State: ACgBeo0d+r4kAz3IauF3W3jSaYmAnGx89YQFJnsbfv+ld3wBzXMtMbie ayYF0ar5efbPVoUyX6p+t7PfyluZUrv4/ueaSJA= X-Google-Smtp-Source: AA6agR7wkn0RAmLqEnhKFrjBC2SiB1cgnt+DE6KE3SLm0f7VG83YSUfURZjcUfWUtrde+0CR82V30A== X-Received: by 2002:a17:906:fe46:b0:730:ca2b:cb7b with SMTP id wz6-20020a170906fe4600b00730ca2bcb7bmr18652293ejb.703.1660071603037; Tue, 09 Aug 2022 12:00:03 -0700 (PDT) Received: from mail-wr1-f41.google.com (mail-wr1-f41.google.com. [209.85.221.41]) by smtp.gmail.com with ESMTPSA id bx13-20020a170906a1cd00b007311eb42e40sm1430663ejb.54.2022.08.09.12.00.02 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 09 Aug 2022 12:00:02 -0700 (PDT) Received: by mail-wr1-f41.google.com with SMTP id j1so15354996wrw.1 for ; Tue, 09 Aug 2022 12:00:02 -0700 (PDT) X-Received: by 2002:a5d:56cf:0:b0:21e:ce64:afe7 with SMTP id m15-20020a5d56cf000000b0021ece64afe7mr14879214wrw.281.1660071601819; Tue, 09 Aug 2022 12:00:01 -0700 (PDT) MIME-Version: 1.0 References: <20220808073232.8808-1-david@redhat.com> <1a48d71d-41ee-bf39-80d2-0102f4fe9ccb@redhat.com> In-Reply-To: <1a48d71d-41ee-bf39-80d2-0102f4fe9ccb@redhat.com> From: Linus Torvalds Date: Tue, 9 Aug 2022 11:59:45 -0700 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH v1] mm/gup: fix FOLL_FORCE COW security issue and remove FOLL_COW To: David Hildenbrand Cc: linux-kernel@vger.kernel.org, linux-mm@kvack.org, stable@vger.kernel.org, Andrew Morton , Greg Kroah-Hartman , Axel Rasmussen , Peter Xu , Hugh Dickins , Andrea Arcangeli , Matthew Wilcox , Vlastimil Babka , John Hubbard , Jason Gunthorpe Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: 9A82DC015E Authentication-Results: imf10.hostedemail.com; dkim=temperror ("DNS error when getting key") header.d=linux-foundation.org header.s=google header.b=XS74q4C+; dmarc=temperror reason="query timed out" header.from=linux-foundation.org (policy=temperror); spf=temperror (imf10.hostedemail.com: error in processing during lookup of torvalds@linuxfoundation.org: DNS error) smtp.mailfrom=torvalds@linuxfoundation.org X-Rspam-User: X-Rspamd-Server: rspam07 X-Stat-Signature: 59p8doewo5mep8k4j6xgsnf3wnwymi1d X-HE-Tag: 1660071604-494363 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 Tue, Aug 9, 2022 at 11:45 AM David Hildenbrand wrote: > > I totally agree with BUG_ON ... but if I get talked to in all-caps on a > Thursday evening and feel like I just touched the forbidden fruit, I > have to ask for details about VM_BUG_ON nowadays. > > VM_BUG_ON is only active with CONFIG_DEBUG_VM. ... which indicated some > kind of debugging at least to me. I *know* that Fedora enables it and I > *know* that this will make Fedora crash. No. VM_BUG_ON() has the exact same semantics as BUG_ON. It is literally no different, the only difference is "we can make the code smaller because these are less important". The only possible case where BUG_ON can validly be used is "I have some fundamental data corruption and cannot possibly return an error". This kind of "I don't think this can happen" is _never_ an excuse for it. Honestly, 99% of our existing BUG_ON() ones are completely bogus, and left-over debug code that wasn't removed because they never triggered. I've several times considered just using a coccinelle script to remove every single BUG_ON() (and VM_BUG_ON()) as simply bogus. Because they are pure noise. I just tried to find a valid BUG_ON() that would make me go "yeah, that's actually worth it", and couldn't really find one. Yeah, there are several ones in the scheduler that make me go "ok, if that triggers, the machine is dead anyway", so in that sense there are certainly BUG_ON()s that don't _hurt_. But as a very good approximation, the rule is "absolutely no new BUG_ON() calls _ever_". Because I really cannot see a single case where "proper error handling and WARN_ON_ONCE()" isn't the right thing. Now, that said, there is one very valid sub-form of BUG_ON(): BUILD_BUG_ON() is absolutely 100% fine. Linus