Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
MIME-Version: 1.0
References: <20220801121726.9681-1-zhangqing@loongson.cn> <20220801121726.9681-4-zhangqing@loongson.cn>
 <CAAhV-H6Az_X1afvAO+JxnDaW-Ey_8wmozehd++qOZoGmimM+6g@mail.gmail.com> <3cc6aebc-87e7-f0d0-2a88-e7e742e1e5ee@loongson.cn>
In-Reply-To: <3cc6aebc-87e7-f0d0-2a88-e7e742e1e5ee@loongson.cn>
From:   Huacai Chen <chenhuacai@kernel.org>
Date:   Tue, 2 Aug 2022 09:30:21 +0800
Message-ID: <CAAhV-H61ZXvF2xvXsyrxRYj6impet0w83svkt94FUhJhzj-2EQ@mail.gmail.com>
Subject: Re: [PATCH 3/4] LoongArch: Add stacktrace support
To:     zhangqing <zhangqing@loongson.cn>
Cc:     WANG Xuerui <kernel@xen0n.name>, loongarch@lists.linux.dev,
        LKML <linux-kernel@vger.kernel.org>,
        Jiaxun Yang <jiaxun.yang@flygoat.com>,
        Jinyang He <hejinyang@loongson.cn>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Precedence: bulk

Hi, Qing,

On Tue, Aug 2, 2022 at 9:20 AM zhangqing <zhangqing@loongson.cn> wrote:
>
>
>
> On 2022/8/1 =E4=B8=8B=E5=8D=8811:30, Huacai Chen wrote:
> > Hi, Qing,
> >
> > On Mon, Aug 1, 2022 at 8:17 PM Qing Zhang <zhangqing@loongson.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 c=
all
> >> 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@loongson.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/inc=
lude/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
>
>
>