On 12/05/2018 02:24 PM, Will Deacon wrote: > On Wed, Dec 05, 2018 at 01:24:17PM +0100, Daniel Borkmann wrote: >> On 12/04/2018 04:45 PM, Ard Biesheuvel wrote: >>> On Mon, 3 Dec 2018 at 13:49, Will Deacon <will.dea...@arm.com> wrote: >>>> On Fri, Nov 30, 2018 at 08:20:06PM +0100, Ard Biesheuvel wrote: >>>>> On Fri, 30 Nov 2018 at 19:26, Will Deacon <will.dea...@arm.com> wrote: >>>>>> On Fri, Nov 23, 2018 at 11:18:04PM +0100, Ard Biesheuvel wrote: >>>>>>> diff --git a/arch/arm64/net/bpf_jit_comp.c >>>>>>> b/arch/arm64/net/bpf_jit_comp.c >>>>>>> index a6fdaea07c63..76c2ab40c02d 100644 >>>>>>> --- a/arch/arm64/net/bpf_jit_comp.c >>>>>>> +++ b/arch/arm64/net/bpf_jit_comp.c >>>>>>> @@ -940,3 +940,16 @@ struct bpf_prog *bpf_int_jit_compile(struct >>>>>>> bpf_prog *prog) >>>>>>> tmp : orig_prog); >>>>>>> return prog; >>>>>>> } >>>>>>> + >>>>>>> +void *bpf_jit_alloc_exec(unsigned long size) >>>>>>> +{ >>>>>>> + return __vmalloc_node_range(size, PAGE_SIZE, BPF_JIT_REGION_START, >>>>>>> + BPF_JIT_REGION_END, GFP_KERNEL, >>>>>>> + PAGE_KERNEL_EXEC, 0, NUMA_NO_NODE, >>>>>>> + __builtin_return_address(0)); >>>>>> >>>>>> I guess we'll want VM_IMMEDIATE_UNMAP here if Rich gets that merged. >>>>> >>>>> I think akpm already queued up that patch. >>>>> >>>>>> In the >>>>>> meantime, I wonder if it's worth zeroing the region in >>>>>> bpf_jit_free_exec()? >>>>>> (although we'd need the size information...). >>>>>> >>>>> >>>>> Not sure. What exactly would that achieve? >>>> >>>> I think the zero encoding is guaranteed to be undefined, so it would limit >>>> the usefulness of any stale, executable TLB entries. However, we'd also >>>> need >>>> cache maintenance to make that stuff visible to the I side, so it's >>>> probably >>>> not worth it, especially if akpm has queued the stuff from Rich. >>>> >>>> Maybe just add an: >>>> >>>> /* FIXME: Remove this when VM_IMMEDIATE_UNMAP is supported */ >>>> #ifndef VM_IMMEDIATE_UNMAP >>>> #define VM_IMMEDIATE_UNMAP 0 >>>> #endif >>>> >>>> so we remember to come back and sort this out? Up to you. >>> >>> I'll just make a note to send out that patch once the definition lands via >>> -akpm >> >> Could I get an ACK from you for this patch, then I'd take the series into >> bpf-next. > > Gah, thanks for the ping: I thought I acked this initially, but turns out I > didn't. > > Acked-by: Will Deacon <will.dea...@arm.com>
Applied, thanks everyone!