mbox series

[v9,0/8] Clean up the case-insensitive lookup path

Message ID 20220913234150.513075-1-krisman@collabora.com
Headers show
Series Clean up the case-insensitive lookup path | expand

Message

Gabriel Krisman Bertazi Sept. 13, 2022, 11:41 p.m. UTC 
Hi,

I'm resubmitting this as v9 since I think it has fallen through the
cracks :).  It is a collection of trivial fixes for casefold support on
ext4/f2fs. More details below.

It has been sitting on the list for a while and most of it is r-b
already. I'm keeping the tags for this submission, since there is no
modifications from previous submissions, apart from a minor conflict
resolution when merging to linus/master.

Thanks,

v8: https://patchwork.ozlabs.org/project/linux-ext4/cover/20220519212359.19442-1-krisman@collabora.com/

* Original commit letter

The case-insensitive implementations in f2fs and ext4 have quite a bit
of duplicated code.  This series simplifies the ext4 version, with the
goal of extracting ext4_ci_compare into a helper library that can be
used by both filesystems.  It also reduces the clutter from many
codeguards for CONFIG_UNICODE; as requested by Linus, they are part of
the codeflow now.

While there, I noticed we can leverage the utf8 functions to detect
encoded names that are corrupted in the filesystem. Therefore, it also
adds an ext4 error on that scenario, to mark the filesystem as
corrupted.

This series survived passes of xfstests -g quick.

Gabriel Krisman Bertazi (8):
  ext4: Simplify the handling of cached insensitive names
  f2fs: Simplify the handling of cached insensitive names
  libfs: Introduce case-insensitive string comparison helper
  ext4: Reuse generic_ci_match for ci comparisons
  f2fs: Reuse generic_ci_match for ci comparisons
  ext4: Log error when lookup of encoded dentry fails
  ext4: Move CONFIG_UNICODE defguards into the code flow
  f2fs: Move CONFIG_UNICODE defguards into the code flow

 fs/ext4/crypto.c   |  15 ++----
 fs/ext4/ext4.h     |  34 +++++++-----
 fs/ext4/namei.c    | 130 ++++++++++++++++-----------------------------
 fs/ext4/super.c    |   4 +-
 fs/f2fs/dir.c      | 105 +++++++++++-------------------------
 fs/f2fs/f2fs.h     |  15 +++++-
 fs/f2fs/namei.c    |  11 ++--
 fs/f2fs/recovery.c |   5 +-
 fs/f2fs/super.c    |   8 +--
 fs/libfs.c         |  68 ++++++++++++++++++++++++
 include/linux/fs.h |   4 ++
 11 files changed, 198 insertions(+), 201 deletions(-)

Comments

Eric Biggers Sept. 23, 2022, 3:54 a.m. UTC | #1 
On Tue, Sep 13, 2022 at 07:41:42PM -0400, Gabriel Krisman Bertazi wrote:
> Hi,
> 
> I'm resubmitting this as v9 since I think it has fallen through the
> cracks :).  It is a collection of trivial fixes for casefold support on
> ext4/f2fs. More details below.
> 
> It has been sitting on the list for a while and most of it is r-b
> already. I'm keeping the tags for this submission, since there is no
> modifications from previous submissions, apart from a minor conflict
> resolution when merging to linus/master.

Who are you expecting to apply this?

- Eric
Gabriel Krisman Bertazi Sept. 23, 2022, 2:54 p.m. UTC | #2 
Eric Biggers <ebiggers@kernel.org> writes:

> On Tue, Sep 13, 2022 at 07:41:42PM -0400, Gabriel Krisman Bertazi wrote:
>> Hi,
>> 
>> I'm resubmitting this as v9 since I think it has fallen through the
>> cracks :).  It is a collection of trivial fixes for casefold support on
>> ext4/f2fs. More details below.
>> 
>> It has been sitting on the list for a while and most of it is r-b
>> already. I'm keeping the tags for this submission, since there is no
>> modifications from previous submissions, apart from a minor conflict
>> resolution when merging to linus/master.
>
> Who are you expecting to apply this?

Hi Eric,

There are three groups of changes here: libfs, ext4 and f2fs.  Since the
changes in libfs are self-contained and only affect these two
filesystems, I think it should be fine for them to go through a fs tree.

The bulk of changes are ext4, and Ted mentioned on an earlier version
that he could pick the first patches of this series, so I'm thinking it
should all go through the ext4 tree.  If Jaegeuk acks, the f2fs changes
are safe to go with the rest, or I can send them afterwards as a
separate series once the libfs code is merged.

Thanks,
Gabriel Krisman Bertazi Oct. 13, 2022, 11:45 p.m. UTC | #3 
Gabriel Krisman Bertazi <krisman@collabora.com> writes:

> Eric Biggers <ebiggers@kernel.org> writes:
>
>> On Tue, Sep 13, 2022 at 07:41:42PM -0400, Gabriel Krisman Bertazi wrote:
>>> Hi,
>>> 
>>> I'm resubmitting this as v9 since I think it has fallen through the
>>> cracks :).  It is a collection of trivial fixes for casefold support on
>>> ext4/f2fs. More details below.
>>> 
>>> It has been sitting on the list for a while and most of it is r-b
>>> already. I'm keeping the tags for this submission, since there is no
>>> modifications from previous submissions, apart from a minor conflict
>>> resolution when merging to linus/master.
>>
>> Who are you expecting to apply this?
>
> Hi Eric,
>
> There are three groups of changes here: libfs, ext4 and f2fs.  Since the
> changes in libfs are self-contained and only affect these two
> filesystems, I think it should be fine for them to go through a fs tree.
>
> The bulk of changes are ext4, and Ted mentioned on an earlier version
> that he could pick the first patches of this series, so I'm thinking it
> should all go through the ext4 tree.  If Jaegeuk acks, the f2fs changes
> are safe to go with the rest, or I can send them afterwards as a
> separate series once the libfs code is merged.

Ted,

Does the above plan work for you? Do you intend to pick this up for the
next merge window?
Muhammad Usama Anjum Dec. 8, 2022, 2:38 p.m. UTC | #4 
On 10/14/22 4:45 AM, Gabriel Krisman Bertazi wrote:
> Gabriel Krisman Bertazi <krisman@collabora.com> writes:
> 
>> Eric Biggers <ebiggers@kernel.org> writes:
>>
>>> On Tue, Sep 13, 2022 at 07:41:42PM -0400, Gabriel Krisman Bertazi wrote:
>>>> Hi,
>>>>
>>>> I'm resubmitting this as v9 since I think it has fallen through the
>>>> cracks :).  It is a collection of trivial fixes for casefold support on
>>>> ext4/f2fs. More details below.
>>>>
>>>> It has been sitting on the list for a while and most of it is r-b
>>>> already. I'm keeping the tags for this submission, since there is no
>>>> modifications from previous submissions, apart from a minor conflict
>>>> resolution when merging to linus/master.
>>>
>>> Who are you expecting to apply this?
>>
>> Hi Eric,
>>
>> There are three groups of changes here: libfs, ext4 and f2fs.  Since the
>> changes in libfs are self-contained and only affect these two
>> filesystems, I think it should be fine for them to go through a fs tree.
>>
>> The bulk of changes are ext4, and Ted mentioned on an earlier version
>> that he could pick the first patches of this series, so I'm thinking it
>> should all go through the ext4 tree.  If Jaegeuk acks, the f2fs changes
>> are safe to go with the rest, or I can send them afterwards as a
>> separate series once the libfs code is merged.
> 
> Ted,
> 
> Does the above plan work for you? Do you intend to pick this up for the
> next merge window?
It seems like this series hasn't been picked up. Any ideas on what can be done?
Gabriel Krisman Bertazi Dec. 9, 2022, 1:47 p.m. UTC | #5 
Muhammad Usama Anjum <usama.anjum@collabora.com> writes:

> On 10/14/22 4:45 AM, Gabriel Krisman Bertazi wrote:
>> Gabriel Krisman Bertazi <krisman@collabora.com> writes:
>> 
>>> Eric Biggers <ebiggers@kernel.org> writes:
>>>
>>>> On Tue, Sep 13, 2022 at 07:41:42PM -0400, Gabriel Krisman Bertazi wrote:
>>>>> Hi,
>>>>>
>>>>> I'm resubmitting this as v9 since I think it has fallen through the
>>>>> cracks :).  It is a collection of trivial fixes for casefold support on
>>>>> ext4/f2fs. More details below.
>>>>>
>>>>> It has been sitting on the list for a while and most of it is r-b
>>>>> already. I'm keeping the tags for this submission, since there is no
>>>>> modifications from previous submissions, apart from a minor conflict
>>>>> resolution when merging to linus/master.
>>>>
>>>> Who are you expecting to apply this?
>>>
>>> Hi Eric,
>>>
>>> There are three groups of changes here: libfs, ext4 and f2fs.  Since the
>>> changes in libfs are self-contained and only affect these two
>>> filesystems, I think it should be fine for them to go through a fs tree.
>>>
>>> The bulk of changes are ext4, and Ted mentioned on an earlier version
>>> that he could pick the first patches of this series, so I'm thinking it
>>> should all go through the ext4 tree.  If Jaegeuk acks, the f2fs changes
>>> are safe to go with the rest, or I can send them afterwards as a
>>> separate series once the libfs code is merged.
>> 
>> Ted,
>> 
>> Does the above plan work for you? Do you intend to pick this up for the
>> next merge window?
> It seems like this series hasn't been picked up. Any ideas on what can
> be done?

I got tired of the radio silence and gave up on it.  If there is interest,
feel free to respin it once more.