Re: [RFC PATCH bpf-next v2 8/9] bpf: Add MEM_RDONLY for helper args that are pointers to rdonly mem.

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Mon, Nov 29, 2021 at 05:29:47PM -0800, Hao Luo wrote:
>  
> +
>  struct bpf_reg_types {
>  	const enum bpf_reg_type types[10];
>  	u32 *btf_id;
> +
> +	/* Certain types require customized type matching function. */
> +	bool (*type_match_fn)(enum bpf_arg_type arg_type,
> +			      enum bpf_reg_type type,
> +			      enum bpf_reg_type expected);
>  };
>  
>  static const struct bpf_reg_types map_key_value_types = {
> @@ -5013,6 +5019,19 @@ static const struct bpf_reg_types btf_id_sock_common_types = {
>  };
>  #endif
>  
> +static bool mem_type_match(enum bpf_arg_type arg_type,
> +			   enum bpf_reg_type type, enum bpf_reg_type expected)
> +{
> +	/* If arg_type is tagged with MEM_RDONLY, type is compatible with both
> +	 * RDONLY and RDWR mem, fold the MEM_RDONLY flag in 'type' before
> +	 * comparison.
> +	 */
> +	if ((arg_type & MEM_RDONLY) != 0)
> +		type &= ~MEM_RDONLY;
> +
> +	return type == expected;
> +}
> +
>  static const struct bpf_reg_types mem_types = {
>  	.types = {
>  		PTR_TO_STACK,
> @@ -5022,8 +5041,8 @@ static const struct bpf_reg_types mem_types = {
>  		PTR_TO_MAP_VALUE,
>  		PTR_TO_MEM,
>  		PTR_TO_BUF,
> -		PTR_TO_BUF | MEM_RDONLY,
>  	},
> +	.type_match_fn = mem_type_match,

why add a callback for this logic?
Isn't it a universal rule for MEM_RDONLY?



[Index of Archives]     [Linux Samsung SoC]     [Linux Rockchip SoC]     [Linux Actions SoC]     [Linux for Synopsys ARC Processors]     [Linux NFS]     [Linux NILFS]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]


  Powered by Linux