On Fri, May 19, 2017 at 11:47 AM, Akshay Narayan wrote:
>> I don't want to defend the use of yield() but it looks like there is other
>> problem.
>
> I believe this use of yield() should be replaced with cond_resched()
> even if it turns out there is an unrelated problem.
Yeah, it is a different
On Fri, 2017-05-19 at 14:47 -0400, Akshay Narayan wrote:
> > I don't want to defend the use of yield() but it looks like there is other
> > problem.
>
> I believe this use of yield() should be replaced with cond_resched()
> even if it turns out there is an unrelated problem.
>
> > Does this modul
> I don't want to defend the use of yield() but it looks like there is other
> problem.
I believe this use of yield() should be replaced with cond_resched()
even if it turns out there is an unrelated problem.
> Does this module call netlink_broadcast() with __GFP_DIRECT_RECLAIM
> in IRQ context?
On Fri, May 19, 2017 at 10:22 AM, Akshay Narayan wrote:
> netlink_broadcast_filtered() calls yield() when a slow listener causes
> the buffer to fill. yield() is the wrong choice here, as pointed out by
> Commit 8e3fabfde4 (sched: Update yield() docs); in some cases, its use causes
> "BUG: schedul
netlink_broadcast_filtered() calls yield() when a slow listener causes
the buffer to fill. yield() is the wrong choice here, as pointed out by
Commit 8e3fabfde4 (sched: Update yield() docs); in some cases, its use causes
"BUG: scheduling while atomic" and, when fewer cores are available,
kernel han
