Re: [PATCH 03/11] x86/mm/hotplug: Don't remove PGD entries in remove_pagetable()

[Andy Lutomirski]

On Thu, Mar 10, 2016 at 1:56 AM, Ingo Molnar  wrote:
>
> * Andy Lutomirski  wrote:
>
>> On Fri, Feb 12, 2016 at 11:04 AM, Andy Lutomirski  
>> wrote:
>> > On Mon, Sep 21, 2015 at 11:23 PM, Ingo Molnar  wrote:
>> >> So when memory hotplug removes a piece of physical memory from pagetable
>> >> mappings, it also frees the underlying PGD entry.
>> >>
>> >> This complicates PGD management, so don't do this. We can keep the
>> >> PGD mapped and the PUD table all clear - it's only a single 4K page
>> >> per 512 GB of memory hotplugged.
>> >
>> > Ressurecting an ancient thread: I want this particular change to make
>> > it (much) easier to make vmapped stacks work correctly.  Could it be
>> > applied by itself?
>> >
>>
>> It's incomplete.  pageattr.c has another instance of the same thing.
>> I'll see if I can make it work, but I may end up doing something a
>> little different.
>
> If so then mind picking up (and fixing ;-) tip:WIP.x86/mm in its entirety? 
> It's
> well tested so shouldn't have too many easy to hit bugs. Feel free to rebase 
> and
> restructure it, it's a WIP tree.

I'll chew on this one patch a bit and see where the whole things go.
If I can rebase the rest on top, I'll use them.

BTW, how are current kernels possibly correct when this code runs?  We
zap a pgd from the init pgd.  I can't find any code that would try to
propagate that zapped pgd to other pgds.  Then, if we hotplug in some
more memory or claim the slot for vmap, we'll install a new pgd entry,
and we might access *that* through a different pgd.  There vmalloc
fault fixup won't help because the MMU will chase a stale pointer in
the old pgd.

So we might actually need this patch sooner rather than later.

>
> I keep getting distracted with other things but I'd hate if this got dropped 
> on
> the floor.
>
> Thanks,
>
> Ingo



-- 
Andy Lutomirski
AMA Capital Management, LLC

Re: [PATCH 03/11] x86/mm/hotplug: Don't remove PGD entries in remove_pagetable()

[Andy Lutomirski]

On Thu, Mar 10, 2016 at 1:56 AM, Ingo Molnar  wrote:
>
> * Andy Lutomirski  wrote:
>
>> On Fri, Feb 12, 2016 at 11:04 AM, Andy Lutomirski  
>> wrote:
>> > On Mon, Sep 21, 2015 at 11:23 PM, Ingo Molnar  wrote:
>> >> So when memory hotplug removes a piece of physical memory from pagetable
>> >> mappings, it also frees the underlying PGD entry.
>> >>
>> >> This complicates PGD management, so don't do this. We can keep the
>> >> PGD mapped and the PUD table all clear - it's only a single 4K page
>> >> per 512 GB of memory hotplugged.
>> >
>> > Ressurecting an ancient thread: I want this particular change to make
>> > it (much) easier to make vmapped stacks work correctly.  Could it be
>> > applied by itself?
>> >
>>
>> It's incomplete.  pageattr.c has another instance of the same thing.
>> I'll see if I can make it work, but I may end up doing something a
>> little different.
>
> If so then mind picking up (and fixing ;-) tip:WIP.x86/mm in its entirety? 
> It's
> well tested so shouldn't have too many easy to hit bugs. Feel free to rebase 
> and
> restructure it, it's a WIP tree.

I'll chew on this one patch a bit and see where the whole things go.
If I can rebase the rest on top, I'll use them.

BTW, how are current kernels possibly correct when this code runs?  We
zap a pgd from the init pgd.  I can't find any code that would try to
propagate that zapped pgd to other pgds.  Then, if we hotplug in some
more memory or claim the slot for vmap, we'll install a new pgd entry,
and we might access *that* through a different pgd.  There vmalloc
fault fixup won't help because the MMU will chase a stale pointer in
the old pgd.

So we might actually need this patch sooner rather than later.

>
> I keep getting distracted with other things but I'd hate if this got dropped 
> on
> the floor.
>
> Thanks,
>
> Ingo



-- 
Andy Lutomirski
AMA Capital Management, LLC

Re: [PATCH 03/11] x86/mm/hotplug: Don't remove PGD entries in remove_pagetable()

[Ingo Molnar]

* Andy Lutomirski  wrote:

> On Fri, Feb 12, 2016 at 11:04 AM, Andy Lutomirski  wrote:
> > On Mon, Sep 21, 2015 at 11:23 PM, Ingo Molnar  wrote:
> >> So when memory hotplug removes a piece of physical memory from pagetable
> >> mappings, it also frees the underlying PGD entry.
> >>
> >> This complicates PGD management, so don't do this. We can keep the
> >> PGD mapped and the PUD table all clear - it's only a single 4K page
> >> per 512 GB of memory hotplugged.
> >
> > Ressurecting an ancient thread: I want this particular change to make
> > it (much) easier to make vmapped stacks work correctly.  Could it be
> > applied by itself?
> >
> 
> It's incomplete.  pageattr.c has another instance of the same thing.
> I'll see if I can make it work, but I may end up doing something a
> little different.

If so then mind picking up (and fixing ;-) tip:WIP.x86/mm in its entirety? It's 
well tested so shouldn't have too many easy to hit bugs. Feel free to rebase 
and 
restructure it, it's a WIP tree.

I keep getting distracted with other things but I'd hate if this got dropped on 
the floor.

Thanks,

Ingo

Re: [PATCH 03/11] x86/mm/hotplug: Don't remove PGD entries in remove_pagetable()

[Ingo Molnar]

* Andy Lutomirski  wrote:

> On Fri, Feb 12, 2016 at 11:04 AM, Andy Lutomirski  wrote:
> > On Mon, Sep 21, 2015 at 11:23 PM, Ingo Molnar  wrote:
> >> So when memory hotplug removes a piece of physical memory from pagetable
> >> mappings, it also frees the underlying PGD entry.
> >>
> >> This complicates PGD management, so don't do this. We can keep the
> >> PGD mapped and the PUD table all clear - it's only a single 4K page
> >> per 512 GB of memory hotplugged.
> >
> > Ressurecting an ancient thread: I want this particular change to make
> > it (much) easier to make vmapped stacks work correctly.  Could it be
> > applied by itself?
> >
> 
> It's incomplete.  pageattr.c has another instance of the same thing.
> I'll see if I can make it work, but I may end up doing something a
> little different.

If so then mind picking up (and fixing ;-) tip:WIP.x86/mm in its entirety? It's 
well tested so shouldn't have too many easy to hit bugs. Feel free to rebase 
and 
restructure it, it's a WIP tree.

I keep getting distracted with other things but I'd hate if this got dropped on 
the floor.

Thanks,

Ingo

Re: [PATCH 03/11] x86/mm/hotplug: Don't remove PGD entries in remove_pagetable()

[Andy Lutomirski]

On Fri, Feb 12, 2016 at 11:04 AM, Andy Lutomirski  wrote:
> On Mon, Sep 21, 2015 at 11:23 PM, Ingo Molnar  wrote:
>> So when memory hotplug removes a piece of physical memory from pagetable
>> mappings, it also frees the underlying PGD entry.
>>
>> This complicates PGD management, so don't do this. We can keep the
>> PGD mapped and the PUD table all clear - it's only a single 4K page
>> per 512 GB of memory hotplugged.
>
> Ressurecting an ancient thread: I want this particular change to make
> it (much) easier to make vmapped stacks work correctly.  Could it be
> applied by itself?
>

It's incomplete.  pageattr.c has another instance of the same thing.
I'll see if I can make it work, but I may end up doing something a
little different.

--Andy

-- 
Andy Lutomirski
AMA Capital Management, LLC

Re: [PATCH 03/11] x86/mm/hotplug: Don't remove PGD entries in remove_pagetable()

[Andy Lutomirski]

On Fri, Feb 12, 2016 at 11:04 AM, Andy Lutomirski  wrote:
> On Mon, Sep 21, 2015 at 11:23 PM, Ingo Molnar  wrote:
>> So when memory hotplug removes a piece of physical memory from pagetable
>> mappings, it also frees the underlying PGD entry.
>>
>> This complicates PGD management, so don't do this. We can keep the
>> PGD mapped and the PUD table all clear - it's only a single 4K page
>> per 512 GB of memory hotplugged.
>
> Ressurecting an ancient thread: I want this particular change to make
> it (much) easier to make vmapped stacks work correctly.  Could it be
> applied by itself?
>

It's incomplete.  pageattr.c has another instance of the same thing.
I'll see if I can make it work, but I may end up doing something a
little different.

--Andy

-- 
Andy Lutomirski
AMA Capital Management, LLC

Re: [PATCH 03/11] x86/mm/hotplug: Don't remove PGD entries in remove_pagetable()

[Andy Lutomirski]

On Mon, Sep 21, 2015 at 11:23 PM, Ingo Molnar  wrote:
> So when memory hotplug removes a piece of physical memory from pagetable
> mappings, it also frees the underlying PGD entry.
>
> This complicates PGD management, so don't do this. We can keep the
> PGD mapped and the PUD table all clear - it's only a single 4K page
> per 512 GB of memory hotplugged.

Ressurecting an ancient thread: I want this particular change to make
it (much) easier to make vmapped stacks work correctly.  Could it be
applied by itself?

--Andy

Re: [PATCH 03/11] x86/mm/hotplug: Don't remove PGD entries in remove_pagetable()

[Andy Lutomirski]

On Mon, Sep 21, 2015 at 11:23 PM, Ingo Molnar  wrote:
> So when memory hotplug removes a piece of physical memory from pagetable
> mappings, it also frees the underlying PGD entry.
>
> This complicates PGD management, so don't do this. We can keep the
> PGD mapped and the PUD table all clear - it's only a single 4K page
> per 512 GB of memory hotplugged.

Ressurecting an ancient thread: I want this particular change to make
it (much) easier to make vmapped stacks work correctly.  Could it be
applied by itself?

--Andy

Re: [PATCH 03/11] x86/mm/hotplug: Don't remove PGD entries in remove_pagetable()

[Kamezawa Hiroyuki]

On 2015/09/22 15:23, Ingo Molnar wrote:
> So when memory hotplug removes a piece of physical memory from pagetable
> mappings, it also frees the underlying PGD entry.
> 
> This complicates PGD management, so don't do this. We can keep the
> PGD mapped and the PUD table all clear - it's only a single 4K page
> per 512 GB of memory hotplugged.
> 
> Cc: Andrew Morton 
> Cc: Andy Lutomirski 
> Cc: Borislav Petkov 
> Cc: Brian Gerst 
> Cc: Denys Vlasenko 
> Cc: H. Peter Anvin 
> Cc: Linus Torvalds 
> Cc: Oleg Nesterov 
> Cc: Peter Zijlstra 
> Cc: Rik van Riel 
> Cc: Thomas Gleixner 
> Cc: Waiman Long 
> Cc: linux...@kvack.org
> Signed-off-by: Ingo Molnar 

Ishimatsu-san, Tang-san, please check.

Doesn't this patch affects the issues of 
 5255e0a79fcc0ff47b387af92bd9ef5729b1b859
 9661d5bcd058fe15b4138a00d96bd36516134543

?

-Kame

> ---
>   arch/x86/mm/init_64.c | 27 ---
>   1 file changed, 27 deletions(-)
> 
> diff --git a/arch/x86/mm/init_64.c b/arch/x86/mm/init_64.c
> index 7129e7647a76..60b0cc3f2819 100644
> --- a/arch/x86/mm/init_64.c
> +++ b/arch/x86/mm/init_64.c
> @@ -780,27 +780,6 @@ static void __meminit free_pmd_table(pmd_t *pmd_start, 
> pud_t *pud)
>   spin_unlock(_mm.page_table_lock);
>   }
>   
> -/* Return true if pgd is changed, otherwise return false. */
> -static bool __meminit free_pud_table(pud_t *pud_start, pgd_t *pgd)
> -{
> - pud_t *pud;
> - int i;
> -
> - for (i = 0; i < PTRS_PER_PUD; i++) {
> - pud = pud_start + i;
> - if (pud_val(*pud))
> - return false;
> - }
> -
> - /* free a pud table */
> - free_pagetable(pgd_page(*pgd), 0);
> - spin_lock(_mm.page_table_lock);
> - pgd_clear(pgd);
> - spin_unlock(_mm.page_table_lock);
> -
> - return true;
> -}
> -
>   static void __meminit
>   remove_pte_table(pte_t *pte_start, unsigned long addr, unsigned long end,
>bool direct)
> @@ -992,7 +971,6 @@ remove_pagetable(unsigned long start, unsigned long end, 
> bool direct)
>   unsigned long addr;
>   pgd_t *pgd;
>   pud_t *pud;
> - bool pgd_changed = false;
>   
>   for (addr = start; addr < end; addr = next) {
>   next = pgd_addr_end(addr, end);
> @@ -1003,13 +981,8 @@ remove_pagetable(unsigned long start, unsigned long 
> end, bool direct)
>   
>   pud = (pud_t *)pgd_page_vaddr(*pgd);
>   remove_pud_table(pud, addr, next, direct);
> - if (free_pud_table(pud, pgd))
> - pgd_changed = true;
>   }
>   
> - if (pgd_changed)
> - sync_global_pgds(start, end - 1, 1);
> -
>   flush_tlb_all();
>   }
>   
> 


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 03/11] x86/mm/hotplug: Don't remove PGD entries in remove_pagetable()

[Kamezawa Hiroyuki]

On 2015/09/22 15:23, Ingo Molnar wrote:
> So when memory hotplug removes a piece of physical memory from pagetable
> mappings, it also frees the underlying PGD entry.
> 
> This complicates PGD management, so don't do this. We can keep the
> PGD mapped and the PUD table all clear - it's only a single 4K page
> per 512 GB of memory hotplugged.
> 
> Cc: Andrew Morton 
> Cc: Andy Lutomirski 
> Cc: Borislav Petkov 
> Cc: Brian Gerst 
> Cc: Denys Vlasenko 
> Cc: H. Peter Anvin 
> Cc: Linus Torvalds 
> Cc: Oleg Nesterov 
> Cc: Peter Zijlstra 
> Cc: Rik van Riel 
> Cc: Thomas Gleixner 
> Cc: Waiman Long 
> Cc: linux...@kvack.org
> Signed-off-by: Ingo Molnar 

Ishimatsu-san, Tang-san, please check.

Doesn't this patch affects the issues of 
 5255e0a79fcc0ff47b387af92bd9ef5729b1b859
 9661d5bcd058fe15b4138a00d96bd36516134543

?

-Kame

> ---
>   arch/x86/mm/init_64.c | 27 ---
>   1 file changed, 27 deletions(-)
> 
> diff --git a/arch/x86/mm/init_64.c b/arch/x86/mm/init_64.c
> index 7129e7647a76..60b0cc3f2819 100644
> --- a/arch/x86/mm/init_64.c
> +++ b/arch/x86/mm/init_64.c
> @@ -780,27 +780,6 @@ static void __meminit free_pmd_table(pmd_t *pmd_start, 
> pud_t *pud)
>   spin_unlock(_mm.page_table_lock);
>   }
>   
> -/* Return true if pgd is changed, otherwise return false. */
> -static bool __meminit free_pud_table(pud_t *pud_start, pgd_t *pgd)
> -{
> - pud_t *pud;
> - int i;
> -
> - for (i = 0; i < PTRS_PER_PUD; i++) {
> - pud = pud_start + i;
> - if (pud_val(*pud))
> - return false;
> - }
> -
> - /* free a pud table */
> - free_pagetable(pgd_page(*pgd), 0);
> - spin_lock(_mm.page_table_lock);
> - pgd_clear(pgd);
> - spin_unlock(_mm.page_table_lock);
> -
> - return true;
> -}
> -
>   static void __meminit
>   remove_pte_table(pte_t *pte_start, unsigned long addr, unsigned long end,
>bool direct)
> @@ -992,7 +971,6 @@ remove_pagetable(unsigned long start, unsigned long end, 
> bool direct)
>   unsigned long addr;
>   pgd_t *pgd;
>   pud_t *pud;
> - bool pgd_changed = false;
>   
>   for (addr = start; addr < end; addr = next) {
>   next = pgd_addr_end(addr, end);
> @@ -1003,13 +981,8 @@ remove_pagetable(unsigned long start, unsigned long 
> end, bool direct)
>   
>   pud = (pud_t *)pgd_page_vaddr(*pgd);
>   remove_pud_table(pud, addr, next, direct);
> - if (free_pud_table(pud, pgd))
> - pgd_changed = true;
>   }
>   
> - if (pgd_changed)
> - sync_global_pgds(start, end - 1, 1);
> -
>   flush_tlb_all();
>   }
>   
> 


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/