linux-kernel - Re: remap allocator for per-CPU memory

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Wed, 13 May 2009 19:09:52 +0900
From:	Tejun Heo <teheo@...ell.com>
To:	Jan Beulich <JBeulich@...ell.com>
Cc:	Ingo Molnar <mingo@...e.hu>, linux-kernel@...r.kernel.org
Subject: Re: remap allocator for per-CPU memory

Tejun Heo wrote:
> Jan Beulich wrote:
>> Didn't the addition of this allocator introduce another case that
>> needs special treatment in pageattr.c? Since large pages are used
>> for mapping the allocated memory, but only part of the initially
>> allocated large pages are actually retained, there's now the
>> potential for TLB aliases with different cache attributes for those
>> parts of these pages that get passed back through free_bootmem().
> 
> Hmmm.... yes, the large page mapping and the returned part of it would
> alias each other.  What changes should be made for it?  Dunno much
> about how pageattr works.

Okay, just glanced over the pageattr code.  I don't think we need any
special provisions for this as long as the TLB is fine with having
overlapping PMD and PTE mappings with different attributes (please
note that these two mappings aren't occupying the same linear
addresses - they're aliases).  This is allowed, right?

Thanks.

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