Re: [PATCH] sysfs: handle duplicate removal attempts insysfs_remove_group()

[James Bottomley]

On Fri, 2013-11-22 at 11:02 -0500, Tejun Heo wrote:
> Hello,
> 
> On Fri, Nov 22, 2013 at 08:43:55AM -0700, Bjorn Helgaas wrote:
> > > So, we do have cases where the parent is removed before the child.  I
> > > suppose the parent pci bridge is removed already?  AFAICS this
> > > shouldn't break anything but people did seem to expect the removals to
> > > be ordered from child to parent.  Bjorn, is this something you expect
> > > to happened?
> > 
> > I do not expect a PCI bridge to be removed before the devices below
> > it.  We should be removing all the children before removing the parent
> > bridge.
> > 
> > But is this related to PCI?  I don't see the connection yet.  I tried
> 
> I'm not sure.  It was from thunderbolt and nobody is reporting it on
> other interconnects, so it could be.
> 
> > to look into this a bit (my notes are at
> > https://bugzilla.kernel.org/show_bug.cgi?id=65281), but I haven't
> > figured out the big-picture problem yet.
> > 
> > I don't have warm fuzzies that adding a "have we already removed this"
> > check is the best resolution, but maybe that's just because I don't
> > understand the problem.
> 
> Yeah, the whole thing is sorta pointless.  Just issuing removal and
> continuing on should do, IMHO.

I'd go for that as well.  We have huge problems with the _del calls
because visibility is strict hierarchy and it's not always easy to work
out who's underneath us.

It's going to be really annoying when refcounting works perfectly for
objects, so you can just do puts in any order, but you have to have
_del() called to remove subordinate objects before their parent.

James

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/