Re: [PATCH 1/2] lib/crc: loongarch: Use hardware unaligned load in CRC32(C) loops

[Huacai Chen]

Hi, Eric and Wentao,

On Sun, Oct 11, 2026 at 11:14 PM Wentao Guan <guanwentao@xxxxxxxxxxxxx> wrote:
>
> > On Sun, Oct 11, 2026 at 10:29:29PM +0800, Huacai Chen wrote:
> > > +static inline u32 get_le32(const void *p)
> > > +{
> > > + if (static_branch_likely(&have_ual))
> > > + return *((__le32 *)p);
> > > + else
> > > + return get_unaligned_le32(p);
> > > +}
> >
> > No, this is just broken.  The bare misaligned access is undefined
> > behavior in C.  Also, every other use of {get,put}_unaligned_* in the
> > kernel would need this; it is not specific to the CRC code.  Also, it is
> Right, I got your thought. It not belong to CRC level.
>
> > inefficient to compile both code paths into the binary.
> >
> > The only way that realistically works, as we know from the other
> > architectures, is for the unaligned access support to be known at
> > compile time, and to have {get,put}_unaligned_* do the right thing
> > accordingly.
> So the optimize it can be move to {get,put}_unaligned_* code?
Yes, we considered modifying {get,put}_unaligned_* globally. But it is
not arch-specific code and we have no way to override it.

On the other hand, the byte-to-byte {get,put}_unaligned_* is always
correct, we are free to only optimise the hot path (like crc32 code).

>
> >
> > Since loongarch made the incorrect decision to not specify unaligned
> > access unconditionally, similar to RISC-V it can be worked around only
> > by overriding that in the kconfig.  For loongarch that appears that
> > already be implemented; just unset CONFIG_ARCH_STRICT_ALIGN when you
> > know the kernel will run only on CPUs that have fixed this bug.
> I think that we have the use cases to provide the general kernel instead of the two kernel with
> different config, so the image increase will be tolerated.
Yes, the default configuration is to keep CONFIG_ARCH_STRICT_ALIGN set
for single kernel binary.

Huacai

>
> BRs
> Wentao Guan