<feed xmlns='http://www.w3.org/2005/Atom'>
<title>kernel.git/arch/loongarch/lib, branch linux-6.15.y</title>
<subtitle>Hosts the 0x221E linux distro kernel.
</subtitle>
<id>https://git.0xinfinity.dev/distro/kernel.git/atom?h=linux-6.15.y</id>
<link rel='self' href='https://git.0xinfinity.dev/distro/kernel.git/atom?h=linux-6.15.y'/>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/'/>
<updated>2025-03-26T01:33:04Z</updated>
<entry>
<title>Merge tag 'crc-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/ebiggers/linux</title>
<updated>2025-03-26T01:33:04Z</updated>
<author>
<name>Linus Torvalds</name>
</author>
<published>2025-03-26T01:33:04Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=ee6740fd34eb53c5c76be01201c15310f461b69f'/>
<id>urn:sha1:ee6740fd34eb53c5c76be01201c15310f461b69f</id>
<content type='text'>
Pull CRC updates from Eric Biggers:
 "Another set of improvements to the kernel's CRC (cyclic redundancy
  check) code:

   - Rework the CRC64 library functions to be directly optimized, like
     what I did last cycle for the CRC32 and CRC-T10DIF library
     functions

   - Rewrite the x86 PCLMULQDQ-optimized CRC code, and add VPCLMULQDQ
     support and acceleration for crc64_be and crc64_nvme

   - Rewrite the riscv Zbc-optimized CRC code, and add acceleration for
     crc_t10dif, crc64_be, and crc64_nvme

   - Remove crc_t10dif and crc64_rocksoft from the crypto API, since
     they are no longer needed there

   - Rename crc64_rocksoft to crc64_nvme, as the old name was incorrect

   - Add kunit test cases for crc64_nvme and crc7

   - Eliminate redundant functions for calculating the Castagnoli CRC32,
     settling on just crc32c()

   - Remove unnecessary prompts from some of the CRC kconfig options

   - Further optimize the x86 crc32c code"

* tag 'crc-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/ebiggers/linux: (36 commits)
  x86/crc: drop the avx10_256 functions and rename avx10_512 to avx512
  lib/crc: remove unnecessary prompt for CONFIG_CRC64
  lib/crc: remove unnecessary prompt for CONFIG_LIBCRC32C
  lib/crc: remove unnecessary prompt for CONFIG_CRC8
  lib/crc: remove unnecessary prompt for CONFIG_CRC7
  lib/crc: remove unnecessary prompt for CONFIG_CRC4
  lib/crc7: unexport crc7_be_syndrome_table
  lib/crc_kunit.c: update comment in crc_benchmark()
  lib/crc_kunit.c: add test and benchmark for crc7_be()
  x86/crc32: optimize tail handling for crc32c short inputs
  riscv/crc64: add Zbc optimized CRC64 functions
  riscv/crc-t10dif: add Zbc optimized CRC-T10DIF function
  riscv/crc32: reimplement the CRC32 functions using new template
  riscv/crc: add "template" for Zbc optimized CRC functions
  x86/crc: add ANNOTATE_NOENDBR to suppress objtool warnings
  x86/crc32: improve crc32c_arch() code generation with clang
  x86/crc64: implement crc64_be and crc64_nvme using new template
  x86/crc-t10dif: implement crc_t10dif using new template
  x86/crc32: implement crc32_le using new template
  x86/crc: add "template" for [V]PCLMULQDQ based CRC functions
  ...
</content>
</entry>
<entry>
<title>LoongArch: csum: Fix OoB access in IP checksum code for negative lengths</title>
<updated>2025-02-13T04:02:40Z</updated>
<author>
<name>Yuli Wang</name>
</author>
<published>2025-02-13T04:02:40Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=6287f1a8c16138c2ec750953e35039634018c84a'/>
<id>urn:sha1:6287f1a8c16138c2ec750953e35039634018c84a</id>
<content type='text'>
Commit 69e3a6aa6be2 ("LoongArch: Add checksum optimization for 64-bit
system") would cause an undefined shift and an out-of-bounds read.

Commit 8bd795fedb84 ("arm64: csum: Fix OoB access in IP checksum code
for negative lengths") fixes the same issue on ARM64.

Fixes: 69e3a6aa6be2 ("LoongArch: Add checksum optimization for 64-bit system")
Co-developed-by: Wentao Guan &lt;guanwentao@uniontech.com&gt;
Signed-off-by: Wentao Guan &lt;guanwentao@uniontech.com&gt;
Signed-off-by: Yuli Wang &lt;wangyuli@uniontech.com&gt;
Signed-off-by: Huacai Chen &lt;chenhuacai@loongson.cn&gt;
</content>
</entry>
<entry>
<title>lib/crc32: remove "_le" from crc32c base and arch functions</title>
<updated>2025-02-09T04:06:30Z</updated>
<author>
<name>Eric Biggers</name>
</author>
<published>2025-02-08T02:49:11Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=68ea3c2ae0affe68aefab27d55c82be5a45ad882'/>
<id>urn:sha1:68ea3c2ae0affe68aefab27d55c82be5a45ad882</id>
<content type='text'>
Following the standardization on crc32c() as the lib entry point for the
Castagnoli CRC32 instead of the previous mix of crc32c(), crc32c_le(),
and __crc32c_le(), make the same change to the underlying base and arch
functions that implement it.

Reviewed-by: Ard Biesheuvel &lt;ardb@kernel.org&gt;
Link: https://lore.kernel.org/r/20250208024911.14936-7-ebiggers@kernel.org
Signed-off-by: Eric Biggers &lt;ebiggers@google.com&gt;
</content>
</entry>
<entry>
<title>loongarch/crc32: expose CRC32 functions through lib</title>
<updated>2024-12-02T01:23:01Z</updated>
<author>
<name>Eric Biggers</name>
</author>
<published>2024-12-02T01:08:31Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=72f51a4f4b076d2ea2751432dee07600aea4c4c4'/>
<id>urn:sha1:72f51a4f4b076d2ea2751432dee07600aea4c4c4</id>
<content type='text'>
Move the loongarch CRC32 assembly code into the lib directory and wire
it up to the library interface.  This allows it to be used without going
through the crypto API.  It remains usable via the crypto API too via
the shash algorithms that use the library interface.  Thus all the
arch-specific "shash" code becomes unnecessary and is removed.

Note: to see the diff from arch/loongarch/crypto/crc32-loongarch.c to
arch/loongarch/lib/crc32-loongarch.c, view this commit with
'git show -M10'.

Reviewed-by: Ard Biesheuvel &lt;ardb@kernel.org&gt;
Reviewed-by: WangYuli &lt;wangyuli@uniontech.com&gt;
Link: https://lore.kernel.org/r/20241202010844.144356-7-ebiggers@kernel.org
Signed-off-by: Eric Biggers &lt;ebiggers@google.com&gt;
</content>
</entry>
<entry>
<title>LoongArch: Select ARCH_SUPPORTS_INT128 if CC_HAS_INT128</title>
<updated>2024-05-14T04:24:18Z</updated>
<author>
<name>Xi Ruoyao</name>
</author>
<published>2024-05-14T04:24:18Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=5125d033c8af733ee4d52e3e3c6ebf5784976e46'/>
<id>urn:sha1:5125d033c8af733ee4d52e3e3c6ebf5784976e46</id>
<content type='text'>
This allows compiling a full 128-bit product of two 64-bit integers as a
mul/mulh pair, instead of a nasty long sequence of 20+ instructions.

However, after selecting ARCH_SUPPORTS_INT128, when optimizing for size
the compiler generates calls to __ashlti3, __ashrti3, and __lshrti3 for
shifting __int128 values, causing a link failure:

    loongarch64-unknown-linux-gnu-ld: kernel/sched/fair.o: in
    function `mul_u64_u32_shr':
    &lt;PATH&gt;/include/linux/math64.h:161:(.text+0x5e4): undefined
    reference to `__lshrti3'

So provide the implementation of these functions if ARCH_SUPPORTS_INT128.

Closes: https://lore.kernel.org/loongarch/CAAhV-H5EZ=7OF7CSiYyZ8_+wWuenpo=K2WT8-6mAT4CvzUC_4g@mail.gmail.com/
Signed-off-by: Xi Ruoyao &lt;xry111@xry111.site&gt;
Signed-off-by: Huacai Chen &lt;chenhuacai@loongson.cn&gt;
</content>
</entry>
<entry>
<title>LoongArch: Add ORC stack unwinder support</title>
<updated>2024-03-11T14:23:47Z</updated>
<author>
<name>Tiezhu Yang</name>
</author>
<published>2024-03-11T14:23:47Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=cb8a2ef0848ca80d67d6d56e2df757cfdf6b3355'/>
<id>urn:sha1:cb8a2ef0848ca80d67d6d56e2df757cfdf6b3355</id>
<content type='text'>
The kernel CONFIG_UNWINDER_ORC option enables the ORC unwinder, which is
similar in concept to a DWARF unwinder. The difference is that the format
of the ORC data is much simpler than DWARF, which in turn allows the ORC
unwinder to be much simpler and faster.

The ORC data consists of unwind tables which are generated by objtool.
After analyzing all the code paths of a .o file, it determines information
about the stack state at each instruction address in the file and outputs
that information to the .orc_unwind and .orc_unwind_ip sections.

The per-object ORC sections are combined at link time and are sorted and
post-processed at boot time. The unwinder uses the resulting data to
correlate instruction addresses with their stack states at run time.

Most of the logic are similar with x86, in order to get ra info before ra
is saved into stack, add ra_reg and ra_offset into orc_entry. At the same
time, modify some arch-specific code to silence the objtool warnings.

Co-developed-by: Jinyang He &lt;hejinyang@loongson.cn&gt;
Signed-off-by: Jinyang He &lt;hejinyang@loongson.cn&gt;
Co-developed-by: Youling Tang &lt;tangyouling@loongson.cn&gt;
Signed-off-by: Youling Tang &lt;tangyouling@loongson.cn&gt;
Signed-off-by: Tiezhu Yang &lt;yangtiezhu@loongson.cn&gt;
Signed-off-by: Huacai Chen &lt;chenhuacai@loongson.cn&gt;
</content>
</entry>
<entry>
<title>LoongArch: Add KASAN (Kernel Address Sanitizer) support</title>
<updated>2023-09-06T14:54:16Z</updated>
<author>
<name>Qing Zhang</name>
</author>
<published>2023-09-06T14:54:16Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=5aa4ac64e6add3e40d5049e31275b2822daf885d'/>
<id>urn:sha1:5aa4ac64e6add3e40d5049e31275b2822daf885d</id>
<content type='text'>
1/8 of kernel addresses reserved for shadow memory. But for LoongArch,
There are a lot of holes between different segments and valid address
space (256T available) is insufficient to map all these segments to kasan
shadow memory with the common formula provided by kasan core, saying
(addr &gt;&gt; KASAN_SHADOW_SCALE_SHIFT) + KASAN_SHADOW_OFFSET

So LoongArch has a arch-specific mapping formula, different segments are
mapped individually, and only limited space lengths of these specific
segments are mapped to shadow.

At early boot stage the whole shadow region populated with just one
physical page (kasan_early_shadow_page). Later, this page is reused as
readonly zero shadow for some memory that kasan currently don't track.
After mapping the physical memory, pages for shadow memory are allocated
and mapped.

Functions like memset()/memcpy()/memmove() do a lot of memory accesses.
If bad pointer passed to one of these function it is important to be
caught. Compiler's instrumentation cannot do this since these functions
are written in assembly.

KASan replaces memory functions with manually instrumented variants.
Original functions declared as weak symbols so strong definitions in
mm/kasan/kasan.c could replace them. Original functions have aliases
with '__' prefix in names, so we could call non-instrumented variant
if needed.

Signed-off-by: Qing Zhang &lt;zhangqing@loongson.cn&gt;
Signed-off-by: Huacai Chen &lt;chenhuacai@loongson.cn&gt;
</content>
</entry>
<entry>
<title>LoongArch: Add SIMD-optimized XOR routines</title>
<updated>2023-09-06T14:53:55Z</updated>
<author>
<name>WANG Xuerui</name>
</author>
<published>2023-09-06T14:53:55Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=75ded18a5e8e51ca2d26d55f010d60ae9aab652c'/>
<id>urn:sha1:75ded18a5e8e51ca2d26d55f010d60ae9aab652c</id>
<content type='text'>
Add LSX and LASX implementations of xor operations, operating on 64
bytes (one L1 cache line) at a time, for a balance between memory
utilization and instruction mix. Huacai confirmed that all future
LoongArch implementations by Loongson (that we care) will likely also
feature 64-byte cache lines, and experiments show no throughput
improvement with further unrolling.

Performance numbers measured during system boot on a 3A5000 @ 2.5GHz:

&gt; 8regs           : 12702 MB/sec
&gt; 8regs_prefetch  : 10920 MB/sec
&gt; 32regs          : 12686 MB/sec
&gt; 32regs_prefetch : 10918 MB/sec
&gt; lsx             : 17589 MB/sec
&gt; lasx            : 26116 MB/sec

Acked-by: Song Liu &lt;song@kernel.org&gt;
Signed-off-by: WANG Xuerui &lt;git@xen0n.name&gt;
Signed-off-by: Huacai Chen &lt;chenhuacai@loongson.cn&gt;
</content>
</entry>
<entry>
<title>LoongArch: Adjust {copy, clear}_user exception handler behavior</title>
<updated>2023-09-06T14:53:10Z</updated>
<author>
<name>Weihao Li</name>
</author>
<published>2023-09-06T14:53:10Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=937f65935950a0346292120acc5d98033f90e61c'/>
<id>urn:sha1:937f65935950a0346292120acc5d98033f90e61c</id>
<content type='text'>
The {copy, clear}_user function should returns number of bytes that
could not be {copied, cleared}. So, try to {copy, clear} byte by byte
when ld.{d,w,h} and st.{d,w,h} trapped into an exception.

Reviewed-by: WANG Rui &lt;wangrui@loongson.cn&gt;
Signed-off-by: Weihao Li &lt;liweihao@loongson.cn&gt;
Signed-off-by: Huacai Chen &lt;chenhuacai@loongson.cn&gt;
</content>
</entry>
<entry>
<title>LoongArch: Replace #include &lt;asm/export.h&gt; with #include &lt;linux/export.h&gt;</title>
<updated>2023-08-25T15:40:26Z</updated>
<author>
<name>Masahiro Yamada</name>
</author>
<published>2023-08-25T15:40:26Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=55b46ff9396caca6ebb73a1d5a00f6f8698391cc'/>
<id>urn:sha1:55b46ff9396caca6ebb73a1d5a00f6f8698391cc</id>
<content type='text'>
Commit ddb5cdbafaaad ("kbuild: generate KSYMTAB entries by modpost")
deprecated &lt;asm/export.h&gt;, which is now a wrapper of &lt;linux/export.h&gt;.

Replace #include &lt;asm/export.h&gt; with #include &lt;linux/export.h&gt;.

After all the &lt;asm/export.h&gt; lines are converted, &lt;asm/export.h&gt; and
&lt;asm-generic/export.h&gt; will be removed.

Signed-off-by: Masahiro Yamada &lt;masahiroy@kernel.org&gt;
Signed-off-by: Huacai Chen &lt;chenhuacai@loongson.cn&gt;
</content>
</entry>
</feed>
