From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-13.7 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_CR_TRAILER,INCLUDES_PATCH, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,UNPARSEABLE_RELAY autolearn=unavailable autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id A36B0C433E6 for ; Thu, 28 Jan 2021 14:09:56 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 5599F64DC4 for ; Thu, 28 Jan 2021 14:09:56 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231235AbhA1OJg convert rfc822-to-8bit (ORCPT ); Thu, 28 Jan 2021 09:09:36 -0500 Received: from mx2.suse.de ([195.135.220.15]:60328 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231148AbhA1OJe (ORCPT ); Thu, 28 Jan 2021 09:09:34 -0500 X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.221.27]) by mx2.suse.de (Postfix) with ESMTP id 53ABFACBA; Thu, 28 Jan 2021 14:08:52 +0000 (UTC) Received: from localhost (brahms [local]) by brahms (OpenSMTPD) with ESMTPA id 59f2bb83; Thu, 28 Jan 2021 14:09:43 +0000 (UTC) From: Luis Henriques To: Jeff Layton Cc: ceph-devel@vger.kernel.org, linux-fscrypt@vger.kernel.org, linux-fsdevel@vger.kernel.org Subject: Re: [RFC PATCH v4 17/17] ceph: add fscrypt ioctls References: <20210120182847.644850-1-jlayton@kernel.org> <20210120182847.644850-18-jlayton@kernel.org> <87y2gdi74l.fsf@suse.de> <91d4d85d1c59d27bc0ed890efd078645211ae86a.camel@kernel.org> Date: Thu, 28 Jan 2021 14:09:43 +0000 In-Reply-To: <91d4d85d1c59d27bc0ed890efd078645211ae86a.camel@kernel.org> (Jeff Layton's message of "Thu, 28 Jan 2021 08:44:29 -0500") Message-ID: <87tur1i254.fsf@suse.de> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8BIT Precedence: bulk List-ID: X-Mailing-List: linux-fscrypt@vger.kernel.org Jeff Layton writes: > On Thu, 2021-01-28 at 12:22 +0000, Luis Henriques wrote: >> Jeff Layton writes: >> >> > Most of the ioctls, we gate on the MDS feature support. The exception is >> > the key removal and status functions that we still want to work if the >> > MDS's were to (inexplicably) lose the feature. >> > >> > Signed-off-by: Jeff Layton >> > --- >> >  fs/ceph/ioctl.c | 61 +++++++++++++++++++++++++++++++++++++++++++++++++ >> >  1 file changed, 61 insertions(+) >> > >> > diff --git a/fs/ceph/ioctl.c b/fs/ceph/ioctl.c >> > index 6e061bf62ad4..832909f3eb1b 100644 >> > --- a/fs/ceph/ioctl.c >> > +++ b/fs/ceph/ioctl.c >> > @@ -6,6 +6,7 @@ >> >  #include "mds_client.h" >> >  #include "ioctl.h" >> >  #include >> > +#include >> >   >> > >> > >> > >> >  /* >> >   * ioctls >> > @@ -268,8 +269,29 @@ static long ceph_ioctl_syncio(struct file *file) >> >   return 0; >> >  } >> >   >> > >> > >> > >> > +static int vet_mds_for_fscrypt(struct file *file) >> > +{ >> > + int i, ret = -EOPNOTSUPP; >> > + struct ceph_mds_client *mdsc = ceph_sb_to_mdsc(file_inode(file)->i_sb); >> > + >> > + mutex_lock(&mdsc->mutex); >> > + for (i = 0; i < mdsc->max_sessions; i++) { >> > + struct ceph_mds_session *s = __ceph_lookup_mds_session(mdsc, i); >> > + >> > + if (!s) >> > + continue; >> > + if (test_bit(CEPHFS_FEATURE_ALTERNATE_NAME, &s->s_features)) >> > + ret = 0; >> >> And another one, I believe...? We need this here: >> >> ceph_put_mds_session(s); >> > > Well spotted. Though since we hold the mutex over the whole thing, I > probably should change this to just not take references at all. I'll fix > that. > >> Also, isn't this logic broken? Shouldn't we walk through all the sessions >> and return 0 only if they all have that feature bit set? >> > > Tough call. > > AFAIU, we're not guaranteed to have a session with all of the available > MDS's at any given time. I figured we'd have one and we'd assume that > all of the others would be similar. > > I'm not sure if that's a safe assumption or not though. Let me do some > asking around... Yeah, you're probably right. All the sessions should have the same features set. Cheers, -- Luis > Thanks! > -- > Jeff Layton >