A new version of the fix to handle race conditions between console
warning logging and status warning disabling messages. Instead of using
a clearly still-unreliable sleep, just hold up the logging of WARN
messages on the server side until we start seeing new messages from
after the warning coming in.
While this kind of buffing is rather unfortunate and means we're
delaying the logging of warnings, I just don't see any other choice.
We don't have a way to re-order status logs after the fact, so if we
log a WARN as soon as we get it then there's still always the posibility
that more status messages will come in that should've been logged
before it.
This still unfortunately leaves the reverse problem (logging warnings
too late instead of too early) but this is the much less common case.
It's also a lot less serious when it occurs, since it doesn't break
the warning enabling and disabling.
Risk: Medium
Visibility: Should prevent WARN messages from being logged before
events that they occured after.
Signed-off-by: John Admanski <jadmanski@google.com>
git-svn-id: http://test.kernel.org/svn/autotest/trunk@3163 592f7852-d20e-0410-864c-8624ca9c26a4
2 files changed