lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <93209b12-9117-484a-908a-5b138fa2ffb0@huaweicloud.com>
Date: Thu, 1 Feb 2024 20:10:13 +0800
From: Pu Lehui <pulehui@...weicloud.com>
To: Björn Töpel <bjorn@...nel.org>, bpf@...r.kernel.org,
 linux-riscv@...ts.infradead.org, netdev@...r.kernel.org
Cc: Song Liu <song@...nel.org>, Alexei Starovoitov <ast@...nel.org>,
 Daniel Borkmann <daniel@...earbox.net>, Andrii Nakryiko <andrii@...nel.org>,
 Martin KaFai Lau <martin.lau@...ux.dev>, Eduard Zingerman
 <eddyz87@...il.com>, Yonghong Song <yhs@...com>,
 John Fastabend <john.fastabend@...il.com>, KP Singh <kpsingh@...nel.org>,
 Stanislav Fomichev <sdf@...gle.com>, Hao Luo <haoluo@...gle.com>,
 Jiri Olsa <jolsa@...nel.org>, Palmer Dabbelt <palmer@...belt.com>,
 Luke Nelson <luke.r.nels@...il.com>, Pu Lehui <pulehui@...wei.com>
Subject: Re: [PATCH bpf-next v2 4/4] riscv, bpf: Mixing bpf2bpf and tailcalls



On 2024/2/1 18:10, Björn Töpel wrote:
> Pu Lehui <pulehui@...weicloud.com> writes:
> 
>>>> @@ -252,10 +220,7 @@ static void __build_epilogue(bool is_tail_call, struct rv_jit_context *ctx)
>>>>    		emit_ld(RV_REG_S5, store_offset, RV_REG_SP, ctx);
>>>>    		store_offset -= 8;
>>>>    	}
>>>> -	if (seen_reg(RV_REG_S6, ctx)) {
>>>> -		emit_ld(RV_REG_S6, store_offset, RV_REG_SP, ctx);
>>>> -		store_offset -= 8;
>>>> -	}
>>>> +	emit_ld(RV_REG_TCC, store_offset, RV_REG_SP, ctx);
>>>
>>> Why do you need to restore RV_REG_TCC? We're passing RV_REG_TCC (a6) as
>>> an argument at all call-sites, and for tailcalls we're loading from the
>>> stack.
>>>
>>> Is this to fake the a6 argument for the tail-call? If so, it's better to
>>> move it to emit_bpf_tail_call(), instead of letting all programs pay for
>>> it.
>>
>> Yes, we can remove this duplicate load. will do that at next version.
> 
> Hmm, no remove, but *move* right? Otherwise a6 can contain gargabe on
> entering the tailcall?
> 
> Move it before __emit_epilogue() in the tailcall, no?
> 

IIUC, we don't need to load it again. In emit_bpf_tail_call function, we 
load TCC from stack to A6, A6--, then store A6 back to stack. Then 
unwind the current stack and jump to target bpf prog, during this 
period, we did not touch the A6 register, do we still need to load it again?

> 
> Björn


Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ