Received: by 2002:a6b:fb09:0:0:0:0:0 with SMTP id h9csp1650769iog; Tue, 14 Jun 2022 10:09:41 -0700 (PDT) X-Google-Smtp-Source: AGRyM1ud28OMFHcS/2NhoI+s2KvWjrrauMUa8swFkr+0m2NJJxbOp53h5EssCN7H3NYoi3pJeWB5 X-Received: by 2002:a17:906:65c8:b0:713:ee3e:254d with SMTP id z8-20020a17090665c800b00713ee3e254dmr964757ejn.0.1655226581475; Tue, 14 Jun 2022 10:09:41 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1655226581; cv=none; d=google.com; s=arc-20160816; b=RmfjXHm0ZALe1P1y3o9yRB9cU2S7ek4a7qOZUr4I0IuHKdnXXy3VAtM1BgcVWZql1k MW+b9eNu2LLmg4zMWhP4Rvwtxu0TfAQaOVGS0kBweb3jf3zw9wG3X1gADDVZXsZ1yuZW TEm6uSjd7U7LAg7JineLkU17M4+9Iq19aBxW36IeOh3h7f3uyN/PlcqTysz7rvEq2MWU uiRCCp9YbKfYdEahNAHQxA7lox2QgR7HUhEm3hUDbUGWwEC0kQ9EVEH0ityHIjzGcdyC 4v5y908zNbmD3EQLQ5Wd5vu8fvI72+97sJv3xSWbvZcYfC7tZWV0dTBpqlLJtm8iHcuW oP2g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:dkim-signature; bh=5cvWfPjVNLAIHIZUAi0xIfsh5PXPOWCDCWkx0bXDbAE=; b=i+vPwDgOrzxb/XmWaT2D5AYpvB95pWADq8DgrMEMU3DTZr/f9nWu46MY8bqBzLfCDo 84XrM4bFAs7etsNriCLCVG+w3vRmOTZ5EtawZvRNTI+MSs23MSARRq7suyKv/bp8GQw4 XFYO8gPYWLgu7SZz1GkMdMVRYB9/bhwzPXT0UgMefHaX/W3JRN1iKrc5kRbVk1CkIhH2 m0WfkV5kU5O/E7vHA/tMmeVdWVBdy8/gpWP7g4LvRBmUOzP+lm+u+2dqDcz2o6NX+MqY Olccz31ZUSe5+hZhleQksTZXFhdh8d+K57V2tvzxG8xagUPlUxQOK7E11QOWPNlBL3KA ugRA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linux-foundation.org header.s=google header.b=fkDY3kih; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id p7-20020aa7d307000000b0042dd79e606fsi12084161edq.478.2022.06.14.10.09.14; Tue, 14 Jun 2022 10:09:41 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@linux-foundation.org header.s=google header.b=fkDY3kih; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1344578AbiFNQtI (ORCPT + 99 others); Tue, 14 Jun 2022 12:49:08 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:38536 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1344657AbiFNQs4 (ORCPT ); Tue, 14 Jun 2022 12:48:56 -0400 Received: from mail-ej1-x634.google.com (mail-ej1-x634.google.com [IPv6:2a00:1450:4864:20::634]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 0843E38792 for ; Tue, 14 Jun 2022 09:48:55 -0700 (PDT) Received: by mail-ej1-x634.google.com with SMTP id fu3so18311687ejc.7 for ; Tue, 14 Jun 2022 09:48:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux-foundation.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=5cvWfPjVNLAIHIZUAi0xIfsh5PXPOWCDCWkx0bXDbAE=; b=fkDY3kih2RQYVtQDrIhydfjyCechMncgd0DM66XBHsRZ/iiPmXjDAf2lJn1ITrb5fe 6AYh21Efuj1jfYc2bBSP/QwQ6FuV1plJzy3GzuPFsugU2gYzcTPep5+zaKdjwSkj2nd+ DOEU7BQswDunRLHojZJVLtdmZVGnqVRXHs9QY= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=5cvWfPjVNLAIHIZUAi0xIfsh5PXPOWCDCWkx0bXDbAE=; b=1vhNDqruZDjoNucfICvisfOhJTSyV2CABH2FDJHivsVx4saocFFtxlTZCSpSDiZl3E hMwE087zR/6Kw/5mcALvkqlN9/gItyjQoKP9amiizu4Sf8NNugu2cjg9KW6OQ33vQOje /tpFLzoaOr8mw85MLtbTivghHapf63ddX8tU8p2a3iwyA8Cx86fEtyVuKA17C0vDDufp pK+VGlxBBWrmzjCeNFZp7enCBW+6ELwM8SW/pI7ZmoV4mpoPSVD2bsSJoHtvO6UbT+H9 1/JpTflo9ZPnwxGjoxXsjqHLMxBZrFDeSOptwKv52zJBqqAcEMAAr0Y2jQK5YWex/YOc oPDw== X-Gm-Message-State: AOAM533tHZqybkh4KdaNGape7U8JqLiUNHJ2mnj91UcAKeHXmICRi6Vw LZl0F3x/HZpPXT3DcLTq6cBtElcsPIUyYzja X-Received: by 2002:a17:906:5352:b0:712:3916:e92 with SMTP id j18-20020a170906535200b0071239160e92mr5109957ejo.756.1655225333240; Tue, 14 Jun 2022 09:48:53 -0700 (PDT) Received: from mail-wr1-f47.google.com (mail-wr1-f47.google.com. [209.85.221.47]) by smtp.gmail.com with ESMTPSA id u20-20020a509514000000b0042dd1d3d571sm7538836eda.26.2022.06.14.09.48.52 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 14 Jun 2022 09:48:52 -0700 (PDT) Received: by mail-wr1-f47.google.com with SMTP id w17so4559687wrg.7 for ; Tue, 14 Jun 2022 09:48:52 -0700 (PDT) X-Received: by 2002:a5d:6da3:0:b0:219:bcdd:97cd with SMTP id u3-20020a5d6da3000000b00219bcdd97cdmr5767487wrs.274.1655225332260; Tue, 14 Jun 2022 09:48:52 -0700 (PDT) MIME-Version: 1.0 References: <20220614144853.3693273-1-glider@google.com> In-Reply-To: <20220614144853.3693273-1-glider@google.com> From: Linus Torvalds Date: Tue, 14 Jun 2022 09:48:35 -0700 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH] [RFC] Initialization of unused function parameters To: Alexander Potapenko Cc: Evgenii Stepanov , Kees Cook , Marco Elver , Nathan Chancellor , Nick Desaulniers , Thomas Gleixner , Vitaly Buka , Linux Kernel Mailing List , linux-toolchains Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-1.8 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS,T_SCC_BODY_TEXT_LINE autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Jun 14, 2022 at 7:49 AM Alexander Potapenko wrote: > > The bigger question I want to raise here is whether we want to > discourage passing uninitialized variables to functions in the kernel > altogether. I'm assuming you mean pass by reference. Some functions are really fundamentally about initializing things, and expect uninitialized allocations. Obviously the traditional example of this is "memset()", and that one can be special-cased as obvious, but we probably have a ton of wrapper things like that. IOW, things like just "snprintf()" etc is fundamentally passed an uninitialized buffer, because the whole point is that it will write to that buffer. And no, we don't want to initialize it, since the buffer may be big (on purpose). Now, for *small* things (like that "pointer to inode") that aren't some kind of array or big structure, I think it might be good to perhaps be stricter. But even there we do have cases where we pass things by reference because the function is explicitly designed to initialize the value: the argument isn't really "an argument", it's a "second return value". But always initializing in the caller sounds stupid and counter-productive, since the point is to initialize by calling the helper function (think things like returning a "cookie" or similar: initializing the cookie to NULL in the caller is just plain _wrong_. What I think might be a good model is to be able to mark such arguments as "must be initialized by callee". So then the rule could be that small arguments passed by reference have to be either initialized by the caller, or the argument must have that "initialized by callee" attribute, and then the initialization would be enforced in the callee instead. But making the rule be that the caller *always* has to initialize sounds really wrong to me. Linus