All of lore.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 08:39:39 -0700	[thread overview]
Message-ID: <op.un0ggdb6l1df02@matts.therealanswer.com> (raw)
In-Reply-To: <20090119152237.GC18301@n2100.arm.linux.org.uk>

On Mon, 19 Jan 2009 08:22:37 -0700, Russell King - ARM Linux  
<linux@arm.linux.org.uk> wrote:

> On Mon, Jan 19, 2009 at 08:06:27AM -0700, Matt Gerassimoff wrote:
>> This issue is the reason I have subscribed to the mailing list.  I have
>> discovered the problem and had a quick patch to solve it.
>
> It's not a solution, it's a work-around.  You're not seeing the problem
> anymore because you've changed the code to avoid using section mappings.

That's what I said at the end of the first message.

> The solution is to fix iounmap() to use proper interfaces into  
> mm/vmalloc.c
> when removing the section and supersection mappings.

After looking at how the the vmap_area's are managed, that's going to
be a tough one.
>
>> The statement:
>>
>> 	} else if (!((__pfn_to_phys(pfn) | size | addr) & ~PMD_MASK)) {
>>
>> is the strange one.  I'm not what is being checked here except the
>> PMD_MASK.
>
> 	(a | b | c) & mask
>
> 	(a & mask) | (b & mask) | (c & mask)
>
> 	(a & mask) || (b & mask) || (c & mask)
>
> and PMD_MASK is used to mask off the offset into a 2MB section.  So,
> (a & ~PMD_MASK) gives the offset into the 2MB section.
>
> So, the test is:
>
> 	- is the physical address aligned to 2MB
> and
> 	- is the size aligned to 2MB
> and
> 	- is the virtual address aligned to 2MB
> then
> 	map using section mappings.

Ok, that makes sense.

>> But without that code, everything works 100%.  I'm not sure what all the
>> remap_area_sections()
>> code does, but the cleanup definitely does not work,  as the kernel OOPS
>> will testify.
>> There may be a better solution, but as far as I can tell, it's not  
>> really
>> needed.  Maybe
>> someone else will disagree.
>
> We might as well rip this code out then.  I'm all for simpler code, but  
> I'm
> sure the folk who want to squeeze the best performance out of their  
> machines
> will quickly squeel if I did that.
>
> And what cleanup are you referring to?

I meant freeing, not cleanup.  Sorry.

As I said it's a start.  I'm all for performance but not at the expense
of integrity.  Right now the code doesn't work and needs to be fixed.

-- 
Matt

  reply	other threads:[~2009-01-19 15:39 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 [this message]
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
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.un0ggdb6l1df02@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.