[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <8CDB95C6-91FB-4F6D-82E1-61F6132A2DE1@netronome.com>
Date: Thu, 11 Apr 2019 07:02:44 +0100
From: Jiong Wang <jiong.wang@...ronome.com>
To: Jakub Kicinski <jakub.kicinski@...ronome.com>
Cc: alexei.starovoitov@...il.com, daniel@...earbox.net,
bpf@...r.kernel.org, netdev@...r.kernel.org,
oss-drivers@...ronome.com
Subject: Re: [PATCH/RFC v2 bpf-next 06/19] bpf: mark lo32 writes that should
be zero extended into hi32
> On 11 Apr 2019, at 04:13, Jakub Kicinski <jakub.kicinski@...ronome.com> wrote:
>
> On Wed, 10 Apr 2019 20:50:20 +0100, Jiong Wang wrote:
>> @@ -2169,6 +2188,12 @@ static int check_mem_access(struct bpf_verifier_env *env, int insn_idx, u32 regn
>> value_regno);
>> if (reg_type_may_be_null(reg_type))
>> regs[value_regno].id = ++env->id_gen;
>> + /* A load of ctx field could have different
>> + * actual load size with the one encoded in the
>> + * insn. When the dst is PTR, it is for sure not
>> + * a sub-register.
>> + */
>> + regs[value_regno].subreg_def = DEF_NOT_SUBREG;
>
> Can't the rewrite generate a 32bit load? E.g. reading skb->len will be
> LDX | W, we still gotta clear the top bits in that case, no?
No. for 32-bit load, I think the type won’t be ptr type. This override is
gated by !SCALAR_VALUE.
Regards,
Jiong
>
> I can't find the explanation of this case with a quick scan of the code
> and cover letter..
>
>> }
>> regs[value_regno].type = reg_type;
>> }
>
Powered by blists - more mailing lists