linux-kernel - Re: [Ocfs2-devel] [PATCH] [ocfs2] Use a kobject instead of a kset

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] [day] [month] [year] [list]

Message-ID: <20110205184523.GB5091@dannf.org>
Date:	Sat, 5 Feb 2011 11:45:26 -0700
From:	dann frazier <dann.frazier@...onical.com>
To:	ocfs2-devel@....oracle.com, linux-kernel@...r.kernel.org
Subject: Re: [Ocfs2-devel] [PATCH] [ocfs2] Use a kobject instead of a kset

On Fri, Feb 04, 2011 at 09:58:01AM -0800, Joel Becker wrote:
> On Fri, Feb 04, 2011 at 09:40:27AM -0700, dann.frazier@...onical.com wrote:
> > From: dann frazier <dann.frazier@...onical.com>
> > 
> > We currently allocate a kset and add attributes to its internal kobject.
> > However, Documentation/kobject.txt says only the kset code should manipulate
> > this internal object, and we can get the same results by just creating our
> > own kobject and avoiding a kset altogether.
> 
> 	Hmm, is this actually valid?  I thought you had to be a kset to
> have children.  Did this change at some point?

hey Joel,
 Well, I'm by no means an expert on kobjects - hopefully someone who
is will chime in. I came across this while debugging a sysfs teardown
issue and looking through this code to see if it might be related. I
read through kobject.txt & saw that note about a kset's kobj being for
internal-use only, and then saw that samples/kobject/kobject-example.c
seems to achieve the same goal (a sysfs dir w/ attributes) w/o using a
kset.

The sysfs entries look the same to me before & after this patch:

$ ls -l /sys/fs/ocfs2
total 0
-r--r--r-- 1 root root 4096 Feb  5 11:40 active_cluster_plugin
-rw-r--r-- 1 root root 4096 Feb  5 11:40 cluster_stack
-r--r--r-- 1 root root 4096 Feb  5 11:40 loaded_cluster_plugins
-r--r--r-- 1 root root 4096 Feb  5 11:40 max_locking_protocol

That said, I haven't been able to demonstate that the current code is
causing any actual problems - this was just a cleanup attempt.
--
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/