On Sat, 2018-07-21 at 09:53 +0200, Greg Kroah-Hartman wrote:
> > > So I hate using kobject_get_unless_zero(), and resisted ever adding it
> > > to the tree as it shows a bad locking/tree situation as you point out
> > > here. But for some reason, the block developers seemed to insist they
> > > ne
On Tue, Jul 10, 2018 at 09:44:33AM +1000, Benjamin Herrenschmidt wrote:
> On Sat, 2018-07-07 at 18:48 +0200, Greg Kroah-Hartman wrote:
> > No, kobject_get() should never happen on a 0 refcount object. That
> > being said, the code does allow it, so if things are messed up, it will
> > happen. I t
On Tue, 2018-07-10 at 16:55 -0700, Linus Torvalds wrote:
> On Tue, Jul 10, 2018 at 4:32 PM Benjamin Herrenschmidt
> wrote:
> >
> > > I like that fix, which should make this patch obsolete, right?
> >
> > Yes, for that specific issue, but Linus seemed to think patch 1 was the
> > "right thing to
On Tue, Jul 10, 2018 at 4:32 PM Benjamin Herrenschmidt
wrote:
>
> > I like that fix, which should make this patch obsolete, right?
>
> Yes, for that specific issue, but Linus seemed to think patch 1 was the
> "right thing to do" regardless...
I would definitely prefer either a kobject_get_unless_
On Tue, 2018-07-10 at 16:55 +0200, Greg Kroah-Hartman wrote:
> On Tue, Jul 10, 2018 at 09:44:33AM +1000, Benjamin Herrenschmidt wrote:
> > On Sat, 2018-07-07 at 18:48 +0200, Greg Kroah-Hartman wrote:
> > > No, kobject_get() should never happen on a 0 refcount object. That
> > > being said, the cod
On Tue, Jul 10, 2018 at 09:44:33AM +1000, Benjamin Herrenschmidt wrote:
> On Sat, 2018-07-07 at 18:48 +0200, Greg Kroah-Hartman wrote:
> > No, kobject_get() should never happen on a 0 refcount object. That
> > being said, the code does allow it, so if things are messed up, it will
> > happen. I t
On Sat, 2018-07-07 at 18:51 +0200, Greg Kroah-Hartman wrote:
>
> > diff --git a/drivers/base/core.c b/drivers/base/core.c
> > index b610816eb887..e9eff2099896 100644
> > --- a/drivers/base/core.c
> > +++ b/drivers/base/core.c
> > @@ -1517,11 +1517,13 @@ static struct kobject *get_device_parent(str
On Sat, 2018-07-07 at 18:48 +0200, Greg Kroah-Hartman wrote:
> No, kobject_get() should never happen on a 0 refcount object. That
> being said, the code does allow it, so if things are messed up, it will
> happen. I think that change happened when the switch to refcount_t
> occured, before then w
On Fri, Jun 29, 2018 at 12:21:51PM +1000, Benjamin Herrenschmidt wrote:
> Under some circumstances (such as when using kobject debugging)
> a gluedir whose kref is 0 might remain in the class kset for
> a long time. The reason is that we don't actively remove glue
> dirs when they become empty, but
On Sat, Jun 30, 2018 at 12:45:21PM -0700, Linus Torvalds wrote:
> On Thu, Jun 28, 2018 at 7:21 PM Benjamin Herrenschmidt
> wrote:
> >
> > Under some circumstances (such as when using kobject debugging)
> > a gluedir whose kref is 0 might remain in the class kset for
> > a long time. The reason is
On Thu, Jun 28, 2018 at 7:21 PM Benjamin Herrenschmidt
wrote:
>
> Under some circumstances (such as when using kobject debugging)
> a gluedir whose kref is 0 might remain in the class kset for
> a long time. The reason is that we don't actively remove glue
> dirs when they become empty, but instea
Under some circumstances (such as when using kobject debugging)
a gluedir whose kref is 0 might remain in the class kset for
a long time. The reason is that we don't actively remove glue
dirs when they become empty, but instead rely on the implicit
removal done by kobject_release(), which can happe
12 matches
Mail list logo
