From: Jeff Layton <jlayton@kernel.org>
To: Luis Henriques <lhenriques@suse.de>, Ilya Dryomov <idryomov@gmail.com>
Cc: ceph-devel@vger.kernel.org, linux-kernel@vger.kernel.org,
stable@vger.kernel.org
Subject: Re: [RFC PATCH] ceph: reduce contention in ceph_check_delayed_caps()
Date: Fri, 25 Jun 2021 12:54:44 -0400 [thread overview]
Message-ID: <e427c4e5877e0b036c36eedbe40020047b02a85b.camel@kernel.org> (raw)
In-Reply-To: <20210625154559.8148-1-lhenriques@suse.de>
On Fri, 2021-06-25 at 16:45 +0100, Luis Henriques wrote:
> Function ceph_check_delayed_caps() is called from the mdsc->delayed_work
> workqueue and it can be kept looping for quite some time if caps keep being
> added back to the mdsc->cap_delay_list. This may result in the watchdog
> tainting the kernel with the softlockup flag.
>
> This patch re-arranges the loop through the caps list so that it initially
> removes all the caps from list, adding them to a temporary list. And then, with
> less locking contention, it will eventually call the ceph_check_caps() for each
> inode. Any caps added to the list in the meantime will be handled in the next
> run.
>
> Cc: stable@vger.kernel.org
> Signed-off-by: Luis Henriques <lhenriques@suse.de>
> ---
> Hi Jeff!
>
> So, I've not based this patch on top of your patchset that gets rid of
> ceph_async_iput() so that it will make it easier to backport it for stable
> kernels. Of course I'm not 100% this classifies as stable material.
>
> Other than that, I've been testing this patch and I couldn't see anything
> breaking. Let me know what you think.
>
> (I *think* I've seen a tracker bug for this in the past but I couldn't
> find it. I guess it could be added as a 'Link:' tag.)
>
> Cheers,
> --
> Luis
>
> fs/ceph/caps.c | 13 +++++++++----
> 1 file changed, 9 insertions(+), 4 deletions(-)
>
> diff --git a/fs/ceph/caps.c b/fs/ceph/caps.c
> index a5e93b185515..727e41e3b939 100644
> --- a/fs/ceph/caps.c
> +++ b/fs/ceph/caps.c
> @@ -4229,6 +4229,7 @@ void ceph_check_delayed_caps(struct ceph_mds_client *mdsc)
> {
> struct inode *inode;
> struct ceph_inode_info *ci;
> + LIST_HEAD(caps_list);
>
> dout("check_delayed_caps\n");
> spin_lock(&mdsc->cap_delay_lock);
> @@ -4239,19 +4240,23 @@ void ceph_check_delayed_caps(struct ceph_mds_client *mdsc)
> if ((ci->i_ceph_flags & CEPH_I_FLUSH) == 0 &&
> time_before(jiffies, ci->i_hold_caps_max))
> break;
> - list_del_init(&ci->i_cap_delay_list);
> + list_move_tail(&ci->i_cap_delay_list, &caps_list);
> + }
> + spin_unlock(&mdsc->cap_delay_lock);
>
> + while (!list_empty(&caps_list)) {
> + ci = list_first_entry(&caps_list,
> + struct ceph_inode_info,
> + i_cap_delay_list);
> + list_del_init(&ci->i_cap_delay_list);
> inode = igrab(&ci->vfs_inode);
> if (inode) {
> - spin_unlock(&mdsc->cap_delay_lock);
> dout("check_delayed_caps on %p\n", inode);
> ceph_check_caps(ci, 0, NULL);
> /* avoid calling iput_final() in tick thread */
> ceph_async_iput(inode);
> - spin_lock(&mdsc->cap_delay_lock);
> }
> }
> - spin_unlock(&mdsc->cap_delay_lock);
> }
>
> /*
I'm not sure this approach is viable, unfortunately. Once you've dropped
the cap_delay_lock, then nothing protects the i_cap_delay_list head
anymore.
So you could detach these objects and put them on the private list, and
then once you drop the spinlock another task could find one of them and
(e.g.) call __cap_delay_requeue on it, potentially corrupting your list.
I think we'll need to come up with a different way to do this...
--
Jeff Layton <jlayton@kernel.org>
next prev parent reply other threads:[~2021-06-25 16:54 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-06-25 15:45 [RFC PATCH] ceph: reduce contention in ceph_check_delayed_caps() Luis Henriques
2021-06-25 16:54 ` Jeff Layton [this message]
2021-06-28 9:04 ` Luis Henriques
2021-06-28 14:44 ` 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=e427c4e5877e0b036c36eedbe40020047b02a85b.camel@kernel.org \
--to=jlayton@kernel.org \
--cc=ceph-devel@vger.kernel.org \
--cc=idryomov@gmail.com \
--cc=lhenriques@suse.de \
--cc=linux-kernel@vger.kernel.org \
--cc=stable@vger.kernel.org \
/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