Received-SPF: pass (google.com: domain of linux-kernel+bounces-132365-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:45d1:ec00::1 as permitted sender) client-ip=2604:1380:45d1:ec00::1;
From: Michael Ellerman <mpe@ellerman.id.au>
To: Finn Thain <fthain@linux-m68k.org>, Greg Kroah-Hartman
 <gregkh@linuxfoundation.org>, Jiri Slaby <jirislaby@kernel.org>
Cc: Nicholas Piggin <npiggin@gmail.com>, Christophe Leroy
 <christophe.leroy@csgroup.eu>, "Aneesh Kumar K.V"
 <aneesh.kumar@kernel.org>, "Naveen N. Rao" <naveen.n.rao@linux.ibm.com>,
 linux-kernel@vger.kernel.org, linux-serial@vger.kernel.org,
 linuxppc-dev@lists.ozlabs.org, linux-m68k@lists.linux-m68k.org, Benjamin
 Herrenschmidt <benh@kernel.crashing.org>, Andy Shevchenko
 <andy.shevchenko@gmail.com>
Subject: Re: [PATCH v2] serial/pmac_zilog: Remove flawed mitigation for rx
 irq flood
In-Reply-To: <0df45bedded1249f6c6ec2c2fb0d9879da1841b7.1712273040.git.fthain@linux-m68k.org>
References: <0df45bedded1249f6c6ec2c2fb0d9879da1841b7.1712273040.git.fthain@linux-m68k.org>
Date: Fri, 05 Apr 2024 14:10:12 +1100
Message-ID: <87v84w7be3.fsf@mail.lhotse>
Precedence: bulk
MIME-Version: 1.0
Content-Type: text/plain

Finn Thain <fthain@linux-m68k.org> writes:
> The mitigation was intended to stop the irq completely. That may be
> better than a hard lock-up but it turns out that you get a crash anyway
> if you're using pmac_zilog as a serial console:
>
> ttyPZ0: pmz: rx irq flood !
> BUG: spinlock recursion on CPU#0, swapper/0
>
> That's because the pr_err() call in pmz_receive_chars() results in
> pmz_console_write() attempting to lock a spinlock already locked in
> pmz_interrupt(). With CONFIG_DEBUG_SPINLOCK=y, this produces a fatal
> BUG splat. The spinlock in question is the one in struct uart_port.
>
> Even when it's not fatal, the serial port rx function ceases to work.
> Also, the iteration limit doesn't play nicely with QEMU, as can be
> seen in the bug report linked below.
>
> A web search for other reports of the error message "pmz: rx irq flood"
> didn't produce anything. So I don't think this code is needed any more.
> Remove it.

Yeah I think you're probably right.

I assume you have tested this on an actual pmac, as well as qemu?

cheers