All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Luís Henriques" <lhenriques@suse.de>
To: Jeff Layton <jlayton@kernel.org>
Cc: Xiubo Li <xiubli@redhat.com>, Ilya Dryomov <idryomov@gmail.com>,
	ceph-devel@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [RFC PATCH 0/2] Add support for snapshot names encryption
Date: Thu, 10 Mar 2022 17:34:58 +0000	[thread overview]
Message-ID: <87ilsl7ltp.fsf@brahms.olymp> (raw)
In-Reply-To: <20220310172616.16212-1-lhenriques@suse.de> ("Luís Henriques"'s message of "Thu, 10 Mar 2022 17:26:14 +0000")

Luís Henriques <lhenriques@suse.de> writes:

> Hi!
>
> So, I've changed this code back into and RFC as I'm not sure yet if this
> is it's final form.  I think the 2 patches in this series should probably
> be squashed into a single patch.  I decided to keep them separate as the
> 1st one is simple (it's the same patch I had already sent), and the 2nd
> patch adds a lot more complexity to the whole thing.
>
> So, I've looked at Xiubo initial patch for handling snapshots long names.
> It was complex, of course, and it required extra MDS changes.  I *think*
> my approach is slightly simpler, but I'm not entirely sure yet that I'm
> handling every case.
>
> In order to test this code the following PRs are required:
>
>   mds: add protection from clients without fscrypt support #45073
>   mds: use the whole string as the snapshot long name #45192
>   mds: support alternate names for snapshots #45224
>   mds: limit the snapshot names to 240 characters #45312
>
> Comments are welcome, I'm still testing these patches and I do expect to
> find that something is still missing.  And I do expect to find bugs.
> These strings parsing scares me a lot, but I couldn't see a simpler
> approach.

Again, I forgot to mention in the cover-letter that handling
base64-encoded snapshots that start with '_' is still missing.  That's
next on my list.

Cheers,
-- 
Luís

>
> Luís Henriques (2):
>   ceph: add support for encrypted snapshot names
>   ceph: add support for handling encrypted snapshot names in subtree
>
>  fs/ceph/crypto.c | 146 +++++++++++++++++++++++++++++++++++++++++------
>  fs/ceph/crypto.h |   9 ++-
>  fs/ceph/dir.c    |   9 +++
>  fs/ceph/inode.c  |  13 +++++
>  4 files changed, 156 insertions(+), 21 deletions(-)
>


      parent reply	other threads:[~2022-03-10 17:34 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-03-10 17:26 [RFC PATCH 0/2] Add support for snapshot names encryption Luís Henriques
2022-03-10 17:26 ` [RFC PATCH 1/2] ceph: add support for encrypted snapshot names Luís Henriques
2022-03-12  8:30   ` Xiubo Li
2022-03-14  2:45     ` Xiubo Li
2022-03-14  5:17       ` Xiubo Li
2022-03-14 11:07         ` Luís Henriques
2022-03-14 18:32         ` Luís Henriques
2022-03-15  7:28           ` Xiubo Li
2022-03-15 11:05             ` Luís Henriques
2022-03-10 17:26 ` [RFC PATCH 2/2] ceph: add support for handling encrypted snapshot names in subtree Luís Henriques
2022-03-14  8:54   ` Xiubo Li
2022-03-14 11:08     ` Luís Henriques
2022-03-10 17:34 ` Luís Henriques [this message]

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=87ilsl7ltp.fsf@brahms.olymp \
    --to=lhenriques@suse.de \
    --cc=ceph-devel@vger.kernel.org \
    --cc=idryomov@gmail.com \
    --cc=jlayton@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --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.