From: Greg Kroah-Hartman Date: Tue, 3 Mar 2020 10:13:27 +0000 (+0100) Subject: 4.9-stable patches X-Git-Tag: v4.19.108~44 X-Git-Url: http://git.ipfire.org/?a=commitdiff_plain;h=e9c41913efb738b9783e0e1efa88c1e1d1f4625f;p=thirdparty%2Fkernel%2Fstable-queue.git 4.9-stable patches added patches: net-netlink-cap-max-groups-which-will-be-considered-in-netlink_bind.patch serial-8250-check-upf_irq_shared-in-advance.patch --- diff --git a/queue-4.9/net-netlink-cap-max-groups-which-will-be-considered-in-netlink_bind.patch b/queue-4.9/net-netlink-cap-max-groups-which-will-be-considered-in-netlink_bind.patch new file mode 100644 index 00000000000..321da04b663 --- /dev/null +++ b/queue-4.9/net-netlink-cap-max-groups-which-will-be-considered-in-netlink_bind.patch @@ -0,0 +1,53 @@ +From 3a20773beeeeadec41477a5ba872175b778ff752 Mon Sep 17 00:00:00 2001 +From: Nikolay Aleksandrov +Date: Thu, 20 Feb 2020 16:42:13 +0200 +Subject: net: netlink: cap max groups which will be considered in netlink_bind() + +From: Nikolay Aleksandrov + +commit 3a20773beeeeadec41477a5ba872175b778ff752 upstream. + +Since nl_groups is a u32 we can't bind more groups via ->bind +(netlink_bind) call, but netlink has supported more groups via +setsockopt() for a long time and thus nlk->ngroups could be over 32. +Recently I added support for per-vlan notifications and increased the +groups to 33 for NETLINK_ROUTE which exposed an old bug in the +netlink_bind() code causing out-of-bounds access on archs where unsigned +long is 32 bits via test_bit() on a local variable. Fix this by capping the +maximum groups in netlink_bind() to BITS_PER_TYPE(u32), effectively +capping them at 32 which is the minimum of allocated groups and the +maximum groups which can be bound via netlink_bind(). + +CC: Christophe Leroy +CC: Richard Guy Briggs +Fixes: 4f520900522f ("netlink: have netlink per-protocol bind function return an error code.") +Reported-by: Erhard F. +Signed-off-by: Nikolay Aleksandrov +Signed-off-by: David S. Miller +Signed-off-by: Greg Kroah-Hartman + +--- + net/netlink/af_netlink.c | 5 +++-- + 1 file changed, 3 insertions(+), 2 deletions(-) + +--- a/net/netlink/af_netlink.c ++++ b/net/netlink/af_netlink.c +@@ -1003,7 +1003,8 @@ static int netlink_bind(struct socket *s + if (nlk->netlink_bind && groups) { + int group; + +- for (group = 0; group < nlk->ngroups; group++) { ++ /* nl_groups is a u32, so cap the maximum groups we can bind */ ++ for (group = 0; group < BITS_PER_TYPE(u32); group++) { + if (!test_bit(group, &groups)) + continue; + err = nlk->netlink_bind(net, group + 1); +@@ -1022,7 +1023,7 @@ static int netlink_bind(struct socket *s + netlink_insert(sk, nladdr->nl_pid) : + netlink_autobind(sock); + if (err) { +- netlink_undo_bind(nlk->ngroups, groups, sk); ++ netlink_undo_bind(BITS_PER_TYPE(u32), groups, sk); + return err; + } + } diff --git a/queue-4.9/net-phy-restore-mdio-regs-in-the-iproc-mdio-driver.patch b/queue-4.9/net-phy-restore-mdio-regs-in-the-iproc-mdio-driver.patch index 64584096ba9..50dc8cb7628 100644 --- a/queue-4.9/net-phy-restore-mdio-regs-in-the-iproc-mdio-driver.patch +++ b/queue-4.9/net-phy-restore-mdio-regs-in-the-iproc-mdio-driver.patch @@ -5,6 +5,8 @@ Subject: net: phy: restore mdio regs in the iproc mdio driver From: Arun Parameswaran +commit 6f08e98d62799e53c89dbf2c9a49d77e20ca648c upstream. + The mii management register in iproc mdio block does not have a retention register so it is lost on suspend. Save and restore value of register while resuming from suspend. diff --git a/queue-4.9/serial-8250-check-upf_irq_shared-in-advance.patch b/queue-4.9/serial-8250-check-upf_irq_shared-in-advance.patch new file mode 100644 index 00000000000..2cdf8fdb20f --- /dev/null +++ b/queue-4.9/serial-8250-check-upf_irq_shared-in-advance.patch @@ -0,0 +1,108 @@ +From 7febbcbc48fc92e3f33863b32ed715ba4aff18c4 Mon Sep 17 00:00:00 2001 +From: Andy Shevchenko +Date: Tue, 11 Feb 2020 15:55:59 +0200 +Subject: serial: 8250: Check UPF_IRQ_SHARED in advance + +From: Andy Shevchenko + +commit 7febbcbc48fc92e3f33863b32ed715ba4aff18c4 upstream. + +The commit 54e53b2e8081 + ("tty: serial: 8250: pass IRQ shared flag to UART ports") +nicely explained the problem: + +---8<---8<--- + +On some systems IRQ lines between multiple UARTs might be shared. If so, the +irqflags have to be configured accordingly. The reason is: The 8250 port startup +code performs IRQ tests *before* the IRQ handler for that particular port is +registered. This is performed in serial8250_do_startup(). This function checks +whether IRQF_SHARED is configured and only then disables the IRQ line while +testing. + +This test is performed upon each open() of the UART device. Imagine two UARTs +share the same IRQ line: On is already opened and the IRQ is active. When the +second UART is opened, the IRQ line has to be disabled while performing IRQ +tests. Otherwise an IRQ might handler might be invoked, but the IRQ itself +cannot be handled, because the corresponding handler isn't registered, +yet. That's because the 8250 code uses a chain-handler and invokes the +corresponding port's IRQ handling routines himself. + +Unfortunately this IRQF_SHARED flag isn't configured for UARTs probed via device +tree even if the IRQs are shared. This way, the actual and shared IRQ line isn't +disabled while performing tests and the kernel correctly detects a spurious +IRQ. So, adding this flag to the DT probe solves the issue. + +Note: The UPF_SHARE_IRQ flag is configured unconditionally. Therefore, the +IRQF_SHARED flag can be set unconditionally as well. + +Example stack trace by performing `echo 1 > /dev/ttyS2` on a non-patched system: + +|irq 85: nobody cared (try booting with the "irqpoll" option) +| [...] +|handlers: +|[] irq_default_primary_handler threaded [] serial8250_interrupt +|Disabling IRQ #85 + +---8<---8<--- + +But unfortunately didn't fix the root cause. Let's try again here by moving +IRQ flag assignment from serial_link_irq_chain() to serial8250_do_startup(). + +This should fix the similar issue reported for 8250_pnp case. + +Since this change we don't need to have custom solutions in 8250_aspeed_vuart +and 8250_of drivers, thus, drop them. + +Fixes: 1c2f04937b3e ("serial: 8250: add IRQ trigger support") +Reported-by: Li RongQing +Cc: Kurt Kanzenbach +Cc: Vikram Pandita +Signed-off-by: Andy Shevchenko +Cc: stable +Acked-by: Kurt Kanzenbach +Link: https://lore.kernel.org/r/20200211135559.85960-1-andriy.shevchenko@linux.intel.com +[Kurt: Backport to v4.9] +Signed-off-by: Kurt Kanzenbach +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/tty/serial/8250/8250_core.c | 5 ++--- + drivers/tty/serial/8250/8250_port.c | 4 ++++ + 2 files changed, 6 insertions(+), 3 deletions(-) + +--- a/drivers/tty/serial/8250/8250_core.c ++++ b/drivers/tty/serial/8250/8250_core.c +@@ -181,7 +181,7 @@ static int serial_link_irq_chain(struct + struct hlist_head *h; + struct hlist_node *n; + struct irq_info *i; +- int ret, irq_flags = up->port.flags & UPF_SHARE_IRQ ? IRQF_SHARED : 0; ++ int ret; + + mutex_lock(&hash_mutex); + +@@ -216,9 +216,8 @@ static int serial_link_irq_chain(struct + INIT_LIST_HEAD(&up->list); + i->head = &up->list; + spin_unlock_irq(&i->lock); +- irq_flags |= up->port.irqflags; + ret = request_irq(up->port.irq, serial8250_interrupt, +- irq_flags, "serial", i); ++ up->port.irqflags, "serial", i); + if (ret < 0) + serial_do_unlink(i, up); + } +--- a/drivers/tty/serial/8250/8250_port.c ++++ b/drivers/tty/serial/8250/8250_port.c +@@ -2199,6 +2199,10 @@ int serial8250_do_startup(struct uart_po + } + } + ++ /* Check if we need to have shared IRQs */ ++ if (port->irq && (up->port.flags & UPF_SHARE_IRQ)) ++ up->port.irqflags |= IRQF_SHARED; ++ + if (port->irq) { + unsigned char iir1; + /* diff --git a/queue-4.9/series b/queue-4.9/series index c7dca2acc41..7d850b7ace1 100644 --- a/queue-4.9/series +++ b/queue-4.9/series @@ -36,3 +36,5 @@ hid-hiddev-fix-race-in-in-hiddev_disconnect.patch mips-vpe-fix-a-double-free-and-a-memory-leak-in-release_vpe.patch i2c-jz4780-silence-log-flood-on-txabrt.patch ecryptfs-fix-up-bad-backport-of-fe2e082f5da5b4a0a92ae32978f81507ef37ec66.patch +serial-8250-check-upf_irq_shared-in-advance.patch +net-netlink-cap-max-groups-which-will-be-considered-in-netlink_bind.patch