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 CEE34CE79A8 for ; Tue, 19 Sep 2023 22:39:32 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 53EF06B00E3; Tue, 19 Sep 2023 18:39:32 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 4EF576B00E4; Tue, 19 Sep 2023 18:39:32 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 3B6D76B00E5; Tue, 19 Sep 2023 18:39:32 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0014.hostedemail.com [216.40.44.14]) by kanga.kvack.org (Postfix) with ESMTP id 257C06B00E3 for ; Tue, 19 Sep 2023 18:39:32 -0400 (EDT) Received: from smtpin14.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay04.hostedemail.com (Postfix) with ESMTP id ED8A11A0CC9 for ; Tue, 19 Sep 2023 22:39:31 +0000 (UTC) X-FDA: 81254814942.14.1CDC6EF Received: from mail-lj1-f182.google.com (mail-lj1-f182.google.com [209.85.208.182]) by imf05.hostedemail.com (Postfix) with ESMTP id 0EB58100007 for ; Tue, 19 Sep 2023 22:39:28 +0000 (UTC) Authentication-Results: imf05.hostedemail.com; dkim=pass header.d=ionos.com header.s=google header.b=HjCPbgCo; dmarc=pass (policy=quarantine) header.from=ionos.com; spf=pass (imf05.hostedemail.com: domain of max.kellermann@ionos.com designates 209.85.208.182 as permitted sender) smtp.mailfrom=max.kellermann@ionos.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1695163169; 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=u4EOAYOSdTJZzySl47ZGYx8cRV3+gQBa0MO+WfUGiX4=; b=4Qks08cuDTcyPUOj6sRMxNv45aC/QeVc29AI/4VDJxMRuaC4Hga9zEUTLDqDaU5fVakZdx R3Agu71ZLLD6g6TTY8g8FCE+hoGFSW74hOj9o9zP7MTAkQdvc82Gs8VRvo5e2zhW+Kax8N iIA76y/gtO+r2/VjhE0HXjH0ri0DIdc= ARC-Authentication-Results: i=1; imf05.hostedemail.com; dkim=pass header.d=ionos.com header.s=google header.b=HjCPbgCo; dmarc=pass (policy=quarantine) header.from=ionos.com; spf=pass (imf05.hostedemail.com: domain of max.kellermann@ionos.com designates 209.85.208.182 as permitted sender) smtp.mailfrom=max.kellermann@ionos.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1695163169; a=rsa-sha256; cv=none; b=NROFDk1PNzvoHW4UptL7CKy53U3taRVnJIaCkCIOaIJ91ubvxVvIl0oW/pW3lvxPBJgRRy GOhQAKXdJbGQHzKByXaiOLDZPKSWsft2pdn0Nj0Ikx8wVknX+VuauFhReGWEQ4Mb3VFyL4 /CPfQ9/C7Lv//uTJrpOObq6xMmLaQ04= Received: by mail-lj1-f182.google.com with SMTP id 38308e7fff4ca-2c012573498so39811731fa.2 for ; Tue, 19 Sep 2023 15:39:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ionos.com; s=google; t=1695163167; x=1695767967; darn=kvack.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=u4EOAYOSdTJZzySl47ZGYx8cRV3+gQBa0MO+WfUGiX4=; b=HjCPbgCo8DeAe8wB/YHkSSAhO0SbEoktZjgC9KWlvw7bvI+aSsWVAAtP2lX8INtguu q8MWy1qJEaGIOd2+NI6PGWBlM1smLXJT8SIjoN8B2+ds/UHVF6Ix4FnihU+kS3IPnj/m qs9hmOABi8KNmz+nL/WT610P5Inbrktuy7V+Igj+LdtgvagLW/7qNcQBl+T9+yHMzVC1 Hnq9jDmy7nXGVAXF+yN4iIf9xXehLD9Wtn6zZgaq5+AXKuwftnB0jSXVcA1RgeB2Dd8P /EJifuECRPz92OXB9CbdvnApZT0oPs4zXU5x9PQ/VupD3ZBsJPSfJY6vhavAUm9bEB8T Z4Gw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1695163167; x=1695767967; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=u4EOAYOSdTJZzySl47ZGYx8cRV3+gQBa0MO+WfUGiX4=; b=mAIkpBJ6WZLVcSf+o2G4X006gre2Dd22Ta/fcJbhNsezMGxLnfadd9OaLJ4YHsiOyH nVFkIbZ0qVxfN0sTVlX74M8sdWWy1X+9a5QLcQKKZ/eL1+bnxX8EEJ11jN4M/gA63afO 9sHxnjDvw7N5iUCn4Z9fJyZkZniRV4Jf9MZSFmP6LFdZj+NDTKYB7icr1q5eZccP4Vqx 0I+3LCB3RSckmqZQzoHxNlRV4sXJ01xai5yXJSBUBuuQdfWW+6c4TBH23VDY1LuP3ZoJ vgmhfEkX5WxFM7p2/MHg6THxZbIije/wy5c8jLTBZEFPHpvn0Uk4HUhJM5YP7i+15SpO 9GLQ== X-Gm-Message-State: AOJu0YyQbExXUUw75WVT55X1Mjxmh+2jzA9EGSDsfIskIVjccJyWprrX FiSP4Lp3sbfQ/zIdHfYXf0s62Zxc0oi2AYEeax32EQ== X-Google-Smtp-Source: AGHT+IGGfEiSjnqJR6q4MlPxBttRVFIpiwjLG8LLmJRqBb5BwFwXS449AXPvD2cc2y7pGEhmjcIKbu3fQ83LZdlANV0= X-Received: by 2002:a2e:9919:0:b0:2b6:eb5a:d377 with SMTP id v25-20020a2e9919000000b002b6eb5ad377mr671269lji.5.1695163167101; Tue, 19 Sep 2023 15:39:27 -0700 (PDT) MIME-Version: 1.0 References: <20230919080707.1077426-1-max.kellermann@ionos.com> <20230919-fachkenntnis-seenotrettung-3f873c1ec8da@brauner> <20230919-deeskalation-hinsehen-3b6765180d71@brauner> In-Reply-To: <20230919-deeskalation-hinsehen-3b6765180d71@brauner> From: Max Kellermann Date: Wed, 20 Sep 2023 00:39:16 +0200 Message-ID: Subject: Re: [PATCH] pipe_fs_i.h: add pipe_buf_init() To: Christian Brauner Cc: Alexander Viro , "Matthew Wilcox (Oracle)" , Andrew Morton , Hugh Dickins , linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org, linux-mm@kvack.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: 0EB58100007 X-Rspam-User: X-Rspamd-Server: rspam05 X-Stat-Signature: iq55tjuu78pb9yit3g6rzaig8s6x7yu5 X-HE-Tag: 1695163168-615198 X-HE-Meta: U2FsdGVkX1/VVqVjd5Ud0PzQXFzo6IfGFgX0kEPDK/WFXwk/fGBsPqzZJP0Evwki5rF6dlEg+YBhc+uNxbFeMxLzjMW7WViIbXDesbK0ZA9oXuS+L1rWTbHwtlQ0tlHX3NiE1Zt1dSesw7MartpdclJoWDxJDNtECmVb7EZyGacKupsEn086oAv14hptFdJtQ8Gg0U8SJrPAFCCIoH5iFzSOQww6ODoUXHl1RPBEsk4axqbqfZq4DXQ6Oy111Fms8HWYkkbzvkwg2yihUaG/ThI4uqGJbhO+LaxlirAQ1l8B8/updkgaNesDSXdoA2j+S+9Vq2llCev7manUQEsSX7SnaiuURM377qySZBduoprQHOQDD3ERdRpyXcCGyY4bJMyzbfwNjTwmyJFNK6OKoZK5YUH8TU8ewJfpNqIYenlYYmrrXpyGsrbF3hwRAOSc4ljttT9Da7d9hmYY5uIuqRYjPNF1f63ONsdLPGH2Z3AuNzXocelnSmaw3gTypzG7CYC75AJyeQhxZA5LaJrJAGsDdd6oWeb2pMFybc01TF2sGT32WC1UnlhGMhSDgiYDD7KjHBYHVQFzSU6hclTiso6sPyrfMcAzR09s5K5aWQELd9ZugtSh+Eo1pIn4cToXC0yHskiL19/sM+bRYALn+boQNA08ymV58ANBuFJRAcO8IK4CRjg8Vkj7lRrHlQpegfIh/TPfA4pGhSaPgpOrvTMv7JB1cAASigT/h6T25UrCyhQh3Hjtj6dMiqpa03EDGuP8sSLl1gJunSDGTWX4jBpEsPf34QaZKAZt+ESyycL+S+RM9ng70JsmZqCY5Tab9gGwLiB8sOMe82NX4XN+Gp86UiDRUzzH8HcRoBJ0pvBeG119AG03lMwKG69ltn018Phdym59LT8AfKfv91J5EeHLQFWWzFCCQAafA/QoWLXKqx5WoRi8TL7d4CpvNDWehgRu4QFG/YSM4a3QKe7 vvHOwxQN xjDMl9rxweY/+klNRpdY+0ECJbvCe71x+QSqvnuO8aEp6F8YweqOcMzJDZK8n0tpN8EAk/1bCfk9FbYl0lYGUGL2DwqRTdqQQtyvMmlPxVkkArPC1BobKCWR/5AUfDWueTCbvxEz8FFFDvyiXP3FyuaAT/lKZTfn8qJIcYQQzDwEnnmxHk0dA3MSUS7fH8gA3A2QKANCm6YOrUMN2JwPnDCa3GvuwLODw4M2htZtHCFOun3fsUiSScXAvVb64xClPTo+T3e9adXGsD/WtQY5B5Hm1Wbxc5S1gynoiE23YzKLe5sYBWbmIBGHfDNt1hiEKkIf72Fz5EwZbOaw= 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 Tue, Sep 19, 2023 at 4:16=E2=80=AFPM Christian Brauner wrote: > You're changing how the code currently works which is written in a way > that ensures all fields are initialized to zero. The fact that currently > nothing looks at private is irrelevant. Two callers were previously using a designated intiializer which implicitly zero-initializes unmentioned fields; but that was not intentional, but accidental. It is true that these two call sites are changed, now omitting the implicit (and unintended) initializer. If you consider this a problem, I'll re-add it to those two callers. But adding the "private" initializer to the new function would also change how the code currently works - fot the other callers. It's only relevant if the "private" field is part of some API contract. If that API contract is undocumented, we should add documentation - what is it? I'll write documentation. > Following your argument below this might very easily be the cause for > another CVE when something starts looking at this. When something starts looking at this, the API contract changes, and this one function needs to be adjusted. Without this function, there is not one function, but an arbitrary number of redundant copies of this initializing code which all need to be fixed. As I said, only two copies of those currently do initialize "private", the others do not. Therefore, my patch is strictly an improvement, and is safer against those alleged future CVEs, which is the very goal of my patch. > Wouldn't it make more sense to have the pipe_buf_init() initialize the > whole thing and for the place where it leaves buf->private untouched you > can just do: Would it? I don't think so, but if you insist, I'll add it. I prefer to leave "private" uninitialized unless there is a reason to initialize it, for the reason I stated in my previous reply.