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  PHC 
Open Source and information security mailing list archives
Hash Suite for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Wed, 6 Aug 2014 11:40:19 +0800
From:	Liu hua <>
To:	Kees Cook <>,
	Nicolas Pitre <>,
	Rob Herring <>
CC:	<>, Laura Abbott <>,
	<>, Will Deacon <>,
	"" <>,
	"Vitaly Andrianov" <>, Rabin Vincent <>,
	Santosh Shilimkar <>,
	"" <>,
	"Cyril Chemparathy" <>,
	Russell King - ARM Linux <>,
Subject: Re: [PATCH v3 2/2] ARM : change fixmap mapping region to support
 32 CPUs

于 2014/8/6 10:51, Kees Cook 写道:
> On Fri, May 30, 2014 at 12:25 PM, Nicolas Pitre
> <> wrote:
>> On Fri, 30 May 2014, Rob Herring wrote:
>>> There's work in flight to support early_ioremap, early console, and RO
>>> text patching which all use the fixmap region.
>>> There's a couple of options to solve this:
>>> - Only support up to 16 cpus. It could be anywhere between 17-31, but
>>> that seems somewhat unlikely. Are we really ever going to see 32-bit
>>> 32 core systems?
>> I wouldn't rule that out.  I've seen 16-core ARM chips in 2008 (although
>> they didn't go into production).  Silly limitations like that always
>> come back to bite you.  And we have better alternatives.
>>> - Reduce KM_TYPE_NR from 16 to 15. Based on the comment for it, we
>>> probably don't want to do that. Is increasing it to the default of 20
>>> worthwhile? Some of the options here would allow doing that.
>>> - Add 0xffe00000-0xfff00000 to the fixmap region. This would make
>>> fixmap span 2 PMDs with the top PMD having a mixture of uses like we
>>> had before.
>> That would be my preferred approach.  Note here it could be
>> 0xffe00000-0xfffe0000 to include the whole of the previous fixmap area
>> curently unused.
>>> - push the PCI i/o space down to 0xfec00000 and make fixmap 4MB. This
>>> is a cleaner solution as the 2 PMDs are only used for fixmap. This may
>>> require some static mapping adjustments on some platforms.
>> No need.  With the latest changes, the fixmap area is between 0xffc00000
>> and 0xffe00000 (there is apparently a mistake in
>> Documentation/arm/memory.txt).  So currently 0xff000000-0xffc00000 is
>> free, which makes the fixmap area far away from the PCI i/o area with
>> plenti of space in between.
> So, it seems there is something wrong with this patch series. I had to
> revert "ARM: 8031/2: change fixmap mapping region to support 32 CPUs"
> to make other fixmap changes work correctly. I think this is due to
> the non-highmem config case moving the fixmap to a location where
> there is to page table entry...
Hi Kees,

Did this patch conflict with others, or it will at the future?

As Rob said "There's work in flight to support early_ioremap, early console, and RO
text patching which all use the fixmap region."  So if this patch will block kernel's
new feature, Should we makes new patch to changes it, not revert it. Because there are
arm platforms with more than 14 CPUs.

Liu Hua
> -Kees
>>> - Same as previous option, but convert the PCI i/o space to fixmap
>>> entries. We don't really need all 2MB for PCI.
>> See above.
>>> Also, there is an error in the documentation below:
>>>> Signed-off-by: Liu Hua <>
>>>> ---
>>>>  Documentation/arm/memory.txt   |  2 +-
>> Yep, good that you spotted it as well.  I failed to catch it during my
>> review so I'll send a patch.
>> Nicolas
>> _______________________________________________
>> linux-arm-kernel mailing list

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

Powered by blists - more mailing lists