Re: [PATCH] mm: fix use-after free of page_ext after race with memory-offline

[Michal Hocko]

On Tue 19-07-22 20:42:42, Charan Teja Kalla wrote:
> Thanks Michal!!
> 
> On 7/18/2022 8:24 PM, Michal Hocko wrote:
[...]
> >>>> diff --git a/mm/page_ext.c b/mm/page_ext.c
> >>>> index 3dc715d..5ccd3ee 100644
> >>>> --- a/mm/page_ext.c
> >>>> +++ b/mm/page_ext.c
> >>>> @@ -299,8 +299,9 @@ static void __free_page_ext(unsigned long pfn)
> >>>>  	if (!ms || !ms->page_ext)
> >>>>  		return;
> >>>>  	base = get_entry(ms->page_ext, pfn);
> >>>> -	free_page_ext(base);
> >>>>  	ms->page_ext = NULL;
> >>>> +	synchronize_rcu();
> >>>> +	free_page_ext(base);
> >>>>  }
> >>> So you are imposing the RCU grace period for each page_ext! This can get
> >>> really expensive. Have you tried to measure the effect?
> > I was wrong here! This is for each memory section which is not as
> > terrible as every single page_ext. This can be still quite a lot memory
> > sections in a single memory block (e.g. on ppc memory sections are
> > ridiculously small).
> > 
> 
> On the ARM64, I see that the minimum a section size will go is 128MB. I
> think 16MB is the section size on ppc. Any inputs on how frequently
> offline/online operation is being done on this ppc arch?

I have seen several reports where 16MB sections were used on PPC LPARs
with a non trivial size. My usual answer to that is tha this is mostly a
self inflicted injury but I am told that for some reasons I cannot
udnerstand this is not easy to change. So reasonable or not this is not
all that uncommon in PPC land.

We definitely shouldn't optimize for those setups but we shouldn't make
them suffer even more as well. Besides that it seems that a single
rcu_synchronize per offline operation should be doable.
-- 
Michal Hocko
SUSE Labs