[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <87v84w3f15.fsf@mailhost.krisman.be>
Date: Thu, 04 Apr 2024 19:05:10 -0400
From: Gabriel Krisman Bertazi <krisman@...e.de>
To: Eugen Hristev <eugen.hristev@...labora.com>
Cc: Eric Biggers <ebiggers@...nel.org>, tytso@....edu,
adilger.kernel@...ger.ca, linux-ext4@...r.kernel.org,
jaegeuk@...nel.org, chao@...nel.org,
linux-f2fs-devel@...ts.sourceforge.net, linux-fsdevel@...r.kernel.org,
brauner@...nel.org, jack@...e.cz, linux-kernel@...r.kernel.org,
viro@...iv.linux.org.uk, kernel@...labora.com
Subject: Re: [f2fs-dev] [PATCH v15 7/9] f2fs: Log error when lookup of
encoded dentry fails
Eugen Hristev <eugen.hristev@...labora.com> writes:
> On 4/3/24 07:25, Eric Biggers wrote:
>> On Tue, Apr 02, 2024 at 06:48:40PM +0300, Eugen Hristev via Linux-f2fs-devel wrote:
>>> If the volume is in strict mode, generi c_ci_compare can report a broken
>>> encoding name. This will not trigger on a bad lookup, which is caught
>>> earlier, only if the actual disk name is bad.
>>>
>>> Suggested-by: Gabriel Krisman Bertazi <krisman@...e.de>
>>> Signed-off-by: Eugen Hristev <eugen.hristev@...labora.com>
>>> ---
>>> fs/f2fs/dir.c | 15 ++++++++++-----
>>> 1 file changed, 10 insertions(+), 5 deletions(-)
>>>
>>> diff --git a/fs/f2fs/dir.c b/fs/f2fs/dir.c
>>> index 88b0045d0c4f..64286d80dd30 100644
>>> --- a/fs/f2fs/dir.c
>>> +++ b/fs/f2fs/dir.c
>>> @@ -192,11 +192,16 @@ static inline int f2fs_match_name(const struct inode *dir,
>>> struct fscrypt_name f;
>>>
>>> #if IS_ENABLED(CONFIG_UNICODE)
>>> - if (fname->cf_name.name)
>>> - return generic_ci_match(dir, fname->usr_fname,
>>> - &fname->cf_name,
>>> - de_name, de_name_len);
>>> -
>>> + if (fname->cf_name.name) {
>>> + int ret = generic_ci_match(dir, fname->usr_fname,
>>> + &fname->cf_name,
>>> + de_name, de_name_len);
>>> + if (ret == -EINVAL)
>>> + f2fs_warn(F2FS_SB(dir->i_sb),
>>> + "Directory contains filename that is invalid UTF-8");
>>> +
>>
>> Shouldn't this use f2fs_warn_ratelimited?
>
> f2fs_warn_ratelimited appears to be very new in the kernel,
>
> Krisman do you think you can rebase your for-next on top of latest such that this
> function is available ? I am basing the series on your for-next
> branch.
I try to make unicode/for-next a non-rebase branch, and I don't want to
pollute the tree with an unecessary backmerge. Instead, why not base
your work on a more recent branch, since it has no dependencies on
anything from unicode/for-next?
--
Gabriel Krisman Bertazi
Powered by blists - more mailing lists