mbox series

[0/5] realtek: avoid blocking for too long

Message ID 20221014210618.3012368-1-jan@3e8.eu
Headers show
Series realtek: avoid blocking for too long | expand

Message

Jan Hoffmann Oct. 14, 2022, 9:06 p.m. UTC 
This fixes multiple instances where the realtek drivers may block for
too long. These issues were discovered on HPE 1920 devices where such
behaviour is made obvious by the short timeout of the hardware watchdog.

This patch series intentionally doesn't address calls to pr_debug which
may also block for long enough to cause issues. Those calls are only
effective if the kernel is built with support for debug messages, which
is a non-default configuration. Also, it is really an issue with printk
itself and in no way specific to the realtek drivers. It is already
being worked on upstream by moving to threaded printk.

Jan Hoffmann (5):
  realtek: avoid busy waiting for RTL839x PHY read/write
  realtek: simplify log messages in rtl83xx_mdio_probe
  realtek: add debugfs node for L2 table
  realtek: reduce excessive logging for FDB operations
  realtek: restructure rtl_table_read/write

 .../drivers/net/dsa/rtl83xx/common.c          |  51 ++++++---
 .../drivers/net/dsa/rtl83xx/debugfs.c         | 107 ++++++++++++++++++
 .../files-5.10/drivers/net/dsa/rtl83xx/dsa.c  |  55 +--------
 .../drivers/net/dsa/rtl83xx/rtl839x.c         |  45 ++++++--
 .../drivers/net/dsa/rtl83xx/rtl83xx.h         |   4 +-
 .../drivers/net/dsa/rtl83xx/rtl930x.c         |  16 ---
 6 files changed, 181 insertions(+), 97 deletions(-)

Comments

Sander Vanheule Oct. 23, 2022, 8:24 p.m. UTC | #1 
On Fri, 2022-10-14 at 23:06 +0200, Jan Hoffmann wrote:
> This fixes multiple instances where the realtek drivers may block for
> too long. These issues were discovered on HPE 1920 devices where such
> behaviour is made obvious by the short timeout of the hardware watchdog.
> 
> This patch series intentionally doesn't address calls to pr_debug which
> may also block for long enough to cause issues. Those calls are only
> effective if the kernel is built with support for debug messages, which
> is a non-default configuration. Also, it is really an issue with printk
> itself and in no way specific to the realtek drivers. It is already
> being worked on upstream by moving to threaded printk.
> 
> Jan Hoffmann (5):
>   realtek: avoid busy waiting for RTL839x PHY read/write
>   realtek: simplify log messages in rtl83xx_mdio_probe
>   realtek: add debugfs node for L2 table
>   realtek: reduce excessive logging for FDB operations
>   realtek: restructure rtl_table_read/write


These patches look good to me, but I agree with Andreas's remark for "realtek:
simplify log messages in rtl83xx_mdio_probe". If you don't get any comments on
moving cond_resched() to the loops, can you do a respin?

I've already picked patches 1, 3, and 4. So you would only need to do the two
remaining ones.

Best,
Sander