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 7460BC32774 for ; Thu, 25 Aug 2022 15:40:03 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id B055D940007; Thu, 25 Aug 2022 11:40:02 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id A8D6E6B0075; Thu, 25 Aug 2022 11:40:02 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 92E4E940007; Thu, 25 Aug 2022 11:40:02 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0015.hostedemail.com [216.40.44.15]) by kanga.kvack.org (Postfix) with ESMTP id 7FF906B0074 for ; Thu, 25 Aug 2022 11:40:02 -0400 (EDT) Received: from smtpin02.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id 52E7C1608E5 for ; Thu, 25 Aug 2022 15:40:02 +0000 (UTC) X-FDA: 79838525844.02.0B660F1 Received: from mail-yw1-f172.google.com (mail-yw1-f172.google.com [209.85.128.172]) by imf08.hostedemail.com (Postfix) with ESMTP id 0473E160009 for ; Thu, 25 Aug 2022 15:40:01 +0000 (UTC) Received: by mail-yw1-f172.google.com with SMTP id 00721157ae682-33dc345ad78so39870747b3.3 for ; Thu, 25 Aug 2022 08:40:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc; bh=fEQ1d/PiEHzLrmSBXGQT2W8YpNnPcaA3hRqhgrIy1b8=; b=F6xZURA7pUQy2v+UOwJV2SRBjGEut5CjaZ/xUi6FcIumRsvYr32tRVL6VK+/rlWoHx UKx7ihhTtIGPsJeDPQVAQEqpER/3I2NT7tZlDZC4342uPPCsBBM1YcMyvgFJt6lwqFlg XN1YHVnBy2JZYsszV+IWYwr61w2KwdeOfaIX6yxyLJ1JC7QX1BLYGCe4hxspikhXhs72 LlOib55bwcEUaEKQmiCFgRQGvJCMgcZvugoncnNXcdNedyHR/+G7DB7ZUsduO3p+lKEL GVa8yILjJVx66GDhOZPVLdOghZ5Desu4mTb7XjFYxcPVXMxvEn3d9VGqQtRRWIFhkS+C 5nvw== 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=fEQ1d/PiEHzLrmSBXGQT2W8YpNnPcaA3hRqhgrIy1b8=; b=qKOspXUvg64WyjF1BjV6VV06Oji7ymbaqx6yvs7v3n2IXBo3IRP8/Hng0cNr31CCIS /xGLAfStbwggM2/Zhbelmp3JCX0TAhwcRZJBwh1770LqaK5q5FqZTXQ55P9IaZscLCFU o4ce3C6tMfwssoOX7iN/slfH0txoJxlfiIbCbAuPXnbwRYhHHZuu4JkLbaxYwhhAUQl0 DF8kXGfzmgwi/IWdZ5W0MOEXg9k6jkhWST4bvTg+jkZy1yc0jLFrLIhBHOvdcrKqthpJ 3BeLEYiwdgU10gbwpkOloSXdFTE1HO+MFRKi5fP7mXo2L8ojF6cmWba7kWcmI03J4XcA n7Gg== X-Gm-Message-State: ACgBeo2W9VrfuPjCAhcXY8bYadYrcXxxPU75WM8YaJAs6xvdYl2qwa+5 E0MND85mcOVzZkijDqEkp4gwQRJEapXQUcNvordVoQ== X-Google-Smtp-Source: AA6agR55v+DLet0yiWWCE94xVChePy5VsoHxFJfjQTURDicCdiaaIP6NeIPTzH3NruHqxBu+qCXcRybcS1En38eDdqc= X-Received: by 2002:a25:bc3:0:b0:673:bc78:c095 with SMTP id 186-20020a250bc3000000b00673bc78c095mr3870021ybl.376.1661442001024; Thu, 25 Aug 2022 08:40:01 -0700 (PDT) MIME-Version: 1.0 References: <20220701142310.2188015-1-glider@google.com> <20220701142310.2188015-45-glider@google.com> In-Reply-To: From: Alexander Potapenko Date: Thu, 25 Aug 2022 17:39:24 +0200 Message-ID: Subject: Re: [PATCH v4 44/45] mm: fs: initialize fsdata passed to write_begin/write_end interface To: Matthew Wilcox , Segher Boessenkool , Linus Torvalds , Thomas Gleixner Cc: 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=1661442002; 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=fEQ1d/PiEHzLrmSBXGQT2W8YpNnPcaA3hRqhgrIy1b8=; b=PNdSCEYbDBB8o/TQWekkTaCycl6gK9EK2gCDEE7KCWl/nK04h12E8ZuFnHGkC3LSCt2b82 4870tHX+y/S0u4v1n1wwu/YH3z8s73AqK5C6r5wKgbQv9PIQmOAy46gFKN2SADm3m3uEg4 70gNofGBgSbKNVltN1scYxYSxnTnSDk= ARC-Authentication-Results: i=1; imf08.hostedemail.com; dkim=pass header.d=google.com header.s=20210112 header.b=F6xZURA7; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf08.hostedemail.com: domain of glider@google.com designates 209.85.128.172 as permitted sender) smtp.mailfrom=glider@google.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1661442002; a=rsa-sha256; cv=none; b=e2B36sMaTtR4DwNAVADXgkaDwY8WEYVEillsOLXRNLPFAt3kRzNmr5NNP+6/J1ZA7QPuU4 ANPicedDl6ffEM79qaQk4uObYHR23wNmqXzaSW1N3x5MKHN4M6d/KeIHE8cxyKs8NPAIkj XLEwN6FkoIf8GQN8GLl4LhGMzXEaIFY= Authentication-Results: imf08.hostedemail.com; dkim=pass header.d=google.com header.s=20210112 header.b=F6xZURA7; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf08.hostedemail.com: domain of glider@google.com designates 209.85.128.172 as permitted sender) smtp.mailfrom=glider@google.com X-Rspamd-Server: rspam07 X-Rspamd-Queue-Id: 0473E160009 X-Stat-Signature: zqbmka91hfsy6hurd1frs5uueiusuzh3 X-Rspam-User: X-HE-Tag: 1661442001-343925 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 Mon, Jul 4, 2022 at 10:07 PM Matthew Wilcox wrote: > > On Fri, Jul 01, 2022 at 04:23:09PM +0200, Alexander Potapenko wrote: > > Functions implementing the a_ops->write_end() interface accept the > > `void *fsdata` parameter that is supposed to be initialized by the > > corresponding a_ops->write_begin() (which accepts `void **fsdata`). > > > > However not all a_ops->write_begin() implementations initialize `fsdata` > > unconditionally, so it may get passed uninitialized to a_ops->write_end(), > > resulting in undefined behavior. > > ... 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? > Hi Matthew, 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. Right now there are only a handful cases in the kernel where such passing is performed (we just need one more patch in addition to this one for KMSAN to boot cleanly). So we are in a good position to start enforcing this rule, unless there's a reason not to. I am not sure standard compliance alone is a convincing argument, but from KMSAN standpoint, performing parameter check at callsites noticeably eases handling of values passed between instrumented and non-instrumented code. This lets us avoid some low-level hacks around instrumentation_begin()/instrumentation_end() (some context available at [4]). Let me know what you think, Alex [1] - https://lore.kernel.org/lkml/CAFKCwrjBjHMquj-adTf0_1QLYq3Et=gJ0rq6HS-qrAEmVA7Ujw@mail.gmail.com/T/ [2] - https://lore.kernel.org/lkml/20220615164655.GC25951@gate.crashing.org/ [3] - https://lore.kernel.org/lkml/CAHk-=whjz3wO8zD+itoerphWem+JZz4uS3myf6u1Wd6epGRgmQ@mail.gmail.com/ [4] https://lore.kernel.org/lkml/20220426164315.625149-29-glider@google.com/