linux-kernel - Re: [PATCH] ARM: allow, but warn, when issuing ioremap() on RAM

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]

Message-ID: <20101011083508.GW29673@pengutronix.de>
Date:	Mon, 11 Oct 2010 10:35:08 +0200
From:	Uwe Kleine-König 
	<u.kleine-koenig@...gutronix.de>
To:	Russell King - ARM Linux <linux@....linux.org.uk>
Cc:	Felipe Contreras <felipe.contreras@...il.com>,
	Greg KH <greg@...ah.com>,
	linux-main <linux-kernel@...r.kernel.org>,
	linux-arm <linux-arm-kernel@...ts.infradead.org>,
	Arnd Hannemann <arnd@...dnet.de>,
	Han Jonghun <jonghun79.han@...il.com>,
	Hemant Pedanekar <hemantp@...com>
Subject: Re: [PATCH] ARM: allow, but warn, when issuing ioremap() on RAM

Hello,
 
On Sun, Oct 10, 2010 at 04:52:36AM +0300, Felipe Contreras wrote:
> On Sat, Oct 9, 2010 at 12:21 PM, Russell King - ARM Linux
> <linux@....linux.org.uk> wrote:
> > static unsigned long reserve_mem(struct meminfo *mi, unsigned long size)
> > {
> >        unsigned long addr = ~0;
> >        int i;
> >
> >        for (i = mi->nr_banks - 1; i >= 0; i--)
> >                if (mi->bank[i].size >= size) {
> >                        mi->bank[i].size -= size;
> >                        addr = mi->bank[i].start + mi->bank[i].size;
> >                        break;
> >                }
> >
> >        return addr;
> > }
> >
> > static void __init my_fixup(struct machine_desc *desc, struct tag *tags,
> >                            char **cmdline, struct meminfo *mi)
> > {
> >        omapfb_buffer_phys = reserve_mem(mi, 32*1048576);
> >        if (omapfb_buffer_phys == ~0)
> >                pr_warn("Unable to allocate omapfb buffer\n");
> > }
> >
> > Then later:
> >
> >        omapfb_buffer = ioremap(omapfb_buffer_phys, 32*1048576);
> >
> > That's a damned simple and direct implementation of exactly what I
> > described, and results in something which is much more architecturally
> > correct than what's going on today.
> 
> I tried this, it doesn't work.
Ack, didn't work.  I tried it for arch/arm/mach-mx3/mach-pcm037.c.

> 
> At the time 'fixup' is called, 'meminfo' is empty; the tags haven't
> been parsed. So my solution is to move the memblock_add() after
> 'reserve', and pass 'meminfo' as an argument:
> 
> --- a/arch/arm/mm/init.c
> +++ b/arch/arm/mm/init.c
> @@ -272,8 +272,6 @@ void __init arm_memblock_init(struct meminfo *mi,
> struct machine_desc *mdesc)
>         int i;
> 
>         memblock_init();
> -       for (i = 0; i < mi->nr_banks; i++)
> -               memblock_add(mi->bank[i].start, mi->bank[i].size);
> 
>         /* Register the kernel text, kernel data and initrd with memblock. */
>  #ifdef CONFIG_XIP_KERNEL
> @@ -295,7 +293,10 @@ void __init arm_memblock_init(struct meminfo *mi,
> struct machine_desc *mdesc)
> 
>         /* reserve any platform specific memblock areas */
>         if (mdesc->reserve)
> -               mdesc->reserve();
> +               mdesc->reserve(mi);
> +
> +       for (i = 0; i < mi->nr_banks; i++)
> +               memblock_add(mi->bank[i].start, mi->bank[i].size);
> 
>         memblock_analyze();
>         memblock_dump_all();
Alternatively when calling fixup only after parse_tags in setup_arch()
it worked.  But I guess this change is not for discussion.
OTOH I wonder why fixup gets passed meminfo.  It's not very useful if
it's not yet filled.

Best regards
Uwe

-- 
Pengutronix e.K.                           | Uwe Kleine-König            |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
--
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/