linux-kernel - Re: [PATCH .36-rc8] arm: mm: 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]

Date:	Sun, 17 Oct 2010 15:06:44 +0300
From:	Felipe Contreras <felipe.contreras@...il.com>
To:	Russell King - ARM Linux <linux@....linux.org.uk>
Cc:	Catalin Marinas <catalin.marinas@....com>,
	linux-main <linux-kernel@...r.kernel.org>,
	linux-arm <linux-arm-kernel@...ts.infradead.org>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Uwe Kleine-König 
	<u.kleine-koenig@...gutronix.de>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Richard Woodruff <r-woodruff2@...com>
Subject: Re: [PATCH .36-rc8] arm: mm: allow, but warn, when issuing ioremap()
 on RAM

On Fri, Oct 15, 2010 at 11:14 PM, Russell King - ARM Linux
<linux@....linux.org.uk> wrote:
> On Fri, Oct 15, 2010 at 11:00:40PM +0300, Felipe Contreras wrote:
>> On Fri, Oct 15, 2010 at 10:42 PM, Russell King - ARM Linux
>> <linux@....linux.org.uk> wrote:
>> > As soon as the first ARM merge hits during the merge window, I'll be
>> > restoring the 'always fail' behaviour.
>>
>> Ok, are you going to merge also your patch to use memblock for the
>> initialization? Many drivers could certainly use that to fix the
>> issue.
>
> There's a lot of work going on with memblock in x86-land which impacts
> ARM and means major conflicts for that patch - I think first we'll have
> to deal with the fallout from that (iow, finding out what's been broken
> by this activity and fix that), and then I'll have to re-do my patch from
> the beginning.
>
> Technically, following the rules, that means it has to miss this merge
> window - so it looks like it's going to take another six months to solve
> this issue (three months to get the memblock patch in, and another three
> months for driver fixes to find their way through.)

I don't think that's a good idea. Drivers would not have a way to get
fixed, even for .37.

Are these x86 changes in some branch? Would it help if I try to port
your patch on top of that? IOW; is there any chance of getting these
drivers fixed on .37?

If not, I guess people would have to revert the patch that disables
ioremap() on RAM on their trees.

> I find these timescales (12 months) rather unacceptable to fix a problem
> such as this.  Makes me wonder why I even bother trying.

As I said, if the warning was merged on .35 (or even before) I think
things would have gone smoother, but I guess we'll see on .36 what
happens.

-- 
Felipe Contreras
--
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/