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] [day] [month] [year] [list]

Message-ID: <57AA43CB.5050209@oracle.com>
Date:	Tue, 9 Aug 2016 13:57:47 -0700
From:	Qing Huang <qing.huang@...cle.com>
To:	Shamir Rabinovitch <shamir.rabinovitch@...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 08/09/2016 03:11 AM, Shamir Rabinovitch wrote:
> 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.

CPU0 will not wait for "driver_deferred_probe_trigger_wrapper" to 
finish, it simply puts the work request onto the queue and returns.

Qing

>
> it seems like dead lock scenario to me.
>
> please say if this scenario is possible.
>
> BR, Shamir Rabinovitch