public inbox for linux-omap@vger.kernel.org
 help / color / mirror / Atom feed
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

  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