Re: [PATCH 2/4] bcachefs: Optimize bch2_dirent_name_bytes

[Kent Overstreet <kent.overstreet@linux.dev>]

On Sat, Aug 12, 2023 at 03:47:46PM +0100, Joshua Ashton wrote:
> Avoids doing a full strnlen for getting the length of the name of a
> dirent entry.
> 
> Given the fact that the name of dirents is stored at the end of the
> bkey's value, and we know the length of that in u64s, we can find the
> last u64 and figure out how many NUL bytes are at the end of the string.
> 
> On little endian systems this ends up being the leading zeros of the
> last u64, whereas on big endian systems this ends up being the trailing
> zeros of the last u64.
> We can take that value in bits and divide it by 8 to get the number of
> NUL bytes at the end.
> 
> There is no endian-fixup or other compatibility here as this is string
> data interpreted as a u64.

This needs a bit more analysis:

If we ever screwed up and created dirents where there was a nul before
the last u64, this is going to change how those dirents are interpreted
- we'll now be returning longer dirents, but with an embedded nul.

Fortunately, bch2_dirent_invalid() checks for this, so we're good there.

But, your change does break the check in bch2_dirent_invalid(); we still
do need to check somehow that there aren't any embedded nuls. Can you
fix that too?