[PATCH v4 0/6] lib/base64: add generic encoder/decoder, migrate users

[Andy Shevchenko]

On Fri, Oct 31, 2025 at 09:09:47PM -0700, Andrew Morton wrote:
> On Wed, 29 Oct 2025 18:17:25 +0800 Guan-Chun Wu <409411716 at gms.tku.edu.tw> wrote:
> 
> > This series introduces a generic Base64 encoder/decoder to the kernel
> > library, eliminating duplicated implementations and delivering significant
> > performance improvements.
> > 
> > The Base64 API has been extended to support multiple variants (Standard,
> > URL-safe, and IMAP) as defined in RFC 4648 and RFC 3501. The API now takes
> > a variant parameter and an option to control padding. As part of this
> > series, users are migrated to the new interface while preserving their
> > specific formats: fscrypt now uses BASE64_URLSAFE, Ceph uses BASE64_IMAP,
> > and NVMe is updated to BASE64_STD.
> > 
> > On the encoder side, the implementation processes input in 3-byte blocks,
> > mapping 24 bits directly to 4 output symbols. This avoids bit-by-bit
> > streaming and reduces loop overhead, achieving about a 2.7x speedup compared
> > to previous implementations.
> > 
> > On the decoder side, replace strchr() lookups with per-variant reverse tables
> > and process input in 4-character groups. Each group is mapped to numeric values
> > and combined into 3 bytes. Padded and unpadded forms are validated explicitly,
> > rejecting invalid '=' usage and enforcing tail rules.
> 
> Looks like wonderful work, thanks.  And it's good to gain a selftest
> for this code.
> 
> > This improves throughput by ~43-52x.
> 
> Well that isn't a thing we see every day.

I agree with the judgement, the problem is that this broke drastically a build:

lib/base64.c:35:17: error: initializer overrides prior initialization of this subobject [-Werror,-Winitializer-overrides]
   35 |         [BASE64_STD] = BASE64_REV_INIT('+', '/'),
      |                        ^~~~~~~~~~~~~~~~~~~~~~~~~
lib/base64.c:26:11: note: expanded from macro 'BASE64_REV_INIT'
   26 |         ['A'] =  0,  1,  2,  3,  4,  5,  6,  7,  8,  9, 10, 11, 12, \
      |                  ^
lib/base64.c:35:17: note: previous initialization is here
   35 |         [BASE64_STD] = BASE64_REV_INIT('+', '/'),
      |                        ^~~~~~~~~~~~~~~~~~~~~~~~~
lib/base64.c:25:16: note: expanded from macro 'BASE64_REV_INIT'
   25 |         [0 ... 255] = -1, \
      |                       ^~
...
fatal error: too many errors emitted, stopping now [-ferror-limit=]
20 errors generated.


> : Decode:
> :   64B   ~1530ns  ->  ~80ns    (~19.1x)
> :   1KB  ~27726ns  -> ~1239ns   (~22.4x)
> 
> 
> : Encode:
> :   64B   ~90ns   -> ~32ns   (~2.8x)
> :   1KB  ~1332ns  -> ~510ns  (~2.6x)
> : 
> : Decode:
> :   64B  ~1530ns  -> ~35ns   (~43.7x)
> :   1KB ~27726ns  -> ~530ns  (~52.3x)
> 
> 
> : This change also improves performance: encoding is about 2.7x faster and
> : decoding achieves 43-52x speedups compared to the previous implementation.
> 
> : This change also improves performance: encoding is about 2.7x faster and
> : decoding achieves 43-52x speedups compared to the previous local
> : implementation.
> 
> 
> Do any of these callers spend a sufficient amount of time in this
> encoder/decoder for the above improvements to be observable/useful?
> 
> 
> I'll add the series to mm.git's mm-nonmm-unstable branch to give it
> linux-next exposure.  I ask the NVMe, ceph and fscrypt teams to check
> the code and give it a test in the next few weeks, thanks.  
> 

-- 
With Best Regards,
Andy Shevchenko