Re: [PATCH] net: tulip: use mod_timer() in t21142_lnk_change()

[Francois Romieu <romieu@fr.zoreil.com>]

Magnus Lindholm <linmag7@gmail.com> :
> t21142_lnk_change() is called from tulip_interrupt(), i.e. in hardirq
> context. On a link-fail or NWay renegotiation event it calls
> timer_delete_sync(&tp->timer) before rescheduling the timer, which is
> exactly what
> 
>   WARN_ON(in_hardirq() && !(timer->flags & TIMER_IRQSAFE));
> 
> in __timer_delete_sync() exists to catch, since tp->timer is not
> TIMER_IRQSAFE:
> 
>   WARNING: kernel/time/timer.c:1611 at __timer_delete_sync+0x13c/0x150
>   ...
>   [<...>] t21142_lnk_change+...
>   [<...>] tulip_interrupt+...
> 
> This isn't teardown, it's just rescheduling the media timer, which is
> exactly what mod_timer() is for. mod_timer(timer, expires) is
> documented as equivalent to timer_delete(); timer->expires = expires;
> add_timer(), and as the only safe way to change the timeout when a
> timer has multiple unserialized concurrent users. That is the case
> here: t21142_media_task(), scheduled by this same timer's callback,
> already ends with its own mod_timer() call on tp->timer, with a
> comment noting it synchronizes against add_timer() calls from
> interrupts. Using mod_timer() in t21142_lnk_change() as well, instead
> of an unprotected timer_delete()+add_timer() pair, matches that
> existing concurrency model instead of racing against it.
> 
> Update the comment in tulip_interrupt() accordingly. pnic2_lnk_change()
> still calls timer_delete_sync() from the same hardirq path, but its timer
> callback re-arms the timer directly with mod_timer(), so fixing that path
> requires separate consideration of the callback/reschedule race.
> 
> The warning was reproduced during a link-state change at boot on an
> Alpha UP2000+ running v7.3-rc1 with:
> 
>   0001:02:08.0 Ethernet controller: Digital Equipment Corporation
>   DECchip 21142/43 (rev 30)
> 
> Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
> Cc: stable@vger.kernel.org
> Signed-off-by: Magnus Lindholm <linmag7@gmail.com>
> ---

The current code may avoid concurrent run (#1) of t21142_start_nway and
t21142_media_task. It may also deadlock (#2) as you have noticed.

As far as I understand the code, current users - if any - may experience
#1 (avoid concurrent run) or #2 (deadlock) alone as well as #1 and #2

Users of modified code won't experience #2 but they may fail more often
at #1.

It may deserve a minor comment explaining either the choice or why it is
not an issue.

-- 
Ueimor