linux-kernel - Re: [RFC PATCH 0/3] sysfs: allow suicide

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 for Android: free password hash cracker in your pocket

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

Message-ID: <20090325225414.GA11447@ldl.fc.hp.com>
Date:	Wed, 25 Mar 2009 16:54:14 -0600
From:	Alex Chiang <achiang@...com>
To:	"Eric W. Biederman" <ebiederm@...ssion.com>
Cc:	htejun@...il.com, greg@...ah.com, cornelia.huck@...ibm.com,
	stern@...land.harvard.edu, kay.sievers@...y.org,
	rusty@...tcorp.com.au, linux-kernel@...r.kernel.org
Subject: Re: [RFC PATCH 0/3] sysfs: allow suicide

* Eric W. Biederman <ebiederm@...ssion.com>:
> 
> Interesting.
> 
> Fixing a read/writer deadlock by allowing the writers to nest
> inside the readers.
> 
> My first impression is that it is too clever.

Clever points go to Tejun. All I did was refresh the series
slightly. :)

> Furthermore I think this is walking around the edges of a more
> general problem.   How should we serial hotplug and hotunplug
> in general.  In what context should remove methods run in.
> 
> My impression is that we have a huge hole in our infrastructure
> for hotplug drivers.  Problems like how do we get a user space
> context for the code to run in and how do we handle
> multiple hotplug actions for overlapping device trees from
> stomping on each other.
> 
> My hypothesis is once we solve this for the general case of
> device hotplug and removal we won't need special support from
> sysfs.  At least not in the suicidal way.

I agree that we have problems in our infrastructure, especially,
as you point out, overlapping device trees, etc.

I see your point about adding extra cruft into sysfs to work
around a special case while leaving the hard problem unsolved.

Perhaps the status quo is better. I do think that getting
suicidal sysfs attributes off the global workqueue is a band-aid
that actually helps, vs. the proposed patches here which are
questionable in nature.

Oh well.

Thanks for the comments.

/ac

> 
> We still have very weird cases such as the lock inversion that
> we have today between rtnl_lock and active reference count,
> coming from the networking code.
> 
> Eric
> 
--
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/