Re: [PATCH] padata: fix possible padata_works_lock deadlock

[Herbert Xu]

On Wed, Sep 02, 2020 at 01:07:56PM -0400, Daniel Jordan wrote:
> syzbot reports,
> 
>   WARNING: inconsistent lock state
>   5.9.0-rc2-syzkaller #0 Not tainted
>   --------------------------------
>   inconsistent {IN-SOFTIRQ-W} -> {SOFTIRQ-ON-W} usage.
>   syz-executor.0/26715 takes:
>   (padata_works_lock){+.?.}-{2:2}, at: padata_do_parallel kernel/padata.c:220
>   {IN-SOFTIRQ-W} state was registered at:
>     spin_lock include/linux/spinlock.h:354 [inline]
>     padata_do_parallel kernel/padata.c:220
>     ...
>     __do_softirq kernel/softirq.c:298
>     ...
>     sysvec_apic_timer_interrupt arch/x86/kernel/apic/apic.c:1091
>     asm_sysvec_apic_timer_interrupt arch/x86/include/asm/idtentry.h:581
> 
>    Possible unsafe locking scenario:
> 
>          CPU0
>          ----
>     lock(padata_works_lock);
>     <Interrupt>
>       lock(padata_works_lock);
> 
> padata_do_parallel() takes padata_works_lock with softirqs enabled, so a
> deadlock is possible if, on the same CPU, the lock is acquired in
> process context and then softirq handling done in an interrupt leads to
> the same path.
> 
> Fix by leaving softirqs disabled while do_parallel holds
> padata_works_lock.
> 
> Reported-by: syzbot+f4b9f49e38e25eb4ef52@xxxxxxxxxxxxxxxxxxxxxxxxx
> Fixes: 4611ce2246889 ("padata: allocate work structures for parallel jobs from a pool")
> Signed-off-by: Daniel Jordan <daniel.m.jordan@xxxxxxxxxx>
> Cc: Herbert Xu <herbert@xxxxxxxxxxxxxxxxxxx>
> Cc: Steffen Klassert <steffen.klassert@xxxxxxxxxxx>
> Cc: linux-crypto@xxxxxxxxxxxxxxx
> Cc: linux-kernel@xxxxxxxxxxxxxxx
> ---
>  kernel/padata.c | 5 +++--
>  1 file changed, 3 insertions(+), 2 deletions(-)

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