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
next prev parent 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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox