linux-kernel - Re: [PATCH -rt DO NOT APPLY] Fix for tg3 networking lockup

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Tue, 8 Aug 2006 09:13:10 -0400 (EDT)
From:	Steven Rostedt <rostedt@...dmis.org>
To:	David Miller <davem@...emloft.net>
cc:	tytso@....edu, mchan@...adcom.com, herbert@...dor.apana.org.au,
	linux-kernel@...r.kernel.org, netdev@...r.kernel.org,
	tglx@...utronix.de, mingo@...e.hu
Subject: Re: [PATCH -rt DO NOT APPLY] Fix for tg3 networking lockup

On Tue, 8 Aug 2006, Steven Rostedt wrote:

>
> On Sun, 6 Aug 2006, David Miller wrote:
>
> > From: Steven Rostedt <rostedt@...dmis.org>
> > Date: Mon, 7 Aug 2006 01:34:56 -0400 (EDT)
> >
> > > My suggestion would be to separate that tg3_timer into 4 different
> > > timers, which is what it actually looks like.
> >
> > Timers have non-trivial cost.  It's cheaper to have one and
> > vector off to the necessary operations each tick internalls.
> >
> > That's why it's implemented as one timer.
> >
>
> hrtimers don't have the cost of a normal timer. And that's why I suggested
> to convert them.  There's a much bigger cost in a single timer that always
> times out than 3 hrtimers.  hrtimers are expected to timeout, but timers
> are not.
>
> Of the 4 timers, only one is a timeout. The other three expire every time,
> forcing the timer wheel into effect.  Even though it's one timer
> implementing 4, it's expensive to use it as a watchdog.

I just got a chance to look a little more deeper at what the tg3 timer is
doing, and I was wrong.  The timeout is not a timeout but some messing
around when the network card doesn't use tagged status (whatever that is).
Which just pushes the point that this should _not_ be a timer, but a
hrtimer (expected to expire).

So you can keep this as one timer, but I would still switch it to a
hrtimer regardless, since it is expected to timeout.  (maybe separate out
the ASF if that still needs to be special?).

Ted,

I don't know what the max latency of that timer is, (I'm sure it wouldn't
be too hard to measuer, just add some timings around the timer handler,
let it run for a while and keep account of the max time).  But, since the
user that opens this network card is the one that initializes the timer,
if you simply switch the timer to be a hrtimer (that should also go in
mainline) and then have a really high prio task start up the network, that
timer would then run at the prio of the task that started the network.

-- Steve

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/