linux-kernel - Re: [PATCH 22/24] sysfs: Make sysfs_rename

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: <4A210EFA.5080103@kernel.org>
Date:	Sat, 30 May 2009 19:48: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 22/24] sysfs: Make sysfs_rename_link atomic

Eric W. Biederman wrote:
> Tejun Heo <tj@...nel.org> writes:
> 
>> Eric W. Biederman wrote:
>>> From: Eric W. Biederman <ebiederm@...ssion.com>
>>>
>>> Use the existing sysfs_rename to make sysfs_rename_link an atomic
>>> operation that does less work.  While I am at add additional sanity
>>> checking to ensure it is a symlink I am renaming.
>>>
>>> Acked-by: Kay Sievers <kay.sievers@...y.org>
>>> Signed-off-by: Eric W. Biederman <ebiederm@...stanetworks.com>
>> It would be really nice to merge or group this together with the first
>> three patches.  Other than that,
> 
> Perfection is the enemy of the good on that one.  That just convolutes
> things unnecessarily, makes the patches harder to review, and requires
> additional testing.
>
> I much prefer to work in a tree without rewinding.

Everything is a matter of degree and I don't think my bar here was too
high.  Unless patches are in some exported tree and when the content
of the patchset changes (you're changing the behavior of the same code
two times), reordering patches is what's usually done.  When the end
results stay the same, reshuffling isn't that much of work, is it?

Well, I'm not the maintainer and things like this are mostly upto the
maintainer, so let's leave it to be decided by Greg.

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/