Hi Ceph maintainers,

This is version 2 of my previous patchset to resolve fscrypt oops/panic when
decrypting filenames from a MDS message that spilled into the vmalloc area. [1]

Cheers,
Sam

Changes v1->v2:
- As Slava pointed out, v1 was performing `snprintf(..., oname->name)` *before*
  the memcpy() that makes `oname->name` valid. He also raised a great point
  about the if/else-if block's complexity. This version simplifies the control
  flow structure.
- Reformat some whitespace and remove unnecessary linebreaks, going a little
  over the 80-column soft limit, but improving readability.

Feedback not addressed:
- David shared some discomfort about fscrypt_fname_alloc_buffer() sometimes
  changing the allocation length, but it only ever lengthens the allocation and
  is therefore always at least NAME_MAX.
- David also began some discussion around passing an explicit `tname` length;
  I'm still open to the idea, but would like to get a consensus around that
  first, because enforcing the buffer size will likely require changes to the
  base64_{de,en}code() function prototypes to accept buffer sizes.

[1] https://lore.kernel.org/ceph-devel/20260527025828.5966-1-CFSworks@gmail.com/

Sam Edwards (2):
  ceph: pass fscrypt `tname` buffers directly
  ceph: properly decrypt filenames in vmalloc() buffers

 fs/ceph/crypto.c     | 50 ++++++++++++++++++++++++++++++++------------
 fs/ceph/crypto.h     |  4 ++--
 fs/ceph/mds_client.c | 12 +++++++----
 3 files changed, 47 insertions(+), 19 deletions(-)

-- 
2.53.0