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: <4A14F2B9.5070703@kernel.org>
Date:	Thu, 21 May 2009 15:20:41 +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 03/20] sysfs: Remove now unnecessary error reporting suppression.

Eric W. Biederman wrote:
> Tejun Heo <tj@...nel.org> writes:
> 
>> Eric W. Biederman wrote:
>>> From: Eric W. Biederman <ebiederm@...ssion.com>
>>>
>>> Now that we use sysfs_rename_link in the places we previously
>>> used sysfs_create_link_nowarn we can remove sysfs_create_link_nowarn
>>> and all it's supporting infrastructure.
>> I'm not entirely sure why implementing a rename helper means that we
>> don't need nowarn version anymore.  Nothing really changed or is it
>> that the nowarn version wasn't too necessary anyway?
> 
> nowarn was used exclusively in the hand coded version of rename.  By
> switching the order I was able perform the operations such that even
> if the operation is ultimately a noop and are attempt to recreate the
> same link we won't have problems.
> 
> The two callers of device_rename are required (and do) perform locking
> to ensure the rename operation is safe.  So the exact implementation
> in the sysfs does not matter.  Although making it atomic would be
> ideal.
> 
> The nowarn helpers existed because the order was backwards in
> device rename and when a noop rename happened sysfs would mistakenly
> think there was a problem and complain.  I think the upper
> layers suppress that case now for a while at least it lead to
> a lot of spurious warnings.

But, still, removing the original link on failure doesn't sound too
enticing.  Wouldn't it be better to detect the noop special case and
do nothing instead of swapping the order?

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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ