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 69C03C433EF for ; Tue, 14 Jun 2022 14:49:31 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S235304AbiFNOt2 (ORCPT ); Tue, 14 Jun 2022 10:49:28 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:45070 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1354065AbiFNOtK (ORCPT ); Tue, 14 Jun 2022 10:49:10 -0400 Received: from mail-ej1-x649.google.com (mail-ej1-x649.google.com [IPv6:2a00:1450:4864:20::649]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id EAF8222B1E for ; Tue, 14 Jun 2022 07:49:07 -0700 (PDT) Received: by mail-ej1-x649.google.com with SMTP id s4-20020a170906500400b006feaccb3a0eso2984664ejj.11 for ; Tue, 14 Jun 2022 07:49:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=date:message-id:mime-version:subject:from:to:cc; bh=f1NsV1WL/3Cu5HsrxjnodRBUD3ku1jNNTcExFOPtw8Q=; b=al9FrbtHB6hB3HQYB0ocqE+/toR3+Zyie77HTHacz6lBVeiSjBBpqTYTMHDrDg4YqU UlHQEBf9E9/D9nTkh9GUZhIldKcB7UOhIH90qqF6Nhfjn4Bq9Vj79utZbWD84hqcUECy 3TVyyarRsH6Y/xaTYSx2hiaMeaQsnzy1oNgcqtnwCywR+hIBjNrD+46yDdUmYkyw+RBb RelxSqDfj/8CwgQZhoQsABEbZWwYfSxDPcgxYJNytaeWQqr1gJRPUwmUsP7UyeWeGiu2 h69JLLvWiBQVbGLN4CHMeR+cVPgPIFnIeRhpCwQusREfkd7m7lhDPMZAe8y4VTJnUIiO 90qQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:message-id:mime-version:subject:from:to:cc; bh=f1NsV1WL/3Cu5HsrxjnodRBUD3ku1jNNTcExFOPtw8Q=; b=R3HwGdXpQFJn6uCMRriaVrHO8DZWZ7yQID4jI/wqlt2la1nbRBvaxc8BB/Beu7zhn6 QlUEH2GNQta2TdtS44m29e4OHxiNiHXEzjFYxL/WTYYJTyeAvFQ06QD89dQ5eunF/y9O fTAadUlhIvVyUnVvO4Cktar5LCpdUtT6dwYrElbD7gzfcfvES9+zL7BPXyytrEj7mIUW x6uAscyX/yVeHcEmMirKMfSt/MHGGyBSaxb5nFE2B1s7RXSfIuCr0t0fySiTBWGJWbTn BY6IWWh9qkwMQFJrI9zXCobv+RbJl+VQ+qv0qwcupP7MyZ2Wk6p74L1wkun0al4bN8sb Z9PQ== X-Gm-Message-State: AOAM532+7+ZkEZ3LpPWGMXP4+vWVdsZGZf1JKE43eo8MbZzjSVyFZnHu GjAh6eckpU+J11yyXLSQILhY2cgZO6I= X-Google-Smtp-Source: ABdhPJwiyOTbJy7/Z19IQ0EL5TB6fB6fce6EnvsVdpqxlH/pXLatowNyuBMnTH7ww5XL7NmjFtiQoYXCqyo= X-Received: from glider.muc.corp.google.com ([2a00:79e0:9c:201:3c7f:9830:1892:19a7]) (user=glider job=sendgmr) by 2002:a05:6402:1f0e:b0:42d:e38a:51f7 with SMTP id b14-20020a0564021f0e00b0042de38a51f7mr6773121edb.68.1655218146192; Tue, 14 Jun 2022 07:49:06 -0700 (PDT) Date: Tue, 14 Jun 2022 16:48:53 +0200 Message-Id: <20220614144853.3693273-1-glider@google.com> Mime-Version: 1.0 X-Mailer: git-send-email 2.36.1.476.g0c4daa206d-goog Subject: [PATCH] [RFC] Initialization of unused function parameters From: Alexander Potapenko To: glider@google.com Cc: Evgenii Stepanov , Kees Cook , Linus Torvalds , Marco Elver , Nathan Chancellor , Nick Desaulniers , Thomas Gleixner , Vitaly Buka , linux-kernel@vger.kernel.org, linux-toolchains@vger.kernel.org Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-toolchains@vger.kernel.org Consider the patch below, where under certain circumstances initialization of `unsigned seq` and `struct inode *inode` passed into step_into() may be skipped. In particular, if the call to lookup_fast() in walk_component() returns NULL, and lookup_slow() returns a valid dentry, then the `seq` and `inode` will remain uninitialized until the call to step_into() (see [1] for more info). Right now step_into() correctly handles this and does not use the uninitialized values, but explicitly initializing them will guarantee their sanity in the case of future changes to step_into(). The bigger question I want to raise here is whether we want to discourage passing uninitialized variables to functions in the kernel altogether. While this is not required by the C standard (see the whole discussion at [2]), KMSAN can help with detecting cases where uninits are passed to functions (there is a more aggressive -fsanitize-memory-param-retval compiler option for that). This is somewhat similar to -Wmaybe-uninitialized, but works dynamically and has no false positives. Would initializing function parameters be a net benefit to the kernel? [1] https://github.com/ClangBuiltLinux/linux/issues/1648#issuecomment-1146608063 [2] https://github.com/ClangBuiltLinux/linux/issues/1648 Cc: Evgenii Stepanov Cc: Kees Cook Cc: Linus Torvalds Cc: Marco Elver Cc: Nathan Chancellor Cc: Nick Desaulniers Cc: Thomas Gleixner Cc: Vitaly Buka Cc: linux-kernel@vger.kernel.org Cc: linux-toolchains@vger.kernel.org Signed-off-by: Alexander Potapenko --- fs/namei.c | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/fs/namei.c b/fs/namei.c index 509657fdf4f56..dde370338f5d6 100644 --- a/fs/namei.c +++ b/fs/namei.c @@ -2001,8 +2001,8 @@ static const char *handle_dots(struct nameidata *nd, int type) static const char *walk_component(struct nameidata *nd, int flags) { struct dentry *dentry; - struct inode *inode; - unsigned seq; + struct inode *inode = NULL; + unsigned seq = 0; /* * "." and ".." are special - ".." especially so because it has * to be able to know about the current root directory and @@ -3349,8 +3349,8 @@ static const char *open_last_lookups(struct nameidata *nd, struct dentry *dir = nd->path.dentry; int open_flag = op->open_flag; bool got_write = false; - unsigned seq; - struct inode *inode; + unsigned seq = 0; + struct inode *inode = NULL; struct dentry *dentry; const char *res; -- 2.36.1.476.g0c4daa206d-goog