[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20200923002315.GC3421308@ZenIV.linux.org.uk>
Date: Wed, 23 Sep 2020 01:23:15 +0100
From: Al Viro <viro@...iv.linux.org.uk>
To: Guo Ren <guoren@...nel.org>
Cc: Zhenzhong Duan <zhenzhong.duan@...il.com>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
linux-csky@...r.kernel.org, Oleg Nesterov <oleg@...hat.com>
Subject: Re: [PATCH] csky: Fix a size determination in gpr_get()
On Wed, Sep 23, 2020 at 08:03:20AM +0800, Guo Ren wrote:
> Thx Duan,
>
> Acked-by: Guo Ren <guoren@...nel.org>
>
> Hi AI,
>
> I found the broken commit still has a question:
>
> > commit dcad7854fcce6a2d49b6a3ead5bbefeff047e559
> > Author: Al Viro <viro@...iv.linux.org.uk>
> > Date: Tue Jun 16 15:28:29 2020 -0400
>
> > csky: switch to ->regset_get()
>
> > NB: WTF "- what the fuck :(" is fpregs_get() playing at???
> The fpregs_get() is for REGSET_FPR regset used by ptrace (gdb) and all
> fp regs are stored in threads' context.
> So, WTF question for?
The part under
#if defined(CONFIG_CPU_HAS_FPUV2) && !defined(CONFIG_CPU_HAS_VDSP)
What's going on there? The mapping is really weird - assuming
you had v0..v31 in the first 32 elements of regs->vr[], you
end up with
v0 v1 v2 v3 v2 v3 v6 v7 v4 v5 v10 v11 v6 v7 v14 v15
v8 v9 v18 v19 v10 v11 v22 v23 v12 v13 v26 v27 v14 v15 v30 v31
in the beginning of the output. Assuming it is the intended
behaviour, it's probably worth some comments...
Powered by blists - more mailing lists