Re: [patch V163 27/51] x86/mm/pti: Populate user PGD

2017-12-20 Thread Thomas Gleixner
On Wed, 20 Dec 2017, Juergen Gross wrote: > On 20/12/17 01:22, Thomas Gleixner wrote: > > On Tue, 19 Dec 2017, Thomas Gleixner wrote: > >> On Tue, 19 Dec 2017, Ingo Molnar wrote: > >> We don't run out of space, but the 0-day robot triggered a nasty issue. > >> > >> The fixmap bottom address, which

Re: [patch V163 27/51] x86/mm/pti: Populate user PGD

2017-12-20 Thread Thomas Gleixner
On Wed, 20 Dec 2017, Juergen Gross wrote: > On 20/12/17 01:22, Thomas Gleixner wrote: > > On Tue, 19 Dec 2017, Thomas Gleixner wrote: > >> On Tue, 19 Dec 2017, Ingo Molnar wrote: > >> We don't run out of space, but the 0-day robot triggered a nasty issue. > >> > >> The fixmap bottom address, which

Re: [patch V163 27/51] x86/mm/pti: Populate user PGD

2017-12-20 Thread Juergen Gross
On 20/12/17 01:22, Thomas Gleixner wrote: > On Tue, 19 Dec 2017, Thomas Gleixner wrote: >> On Tue, 19 Dec 2017, Ingo Molnar wrote: >> We don't run out of space, but the 0-day robot triggered a nasty issue. >> >> The fixmap bottom address, which contains the early_ioremap fixmap area, is: >> >>

Re: [patch V163 27/51] x86/mm/pti: Populate user PGD

2017-12-20 Thread Juergen Gross
On 20/12/17 01:22, Thomas Gleixner wrote: > On Tue, 19 Dec 2017, Thomas Gleixner wrote: >> On Tue, 19 Dec 2017, Ingo Molnar wrote: >> We don't run out of space, but the 0-day robot triggered a nasty issue. >> >> The fixmap bottom address, which contains the early_ioremap fixmap area, is: >> >>

Re: [patch V163 27/51] x86/mm/pti: Populate user PGD

2017-12-19 Thread Thomas Gleixner
On Tue, 19 Dec 2017, Thomas Gleixner wrote: > On Tue, 19 Dec 2017, Ingo Molnar wrote: > We don't run out of space, but the 0-day robot triggered a nasty issue. > > The fixmap bottom address, which contains the early_ioremap fixmap area, is: > > vaddr_bt = FIXADDR_TOP - FIX_BTMAP_BEGIN *

Re: [patch V163 27/51] x86/mm/pti: Populate user PGD

2017-12-19 Thread Thomas Gleixner
On Tue, 19 Dec 2017, Thomas Gleixner wrote: > On Tue, 19 Dec 2017, Ingo Molnar wrote: > We don't run out of space, but the 0-day robot triggered a nasty issue. > > The fixmap bottom address, which contains the early_ioremap fixmap area, is: > > vaddr_bt = FIXADDR_TOP - FIX_BTMAP_BEGIN *

Re: [patch V163 27/51] x86/mm/pti: Populate user PGD

2017-12-19 Thread Thomas Gleixner
On Tue, 19 Dec 2017, Ingo Molnar wrote: > * Peter Zijlstra wrote: > > > On Mon, Dec 18, 2017 at 12:45:13PM -0800, Dave Hansen wrote: > > > On 12/18/2017 12:41 PM, Peter Zijlstra wrote: > > > >> I also don't think the user_shared area of the fixmap can get *that* > > > >>

Re: [patch V163 27/51] x86/mm/pti: Populate user PGD

2017-12-19 Thread Thomas Gleixner
On Tue, 19 Dec 2017, Ingo Molnar wrote: > * Peter Zijlstra wrote: > > > On Mon, Dec 18, 2017 at 12:45:13PM -0800, Dave Hansen wrote: > > > On 12/18/2017 12:41 PM, Peter Zijlstra wrote: > > > >> I also don't think the user_shared area of the fixmap can get *that* > > > >> big. Does anybody know

Re: [patch V163 27/51] x86/mm/pti: Populate user PGD

2017-12-18 Thread Ingo Molnar
* Peter Zijlstra wrote: > On Mon, Dec 18, 2017 at 12:45:13PM -0800, Dave Hansen wrote: > > On 12/18/2017 12:41 PM, Peter Zijlstra wrote: > > >> I also don't think the user_shared area of the fixmap can get *that* > > >> big. Does anybody know offhand what the theoretical

Re: [patch V163 27/51] x86/mm/pti: Populate user PGD

2017-12-18 Thread Ingo Molnar
* Peter Zijlstra wrote: > On Mon, Dec 18, 2017 at 12:45:13PM -0800, Dave Hansen wrote: > > On 12/18/2017 12:41 PM, Peter Zijlstra wrote: > > >> I also don't think the user_shared area of the fixmap can get *that* > > >> big. Does anybody know offhand what the theoretical limits are there? > >

Re: [patch V163 27/51] x86/mm/pti: Populate user PGD

2017-12-18 Thread Andy Lutomirski
On Mon, Dec 18, 2017 at 12:34 PM, Dave Hansen wrote: > On 12/18/2017 03:42 AM, Thomas Gleixner wrote: >> --- a/arch/x86/include/asm/pgtable.h >> +++ b/arch/x86/include/asm/pgtable.h >> @@ -1120,6 +1120,11 @@ static inline void pmdp_set_wrprotect(st >> static inline void

Re: [patch V163 27/51] x86/mm/pti: Populate user PGD

2017-12-18 Thread Andy Lutomirski
On Mon, Dec 18, 2017 at 12:34 PM, Dave Hansen wrote: > On 12/18/2017 03:42 AM, Thomas Gleixner wrote: >> --- a/arch/x86/include/asm/pgtable.h >> +++ b/arch/x86/include/asm/pgtable.h >> @@ -1120,6 +1120,11 @@ static inline void pmdp_set_wrprotect(st >> static inline void clone_pgd_range(pgd_t

Re: [patch V163 27/51] x86/mm/pti: Populate user PGD

2017-12-18 Thread Peter Zijlstra
On Mon, Dec 18, 2017 at 12:45:13PM -0800, Dave Hansen wrote: > On 12/18/2017 12:41 PM, Peter Zijlstra wrote: > >> I also don't think the user_shared area of the fixmap can get *that* > >> big. Does anybody know offhand what the theoretical limits are there? > > Problem there is the nr_cpus term I

Re: [patch V163 27/51] x86/mm/pti: Populate user PGD

2017-12-18 Thread Peter Zijlstra
On Mon, Dec 18, 2017 at 12:45:13PM -0800, Dave Hansen wrote: > On 12/18/2017 12:41 PM, Peter Zijlstra wrote: > >> I also don't think the user_shared area of the fixmap can get *that* > >> big. Does anybody know offhand what the theoretical limits are there? > > Problem there is the nr_cpus term I

Re: [patch V163 27/51] x86/mm/pti: Populate user PGD

2017-12-18 Thread Dave Hansen
On 12/18/2017 12:41 PM, Peter Zijlstra wrote: >> I also don't think the user_shared area of the fixmap can get *that* >> big. Does anybody know offhand what the theoretical limits are there? > Problem there is the nr_cpus term I think, we currently have up to 8k > CPUs, but I can see that getting

Re: [patch V163 27/51] x86/mm/pti: Populate user PGD

2017-12-18 Thread Dave Hansen
On 12/18/2017 12:41 PM, Peter Zijlstra wrote: >> I also don't think the user_shared area of the fixmap can get *that* >> big. Does anybody know offhand what the theoretical limits are there? > Problem there is the nr_cpus term I think, we currently have up to 8k > CPUs, but I can see that getting

Re: [patch V163 27/51] x86/mm/pti: Populate user PGD

2017-12-18 Thread Peter Zijlstra
On Mon, Dec 18, 2017 at 12:34:22PM -0800, Dave Hansen wrote: > On 12/18/2017 03:42 AM, Thomas Gleixner wrote: > > --- a/arch/x86/include/asm/pgtable.h > > +++ b/arch/x86/include/asm/pgtable.h > > @@ -1120,6 +1120,11 @@ static inline void pmdp_set_wrprotect(st > > static inline void

Re: [patch V163 27/51] x86/mm/pti: Populate user PGD

2017-12-18 Thread Peter Zijlstra
On Mon, Dec 18, 2017 at 12:34:22PM -0800, Dave Hansen wrote: > On 12/18/2017 03:42 AM, Thomas Gleixner wrote: > > --- a/arch/x86/include/asm/pgtable.h > > +++ b/arch/x86/include/asm/pgtable.h > > @@ -1120,6 +1120,11 @@ static inline void pmdp_set_wrprotect(st > > static inline void

Re: [patch V163 27/51] x86/mm/pti: Populate user PGD

2017-12-18 Thread Dave Hansen
On 12/18/2017 03:42 AM, Thomas Gleixner wrote: > --- a/arch/x86/include/asm/pgtable.h > +++ b/arch/x86/include/asm/pgtable.h > @@ -1120,6 +1120,11 @@ static inline void pmdp_set_wrprotect(st > static inline void clone_pgd_range(pgd_t *dst, pgd_t *src, int count) > { > memcpy(dst, src,

Re: [patch V163 27/51] x86/mm/pti: Populate user PGD

2017-12-18 Thread Dave Hansen
On 12/18/2017 03:42 AM, Thomas Gleixner wrote: > --- a/arch/x86/include/asm/pgtable.h > +++ b/arch/x86/include/asm/pgtable.h > @@ -1120,6 +1120,11 @@ static inline void pmdp_set_wrprotect(st > static inline void clone_pgd_range(pgd_t *dst, pgd_t *src, int count) > { > memcpy(dst, src,

[patch V163 27/51] x86/mm/pti: Populate user PGD

2017-12-18 Thread Thomas Gleixner
From: Dave Hansen In clone_pgd_range() copy the init user PGDs which cover the kernel half of the address space, so a process has all the required kernel mappings visible. [ tglx: Split out from the big kaiser dump and folded Andys simplification ] Signed-off-by:

[patch V163 27/51] x86/mm/pti: Populate user PGD

2017-12-18 Thread Thomas Gleixner
From: Dave Hansen In clone_pgd_range() copy the init user PGDs which cover the kernel half of the address space, so a process has all the required kernel mappings visible. [ tglx: Split out from the big kaiser dump and folded Andys simplification ] Signed-off-by: Dave Hansen Signed-off-by: