Hello, David Bidner, le ven. 09 oct. 2026 09:24:51 +0200, a ecrit: > > David Bidner, le mer. 07 oct. 2026 06:11:02 +0200, a ecrit: > >> Ethernet receive threads and loopback sends can enqueue packets at the > >> same time: they hold different locks, > > > > ? They don't? > > > > loopback_xmit() assumes that net_bh_lock() is already taken, and > > ethernet_demuxer takes it. > > ethernet_demuxer does take it, but the loopback send path does not. > start_bh_atomic() is a no-op in this tree > (pfinet/glue-include/linux/interrupt.h, the net_bh_lock version is commented > out), so dev_queue_xmit() does not take net_bh_lock before calling > loopback_xmit(). An application send runs > > S_io_write -> tcp_sendmsg -> tcp_transmit_skb -> ip_queue_xmit > -> dev_queue_xmit -> loopback_xmit -> netif_rx > > holding only global_lock,
Ok, so that's the bug, incoherent with the loopback_xmit comment: net_bh_lock should already be taken there. Otherwise, what would be the point of net_bh_lock, if not protecting the backlog? I.e. I believe that yes, it's the lock you are looking for, and it's just currently used erroneously. > net_bh_worker holds net_bh_lock and then takes global_lock Does it really need to keep net_bh_lock all the time? We can as well just make net_bh_worker not take the global_lock, and make net_bh release net_bh_lock and take global_lock after skb_dequeue from backlog. And do the converse before looking back at the backlog queue. Yes, this is really similar to what you have done, but keeping just the existing mutex which was already made to protect the reception queue. Samuel
