From: Rusty Russell <rusty@rustcorp.com.au>
To: Greg KH <gregkh@linuxfoundation.org>
Cc: Li Zhong <zhong@linux.vnet.ibm.com>,
linux-next list <linux-next@vger.kernel.org>,
LKML <linux-kernel@vger.kernel.org>,
rmk+kernel@arm.linux.org.uk
Subject: Re: [RFC PATCH v2 next]module: Fix mod->mkobj.kobj potentially freed too early
Date: Mon, 02 Sep 2013 09:21:55 +0930 [thread overview]
Message-ID: <871u58ayn8.fsf@rustcorp.com.au> (raw)
In-Reply-To: <20130827062135.GA3395@kroah.com>
Greg KH <gregkh@linuxfoundation.org> writes:
> On Tue, Aug 27, 2013 at 02:08:27PM +0930, Rusty Russell wrote:
>> Greg KH <gregkh@linuxfoundation.org> writes:
>> > On Thu, Aug 22, 2013 at 03:37:55PM +0800, Li Zhong wrote:
>> >> DEBUG_KOBJECT_RELEASE helps to find the issue attached below.
>> > People are starting to hit these types of issues, and I'd like to take
>> > this one out of the picture.
>> >
>> > Rusty, any objection to me taking this through my driver-core tree,
>> > where this new config option shows up?
>>
>> The original fix was better.
>>
>> Moving the module_kobject out and giving it its own lifetime solves this
>> immediate issue, but it still means there's an accessible module_kobject
>> around referring to a module which doesn't exist any more.
>
> That's ok, it could happen before as well. What's wrong with that?
>
>> Original copied below, feel free to take it.
>
> You are just sitting and sleeping until someone drops the last reference
> to the module. What if userspace grabs a reference from sysfs? That
> could never return, I don't think you want to stall that out.
In your scenario, what happens if userspace grabs a reference via sysfs?
It then tries to use module_kobj->mod which points into freed memory?
eg. show_modinfo_##field or show_refcnt.
Is there an owner field I'm missing somewhere which stops this from
happening? Otherwise, we can't unload the module until it's done.
> I'd prefer not having 2 things determining the lifecycle of a single
> object, that's messy, and not needed at all.
Normally you'd grab a reference to the module via an owner pointer.
Doing that in kobject seems like overkill, so we're working around it
here...
Hope that clarifies,
Rusty.
next prev parent reply other threads:[~2013-09-01 23:51 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
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 [this message]
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=871u58ayn8.fsf@rustcorp.com.au \
--to=rusty@rustcorp.com.au \
--cc=gregkh@linuxfoundation.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-next@vger.kernel.org \
--cc=rmk+kernel@arm.linux.org.uk \
--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).