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 B700AC19F2D for ; Tue, 9 Aug 2022 19:21:40 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 4ECFC8E0002; Tue, 9 Aug 2022 15:21:40 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 4C3378E0001; Tue, 9 Aug 2022 15:21:40 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 3639E8E0002; Tue, 9 Aug 2022 15:21:40 -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 253A38E0001 for ; Tue, 9 Aug 2022 15:21:40 -0400 (EDT) Received: from smtpin06.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id D2D28AB966 for ; Tue, 9 Aug 2022 19:21:39 +0000 (UTC) X-FDA: 79781023518.06.C262EFA Received: from mail-ej1-f52.google.com (mail-ej1-f52.google.com [209.85.218.52]) by imf20.hostedemail.com (Postfix) with ESMTP id 771231C0184 for ; Tue, 9 Aug 2022 19:21:39 +0000 (UTC) Received: by mail-ej1-f52.google.com with SMTP id tl27so23959370ejc.1 for ; Tue, 09 Aug 2022 12:21:39 -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=r+avV5S2drX7G/TFGfNe00g1z/YAKwkOT5Ou5nsHkJY=; b=ZIX4nAvOOGcWp15i8uPfVmKtbEGBXCGgBiIwHpC5nNIUBi7Iq5HzVNS9BhUcgOter0 Oz2pZJ2RXavV4TVExYGzNgrX3BkQJjqumwDM/WFjxr12SCHjp9H48+PjlxSz0os95unt CPUV9XF+R7aEo6gt5l06ltaPKhdqQRG3D3AK8= 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=r+avV5S2drX7G/TFGfNe00g1z/YAKwkOT5Ou5nsHkJY=; b=WvlvNmrmhdGVmjoQVBPnvn56sE85ddkCqMTWUjRKekgJeniosEfuvgl4gQOF/EA+pd FTdSTF+kOAsBt5aWJdrPNnNvKBPicsx9UbAE19/6ZLMrjJLAOHmwx61OZBF/px6Gg8yb SoUdtwmE/QnNeLXlI5O/D2uFvkLQ6vhB6ULqvWRs1dibJ09Ub5+5mc4WY4v32NCrV9qR 9kTIrPkRqDV+YXOugl9wYt6FIEmLxQSLgtp5x34bU9qbV0yaQbB4FGcQSnk7a5Qnbne8 A2W+dtvxNa6UIECXQsjSoNoUGTijwRBfHjGGMCSEOT++AW9DBqeGRgQ6a8gGrKL9VF2I elsA== X-Gm-Message-State: ACgBeo3AOd2ZnRgVgy3uJfc8B/K81elwoK9SgvQ3qq7eMcQaAHtPIkhW TXQB4rCciT8p24iDAexZHwXoQZ69KpIxYKY9PVQ= X-Google-Smtp-Source: AA6agR7KtVw+oGpMqTm6D6Rx7cYnmXMhLwUpzF3KJnT6AA8wjwnxgYlA+sUHxcdeveM3AhLvpxzDAQ== X-Received: by 2002:a17:906:228a:b0:731:3a33:326 with SMTP id p10-20020a170906228a00b007313a330326mr10213765eja.253.1660072897916; Tue, 09 Aug 2022 12:21:37 -0700 (PDT) Received: from mail-wr1-f44.google.com (mail-wr1-f44.google.com. [209.85.221.44]) by smtp.gmail.com with ESMTPSA id t16-20020a1709066bd000b007308bdef04bsm1434709ejs.103.2022.08.09.12.21.34 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 09 Aug 2022 12:21:34 -0700 (PDT) Received: by mail-wr1-f44.google.com with SMTP id z17so15367982wrq.4 for ; Tue, 09 Aug 2022 12:21:34 -0700 (PDT) X-Received: by 2002:a5d:638b:0:b0:220:6e1a:8794 with SMTP id p11-20020a5d638b000000b002206e1a8794mr15428277wru.193.1660072893720; Tue, 09 Aug 2022 12:21:33 -0700 (PDT) MIME-Version: 1.0 References: <20220808073232.8808-1-david@redhat.com> <1a48d71d-41ee-bf39-80d2-0102f4fe9ccb@redhat.com> In-Reply-To: From: Linus Torvalds Date: Tue, 9 Aug 2022 12:21:17 -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: Jason Gunthorpe Cc: David Hildenbrand , 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 Content-Type: text/plain; charset="UTF-8" ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1660072899; a=rsa-sha256; cv=none; b=5/rK4AXtZMT+mkhfshn1Q2Prcm1qfIg50PBcqrNMvyO7evht/vQpsU78sZEPRQrXVuzKsX AVTOTWqjFAStKnHv5ndq101WiEohrJyQzoVlHhSl16wmhP+rALnRS0zGFOFbv8K7VYKmwk jDWQVNWJztRL4M4gBOazClY0OaF+4Co= ARC-Authentication-Results: i=1; imf20.hostedemail.com; dkim=pass header.d=linux-foundation.org header.s=google header.b=ZIX4nAvO; dmarc=none; spf=pass (imf20.hostedemail.com: domain of torvalds@linuxfoundation.org designates 209.85.218.52 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=1660072899; 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=r+avV5S2drX7G/TFGfNe00g1z/YAKwkOT5Ou5nsHkJY=; b=3571PteNCQK3xBuRNalNWFO4TE5Y5FHbNW7fRg6O5F3h7zjfMa1sP+cGheG14SVwxiODJL 7h7tL4dUQntnWBxmBokEs7a3CJsQCPTfsa1psS31bLj0jSZOsCWH77Em+m/7HVxhkLOgrx Vw5gpBxSYsMWZf0DLEHuxgNUMhnSmI0= X-Rspamd-Server: rspam12 X-Rspamd-Queue-Id: 771231C0184 Authentication-Results: imf20.hostedemail.com; dkim=pass header.d=linux-foundation.org header.s=google header.b=ZIX4nAvO; dmarc=none; spf=pass (imf20.hostedemail.com: domain of torvalds@linuxfoundation.org designates 209.85.218.52 as permitted sender) smtp.mailfrom=torvalds@linuxfoundation.org X-Rspam-User: X-Stat-Signature: gfknssaknm6c6cmdsy6gscd1jnj9rd9q X-HE-Tag: 1660072899-710369 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 12:09 PM Jason Gunthorpe wrote: > > Since BUG_ON crashes the machine and Linus says that crashing the > machine is bad, WARN_ON will also crash the machine if you set the > panic_on_warn parameter, so it is also bad, thus we shouldn't use > anything. If you set 'panic_on_warn' you get to keep both pieces when something breaks. The thing is, there are people who *do* want to stop immediately when something goes wrong in the kernel. Anybody doing large-scale virtualization presumably has all the infrastructure to get debug info out of the virtual environment. And people who run controlled loads in big server machine setups and have a MIS department to manage said machines typically also prefer for a machine to just crash over continuing. So in those situations, a dead machine is still a dead machine, but you get the information out, and panic_on_warn is fine, because panic and reboot is fine. And yes, that's actually a fairly common case. Things like syzkaller etc *wants* to abort on the first warning, because that's kind of the point. But while that kind of virtualized automation machinery is very very common, and is a big deal, it's by no means the only deal, and the most important thing to the point where nothing else matters. And if you are *not* in a farm, and if you are *not* using virtualization, a dead machine is literally a useless brick. Nobody has serial lines on individual machines any more. In most cases, the hardware literally doesn't even exist any more. So in that situation, you really cannot afford to take the approach of "just kill the machine". If you are on a laptop and are doing power management code, you generally cannot do that in a virtual environment, and you already have enough problems with suspend and resume being hard to debug, without people also going "oh, let's just BUG_ON() and kill the machine". Because the other side of that "we have a lot of machine farms doing automated testing" is that those machine farms do not generally find a lot of the exciting cases. Almost every single merge window, I end up having to bisect and report an oops or a WARN_ON(), because I actually run on real hardware. And said problem was never seen in linux-next. So we have two very different cases: the "virtual machine with good logging where a dead machine is fine" - use 'panic_on_warn'. And the actual real hardware with real drivers, running real loads by users. Both are valid. But the second case means that BUG_ON() is basically _never_ valid. Linus