linux-next.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Greg KH <gregkh@linuxfoundation.org>
To: Li Zhong <zhong@linux.vnet.ibm.com>
Cc: linux-next list <linux-next@vger.kernel.org>,
	rusty@rustcorp.com.au, LKML <linux-kernel@vger.kernel.org>,
	rmk+kernel@arm.linux.org.uk
Subject: Re: [RFC PATCH next]module: Fix mod->mkobj.kobj potentially freed too early
Date: Wed, 21 Aug 2013 21:03:33 -0700	[thread overview]
Message-ID: <20130822040333.GB4821@kroah.com> (raw)
In-Reply-To: <1377138846.2633.25.camel@ThinkPad-T5421>

On Thu, Aug 22, 2013 at 10:34:06AM +0800, Li Zhong wrote:
> On Wed, 2013-08-21 at 09:18 -0700, Greg KH wrote:
> > On Wed, Aug 21, 2013 at 05:49:58PM +0800, Li Zhong wrote:
> > > DEBUG_KOBJECT_RELEASE helps to find the issue attached below.
> > > 
> > > After some investigation, it seems the reason is:
> > > The mod->mkobj.kobj(ffffffffa01600d0 below) is freed together with mod
> > > itself in free_module(). However, its children still hold references to
> > > it, as the delay caused by DEBUG_KOBJECT_RELEASE. So when the
> > > child(holders below) tries to decrease the reference count to its parent
> > > in kobject_del(), BUG happens as it tries to access already freed memory.
> > 
> > Ah, thanks for tracking this down.  I had seen this in my local testing,
> > but wasn't able to figure out the offending code.
> > 
> > > This patch tries to fix it by waiting for the mod->mkobj.kobj to be
> > > really released in the module removing process (and some error code
> > > paths).
> > 
> > Nasty, we should just be freeing the structure in the release function,
> > why doesn't that work?
> 
> Hi Greg,
> 
> It seems I didn't describe it clearly in the previous mail. I'm trying
> to do it better below: 
> 
> mod->mkobj.kobj is embedded in module_kobject(not a pointer):
> struct module_kobject {
>         struct kobject kobj;
> 	...
> 
> and allocated with the module memory. So we could see the parent below
> ffffffffa01600d0 is between MODULES_VADDR (ffffffffa0000000) and
> MODULES_END(ffffffffff000000). 
> 
> It seem to me that the mkobj.kobj is freed by module_free(mod,
> mod->module_core). 

Ick, you are right.  If a kobject is being embedded in an object, it
should control the lifespan of the object, not somewhere else like is
happening here.

The best solution for this is to make the kobject a pointer, not
embedded in the structure, that will fix this issue, right?

thanks,

greg k-h

  reply	other threads:[~2013-08-22  4:01 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-08-21  9:49 [RFC PATCH next]module: Fix mod->mkobj.kobj potentially freed too early Li Zhong
2013-08-21 16:18 ` Greg KH
2013-08-22  2:34   ` Li Zhong
2013-08-22  4:03     ` Greg KH [this message]
2013-08-22  5:37       ` Li Zhong
2013-08-22  7:37       ` [RFC PATCH v2 " Li Zhong
2013-08-22 21:58         ` Greg KH
2013-08-25  4:07         ` Greg KH
2013-08-27  4:38           ` Rusty Russell
2013-08-27  6:21             ` Greg KH
2013-09-01 23:51               ` Rusty Russell
2013-09-02  0:43                 ` Greg KH
2013-08-22  7:00   ` [RFC PATCH " Rusty Russell
2013-08-22  7:50     ` Li Zhong

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=20130822040333.GB4821@kroah.com \
    --to=gregkh@linuxfoundation.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-next@vger.kernel.org \
    --cc=rmk+kernel@arm.linux.org.uk \
    --cc=rusty@rustcorp.com.au \
    --cc=zhong@linux.vnet.ibm.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;
as well as URLs for NNTP newsgroup(s).