2023-09-08 18:21:37

by Huacai Chen

[permalink] [raw]
Subject: [GIT PULL] LoongArch changes for v6.6

The following changes since commit 2dde18cd1d8fac735875f2e4987f11817cc0bc2c:

Linux 6.5 (2023-08-27 14:49:51 -0700)

are available in the Git repository at:

git://git.kernel.org/pub/scm/linux/kernel/git/chenhuacai/linux-loongson.git tags/loongarch-6.6

for you to fetch changes up to 671eae93ae2090d2df01d810d354cab05f6bed8b:

LoongArch: Update Loongson-3 default config file (2023-09-07 12:06:20 +0800)

----------------------------------------------------------------
LoongArch changes for v6.6

1, Allow usage of LSX/LASX in the kernel;
2, Add SIMD-optimized RAID5/RAID6 routines;
3, Add Loongson Binary Translation (LBT) extension support;
4, Add basic KGDB & KDB support;
5, Add building with kcov coverage;
6, Add KFENCE (Kernel Electric-Fence) support;
7, Add KASAN (Kernel Address Sanitizer) support;
8, Some bug fixes and other small changes;
9, Update the default config file.

Note: There is a conflicts in arch/loongarch/mm/pgtable.c but can be
simply fixed by adjusting context.

----------------------------------------------------------------
Bibo Mao (3):
LoongArch: Code improvements in function pcpu_populate_pte()
LoongArch: mm: Introduce unified function populate_kernel_pte()
LoongArch: Use static defined zero page rather than allocated

Enze Li (4):
kfence: Defer the assignment of the local variable addr
LoongArch: mm: Add page table mapped mode support for virt_to_page()
LoongArch: Get partial stack information when providing regs parameter
LoongArch: Add KFENCE (Kernel Electric-Fence) support

Feiyang Chen (2):
LoongArch: Provide kaslr_offset() to get kernel offset
LoongArch: Allow building with kcov coverage

Hongchen Zhang (1):
LoongArch: mm: Add p?d_leaf() definitions

Huacai Chen (4):
Merge tag 'md-next-20230814-resend' into loongarch-next
LoongArch: Remove shm_align_mask and use SHMLBA instead
LoongArch: Allow usage of LSX/LASX in the kernel
LoongArch: Update Loongson-3 default config file

Nathan Chancellor (1):
LoongArch: Drop unused parse_r and parse_v macros

Qi Hu (1):
LoongArch: Add Loongson Binary Translation (LBT) extension support

Qing Zhang (5):
LoongArch: Add basic KGDB & KDB support
kasan: Add __HAVE_ARCH_SHADOW_MAP to support arch specific mapping
kasan: Add (pmd|pud)_init for LoongArch zero_(pud|p4d)_populate process
LoongArch: Simplify the processing of jumping new kernel for KASLR
LoongArch: Add KASAN (Kernel Address Sanitizer) support

Tiezhu Yang (1):
LoongArch: Define symbol 'fault' as a local label in fpu.S

WANG Xuerui (3):
LoongArch: Add SIMD-optimized XOR routines
raid6: Add LoongArch SIMD syndrome calculation
raid6: Add LoongArch SIMD recovery implementation

Weihao Li (1):
LoongArch: Adjust {copy, clear}_user exception handler behavior

Documentation/dev-tools/kasan.rst | 4 +-
.../features/debug/KASAN/arch-support.txt | 2 +-
Documentation/features/debug/kcov/arch-support.txt | 2 +-
Documentation/features/debug/kgdb/arch-support.txt | 2 +-
.../translations/zh_CN/dev-tools/kasan.rst | 2 +-
arch/loongarch/Kconfig | 26 +
arch/loongarch/Makefile | 3 +
arch/loongarch/configs/loongson3_defconfig | 74 ++-
arch/loongarch/include/asm/asm-prototypes.h | 1 +
arch/loongarch/include/asm/asmmacro.h | 158 ++---
arch/loongarch/include/asm/kasan.h | 126 ++++
arch/loongarch/include/asm/kfence.h | 61 ++
arch/loongarch/include/asm/kgdb.h | 97 +++
arch/loongarch/include/asm/lbt.h | 109 +++
arch/loongarch/include/asm/loongarch.h | 47 +-
arch/loongarch/include/asm/mmzone.h | 2 -
arch/loongarch/include/asm/page.h | 7 +-
arch/loongarch/include/asm/pgalloc.h | 1 +
arch/loongarch/include/asm/pgtable.h | 31 +-
arch/loongarch/include/asm/processor.h | 26 +-
arch/loongarch/include/asm/setup.h | 8 +-
arch/loongarch/include/asm/stackframe.h | 4 +
arch/loongarch/include/asm/string.h | 20 +
arch/loongarch/include/asm/switch_to.h | 2 +
arch/loongarch/include/asm/thread_info.h | 4 +
arch/loongarch/include/asm/xor.h | 68 ++
arch/loongarch/include/asm/xor_simd.h | 34 +
arch/loongarch/include/uapi/asm/ptrace.h | 6 +
arch/loongarch/include/uapi/asm/sigcontext.h | 10 +
arch/loongarch/kernel/Makefile | 9 +
arch/loongarch/kernel/asm-offsets.c | 18 +-
arch/loongarch/kernel/cpu-probe.c | 14 +
arch/loongarch/kernel/entry.S | 5 +
arch/loongarch/kernel/fpu.S | 14 +-
arch/loongarch/kernel/head.S | 13 +-
arch/loongarch/kernel/kfpu.c | 55 +-
arch/loongarch/kernel/kgdb.c | 727 +++++++++++++++++++++
arch/loongarch/kernel/lbt.S | 155 +++++
arch/loongarch/kernel/numa.c | 35 +-
arch/loongarch/kernel/process.c | 15 +-
arch/loongarch/kernel/ptrace.c | 54 ++
arch/loongarch/kernel/relocate.c | 8 +-
arch/loongarch/kernel/setup.c | 4 +
arch/loongarch/kernel/signal.c | 188 ++++++
arch/loongarch/kernel/stacktrace.c | 18 +-
arch/loongarch/kernel/traps.c | 50 +-
arch/loongarch/lib/Makefile | 2 +
arch/loongarch/lib/clear_user.S | 87 +--
arch/loongarch/lib/copy_user.S | 161 ++---
arch/loongarch/lib/memcpy.S | 8 +-
arch/loongarch/lib/memmove.S | 20 +-
arch/loongarch/lib/memset.S | 8 +-
arch/loongarch/lib/xor_simd.c | 93 +++
arch/loongarch/lib/xor_simd.h | 38 ++
arch/loongarch/lib/xor_simd_glue.c | 72 ++
arch/loongarch/lib/xor_template.c | 110 ++++
arch/loongarch/mm/Makefile | 3 +
arch/loongarch/mm/cache.c | 1 -
arch/loongarch/mm/fault.c | 22 +-
arch/loongarch/mm/init.c | 71 +-
arch/loongarch/mm/kasan_init.c | 243 +++++++
arch/loongarch/mm/mmap.c | 13 +-
arch/loongarch/mm/pgtable.c | 12 +
arch/loongarch/vdso/Makefile | 3 +
include/linux/kasan.h | 2 +
include/linux/raid/pq.h | 4 +
lib/raid6/Makefile | 1 +
lib/raid6/algos.c | 16 +
lib/raid6/loongarch.h | 38 ++
lib/raid6/loongarch_simd.c | 422 ++++++++++++
lib/raid6/recov_loongarch_simd.c | 513 +++++++++++++++
lib/raid6/test/Makefile | 12 +
mm/kasan/init.c | 18 +-
mm/kasan/kasan.h | 6 +
mm/kfence/core.c | 5 +-
75 files changed, 3862 insertions(+), 461 deletions(-)
create mode 100644 arch/loongarch/include/asm/kasan.h
create mode 100644 arch/loongarch/include/asm/kfence.h
create mode 100644 arch/loongarch/include/asm/kgdb.h
create mode 100644 arch/loongarch/include/asm/lbt.h
create mode 100644 arch/loongarch/include/asm/xor.h
create mode 100644 arch/loongarch/include/asm/xor_simd.h
create mode 100644 arch/loongarch/kernel/kgdb.c
create mode 100644 arch/loongarch/kernel/lbt.S
create mode 100644 arch/loongarch/lib/xor_simd.c
create mode 100644 arch/loongarch/lib/xor_simd.h
create mode 100644 arch/loongarch/lib/xor_simd_glue.c
create mode 100644 arch/loongarch/lib/xor_template.c
create mode 100644 arch/loongarch/mm/kasan_init.c
create mode 100644 lib/raid6/loongarch.h
create mode 100644 lib/raid6/loongarch_simd.c
create mode 100644 lib/raid6/recov_loongarch_simd.c


2023-09-08 22:24:43

by pr-tracker-bot

[permalink] [raw]
Subject: Re: [GIT PULL] LoongArch changes for v6.6

The pull request you sent on Fri, 8 Sep 2023 19:10:53 +0800:

> git://git.kernel.org/pub/scm/linux/kernel/git/chenhuacai/linux-loongson.git tags/loongarch-6.6

has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/12952b6bbd36b372345f179f1a85576c5924d425

Thank you!

--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/prtracker.html

2023-09-08 23:51:00

by Linus Torvalds

[permalink] [raw]
Subject: Re: [GIT PULL] LoongArch changes for v6.6

On Fri, 8 Sept 2023 at 04:11, Huacai Chen <[email protected]> wrote:
>
> 7, Add KASAN (Kernel Address Sanitizer) support

I have pulled this, but please at least consider

(a) don't use the stupid and random __HAVE_ARCH_xyz defines

Yes, yes, we have historical uses of it. That doesn't make it good.
Instead of making up new random symbol names, just *USE* the names you
are defining per architecture.

IOW, instead of doing

#define __HAVE_ARCH_SHADOW_MAP

and defining your own helper replacement functions for
kasan_mem_to_shadow() etc, just use those names as-is.

So if you have an architecture that has its own version of
"kasan_mem_to_shadow()", then use *THAT* name for the #ifdef too.
Don't make up another name entirely of the form "__HAVE_ARCH_xyz".

Example: architectures can override the default generic versions of
"arch_atomic_xyz()" operations, and the way you do that is (for
example)

static __always_inline int arch_atomic_add_return(int i, atomic_t *v)
{
return i + xadd(&v->counter, i);
}
#define arch_atomic_add_return arch_atomic_add_return

note how the define to let you know the name exists is the name itself
(and because the implementation is an inline function, not the macro,
the marker is then just a "define the name to itself").

End result: no made-up secondary names for other things. When you grep
for the thing that is used, you find both the implementation and the
marker for "look, I am overriding it".

And also

(b) do you really want to inline those kasan_mem_to_shadow() and
kasan_shadow_to_mem() things?

Yes, the caller is addr_has_metadata(), and that one is
"__always_inline",. because otherwise objtool would complain about
doing function calls in SMAP-enabled regions.

HOWEVER:

- on LoongArch, I don't think you have that objtool / SMAP issue

- and if you did, the function should be __always_inline, not just
plain inline anyway

so I get the feeling that the inline is simply wrong either way. Maybe
that function should just be declared, with the implementation being
out-of-line? It seems unnecessarily big to be an inline function, and
it doesn't seem performance-critical?

Neither of the above issues are critical, and the second one in
particular really is just a "did you really mean to do that" kind of
reaction, but since I was looking at this, I decided to write up my
reactions.

Linus

2023-09-09 21:55:22

by Huacai Chen

[permalink] [raw]
Subject: Re: [GIT PULL] LoongArch changes for v6.6

Hi, Linus,

On Sat, Sep 9, 2023 at 3:48 AM Linus Torvalds
<[email protected]> wrote:
>
> On Fri, 8 Sept 2023 at 04:11, Huacai Chen <[email protected]> wrote:
> >
> > 7, Add KASAN (Kernel Address Sanitizer) support
>
> I have pulled this, but please at least consider
>
> (a) don't use the stupid and random __HAVE_ARCH_xyz defines
>
> Yes, yes, we have historical uses of it. That doesn't make it good.
> Instead of making up new random symbol names, just *USE* the names you
> are defining per architecture.
>
> IOW, instead of doing
>
> #define __HAVE_ARCH_SHADOW_MAP
>
> and defining your own helper replacement functions for
> kasan_mem_to_shadow() etc, just use those names as-is.
>
> So if you have an architecture that has its own version of
> "kasan_mem_to_shadow()", then use *THAT* name for the #ifdef too.
> Don't make up another name entirely of the form "__HAVE_ARCH_xyz".
>
> Example: architectures can override the default generic versions of
> "arch_atomic_xyz()" operations, and the way you do that is (for
> example)
>
> static __always_inline int arch_atomic_add_return(int i, atomic_t *v)
> {
> return i + xadd(&v->counter, i);
> }
> #define arch_atomic_add_return arch_atomic_add_return
>
> note how the define to let you know the name exists is the name itself
> (and because the implementation is an inline function, not the macro,
> the marker is then just a "define the name to itself").
>
> End result: no made-up secondary names for other things. When you grep
> for the thing that is used, you find both the implementation and the
> marker for "look, I am overriding it".
>
> And also
>
> (b) do you really want to inline those kasan_mem_to_shadow() and
> kasan_shadow_to_mem() things?
>
> Yes, the caller is addr_has_metadata(), and that one is
> "__always_inline",. because otherwise objtool would complain about
> doing function calls in SMAP-enabled regions.
>
> HOWEVER:
>
> - on LoongArch, I don't think you have that objtool / SMAP issue
>
> - and if you did, the function should be __always_inline, not just
> plain inline anyway
>
> so I get the feeling that the inline is simply wrong either way. Maybe
> that function should just be declared, with the implementation being
> out-of-line? It seems unnecessarily big to be an inline function, and
> it doesn't seem performance-critical?
>
> Neither of the above issues are critical, and the second one in
> particular really is just a "did you really mean to do that" kind of
> reaction, but since I was looking at this, I decided to write up my
> reactions.
Thank you for your suggestions, I will make cleanup patches for the
two issues before v6.6 is released.

Huacai
>
> Linus
>