Messages in this thread | | | Subject | Re: [PATCH] Revert "workqueue: re-add lockdep dependencies for flushing" | From | Sagi Grimberg <> | Date | Mon, 22 Oct 2018 17:43:51 -0700 |
| |
>> 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...
| |