All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Hans J. Koch" <hjk@linutronix.de>
To: Peter Crosthwaite <peter.crosthwaite@petalogix.com>
Cc: Greg KH <gregkh@suse.de>,
	linux-kernel@vger.kernel.org, hjk@linutronix.de,
	Michal Simek <michal.simek@petalogix.com>,
	John Williams <john.williams@petalogix.com>
Subject: Re: UIO: munmap bug for boot time allocated memory
Date: Wed, 21 Jul 2010 11:09:12 +0200	[thread overview]
Message-ID: <20100721090912.GC1669@local> (raw)
In-Reply-To: <AANLkTinuMRXSInvNTxVYPH3gFd8HA0LV_pO1e44QvBkt@mail.gmail.com>

On Wed, Jul 21, 2010 at 05:17:17PM +1000, Peter Crosthwaite wrote:
> Hi Greg,
> 
> Thanks for your reply on the mmunmap issue. Sorry about the delay on
> this correspondance.
> 
> I have looked into this bug in more detail. The
> alloc_bootmem_low_pages() call is falling back to a call to kzalloc(),
> so the address passed to UIO when used in UIO_MEM_LOGICAL is a return
> from kmalloc(). So my first question is, is kmalloc'ed memory
> supported by UIO?

Yes, of course. UIO_MEM_LOGICAL is the correct memtype for that. But
that applies only to memory you get _directly_ from kmalloc().
For example, dma_alloc_coherent() on ARM internally gets its memory from
kmalloc, too. But it needs a completely different mapping routine,
trying to map it using UIO_MEM_LOGICAL will fail.

> 
> With regards to the copying the data from the buffer to file, yes it
> is showing the correct data.
> 
> I have since resolved the BUG() by manually modifying the usage
> counters for the buffer pages from kernel space. i.e. Once the memory
> is kmalloc'ed the driver will iterate through all the pages and
> increment the _count field of the struct page. This will cause the
> pages to have a user count of 2 when mmaped (by user space) which
> reverts to 1 when unmapped. Now this fixes the bug, but should this
> manual increment be necessary? Is there a cleaner way in the kernel
> API for kernel space to mark itself as a user of a memory range or
> user space VMA?
> 
> You mentioned linking you up with the source code for my driver. Im
> trying to put together a minimal driver that replicates this bug, but
> it seems UIO enforces the need for a parent device when initialised.
> Considering this bug requires no actual hardware to replicate, is
> there a way to get a UIO device without a physical device to be able
> to test this behaviour in isolation?

There once was the uio_dummy driver. It maps some kmalloc'ed memory
to userspace and uses a timer to simulate interrupts. Just google
for "uio_dummy" and you'll find it. It's quite old (2.6.23), so it
will need some fixing. But it should give you the idea.

Thanks,
Hans

  reply	other threads:[~2010-07-21  9:09 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <AANLkTikuRjaAUF5KOn1QnVU8VnUiSNPkoKkkBdipXooY@mail.gmail.com>
2010-07-08 23:39 ` UIO: munmap bug for boot time allocated memory Greg KH
2010-07-21  7:17   ` Peter Crosthwaite
2010-07-21  9:09     ` Hans J. Koch [this message]
2010-07-11 23:51 Peter Crosthwaite

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=20100721090912.GC1669@local \
    --to=hjk@linutronix.de \
    --cc=gregkh@suse.de \
    --cc=john.williams@petalogix.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=michal.simek@petalogix.com \
    --cc=peter.crosthwaite@petalogix.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.