lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-id: <174043977707.74271.6498110571534472585@noble.neil.brown.name>
Date: Tue, 25 Feb 2025 10:29:37 +1100
From: "NeilBrown" <neilb@...e.de>
To: "Viacheslav Dubeyko" <Slava.Dubeyko@....com>
Cc: "brauner@...nel.org" <brauner@...nel.org>, "Xiubo Li" <xiubli@...hat.com>,
 "idryomov@...il.com" <idryomov@...il.com>,
 "Olga Kornievskaia" <okorniev@...hat.com>,
 "linux-cifs@...r.kernel.org" <linux-cifs@...r.kernel.org>,
 "Dai.Ngo@...cle.com" <Dai.Ngo@...cle.com>,
 "linux-um@...ts.infradead.org" <linux-um@...ts.infradead.org>,
 "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
 "johannes@...solutions.net" <johannes@...solutions.net>,
 "chuck.lever@...cle.com" <chuck.lever@...cle.com>,
 "jlayton@...nel.org" <jlayton@...nel.org>,
 "anna@...nel.org" <anna@...nel.org>, "miklos@...redi.hu" <miklos@...redi.hu>,
 "trondmy@...nel.org" <trondmy@...nel.org>,
 "viro@...iv.linux.org.uk" <viro@...iv.linux.org.uk>,
 "jack@...e.cz" <jack@...e.cz>, "tom@...pey.com" <tom@...pey.com>,
 "richard@....at" <richard@....at>,
 "anton.ivanov@...bridgegreys.com" <anton.ivanov@...bridgegreys.com>,
 "linux-fsdevel@...r.kernel.org" <linux-fsdevel@...r.kernel.org>,
 "netfs@...ts.linux.dev" <netfs@...ts.linux.dev>,
 "linux-nfs@...r.kernel.org" <linux-nfs@...r.kernel.org>,
 "ceph-devel@...r.kernel.org" <ceph-devel@...r.kernel.org>,
 "senozhatsky@...omium.org" <senozhatsky@...omium.org>
Subject: RE:  [PATCH 3/6] ceph: return the correct dentry on mkdir

On Tue, 25 Feb 2025, Viacheslav Dubeyko wrote:
> On Mon, 2025-02-24 at 13:15 +1100, NeilBrown wrote:
> > On Fri, 21 Feb 2025, Viacheslav Dubeyko wrote:
> > > On Fri, 2025-02-21 at 10:36 +1100, NeilBrown wrote:
> > > > ceph already splices the correct dentry (in splice_dentry()) from the
> > > > result of mkdir but does nothing more with it.
> > > > 
> > > > Now that ->mkdir can return a dentry, return the correct dentry.
> > > > 
> > > > Signed-off-by: NeilBrown <neilb@...e.de>
> > > > ---
> > > >  fs/ceph/dir.c | 9 ++++++++-
> > > >  1 file changed, 8 insertions(+), 1 deletion(-)
> > > > 
> > > > diff --git a/fs/ceph/dir.c b/fs/ceph/dir.c
> > > > index 39e0f240de06..c1a1c168bb27 100644
> > > > --- a/fs/ceph/dir.c
> > > > +++ b/fs/ceph/dir.c
> > > > @@ -1099,6 +1099,7 @@ static struct dentry *ceph_mkdir(struct mnt_idmap *idmap, struct inode *dir,
> > > >  	struct ceph_client *cl = mdsc->fsc->client;
> > > >  	struct ceph_mds_request *req;
> > > >  	struct ceph_acl_sec_ctx as_ctx = {};
> > > > +	struct dentry *ret = NULL;
> > > 
> > > I believe that it makes sense to initialize pointer by error here and always
> > > return ret as output. If something goes wrong in the logic, then we already have
> > > error.
> > 
> > I'm not certain that I understand, but I have made a change which seems
> > to be consistent with the above and included it below.  Please let me
> > know if it is what you intended.
> > 
> > > 
> > > >  	int err;
> > > >  	int op;
> > > >  
> > > > @@ -1166,14 +1167,20 @@ static struct dentry *ceph_mkdir(struct mnt_idmap *idmap, struct inode *dir,
> > > >  	    !req->r_reply_info.head->is_dentry)
> > > >  		err = ceph_handle_notrace_create(dir, dentry);
> > > >  out_req:
> > > > +	if (!err && req->r_dentry != dentry)
> > > > +		/* Some other dentry was spliced in */
> > > > +		ret = dget(req->r_dentry);
> > > >  	ceph_mdsc_put_request(req);
> > > >  out:
> > > >  	if (!err)
> > > > +		/* Should this use 'ret' ?? */
> > > 
> > > Could we make a decision should or shouldn't? :)
> > > It looks not good to leave this comment instead of proper implementation. Do we
> > > have some obstacles to make this decision?
> > 
> > I suspect we should use ret, but I didn't want to make a change which
> > wasn't directly required by my needed.  So I highlighted this which
> > looks to me like a possible bug, hoping that someone more familiar with
> > the code would give an opinion.  Do you agree that 'ret' (i.e.
> > ->r_dentry) should be used when ret is not NULL?
> > 
> 
> I think if we are going to return ret as a dentry, then it makes sense to call
> the ceph_init_inode_acls() for d_inode(ret). I don't see the point to call
> ceph_init_inode_acls() for d_inode(dentry) then.

If the mkdir used the original dentry, then ->mkdir returns NULL so ret
is NULL.  If the mkdir used a different dentry it returns that, so ret
is not NULL.

I'll try to re-organise the code so that "dentry" is the correct dentry
on success, and "ret" is the returned dentry, which might be NULL.

Thanks,
NeilBrown


> 
> > > 
> > > >  		ceph_init_inode_acls(d_inode(dentry), &as_ctx);
> > > >  	else
> > > >  		d_drop(dentry);
> > > >  	ceph_release_acl_sec_ctx(&as_ctx);
> > > > -	return ERR_PTR(err);
> > > > +	if (err)
> > > > +		return ERR_PTR(err);
> > > > +	return ret;
> > > 
> > > What's about this?
> > > 
> > > return err ? ERR_PTR(err) : ret;
> > 
> > We could do that, but you said above that you thought we should always
> > return 'ret' - which does make some sense.
> > 
> > What do you think of the following alternate patch?
> > 
> 
> Patch looks good to me. Thanks.
> 
> Reviewed-by: Viacheslav Dubeyko <Slava.Dubeyko@....com>
> 
> > Thanks,
> > NeilBrown
> > 
> > diff --git a/fs/ceph/dir.c b/fs/ceph/dir.c
> > index 39e0f240de06..d2e5c557df83 100644
> > --- a/fs/ceph/dir.c
> > +++ b/fs/ceph/dir.c
> > @@ -1099,6 +1099,7 @@ static struct dentry *ceph_mkdir(struct mnt_idmap *idmap, struct inode *dir,
> >  	struct ceph_client *cl = mdsc->fsc->client;
> >  	struct ceph_mds_request *req;
> >  	struct ceph_acl_sec_ctx as_ctx = {};
> > +	struct dentry *ret;
> >  	int err;
> >  	int op;
> >  
> > @@ -1116,32 +1117,32 @@ static struct dentry *ceph_mkdir(struct mnt_idmap *idmap, struct inode *dir,
> >  		      ceph_vinop(dir), dentry, dentry, mode);
> >  		op = CEPH_MDS_OP_MKDIR;
> >  	} else {
> > -		err = -EROFS;
> > +		ret = ERR_PTR(-EROFS);
> >  		goto out;
> >  	}
> >  
> >  	if (op == CEPH_MDS_OP_MKDIR &&
> >  	    ceph_quota_is_max_files_exceeded(dir)) {
> > -		err = -EDQUOT;
> > +		ret = ERR_PTR(-EDQUOT);
> >  		goto out;
> >  	}
> >  	if ((op == CEPH_MDS_OP_MKSNAP) && IS_ENCRYPTED(dir) &&
> >  	    !fscrypt_has_encryption_key(dir)) {
> > -		err = -ENOKEY;
> > +		ret = ERR_PTR(-ENOKEY);
> >  		goto out;
> >  	}
> >  
> >  
> >  	req = ceph_mdsc_create_request(mdsc, op, USE_AUTH_MDS);
> >  	if (IS_ERR(req)) {
> > -		err = PTR_ERR(req);
> > +		ret = ERR_CAST(req);
> >  		goto out;
> >  	}
> >  
> >  	mode |= S_IFDIR;
> >  	req->r_new_inode = ceph_new_inode(dir, dentry, &mode, &as_ctx);
> >  	if (IS_ERR(req->r_new_inode)) {
> > -		err = PTR_ERR(req->r_new_inode);
> > +		ret = ERR_CAST(req->r_new_inode);
> >  		req->r_new_inode = NULL;
> >  		goto out_req;
> >  	}
> > @@ -1165,15 +1166,23 @@ static struct dentry *ceph_mkdir(struct mnt_idmap *idmap, struct inode *dir,
> >  	    !req->r_reply_info.head->is_target &&
> >  	    !req->r_reply_info.head->is_dentry)
> >  		err = ceph_handle_notrace_create(dir, dentry);
> > +	ret = ERR_PTR(err);
> >  out_req:
> > +	if (!IS_ERR(ret) && req->r_dentry != dentry)
> > +		/* Some other dentry was spliced in */
> > +		ret = dget(req->r_dentry);
> >  	ceph_mdsc_put_request(req);
> >  out:
> > -	if (!err)
> > -		ceph_init_inode_acls(d_inode(dentry), &as_ctx);
> > -	else
> > +	if (!IS_ERR(ret)) {
> > +		if (ret)
> > +			ceph_init_inode_acls(d_inode(ret), &as_ctx);
> > +		else
> > +			ceph_init_inode_acls(d_inode(dentry), &as_ctx);
> > +	} else {
> >  		d_drop(dentry);
> > +	}
> >  	ceph_release_acl_sec_ctx(&as_ctx);
> > -	return ERR_PTR(err);
> > +	return ret;
> >  }
> >  
> >  static int ceph_link(struct dentry *old_dentry, struct inode *dir,
> > 
> 
> Thanks,
> Slava.
> 
> 


Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ