+Cc David Hi Guan-Chun,
If we need to respin this series, please Cc David when sending the next version. On Mon, Nov 03, 2025 at 11:24:35AM +0100, Andy Shevchenko wrote: > 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 <[email protected]> > > 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. > Since I didn't notice this build failure, I guess this happens during a W=1 build? Sorry for that. Maybe I should add W=1 compilation testing to my checklist before sending patches in the future. I also got an email from the kernel test robot with a duplicate initialization warning from the sparse tool [1], pointing to the same code. This implementation was based on David's previous suggestion [2] to first default all entries to -1 and then set the values for the 64 character entries. This was to avoid expanding the large 256 * 3 table and improve code readability. Hi David, Since I believe many people test and care about W=1 builds, I think we need to find another way to avoid this warning? Perhaps we could consider what you suggested: #define BASE64_REV_INIT(val_plus, val_comma, val_minus, val_slash, val_under) { \ [ 0 ... '+'-1 ] = -1, \ [ '+' ] = val_plus, val_comma, val_minus, -1, val_slash, \ [ '0' ] = 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, \ [ '9'+1 ... 'A'-1 ] = -1, \ [ 'A' ] = 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22, \ 23, 24, 25, 26, 27, 28, 28, 30, 31, 32, 33, 34, 35, \ [ 'Z'+1 ... '_'-1 ] = -1, \ [ '_' ] = val_under, \ [ '_'+1 ... 'a'-1 ] = -1, \ [ 'a' ] = 36, 37, 38, 39, 40, 41, 42, 43, 44, 45, 46, 47, 48, \ 49, 50, 51, 52, 53, 54, 55, 56, 57, 58, 59, 60, 61, \ [ 'z'+1 ... 255 ] = -1 \ } Or should we just expand the 256 * 3 table as it was before? [1]: https://lore.kernel.org/oe-kbuild-all/[email protected]/ [2]: https://lore.kernel.org/lkml/20250928195736.71bec9ae@pumpkin/ Regards, Kuan-Wei
