linux-kernel - Re: [PATCH 3/4] LoongArch: Add stacktrace support

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAAhV-H61ZXvF2xvXsyrxRYj6impet0w83svkt94FUhJhzj-2EQ@mail.gmail.com>
Date:   Tue, 2 Aug 2022 09:30:21 +0800
From:   Huacai Chen <chenhuacai@...nel.org>
To:     zhangqing <zhangqing@...ngson.cn>
Cc:     WANG Xuerui <kernel@...0n.name>, loongarch@...ts.linux.dev,
        LKML <linux-kernel@...r.kernel.org>,
        Jiaxun Yang <jiaxun.yang@...goat.com>,
        Jinyang He <hejinyang@...ngson.cn>
Subject: Re: [PATCH 3/4] LoongArch: Add stacktrace support

Hi, Qing,

On Tue, Aug 2, 2022 at 9:20 AM zhangqing <zhangqing@...ngson.cn> wrote:
>
>
>
> On 2022/8/1 下午11:30, Huacai Chen wrote:
> > Hi, Qing,
> >
> > On Mon, Aug 1, 2022 at 8:17 PM Qing Zhang <zhangqing@...ngson.cn> wrote:
> >>
> >> Use common arch_stack_walk infrastructure to avoid duplicated code and
> >> avoid taking care of the stack storage and filtering.
> >> Add sra (means __schedule return address) and scfa (means __schedule call
> >> frame address) to thread_info and store it in switch_to().
> >>
> >> Now we can print the process stack by cat /proc/*/stack and can better
> >> support ftrace.
> >>
> >> Signed-off-by: Qing Zhang <zhangqing@...ngson.cn>
> >> ---
> >>   arch/loongarch/Kconfig                 |  5 ++++
> >>   arch/loongarch/include/asm/processor.h |  9 +++++++
> >>   arch/loongarch/include/asm/switch_to.h | 14 ++++++----
> >>   arch/loongarch/include/asm/uaccess.h   |  4 +--
> >>   arch/loongarch/kernel/Makefile         |  1 +
> >>   arch/loongarch/kernel/asm-offsets.c    |  2 ++
> >>   arch/loongarch/kernel/process.c        |  3 +++
> >>   arch/loongarch/kernel/stacktrace.c     | 37 ++++++++++++++++++++++++++
> >>   arch/loongarch/kernel/switch.S         |  2 ++
> >>   9 files changed, 70 insertions(+), 7 deletions(-)
> >>   create mode 100644 arch/loongarch/kernel/stacktrace.c
> >>
> >> diff --git a/arch/loongarch/include/asm/uaccess.h b/arch/loongarch/include/asm/uaccess.h
> >> index 2b44edc604a2..a8ae2af4025a 100644
> >> --- a/arch/loongarch/include/asm/uaccess.h
> >> +++ b/arch/loongarch/include/asm/uaccess.h
> >> @@ -229,13 +229,13 @@ extern unsigned long __copy_user(void *to, const void *from, __kernel_size_t n);
> >>   static inline unsigned long __must_check
> >>   raw_copy_from_user(void *to, const void __user *from, unsigned long n)
> >>   {
> >> -       return __copy_user(to, from, n);
> >> +       return __copy_user(to, (__force const void *)from, n);
> >>   }
> >>
> >>   static inline unsigned long __must_check
> >>   raw_copy_to_user(void __user *to, const void *from, unsigned long n)
> >>   {
> >> -       return __copy_user(to, from, n);
> >> +       return __copy_user((__force void *)to, from, n);
> > Why this? Does it have something to do with stacktrace?
> >
> > Huacai
>
> Hi, huacai
>
> This is kernel test robot report sparse warnings:
> I reproduced locally and found that other architectures calling
> __copy_user also use __force conversion, Is this modification appropriate?
>
> kernel/trace/trace_events_user.c: note: in included file (through
> include/linux/uaccess.h, include/linux/sched/task.h,
> include/linux/sched/signal.h, ...):
>     arch/loongarch/include/asm/uaccess.h:232:32: sparse: sparse:
> incorrect type in argument 2 (different address spaces) @@     expected
> void const *from @@     got void const [noderef] __user *from @@
>     arch/loongarch/include/asm/uaccess.h:232:32: sparse:     expected
> void const *from
>     arch/loongarch/include/asm/uaccess.h:232:32: sparse:     got void
> const [noderef] __user *from
The modification might be correct, but should it be in this patch?

Huacai
>
> Thanks,
> -Qing
>
>
>