From: Jeff Layton <jlayton@kernel.org>
To: "Yan, Zheng" <ukernel@gmail.com>
Cc: ceph-devel <ceph-devel@vger.kernel.org>,
Ilya Dryomov <idryomov@gmail.com>
Subject: Re: [PATCH] ceph: wake waiters on any IMPORT that grants new caps
Date: Sat, 29 Jan 2022 05:36:52 -0500 [thread overview]
Message-ID: <61d982d3a9a3d2ba39de755be5559391221061fb.camel@kernel.org> (raw)
In-Reply-To: <CAAM7YAmcj4JQ64EHWRTAVnEGnhfSN1OSUCSuOoi2PhOT8s_cHg@mail.gmail.com>
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.
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>
next prev parent reply other threads:[~2022-01-29 10:36 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 [this message]
[not found] ` <CAAM7YAn+8H5nv_Y3hBDtEGA5=jbtsG8-RX=dGU6wB3RRH-HGmw@mail.gmail.com>
2022-02-02 12:40 ` 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=61d982d3a9a3d2ba39de755be5559391221061fb.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