lkml.org 
[lkml]   [2018]   [Oct]   [23]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: [PATCH] Revert "workqueue: re-add lockdep dependencies for flushing"
From
Date

>> I must also say that I'm disappointed you'd try to do things this way.
>> I'd be (have been?) willing to actually help you understand the problem
>> and add the annotations, but rather than answer my question ("where do I
>> find the right git tree"!) you just send a revert patch.
>
> Sorry that I had not yet provided that information. You should have
> received this information through another e-mail thread. See also
> http://lists.infradead.org/pipermail/linux-nvme/2018-October/020493.html.
>
>> To do that, you have to understand what recursion is valid (I'm guessing
>> there's some sort of layering involved), and I'm far from understanding
>> anything about the code that triggered this report.
>
> I don't think there is any kind of recursion involved in the NVMe code
> that triggered the lockdep complaint. Sagi, please correct me if I got this
> wrong.

I commented on the original thread. I'm not sure it qualifies as a
recursion, but in that use-case, when priv->handler_mutex is taken
it is possible that other priv->handler_mutex instances are taken but
are guaranteed not to belong to that priv...

\
 
 \ /
  Last update: 2018-10-23 02:44    [W:0.097 / U:1.960 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site