lkml.org 
[lkml]   [2020]   [Sep]   [24]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: inconsistent lock state in xfrm_policy_lookup_inexact_addr
On Wed, Sep 16, 2020 at 01:51:14AM -0700, syzbot wrote:
> Hello,
>
> syzbot found the following issue on:
>
> HEAD commit: 6b02addb Add linux-next specific files for 20200915
> git tree: linux-next
> console output: https://syzkaller.appspot.com/x/log.txt?x=15888efd900000
> kernel config: https://syzkaller.appspot.com/x/.config?x=7086d0e9e44d4a14
> dashboard link: https://syzkaller.appspot.com/bug?extid=f4d0f0f7c860608404c4
> compiler: gcc (GCC) 10.1.0-syz 20200507
>
> Unfortunately, I don't have any reproducer for this issue yet.
>
> IMPORTANT: if you fix the issue, please add the following tag to the commit:
> Reported-by: syzbot+f4d0f0f7c860608404c4@syzkaller.appspotmail.com
>
> ================================
> WARNING: inconsistent lock state
> 5.9.0-rc5-next-20200915-syzkaller #0 Not tainted
> --------------------------------
> inconsistent {SOFTIRQ-ON-W} -> {IN-SOFTIRQ-R} usage.
> kworker/1:1/23 [HC0[0]:SC1[1]:HE0:SE0] takes:
> ffff8880a6ff5f28 (&s->seqcount#12){+.+-}-{0:0}, at: xfrm_policy_lookup_inexact_addr+0x57/0x200 net/xfrm/xfrm_policy.c:1909
> {SOFTIRQ-ON-W} state was registered at:
> lock_acquire+0x1f2/0xaa0 kernel/locking/lockdep.c:5398
> write_seqcount_t_begin_nested include/linux/seqlock.h:509 [inline]
> write_seqcount_t_begin include/linux/seqlock.h:535 [inline]
> write_seqlock include/linux/seqlock.h:883 [inline]
> xfrm_set_spdinfo+0x302/0x660 net/xfrm/xfrm_user.c:1185

This is &net->xfrm.policy_hthresh.lock.

...

> stack backtrace:
> CPU: 1 PID: 23 Comm: kworker/1:1 Not tainted 5.9.0-rc5-next-20200915-syzkaller #0
> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
> Workqueue: wg-crypt-wg0 wg_packet_tx_worker
> Call Trace:
> <IRQ>
> __dump_stack lib/dump_stack.c:77 [inline]
> dump_stack+0x198/0x1fb lib/dump_stack.c:118
> print_usage_bug kernel/locking/lockdep.c:3694 [inline]
> valid_state kernel/locking/lockdep.c:3705 [inline]
> mark_lock_irq kernel/locking/lockdep.c:3908 [inline]
> mark_lock.cold+0x13/0x10d kernel/locking/lockdep.c:4375
> mark_usage kernel/locking/lockdep.c:4252 [inline]
> __lock_acquire+0x1402/0x55d0 kernel/locking/lockdep.c:4750
> lock_acquire+0x1f2/0xaa0 kernel/locking/lockdep.c:5398
> seqcount_lockdep_reader_access+0x139/0x1a0 include/linux/seqlock.h:103
> xfrm_policy_lookup_inexact_addr+0x57/0x200 net/xfrm/xfrm_policy.c:1909

And this is a completely different seqlock.

Again lockdep is creating a bogus report by lumping two unrelated
locks (but of the same type, in this case seqlock) together.

Cheers,
--
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: 2020-09-24 06:41    [W:0.061 / U:1.748 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site