From: linux@arm.linux.org.uk (Russell King - ARM Linux)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH] ARM: ioremap: fix boundary check when reusing static mapping
Date: Sun, 29 Jan 2012 14:55:03 +0000 [thread overview]
Message-ID: <20120129145503.GE15455@n2100.arm.linux.org.uk> (raw)
In-Reply-To: <CAGhQ9Vwh6TTeQ1qy_Mvou+XKJ4kkZE4dUZk+3CzS2g7TM7kTrQ@mail.gmail.com>
On Sun, Jan 29, 2012 at 03:33:35PM +0100, Joachim Eastwood wrote:
> <1>ioremap: pfn=fffff phys=fffff000 offset=400 size=1000
> <1>ioremap: area c3ffdfc0: phys_addr=200000 pfn=200 size=4000
> <1>ioremap: found: addr fef74000 => fed73000 => fed73400
Ok, first thing is that patch 7304/1 is utter crap. The reason is simple -
'size' here:
if (__phys_to_pfn(area->phys_addr) > pfn ||
__pfn_to_phys(pfn) + offset + size-1 >
area->phys_addr + area->size-1)
continue;
_already_ contains 'offset', as we've only _just_ done this a few lines
above the loop:
size = PAGE_ALIGN(offset + size);
So, 'size' includes the requested offset *already*. So, Nicolas' original:
if (__phys_to_pfn(area->phys_addr) > pfn ||
__pfn_to_phys(pfn) + size-1 > area->phys_addr + area->size-1)
continue;
was correct in the first place. In any case, let's see what's going on
here:
if (__phys_to_pfn(area->phys_addr) > pfn ||
__pfn_to_phys(pfn) + offset + size-1 >
area->phys_addr + area->size-1)
continue;
we have:
area->phys_addr = 0x00200000, __phys_to_pfn(area->phys_addr) = 0x00200
area->size = 0x4000, pfn = 0xfffff, offset = 0x400, size = 0x1000
So, this if condition becomes:
if (0x00200 > 0xfffff ||
0xfffff000 + 0x400 + 0x1000-1 > 0x00200000 + 0x4000-1)
and therefore:
if (0x00200 > 0xfffff ||
0x000003ff > 0x00203fff)
So, the if condition fails, and so we _believe_ that the SRAM mapping fits
our request. Clearly that's totally bogus and crap.
Unfortunately, Pawel doesn't say what the problem he was trying to fix was,
all we have to go on is this totally crap commit comment:
The condition checking boundaries of the requested and existing
mappings didn't take in-page offset into consideration though,
which lead to obscure and hard to debug problems when requested
mapping crossed end of the static one.
In any case, I don't think it matters, and I'm going to schedule a revert
of that crap commit. So, Joachim, well spotted.
next prev parent reply other threads:[~2012-01-29 14:55 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-01-25 18:16 [PATCH] ARM: ioremap: fix boundary check when reusing static mapping Pawel Moll
2012-01-25 18:37 ` Nicolas Pitre
2012-01-26 10:35 ` Pawel Moll
2012-01-28 22:55 ` Joachim Eastwood
2012-01-29 0:11 ` Russell King - ARM Linux
2012-01-29 13:10 ` Joachim Eastwood
2012-01-29 13:14 ` Russell King - ARM Linux
2012-01-29 13:22 ` Joachim Eastwood
2012-01-29 14:14 ` Russell King - ARM Linux
2012-01-29 14:33 ` Joachim Eastwood
2012-01-29 14:55 ` Russell King - ARM Linux [this message]
2012-01-29 15:13 ` Nicolas Pitre
2012-01-30 11:10 ` Pawel Moll
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20120129145503.GE15455@n2100.arm.linux.org.uk \
--to=linux@arm.linux.org.uk \
--cc=linux-arm-kernel@lists.infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).