[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <f0678e11-dd59-2e9b-56d5-cb28a20ffac7@huawei.com>
Date: Thu, 20 Jun 2024 17:58:11 +0800
From: "Liao, Chang" <liaochang1@...wei.com>
To: Oleg Nesterov <oleg@...hat.com>
CC: <jolsa@...nel.org>, <rostedt@...dmis.org>, <mhiramat@...nel.org>,
<ast@...nel.org>, <daniel@...earbox.net>, <andrii@...nel.org>,
<nathan@...nel.org>, <peterz@...radead.org>, <mingo@...hat.com>,
<mark.rutland@....com>, <linux-perf-users@...r.kernel.org>,
<linux-kernel@...r.kernel.org>, <bpf@...r.kernel.org>
Subject: Re: [PATCH bpf-next] uprobes: Fix the xol slots reserved for
uretprobe trampoline
在 2024/6/20 16:36, Oleg Nesterov 写道:
> On 06/20, Liao, Chang wrote:
>>
>> However, when i asm porting uretprobe trampoline to arm64
>> to explore its benefits on that architecture, i discovered the problem that
>> single slot is not large enought for trampoline code.
>
> Ah, but then I'd suggest to make the changelog more clear. It looks as
> if the problem was introduced by the patch from Jiri. Note that we was
> confused as well ;)
Perhaps i should use 'RFC' in the subject line, instead of 'PATCH'?
>
> And,
>
> + /* Reserve enough slots for the uretprobe trampoline */
> + for (slot_nr = 0;
> + slot_nr < max((insns_size / UPROBE_XOL_SLOT_BYTES), 1);
> + slot_nr++)
>
> this doesn't look right. Just suppose that insns_size = UPROBE_XOL_SLOT_BYTES + 1.
> I'd suggest DIV_ROUND_UP(insns_size, UPROBE_XOL_SLOT_BYTES).
Oh, what a stupid mistake to me. thanks for pointing that out.
>
> And perhaps it would be better to send this change along with
> uretprobe_trampoline_for_arm64 ?
Sure, i would send them out in next revision.
>
> Oleg.
>
--
BR
Liao, Chang
Powered by blists - more mailing lists