Message ID | 20230811-strncpy-arch-powerpc-platforms-ps3-v1-0-301052a5663e@google.com |
---|---|
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a59:b824:0:b0:3f2:4152:657d with SMTP id z4csp1370115vqi; Fri, 11 Aug 2023 14:39:07 -0700 (PDT) X-Google-Smtp-Source: AGHT+IEJu1+DnUsVZXfaIKJWFcSdjf933uZLfGcHaSNNiSCR8sje28fsolm4PAet6/DDyXpjSeEk X-Received: by 2002:a17:907:3f9c:b0:992:103c:43fa with SMTP id hr28-20020a1709073f9c00b00992103c43famr8153702ejc.30.1691789947509; Fri, 11 Aug 2023 14:39:07 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1691789947; cv=none; d=google.com; s=arc-20160816; b=DLMGcaRQ471BEhbgdFUgUqNodc0GEckDNV9YlY5ldvHBOicbEgI5FUIhfn/XVTXPsB UZRwak+abhO8VTeCBY1mRjUOJDDzSIQRv7o/XPkjHDfKKa5vTRIVCjRIGNXZE23Fgw63 M8RWRF0U3RqbgBwV9M2kAO4eNJlKoCq1UPveN0CoNLQEKeUt4S0KA2/TSNvjzSZu4PY2 qxHo39FlGWpCNIyyiq8UBhrH0aLGs5fcejcOsH3KSFrH1tI1Yt6z+Qzfm0vlCGWLia2T tMO5RWLIAmnJ7784A6rzFSsa3PzIu4c0IHYkCIgcDYTI4BTE7Nk2geJZSTOnlC2QcoBF DqDA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:cc:to:from:subject:message-id:mime-version:date :dkim-signature; bh=RFrxluOoy6twC+BtLwdF7yyyJ9Z+VqsYDm8spFvMc3o=; fh=JCPU5pmF5rAwjFhHLu3KoQR9dMjxzJUTO5pcc/zTQm0=; b=TyeASCD3Cy3fWZ+xMEeQfTHCnJahteiVPe4xjgGp6RaaIqMh1nK/+PolVBSUUL3Rwf PJBF9LXTZ+UXVfmzniT0XJD2HFXIS9Fy5PAETLCSHf5O3MZ8pMik8IgKp1IWB35hYuAY YSeptxdvC3E7kOY6J5AgKVMmqDHVxWJvgg0l3OKTeQ29w3asjP0zdFraRBaf9vPvth88 aZwtpKx9qRvMevC+CHzxFcRxiZtl06JuKopHbckmVo1lBr1vHvfhmfLM5S7LpJ4BOzIc uIsFIM0t92zXVgaSp/mEegwNbDxLDqalUchilZHYPekfpEH9Yrr3CVifV//JNpKSNK7K 7x4A== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20221208 header.b=KEeT3bwg; 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; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id ss15-20020a170907038f00b00991c46d0bb6si3856551ejb.93.2023.08.11.14.38.43; Fri, 11 Aug 2023 14:39:07 -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=@google.com header.s=20221208 header.b=KEeT3bwg; 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; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S235273AbjHKVT2 (ORCPT <rfc822;lanlanxiyiji@gmail.com> + 99 others); Fri, 11 Aug 2023 17:19:28 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:50710 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S234684AbjHKVT1 (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Fri, 11 Aug 2023 17:19:27 -0400 Received: from mail-yb1-xb4a.google.com (mail-yb1-xb4a.google.com [IPv6:2607:f8b0:4864:20::b4a]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 465101FED for <linux-kernel@vger.kernel.org>; Fri, 11 Aug 2023 14:19:26 -0700 (PDT) Received: by mail-yb1-xb4a.google.com with SMTP id 3f1490d57ef6-d67a458ff66so669911276.3 for <linux-kernel@vger.kernel.org>; Fri, 11 Aug 2023 14:19:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20221208; t=1691788765; x=1692393565; h=cc:to:from:subject:message-id:mime-version:date:from:to:cc:subject :date:message-id:reply-to; bh=RFrxluOoy6twC+BtLwdF7yyyJ9Z+VqsYDm8spFvMc3o=; b=KEeT3bwgLFy9nncUtsA1DUMJ+lw/0tWaAcyjIIb1nTbBe9h5TbDkdkoFdWj0klLLdY NjGjXqqFdce2YstjTQv4AXniOjzoMu28xyT5D4d0ahEoSsaQv2JPfHwpqA0NmS6hSaoj Ks8ws9d3oxBF4ffFqKww/GZSfMSB6ylltuLMG9B8Zg6oRBC7xMlGlNK4jl0ZbhOlbG98 etWolJ0AzSzpyRaHQuKDNmGQpHcuo17dYYBylyaUCsXRYpGHnXKDfJYQCid8aAq7N5vB /wlg08oiFa/ZVqNwZCHx7vqYFQ8UxrMpuYeUotCGkC4b8VLq5VoF7oCeCmmk9oSwMEZp Ds4Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1691788765; x=1692393565; h=cc:to:from:subject:message-id:mime-version:date:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=RFrxluOoy6twC+BtLwdF7yyyJ9Z+VqsYDm8spFvMc3o=; b=hiFuQZE9OEXtucTW6Gz+MQ0XTrx+DMhMJhQeKvrozTiyhFbTJF5ToUlYM5QvXoDxPy zgdGJBx5PrWOS7sc1/4a64ixAFfj+Bnl2aGLAmkk370naAIkj3oB4pU1ROGWu/hYcYjN bfFtpFdfMleOwm9PZ0cJGtF2rBa9qXdWvB9m0orHK/TaR6a0N2tZm7Z1t9WLvBfThi3k AQq/cT9MfqRZEHyStBfGUgp361y61XhpN0hnyY162+UfcoDJe0UZpGMxvqzOLKutk1wz S7aKwxQU6o9cgcOHf1vVyXlEt2QXINLJw0pEw6m/yZ8/PdglCMr4h08Et9ldfABI0ryv qAJg== X-Gm-Message-State: AOJu0YzIEJPAnWEetiObsRJ8CdXtRl13MSS6FCjgdN4z7e8Et/eiyv7E U5d0qr2Bgf9neOQAAr5fcIBPI+KAO7SRIfC2Hw== X-Received: from jstitt-linux1.c.googlers.com ([fda3:e722:ac3:cc00:2b:ff92:c0a8:23b5]) (user=justinstitt job=sendgmr) by 2002:a25:ad55:0:b0:d4d:8ade:4dfa with SMTP id l21-20020a25ad55000000b00d4d8ade4dfamr48994ybe.1.1691788765541; Fri, 11 Aug 2023 14:19:25 -0700 (PDT) Date: Fri, 11 Aug 2023 21:19:18 +0000 Mime-Version: 1.0 X-B4-Tracking: v=1; b=H4sIANal1mQC/x3NTQrCMBBA4auUWTvQpIg/W8EDuJUu0mRqBzQZZ opWSu9ucPlt3lvBSJkMzs0KSm82LrnC7RqIU8gPQk7V4FvftUfn0GbNUb4YNE4o5UMqEeUZ5rH oy1Csw/0huJgGH9JpgBoSpZGX/+QOt+sF+m37AXk5aSh5AAAA X-Developer-Key: i=justinstitt@google.com; a=ed25519; pk=tC3hNkJQTpNX/gLKxTNQKDmiQl6QjBNCGKJINqAdJsE= X-Developer-Signature: v=1; a=ed25519-sha256; t=1691788764; l=1075; i=justinstitt@google.com; s=20230717; h=from:subject:message-id; bh=UEYyh0BWz2Miih72wZBvRAC+rwc0jWuEQ2qNUTkM5XU=; b=Zlh1YTXz73wMqDpXUvsEhgcdl9DyMmUzchwKzmOb2URaBWyy4LBJQTuQT9BtWkgTvdP5uJxVy 20A8c1diBa9BvaWKvZttQDKCDc7IH26PulJT/j+2/N0g1J73S5NClwP X-Mailer: b4 0.12.3 Message-ID: <20230811-strncpy-arch-powerpc-platforms-ps3-v1-0-301052a5663e@google.com> Subject: [PATCH RFC 0/3] powerpc/ps3: refactor strncpy usage From: Justin Stitt <justinstitt@google.com> To: Geoff Levand <geoff@infradead.org>, Michael Ellerman <mpe@ellerman.id.au>, Nicholas Piggin <npiggin@gmail.com>, Christophe Leroy <christophe.leroy@csgroup.eu> Cc: linux-hardening@vger.kernel.org, Kees Cook <keescook@chromium.org>, Nick Desaulniers <ndesaulniers@google.com>, Nathan Chancellor <nathan@kernel.org>, linuxppc-dev@lists.ozlabs.org, linux-kernel@vger.kernel.org, Justin Stitt <justinstitt@google.com> Content-Type: text/plain; charset="utf-8" X-Spam-Status: No, score=-9.6 required=5.0 tests=BAYES_00,DKIMWL_WL_MED, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF, RCVD_IN_DNSWL_BLOCKED,SPF_HELO_NONE,SPF_PASS,USER_IN_DEF_DKIM_WL autolearn=ham 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: <linux-kernel.vger.kernel.org> X-Mailing-List: linux-kernel@vger.kernel.org X-getmail-retrieved-from-mailbox: INBOX X-GMAIL-THRID: 1773970336153209123 X-GMAIL-MSGID: 1773970336153209123 |
Series |
powerpc/ps3: refactor strncpy usage
|
|
Message
Justin Stitt
Aug. 11, 2023, 9:19 p.m. UTC
Within this RFC-series I want to get some comments on two ideas that I
have for refactoring the current `strncpy` usage in repository.c.
When looking at `make_first_field` we see a u64 is being used to store
up to 8 bytes from a literal string. This is slightly suspect to me but
it works? In regards to `strncpy` here, it makes the code needlessly
complex imo.
Please see my two ideas to change this and let me know if any other
approaches are more reasonable.
Link: https://github.com/KSPP/linux/issues/90
Signed-off-by: Justin Stitt <justinstitt@google.com>
---
Justin Stitt (3):
[RFC] powerpc/ps3: refactor strncpy usage attempt 1
[RFC] powerpc/ps3: refactor strncpy usage attempt 2
[RFC] powerpc/ps3: refactor strncpy usage attempt 2.5
arch/powerpc/platforms/ps3/repository.c | 7 +++----
1 file changed, 3 insertions(+), 4 deletions(-)
---
base-commit: 52a93d39b17dc7eb98b6aa3edb93943248e03b2f
change-id: 20230811-strncpy-arch-powerpc-platforms-ps3-57a1cdb2ad9b
Best regards,
--
Justin Stitt <justinstitt@google.com>
Comments
On Fri, Aug 11, 2023 at 2:19 PM Justin Stitt <justinstitt@google.com> wrote: > > Within this RFC-series I want to get some comments on two ideas that I > have for refactoring the current `strncpy` usage in repository.c. > > When looking at `make_first_field` we see a u64 is being used to store > up to 8 bytes from a literal string. This is slightly suspect to me but > it works? In regards to `strncpy` here, it makes the code needlessly > complex imo. > > Please see my two ideas to change this and let me know if any other > approaches are more reasonable. > > Link: https://github.com/KSPP/linux/issues/90 > Signed-off-by: Justin Stitt <justinstitt@google.com> > --- > Justin Stitt (3): > [RFC] powerpc/ps3: refactor strncpy usage attempt 1 > [RFC] powerpc/ps3: refactor strncpy usage attempt 2 > [RFC] powerpc/ps3: refactor strncpy usage attempt 2.5 Errhm, It looks like the diffs after attempt 1 came out poorly and probably won't apply cleanly because they were inter-diffed with the first patch. Is there a way to let b4 know I wanted each patch diff'd against the same SHA and not each other sequentially? As it stands only attempt 1 is readable. > > arch/powerpc/platforms/ps3/repository.c | 7 +++---- > 1 file changed, 3 insertions(+), 4 deletions(-) > --- > base-commit: 52a93d39b17dc7eb98b6aa3edb93943248e03b2f > change-id: 20230811-strncpy-arch-powerpc-platforms-ps3-57a1cdb2ad9b > > Best regards, > -- > Justin Stitt <justinstitt@google.com> >
Justin Stitt <justinstitt@google.com> writes: > On Fri, Aug 11, 2023 at 2:19 PM Justin Stitt <justinstitt@google.com> wrote: >> >> Within this RFC-series I want to get some comments on two ideas that I >> have for refactoring the current `strncpy` usage in repository.c. >> >> When looking at `make_first_field` we see a u64 is being used to store >> up to 8 bytes from a literal string. This is slightly suspect to me but >> it works? In regards to `strncpy` here, it makes the code needlessly >> complex imo. >> >> Please see my two ideas to change this and let me know if any other >> approaches are more reasonable. >> >> Link: https://github.com/KSPP/linux/issues/90 >> Signed-off-by: Justin Stitt <justinstitt@google.com> >> --- >> Justin Stitt (3): >> [RFC] powerpc/ps3: refactor strncpy usage attempt 1 >> [RFC] powerpc/ps3: refactor strncpy usage attempt 2 >> [RFC] powerpc/ps3: refactor strncpy usage attempt 2.5 > Errhm, It looks like the diffs after attempt 1 came out poorly and > probably won't apply cleanly because they were inter-diffed with the > first patch. Is there a way to let b4 know I wanted each patch diff'd > against the same SHA and not each other sequentially? I don't think there is. It always assumes they're a series. cheers