[v1, 2/3] RISC-V: vector: export VLENB csr in __sc_riscv_v_state

Maciej W. Rozycki macro at orcam.me.uk
Thu Aug 17 05:35:43 PDT 2023


On Wed, 16 Aug 2023, Andy Chiu wrote:

> diff --git a/arch/riscv/include/uapi/asm/ptrace.h b/arch/riscv/include/uapi/asm/ptrace.h
> index e17c550986a6..283800130614 100644
> --- a/arch/riscv/include/uapi/asm/ptrace.h
> +++ b/arch/riscv/include/uapi/asm/ptrace.h
> @@ -97,6 +97,7 @@ struct __riscv_v_ext_state {
>  	unsigned long vl;
>  	unsigned long vtype;
>  	unsigned long vcsr;
> +	unsigned long vlenb;
>  	void *datap;

 I think we really ought to make a distinct structure holding the vector 
CSR state only, and then have it included as a leading member of a pair of 
other structures, one for the signal context with a trailing `datap' (or 
`vregp' or `vreg') member and another one for the regset with a flexible 
array member of the `char' type, e.g. (actual names TBD):

struct __riscv_v_csr_state {
	unsigned long vstart;
	unsigned long vl;
	unsigned long vtype;
	unsigned long vcsr;
	unsigned long vlenb;
};

struct __riscv_v_signal_state {
	struct __riscv_v_csr_state csr;
	void *vregp;
};

struct __riscv_v_regset_state {
	struct __riscv_v_csr_state csr;
	char vreg[];
};

This will make the API cleaner and avoid both UB with making accesses 
beyond the end of a structure and clutter with an unused entry in core 
files and data exchanged via ptrace(2).

 Since this is a part of the UAPI I suggest consulting with libc people, 
possibly by posting an RFC to <libc-alpha at sourceware.org>.

  Maciej



More information about the linux-riscv mailing list