On Nov 19, 2014 4:00 PM, "Thomas Gleixner" <[email protected]> wrote: > > On Wed, 19 Nov 2014, Andy Lutomirski wrote: > > On Wed, Nov 19, 2014 at 3:09 PM, Thomas Gleixner <[email protected]> wrote: > > > Sorry, I can't follow your argumentation here. > > > > > > pcpu_alloc() > > > .... > > > area_found: > > > .... > > > > > > /* clear the areas and return address relative to base address */ > > > for_each_possible_cpu(cpu) > > > memset((void *)pcpu_chunk_addr(chunk, cpu, 0) + off, 0, > > > size); > > > > > > How would that memset fail to establish the mapping, which is > > > btw. already established via: > > > > > > pcpu_populate_chunk() > > > > > > already before that memset? > > > > I think that this will map them into init_mm->pgd and > > current->active_mm->pgd, but it won't necessarily map them into the > > rest of the pgds. > > And why would mapping them into the kernel mapping, i.e. init_mm not > be sufficient?
Because the kernel can run with any pgd loaded into cr3, and we rely on vmalloc_fault to lazily populate pgds in all the non-init pgds as needed. But this only happens if the first TLB-missing reference to the pgd in question with any given cr3 value happens from a safe context. This is why I think that the grsec kernels will crash on very large memory systems. They don't seem to get this right for the kernel stack, and a page fault trying to access the stack is a big no-no. --Andy > > We are talking about kernel memory and not some random user space > mapping. > > Thanks, > > tglx -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
