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: <4B73671E.2050105@kernel.org>
Date:	Thu, 11 Feb 2010 11:10:38 +0900
From:	Tejun Heo <tj@...nel.org>
To:	"Eric W. Biederman" <ebiederm@...ssion.com>
CC:	Greg KH <gregkh@...e.de>,
	Américo Wang <xiyou.wangcong@...il.com>,
	Neil Brown <neilb@...e.de>, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] sysfs: differentiate between locking links and non-links

Hello,

On 02/11/2010 10:31 AM, Eric W. Biederman wrote:
>> I think some code dynamically creates attributes today, as this has
>> never been a restriction.
>>
>> So I don't know if this is going to work :(
> 
> I need to see how locks do this, but they face the same problem.  For
> normal locks this is resolved by having a requirement to call a special
> initializer in the dynamic case.  Adding that requirement for the
> rare dynamically allocated sysfs attributes seems reasonable.

Yeah, this is the same problem all other constructus face too and the
reason why different variants of initializers are introduced for
lockdep support.  For dynamic ones, making the initializer declare
static key and using it to initialize lockdep_map should work.

> Additionally sysfs attributes are exactly the right granularity for
> lock classes because that is where the behavior is the same or
> changes.

Yeap.

> We have 845 instances of static struct attributes which certainly makes
> that the dominant case and worth aiming at.

Yeah, and sysfs will be following the usual convention of dealing with
these issues, which is the right thing to do.

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