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

Groups > linux.kernel > #1457699 > unrolled thread

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

Started byShamir Rabinovitch <shamir.rabinovitch@oracle.com>
First post2016-08-08 12:50 +0200
Last post2016-08-09 23:00 +0200
Articles 4 — 2 participants

Back to article view | Back to linux.kernel

Contents

  Re: [PATCH] device probe: add self triggered delayed work request Shamir Rabinovitch <shamir.rabinovitch@oracle.com> - 2016-08-08 12:50 +0200
    Re: [PATCH] device probe: add self triggered delayed work request Qing Huang <qing.huang@oracle.com> - 2016-08-09 02:10 +0200
      Re: [PATCH] device probe: add self triggered delayed work request Shamir Rabinovitch <shamir.rabinovitch@oracle.com> - 2016-08-09 12:20 +0200
        Re: [PATCH] device probe: add self triggered delayed work request Qing Huang <qing.huang@oracle.com> - 2016-08-09 23:00 +0200

#1457699 — Re: [PATCH] device probe: add self triggered delayed work request

FromShamir Rabinovitch <shamir.rabinovitch@oracle.com>
Date2016-08-08 12:50 +0200
SubjectRe: [PATCH] device probe: add self triggered delayed work request
Message-ID<s3Qi5-e1-13@gated-at.bofh.it>
Hi Qing,

I suspect there is potential dead-lock with this patch:

cpu0                                                    cpu1

driver_deferred_probe_add                               deferred_probe_work_func
 ...                                                     mutex_unlock(&deferred_probe_mutex)
 mutex_lock(&deferred_probe_mutex)                        bus_probe_device(dev)
  ...                                                      device return -EPROBE_DEFER
  ...                                                       driver_deferred_probe_add
  ...                                                        mutex_lock(&deferred_probe_mutex)
  ...                                                         <deadlock!>
  cancel_delayed_work(&deferred_probe_trigger_work)
   <work will never end - deadlock!>

Please confirm if this scenario is possible.

BR, Shamir Rabinovitch

[toc] | [next] | [standalone]

#1458330

FromQing Huang <qing.huang@oracle.com>
Date2016-08-09 02:10 +0200
Message-ID<s42Mh-8w3-1@gated-at.bofh.it>
In reply to#1457699

On 08/08/2016 03:42 AM, Shamir Rabinovitch wrote:
> Hi Qing,
>
> I suspect there is potential dead-lock with this patch:
>
> cpu0                                                    cpu1
>
> driver_deferred_probe_add                               deferred_probe_work_func
>   ...                                                     mutex_unlock(&deferred_probe_mutex)
>   mutex_lock(&deferred_probe_mutex)                        bus_probe_device(dev)
>    ...                                                      device return -EPROBE_DEFER
>    ...                                                       driver_deferred_probe_add
>    ...                                                        mutex_lock(&deferred_probe_mutex)
>    ...                                                         <deadlock!>
>    cancel_delayed_work(&deferred_probe_trigger_work)
>     <work will never end - deadlock!>
Not sure if I understood your scenario. Why there is a deadlock here?

>
> Please confirm if this scenario is possible.
>
> BR, Shamir Rabinovitch

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

#1458572

FromShamir Rabinovitch <shamir.rabinovitch@oracle.com>
Date2016-08-09 12:20 +0200
Message-ID<s4ciB-6ek-1@gated-at.bofh.it>
In reply to#1458330
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

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

#1459124

FromQing Huang <qing.huang@oracle.com>
Date2016-08-09 23:00 +0200
Message-ID<s4mhX-437-5@gated-at.bofh.it>
In reply to#1458572

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

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web