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: <20101009000046.GA30616@kroah.com>
Date:	Fri, 8 Oct 2010 17:00:46 -0700
From:	Greg KH <greg@...ah.com>
To:	Russell King - ARM Linux <linux@....linux.org.uk>
Cc:	Felipe Contreras <felipe.contreras@...il.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>,
	Uwe Kleine-König 
	<u.kleine-koenig@...gutronix.de>, Hemant Pedanekar <hemantp@...com>
Subject: Re: [PATCH] ARM: allow, but warn, when issuing ioremap() on RAM

On Sat, Oct 09, 2010 at 12:44:48AM +0100, Russell King - ARM Linux wrote:
> On Fri, Oct 08, 2010 at 04:25:39PM -0700, Greg KH wrote:
> > I doubt that people even noticed that this was a problem.
> 
> So what you're telling me is that ARM SoC people don't read the
> ARM kernel mailing list?  I might as well stop posting patches
> if no one's paying attention then! :-P
> 
> Reality is that it was discussed, and I did propose solutions at
> the time.

Heh, fair enough

> > Unless you throw a run-time warning at them, or even better, break the
> > build of their drivers, they will not notice.
> > 
> > Also, how can we fix this in a driver, what is the proper steps to do
> > so?
> 
> On April 23rd:
> | I think a viable safe solution is to set aside some RAM at boot (which
> | the kernel doesn't manage at all) and then use ioremap on that; that
> | approach will still work with this patch in place.
> 
> On April 30th when discussing the omapfb driver:
> | There's really one option for this - in the machine's fixup handler, you
> | can walk the meminfo array and kick out some memory from that.  This will
> | prevent the kernel mapping that memory and make pfn_valid() fail for that
> | memory range.  Another advantage of this is that it won't break when we
> | switch to LMB.

Ah, but no drivers have been fixed in any of these ways yet?

> So, as I say, there's been six months.  It was discussed.  But still
> we find that the drivers haven't been touched and now we're complaining
> that drivers are breaking.
> 
> If it hadn't been discussed, if solutions hadn't been proposed, then
> yes, it would be right to revert it out-right.  But that's not what
> happened.
> 
> If we have to have another three months (or so), this time with a warning,
> then so be it, but let's make it plainly clear that it _will_ _definitely_
> be changing, and that drivers _will_ break unless they are fixed.
> 
> Unfortunately, what I fear is that nothing will happen because people
> want the ioremap-on-system-RAM to just work, and then we'll hit this
> exact same issue again in three months time.

But you can't expect that you make this change, and not fix up the
drivers, and people would be happy, right?  The rule for API changes
like this, or anything, is that the person making the change fixes the
other drivers, and that seems to be the issue here.

Any pointers to patches where people have fixed up the drivers?

thanks,

greg k-h
--
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/