[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAK8P3a2=d0wT9UWgkKDJS5Bd8dPYswah79O5tAg5tHpr4vMH4Q@mail.gmail.com>
Date: Sat, 3 Jul 2021 11:10:24 +0200
From: Arnd Bergmann <arnd@...nel.org>
To: Nikolai Zhubr <zhubr.2@...il.com>
Cc: "Maciej W. Rozycki" <macro@...am.me.uk>,
Thomas Gleixner <tglx@...utronix.de>,
Heiner Kallweit <hkallweit1@...il.com>,
netdev <netdev@...r.kernel.org>,
"the arch/x86 maintainers" <x86@...nel.org>,
Ingo Molnar <mingo@...hat.com>, Borislav Petkov <bp@...en8.de>,
"H. Peter Anvin" <hpa@...or.com>
Subject: Re: Realtek 8139 problem on 486.
On Fri, Jul 2, 2021 at 8:53 PM Nikolai Zhubr <zhubr.2@...il.com> wrote:
>
> 24.06.2021 11:28, Arnd Bergmann:
> > Right, I forgot you saw that one WARN_ON trigger. If you enable KALLSYMS
> > and BUGVERBOSE, it should become obvious what that one is about.
>
> Here is new log with a better backtrace:
>
> https://pastebin.com/DP3dSE4w
Ok, I think the generic code changed a bit, but it does confirm that the
problem is doing the RX handing with IRQs disabled.
> The respective diff against regular 8139too.c is here:
>
> https://pastebin.com/v8kA7ZmX
>
> (Basically the same as you proposed initially, just slight difference
> might be as a remainder of my various previous testing)
The simplest workaround would be to just move the
"spin_lock_irqsave(&tp->lock, flags);" a few lines down, below the rx
processing. This keeps the locking rules exactly how they were before
your patch, and anything beyond that could be done as a follow-up
cleanup, if someone wants to think this through more.
Arnd
Powered by blists - more mailing lists