[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <878r7iiwb6.fsf@igel.home>
Date: Tue, 31 Oct 2023 17:35:57 +0100
From: Andreas Schwab <schwab@...ux-m68k.org>
To: Emil Renner Berthing <emil.renner.berthing@...onical.com>
Cc: Charlie Jenkins <charlie@...osinc.com>,
linux-riscv@...ts.infradead.org, linux-mm@...ck.org,
linux-kernel@...r.kernel.org,
Eric Biederman <ebiederm@...ssion.com>,
Kees Cook <keescook@...omium.org>,
Paul Walmsley <paul.walmsley@...ive.com>,
Palmer Dabbelt <palmer@...belt.com>,
Albert Ou <aou@...s.berkeley.edu>,
Samuel Holland <samuel.holland@...ive.com>,
Nelson Chu <nelson@...osinc.com>,
Emil Renner Berthing <kernel@...il.dk>
Subject: Re: [PATCH v7 1/3] riscv: Avoid unaligned access when relocating
modules
On Okt 31 2023, Emil Renner Berthing wrote:
>> +static int riscv_insn_rmw(void *location, u32 keep, u32 set)
>> +{
>> + u16 *parcel = location;
>> + u32 insn = (u32)le16_to_cpu(parcel[0]) | (u32)le16_to_cpu(parcel[1]) << 16;
>> +
>> + insn &= keep;
>> + insn |= set;
>> +
>> + parcel[0] = cpu_to_le32(insn);
>
> Why cpu_to_le32(insn)? Unless I've misunderstood something downcasting unsigned
> to unsigned values in C (eg. from u32 to u16) is defined to always discard the
> most signifcant bits, so cpu_to_le16(insn) should be fine.
cpu_to_le32(insn) can't be right here anyway, since it also swaps the
two u16 halves and would be the same as cpu_to_le16(insn >> 16) on big
endian.
--
Andreas Schwab, schwab@...ux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA AEC1
"And now for something completely different."
Powered by blists - more mailing lists