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 vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id EE222ECAAD1 for ; Wed, 31 Aug 2022 13:34:55 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231881AbiHaNey (ORCPT ); Wed, 31 Aug 2022 09:34:54 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:43088 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231890AbiHaNe3 (ORCPT ); Wed, 31 Aug 2022 09:34:29 -0400 Received: from mail-yb1-xb36.google.com (mail-yb1-xb36.google.com [IPv6:2607:f8b0:4864:20::b36]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id CE73DD4F59 for ; Wed, 31 Aug 2022 06:33:36 -0700 (PDT) Received: by mail-yb1-xb36.google.com with SMTP id g5so4158281ybg.11 for ; Wed, 31 Aug 2022 06:33:36 -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=C39K45wIwffFM78TqlVdzyGIf1+av7WiNBDoS+/TODv1O1VD0k3CCAwRwEtE+YxzIU ar/WONqEt7l4rH9HY58d1+dcHOMEPRQYdLbT4XXy51z6cQZ7RXL7FJ4OUNV67egjbC6C qIgxIOb2LohODEO9l5GTrqybwMpVJlVjKNHklrNM75Zwattfukz7Z8yxXgn9UUqCqgzV iTVVmhRNZcMGqJ9j/l/l+iqdM4sxKmUAkbwKooWRp2DZ9dY7MGc8M8jkYF6QD/4epu/R znhC0iEMBqtwGEytJ4OBel0WgGZ2dBk8K2zINHYRE07gmgvbmh/DGCII8qtiAUWOKQZK YcUQ== X-Gm-Message-State: ACgBeo3wbY09iLKWULo4Em7CYfCfeHvhWeVMD6Dy9W9bS6tn0D8UAJae YYQpoGn5vsndb58ygyl2X9v8GCySEpFQuwDnFhLtQg== 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 Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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