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 858C9ECAAD5 for ; Wed, 31 Aug 2022 13:33:33 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id A61F88D0001; Wed, 31 Aug 2022 09:33:32 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id A11D06B0072; Wed, 31 Aug 2022 09:33:32 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 8B2158D0001; Wed, 31 Aug 2022 09:33:32 -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 7D24C6B0071 for ; Wed, 31 Aug 2022 09:33:32 -0400 (EDT) Received: from smtpin25.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay09.hostedemail.com (Postfix) with ESMTP id 488E0801A6 for ; Wed, 31 Aug 2022 13:33:32 +0000 (UTC) X-FDA: 79859979864.25.F32A5AE Received: from mail-yb1-f181.google.com (mail-yb1-f181.google.com [209.85.219.181]) by imf18.hostedemail.com (Postfix) with ESMTP id E7C941C0046 for ; Wed, 31 Aug 2022 13:33:31 +0000 (UTC) Received: by mail-yb1-f181.google.com with SMTP id y197so4166537yby.13 for ; Wed, 31 Aug 2022 06:33:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc; bh=0+LvJ7VjdJUJkQtLqFzy6A2FisDBtX4zU7WtR7vEfb0=; b=lZE1wqPcUFTWUx2edJyH4j/xIAjV6jv2Q2oGtrj5GUNtTwzHlWPP5s6DqeZqSl9h8Y 5M2pjTrzgC3VMZR1TKgCMVNlFqzs6YpmNTPNQaRsVMonq17hQ26jD/H8Tz4E177fgg73 NhpoSy/yJx6JeJJ3hdx3YKg/Vku4dz+HPU8DXoj1Lu6i1NLgUA423Pyw9B/ZdZTJshiC 0mDh6vZsBBLCK+Ee0Us1bvDT2sG55h+CvEl+1b3evaLpTPUB/pNCbiPncvz2hXqSHBMG ix9J/RXr86EQDoPG2G1AYL+iXKf1Eu4GvNPauyG64Q5cElBD6rPco7a1Ku2nEJgjEUMv cDYg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc; bh=0+LvJ7VjdJUJkQtLqFzy6A2FisDBtX4zU7WtR7vEfb0=; b=GtA/MnbZwrlJEqg3ihu+S8EPJi1KmayzP+QIt73vqUkoYj6d4cgXLj60lDoyaVMt0I f7ww5xDf9rfIhlA/ea0XxPmC7UOjY2yk/hS4jTjd3FHssAGm3PyvMVgdCgdvz3drLT5c aR2e+LDPvS/2pGdpuxXi4jksp69Gav97zL4KT+tvZtjUgLrWTPYcY6UhjMddTzsQF2hG lkNO2l4H+4hRX5Myhb81FHwnnVsL+TYB8/M5UyBsV3NTwvOO2/vvvnpBtzblEuWX/Qc9 +9as1yIr7sfifYzKA8s05lcndNOWFmeC7otl9eHp/Iw6eBEGglq+WvRgfW6EGQ8RwPJz y8uQ== X-Gm-Message-State: ACgBeo1HiWmsj/BSW0PkL+sDP4oeCEyItTWfsIMoVuZSarVaMrwQpe0I kb3BoUgeC+ksFGQjSB88FcMpjU2MSo1Lr4JVe6YUqQ== X-Google-Smtp-Source: AA6agR527s4sIJuqvAoe6R6bXgEbs7fsJxYB1PTbH3VZAYpcKPk/1e0D345H5OETRX62rrwgZpKJfp6B29lhrMk3Lhk= X-Received: by 2002:a25:bc3:0:b0:673:bc78:c095 with SMTP id 186-20020a250bc3000000b00673bc78c095mr15327415ybl.376.1661952810986; Wed, 31 Aug 2022 06:33:30 -0700 (PDT) MIME-Version: 1.0 References: <20220701142310.2188015-1-glider@google.com> <20220701142310.2188015-45-glider@google.com> <20220825215754.GI25951@gate.crashing.org> In-Reply-To: From: Alexander Potapenko Date: Wed, 31 Aug 2022 15:32:54 +0200 Message-ID: Subject: Re: [PATCH v4 44/45] mm: fs: initialize fsdata passed to write_begin/write_end interface To: Linus Torvalds Cc: Segher Boessenkool , Matthew Wilcox , 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" Content-Transfer-Encoding: quoted-printable ARC-Authentication-Results: i=1; imf18.hostedemail.com; dkim=pass header.d=google.com header.s=20210112 header.b=lZE1wqPc; spf=pass (imf18.hostedemail.com: domain of glider@google.com designates 209.85.219.181 as permitted sender) smtp.mailfrom=glider@google.com; dmarc=pass (policy=reject) header.from=google.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1661952811; a=rsa-sha256; cv=none; b=bNBl52NLaSzPwZzNGw+uOFm3JxMnyK+gkiFso/dzJM5t9VgaSmqRXPX391ONGqmLbBRdjQ MxdIhSOzWqox7W5qeQIofIqy5BURWMfOLtrkA/8zgwYev2JKDA+KBFT+Qe3VwrcEwCt0de TJ/Ye08v32xIgG+8GPlT2ihz4rCIINY= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1661952811; 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:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=0+LvJ7VjdJUJkQtLqFzy6A2FisDBtX4zU7WtR7vEfb0=; b=UhIGjAItJzoO/1IKI8XRlGKlqqFpowS4FwZ7GsBrbVviuNXEQKrfgxSuFZldkjHfzzHh46 Ym3eZa+PiAgugPpd1Yf77hyWGd2Ukzn1Stb6m86ItomvzQ8z0E15fJ7bJWooLT/+wxptOW B6ZQzkCFgjp4pVZHKfymgXBm+BOwnAE= X-Rspamd-Server: rspam06 X-Rspamd-Queue-Id: E7C941C0046 X-Rspam-User: Authentication-Results: imf18.hostedemail.com; dkim=pass header.d=google.com header.s=20210112 header.b=lZE1wqPc; spf=pass (imf18.hostedemail.com: domain of glider@google.com designates 209.85.219.181 as permitted sender) smtp.mailfrom=glider@google.com; dmarc=pass (policy=reject) header.from=google.com X-Stat-Signature: x97snc47wup5wq8bcrt8r61krery5jy1 X-HE-Tag: 1661952811-118894 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 Fri, Aug 26, 2022 at 9:41 PM Linus Torvalds wrote: > > On Thu, Aug 25, 2022 at 3:10 PM Segher Boessenkool > wrote: > > > > But UB is defined in terms of the abstract machine (like *all* of C), > > not in terms of the generated machine code. Typically things will work > > fine if they "become invisible" by inlining, but this does not make the > > program a correct program ever. Sorry :-( > > Yeah, and the abstract machine model based on "abstract syntax" is > just wrong, wrong, wrong. > > I really wish the C standard people had the guts to just fix it. At > some point, relying on tradition when the tradition is bad is not a > great thing. > > It's the same problem that made all the memory ordering discussions > completely untenable. The language to allow the whole data dependency > was completely ridiculous, because it became about the C language > syntax and theory, not about the actual code generation and actual > *meaning* that the whole thing was *about*. > > Java may be a horrible language that a lot of people hate, but it > avoided a lot of problems by just making things about an actual > virtual machine and describing things within a more concrete model of > a virtual machine. > > Then you can just say "this code sequence generates this set of > operations, and the compiler can optimize it any which way it likes as > long as the end result is equivalent". > > Oh well. > > I will repeat: a paper standard that doesn't take reality into account > is less useful than toilet paper. It's scratchy and not very > absorbent. > > And the kernel will continue to care more about reality than about a C > standard that does bad things. > > Inlining makes the use of the argument go away at the call site and > moves the code of the function into the body. That's how things > *work*. That's literally the meaning of inlining. > > And inlining in C is so important because macros are weak, and other > facilities like templates don't exist. > > But in the kernel, we also often use it because the actual semantics > of "not a function call" in terms of code generation is also important > (ie we have literal cases where "not generating the 'call' > instruction" is a correctness issue). > > If the C standard thinks "undefined argument even for inlining use is > UB", then it's a case of that paperwork that doesn't reflect reality, > and we'll treat it with the deference it deserves - is less than > toilet paper. Just for posterity, in the case of KMSAN we are only dealing with cases where the function call survived inlining and dead code elimination. > We have decades of history of doing that in the kernel. Sometimes the > standards are just wrong, sometimes they are just too far removed from > reality to be relevant, and then it's just not worth worrying about > them. > > Linus --=20 Alexander Potapenko Software Engineer Google Germany GmbH Erika-Mann-Stra=C3=9Fe, 33 80636 M=C3=BCnchen Gesch=C3=A4ftsf=C3=BChrer: Paul Manicle, Liana Sebastian Registergericht und -nummer: Hamburg, HRB 86891 Sitz der Gesellschaft: Hamburg