Messages in this thread | | | From | "Edgecombe, Rick P" <> | Subject | Re: [PATCH v4 bpf 0/4] vmalloc: bpf: introduce VM_ALLOW_HUGE_VMAP | Date | Thu, 21 Apr 2022 15:47:21 +0000 |
| |
On Thu, 2022-04-21 at 18:57 +1000, Nicholas Piggin wrote: > Those were (AFAIKS) all in arch code though. The patch was the > fundamental issue for x86 because it had bugs.
This wasn't root caused to arch code: "BUG: Bad page state in process systemd-udevd"
https://lore.kernel.org/all/14444103-d51b-0fb3-ee63-c3f182f0b546@molgen.mpg.de/
In fact it wasn't root caused at all. But on the surface it seemed like it didn't have to do with virtual page size assumptions. I wonder if it might have to do with the vmalloc huge pages using compound pages, then some caller doing vmalloc_to_page() and getting surprised with what they could get away with in the struct page. But, regardless there was an assumption, not proven, that there was some lurking cross-arch issue that could show up for any vmalloc huge page user.
There is another good reason to opt-in to the current vmalloc huge page size implementation - vmalloc will round up to huge page size once the size exceeds the huge page size. Only the callers can know if the allocation is worth using extra memory for.
| |