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

[Joshua Ashton <joshua@froggi.es>]

On 8/12/23 17:23, Kent Overstreet wrote:
> 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?

Yes. I have fixed this locally by ensuring strlen(name.name, name.len) 
== name.len now in bch2_dirent_invalid.

- Joshie 🐸✨