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: <49CADB45.3090501@gmail.com>
Date:	Thu, 26 Mar 2009 10:32:53 +0900
From:	Tejun Heo <htejun@...il.com>
To:	"Eric W. Biederman" <ebiederm@...ssion.com>
CC:	Alex Chiang <achiang@...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

Hello,

Eric W. Biederman wrote:
>>> 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. :)

Thanks for the points.  I do agree that it could be a bit too clever,
but the thing is that protecting the code area from going underneath
something is a pretty special thing to begin with and I think it's
better to apply special solution rather than trying to work around it
using general mechanisms.  So, I actually think the global inhibit
thing is one of the better ways to deal with the nasty-in-nature
problem.

>>> 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 don't really see how some grand general solution would solve
deadlock problem at sysfs layer, care to elaborate a bit?

>> 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.
> 
> Sounds like it.    I'm not trying to shoot this down, rather
> I'm trying to figure out how to solve this cleanly, as I am slowly
> trying to sort out the pci hotplug and unplug issues.

The problem I see is that there aren't too many users and the solution
is a bit too narrow focused, but with increasing support for
hotplug/unplug, I think the problem is becoming more widespread and
the workqueue solution is quite fragile and cumbersome for each and
every user, so unless there are other directions we can pursue (the
general one above maybe?), I think it's better to add a bit of
complexity to sysfs rather than forcing everyone user of it to do it.

Thanks.

-- 
tejun
--
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/