linux-kernel - Re: [PATCH] ARM: fix bug which lowmem size is limited to 760MB

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] [day] [month] [year] [list]

Date:	Tue, 8 Sep 2015 10:58:09 -0400 (EDT)
From:	Nicolas Pitre <nicolas.pitre@...aro.org>
To:	Russell King - ARM Linux <linux@....linux.org.uk>
cc:	Arnd Bergmann <arnd@...db.de>,
	linux-arm-kernel@...ts.infradead.org,
	Yongtaek Lee <ytk.lee@...sung.com>,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH] ARM: fix bug which lowmem size is limited to 760MB

On Tue, 8 Sep 2015, Russell King - ARM Linux wrote:

> On Mon, Sep 07, 2015 at 10:01:41PM -0400, Nicolas Pitre wrote:
> 
[...]
> > This is passed to iotable_init(), then to create_mapping(). There you 
> > have:
> > 
> >         if ((md->type == MT_DEVICE || md->type == MT_ROM) &&
> >             md->virtual >= PAGE_OFFSET &&
> >             (md->virtual < VMALLOC_START || md->virtual >= VMALLOC_END)) {
> >                 pr_warn("BUG: mapping for 0x%08llx at 0x%08lx out of vmalloc space\n",
> >                         (long long)__pfn_to_phys((u64)md->pfn), md->virtual);
> >         }
> > 
> > So you must have hit the above warning somehow. Incidentally, this 
> > IRQ_STAT entry is the only one that happened to be outside the vmalloc 
> > area. By moving VMALLOC_END from 0xff000000 to 0xff800000 the warning 
> > will be gone.
> 
> No, there are other legacy platforms which have mappings above that.

... for that particular map_desc array instance I mean.

WRT other legacy platforms: if the above warning didn't bother anyone 
for the last 4 years, then it won't be such an issue either if the 
current proposal doesn't solve them all.  That's not the primary purpose 
of this change anyway. In those cases, the appropriate fix, like it is 
today, should consist in some adjustment of those virtual addresses to 
bring them inside the vmalloc area.

Your original concern was whether extending the vmalloc area upward 
would clash with something else, and the short answer is no.


Nicolas
--
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/