[willy@infradead.org: Re: [willy@infradead.org: Re: [PATCH v4] fs: introduce is_dot_or_dotdot helper for cleanup]]

[willy@infradead.org: Re: [willy@infradead.org: Re: [PATCH v4] fs: introduce is_dot_or_dotdot helper for cleanup]]

[Matthew Wilcox]

I've tried to get Ted's opinion on this a few times with radio silence.
Or email is broken.  Anyone else care to offer an opinion?

----- Forwarded message from Matthew Wilcox <willy@infradead.org> -----

Date: Thu, 23 Jan 2020 21:11:43 -0800
From: Matthew Wilcox <willy@infradead.org>
To: "Theodore Y. Ts'o" <tytso@mit.edu>
Subject: Re: [willy@infradead.org: Re: [PATCH v4] fs: introduce
	is_dot_or_dotdot helper for cleanup]


ping?

On Mon, Dec 30, 2019 at 06:13:03AM -0800, Matthew Wilcox wrote:
> 
> Didn't see a response from you on this.  Can you confirm the three
> cases in ext4 mentioned below should be converted to return -EUNCLEAN?
> 
> ----- Forwarded message from Matthew Wilcox <willy@infradead.org> -----
> 
> Date: Thu, 12 Dec 2019 10:13:02 -0800
> From: Matthew Wilcox <willy@infradead.org>
> To: Eric Biggers <ebiggers@kernel.org>
> Cc: Tiezhu Yang <yangtiezhu@loongson.cn>, Alexander Viro
> 	<viro@zeniv.linux.org.uk>, "Theodore Y. Ts'o" <tytso@mit.edu>, Jaegeuk
> 	Kim <jaegeuk@kernel.org>, Chao Yu <yuchao0@huawei.com>, Tyler Hicks
> 	<tyhicks@canonical.com>, linux-fsdevel@vger.kernel.org,
> 	ecryptfs@vger.kernel.org, linux-fscrypt@vger.kernel.org,
> 	linux-f2fs-devel@lists.sourceforge.net, linux-kernel@vger.kernel.org
> Subject: Re: [PATCH v4] fs: introduce is_dot_or_dotdot helper for cleanup
> User-Agent: Mutt/1.12.1 (2019-06-15)
> 
> On Tue, Dec 10, 2019 at 11:19:13AM -0800, Eric Biggers wrote:
> > > +static inline bool is_dot_or_dotdot(const unsigned char *name, size_t len)
> > > +{
> > > +	if (unlikely(name[0] == '.')) {
> > > +		if (len < 2 || (len == 2 && name[1] == '.'))
> > > +			return true;
> > > +	}
> > > +
> > > +	return false;
> > > +}
> > 
> > This doesn't handle the len=0 case.  Did you check that none of the users pass
> > in zero-length names?  It looks like fscrypt_fname_disk_to_usr() can, if the
> > directory entry on-disk has a zero-length name.  Currently it will return
> > -EUCLEAN in that case, but with this patch it may think it's the name ".".
> 
> Trying to wrench this back on track ...
> 
> fscrypt_fname_disk_to_usr is called by:
> 
> fscrypt_get_symlink():
>        if (cstr.len == 0)
>                 return ERR_PTR(-EUCLEAN);
> ext4_readdir():
> 	Does not currently check de->name_len.  I believe this check should
> 	be added to __ext4_check_dir_entry() because a zero-length directory
> 	entry can affect both encrypted and non-encrypted directory entries.
> dx_show_leaf():
> 	Same as ext4_readdir().  Should probably call ext4_check_dir_entry()?
> htree_dirblock_to_tree():
> 	Would be covered by a fix to ext4_check_dir_entry().
> f2fs_fill_dentries():
> 	if (de->name_len == 0) {
> 		...
> ubifs_readdir():
> 	Does not currently check de->name_len.  Also affects non-encrypted
> 	directory entries.
> 
> So of the six callers, two of them already check the dirent length for
> being zero, and four of them ought to anyway, but don't.  I think they
> should be fixed, but clearly we don't historically check for this kind
> of data corruption (strangely), so I don't think that's a reason to hold
> up this patch until the individual filesystems are fixed.
> 
> ----- End forwarded message -----

----- End forwarded message -----

Re: [PATCH v4] fs: introduce is_dot_or_dotdot helper for cleanup

[Andreas Dilger]

[-- Attachment #1: Type: text/plain, Size: 4261 bytes --]

On Jan 28, 2020, at 3:11 PM, Matthew Wilcox <willy@infradead.org> wrote:
> 
> 
> I've tried to get Ted's opinion on this a few times with radio silence.
> Or email is broken.  Anyone else care to offer an opinion?

Maybe I'm missing something, but I think the discussion of the len == 0
case is now moot, since PATCH v6 (which is the latest version that I can
find) is checking for "len >= 1" before accessing name[0]:

+static inline bool is_dot_or_dotdot(const unsigned char *name, size_t len)
+{
+	if (len >= 1 && unlikely(name[0] == '.')) {
+		if (len == 1 || (len == 2 && name[1] == '.'))
+			return true;
+	}
+
+	return false;
+}

This seems a tiny bit sub-optimal, as (len >= 1) is true for almost every
filename, so it doesn't allow failing the condition quickly.  Checking
for exactly (len == 1) and (len == 2) allows failing this condition for
most of the files immediately, which makes "unlikely()" actually useful,
and allows simplifying the inside condition.

static inline bool is_dot_or_dotdot(const unsigned char *name, size_t len)
{
	if (unlikely((len == 1 || len == 2) && name[0] == '.')) {
		if (len == 1 || name[1] == '.')
			return true;
	}

	return false;
}

That said, this is at best micro-optimization so it isn't obvious this is
much of an improvement or not.

Cheers, Andreas

> On Mon, Dec 30, 2019 at 06:13:03AM -0800, Matthew Wilcox wrote:
>> 
>> Didn't see a response from you on this.  Can you confirm the three
>> cases in ext4 mentioned below should be converted to return -EUNCLEAN?
>> 
>> ----- Forwarded message from Matthew Wilcox <willy@infradead.org> -----
>> 
>> Date: Thu, 12 Dec 2019 10:13:02 -0800
>> From: Matthew Wilcox <willy@infradead.org>
>> To: Eric Biggers <ebiggers@kernel.org>
>> Cc: Tiezhu Yang <yangtiezhu@loongson.cn>, Alexander Viro
>> 	<viro@zeniv.linux.org.uk>, "Theodore Y. Ts'o" <tytso@mit.edu>, Jaegeuk
>> 	Kim <jaegeuk@kernel.org>, Chao Yu <yuchao0@huawei.com>, Tyler Hicks
>> 	<tyhicks@canonical.com>, linux-fsdevel@vger.kernel.org,
>> 	ecryptfs@vger.kernel.org, linux-fscrypt@vger.kernel.org,
>> 	linux-f2fs-devel@lists.sourceforge.net, linux-kernel@vger.kernel.org
>> Subject: Re: [PATCH v4] fs: introduce is_dot_or_dotdot helper for cleanup
>> User-Agent: Mutt/1.12.1 (2019-06-15)
>> 
>> On Tue, Dec 10, 2019 at 11:19:13AM -0800, Eric Biggers wrote:
>>>> +static inline bool is_dot_or_dotdot(const unsigned char *name, size_t len)
>>>> +{
>>>> +	if (unlikely(name[0] == '.')) {
>>>> +		if (len < 2 || (len == 2 && name[1] == '.'))
>>>> +			return true;
>>>> +	}
>>>> +
>>>> +	return false;
>>>> +}
>>> 
>>> This doesn't handle the len=0 case.  Did you check that none of the users pass
>>> in zero-length names?  It looks like fscrypt_fname_disk_to_usr() can, if the
>>> directory entry on-disk has a zero-length name.  Currently it will return
>>> -EUCLEAN in that case, but with this patch it may think it's the name ".".
>> 
>> Trying to wrench this back on track ...
>> 
>> fscrypt_fname_disk_to_usr is called by:
>> 
>> fscrypt_get_symlink():
>>       if (cstr.len == 0)
>>                return ERR_PTR(-EUCLEAN);
>> ext4_readdir():
>> 	Does not currently check de->name_len.  I believe this check should
>> 	be added to __ext4_check_dir_entry() because a zero-length directory
>> 	entry can affect both encrypted and non-encrypted directory entries.
>> dx_show_leaf():
>> 	Same as ext4_readdir().  Should probably call ext4_check_dir_entry()?
>> htree_dirblock_to_tree():
>> 	Would be covered by a fix to ext4_check_dir_entry().
>> f2fs_fill_dentries():
>> 	if (de->name_len == 0) {
>> 		...
>> ubifs_readdir():
>> 	Does not currently check de->name_len.  Also affects non-encrypted
>> 	directory entries.
>> 
>> So of the six callers, two of them already check the dirent length for
>> being zero, and four of them ought to anyway, but don't.  I think they
>> should be fixed, but clearly we don't historically check for this kind
>> of data corruption (strangely), so I don't think that's a reason to hold
>> up this patch until the individual filesystems are fixed.
>> 
>> ----- End forwarded message -----
> 
> ----- End forwarded message -----


Cheers, Andreas






[-- Attachment #2: Message signed with OpenPGP --]
[-- Type: application/pgp-signature, Size: 873 bytes --]

Re: [PATCH v4] fs: introduce is_dot_or_dotdot helper for cleanup

[Matthew Wilcox]

On Tue, Jan 28, 2020 at 06:23:18PM -0700, Andreas Dilger wrote:
> On Jan 28, 2020, at 3:11 PM, Matthew Wilcox <willy@infradead.org> wrote:
> > I've tried to get Ted's opinion on this a few times with radio silence.
> > Or email is broken.  Anyone else care to offer an opinion?
> 
> Maybe I'm missing something, but I think the discussion of the len == 0
> case is now moot, since PATCH v6 (which is the latest version that I can
> find) is checking for "len >= 1" before accessing name[0]:

Regardless of _this_ patch, the question is "Should ext4 be checking
for filenames of zero length and reporting -EUCLEAN if it finds any?"
I believe the answer is yes, since it's clearly a corrupted filesystem,
but I may be missing something.

Thanks for your reply.

> >> fscrypt_get_symlink():
> >>       if (cstr.len == 0)
> >>                return ERR_PTR(-EUCLEAN);
> >> ext4_readdir():
> >> 	Does not currently check de->name_len.  I believe this check should
> >> 	be added to __ext4_check_dir_entry() because a zero-length directory
> >> 	entry can affect both encrypted and non-encrypted directory entries.
> >> dx_show_leaf():
> >> 	Same as ext4_readdir().  Should probably call ext4_check_dir_entry()?
> >> htree_dirblock_to_tree():
> >> 	Would be covered by a fix to ext4_check_dir_entry().
> >> f2fs_fill_dentries():
> >> 	if (de->name_len == 0) {
> >> 		...
> >> ubifs_readdir():
> >> 	Does not currently check de->name_len.  Also affects non-encrypted
> >> 	directory entries.
> >> 
> >> So of the six callers, two of them already check the dirent length for
> >> being zero, and four of them ought to anyway, but don't.  I think they
> >> should be fixed, but clearly we don't historically check for this kind
> >> of data corruption (strangely), so I don't think that's a reason to hold
> >> up this patch until the individual filesystems are fixed.