Linux filesystem development
 help / color / mirror / Atom feed
From: David Timber <dxdt@dev.snart.me>
To: "Yuezhang.Mo@sony.com" <Yuezhang.Mo@sony.com>,
	Namjae Jeon <linkinjeon@kernel.org>,
	Sungjong Seo <sj1557.seo@samsung.com>
Cc: "linux-fsdevel@vger.kernel.org" <linux-fsdevel@vger.kernel.org>
Subject: Re: [PATCH v1 2/4] exfat: use upcase_ptable and upcase_range_info to reduce memory footprint
Date: Thu, 30 Apr 2026 18:45:48 +0900	[thread overview]
Message-ID: <79b70927-e766-4487-bbda-2481288a0f31@dev.snart.me> (raw)
In-Reply-To: <PUZPR04MB6316657C9EB764F8A3A119AB81352@PUZPR04MB6316.apcprd04.prod.outlook.com>

On 4/30/26 16:58, Yuezhang.Mo@sony.com wrote:
>> +static inline __u16 exfat_lookup_upcase_ptable(const struct exfat_upcase_ptable *ptbl,
>> +             const __u16 index)
>> +{
>> +     const size_t page_idx = index / EXFAT_UPTBL_PAGESIZE;
>> +     const size_t idx_in_page = index % EXFAT_UPTBL_PAGESIZE;
>> +
>> +     return ptbl->pages[page_idx] == NULL ? 0 : ptbl->pages[page_idx][idx_in_page];
>  
> How about this? Then we won't need to check it again in exfat_toupper().
>  
> return ptbl->pages[page_idx] == NULL ? index : ptbl->pages[page_idx][idx_in_page]; 

Zero(invalid character in exFAT spec) is used as identity within the
kernel. We'll have to be a bit careful. I'd have to change this logic in
exfat_load_upcase_table()

                ret = exfat_set_upcase_ptable(upcase_table, index, uni);
                if (ret) {
                    brelse(bh);
                    goto err;
                }

                def_upcase =
exfat_lookup_upcase_ptable(&default_upcase_table,
                                    index);
                is_default &= def_upcase == uni;

Some OOB data check will be ignored:

 - the character is "skipped": zero
 - the character is not skipped or specified as identity: non-zero

Subtle difference. If we change exfat_lookup_upcase_ptable() to return
identity on non-existent mapping, that information is lost, I think. But
again, the resulting contents would be the same regardless so I think
there isn't really a side effect.

>> +}
>> +
>> +void exfat_free_upcase_ptable(struct exfat_upcase_ptable *ptbl);
>> +int exfat_populate_upcase_ptable(struct exfat_upcase_ptable *ptbl,
>> +             const struct exfat_upcase_range_info *ri,
>> +             const size_t cnt);
>> +
>>  /* exfat/tables.c */
>>  /* Upcase table macro */
>> -#define EXFAT_NUM_UPCASE     (2918)
>> -#define EXFAT_UTBL_COUNT     (0x10000)
>> +#define EXFAT_DEF_UTBL_RI_COUNT      (112)
>> +#define EXFAT_DEF_UTBL_CHKSUM        (0xE619D30D)
>>  
>> -extern const unsigned short exfat_uni_def_upcase[EXFAT_NUM_UPCASE];
>> +extern const struct exfat_upcase_range_info exfat_def_utbl_ri[EXFAT_DEF_UTBL_RI_COUNT];
>  
> Is there a way to reduce the size of `exfat_def_utbl_ri` so that we
> can put it on the stack of `exfat_init_default_upcase_ptable()`?
>  
> If not, add `__initconst` for `exfat_def_utbl_ri`.
>  
Nah. It's as packed as it could get without breaking the alignment. We
could pack it down to 784 bytes, but that's still a lot of stack usage IMO.

>> +int exfat_init_default_upcase_ptable(void)
>  
> Add __init.
>  
>> +void exfat_free_default_upcase_ptable(void)
>  
> Add __exit.
Thanks.

>> @@ -896,6 +896,12 @@ static int __init init_exfat_fs(void)
>>  {
>>       int err;
>>  
>> +     err = exfat_init_default_upcase_ptable();
>> +     if (err) {
>> +             WARN_ON(err == -EINVAL);
>> +             return err;
>> +     }
>> +
>>       err = exfat_cache_init();
>>       if (err)
>>               return err;
>  
> Please add error handling to release default_upcase_ptable.
>  
>> +
>> +int exfat_populate_upcase_ptable(struct exfat_upcase_ptable *ptbl,
>> +             const struct exfat_upcase_range_info *ri,
>> +             const size_t cnt)
>                                                                                                                                                                                         
> This function is only called by exfat_init_default_upcase_ptable(),
> how about merge this function to it?
>  
default_upcase_ptable is already freed up before returning from
exfat_init_default_upcase_ptable() upon error. I made
exfat_populate_upcase_ptable() as a separate function to use it on my
test cases. The compiler inlines the function anyway(although
appropriate attributes are missing in the original patch, my bad) so
there's no ELF overhead either. I'd like to leave it as it is, if that's
okay.


  reply	other threads:[~2026-04-30  9:45 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-04-28 23:50 [PATCH v1 0/4] exfat: memory optimisations and stringent integrity checks for up-case table David Timber
2026-04-28 23:50 ` [PATCH v1 1/4] exfat: refactor nls.c (tables) David Timber
2026-04-30  7:53   ` Yuezhang.Mo
2026-04-30  9:22     ` David Timber
2026-05-03  8:03       ` David Timber
2026-04-28 23:50 ` [PATCH v1 2/4] exfat: use upcase_ptable and upcase_range_info to reduce memory footprint David Timber
2026-04-30  7:58   ` Yuezhang.Mo
2026-04-30  9:45     ` David Timber [this message]
2026-04-30 11:48       ` Yuezhang.Mo
2026-04-30 17:13         ` David Timber
2026-04-28 23:50 ` [PATCH v1 3/4] exfat: add default_upcase option (read-only) David Timber
2026-04-28 23:50 ` [PATCH v1 4/4] exfat: more pedantic upcase table validity check David Timber
2026-04-30  7:58   ` Yuezhang.Mo
2026-04-30  9:24     ` David Timber
2026-05-01 11:27       ` Namjae Jeon
2026-05-01 12:20         ` David Timber

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=79b70927-e766-4487-bbda-2481288a0f31@dev.snart.me \
    --to=dxdt@dev.snart.me \
    --cc=Yuezhang.Mo@sony.com \
    --cc=linkinjeon@kernel.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=sj1557.seo@samsung.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox