linux-kernel - Re: [PATCH 1/3] add a private data field within kobj

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]

Date:	Mon, 03 Mar 2008 13:42:46 +0900
From:	Kohei KaiGai <kaigai@...jp.nec.com>
To:	Valdis.Kletnieks@...edu
CC:	greg@...ah.com, morgan@...nel.org, serue@...ibm.com,
	linux-security-module@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 1/3] add a private data field within kobj_attribute structure
 (final#2)

Valdis.Kletnieks@...edu wrote:
> On Mon, 25 Feb 2008 15:10:27 +0900, Kohei KaiGai said:
>> [PATCH 1/3] add a private data field within kobj_attribute structure.
> 
>> diff --git a/Documentation/kobject.txt b/Documentation/kobject.txt
>> index bf3256e..efa5d71 100644
>> --- a/Documentation/kobject.txt
>> +++ b/Documentation/kobject.txt
>> @@ -207,6 +207,12 @@ Both types of attributes used here, with a kobject that has been created
>>  with the kobject_create_and_add(), can be of type kobj_attribute, so no
>>  special custom attribute is needed to be created.
>>
>> +The simple kobj_attribute is prototyped at include/linux/kobject.h, and can
>> +contain your own show()/store() method and private data.
>> +When an attribute is accessed, these methods are invoked with kobject,
>> +kobj_attribute and read/write buffer. The method can refer the private data
>> +via given kobj_attribute, to show/store itself in the text representation.
>> +
>>  See the example module, samples/kobject/kobject-example.c for an
>>  implementation of a simple kobject and attributes.
> 
> OK, I'm an idiot, so I re-read this several times, and looked at patch 3/3
> that added the sample code, and I'm still confoozled.
> 
> Who creates/destroys/manages this "read/write buffer", and/or how does the
> method know how large a buffer is available, so (for example) it can use the
> strn* versions of string functions to be sure not to run off the end?  Does
> this buffer have any lifetime rules attached to it?

This "read/write buffer" is managed by sysfs filesystem.

Sysfs is invoked via kernel VFS subsystem, when user calls read(2) or write(2).
In the read(2) case, sysfs_read_file() is invoked, allocates a page for buffer,
and calls the show() method to generate the containts of this pseudo file entry.
Therefore, show() and store() method does not need to manage this buffer.

When store() method is invoked with data from userspace, sysfs terminate it with
'\0' implicitly. The size of buffer is also limited to PAGE_SIZE implicitly.

Can you make it clear?

Thanks,
-- 
OSS Platform Development Division, NEC
KaiGai Kohei <kaigai@...jp.nec.com>
--
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/