linux-kernel - Re: [PATCH v4 0/2] mm/highmem: make kmap cache coloring aware

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:	Mon, 25 Aug 2014 17:36:06 -0700
From:	David Daney <ddaney.cavm@...il.com>
To:	Joshua Kinard <kumba@...too.org>
CC:	Ralf Baechle <ralf@...ux-mips.org>,
	Max Filippov <jcmvbkbc@...il.com>,
	linux-xtensa@...ux-xtensa.org, Chris Zankel <chris@...kel.net>,
	Marc Gauthier <marc@...ence.com>, linux-mm@...ck.org,
	linux-arch@...r.kernel.org, linux-mips@...ux-mips.org,
	linux-kernel@...r.kernel.org, David Rientjes <rientjes@...gle.com>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Leonid Yegoshin <Leonid.Yegoshin@...tec.com>,
	Steven Hill <Steven.Hill@...tec.com>
Subject: Re: [PATCH v4 0/2] mm/highmem: make kmap cache coloring aware

On 08/25/2014 04:55 PM, Joshua Kinard wrote:
> On 08/25/2014 13:16, Ralf Baechle wrote:
>> On Sat, Aug 02, 2014 at 05:11:37AM +0400, Max Filippov wrote:
>>
>>> this series adds mapping color control to the generic kmap code, allowing
>>> architectures with aliasing VIPT cache to use high memory. There's also
>>> use example of this new interface by xtensa.
>>
>> I haven't actually ported this to MIPS but it certainly appears to be
>> the right framework to get highmem aliases handled on MIPS, too.
>>
>> Though I still consider increasing PAGE_SIZE to 16k the preferable
>> solution because it will entirly do away with cache aliases.
>
> Won't setting PAGE_SIZE to 16k break some existing userlands (o32)?  I use a
> 4k PAGE_SIZE because the last few times I've tried 16k or 64k, init won't
> load (SIGSEGVs or such, which panicks the kernel).
>

It isn't supposed to break things.  Using "stock" toolchains should 
result in executables that will run with any page size.

In the past, some geniuses came up with some linker (ld) patches that, 
in order to save a few KB of RAM, produced executables that ran only on 
4K pages.

There were some equally astute Debian emacs package maintainers that 
were carrying emacs patches into Debian that would not work on non-4K 
page size systems.

That said, I think such thinking should be punished.  The punishment 
should be to not have their software run when we select non-4K page 
sizes.  The vast majority of prepackaged software runs just fine with a 
larger page size.

David Daney
--
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/