linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
* 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