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 X-Spam-Level: X-Spam-Status: No, score=-5.8 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 97799C432BE for ; Fri, 27 Aug 2021 17:53:37 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 680E060FD9 for ; Fri, 27 Aug 2021 17:53:37 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231196AbhH0RyZ (ORCPT ); Fri, 27 Aug 2021 13:54:25 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:39902 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231349AbhH0RyY (ORCPT ); Fri, 27 Aug 2021 13:54:24 -0400 Received: from mail.skyhub.de (mail.skyhub.de [IPv6:2a01:4f8:190:11c2::b:1457]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id C8698C061757; Fri, 27 Aug 2021 10:53:31 -0700 (PDT) Received: from zn.tnic (p200300ec2f111700cf40790d4c46ba75.dip0.t-ipconnect.de [IPv6:2003:ec:2f11:1700:cf40:790d:4c46:ba75]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.skyhub.de (SuperMail on ZX Spectrum 128k) with ESMTPSA id C0D781EC0464; Fri, 27 Aug 2021 19:53:25 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=alien8.de; s=dkim; t=1630086805; h=from:from: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; bh=Vnzi8i4BEi+cvl2op6fLcbMnIqawCJJ9n45UwHm3acc=; b=dE/4cW7JIYkODgbdUOgqYWF853o0YXGEMA5Vs0UV4nyXDhklFT5wPwDMO8d42wsyIDh5L8 03OTw4N2uUvYWb0eoiVLN4YFaDAT5e59Ge8dIewEO6WY+HjqER9WJ6zSPSmtouSFZVtbKb Vv30fIMAPxzc3cFG7H+3NN/vD7XmHJY= Date: Fri, 27 Aug 2021 19:54:07 +0200 From: Borislav Petkov To: Len Baker Cc: Mauro Carvalho Chehab , Tony Luck , James Morse , Robert Richter , Joe Perches , David Laight , Kees Cook , linux-hardening@vger.kernel.org, linux-edac@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH v4] EDAC/mc: Prefer strscpy over strcpy Message-ID: References: <20210814075527.5999-1-len.baker@gmx.com> <20210824090338.GB7999@titan> <20210827173633.GA3040@titan> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20210827173633.GA3040@titan> Precedence: bulk List-ID: X-Mailing-List: linux-edac@vger.kernel.org On Fri, Aug 27, 2021 at 07:36:33PM +0200, Len Baker wrote: > Well, the main purpose is to clean up the proliferation of str*cpy functions. > One task is to remove the strcpy uses: The first step (previous step) would > be to remove all the strcpy uses. Then, as a second step remove all the > strcpy implementations. > > I hope that this clarify your question. Yes, it does. Now lemme clarify why I'm asking: when your patch is committed to the kernel tree and someone reads its commit message months or even years from now - and those who do that are mostly maintainers trying to figure out why stuff was done the way it was - they will read: "This is a previous step in the path to remove the strcpy() function entirely from the kernel." and wonder what previous step that is what the following step is... So, long story short, your commit message should be complete on its own and understandable without any references to things which might not be as clear and self-evident in the future as they are now. Makes sense? Also, if you're wondering if you should send the patch with the error checking of strscpy() added, as I requested, even if it might look superfluous now, yes you should. Even if it looks impossible now, we might change some of those defines in the future and forget to touch the logic which generates e->label and we might end up exhausting that string. So it would be a lot more robust if something would catch that change, albeit seemingly redundant now. I sincerely hope that clears up things. Thx. -- Regards/Gruss, Boris. https://people.kernel.org/tglx/notes-about-netiquette