linux-kernel - Re: [PATCH 3/3] nilfs2: move ioctl interface and disk layout to uapi separately

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: <20160615.222713.1679449238980418194.konishi.ryusuke@lab.ntt.co.jp>
Date:	Wed, 15 Jun 2016 22:27:13 +0900 (JST)
From:	Ryusuke Konishi <konishi.ryusuke@....ntt.co.jp>
To:	Andrew Morton <akpm@...ux-foundation.org>
Cc:	linux-nilfs <linux-nilfs@...r.kernel.org>,
	LKML <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 3/3] nilfs2: move ioctl interface and disk layout to
 uapi separately

On Tue, 14 Jun 2016 15:29:52 -0700, Andrew Morton wrote:
> On Mon, 13 Jun 2016 22:45:07 +0900 Ryusuke Konishi <konishi.ryusuke@....ntt.co.jp> wrote:
> 
>> The header file "include/linux/nilfs2_fs.h" is composed of parts for
>> ioctl and disk format, and both are intended to be shared with user
>> space programs.
>> 
>> This moves them to the uapi directory "include/uapi/linux" splitting
>> the file to "nilfs2_api.h" and "nilfs2_ondisk.h".  The following minor
>> changes are accompanied by this migration:
>> 
>>  - nilfs_direct_node struct in nilfs2/direct.h is converged to
>>    nilfs2_ondisk.h because it's an on-disk structure.
>>  - inline functions nilfs_rec_len_from_disk() and
>>    nilfs_rec_len_to_disk() are moved to nilfs2/dir.c.
>> 
>> ...
>>
>> +static inline __le16 nilfs_rec_len_to_disk(unsigned int len)
>> +{
>> +#if (PAGE_SIZE >= 65536)
>> +	if (len == (1 << 16))
>> +		return cpu_to_le16(NILFS_MAX_REC_LEN);
>> +
>> +	BUG_ON(len > (1 << 16));
> 
> Is there any way in which the mount of a corrupted filesystem could
> trigger this BUG?  If so, that would be bad.

This BUG is never triggered in theory because the length is limited to
"chunk_size" by nilfs_check_page(), nilfs_make_empty(), etc, and the
chunk_size is limited to s_blocksize which is verified to be less than
or equal to NILFS_MAX_BLOCK_SIZE (= 65536) at mount time.

This time I didn't come up with a simple way to remove it - I hope to
clean it when refactoring the directory implementation.

Thanks,
Ryusuke Konishi


>> +#endif
>> +	return cpu_to_le16(len);
>> +}