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
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
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:
>>
>>
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:
>>
>>
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 *
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 *
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*
> > > >>
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
* 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
* 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?
> >
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
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
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
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
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
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
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
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
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,
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,
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:
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:
22 matches
Mail list logo