lkml.org 
[lkml]   [2021]   [Aug]   [6]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [REPORT] Request for reviewing crypto code wrt wait_for_completion()
On Fri, Aug 06, 2021 at 05:03:44PM +0900, Byungchul Park wrote:
> Hello crypto folks,
>
> I developed a tool for tracking waiters and reporting if any of the
> events that the waiters are waiting for would never happen, say, a
> deadlock. Yes, it would look like Lockdep but more inclusive.
>
> While I ran the tool(Dept: Dependency Tracker) on v5.4.96, I got some
> reports from the tool. One of them is related to crypto subsystem.
> Because I'm not that familiar with the code, I'd like to ask you guys to
> review the related code.
>
> If I understand correctly, it doesn't actually cause deadlock but looks
> like a problematic code. I know you are not used to the format of the
> report from Dept so.. let me summerize the result.
>
> The simplified call trace looks like when the problem araised :
>
> THREAD A
> --------
> A1 crypto_alg_mod_lookup()
> A2 crypto_probing_notify(CRYPTO_MSG_ALG_REQUEST)
> A3 cryptomgr_schedule_probe()
> A4 kthread_run(cyptomgr_probe) ---> Start THREAD B
>
> A5 crypto_larval_wait()
> A6 wait_for_completion_killable_timeout(c) /* waiting for B10 */

This larval would be an instantiation larval, and it can only be
woken up by thread B, not C.

> THREAD B
> --------
> B1 cryptomgr_probe()
> B2 pkcslpad_create()
> B3 crypto_wait_for_test()
> B4 crypto_probing_notify(CRYPTO_MSG_ALG_REGISTER)
> B5 cryptomgr_schedule_test()
> B6 kthread_run(cyptomgr_test) ---> Start THREAD C
>
> B7 tmpl->alloc()
> B8 crupto_register_instance()
> B9 wait_for_completion_killable(c) /* waiting for C3 */
> B10 complete_all(c)

I presume you're talking about about the wait_for_completion from
crypto_wait_for_test, in which case it can only be woken by thread
C. After which thread B will return to cryptomgr_probe and wake up
thread A.

> THREAD C
> --------
> C1 cryptomgr_test()
> C2 crypto_alg_tested()
> C3 complete_all(c)
>
> ---
>
> For example, in this situation, I think C3 could wake up both A6 and B9
> before THREAD B reaches B10 which is not desired by A6. Say, is it okay
> to wake up A6 with B7 ~ B9 having yet to complete?

AFAICS thread C only wakes up test larvals, not instantiation larvals.
Please let me know if you have any further issues.

Thanks,
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

\
 
 \ /
  Last update: 2021-08-06 13:43    [W:0.104 / U:0.152 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site