On Mon, Sep 05, 2022 at 08:35:25PM -0400, Sweet Tea Dorminy wrote: > From: Omar Sandoval <osandov@xxxxxxxxxxx> > > Now that everything in btrfs is dealing in fscrypt_names, fscrypt has a > useful function, fscrypt_match_name(), to check whether a fscrypt_name > matches a provided buffer. However, btrfs buffers are struct > extent_buffer rather than a raw char array, so we need to implement our > own imitation of fscrypt_match_name() that deals in extent_buffers, > falling back to a simple memcpy if fscrypt isn't compiled. We > can then use this matching method in btrfs_match_dir_item_name() and > other locations. > > This also provides a useful occasion to introduce the new fscrypt file > for btrfs, handling the fscrypt-specific functions needed. > > Signed-off-by: Omar Sandoval <osandov@xxxxxxxxxxx> > Signed-off-by: Sweet Tea Dorminy <sweettea-kernel@xxxxxxxxxx> The code is fine, but I was very confused about why we do this sha256 thing. Perhaps point at the code for fscrypt_nokey_name and indicate that it exists to be interoperable with no-key actions on the file system. Thanks, Josef
|