CEPH filesystem development
 help / color / mirror / Atom feed
From: Jeff Layton <jlayton@kernel.org>
To: "Yan, Zheng" <ukernel@gmail.com>
Cc: Ilya Dryomov <idryomov@gmail.com>,
	ceph-devel <ceph-devel@vger.kernel.org>
Subject: Re: [PATCH] ceph: wake waiters on any IMPORT that grants new caps
Date: Wed, 02 Feb 2022 07:40:52 -0500	[thread overview]
Message-ID: <a6a08d6ea41b996568fdf16314fec83b34234626.camel@kernel.org> (raw)
In-Reply-To: <CAAM7YAn+8H5nv_Y3hBDtEGA5=jbtsG8-RX=dGU6wB3RRH-HGmw@mail.gmail.com>

On Wed, 2022-02-02 at 03:36 +0800, Yan, Zheng wrote:
> 
> 
> Jeff Layton <jlayton@kernel.org>于2022年1月29日 周六18:36写道:
> > On Sat, 2022-01-29 at 11:14 +0800, Yan, Zheng wrote:
> > > On Sat, Jan 29, 2022 at 2:32 AM Jeff Layton <jlayton@kernel.org>
> > > wrote:
> > > > 
> > > > I've noticed an intermittent hang waiting for caps in some
> > > > testing. What
> > > > I see is that the client will try to get caps for an operation
> > > > (e.g. a
> > > > read), and ends up waiting on the waitqueue forever. The caps
> > > > debugfs
> > > > file however shows that the caps it's waiting on have already
> > > > been
> > > > granted.
> > > > 
> > > > The current grant handling code will wake the waitqueue when it
> > > > sees
> > > > that there are newly-granted caps in the issued set. On an
> > > > import
> > > > however, we'll end up adding a new cap first, which fools the
> > > > logic into
> > > > thinking that nothing has changed. A later hack in the code
> > > > works around
> > > > this, but only for auth caps.
> > > 
> > > not right. handle_cap_import() saves old issued to extra_info-
> > > >issued.
> > > 
> > 
> > It does save the old issued value to extra_info->issued, but
> > handle_cap
> > grant consults cap->issued for most of its logic. It does check
> > against
> > extra_info->issued for auth caps to determine whether to wake
> > waiters,
> > but doesn't do that for non-auth caps. This patch corrects that.
> > 
> 
> 
> non auth mds never imports caps. ‘ci->i_auth_cap != cap’ happened only
> when client receives out-of-order messages for successive cap
> import/export. It’s unlikely in your case because you saw caps were
> there.
> 

Ok! I'll drop this patch, and keep hunting for how we're not getting
awoken. Let me know if you see any gaps in how "wake" gets set.

Thanks,
Jeff

> 
> > 
> > If you think this patch isn't right, can you elaborate on why and
> > what
> > would make it correct?
> > 
> > Thanks,
> > Jeff
> > 
> > > > 
> > > > Ensure we wake the waiters whenever we get an IMPORT that grants
> > > > new
> > > > caps for the inode.
> > > > 
> > > > URL: https://tracker.ceph.com/issues/54044
> > > > Signed-off-by: Jeff Layton <jlayton@kernel.org>
> > > > ---
> > > >   fs/ceph/caps.c | 23 ++++++++++++-----------
> > > >   1 file changed, 12 insertions(+), 11 deletions(-)
> > > > 
> > > > I'm still testing this patch, but I think this may be the cause
> > > > of some
> > > > mysterious hangs I've hit in testing.
> > > > 
> > > > diff --git a/fs/ceph/caps.c b/fs/ceph/caps.c
> > > > index e668cdb9c99e..06b65a68e920 100644
> > > > --- a/fs/ceph/caps.c
> > > > +++ b/fs/ceph/caps.c
> > > > @@ -3541,21 +3541,22 @@ static void handle_cap_grant(struct
> > > > inode *inode,
> > > >                          fill_inline = true;
> > > >          }
> > > > 
> > > > -       if (ci->i_auth_cap == cap &&
> > > > -           le32_to_cpu(grant->op) == CEPH_CAP_OP_IMPORT) {
> > > > +       if (le32_to_cpu(grant->op) == CEPH_CAP_OP_IMPORT) {
> > > >                  if (newcaps & ~extra_info->issued)
> > > >                          wake = true;
> > > > 
> > > > -               if (ci->i_requested_max_size > max_size ||
> > > > -                   !(le32_to_cpu(grant->wanted) &
> > > > CEPH_CAP_ANY_FILE_WR)) {
> > > > -                       /* re-request max_size if necessary */
> > > > -                       ci->i_requested_max_size = 0;
> > > > -                       wake = true;
> > > > -               }
> > > > +               if (ci->i_auth_cap == cap) {
> > > > +                       if (ci->i_requested_max_size > max_size
> > > > ||
> > > > +                           !(le32_to_cpu(grant->wanted) &
> > > > CEPH_CAP_ANY_FILE_WR)) {
> > > > +                               /* re-request max_size if
> > > > necessary */
> > > > +                               ci->i_requested_max_size = 0;
> > > > +                               wake = true;
> > > > +                       }
> > > > 
> > > > -               ceph_kick_flushing_inode_caps(session, ci);
> > > > -               spin_unlock(&ci->i_ceph_lock);
> > > > -               up_read(&session->s_mdsc->snap_rwsem);
> > > > +                       ceph_kick_flushing_inode_caps(session,
> > > > ci);
> > > > +                       spin_unlock(&ci->i_ceph_lock);
> > > > +                       up_read(&session->s_mdsc->snap_rwsem);
> > > > +               }
> > > >          } else {
> > > >                  spin_unlock(&ci->i_ceph_lock);
> > > >          }
> > > > --
> > > > 2.34.1
> > > > 
> > 

-- 
Jeff Layton <jlayton@kernel.org>

      parent reply	other threads:[~2022-02-02 12:40 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-01-27 20:08 [PATCH] ceph: wake waiters on any IMPORT that grants new caps Jeff Layton
2022-01-29  3:14 ` Yan, Zheng
2022-01-29 10:36   ` Jeff Layton
     [not found]     ` <CAAM7YAn+8H5nv_Y3hBDtEGA5=jbtsG8-RX=dGU6wB3RRH-HGmw@mail.gmail.com>
2022-02-02 12:40       ` Jeff Layton [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=a6a08d6ea41b996568fdf16314fec83b34234626.camel@kernel.org \
    --to=jlayton@kernel.org \
    --cc=ceph-devel@vger.kernel.org \
    --cc=idryomov@gmail.com \
    --cc=ukernel@gmail.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