> On 25 Aug 2021, at 19:26, Jason Gunthorpe <jgg@xxxxxxxxxx> wrote: > > On Mon, Aug 23, 2021 at 04:54:16PM +0000, Haakon Bugge wrote: >> >> >>> On 8 Jul 2020, at 03:12, Jason Gunthorpe <jgg@xxxxxxxxxx> wrote: >>> >>> On Tue, Jul 07, 2020 at 06:05:02PM -0700, Divya Indi wrote: >>>> Thanks Jason. >>>> >>>> Appreciate your help and feedback for fixing this issue. >>>> >>>> Would it be possible to access the edited version of the patch? >>>> If yes, please share a pointer to the same. >>> >>> https://git.kernel.org/pub/scm/linux/kernel/git/rdma/rdma.git/commit/?h=for-rc&id=f427f4d6214c183c474eeb46212d38e6c7223d6a >> >> Hi Jason, >> >> >> At first glanse, this commit calls rdma_nl_multicast() whilst >> holding a spinlock. Since rdma_nl_multicast() is called with a >> gfp_flag parameter, one could assume it supports an atomic >> context. rdma_nl_multicast() ends up in >> netlink_broadcast_filtered(). This function calls >> netlink_lock_table(), which calls read_unlock_irqrestore(), which >> ends up calling _raw_read_unlock_irqrestore(). And here >> preempt_enable() is called :-( > > I don't understand. This: > > unsigned long flags; > > read_lock_irqsave(&nl_table_lock, flags); > atomic_inc(&nl_table_users); > read_unlock_irqrestore(&nl_table_lock, flags); > > Is perfectly fine in an atomic context. > > preempt_enable is implemented as a nesting counter, so it is fine to > call it from inside an atomic region so long as it is balanced. You are right. As I said, the stack trace was from a UEK kernel. It turns out, I overlooked commit 2dce224f469f ("netns: protect netns ID lookups with RCU"), which replaces spin_{lock,unlock}_bh with rcu_read_{lock,unlock} in peernet2id(). This commit fixed this bug un-intentionally, I would say! So, this bug has been present in kernels until v5.5-rc7. Sorry for the noise! Håkon
