[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <87cyzperg1.fsf@mail.lhotse>
Date: Mon, 14 Aug 2023 22:31:10 +1000
From: Michael Ellerman <mpe@...erman.id.au>
To: Justin Stitt <justinstitt@...gle.com>,
Geoff Levand <geoff@...radead.org>,
Nicholas Piggin <npiggin@...il.com>,
Christophe Leroy <christophe.leroy@...roup.eu>
Cc: linux-hardening@...r.kernel.org, Kees Cook <keescook@...omium.org>,
Nick Desaulniers <ndesaulniers@...gle.com>,
Nathan Chancellor <nathan@...nel.org>,
linuxppc-dev@...ts.ozlabs.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH RFC 0/3] powerpc/ps3: refactor strncpy usage
Justin Stitt <justinstitt@...gle.com> writes:
> On Fri, Aug 11, 2023 at 2:19 PM Justin Stitt <justinstitt@...gle.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@...gle.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
Powered by blists - more mailing lists