Re: [External] Re: [patch 004/192] mm: hugetlb: free the vmemmap pages associated with each HugeTLB page

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Wed, Jun 30, 2021 at 11:30 PM Muchun Song <songmuchun@xxxxxxxxxxxxx> wrote:
>
> On Thu, Jul 1, 2021 at 11:46 AM Linus Torvalds
> <torvalds@xxxxxxxxxxxxxxxxxxxx> wrote:
> >
> > Anyway, this HugeTLB 'struct page' vmemmap patch-series doesn't look
> > _wrong_ to me, but it does look like it is a nightmare to debug if
> > something ever goes wrong. And it looks like a lot of things _could_
> > go wrong. It all looks very subtle.
>
> In order to make things work well, some addresses of vmemmap are
> also mapped with read only to catch invalid usage from other modules
> (e.g. write operation). I didn't get the point of "a lot of things _could_ go
> wrong". Would you like to describe the details? Thanks.

I just worry about the subtlety.

Things like "oh, now I can't free the page because I need allocations
for the mapping pages" is a very new condition for hugetlb pages.

And if the page table mapping ever gets out-of-sync, debugging it
sounds nightmarish. The real horror: missed TLB invalidates or things
like that, where even if the page tables themselves updated, the CPU
actually uses something else.

So I didn't see any bugs, but honestly, while I read through all the
patches that was really just that: "reading patches". I just want
people to be very ready to revert, because I suspect that any
potential bugs will just result in very subtle behavior problems.

                  Linus




[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Bugtraq]     [Linux OMAP]     [Linux MIPS]     [eCos]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux