linux-kernel - Re: [PATCH 04/20] sysfs: Handle the general case of removing of directories with subdirectories

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:	Thu, 21 May 2009 18:28:46 +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,
	"Eric W. Biederman" <ebiederm@...stanetworks.com>
Subject: Re: [PATCH 04/20] sysfs: Handle the general case of removing of directories
 with subdirectories

Hello, Eric.

Eric W. Biederman wrote:
> Tejun Heo <tj@...nel.org> writes:
> 
>> Well, it can be trivially fixed by checking the removed flag.  The
>> add/rm thing is designed to help additions and removals of multiple
>> nodes at one go and I'd really like to see it working that way.  Any
>> chance you can change code toward that direction?
> 
> Yes.  We definitely need to check the removed flag in sysfs_add_one.
> Regardless of anything else.
> 
> I need to sleep on this but I am inclined to get rid of the rest of
> the complications simply by failing the removal of non-empty
> directories.  Going through the upper layers and making them properly
> responsible for their actions.
> 
> I am afraid friendlier in this circumstance might equate to easier
> to misuse and let code bugs pile up.

I'm going through the latter part of the patchset and the code around
this area gets much simpler there.  Would it be possible to make it
atomic after the simplification?  Requiring recursive deletion from
all the callers is silly and error prone.

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/