Re: [PATCH v7 0/2] serial: core: fix baud rate fallback loop and baud_base overflow

[Greg Kroah-Hartman <gregkh@linuxfoundation.org>]

On Wed, Sep 30, 2026 at 12:58:59PM +0000, Hui Peng wrote:
> This series addresses two issues in serial core:
> 1. Division-by-zero WARN/Oops during baud rate fallback in uart_get_baud_rate().
> 2. 32-bit unsigned overflow in uart_set_info() when multiplying new_info->baud_base by 16.
> 
> Note on v6 1/3:
> Patch 1/3 from v6 ("serial: 8250: fix deadlock in serial8250_register_ports")
> has been dropped. The hash_mutex race condition was originally found and
> reproduced on Linux 6.18.14 (where guard(mutex)(&hash_mutex) was dropped
> inside serial_get_or_create_irq_info() before serial_link_irq_chain() linked
> the port). We did not realize that it was already fixed in mainline by
> commit b339809edda1 ("serial: 8250: use guard()s"), which refactored to
> serial_get_or_create_irq_info_locked() with guard(mutex)(&hash_mutex) moved
> into serial_link_irq_chain(). Apologies for the noise in v6 1/3.
> 
> All remaining patches are ported to the latest tip of mainline (551c722f4080)
> and dynamically verified in QEMU KVM with CONFIG_KASAN=y.
> 
> Changes in v7:
> - Dropped patch 1/3 (already resolved in mainline).
> - Clarified in cover letter that 1/3 was found and reproduced on 6.18.14 and
>   we did not realize it was already fixed in mainline.
> - Retained patch 1/2 and patch 2/2 using check_mul_overflow() as requested
>   by Jiri Slaby.
> 
> Hui Peng (2):
>   serial: core: fix baud rate fallback in uart_get_baud_rate()
>   serial: core: reject baud_base values that overflow port->uartclk in
>     uart_set_info()
> 
>  drivers/tty/serial/serial_core.c | 11 ++++++++---
>  1 file changed, 8 insertions(+), 3 deletions(-)
> -- 
> 2.47.3

You have sent 3 versions of this series in one day.  Please relax and
slow down.  I've now deleted all of these patches from my review queue.
Please wait a few days, take the time to make sure the submission is
correct, and then send a new version.  Don't overwhelm reviewers without
helping them with review of other submissions, to do otherwise is not
very kind.

thanks,

greg k-h