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 5C061ECAAD7 for ; Fri, 26 Aug 2022 19:41:59 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id AE2686B0073; Fri, 26 Aug 2022 15:41:58 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id A90FF6B0074; Fri, 26 Aug 2022 15:41:58 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 932FF6B0075; Fri, 26 Aug 2022 15:41:58 -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 828736B0073 for ; Fri, 26 Aug 2022 15:41:58 -0400 (EDT) Received: from smtpin16.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay04.hostedemail.com (Postfix) with ESMTP id 5C5C21A06E1 for ; Fri, 26 Aug 2022 19:41:58 +0000 (UTC) X-FDA: 79842764316.16.00AED63 Received: from mail-ej1-f53.google.com (mail-ej1-f53.google.com [209.85.218.53]) by imf29.hostedemail.com (Postfix) with ESMTP id 1C1C8120008 for ; Fri, 26 Aug 2022 19:41:56 +0000 (UTC) Received: by mail-ej1-f53.google.com with SMTP id kk26so4959496ejc.11 for ; Fri, 26 Aug 2022 12:41:56 -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=qH9fXuLG/2N7XJd2Ax6mCY7hEPgeeICD6t/tT+e4ZA0=; b=OpNlxqMQbRgNEJYIapLZRyQ8QLwCr73YGaTNiV0QC490OmZqzOw8r4qyVuMJ9681dr No7PNh11cqUCQ6/tlGADYZyVLggenKnKCbhwK3EhhA7NtQAfrR6gJfRDHAKdwOLHx5t8 vBiepUa6W5cge4oVs0JpvJo51S3Adxw2YNf3M= 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=qH9fXuLG/2N7XJd2Ax6mCY7hEPgeeICD6t/tT+e4ZA0=; b=K2SDTW61uj5UyvDKlPN9dTF4UbBWtzaCrsO/9tDhVScn0Pzrrk4GrbkAAPHlxs/Ngd eipCZe16tpsMbVI5c9MDWkmtIkbVgmF+xUFcwcgmQ4II3Cb2775OAcsiAmlMQYA3Pqc3 0+ifu8PMqQ/uWAhkAGaEtQ3nFonR/Nitngpk8WX0YURu0+to072671CwN81RxdQEJtvg liI+eTp/eAGyc1iTjPxVsaJohvpkBdooWvDBqfMH9h6cTYWXEfzimNO0ileCIm0B8CFY wt6f2kOpHFkJ/mPz9nBfDcwqasz5RuSKqLIKLl08lFt6VYBQKGMaJrTfLFhZB0n5SBiF Nf6g== X-Gm-Message-State: ACgBeo21l/CKlGRYm/S6M2ImWIVv8ws4t37bAlp1V2QBHUQT+BTBIz+g I0Kg4XAIu+1w+2qv1kM07SkFlJ+KSk8uTjowec0= X-Google-Smtp-Source: AA6agR5yOC0HFTvw4x8iAf6gSEoPVTJgxVDODhpKg1tRKi6bS0dqmsqLQPG5NWd89tbm1Dyoju/zLg== X-Received: by 2002:a17:907:94c4:b0:73c:1547:f2f5 with SMTP id dn4-20020a17090794c400b0073c1547f2f5mr6445668ejc.234.1661542915322; Fri, 26 Aug 2022 12:41:55 -0700 (PDT) Received: from mail-wr1-f43.google.com (mail-wr1-f43.google.com. [209.85.221.43]) by smtp.gmail.com with ESMTPSA id bq10-20020a170906d0ca00b00734b2169222sm1216833ejb.186.2022.08.26.12.41.53 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 26 Aug 2022 12:41:54 -0700 (PDT) Received: by mail-wr1-f43.google.com with SMTP id bu22so2595039wrb.3 for ; Fri, 26 Aug 2022 12:41:53 -0700 (PDT) X-Received: by 2002:a5d:4052:0:b0:225:8b55:67fd with SMTP id w18-20020a5d4052000000b002258b5567fdmr600450wrp.281.1661542902549; Fri, 26 Aug 2022 12:41:42 -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: <20220825215754.GI25951@gate.crashing.org> From: Linus Torvalds Date: Fri, 26 Aug 2022 12:41:25 -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: Segher Boessenkool Cc: Alexander Potapenko , 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" ARC-Authentication-Results: i=1; imf29.hostedemail.com; dkim=pass header.d=linux-foundation.org header.s=google header.b=OpNlxqMQ; spf=pass (imf29.hostedemail.com: domain of torvalds@linuxfoundation.org designates 209.85.218.53 as permitted sender) smtp.mailfrom=torvalds@linuxfoundation.org; dmarc=none ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1661542917; a=rsa-sha256; cv=none; b=7fBA0WrvfiDR44QRmb+nJdWFgHNZI8FrIwUm/Q0fXLM8GKesrIN4Hh6bFZlC35yONySU28 +IDhOWI5b15i0enpV1TuKgmPIoA3un5dY58O6nTaST6wGq5C7YtvdbGRdhDzXjm9g8UvLv 91I3wdZ0wOlOn2s7s3NHox3/VTePPQE= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1661542917; 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=qH9fXuLG/2N7XJd2Ax6mCY7hEPgeeICD6t/tT+e4ZA0=; b=49dmnFpEmQISEOyfqN33vNMiInaiWQCaP6cDZL4svWkuZWs2+Y1ZYI+4baEO1DFb/R8OAY Aj4sWZ3/cnEQVRCAM3tGarIzy/PlERGFsWIsVvDyYxxxSTa3UJc6GGKYNfWs2A9vstKK/R uYPWkWJgBlZJYX7cUJrIgnhBnvS+OFk= X-Rspam-User: X-Stat-Signature: 3p7duui8nntt3gd785y51afa5dc6joky X-Rspamd-Queue-Id: 1C1C8120008 Authentication-Results: imf29.hostedemail.com; dkim=pass header.d=linux-foundation.org header.s=google header.b=OpNlxqMQ; spf=pass (imf29.hostedemail.com: domain of torvalds@linuxfoundation.org designates 209.85.218.53 as permitted sender) smtp.mailfrom=torvalds@linuxfoundation.org; dmarc=none X-Rspamd-Server: rspam09 X-HE-Tag: 1661542916-584816 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 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. 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