All of lore.kernel.org
 help / color / mirror / Atom feed
From: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
To: Ankit Jindal <ajindal@apm.com>
Cc: linux-kernel@vger.kernel.org, "Hans J. Koch" <hjk@hansjkoch.de>,
	Pranavkumar Sawargaonkar <psawargaonkar@apm.com>,
	Jitendra Kanitkar <jkanitkar@apm.com>,
	Tushar Jagad <tjagad@apm.com>
Subject: Re: Unmapping of UIO logical memory causing a trace
Date: Wed, 19 Aug 2015 07:07:58 -0700	[thread overview]
Message-ID: <20150819140758.GA19776@kroah.com> (raw)
In-Reply-To: <CAJC5FUWNv8t6EVP0Nx2-etjMVZakXX1fi_ZiNOgGYm8EBbcA9w@mail.gmail.com>

On Wed, Aug 19, 2015 at 03:25:09PM +0530, Ankit Jindal wrote:
> Hi Greg,
> 
> On Wed, Aug 12, 2015 at 10:41 PM, Greg Kroah-Hartman
> <gregkh@linuxfoundation.org> wrote:
> > On Wed, Aug 12, 2015 at 01:25:53PM +0530, Ankit Jindal wrote:
> >> Hi Greg,
> >>
> >> On Wed, Aug 12, 2015 at 3:15 AM, Greg Kroah-Hartman
> >> <gregkh@linuxfoundation.org> wrote:
> >> > On Tue, Aug 11, 2015 at 04:39:08PM +0530, Ankit Jindal wrote:
> >> >> Hi,
> >> >>
> >> >> We have observed an issue where kmalloc of a small sized memory causes
> >> >> an occasional trace when unmapping the mmaped memory via UIO framework
> >> >> This trace is coming when kernel sees a negative value in
> >> >> page->_mapcount. Trace is pasted at the end of the mail.
> >> >>
> >> >> After debugging this issue further, we realized following sequence
> >> >> occurs when kmalloc is used to allocate small memory using slub
> >> >> allocator:
> >> >> 1. Frozen bit (msb) of the page from which memory has been allocated
> >> >> is set (which is an union with _mapcount).
> >> >> 2. If there are free objects in the the same page then this frozen bit
> >> >> remains set even after kernel boots completely.
> >> >> 3. When user space calls unmap of this memory, vma_unmap_single()
> >> >> treats the _mapcount as a negative (as frozen bit is set), causing a
> >> >> trace.
> >> >>
> >> >> We are not sure whether exposing kernel memory of size
> >> >> less than PAGE_SIZE via UIO is a valid use case ? In case this is an invalid
> >> >> use case then shouldn't the UIO framework restrict mapping of non
> >> >> PAGE_SIZE aligned memory and size not in order of PAGE_SIZE.
> >> >
> >> > We've had a few discussions about this in the past, and one proposed
> >> > patch which had to be reverted because it broke some working systems, so
> >> > it's a messy thing.
> >> >
> >> > What UIO driver are you using that causes this behavior?
> >>
> >> We have observed this during the development of new UIO driver for our
> >> soc. In our driver, we need to parse non probable properties of device
> >> and provide these details to our user application.
> >
> > What exactly do you mean by this?
> 
> There are certain the device specific properties (coming from device
> tree) which we are exposing using UIO_LOGICAL_MEM to the user space.

Why would you do that?  Userspace has the device tree info already
through other means.

> >> For this we do a kmalloc of device info(approx size 80 bytes) and pass
> >> this address to user space via UIO mem logical.
> >
> > For such tiny sizes, why not just use a normal sysfs file?
> 
> We did not think of sysfs as an option, since UIO_MEM_LOGICAL seems to
> address our use case.

Not for tiny memory chunks like you have seen :)

> > Do you have a pointer to your driver so that I can see exactly what it
> > is doing here?
> 
> Below is the code snippet of my driver.

<snip>

How about the whole driver please.

thanks,

greg k-h

      reply	other threads:[~2015-08-19 14:08 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-08-11 11:09 Unmapping of UIO logical memory causing a trace Ankit Jindal
2015-08-11 21:45 ` Greg Kroah-Hartman
2015-08-12  7:55   ` Ankit Jindal
2015-08-12 17:11     ` Greg Kroah-Hartman
2015-08-19  9:55       ` Ankit Jindal
2015-08-19 14:07         ` Greg Kroah-Hartman [this message]

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=20150819140758.GA19776@kroah.com \
    --to=gregkh@linuxfoundation.org \
    --cc=ajindal@apm.com \
    --cc=hjk@hansjkoch.de \
    --cc=jkanitkar@apm.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=psawargaonkar@apm.com \
    --cc=tjagad@apm.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.