Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
IronPort-SDR: E6xkxJhAvk9IlxlmmSNdZvH60YJz0d86nUEb+WOlVOVOWlmPoC1UU1Z7TvxOeXJ7whK45egdpJ
 mZfBUXqp2OA3qVlY+oVog6Ouusc80hYpMzTCg+q1x7LPlnO7rKVD9lkmQUrOfmX2Ve8NxS5kWm
 3+O1Weph0AMGPrwFAZo1JxFn7vopuVLZjr3kn9CxlpPrVxqalFOGB4I1BFyvJ0rij95RRKknlc
 4tnj3cgA2cF08C2Jrhor8mVUMydx3dTDcblT76YB9dY4OKsVo5TQNMJ/iuC7HbUAGM+szMz2Cx
 SR4=
IronPort-SDR: IdIlcPUalfm/E3xDxAJnovdA1QJlRREpBk3ZaOD4vPpIxTIfYPQ/TrBqH5v1IZyPLH7Ot5Hsgj
 MSVAd6M7mz/vKe12i5bB53cZ9xXT/Rk8E=
IronPort-SDR: jN5CtwZpnd+5N/goMHUWZJYQbmHItg8c2A91kwQxZACRbomktFOQsOgxQ5XD6qEzTP31o6d/nC
 A3tRmg5flFsg==
WDCIronportException: Internal
Date:   Fri, 24 Jul 2020 00:22:15 +0100 (BST)
From:   "Maciej W. Rozycki" <macro@wdc.com>
To:     linux-riscv@lists.infradead.org
cc:     Paul Walmsley <paul.walmsley@sifive.com>,
        Palmer Dabbelt <palmer@dabbelt.com>,
        Albert Ou <aou@eecs.berkeley.edu>,
        linux-kernel@vger.kernel.org, stable@vger.kernel.org
Subject: [PATCH 1/2] riscv: ptrace: Use the correct API for `fcsr' access
In-Reply-To: <alpine.LFD.2.21.2007232038170.24175@redsun52.ssa.fujisawa.hgst.com>
Message-ID: <alpine.DEB.2.20.2007232213510.4462@tpp.orcam.me.uk>
References: <alpine.LFD.2.21.2007232038170.24175@redsun52.ssa.fujisawa.hgst.com>
User-Agent: Alpine 2.21 (LFD 202 2017-01-01)
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

Adjust the calls to `user_regset_copyout' and `user_regset_copyin' in 
`riscv_fpr_get' and `riscv_fpr_set' respectively so as to use @start_pos 
and @end_pos according to API documentation in <linux/regset.h>, that is 
to point at the beginning and the end respectively of the data chunk to 
be copied.  Update @data accordingly, also for the first call, to make 
it clear which structure member is accessed.

We currently have @start_pos fixed at 0 across all calls, which works as 
a result of the implementation, in particular because we have no padding 
between the FP general registers and the FP control and status register, 
but appears not to have been the intent of the API and is not what other 
ports do, requiring one to study the copy handlers to understand what is 
going on here.

Signed-off-by: Maciej W. Rozycki <macro@wdc.com>
Fixes: b8c8a9590e4f ("RISC-V: Add FP register ptrace support for gdb.")
Cc: stable@vger.kernel.org # 4.20+
---
 arch/riscv/kernel/ptrace.c |   14 ++++++++++----
 1 file changed, 10 insertions(+), 4 deletions(-)

linux-riscv-ptrace-fcsr.diff
Index: linux-hv/arch/riscv/kernel/ptrace.c
===================================================================
--- linux-hv.orig/arch/riscv/kernel/ptrace.c
+++ linux-hv/arch/riscv/kernel/ptrace.c
@@ -61,10 +61,13 @@ static int riscv_fpr_get(struct task_str
 	int ret;
 	struct __riscv_d_ext_state *fstate = &target->thread.fstate;
 
-	ret = user_regset_copyout(&pos, &count, &kbuf, &ubuf, fstate, 0,
+	ret = user_regset_copyout(&pos, &count, &kbuf, &ubuf, &fstate->f, 0,
 				  offsetof(struct __riscv_d_ext_state, fcsr));
 	if (!ret) {
-		ret = user_regset_copyout(&pos, &count, &kbuf, &ubuf, fstate, 0,
+		ret = user_regset_copyout(&pos, &count, &kbuf, &ubuf,
+					  &fstate->fcsr,
+					  offsetof(struct __riscv_d_ext_state,
+						   fcsr),
 					  offsetof(struct __riscv_d_ext_state, fcsr) +
 					  sizeof(fstate->fcsr));
 	}
@@ -80,10 +83,13 @@ static int riscv_fpr_set(struct task_str
 	int ret;
 	struct __riscv_d_ext_state *fstate = &target->thread.fstate;
 
-	ret = user_regset_copyin(&pos, &count, &kbuf, &ubuf, fstate, 0,
+	ret = user_regset_copyin(&pos, &count, &kbuf, &ubuf, &fstate->f, 0,
 				 offsetof(struct __riscv_d_ext_state, fcsr));
 	if (!ret) {
-		ret = user_regset_copyin(&pos, &count, &kbuf, &ubuf, fstate, 0,
+		ret = user_regset_copyin(&pos, &count, &kbuf, &ubuf,
+					 &fstate->fcsr,
+					 offsetof(struct __riscv_d_ext_state,
+						  fcsr),
 					 offsetof(struct __riscv_d_ext_state, fcsr) +
 					 sizeof(fstate->fcsr));
 	}