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 391FDECAA24 for ; Thu, 25 Aug 2022 16:33:51 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 60FB194000B; Thu, 25 Aug 2022 12:33:50 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 5BE4C940007; Thu, 25 Aug 2022 12:33:50 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 4862A94000B; Thu, 25 Aug 2022 12:33:50 -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 39D8A940007 for ; Thu, 25 Aug 2022 12:33:50 -0400 (EDT) Received: from smtpin05.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id 10665AC9D0 for ; Thu, 25 Aug 2022 16:33:50 +0000 (UTC) X-FDA: 79838661420.05.FA6357C Received: from mail-lf1-f47.google.com (mail-lf1-f47.google.com [209.85.167.47]) by imf27.hostedemail.com (Postfix) with ESMTP id 8B3B040016 for ; Thu, 25 Aug 2022 16:33:49 +0000 (UTC) Received: by mail-lf1-f47.google.com with SMTP id z25so28982236lfr.2 for ; Thu, 25 Aug 2022 09:33:49 -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=4kxSioqpPleGpZIZkkWOJIrDSHemVIWhFh1D4qTNMMk=; b=NQdfXYryhBWr+N3PJU06t0oQ4lc7CgVyo3TcFiyRIk4CHatVXVTSn10rQYt/VJlpXo LGThVX0JBX37Gketuzyx64A18LV9xMpey8uidDsTEiKkgCxa9zRszgiZgCMlPF80koQr EwVPdmre7iSz8fqkh6ENGdiOp2RDRJzDuAgj0= 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=4kxSioqpPleGpZIZkkWOJIrDSHemVIWhFh1D4qTNMMk=; b=U8LaG8lg8NwUcx7+tYV7PIEtqATJn+RE9+u6MnLT3aRMzogzA81ZjdRKQsD5K1ixe6 ETmXWQ0N8j20FCTT0q3ZUsG2/aWt17fhtd4Nfsr8Ht0zw9X5eLIu1wlojQx3/w8X7kVM 5E1Vq68j+DrlfYjAzRW9ifF6B/1EpXNUiJw8EOhMgw18wv65+q1aFq6MOZiDGjWoX8X8 AyO0Nl5u1VHs1L03tmeNiAsbHGeVJrQIetzKQEaZt8vvxRuA5q+4dFH62o/ZvEJN3+LD 9lQ5byIR1zw2IgRoQMnlLysRXdyNYALrdSRK6oxaf8OsJemQvFpiJM17GHfXkBclF4Lh 8JEQ== X-Gm-Message-State: ACgBeo1hfrEHoH/t943t9wDLhr5nX+t48Ml6q1q9OD+DLJ2z3XyATUOw rszvNdiF9GDy1UzLJ70D0xvSfP2M0w1e2IewiH0= X-Google-Smtp-Source: AA6agR5Mrw/FCOUG43FvczaiEAuR28om3+wrGkcFvqY2ANlsCYi5oV68pLiiWrlrkEAerjozfJNJsg== X-Received: by 2002:a05:6512:2381:b0:492:afa4:6b67 with SMTP id c1-20020a056512238100b00492afa46b67mr1305042lfv.621.1661445227159; Thu, 25 Aug 2022 09:33:47 -0700 (PDT) Received: from mail-lj1-f181.google.com (mail-lj1-f181.google.com. [209.85.208.181]) by smtp.gmail.com with ESMTPSA id u22-20020ac24c36000000b0048a8c907fe9sm572317lfq.167.2022.08.25.09.33.45 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 25 Aug 2022 09:33:46 -0700 (PDT) Received: by mail-lj1-f181.google.com with SMTP id u24so14407897lji.0 for ; Thu, 25 Aug 2022 09:33:45 -0700 (PDT) X-Received: by 2002:a05:6000:1888:b0:222:ca41:dc26 with SMTP id a8-20020a056000188800b00222ca41dc26mr2662375wri.442.1661445214833; Thu, 25 Aug 2022 09:33:34 -0700 (PDT) MIME-Version: 1.0 References: <20220701142310.2188015-1-glider@google.com> <20220701142310.2188015-45-glider@google.com> In-Reply-To: From: Linus Torvalds Date: Thu, 25 Aug 2022 09:33:18 -0700 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH v4 44/45] mm: fs: initialize fsdata passed to write_begin/write_end interface To: Alexander Potapenko Cc: Matthew Wilcox , Segher Boessenkool , Thomas Gleixner , Alexander Viro , Alexei Starovoitov , Andrew Morton , Andrey Konovalov , Andy Lutomirski , Arnd Bergmann , Borislav Petkov , Christoph Hellwig , Christoph Lameter , David Rientjes , Dmitry Vyukov , Eric Dumazet , Greg Kroah-Hartman , Herbert Xu , Ilya Leoshkevich , Ingo Molnar , Jens Axboe , Joonsoo Kim , Kees Cook , Marco Elver , Mark Rutland , "Michael S. Tsirkin" , Pekka Enberg , Peter Zijlstra , Petr Mladek , Steven Rostedt , Vasily Gorbik , Vegard Nossum , Vlastimil Babka , kasan-dev , Linux Memory Management List , Linux-Arch , LKML Content-Type: text/plain; charset="UTF-8" ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1661445229; 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=4kxSioqpPleGpZIZkkWOJIrDSHemVIWhFh1D4qTNMMk=; b=eJzfl2sc1wsggx/bRTm8zaEycG1RRDxnyeNsKWi+FHY4x16SkWwgAJd1R0lLTSvRHsd2TJ CyrV9xBJkwaE576AzfSClj8tUX72dwa6d37xjqIT/7NnltDnB5Bs+w9m8+JLtPbbMmZYFU Q0MrNtqiUbWEE5V2SUE23W0jiQVp7H8= ARC-Authentication-Results: i=1; imf27.hostedemail.com; dkim=pass header.d=linux-foundation.org header.s=google header.b=NQdfXYry; spf=pass (imf27.hostedemail.com: domain of torvalds@linuxfoundation.org designates 209.85.167.47 as permitted sender) smtp.mailfrom=torvalds@linuxfoundation.org; dmarc=none ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1661445229; a=rsa-sha256; cv=none; b=uCrqJpXAOWlnNmJWIbDVgK+VxO+e2kuJ8RPnSTW3kgTh/7EPlD3TPuq5RGIh9xUNn47e4g 5uHT0kYwxM4YPWxW+YGFOEWSzSq8BQtuTnko6opTPrhW6lpWWMNauVP1kj0ArDrTEXuJs4 7QqIHDFk22qUT39iO7DsVsEfpRsjuBo= Authentication-Results: imf27.hostedemail.com; dkim=pass header.d=linux-foundation.org header.s=google header.b=NQdfXYry; spf=pass (imf27.hostedemail.com: domain of torvalds@linuxfoundation.org designates 209.85.167.47 as permitted sender) smtp.mailfrom=torvalds@linuxfoundation.org; dmarc=none X-Rspam-User: X-Stat-Signature: esa3st1pde87iozaesjqxkzffh3tdkmr X-Rspamd-Queue-Id: 8B3B040016 X-Rspamd-Server: rspam03 X-HE-Tag: 1661445229-815071 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 Thu, Aug 25, 2022 at 8:40 AM Alexander Potapenko wrote: > > On Mon, Jul 4, 2022 at 10:07 PM Matthew Wilcox wrote: > > > > ... wait, passing an uninitialised variable to a function *which doesn't > > actually use it* is now UB? What genius came up with that rule? What > > purpose does it serve? > > > > There is a discussion at [1], with Segher pointing out a reason for > this rule [2] and Linus requesting that we should be warning about the > cases where uninitialized variables are passed by value. I think Matthew was actually more wondering how that UB rule came to be. Personally, I pretty much despise *all* cases of "undefined behavior", but "uninitialized argument" across a function call is one of the more understandable ones. For one, it's a static sanity checking issue: if function call arguments can be uninitialized random garbage on the assumption that the callee doesn't necessarily _use_ them, then any static checker is going to be unhappy because it means that it can never assume that incoming arguments have been initialized either. Of course, that's always true for any pointer passing, but hey, at least then it's pretty much explicit. You're passing a pointer to some memory to another function, it's always going to be a bit ambiguous who is supposed to initialize it - the caller or the callee. Because one very important "static checker" is the person reading the code. When I read a function definition, I most definitely have the expectation that the caller has initialized all the arguments. So I actually think that "human static checker" is a really important case. I do not think I'm the only one who expects incomping function arguments to have values. But I think the immediate cause of it on a compiler side was basically things like poison bits. Which are a nice debugging feature, even though (sadly) I don't think they are usually added the for debugging. It's always for some other much more nefarious reason (eg ia64 and speculative loads weren't for "hey, this will help people find bugs", but for "hey, our architecture depends on static scheduling tricks that aren't really valid, so we have to take faults late"). Now, imagine you're a compiler, and you see a random incoming integer argument, and you can't even schedule simple arithmetic expressions on it early because you don't know if the caller initialized it or not, and it might cause some poison bit fault... So you'd most certainly want to know that all incoming arguments are actually valid, because otherwise you can't do even some really simple and obvious optimziations. Of course, on normal architectures, this only ever happens with FP values, and it's often hard to trigger there too. But you most definitely *could* see it. I personally was actually surprised compilers didn't warn for "you are using an uninitialized value" for a function call argument, because I mentally consider function call arguments to *be* a use of a value. Except when the function is inlined, and then it's all different - the call itself goes away, and I *expect* the compiler to DTRT and not "use" the argument except when it's used inside the inlined function. Because hey, that's literally the whole point of inlining, and it makes the "static checking" problem go away at least for a compiler. Linus