From: Veaceslav Falico <vfalico@redhat.com>
To: Rusty Russell <rusty@rustcorp.com.au>
Cc: Greg KH <gregkh@linuxfoundation.org>,
linux-kernel@vger.kernel.org, linux-pci@vger.kernel.org,
bhelgaas@google.com
Subject: Re: [PATCH] module: add kset_obj_exists() and use it
Date: Thu, 11 Apr 2013 07:05:43 +0200 [thread overview]
Message-ID: <20130411050543.GB21812@redhat.com> (raw)
In-Reply-To: <87vc7t4ymp.fsf@rustcorp.com.au>
On Thu, Apr 11, 2013 at 11:28:06AM +0930, Rusty Russell wrote:
>Greg KH <gregkh@linuxfoundation.org> writes:
>
>> On Tue, Apr 09, 2013 at 01:22:09PM +0200, Veaceslav Falico wrote:
>>> Add a new function, kset_obj_exists(), which is identical to
>>> kset_find_obj() but doesn't take a reference to the kobject
>>> found and only returns bool if found/not found.
>>>
>>> The main purpose would be to avoid the possible race scenario,
>>> when we could get the reference in between the kref_put() and
>>> kobject_release() functions (i.e. kref_put() already ran,
>>> refcount became 0, but the kobject_release() function still
>>> didn't run, and we try to get via kobject_get() and thus ending
>>> up with a released kobject). It can be triggered, for example,
>>> by running insmod/rmmod bonding in parallel, which ends up in
>>> a race between kset_obj_find() in mod_sysfs_init() and rmmod's
>>> mod_sysfs_fini()/kobject_put().
>>
>> As Rusty points out, this isn't a kobject issue that can be solved with
>> a new api call, but rather, the user of the kobject code needs to be
>> fixed, with something like his proposed patch instead.
>>
>> So, because of this, I can't take this patch, sorry.
>
>Greg, I'm shocked! Surely you've been doing this long enough to know
>that we don't use that kind of language on lkml?
>
>To restore the list's reputation as a hostile pressure cooker powered by
>the smouldering remains of flame-roasted newcomers, allow me to correct
>your reply:
>
> "NAK. And you smell."
Got it :). Thank you for your input and your patch, I'll come back with a
proper fix when I'll have one.
Thanks all.
>
>Crisis averted,
>Rusty.
>PS. Thanks :)
prev parent reply other threads:[~2013-04-11 5:05 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-04-09 11:22 [PATCH] module: add kset_obj_exists() and use it Veaceslav Falico
2013-04-10 7:17 ` Rusty Russell
2013-04-11 9:55 ` Veaceslav Falico
2013-04-11 13:28 ` Greg KH
2013-04-11 13:53 ` Veaceslav Falico
2013-04-11 15:20 ` Greg KH
2013-04-11 15:39 ` Veaceslav Falico
2013-04-15 2:26 ` Rusty Russell
2013-04-16 12:26 ` Veaceslav Falico
2013-04-17 3:55 ` Rusty Russell
2013-04-17 5:33 ` Veaceslav Falico
2013-04-10 17:27 ` Greg KH
2013-04-11 1:58 ` Rusty Russell
2013-04-11 5:05 ` Veaceslav Falico [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=20130411050543.GB21812@redhat.com \
--to=vfalico@redhat.com \
--cc=bhelgaas@google.com \
--cc=gregkh@linuxfoundation.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pci@vger.kernel.org \
--cc=rusty@rustcorp.com.au \
/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.