linux-kernel - Re: [PATCH 6/9] exofs: super_operations and file_system

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: <494A0CAC.2010700@panasas.com>
Date:	Thu, 18 Dec 2008 10:41:16 +0200
From:	Boaz Harrosh <bharrosh@...asas.com>
To:	Marcin Slusarz <marcin.slusarz@...il.com>
CC:	Avishay Traeger <avishay@...il.com>, Jeff Garzik <jeff@...zik.org>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Al Viro <viro@...IV.linux.org.uk>,
	linux-fsdevel <linux-fsdevel@...r.kernel.org>,
	open-osd <osd-dev@...n-osd.org>,
	linux-kernel <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 6/9] exofs: super_operations and file_system_type

Marcin Slusarz wrote:
> On Tue, Dec 16, 2008 at 05:31:30PM +0200, Boaz Harrosh wrote:
>> This patch ties all operation vectors into a file system superblock
>> and registers the exofs file_system_type at module's load time.
>>
>> * The file system control block (AKA on-disk superblock) resides in
>>   an object with a special ID (defined in common.h).
>>   Information included in the file system control block is used to
>>   fill the in-memory superblock structure at mount time. This object
>>   is created before the file system is used by mkexofs.c It contains
>>   information such as:
>> 	- The file system's magic number
>> 	- The next inode number to be allocated
>>
>> Signed-off-by: Boaz Harrosh <bharrosh@...asas.com>
> 
> Some minor comments below.
> 

Thank you Marcin for your comments. They are all true and I will
fix them.

Just as a side note, most of your comments are on code inherited from
ext2. Though it is a good chance to fix them here.

>> ---
<snip>
>> +	sbi = kzalloc(sizeof(*sbi), GFP_KERNEL);
>> +	if (!sbi)
>> +		return -ENOMEM;
>> +	sb->s_fs_info = sbi;
>> +
>> +	/* use mount options to fill superblock */
>> +	sbi->s_dev = osduld_path_lookup(opts->dev_name);
>> +	if (IS_ERR(sbi->s_dev)) {
>> +		ret = PTR_ERR(sbi->s_dev);
>> +		sbi->s_dev = NULL;
>> +		goto free_sbi;
>> +	}
>> +
>> +	sbi->s_pid = opts->pid;
>> +	sbi->s_timeout = opts->timeout;
>> +
>> +	/* fill in some other data by hand */
>> +	memset(sb->s_id, 0, sizeof(sb->s_id));
> 
> wasn't it zeroed by kzalloc?
> 

That is a different kzalloc, though I agree that a memset is a bit hysterical
for a strcpy

>> +	strcpy(sb->s_id, "exofs");

Thanks
Boaz
--
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/