From: "Matt Gerassimoff" <mgeras@gmail.com>
To: Russell King - ARM Linux <linux@arm.linux.org.uk>
Cc: "Woodruff, Richard" <r-woodruff2@ti.com>,
"tomi.valkeinen@nokia.com" <tomi.valkeinen@nokia.com>,
"linux-arm-kernel@lists.arm.linux.org.uk"
<linux-arm-kernel@lists.arm.linux.org.uk>,
"linux-omap@vger.kernel.org" <linux-omap@vger.kernel.org>
Subject: Re: ioremap()/iounmap() problem
Date: Mon, 19 Jan 2009 10:47:52 -0700 [thread overview]
Message-ID: <op.un0md2f7l1df02@matts.therealanswer.com> (raw)
In-Reply-To: <20090119171411.GG18301@n2100.arm.linux.org.uk>
On Mon, 19 Jan 2009 10:14:11 -0700, Russell King - ARM Linux
<linux@arm.linux.org.uk> wrote:
> On Mon, Jan 19, 2009 at 10:07:13AM -0700, Matt Gerassimoff wrote:
>> On Mon, 19 Jan 2009 09:13:58 -0700, Russell King - ARM Linux
>> <linux@arm.linux.org.uk> wrote:
>>
>> >diff --git a/arch/arm/mm/ioremap.c b/arch/arm/mm/ioremap.c
>> >index 18373f7..9f88dd3 100644
>> >--- a/arch/arm/mm/ioremap.c
>> >+++ b/arch/arm/mm/ioremap.c
>> >@@ -138,7 +138,7 @@ void __check_kvm_seq(struct mm_struct *mm)
>> > */
>> > static void unmap_area_sections(unsigned long virt, unsigned long
>> size)
>> > {
>> >- unsigned long addr = virt, end = virt + (size & ~SZ_1M);
>> >+ unsigned long addr = virt, end = virt + (size & ~(SZ_1M - 1));
>> > pgd_t *pgd;
>> > flush_cache_vunmap(addr, end);
>> >@@ -337,10 +337,7 @@ void __iounmap(volatile void __iomem *io_addr)
>> > void *addr = (void *)(PAGE_MASK & (unsigned long)io_addr);
>> > #ifndef CONFIG_SMP
>> > struct vm_struct **p, *tmp;
>> >-#endif
>> >- unsigned int section_mapping = 0;
>> >-#ifndef CONFIG_SMP
>> > /*
>> > * If this is a section based mapping we need to handle it
>> > * specially as the VM subsystem does not know how to handle
>> >@@ -352,11 +349,8 @@ void __iounmap(volatile void __iomem *io_addr)
>> > for (p = &vmlist ; (tmp = *p) ; p = &tmp->next) {
>> > if ((tmp->flags & VM_IOREMAP) && (tmp->addr == addr)) {
>> > if (tmp->flags & VM_ARM_SECTION_MAPPING) {
>> >- *p = tmp->next;
>> > unmap_area_sections((unsigned long)tmp->addr,
>> > tmp->size);
>> >- kfree(tmp);
>> >- section_mapping = 1;
>> > }
>> > break;
>> > }
>> >@@ -364,7 +358,6 @@ void __iounmap(volatile void __iomem *io_addr)
>> > write_unlock(&vmlist_lock);
>> > #endif
>> >- if (!section_mapping)
>> >- vunmap(addr);
>> >+ vunmap(addr);
>> > }
>> > EXPORT_SYMBOL(__iounmap);
>>
>> Before this is even tested. I've went down this path. You will
>> receive a
>> ton
>> of Bad PMD errors. unmap_area_sections() and vunmap() don't play nice
>> together.
>> This type of solution will require changes to unmap_area_sections().
>
> Okay, I've just lost interest in persuing this bug any further.
I mis-spoke, the changes required are in remap_area_sections(). They
are not doing proper manipulations to the pmd information. If
remap_area_sections() is fixed, there will be no need for
unmap_area_sections()
as vunmap() will do all the work as far as I can tell.
From that statement you just made, where does that leave us? This in my
estimation
is a MAJOR issue. If you need help testing this, I'll be happy to do so.
It may be
faster for you to create a simple kernel module that ioremap() on module
init and
iounmep() on module exit. Printing the returned virtual address from
ioremap() on
each load will yeild a higher and higher addresses until it returns a NULL
pointer
and kernel OOPS. I'm running on a at91sam9260 and it will fail on about 6
to 10
load/unload cycles of the kernel module. So it happens pretty fast.
--
Matt
next prev parent reply other threads:[~2009-01-19 17:48 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-01-19 10:23 ioremap()/iounmap() problem Tomi Valkeinen
2009-01-19 11:01 ` Russell King - ARM Linux
2009-01-19 12:27 ` Tomi Valkeinen
2009-01-19 12:53 ` Russell King - ARM Linux
2009-01-19 13:49 ` Tomi Valkeinen
2009-01-21 19:23 ` Russell King - ARM Linux
2009-01-22 11:55 ` Tomi Valkeinen
2009-01-22 15:25 ` Matt Gerassimoff
2009-01-19 13:34 ` Woodruff, Richard
2009-01-19 13:43 ` Russell King - ARM Linux
2009-01-19 13:48 ` Woodruff, Richard
2009-01-19 13:56 ` Russell King - ARM Linux
2009-01-19 15:06 ` Matt Gerassimoff
2009-01-19 15:22 ` Russell King - ARM Linux
2009-01-19 15:39 ` Matt Gerassimoff
2009-01-19 15:58 ` Russell King - ARM Linux
2009-01-19 16:13 ` Russell King - ARM Linux
2009-01-19 17:07 ` Matt Gerassimoff
2009-01-19 17:14 ` Russell King - ARM Linux
2009-01-19 17:47 ` Matt Gerassimoff [this message]
2009-01-19 17:07 ` Woodruff, Richard
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=op.un0md2f7l1df02@matts.therealanswer.com \
--to=mgeras@gmail.com \
--cc=linux-arm-kernel@lists.arm.linux.org.uk \
--cc=linux-omap@vger.kernel.org \
--cc=linux@arm.linux.org.uk \
--cc=r-woodruff2@ti.com \
--cc=tomi.valkeinen@nokia.com \
/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