ceph-devel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Luís Henriques" <lhenriques@suse.de>
To: Eric Biggers <ebiggers@kernel.org>
Cc: Xiubo Li <xiubli@redhat.com>, Jeff Layton <jlayton@kernel.org>,
	"Theodore Y. Ts'o" <tytso@mit.edu>,
	Jaegeuk Kim <jaegeuk@kernel.org>,
	Ilya Dryomov <idryomov@gmail.com>,
	linux-fscrypt@vger.kernel.org, ceph-devel@vger.kernel.org,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH 2/2] ceph: switch atomic open to use new fscrypt helper
Date: Mon, 13 Mar 2023 18:42:01 +0000	[thread overview]
Message-ID: <87cz5cv6h2.fsf@suse.de> (raw)
In-Reply-To: <ZA9nPXNpBX0U5joC@sol.localdomain> (Eric Biggers's message of "Mon, 13 Mar 2023 11:11:09 -0700")

Eric Biggers <ebiggers@kernel.org> writes:

> On Mon, Mar 13, 2023 at 12:33:10PM +0000, Luís Henriques wrote:
>> Switch ceph atomic open to use fscrypt_prepare_atomic_open().  This fixes
>> a bug where a dentry is incorrectly set with DCACHE_NOKEY_NAME when 'dir'
>> has been evicted but the key is still available (for example, where there's
>> a drop_caches).
>> 
>> Signed-off-by: Luís Henriques <lhenriques@suse.de>
>> ---
>>  fs/ceph/file.c | 8 +++-----
>>  1 file changed, 3 insertions(+), 5 deletions(-)
>> 
>> diff --git a/fs/ceph/file.c b/fs/ceph/file.c
>> index dee3b445f415..5ad57cc4c13b 100644
>> --- a/fs/ceph/file.c
>> +++ b/fs/ceph/file.c
>> @@ -795,11 +795,9 @@ int ceph_atomic_open(struct inode *dir, struct dentry *dentry,
>>  	ihold(dir);
>>  	if (IS_ENCRYPTED(dir)) {
>>  		set_bit(CEPH_MDS_R_FSCRYPT_FILE, &req->r_req_flags);
>> -		if (!fscrypt_has_encryption_key(dir)) {
>> -			spin_lock(&dentry->d_lock);
>> -			dentry->d_flags |= DCACHE_NOKEY_NAME;
>> -			spin_unlock(&dentry->d_lock);
>> -		}
>> +		err = fscrypt_prepare_atomic_open(dir, dentry);
>> +		if (err)
>> +			goto out_req;
>
> Note that this patch does not apply to upstream or even to linux-next.

True, I should have mentioned that in the cover-letter.  This patch should
be applied against the 'testing' branch in https://github.com/ceph/ceph-client,
which is where the ceph fscrypt currently lives.

> I'd be glad to take patch 1 through the fscrypt tree for 6.4.  But I'm wondering
> what the current plans are for getting ceph's fscrypt support upstream?

As far as I know, the current plan is to try to merge the ceph code during
the next merge window for 6.4 (but Xiubo and Ilya may correct me if I'm
wrong).  Also, regarding who picks which patch, I'm fine with you picking
the first one.  But I'll let the ceph maintainers say what they think,
because it may be easier for them to keep both patches together due to the
testing infrastructure being used.

Anyway, I'll send out a new rev tomorrow taking your comments into
account.  Thanks, Eric!

Cheers,
-- 
Luís

  reply	other threads:[~2023-03-13 18:43 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-03-13 12:33 [PATCH 0/2] ceph: fscrypt: fix atomic open bug for encrypted directories Luís Henriques
2023-03-13 12:33 ` [PATCH 1/2] fscrypt: new helper function - fscrypt_prepare_atomic_open() Luís Henriques
2023-03-13 18:09   ` Eric Biggers
2023-03-14  0:53     ` Xiubo Li
2023-03-14  2:25       ` Eric Biggers
2023-03-14  4:20         ` Xiubo Li
2023-03-14  9:25           ` Luís Henriques
2023-03-14 10:15     ` Luís Henriques
2023-03-14 17:56       ` Eric Biggers
2023-03-15 11:08         ` Luís Henriques
2023-03-15 17:12           ` Eric Biggers
2023-03-15 17:59             ` Luís Henriques
2023-03-13 12:33 ` [PATCH 2/2] ceph: switch atomic open to use new fscrypt helper Luís Henriques
2023-03-13 18:11   ` Eric Biggers
2023-03-13 18:42     ` Luís Henriques [this message]
2023-03-14  0:38       ` Xiubo Li
2023-03-14  9:27         ` Luís Henriques
2023-03-13 17:11 ` [PATCH 0/2] ceph: fscrypt: fix atomic open bug for encrypted directories Jeff Layton

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=87cz5cv6h2.fsf@suse.de \
    --to=lhenriques@suse.de \
    --cc=ceph-devel@vger.kernel.org \
    --cc=ebiggers@kernel.org \
    --cc=idryomov@gmail.com \
    --cc=jaegeuk@kernel.org \
    --cc=jlayton@kernel.org \
    --cc=linux-fscrypt@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=tytso@mit.edu \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).