linux-kernel - Re: [PATCH] sysfs: handle duplicate removal attempts in sysfs_remove

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Mon, 25 Nov 2013 10:29:00 +0000
From:	James Bottomley <jbottomley@...allels.com>
To:	Tejun Heo <tj@...nel.org>
CC:	Bjorn Helgaas <bhelgaas@...gle.com>,
	Mika Westerberg <mika.westerberg@...ux.intel.com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
	"Rafael J. Wysocki" <rjw@...ysocki.net>
Subject: Re: [PATCH] sysfs: handle duplicate removal attempts in
 sysfs_remove_group()

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@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/