From mboxrd@z Thu Jan 1 00:00:00 1970 From: Tejun Heo Subject: Re: [PATCH 04/20] sysfs: Handle the general case of removing of directories with subdirectories Date: Thu, 21 May 2009 18:28:46 +0900 Message-ID: <4A151ECE.50800@kernel.org> References: <1242865694-2100-1-git-send-email-ebiederm@xmission.com> <1242865694-2100-2-git-send-email-ebiederm@xmission.com> <1242865694-2100-3-git-send-email-ebiederm@xmission.com> <1242865694-2100-4-git-send-email-ebiederm@xmission.com> <4A14F356.3030501@kernel.org> <4A15046A.10106@kernel.org> <4A1512E2.2040505@kernel.org> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Andrew Morton , Greg Kroah-Hartman , linux-kernel@vger.kernel.org, Cornelia Huck , linux-fsdevel@vger.kernel.org, "Eric W. Biederman" To: "Eric W. Biederman" Return-path: Received: from hera.kernel.org ([140.211.167.34]:41164 "EHLO hera.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751051AbZEUJ3G (ORCPT ); Thu, 21 May 2009 05:29:06 -0400 In-Reply-To: Sender: linux-fsdevel-owner@vger.kernel.org List-ID: Hello, Eric. Eric W. Biederman wrote: > Tejun Heo 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