On Mon, Nov 23, 2020 at 8:18 PM Michal Hocko <mhocko@xxxxxxxx> wrote: > > On Mon 23-11-20 20:07:23, Muchun Song wrote: > > On Mon, Nov 23, 2020 at 7:32 PM Michal Hocko <mhocko@xxxxxxxx> wrote: > [...] > > > > > > > No I really mean that pfn_to_page will give you a struct page pointer > > > > > > > from pages which you release from the vmemmap page tables. Those pages > > > > > > > might get reused as soon sa they are freed to the page allocator. > > > > > > > > > > > > We will remap vmemmap pages 2-7 (virtual addresses) to page > > > > > > frame 1. And then we free page frame 2-7 to the buddy allocator. > > > > > > > > > > And this doesn't really happen in an atomic fashion from the pfn walker > > > > > POV, right? So it is very well possible that > > > > > > > > Yeah, you are right. But it may not be a problem for HugeTLB pages. > > > > Because in most cases, we only read the tail struct page and get the > > > > head struct page through compound_head() when the pfn is within > > > > a HugeTLB range. Right? > > > > > > Many pfn walkers would encounter the head page first and then skip over > > > the rest. Those should be reasonably safe. But there is no guarantee and > > > the fact that you need a valid page->compound_head which might get > > > scribbled over once you have the struct page makes this extremely > > > subtle. > > > > In this patch series, we can guarantee that the page->compound_head > > is always valid. Because we reuse the first tail page. Maybe you need to > > look closer at this series. Thanks. > > I must be really terrible exaplaining my concern. Let me try one last > time. It is really _irrelevant_ what you do with tail pages. The > underlying problem is that you are changing struct pages under users > without any synchronization. What used to be a valid struct page will > turn into garbage as soon as you remap vmemmap page tables. Thank you very much for your patient explanation. So if the pfn walkers always try get the head struct page through compound_head() when it encounter a tail struct page. There will be no concerns. Do you agree? > -- > Michal Hocko > SUSE Labs -- Yours, Muchun
