On Fri, Oct 16, 2020 at 12:50 PM Sudeep Holla <[email protected]> wrote: > > On Fri, Oct 16, 2020 at 12:30:20PM -0500, [email protected] wrote: > > From: Jassi Brar <[email protected]> > > > > If the txdone is done by polling, it is possible for msg_submit() to start > > the timer while txdone_hrtimer() callback is running. If the timer needs > > recheduling, it could already be enqueued by the time hrtimer_forward_now() > > is called, leading hrtimer to loudly complain. > > > > WARNING: CPU: 3 PID: 74 at kernel/time/hrtimer.c:932 > > hrtimer_forward+0xc4/0x110 > > CPU: 3 PID: 74 Comm: kworker/u8:1 Not tainted > > 5.9.0-rc2-00236-gd3520067d01c-dirty #5 > > Hardware name: Libre Computer AML-S805X-AC (DT) > > Workqueue: events_freezable_power_ thermal_zone_device_check > > pstate: 20000085 (nzCv daIf -PAN -UAO BTYPE=--) > > pc : hrtimer_forward+0xc4/0x110 > > lr : txdone_hrtimer+0xf8/0x118 > > [...] > > > > This can be fixed by not starting the timer from the callback path. Which > > requires the timer reloading as long as any message is queued on the > > channel, and not just when current tx is not done yet. > > > > I came to similar conclusion and was testing something similar. You bet > me. Since we have single timer and multiple channels, each time a message > is enqueued on any channel, timer gets added which is wrong. > > Reviewed-by: Sudeep Holla <[email protected]> > > I tested this patch too by reverting offending commit in -next, so > > Tested-by: Sudeep Holla <[email protected]> > > You seem to have dropped the Fixes tags. Is that intentional ? If so, > any particular reasons. I think it is stable material and better to have > fixes tag so that it gets added to stable trees. > Thanks for testing. I will decorate it appropriately once I have Jerome's tested-by too.
-jassi
