linux-kernel - Re: [PATCH] sysfs: differentiate between locking links and non-links

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: <m1mxzfzlv3.fsf@fess.ebiederm.org>
Date:	Thu, 11 Feb 2010 10:08:16 -0800
From:	ebiederm@...ssion.com (Eric W. Biederman)
To:	Tejun Heo <tj@...nel.org>
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

Tejun Heo <tj@...nel.org> writes:

> 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.

I have been playing with it and so far the code doesn't seem too bad. I have
however come across another misfeature of sysfs.  sysfs_get_active_two appears
to be unnecessary overkill.

The purpose of the active references are to allows us to block when
removing sysfs entries that have custom methods so we don't remove
modules or those custom methods don't remove access data structures
after the files have been removed.  Further sysfs_remove_dir remove
all elements in the directory before removing the directory itself, so
there is no chance we will remove a directory with active children.

Tejun do you know of any other reason we want sysfs_get_active_two?

If not I think we can make active references apply exclusively to attributes.

Eric
--
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/