linux-kernel - Re: [PATCH 04/24] sysfs: Normalize removing sysfs directories.

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]

Message-ID: <4A21329A.10202@kernel.org>
Date:	Sat, 30 May 2009 22:20:26 +0900
From:	Tejun Heo <tj@...nel.org>
To:	"Eric W. Biederman" <ebiederm@...ssion.com>
CC:	Andrew Morton <akpm@...ux-foundation.org>,
	Greg Kroah-Hartman <gregkh@...e.de>,
	linux-kernel@...r.kernel.org,
	Cornelia Huck <cornelia.huck@...ibm.com>,
	linux-fsdevel@...r.kernel.org, Kay Sievers <kay.sievers@...y.org>,
	Greg KH <greg@...ah.com>,
	"Eric W. Biederman" <ebiederm@...stanetworks.com>
Subject: Re: [PATCH 04/24] sysfs: Normalize removing sysfs directories.

Hello,

Eric W. Biederman wrote:
> I guess we are going to have to disagree on this one.

Yeap, seems like it.

> My take is simply that a correct user has to wait until no one else
> can find the kobject before calling kobject_del.  At which point
> races are impossible, and it doesn't matter if sysfs_mutex is held
> across the entire operation.

This one also is a matter of degree.  Way back when users could crash
sysfs reliably from userland, the sysfs code had a lot of assumptions
about object lifetime and synchronizaion which even the sysfs code
itself didn't really follow leading to fragility.  My focus while
restructuring the code was to make the code behave as expected by the
usual conventions.  It could be that I'm a bit paranoid about this,
but in general I really don't like when low level code doesn't do its
due diligence to save several hours of effort to implement clean
semantics, but again there's nothing wrong with your due and my due
being different.

I guess I'll have to pass the buck to Greg again with my rather strong
NACK.

> For the long term I still intend to kill __sysfs_remove_dir.  Just
> not in this patch series.

Yeah, sysfs code is in the middle of two sane ways.  sysfs either has
to deal with children creation/removal including atomicity of the
operations or it should force its users to do so.  I prefer the former
but any would be better than the current situation.

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/