On Thu, Apr 21, 2022 at 6:51 PM Nicholas Piggin <npiggin@xxxxxxxxx> wrote: > > > See > > > > https://lore.kernel.org/all/20220415164413.2727220-3-song@xxxxxxxxxx/ > > > > for [PATCH 2/4] in the series for this particular issue. > > I was being facetious. The problem is you can't do ^ because x86 is > buggy. No, we probably *can* do that PATCH 2/4. I suspect x86 really isn't that buggy. The bugs are elsewhere (including other vmalloc_huge() uses). Really. Why can't you just admit that the major bug was in the hugepage code itself? You claim: > Because it can be transparent. The bug was (stupidly) using compound > pages when it should have just used split higher order pages. but we're in -rc3 for 5.18, and you seem to be entirely ignoring the fact that that stupid bug has been around for a *YEAR* now. Guess what? It was reported within *days* of the code having been enabled on x86. But for about a year, youv'e been convinced that powerpc is fine, because nobody ever reported it. And you *still* try to make this about how it's some "x86 bug", despite that bug not having been x86-specific AT ALL. Nick, please take a long look at yourself in the mirror. And stop this whole mindless "it's x86". The *ONLY* thing x86-64 did was to show that the code that had been enabled on powerpc for a year had gotten almost no testing there. And don't bother mentioning s390. It got even less coverage there. So exactly *because* bugs were uncovered in days by x86 enabling this, I'm not rushing to re-enable it until I think it's gone through more thinking and testing. And in particular, I really *really* want to limit the fallout. For example, your "two-liner fix" is not at all obvious. That broken code case used to have a comment that remap_vmalloc_page() required compound pages, and you just removed that whole thing as if it didn't matter, and split the page. (I also think the comment meant 'vmap_pages_range()', but whatever). And the thing is, I'm not entirely convinced that comment was wrong and could just be ignored. The freeing code in __vunmap() will do int i, step = 1U << page_order; for (i = 0; i < area->nr_pages; i += step) { struct page *page = area->pages[i]; BUG_ON(!page); mod_memcg_page_state(page, MEMCG_VMALLOC, -step); __free_pages(page, page_order); which now looks VERY VERY wrong. You've split the pages, they may be used as individual pages (possibly by other things), and then you now at freeing time treat them as a single compound page after all.. So your "trivial two-liner" that tried to fix a bug that has been there for a year now, itself seems quite questionable. Maybe it works, maybe it doesn't. My bet is "it doesn't". And guess what? I bet it worked just fine in your testing on powerpc, because you probably didn't actually have any real huge-page vmalloc cases except for those filesystem big-hash cases that never get free'd. So that "this code was completely buggy for a year on powerpc" never seemed to teach you anything about the code. And again - none of this is at all x86-specific. NOT AT ALL. So how about you admit you were wrong to begin with. That hugepage code needs more care before we re-enable it. Your two-liner wasn't so obvious after all, was it? I really think we're much safer saying "hugepage mappings only matter for a couple of things, and those things will *not* do sub-page games, so it's simple and safe". .. and that requires that opt-in model. Because your "it's transparent" argument has never ever actually been true, now has it? Linus
