Bounce buffer for mds client decryption when vmalloc()

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/[email protected]/

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