Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > linux.kernel > #1401111 > unrolled thread

Re: [PATCH] watchdog: core: Fix circular locking dependency

Started byWim Van Sebroeck <wim@iguana.be>
First post2016-05-14 18:50 +0200
Last post2016-05-14 20:30 +0200
Articles 4 — 2 participants

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.


Contents

  Re: [PATCH] watchdog: core: Fix circular locking dependency Wim Van Sebroeck <wim@iguana.be> - 2016-05-14 18:50 +0200
    Re: [PATCH] watchdog: core: Fix circular locking dependency Guenter Roeck <linux@roeck-us.net> - 2016-05-14 19:10 +0200
      Re: [PATCH] watchdog: core: Fix circular locking dependency Guenter Roeck <linux@roeck-us.net> - 2016-05-14 19:30 +0200
        Re: [PATCH] watchdog: core: Fix circular locking dependency Wim Van Sebroeck <wim@iguana.be> - 2016-05-14 20:30 +0200

#1401111 — Re: [PATCH] watchdog: core: Fix circular locking dependency

FromWim Van Sebroeck <wim@iguana.be>
Date2016-05-14 18:50 +0200
SubjectRe: [PATCH] watchdog: core: Fix circular locking dependency
Message-ID<ryKVk-49j-15@gated-at.bofh.it>
Hi Guenter,

> lockdep reports the following circular locking dependency.
> 
> ======================================================
> INFO: possible circular locking dependency detected ]
> 4.6.0-rc3-00191-gfabf418 #162 Not tainted
> -------------------------------------------------------
> systemd/1 is trying to acquire lock:
> ((&(&wd_data->work)->work)){+.+...}, at: [<80141650>] flush_work+0x0/0x280
> 
> but task is already holding lock:
> 
> (&wd_data->lock){+.+...}, at: [<804acfa8>] watchdog_release+0x18/0x190
> 
> which lock already depends on the new lock.
> the existing dependency chain (in reverse order) is:
> 
> -> #1 (&wd_data->lock){+.+...}:
> 	[<80662310>] mutex_lock_nested+0x64/0x4a8
> 	[<804aca4c>] watchdog_ping_work+0x18/0x4c
> 	[<80143128>] process_one_work+0x1ac/0x500
> 	[<801434b4>] worker_thread+0x38/0x554
> 	[<80149510>] kthread+0xf4/0x108
> 	[<80107c10>] ret_from_fork+0x14/0x24
> 
> -> #0 ((&(&wd_data->work)->work)){+.+...}:
> 	[<8017c4e8>] lock_acquire+0x70/0x90
> 	[<8014169c>] flush_work+0x4c/0x280
> 	[<801440f8>] __cancel_work_timer+0x9c/0x1e0
> 	[<804acfcc>] watchdog_release+0x3c/0x190
> 	[<8022c5e8>] __fput+0x80/0x1c8
> 	[<80147b28>] task_work_run+0x94/0xc8
> 	[<8010b998>] do_work_pending+0x8c/0xb4
> 	[<80107ba8>] slow_work_pending+0xc/0x20
> 
> other info that might help us debug this:
> Possible unsafe locking scenario:
> 
> CPU0                    CPU1
> ----                    ----
> lock(&wd_data->lock);
>                         lock((&(&wd_data->work)->work));
>                         lock(&wd_data->lock);
> lock((&(&wd_data->work)->work));
> 
> *** DEADLOCK ***
> 
> 1 lock held by systemd/1:
> 
> stack backtrace:
> CPU: 2 PID: 1 Comm: systemd Not tainted 4.6.0-rc3-00191-gfabf418 #162
> Hardware name: Freescale i.MX6 Quad/DualLite (Device Tree)
> [<8010f5e4>] (unwind_backtrace) from [<8010c038>] (show_stack+0x10/0x14)
> [<8010c038>] (show_stack) from [<8039d7fc>] (dump_stack+0xa8/0xd4)
> [<8039d7fc>] (dump_stack) from [<80177ee0>] (print_circular_bug+0x214/0x334)
> [<80177ee0>] (print_circular_bug) from [<80179230>] (check_prevs_add+0x4dc/0x8e8)
> [<80179230>] (check_prevs_add) from [<8017b3d8>] (__lock_acquire+0xc6c/0x14ec)
> [<8017b3d8>] (__lock_acquire) from [<8017c4e8>] (lock_acquire+0x70/0x90)
> [<8017c4e8>] (lock_acquire) from [<8014169c>] (flush_work+0x4c/0x280)
> [<8014169c>] (flush_work) from [<801440f8>] (__cancel_work_timer+0x9c/0x1e0)
> [<801440f8>] (__cancel_work_timer) from [<804acfcc>] (watchdog_release+0x3c/0x190)
> [<804acfcc>] (watchdog_release) from [<8022c5e8>] (__fput+0x80/0x1c8)
> [<8022c5e8>] (__fput) from [<80147b28>] (task_work_run+0x94/0xc8)
> [<80147b28>] (task_work_run) from [<8010b998>] (do_work_pending+0x8c/0xb4)
> [<8010b998>] (do_work_pending) from [<80107ba8>] (slow_work_pending+0xc/0x20)
> 
> Turns out the call to cancel_delayed_work_sync() in watchdog_release()
> is not necessary and can be dropped. If the worker is no longer necessary,
> the subsequent call to watchdog_update_worker() will cancel it. If it is
> already running, it won't do anything, since the worker function checks
> if it needs to ping the watchdog or not.
> 
> Reported-by: Clemens Gruber <clemens.gruber@pqgruber.com>
> Tested-by: Clemens Gruber <clemens.gruber@pqgruber.com>
> Fixes: 11d7aba9ceb7 ("watchdog: imx2: Convert to use infrastructure triggered keepalives")
> Signed-off-by: Guenter Roeck <linux@roeck-us.net>
> ---
>  drivers/watchdog/watchdog_dev.c | 1 -
>  1 file changed, 1 deletion(-)
> 
> diff --git a/drivers/watchdog/watchdog_dev.c b/drivers/watchdog/watchdog_dev.c
> index e2c5abbb45ff..3595cffa24ea 100644
> --- a/drivers/watchdog/watchdog_dev.c
> +++ b/drivers/watchdog/watchdog_dev.c
> @@ -736,7 +736,6 @@ static int watchdog_release(struct inode *inode, struct file *file)
>  		watchdog_ping(wdd);
>  	}
>  
> -	cancel_delayed_work_sync(&wd_data->work);
>  	watchdog_update_worker(wdd);
>  
>  	/* make sure that /dev/watchdog can be re-opened */
> -- 
> 2.5.0
> 

This patch has been added to linux-watchdog-next.

Kind regards,
Wim.

[toc] | [next] | [standalone]


#1401118

FromGuenter Roeck <linux@roeck-us.net>
Date2016-05-14 19:10 +0200
Message-ID<ryLeH-4J6-23@gated-at.bofh.it>
In reply to#1401111
Hi Wim,

On 05/14/2016 09:41 AM, Wim Van Sebroeck wrote:
> Hi Guenter,
>
>> lockdep reports the following circular locking dependency.
>>

You are faster than me this time. I was just about to send you a pull request.
Sorry for being late. The watchdog-next branch in my repository on kernel.org
has all patches in my queue, in case you want to have a look.

I'll rebase my branch to yours and see if anything is missing, then send
you a pull request on top of it if needed.

>
> This patch has been added to linux-watchdog-next.
>

This patch should probably be tagged for v4.6.

Thanks,
Guenter

[toc] | [prev] | [next] | [standalone]


#1401119

FromGuenter Roeck <linux@roeck-us.net>
Date2016-05-14 19:30 +0200
Message-ID<ryLy2-50o-3@gated-at.bofh.it>
In reply to#1401118
On 05/14/2016 10:07 AM, Guenter Roeck wrote:
> Hi Wim,
>
> On 05/14/2016 09:41 AM, Wim Van Sebroeck wrote:
>> Hi Guenter,
>>
>>> lockdep reports the following circular locking dependency.
>>>
>
> You are faster than me this time. I was just about to send you a pull request.
> Sorry for being late. The watchdog-next branch in my repository on kernel.org
> has all patches in my queue, in case you want to have a look.
>
> I'll rebase my branch to yours and see if anything is missing, then send
> you a pull request on top of it if needed.
>

All there. Looks like you picked it up right after I updated the branch
this morning.

>>
>> This patch has been added to linux-watchdog-next.
>>
>
> This patch should probably be tagged for v4.6.
>
Turns out it has a Fixes: tag, so an additional tag should not be necessary.

Thanks,
Guenter

[toc] | [prev] | [next] | [standalone]


#1401127

FromWim Van Sebroeck <wim@iguana.be>
Date2016-05-14 20:30 +0200
Message-ID<ryMu6-67X-11@gated-at.bofh.it>
In reply to#1401119
Hi Guenter,

> On 05/14/2016 10:07 AM, Guenter Roeck wrote:
> >Hi Wim,
> >
> >On 05/14/2016 09:41 AM, Wim Van Sebroeck wrote:
> >>Hi Guenter,
> >>
> >>>lockdep reports the following circular locking dependency.
> >>>
> >
> >You are faster than me this time. I was just about to send you a pull 
> >request.
> >Sorry for being late. The watchdog-next branch in my repository on 
> >kernel.org
> >has all patches in my queue, in case you want to have a look.
> >
> >I'll rebase my branch to yours and see if anything is missing, then send
> >you a pull request on top of it if needed.
> >
> 
> All there. Looks like you picked it up right after I updated the branch
> this morning.

Correct ;-)

Kind regards,
Wim.

[toc] | [prev] | [standalone]


Back to top | Article view | linux.kernel


csiph-web