linux-kernel - Re: [PATCH] device probe: add self triggered delayed work request

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Tue, 9 Aug 2016 13:11:22 +0300
From:	Shamir Rabinovitch <shamir.rabinovitch@...cle.com>
To:	Qing Huang <qing.huang@...cle.com>
Cc:	Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
	Grant Likely <grant.likely@...aro.org>,
	Santosh Shilimkar <santosh.shilimkar@...cle.com>,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH] device probe: add self triggered delayed work request

On Mon, Aug 08, 2016 at 05:10:05PM -0700, Qing Huang wrote:
> 
> Not sure if I understood your scenario. Why there is a deadlock here?
> 

 CPU0                                                   | CPU1
---------------------------------------------------------------------------------------------
 driver_deferred_probe_add                              | driver_deferred_probe_trigger_wrapper   
  mutex_lock(&deferred_probe_mutex)                     |  driver_deferred_probe_trigger
   cancel_delayed_work(&deferred_probe_trigger_work)    |   mutex_lock(&deferred_probe_mutex)
    wait for "driver_deferred_probe_trigger_wrapper"    |    wait for "deferred_probe_mutex"

is this possible scenario with this patch?

if yes then CPU0 will wait for CPU1 to finish the delayed work whith
mutex deferred_probe_mutex held while CPU1 will try to finish the
delayed work and will wait for the same mutex forever.

it seems like dead lock scenario to me.

please say if this scenario is possible.

BR, Shamir Rabinovitch