netdev - Re: [PATCH RFC net 1/1] net/sched: Fix mirred to self recursion

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date: Mon, 15 Apr 2024 17:14:55 -0400
From: Jamal Hadi Salim <jhs@...atatu.com>
To: Eric Dumazet <edumazet@...gle.com>
Cc: davem@...emloft.net, kuba@...nel.org, pabeni@...hat.com, jiri@...nulli.us, 
	xiyou.wangcong@...il.com, netdev@...r.kernel.org, renmingshuai@...wei.com, 
	Victor Nogueira <victor@...atatu.com>
Subject: Re: [PATCH RFC net 1/1] net/sched: Fix mirred to self recursion

On Mon, Apr 15, 2024 at 10:11 AM Eric Dumazet <edumazet@...gle.com> wrote:
>
> On Mon, Apr 15, 2024 at 4:01 PM Jamal Hadi Salim <jhs@...atatu.com> wrote:
> >
>
> > Sorry - shows Victor's name but this is your patch, so feel free if
> > you send to add your name as author.
>
> Sure go ahead, but I would rather put the sch->owner init in
> qdisc_alloc() so that qdisc_create_dflt() is covered.

Victor sent the patch. As i mentioned earlier, we found a lockdep
false positive for the case of redirect from eth0->eth1->eth0
(potential fix attached)

[   75.691724] ============================================
[   75.691964] WARNING: possible recursive locking detected
[   75.691964] 6.9.0-rc3-00861-g0a7d3ab066ff #60 Not tainted
[   75.691964] --------------------------------------------
[   75.691964] ping/421 is trying to acquire lock:
[   75.691964] ffff88800568e110 (&sch->q.lock){+.-.}-{3:3}, at:
__dev_queue_xmit+0x1828/0x3580
[   75.691964]
[   75.691964] but task is already holding lock:
[   75.691964] ffff88800bd2c110 (&sch->q.lock){+.-.}-{3:3}, at:
__dev_queue_xmit+0x1828/0x3580
[   75.691964]
[   75.691964] other info that might help us debug this:
[   75.691964]  Possible unsafe locking scenario:
[   75.691964]
[   75.691964]        CPU0
[   75.691964]        ----
[   75.691964]   lock(&sch->q.lock);
[   75.691964]   lock(&sch->q.lock);
[   75.691964]
[   75.691964]  *** DEADLOCK ***
[   75.691964]
[   75.691964]  May be due to missing lock nesting notation
[   75.691964]
[   75.691964] 9 locks held by ping/421:
[   75.691964]  #0: ffff888002564ff8 (sk_lock-AF_INET){+.+.}-{0:0},
at: raw_sendmsg+0xa32/0x2d80
[   75.691964]  #1: ffffffffa7233540 (rcu_read_lock){....}-{1:3}, at:
ip_finish_output2+0x284/0x1f80
[   75.691964]  #2: ffffffffa7233540 (rcu_read_lock){....}-{1:3}, at:
process_backlog+0x210/0x660
[   75.691964]  #3: ffffffffa7233540 (rcu_read_lock){....}-{1:3}, at:
ip_local_deliver_finish+0x21e/0x4d0
[   75.691964]  #4: ffff8880025648a8 (k-slock-AF_INET){+...}-{3:3},
at: icmp_reply+0x2e6/0xa20
[   75.691964]  #5: ffffffffa7233540 (rcu_read_lock){....}-{1:3}, at:
ip_finish_output2+0x284/0x1f80
[   75.691964]  #6: ffffffffa72334e0 (rcu_read_lock_bh){....}-{1:3},
at: __dev_queue_xmit+0x224/0x3580
[   75.691964]  #7: ffff88800bd2c110 (&sch->q.lock){+.-.}-{3:3}, at:
__dev_queue_xmit+0x1828/0x3580
[   75.691964]  #8: ffffffffa72334e0 (rcu_read_lock_bh){....}-{1:3},
at: __dev_queue_xmit+0x224/0x3580

cheers,
jamal

View attachment "lockdep-fix.patch" of type "text/x-patch" (1210 bytes)