* Re: [PATCH v2 bpf-next 0/2] enforce W^X for trampoline and dispatcher
[not found] <20220926184739.3512547-1-song@kernel.org>
@ 2022-09-28 9:42 ` Jesper Dangaard Brouer
2022-09-28 16:23 ` Song Liu
0 siblings, 1 reply; 2+ messages in thread
From: Jesper Dangaard Brouer @ 2022-09-28 9:42 UTC (permalink / raw)
To: Song Liu, bpf
Cc: brouer, ast, daniel, john.fastabend, kpsingh, kernel-team,
haoluo, jlayton, bjorn, Toke Hoiland Jorgensen, Clark Williams,
Steven Rostedt, Thomas Gleixner, Linux-MM
On 26/09/2022 20.47, Song Liu wrote:
> Changes v1 => v2:
> 1. Update arch_prepare_bpf_dispatcher to use a RO image and a RW buffer.
> (Alexei) Note: I haven't found an existing test to cover this part, so
> this part was tested manually (comparing the generated dispatcher is
> the same).
>
> Jeff Layton reported CPA W^X warning linux-next [1]. It turns out to be
> W^X issue with bpf trampoline and bpf dispatcher. Fix these by:
>
> 1. Use bpf_prog_pack for bpf_dispatcher;
> 2. Set memory permission properly with bpf trampoline.
Indirectly related to your patchset[0].
- TL;DR calling set_memory_x() have side-effects
We are getting reports that loading BPF-progs (jit stage) cause issues
for RT in the form of triggering work on isolated CPUs. It looks like
BTF JIT stage cause a TLB flush on all CPUs, including isolated CPUs.
The triggering function is set_memory_x() (see call-stack[2]).
We have noticed (and appreciate) you have previously improved the
situation in this patchset[3]:
[3]
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=80123f0ac4a6
Is this patchset also part of improving the situation, or does it
introduce more calls to set_memory_x() ?
> [1] https://lore.kernel.org/lkml/c84cc27c1a5031a003039748c3c099732a718aec.camel@kernel.org/
[2] Call stack triggering issue:
smp_call_function_many_cond+0x1
smp_call_function+0x39
on_each_cpu+0x2a
cpa_flush+0x11a
change_page_attr_set_clr+0x129
set_memory_x+0x37
bpf_int_jit_compile+0x36f
bpf_prog_select_runtime+0xc6
bpf_prepare_filter+0x523
sk_attach_filter+0x13
sock_setsockopt+0x920
__sys_setsockopt+0x16a
__x64_sys_setsockopt+0x20
do_syscall_64+0x87
entry_SYSCALL_64_after_hwframe+0x65
[0] https://lore.kernel.org/all/20220926184739.3512547-1-song@kernel.org/#r
--Jesper
^ permalink raw reply [flat|nested] 2+ messages in thread
* Re: [PATCH v2 bpf-next 0/2] enforce W^X for trampoline and dispatcher
2022-09-28 9:42 ` [PATCH v2 bpf-next 0/2] enforce W^X for trampoline and dispatcher Jesper Dangaard Brouer
@ 2022-09-28 16:23 ` Song Liu
0 siblings, 0 replies; 2+ messages in thread
From: Song Liu @ 2022-09-28 16:23 UTC (permalink / raw)
To: Jesper Dangaard Brouer
Cc: Song Liu, bpf, Jesper Dangaard Brouer, Alexei Starovoitov,
Daniel Borkmann, John Fastabend, KP Singh, Kernel Team, Hao Luo,
jlayton, Björn Töpel, Toke Hoiland Jorgensen,
Clark Williams, Steven Rostedt, Thomas Gleixner, Linux-MM
> On Sep 28, 2022, at 2:42 AM, Jesper Dangaard Brouer <jbrouer@redhat.com> wrote:
>
>
> On 26/09/2022 20.47, Song Liu wrote:
>> Changes v1 => v2:
>> 1. Update arch_prepare_bpf_dispatcher to use a RO image and a RW buffer.
>> (Alexei) Note: I haven't found an existing test to cover this part, so
>> this part was tested manually (comparing the generated dispatcher is
>> the same).
>> Jeff Layton reported CPA W^X warning linux-next [1]. It turns out to be
>> W^X issue with bpf trampoline and bpf dispatcher. Fix these by:
>> 1. Use bpf_prog_pack for bpf_dispatcher;
>> 2. Set memory permission properly with bpf trampoline.
>
> Indirectly related to your patchset[0].
> - TL;DR calling set_memory_x() have side-effects
>
> We are getting reports that loading BPF-progs (jit stage) cause issues for RT in the form of triggering work on isolated CPUs. It looks like BTF JIT stage cause a TLB flush on all CPUs, including isolated CPUs.
>
> The triggering function is set_memory_x() (see call-stack[2]).
>
> We have noticed (and appreciate) you have previously improved the situation in this patchset[3]:
> [3] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=80123f0ac4a6
>
> Is this patchset also part of improving the situation, or does it introduce more calls to set_memory_x() ?
This set doesn't change numbers of set_memory_x() calls for trampolines.
We plan to move trampolines to use bpf_prog_pack (or the new vmalloc_exec,
if I am lucky) in 6.2. We will see fewer set_memory_x() calls after that.
Thanks,
Song
>
>
>> [1] https://lore.kernel.org/lkml/c84cc27c1a5031a003039748c3c099732a718aec.camel@kernel.org/
>
>
> [2] Call stack triggering issue:
>
> smp_call_function_many_cond+0x1
> smp_call_function+0x39
> on_each_cpu+0x2a
> cpa_flush+0x11a
> change_page_attr_set_clr+0x129
> set_memory_x+0x37
> bpf_int_jit_compile+0x36f
> bpf_prog_select_runtime+0xc6
> bpf_prepare_filter+0x523
> sk_attach_filter+0x13
> sock_setsockopt+0x920
> __sys_setsockopt+0x16a
> __x64_sys_setsockopt+0x20
> do_syscall_64+0x87
> entry_SYSCALL_64_after_hwframe+0x65
>
>
> [0] https://lore.kernel.org/all/20220926184739.3512547-1-song@kernel.org/#r
>
> --Jesper
>
^ permalink raw reply [flat|nested] 2+ messages in thread
end of thread, other threads:[~2022-09-28 16:31 UTC | newest]
Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
[not found] <20220926184739.3512547-1-song@kernel.org>
2022-09-28 9:42 ` [PATCH v2 bpf-next 0/2] enforce W^X for trampoline and dispatcher Jesper Dangaard Brouer
2022-09-28 16:23 ` Song Liu
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox