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: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [day] [month] [year] [list]
Message-ID: <dd21cf251b519685e2d3b204b8c48746b93dc264.camel@intel.com>
Date:   Fri, 17 Jun 2022 23:05:24 +0000
From:   "Edgecombe, Rick P" <rick.p.edgecombe@...el.com>
To:     "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "linux-mm@...ck.org" <linux-mm@...ck.org>,
        "song@...nel.org" <song@...nel.org>,
        "bpf@...r.kernel.org" <bpf@...r.kernel.org>
CC:     "daniel@...earbox.net" <daniel@...earbox.net>,
        "Torvalds, Linus" <torvalds@...ux-foundation.org>,
        "peterz@...radead.org" <peterz@...radead.org>,
        "kernel-team@...com" <kernel-team@...com>,
        "ast@...nel.org" <ast@...nel.org>,
        "mcgrof@...nel.org" <mcgrof@...nel.org>
Subject: Re: [PATCH v4 bpf-next 5/8] bpf: use module_alloc_huge for
 bpf_prog_pack

On Fri, 2022-05-20 at 16:57 -0700, Song Liu wrote:
> Use module_alloc_huge for bpf_prog_pack so that BPF programs sit on
> PMD_SIZE pages. This benefits system performance by reducing iTLB
> miss
> rate. Benchmark of a real web service workload shows this change
> gives
> another ~0.2% performance boost on top of PAGE_SIZE bpf_prog_pack
> (which improve system throughput by ~0.5%).
> 
> Also, remove set_vm_flush_reset_perms() from alloc_new_pack() and use
> set_memory_[nx|rw] in bpf_prog_pack_free(). This is because
> VM_FLUSH_RESET_PERMS does not work with huge pages yet. [1]
> 
> [1] 
> https://lore.kernel.org/bpf/aeeeaf0b7ec63fdba55d4834d2f524d8bf05b71b.camel@intel.com/
> Suggested-by: Rick Edgecombe <rick.p.edgecombe@...el.com>
> Signed-off-by: Song Liu <song@...nel.org>

Hi,

Per request, just wanted to make it clear I'm personally on board with
side-stepping VM_FLUSH_RESET_PERMS here because the way things are
headed it may change anyway, and this already does a better job at
minimizing eBPF JIT kernel shootdowns than VM_FLUSH_RESET_PERMS did
when it was introduced. The warning added in the other patch will
prevent accidents like the first version of the series. So that aspect
seems ok to me.

In general I think this series still needs more x86/mm scrutiny though.

Thanks,

Rick

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ