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>,
Dan Carpenter <dan.carpenter@oracle.com>,
Jonathan Corbet <corbet@lwn.net>,
Linus Torvalds <torvalds@linux-foundation.org>
Subject: Re: [PATCH v2 1/4] exfat: use upcase_ptable and upcase_range_info to reduce memory footprint
Date: Thu, 14 May 2026 19:34:55 +0900 [thread overview]
Message-ID: <71590543-ff2e-4f27-9be4-debc6157eba1@dev.snart.me> (raw)
In-Reply-To: <PUZPR04MB6316CE26A44D001F933B14B581062@PUZPR04MB6316.apcprd04.prod.outlook.com>
On 5/14/26 19:04, Yuezhang.Mo@sony.com wrote:
> A single bail label might seem simpler, but it obscures the pairing of
> resource allocation and release. Using multiple goto labels (e.g.,
> `err_free_upcase`, `err_shutdown_cache`), each cleanup operation perfectly
> matches an allocation step, and the reverse order is explicit.
>
> A unified bail approach enforces that each cleanup function can be safely
> called even if the resource was never allocated; while this is currently
> true, future additions of new cleanup functions might overlook this.
I dug further into this rabbit hole.
Turns out, this debate goes way back to early 2000s. A quick LLM prompt
revealed that numberous kernel devs already pointed it out and different
parts of the kernel have their own agenda(especially ARM and Netfilter
devs). I was just rediscovering it. A simple fs like exFAT will probably
never grow that much complexity (hopefully) so it wouldn't make much
difference on this matter.
I'm in no position to demand such changes to exFAT, but I'd be voicing a
different opinions on the projects I maintain. I will report back with
additional error labels in the fill_super() and module init function.
> I understand your point that currently known formatters all use default
> tables, and I agree that in practice, the probability of a non-default
> table unexpectedly matching the default checksum is extremely low, and
> such conflicts are extremely rare. However, theoretically, simply checking
> `utbl_checksum == EXFAT_DEF_UTBL_CHKSUM`, even with checking
> `tbl_size == EXFAT_NUM_UPCASE * 2`, is not rigorous.
Well, if we really want a rigorous one... I really don't know what we're
trying to prove here, but that I can probably whip out some sort of
algorithm to make sure all the 874 default entries are covered only once
using hasing, bit test or bitmap tricks. It could come out fairly
obsecure, but, well, as long as it's documented somewhere.
Stay tuned.
Davo
next prev parent reply other threads:[~2026-05-14 10:35 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-05-05 12:31 [PATCH v2 0/4] exfat: memory optimisations and stringent integrity checks for up-case table David Timber
2026-05-05 12:31 ` [PATCH v2 1/4] exfat: use upcase_ptable and upcase_range_info to reduce memory footprint David Timber
2026-05-07 12:03 ` Yuezhang.Mo
2026-05-10 22:22 ` David Timber
2026-05-14 10:04 ` Yuezhang.Mo
2026-05-14 10:34 ` David Timber [this message]
2026-05-05 12:31 ` [PATCH v2 2/4] exfat: optimise and refactor filename up-case conversion David Timber
2026-05-07 12:03 ` Yuezhang.Mo
2026-05-10 22:58 ` David Timber
2026-05-05 12:31 ` [PATCH v2 3/4] exfat: add default_upcase option (read-only) David Timber
2026-05-05 12:31 ` [PATCH v2 4/4] exfat: more pedantic upcase table validity check 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=71590543-ff2e-4f27-9be4-debc6157eba1@dev.snart.me \
--to=dxdt@dev.snart.me \
--cc=Yuezhang.Mo@sony.com \
--cc=corbet@lwn.net \
--cc=dan.carpenter@oracle.com \
--cc=linkinjeon@kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=sj1557.seo@samsung.com \
--cc=torvalds@linux-foundation.org \
/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