All of lore.kernel.org
 help / color / mirror / Atom feed
From: Sam Edwards <cfsworks@gmail.com>
To: Ilya Dryomov <idryomov@gmail.com>,
	Alex Markuze <amarkuze@redhat.com>,
	Viacheslav Dubeyko <slava@dubeyko.com>
Cc: Jeff Layton <jlayton@kernel.org>, Xiubo Li <xiubli@redhat.com>,
	ceph-devel@vger.kernel.org, linux-kernel@vger.kernel.org,
	Sam Edwards <CFSworks@gmail.com>
Subject: [PATCH v2 0/2] Bounce buffer for mds client decryption when vmalloc()
Date: Fri, 29 May 2026 20:06:44 -0700	[thread overview]
Message-ID: <20260530030646.85589-1-CFSworks@gmail.com> (raw)

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


             reply	other threads:[~2026-05-30  3:07 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-05-30  3:06 Sam Edwards [this message]
2026-05-30  3:06 ` [PATCH v2 1/2] ceph: pass fscrypt `tname` buffers directly Sam Edwards
2026-05-30  3:06 ` [PATCH v2 2/2] ceph: properly decrypt filenames in vmalloc() buffers Sam Edwards

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20260530030646.85589-1-CFSworks@gmail.com \
    --to=cfsworks@gmail.com \
    --cc=amarkuze@redhat.com \
    --cc=ceph-devel@vger.kernel.org \
    --cc=idryomov@gmail.com \
    --cc=jlayton@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=slava@dubeyko.com \
    --cc=xiubli@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.