From: Dave Jiang <dave.jiang@intel.com>
To: Waiman Long <longman@redhat.com>, Vinod Koul <vkoul@kernel.org>
Cc: "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"dmaengine@vger.kernel.org" <dmaengine@vger.kernel.org>,
"Williams, Dan J" <dan.j.williams@intel.com>,
Kees Cook <keescook@chromium.org>,
Christophe JAILLET <christophe.jaillet@wanadoo.fr>
Subject: driver/dma/ioat: Call del_timer_sync() without holding prep_lock
Date: Fri, 14 Sep 2018 12:35:22 -0700 [thread overview]
Message-ID: <b7b1a71a-9121-930e-bc77-8209d188c628@intel.com> (raw)
On 09/14/2018 11:53 AM, Waiman Long wrote:
> The following lockdep splat was observed:
>
> [ 1222.241750] ======================================================
> [ 1222.271301] WARNING: possible circular locking dependency detected
> [ 1222.301060] 4.16.0-10.el8+5.x86_64+debug #1 Not tainted
> [ 1222.326659] ------------------------------------------------------
> [ 1222.356565] systemd-shutdow/1 is trying to acquire lock:
> [ 1222.382660] ((&ioat_chan->timer)){+.-.}, at: [<00000000f71e1a28>] del_timer_sync+0x5/0xf0
> [ 1222.422928]
> [ 1222.422928] but task is already holding lock:
> [ 1222.451743] (&(&ioat_chan->prep_lock)->rlock){+.-.}, at: [<000000008ea98b12>] ioat_shutdown+0x86/0x100 [ioatdma]
> :
> [ 1223.524987] Chain exists of:
> [ 1223.524987] (&ioat_chan->timer) --> &(&ioat_chan->cleanup_lock)->rlock --> &(&ioat_chan->prep_lock)->rlock
> [ 1223.524987]
> [ 1223.594082] Possible unsafe locking scenario:
> [ 1223.594082]
> [ 1223.622630] CPU0 CPU1
> [ 1223.645080] ---- ----
> [ 1223.667404] lock(&(&ioat_chan->prep_lock)->rlock);
> [ 1223.691535] lock(&(&ioat_chan->cleanup_lock)->rlock);
> [ 1223.728657] lock(&(&ioat_chan->prep_lock)->rlock);
> [ 1223.765122] lock((&ioat_chan->timer));
> [ 1223.784095]
> [ 1223.784095] *** DEADLOCK ***
> [ 1223.784095]
> [ 1223.813492] 4 locks held by systemd-shutdow/1:
> [ 1223.834677] #0: (reboot_mutex){+.+.}, at: [<0000000056d33456>] SYSC_reboot+0x10f/0x300
> [ 1223.873310] #1: (&dev->mutex){....}, at: [<00000000258dfdd7>] device_shutdown+0x1c8/0x660
> [ 1223.913604] #2: (&dev->mutex){....}, at: [<0000000068331147>] device_shutdown+0x1d6/0x660
> [ 1223.954000] #3: (&(&ioat_chan->prep_lock)->rlock){+.-.}, at: [<000000008ea98b12>] ioat_shutdown+0x86/0x100 [ioatdma]
>
> In the ioat_shutdown() function:
>
> spin_lock_bh(&ioat_chan->prep_lock);
> set_bit(IOAT_CHAN_DOWN, &ioat_chan->state);
> del_timer_sync(&ioat_chan->timer);
> spin_unlock_bh(&ioat_chan->prep_lock);
>
> According to the synchronization rule for the del_timer_sync() function,
> the caller must not hold locks which would prevent completion of the
> timer's handler.
>
> The timer structure has its own lock that manages its synchronization.
> Setting the IOAT_CHAN_DOWN bit should prevent other CPUs from
> trying to use that device anyway, there is probably no need to call
> del_timer_sync() while holding the prep_lock. So the del_timer_sync()
> call is now moved outside of the prep_lock critical section to prevent
> the circular lock dependency.
>
> Signed-off-by: Waiman Long <longman@redhat.com>
Thanks!
Reviewed-by: Dave Jiang <dave.jiang@intel.com>
> ---
> drivers/dma/ioat/init.c | 9 ++++++++-
> 1 file changed, 8 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/dma/ioat/init.c b/drivers/dma/ioat/init.c
> index 4fa4c06..21a5708 100644
> --- a/drivers/dma/ioat/init.c
> +++ b/drivers/dma/ioat/init.c
> @@ -1205,8 +1205,15 @@ static void ioat_shutdown(struct pci_dev *pdev)
>
> spin_lock_bh(&ioat_chan->prep_lock);
> set_bit(IOAT_CHAN_DOWN, &ioat_chan->state);
> - del_timer_sync(&ioat_chan->timer);
> spin_unlock_bh(&ioat_chan->prep_lock);
> + /*
> + * Synchronization rule for del_timer_sync():
> + * - The caller must not hold locks which would prevent
> + * completion of the timer's handler.
> + * So prep_lock cannot be held before calling it.
> + */
> + del_timer_sync(&ioat_chan->timer);
> +
> /* this should quiesce then reset */
> ioat_reset_hw(ioat_chan);
> }
>
next reply other threads:[~2018-09-14 19:35 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-09-14 19:35 Dave Jiang [this message]
-- strict thread matches above, loose matches on Subject: below --
2018-09-18 19:20 driver/dma/ioat: Call del_timer_sync() without holding prep_lock Vinod Koul
2018-09-14 18:53 Waiman Long
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=b7b1a71a-9121-930e-bc77-8209d188c628@intel.com \
--to=dave.jiang@intel.com \
--cc=christophe.jaillet@wanadoo.fr \
--cc=dan.j.williams@intel.com \
--cc=dmaengine@vger.kernel.org \
--cc=keescook@chromium.org \
--cc=linux-kernel@vger.kernel.org \
--cc=longman@redhat.com \
--cc=vkoul@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