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>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <ee754770889c7b6de13d8e4835c7bd8b15d5e538.camel@intel.com>
Date:   Tue, 29 Mar 2022 00:18:09 +0000
From:   "Edgecombe, Rick P" <rick.p.edgecombe@...el.com>
To:     "pmenzel@...gen.mpg.de" <pmenzel@...gen.mpg.de>,
        "songliubraving@...com" <songliubraving@...com>
CC:     "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "daniel@...earbox.net" <daniel@...earbox.net>,
        "peterz@...radead.org" <peterz@...radead.org>,
        "ast@...nel.org" <ast@...nel.org>,
        "bpf@...r.kernel.org" <bpf@...r.kernel.org>,
        "Kernel-team@...com" <Kernel-team@...com>,
        "song@...nel.org" <song@...nel.org>,
        "andrii@...nel.org" <andrii@...nel.org>,
        "x86@...nel.org" <x86@...nel.org>,
        "iii@...ux.ibm.com" <iii@...ux.ibm.com>,
        "netdev@...r.kernel.org" <netdev@...r.kernel.org>
Subject: Re: [PATCH v9 bpf-next 1/9] x86/Kconfig: select
 HAVE_ARCH_HUGE_VMALLOC with HAVE_ARCH_HUGE_VMAP

On Mon, 2022-03-28 at 23:27 +0000, Song Liu wrote:
> I like this direction. But I am afraid this is not enough. Using
> VM_NO_HUGE_VMAP in module_alloc() will make sure we don't allocate 
> huge pages for modules. But other users of __vmalloc_node_range(), 
> such as vzalloc in Paul's report, may still hit the issue. 
> 
> Maybe we need another flag VM_FORCE_HUGE_VMAP that bypasses 
> vmap_allow_huge check. Something like the diff below.
> 
> Would this work?

Yea, that looks like a safer direction. It's too bad we can't have
automatic large pages, but it doesn't seem ready to just turn on for
the whole x86 kernel.

I'm not sure about this implementation though. It would let large pages
get enabled without HAVE_ARCH_HUGE_VMALLOC and also despite the disable
kernel parameter.

Apparently some architectures can handle large pages automatically and
it has benefits for them, so maybe vmalloc should support both
behaviors based on config. Like there should a
ARCH_HUGE_VMALLOC_REQUIRE_FLAG config. If configured it requires
VM_HUGE_VMAP (or some name). I don't think FORCE fits, because the
current logic would not always give huge pages.

But yea, seems risky to leave it on generally, even if you could fix
Paul's specific issue.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ