* [PATCH 5.4 1/9] scsi: core: Put LLD module refcnt after SCSI device is released
2021-11-04 14:12 [PATCH 5.4 0/9] 5.4.158-rc1 review Greg Kroah-Hartman
@ 2021-11-04 14:12 ` Greg Kroah-Hartman
2021-11-04 14:12 ` [PATCH 5.4 2/9] vrf: Revert "Reset skb conntrack connection..." Greg Kroah-Hartman
` (12 subsequent siblings)
13 siblings, 0 replies; 15+ messages in thread
From: Greg Kroah-Hartman @ 2021-11-04 14:12 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Changhui Zhong, Yi Zhang, Ming Lei,
Martin K. Petersen
From: Ming Lei <ming.lei@redhat.com>
commit f2b85040acec9a928b4eb1b57a989324e8e38d3f upstream.
SCSI host release is triggered when SCSI device is freed. We have to make
sure that the low-level device driver module won't be unloaded before SCSI
host instance is released because shost->hostt is required in the release
handler.
Make sure to put LLD module refcnt after SCSI device is released.
Fixes a kernel panic of 'BUG: unable to handle page fault for address'
reported by Changhui and Yi.
Link: https://lore.kernel.org/r/20211008050118.1440686-1-ming.lei@redhat.com
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Reported-by: Changhui Zhong <czhong@redhat.com>
Reported-by: Yi Zhang <yi.zhang@redhat.com>
Tested-by: Yi Zhang <yi.zhang@redhat.com>
Signed-off-by: Ming Lei <ming.lei@redhat.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/scsi/scsi.c | 4 +++-
drivers/scsi/scsi_sysfs.c | 9 +++++++++
2 files changed, 12 insertions(+), 1 deletion(-)
--- a/drivers/scsi/scsi.c
+++ b/drivers/scsi/scsi.c
@@ -555,8 +555,10 @@ EXPORT_SYMBOL(scsi_device_get);
*/
void scsi_device_put(struct scsi_device *sdev)
{
- module_put(sdev->host->hostt->module);
+ struct module *mod = sdev->host->hostt->module;
+
put_device(&sdev->sdev_gendev);
+ module_put(mod);
}
EXPORT_SYMBOL(scsi_device_put);
--- a/drivers/scsi/scsi_sysfs.c
+++ b/drivers/scsi/scsi_sysfs.c
@@ -438,9 +438,12 @@ static void scsi_device_dev_release_user
struct list_head *this, *tmp;
struct scsi_vpd *vpd_pg80 = NULL, *vpd_pg83 = NULL;
unsigned long flags;
+ struct module *mod;
sdev = container_of(work, struct scsi_device, ew.work);
+ mod = sdev->host->hostt->module;
+
scsi_dh_release_device(sdev);
parent = sdev->sdev_gendev.parent;
@@ -481,11 +484,17 @@ static void scsi_device_dev_release_user
if (parent)
put_device(parent);
+ module_put(mod);
}
static void scsi_device_dev_release(struct device *dev)
{
struct scsi_device *sdp = to_scsi_device(dev);
+
+ /* Set module pointer as NULL in case of module unloading */
+ if (!try_module_get(sdp->host->hostt->module))
+ sdp->host->hostt->module = NULL;
+
execute_in_process_context(scsi_device_dev_release_usercontext,
&sdp->ew);
}
^ permalink raw reply [flat|nested] 15+ messages in thread* [PATCH 5.4 2/9] vrf: Revert "Reset skb conntrack connection..."
2021-11-04 14:12 [PATCH 5.4 0/9] 5.4.158-rc1 review Greg Kroah-Hartman
2021-11-04 14:12 ` [PATCH 5.4 1/9] scsi: core: Put LLD module refcnt after SCSI device is released Greg Kroah-Hartman
@ 2021-11-04 14:12 ` Greg Kroah-Hartman
2021-11-04 14:12 ` [PATCH 5.4 3/9] net: ethernet: microchip: lan743x: Fix skb allocation failure Greg Kroah-Hartman
` (11 subsequent siblings)
13 siblings, 0 replies; 15+ messages in thread
From: Greg Kroah-Hartman @ 2021-11-04 14:12 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Eugene Crosser, David Ahern,
David S. Miller, Florian Westphal
From: Eugene Crosser <crosser@average.org>
commit 55161e67d44fdd23900be166a81e996abd6e3be9 upstream.
This reverts commit 09e856d54bda5f288ef8437a90ab2b9b3eab83d1.
When an interface is enslaved in a VRF, prerouting conntrack hook is
called twice: once in the context of the original input interface, and
once in the context of the VRF interface. If no special precausions are
taken, this leads to creation of two conntrack entries instead of one,
and breaks SNAT.
Commit above was intended to avoid creation of extra conntrack entries
when input interface is enslaved in a VRF. It did so by resetting
conntrack related data associated with the skb when it enters VRF context.
However it breaks netfilter operation. Imagine a use case when conntrack
zone must be assigned based on the original input interface, rather than
VRF interface (that would make original interfaces indistinguishable). One
could create netfilter rules similar to these:
chain rawprerouting {
type filter hook prerouting priority raw;
iif realiface1 ct zone set 1 return
iif realiface2 ct zone set 2 return
}
This works before the mentioned commit, but not after: zone assignment
is "forgotten", and any subsequent NAT or filtering that is dependent
on the conntrack zone does not work.
Here is a reproducer script that demonstrates the difference in behaviour.
==========
#!/bin/sh
# This script demonstrates unexpected change of nftables behaviour
# caused by commit 09e856d54bda5f28 ""vrf: Reset skb conntrack
# connection on VRF rcv"
# https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=09e856d54bda5f288ef8437a90ab2b9b3eab83d1
#
# Before the commit, it was possible to assign conntrack zone to a
# packet (or mark it for `notracking`) in the prerouting chanin, raw
# priority, based on the `iif` (interface from which the packet
# arrived).
# After the change, # if the interface is enslaved in a VRF, such
# assignment is lost. Instead, assignment based on the `iif` matching
# the VRF master interface is honored. Thus it is impossible to
# distinguish packets based on the original interface.
#
# This script demonstrates this change of behaviour: conntrack zone 1
# or 2 is assigned depending on the match with the original interface
# or the vrf master interface. It can be observed that conntrack entry
# appears in different zone in the kernel versions before and after
# the commit.
IPIN=172.30.30.1
IPOUT=172.30.30.2
PFXL=30
ip li sh vein >/dev/null 2>&1 && ip li del vein
ip li sh tvrf >/dev/null 2>&1 && ip li del tvrf
nft list table testct >/dev/null 2>&1 && nft delete table testct
ip li add vein type veth peer veout
ip li add tvrf type vrf table 9876
ip li set veout master tvrf
ip li set vein up
ip li set veout up
ip li set tvrf up
/sbin/sysctl -w net.ipv4.conf.veout.accept_local=1
/sbin/sysctl -w net.ipv4.conf.veout.rp_filter=0
ip addr add $IPIN/$PFXL dev vein
ip addr add $IPOUT/$PFXL dev veout
nft -f - <<__END__
table testct {
chain rawpre {
type filter hook prerouting priority raw;
iif { veout, tvrf } meta nftrace set 1
iif veout ct zone set 1 return
iif tvrf ct zone set 2 return
notrack
}
chain rawout {
type filter hook output priority raw;
notrack
}
}
__END__
uname -rv
conntrack -F
ping -W 1 -c 1 -I vein $IPOUT
conntrack -L
Signed-off-by: Eugene Crosser <crosser@average.org>
Acked-by: David Ahern <dsahern@kernel.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
Cc: Florian Westphal <fw@strlen.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/net/vrf.c | 4 ----
1 file changed, 4 deletions(-)
--- a/drivers/net/vrf.c
+++ b/drivers/net/vrf.c
@@ -1036,8 +1036,6 @@ static struct sk_buff *vrf_ip6_rcv(struc
bool need_strict = rt6_need_strict(&ipv6_hdr(skb)->daddr);
bool is_ndisc = ipv6_ndisc_frame(skb);
- nf_reset_ct(skb);
-
/* loopback, multicast & non-ND link-local traffic; do not push through
* packet taps again. Reset pkt_type for upper layers to process skb.
* For strict packets with a source LLA, determine the dst using the
@@ -1094,8 +1092,6 @@ static struct sk_buff *vrf_ip_rcv(struct
skb->skb_iif = vrf_dev->ifindex;
IPCB(skb)->flags |= IPSKB_L3SLAVE;
- nf_reset_ct(skb);
-
if (ipv4_is_multicast(ip_hdr(skb)->daddr))
goto out;
^ permalink raw reply [flat|nested] 15+ messages in thread* [PATCH 5.4 3/9] net: ethernet: microchip: lan743x: Fix skb allocation failure
2021-11-04 14:12 [PATCH 5.4 0/9] 5.4.158-rc1 review Greg Kroah-Hartman
2021-11-04 14:12 ` [PATCH 5.4 1/9] scsi: core: Put LLD module refcnt after SCSI device is released Greg Kroah-Hartman
2021-11-04 14:12 ` [PATCH 5.4 2/9] vrf: Revert "Reset skb conntrack connection..." Greg Kroah-Hartman
@ 2021-11-04 14:12 ` Greg Kroah-Hartman
2021-11-04 14:12 ` [PATCH 5.4 4/9] media: firewire: firedtv-avc: fix a buffer overflow in avc_ca_pmt() Greg Kroah-Hartman
` (10 subsequent siblings)
13 siblings, 0 replies; 15+ messages in thread
From: Greg Kroah-Hartman @ 2021-11-04 14:12 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, Yuiko Oshino, David S. Miller
From: Yuiko Oshino <yuiko.oshino@microchip.com>
commit e8684db191e4164f3f5f3ad7dec04a6734c25f1c upstream.
The driver allocates skb during ndo_open with GFP_ATOMIC which has high chance of failure when there are multiple instances.
GFP_KERNEL is enough while open and use GFP_ATOMIC only from interrupt context.
Fixes: 23f0703c125b ("lan743x: Add main source files for new lan743x driver")
Signed-off-by: Yuiko Oshino <yuiko.oshino@microchip.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/net/ethernet/microchip/lan743x_main.c | 10 ++++++----
1 file changed, 6 insertions(+), 4 deletions(-)
--- a/drivers/net/ethernet/microchip/lan743x_main.c
+++ b/drivers/net/ethernet/microchip/lan743x_main.c
@@ -1898,13 +1898,13 @@ static int lan743x_rx_next_index(struct
return ((++index) % rx->ring_size);
}
-static struct sk_buff *lan743x_rx_allocate_skb(struct lan743x_rx *rx)
+static struct sk_buff *lan743x_rx_allocate_skb(struct lan743x_rx *rx, gfp_t gfp)
{
int length = 0;
length = (LAN743X_MAX_FRAME_SIZE + ETH_HLEN + 4 + RX_HEAD_PADDING);
return __netdev_alloc_skb(rx->adapter->netdev,
- length, GFP_ATOMIC | GFP_DMA);
+ length, gfp);
}
static void lan743x_rx_update_tail(struct lan743x_rx *rx, int index)
@@ -2077,7 +2077,8 @@ static int lan743x_rx_process_packet(str
struct sk_buff *new_skb = NULL;
int packet_length;
- new_skb = lan743x_rx_allocate_skb(rx);
+ new_skb = lan743x_rx_allocate_skb(rx,
+ GFP_ATOMIC | GFP_DMA);
if (!new_skb) {
/* failed to allocate next skb.
* Memory is very low.
@@ -2314,7 +2315,8 @@ static int lan743x_rx_ring_init(struct l
rx->last_head = 0;
for (index = 0; index < rx->ring_size; index++) {
- struct sk_buff *new_skb = lan743x_rx_allocate_skb(rx);
+ struct sk_buff *new_skb = lan743x_rx_allocate_skb(rx,
+ GFP_KERNEL);
ret = lan743x_rx_init_ring_element(rx, index, new_skb);
if (ret)
^ permalink raw reply [flat|nested] 15+ messages in thread* [PATCH 5.4 4/9] media: firewire: firedtv-avc: fix a buffer overflow in avc_ca_pmt()
2021-11-04 14:12 [PATCH 5.4 0/9] 5.4.158-rc1 review Greg Kroah-Hartman
` (2 preceding siblings ...)
2021-11-04 14:12 ` [PATCH 5.4 3/9] net: ethernet: microchip: lan743x: Fix skb allocation failure Greg Kroah-Hartman
@ 2021-11-04 14:12 ` Greg Kroah-Hartman
2021-11-04 14:12 ` [PATCH 5.4 5/9] Revert "xhci: Set HCD flag to defer primary roothub registration" Greg Kroah-Hartman
` (9 subsequent siblings)
13 siblings, 0 replies; 15+ messages in thread
From: Greg Kroah-Hartman @ 2021-11-04 14:12 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Luo Likang, Dan Carpenter,
Hans Verkuil, Mauro Carvalho Chehab
From: Dan Carpenter <dan.carpenter@oracle.com>
commit 35d2969ea3c7d32aee78066b1f3cf61a0d935a4e upstream.
The bounds checking in avc_ca_pmt() is not strict enough. It should
be checking "read_pos + 4" because it's reading 5 bytes. If the
"es_info_length" is non-zero then it reads a 6th byte so there needs to
be an additional check for that.
I also added checks for the "write_pos". I don't think these are
required because "read_pos" and "write_pos" are tied together so
checking one ought to be enough. But they make the code easier to
understand for me. The check on write_pos is:
if (write_pos + 4 >= sizeof(c->operand) - 4) {
The first "+ 4" is because we're writing 5 bytes and the last " - 4"
is to leave space for the CRC.
The other problem is that "length" can be invalid. It comes from
"data_length" in fdtv_ca_pmt().
Cc: stable@vger.kernel.org
Reported-by: Luo Likang <luolikang@nsfocus.com>
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/media/firewire/firedtv-avc.c | 14 +++++++++++---
drivers/media/firewire/firedtv-ci.c | 2 ++
2 files changed, 13 insertions(+), 3 deletions(-)
--- a/drivers/media/firewire/firedtv-avc.c
+++ b/drivers/media/firewire/firedtv-avc.c
@@ -1165,7 +1165,11 @@ int avc_ca_pmt(struct firedtv *fdtv, cha
read_pos += program_info_length;
write_pos += program_info_length;
}
- while (read_pos < length) {
+ while (read_pos + 4 < length) {
+ if (write_pos + 4 >= sizeof(c->operand) - 4) {
+ ret = -EINVAL;
+ goto out;
+ }
c->operand[write_pos++] = msg[read_pos++];
c->operand[write_pos++] = msg[read_pos++];
c->operand[write_pos++] = msg[read_pos++];
@@ -1177,13 +1181,17 @@ int avc_ca_pmt(struct firedtv *fdtv, cha
c->operand[write_pos++] = es_info_length >> 8;
c->operand[write_pos++] = es_info_length & 0xff;
if (es_info_length > 0) {
+ if (read_pos >= length) {
+ ret = -EINVAL;
+ goto out;
+ }
pmt_cmd_id = msg[read_pos++];
if (pmt_cmd_id != 1 && pmt_cmd_id != 4)
dev_err(fdtv->device, "invalid pmt_cmd_id %d at stream level\n",
pmt_cmd_id);
- if (es_info_length > sizeof(c->operand) - 4 -
- write_pos) {
+ if (es_info_length > sizeof(c->operand) - 4 - write_pos ||
+ es_info_length > length - read_pos) {
ret = -EINVAL;
goto out;
}
--- a/drivers/media/firewire/firedtv-ci.c
+++ b/drivers/media/firewire/firedtv-ci.c
@@ -134,6 +134,8 @@ static int fdtv_ca_pmt(struct firedtv *f
} else {
data_length = msg->msg[3];
}
+ if (data_length > sizeof(msg->msg) - data_pos)
+ return -EINVAL;
return avc_ca_pmt(fdtv, &msg->msg[data_pos], data_length);
}
^ permalink raw reply [flat|nested] 15+ messages in thread* [PATCH 5.4 5/9] Revert "xhci: Set HCD flag to defer primary roothub registration"
2021-11-04 14:12 [PATCH 5.4 0/9] 5.4.158-rc1 review Greg Kroah-Hartman
` (3 preceding siblings ...)
2021-11-04 14:12 ` [PATCH 5.4 4/9] media: firewire: firedtv-avc: fix a buffer overflow in avc_ca_pmt() Greg Kroah-Hartman
@ 2021-11-04 14:12 ` Greg Kroah-Hartman
2021-11-04 14:12 ` [PATCH 5.4 6/9] Revert "usb: core: hcd: Add support for deferring " Greg Kroah-Hartman
` (8 subsequent siblings)
13 siblings, 0 replies; 15+ messages in thread
From: Greg Kroah-Hartman @ 2021-11-04 14:12 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Hans de Goede, Mathias Nyman,
Chris Chiu, Alan Stern, Kishon Vijay Abraham I
From: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
This reverts commit 2d7c20db7220bc8dbc560de6e58f024696c790e5 which is
commit b7a0a792f864583207c593b50fd1b752ed89f4c1 upstream.
It has been reported to be causing problems in Arch and Fedora bug
reports.
Reported-by: Hans de Goede <hdegoede@redhat.com>
Link: https://bbs.archlinux.org/viewtopic.php?pid=2000956#p2000956
Link: https://bugzilla.redhat.com/show_bug.cgi?id=2019542
Link: https://bugzilla.redhat.com/show_bug.cgi?id=2019576
Link: https://lore.kernel.org/r/42bcbea6-5eb8-16c7-336a-2cb72e71bc36@redhat.com
Cc: Mathias Nyman <mathias.nyman@linux.intel.com>
Cc: Chris Chiu <chris.chiu@canonical.com>
Cc: Alan Stern <stern@rowland.harvard.edu>
Cc: Kishon Vijay Abraham I <kishon@ti.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/usb/host/xhci.c | 1 -
1 file changed, 1 deletion(-)
--- a/drivers/usb/host/xhci.c
+++ b/drivers/usb/host/xhci.c
@@ -693,7 +693,6 @@ int xhci_run(struct usb_hcd *hcd)
if (ret)
xhci_free_command(xhci, command);
}
- set_bit(HCD_FLAG_DEFER_RH_REGISTER, &hcd->flags);
xhci_dbg_trace(xhci, trace_xhci_dbg_init,
"Finished xhci_run for USB2 roothub");
^ permalink raw reply [flat|nested] 15+ messages in thread* [PATCH 5.4 6/9] Revert "usb: core: hcd: Add support for deferring roothub registration"
2021-11-04 14:12 [PATCH 5.4 0/9] 5.4.158-rc1 review Greg Kroah-Hartman
` (4 preceding siblings ...)
2021-11-04 14:12 ` [PATCH 5.4 5/9] Revert "xhci: Set HCD flag to defer primary roothub registration" Greg Kroah-Hartman
@ 2021-11-04 14:12 ` Greg Kroah-Hartman
2021-11-04 14:13 ` [PATCH 5.4 7/9] sfc: Fix reading non-legacy supported link modes Greg Kroah-Hartman
` (7 subsequent siblings)
13 siblings, 0 replies; 15+ messages in thread
From: Greg Kroah-Hartman @ 2021-11-04 14:12 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Hans de Goede, Mathias Nyman,
Chris Chiu, Alan Stern, Kishon Vijay Abraham I
From: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
This reverts commit 20c9fdde30fbe797aec0e0a04fb77013fe473886 which is
commit 58877b0824da15698bd85a0a9dbfa8c354e6ecb7 upstream.
It has been reported to be causing problems in Arch and Fedora bug
reports.
Reported-by: Hans de Goede <hdegoede@redhat.com>
Link: https://bbs.archlinux.org/viewtopic.php?pid=2000956#p2000956
Link: https://bugzilla.redhat.com/show_bug.cgi?id=2019542
Link: https://bugzilla.redhat.com/show_bug.cgi?id=2019576
Link: https://lore.kernel.org/r/42bcbea6-5eb8-16c7-336a-2cb72e71bc36@redhat.com
Cc: Mathias Nyman <mathias.nyman@linux.intel.com>
Cc: Chris Chiu <chris.chiu@canonical.com>
Cc: Alan Stern <stern@rowland.harvard.edu>
Cc: Kishon Vijay Abraham I <kishon@ti.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/usb/core/hcd.c | 29 ++++++-----------------------
include/linux/usb/hcd.h | 2 --
2 files changed, 6 insertions(+), 25 deletions(-)
--- a/drivers/usb/core/hcd.c
+++ b/drivers/usb/core/hcd.c
@@ -2636,7 +2636,6 @@ int usb_add_hcd(struct usb_hcd *hcd,
{
int retval;
struct usb_device *rhdev;
- struct usb_hcd *shared_hcd;
if (!hcd->skip_phy_initialization && usb_hcd_is_primary_hcd(hcd)) {
hcd->phy_roothub = usb_phy_roothub_alloc(hcd->self.sysdev);
@@ -2793,26 +2792,13 @@ int usb_add_hcd(struct usb_hcd *hcd,
goto err_hcd_driver_start;
}
- /* starting here, usbcore will pay attention to the shared HCD roothub */
- shared_hcd = hcd->shared_hcd;
- if (!usb_hcd_is_primary_hcd(hcd) && shared_hcd && HCD_DEFER_RH_REGISTER(shared_hcd)) {
- retval = register_root_hub(shared_hcd);
- if (retval != 0)
- goto err_register_root_hub;
-
- if (shared_hcd->uses_new_polling && HCD_POLL_RH(shared_hcd))
- usb_hcd_poll_rh_status(shared_hcd);
- }
-
/* starting here, usbcore will pay attention to this root hub */
- if (!HCD_DEFER_RH_REGISTER(hcd)) {
- retval = register_root_hub(hcd);
- if (retval != 0)
- goto err_register_root_hub;
+ retval = register_root_hub(hcd);
+ if (retval != 0)
+ goto err_register_root_hub;
- if (hcd->uses_new_polling && HCD_POLL_RH(hcd))
- usb_hcd_poll_rh_status(hcd);
- }
+ if (hcd->uses_new_polling && HCD_POLL_RH(hcd))
+ usb_hcd_poll_rh_status(hcd);
return retval;
@@ -2855,7 +2841,6 @@ EXPORT_SYMBOL_GPL(usb_add_hcd);
void usb_remove_hcd(struct usb_hcd *hcd)
{
struct usb_device *rhdev = hcd->self.root_hub;
- bool rh_registered;
dev_info(hcd->self.controller, "remove, state %x\n", hcd->state);
@@ -2866,7 +2851,6 @@ void usb_remove_hcd(struct usb_hcd *hcd)
dev_dbg(hcd->self.controller, "roothub graceful disconnect\n");
spin_lock_irq (&hcd_root_hub_lock);
- rh_registered = hcd->rh_registered;
hcd->rh_registered = 0;
spin_unlock_irq (&hcd_root_hub_lock);
@@ -2876,8 +2860,7 @@ void usb_remove_hcd(struct usb_hcd *hcd)
cancel_work_sync(&hcd->died_work);
mutex_lock(&usb_bus_idr_lock);
- if (rh_registered)
- usb_disconnect(&rhdev); /* Sets rhdev to NULL */
+ usb_disconnect(&rhdev); /* Sets rhdev to NULL */
mutex_unlock(&usb_bus_idr_lock);
/*
--- a/include/linux/usb/hcd.h
+++ b/include/linux/usb/hcd.h
@@ -124,7 +124,6 @@ struct usb_hcd {
#define HCD_FLAG_RH_RUNNING 5 /* root hub is running? */
#define HCD_FLAG_DEAD 6 /* controller has died? */
#define HCD_FLAG_INTF_AUTHORIZED 7 /* authorize interfaces? */
-#define HCD_FLAG_DEFER_RH_REGISTER 8 /* Defer roothub registration */
/* The flags can be tested using these macros; they are likely to
* be slightly faster than test_bit().
@@ -135,7 +134,6 @@ struct usb_hcd {
#define HCD_WAKEUP_PENDING(hcd) ((hcd)->flags & (1U << HCD_FLAG_WAKEUP_PENDING))
#define HCD_RH_RUNNING(hcd) ((hcd)->flags & (1U << HCD_FLAG_RH_RUNNING))
#define HCD_DEAD(hcd) ((hcd)->flags & (1U << HCD_FLAG_DEAD))
-#define HCD_DEFER_RH_REGISTER(hcd) ((hcd)->flags & (1U << HCD_FLAG_DEFER_RH_REGISTER))
/*
* Specifies if interfaces are authorized by default
^ permalink raw reply [flat|nested] 15+ messages in thread* [PATCH 5.4 7/9] sfc: Fix reading non-legacy supported link modes
2021-11-04 14:12 [PATCH 5.4 0/9] 5.4.158-rc1 review Greg Kroah-Hartman
` (5 preceding siblings ...)
2021-11-04 14:12 ` [PATCH 5.4 6/9] Revert "usb: core: hcd: Add support for deferring " Greg Kroah-Hartman
@ 2021-11-04 14:13 ` Greg Kroah-Hartman
2021-11-04 14:13 ` [PATCH 5.4 8/9] Revert "drm/ttm: fix memleak in ttm_transfered_destroy" Greg Kroah-Hartman
` (6 subsequent siblings)
13 siblings, 0 replies; 15+ messages in thread
From: Greg Kroah-Hartman @ 2021-11-04 14:13 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, Erik Ekman, David S. Miller
From: Erik Ekman <erik@kryo.se>
commit 041c61488236a5a84789083e3d9f0a51139b6edf upstream.
Everything except the first 32 bits was lost when the pause flags were
added. This makes the 50000baseCR2 mode flag (bit 34) not appear.
I have tested this with a 10G card (SFN5122F-R7) by modifying it to
return a non-legacy link mode (10000baseCR).
Signed-off-by: Erik Ekman <erik@kryo.se>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/net/ethernet/sfc/ethtool.c | 10 ++--------
1 file changed, 2 insertions(+), 8 deletions(-)
--- a/drivers/net/ethernet/sfc/ethtool.c
+++ b/drivers/net/ethernet/sfc/ethtool.c
@@ -128,20 +128,14 @@ efx_ethtool_get_link_ksettings(struct ne
{
struct efx_nic *efx = netdev_priv(net_dev);
struct efx_link_state *link_state = &efx->link_state;
- u32 supported;
mutex_lock(&efx->mac_lock);
efx->phy_op->get_link_ksettings(efx, cmd);
mutex_unlock(&efx->mac_lock);
/* Both MACs support pause frames (bidirectional and respond-only) */
- ethtool_convert_link_mode_to_legacy_u32(&supported,
- cmd->link_modes.supported);
-
- supported |= SUPPORTED_Pause | SUPPORTED_Asym_Pause;
-
- ethtool_convert_legacy_u32_to_link_mode(cmd->link_modes.supported,
- supported);
+ ethtool_link_ksettings_add_link_mode(cmd, supported, Pause);
+ ethtool_link_ksettings_add_link_mode(cmd, supported, Asym_Pause);
if (LOOPBACK_INTERNAL(efx)) {
cmd->base.speed = link_state->speed;
^ permalink raw reply [flat|nested] 15+ messages in thread* [PATCH 5.4 8/9] Revert "drm/ttm: fix memleak in ttm_transfered_destroy"
2021-11-04 14:12 [PATCH 5.4 0/9] 5.4.158-rc1 review Greg Kroah-Hartman
` (6 preceding siblings ...)
2021-11-04 14:13 ` [PATCH 5.4 7/9] sfc: Fix reading non-legacy supported link modes Greg Kroah-Hartman
@ 2021-11-04 14:13 ` Greg Kroah-Hartman
2021-11-04 14:13 ` [PATCH 5.4 9/9] ARM: 9120/1: Revert "amba: make use of -1 IRQs warn" Greg Kroah-Hartman
` (5 subsequent siblings)
13 siblings, 0 replies; 15+ messages in thread
From: Greg Kroah-Hartman @ 2021-11-04 14:13 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Christian König, Erhard F., Huang Rui
From: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
This reverts commit bd99782f3ca491879e8524c89b1c0f40071903bd which is
commit 0db55f9a1bafbe3dac750ea669de9134922389b5 upstream.
Seems that the older kernels can not handle this fix because, to quote
Christian:
The problem is this memory leak could potentially happen with
5.10 as wel, just much much much less likely.
But my guess is that 5.10 is so buggy that when the leak does
NOT happen we double free and obviously causing a crash.
So it needs to be reverted.
Link: https://lore.kernel.org/r/1a1cc125-9314-f569-a6c4-40fc4509a377@amd.com
Cc: Christian König <christian.koenig@amd.com>
Cc: Erhard F. <erhard_f@mailbox.org>
Cc: Erhard F. <erhard_f@mailbox.org>
Cc: Huang Rui <ray.huang@amd.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/gpu/drm/ttm/ttm_bo_util.c | 1 -
1 file changed, 1 deletion(-)
--- a/drivers/gpu/drm/ttm/ttm_bo_util.c
+++ b/drivers/gpu/drm/ttm/ttm_bo_util.c
@@ -463,7 +463,6 @@ static void ttm_transfered_destroy(struc
struct ttm_transfer_obj *fbo;
fbo = container_of(bo, struct ttm_transfer_obj, base);
- dma_resv_fini(&fbo->base.base._resv);
ttm_bo_put(fbo->bo);
kfree(fbo);
}
^ permalink raw reply [flat|nested] 15+ messages in thread* [PATCH 5.4 9/9] ARM: 9120/1: Revert "amba: make use of -1 IRQs warn"
2021-11-04 14:12 [PATCH 5.4 0/9] 5.4.158-rc1 review Greg Kroah-Hartman
` (7 preceding siblings ...)
2021-11-04 14:13 ` [PATCH 5.4 8/9] Revert "drm/ttm: fix memleak in ttm_transfered_destroy" Greg Kroah-Hartman
@ 2021-11-04 14:13 ` Greg Kroah-Hartman
2021-11-04 21:21 ` [PATCH 5.4 0/9] 5.4.158-rc1 review Florian Fainelli
` (4 subsequent siblings)
13 siblings, 0 replies; 15+ messages in thread
From: Greg Kroah-Hartman @ 2021-11-04 14:13 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Rob Herring, Kefeng Wang,
Russell King (Oracle)
From: Wang Kefeng <wangkefeng.wang@huawei.com>
commit eb4f756915875b0ea0757751cd29841f0504d547 upstream.
After commit 77a7300abad7 ("of/irq: Get rid of NO_IRQ usage"),
no irq case has been removed, irq_of_parse_and_map() will return
0 in all cases when get error from parse and map an interrupt into
linux virq space.
amba_device_register() is only used on no-DT initialization, see
s3c64xx_pl080_init() arch/arm/mach-s3c/pl080.c
ep93xx_init_devices() arch/arm/mach-ep93xx/core.c
They won't set -1 to irq[0], so no need the warn.
This reverts commit 2eac58d5026e4ec8b17ff8b62877fea9e1d2f1b3.
Reviewed-by: Rob Herring <robh@kernel.org>
Signed-off-by: Kefeng Wang <wangkefeng.wang@huawei.com>
Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/amba/bus.c | 3 ---
1 file changed, 3 deletions(-)
--- a/drivers/amba/bus.c
+++ b/drivers/amba/bus.c
@@ -375,9 +375,6 @@ static int amba_device_try_add(struct am
void __iomem *tmp;
int i, ret;
- WARN_ON(dev->irq[0] == (unsigned int)-1);
- WARN_ON(dev->irq[1] == (unsigned int)-1);
-
ret = request_resource(parent, &dev->res);
if (ret)
goto err_out;
^ permalink raw reply [flat|nested] 15+ messages in thread* Re: [PATCH 5.4 0/9] 5.4.158-rc1 review
2021-11-04 14:12 [PATCH 5.4 0/9] 5.4.158-rc1 review Greg Kroah-Hartman
` (8 preceding siblings ...)
2021-11-04 14:13 ` [PATCH 5.4 9/9] ARM: 9120/1: Revert "amba: make use of -1 IRQs warn" Greg Kroah-Hartman
@ 2021-11-04 21:21 ` Florian Fainelli
2021-11-04 22:22 ` Shuah Khan
` (3 subsequent siblings)
13 siblings, 0 replies; 15+ messages in thread
From: Florian Fainelli @ 2021-11-04 21:21 UTC (permalink / raw)
To: Greg Kroah-Hartman, linux-kernel
Cc: torvalds, akpm, linux, shuah, patches, lkft-triage, pavel,
jonathanh, stable
On 11/4/21 7:12 AM, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 5.4.158 release.
> There are 9 patches in this series, all will be posted as a response
> to this one. If anyone has any issues with these being applied, please
> let me know.
>
> Responses should be made by Sat, 06 Nov 2021 14:11:51 +0000.
> Anything received after that time might be too late.
>
> The whole patch series can be found in one patch at:
> https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.4.158-rc1.gz
> or in the git tree and branch at:
> git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-5.4.y
> and the diffstat can be found below.
>
> thanks,
>
> greg k-h
On ARCH_BRCMSTB, using 32-bit and 64-bit ARM kernels:
Tested-by: Florian Fainelli <f.fainelli@gmail.com>
--
Florian
^ permalink raw reply [flat|nested] 15+ messages in thread* Re: [PATCH 5.4 0/9] 5.4.158-rc1 review
2021-11-04 14:12 [PATCH 5.4 0/9] 5.4.158-rc1 review Greg Kroah-Hartman
` (9 preceding siblings ...)
2021-11-04 21:21 ` [PATCH 5.4 0/9] 5.4.158-rc1 review Florian Fainelli
@ 2021-11-04 22:22 ` Shuah Khan
2021-11-05 11:36 ` Naresh Kamboju
` (2 subsequent siblings)
13 siblings, 0 replies; 15+ messages in thread
From: Shuah Khan @ 2021-11-04 22:22 UTC (permalink / raw)
To: Greg Kroah-Hartman, linux-kernel
Cc: torvalds, akpm, linux, shuah, patches, lkft-triage, pavel,
jonathanh, f.fainelli, stable, Shuah Khan
On 11/4/21 8:12 AM, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 5.4.158 release.
> There are 9 patches in this series, all will be posted as a response
> to this one. If anyone has any issues with these being applied, please
> let me know.
>
> Responses should be made by Sat, 06 Nov 2021 14:11:51 +0000.
> Anything received after that time might be too late.
>
> The whole patch series can be found in one patch at:
> https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.4.158-rc1.gz
> or in the git tree and branch at:
> git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-5.4.y
> and the diffstat can be found below.
>
> thanks,
>
> greg k-h
>
Compiled and booted on my test system. No dmesg regressions.
Tested-by: Shuah Khan <skhan@linuxfoundation.org>
thanks,
-- Shuah
^ permalink raw reply [flat|nested] 15+ messages in thread* Re: [PATCH 5.4 0/9] 5.4.158-rc1 review
2021-11-04 14:12 [PATCH 5.4 0/9] 5.4.158-rc1 review Greg Kroah-Hartman
` (10 preceding siblings ...)
2021-11-04 22:22 ` Shuah Khan
@ 2021-11-05 11:36 ` Naresh Kamboju
2021-11-05 12:48 ` Sudip Mukherjee
2021-11-05 15:13 ` Guenter Roeck
13 siblings, 0 replies; 15+ messages in thread
From: Naresh Kamboju @ 2021-11-05 11:36 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: linux-kernel, shuah, f.fainelli, patches, lkft-triage, jonathanh,
stable, pavel, akpm, torvalds, linux
On Thu, 4 Nov 2021 at 19:46, Greg Kroah-Hartman
<gregkh@linuxfoundation.org> wrote:
>
> This is the start of the stable review cycle for the 5.4.158 release.
> There are 9 patches in this series, all will be posted as a response
> to this one. If anyone has any issues with these being applied, please
> let me know.
>
> Responses should be made by Sat, 06 Nov 2021 14:11:51 +0000.
> Anything received after that time might be too late.
>
> The whole patch series can be found in one patch at:
> https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.4.158-rc1.gz
> or in the git tree and branch at:
> git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-5.4.y
> and the diffstat can be found below.
>
> thanks,
>
> greg k-h
Results from Linaro’s test farm.
No regressions on arm64, arm, x86_64, and i386.
Tested-by: Linux Kernel Functional Testing <lkft@linaro.org>
## Build
* kernel: 5.4.158-rc1
* git: https://gitlab.com/Linaro/lkft/mirrors/stable/linux-stable-rc
* git branch: linux-5.4.y
* git commit: f4b30ec4660320a284634b244975523964b581bb
* git describe: v5.4.157-10-gf4b30ec46603
* test details:
https://qa-reports.linaro.org/lkft/linux-stable-rc-linux-5.4.y/build/v5.4.157-10-gf4b30ec46603
## No regressions (compared to v5.4.157)
## No fixes (compared to v5.4.157)
## Test result summary
total: 91815, pass: 75798, fail: 826, skip: 13900, xfail: 1291
## Build Summary
* arc: 10 total, 10 passed, 0 failed
* arm: 289 total, 267 passed, 22 failed
* arm64: 39 total, 39 passed, 0 failed
* dragonboard-410c: 1 total, 1 passed, 0 failed
* hi6220-hikey: 1 total, 1 passed, 0 failed
* i386: 20 total, 20 passed, 0 failed
* juno-r2: 1 total, 1 passed, 0 failed
* mips: 37 total, 37 passed, 0 failed
* parisc: 12 total, 12 passed, 0 failed
* powerpc: 36 total, 36 passed, 0 failed
* riscv: 24 total, 24 passed, 0 failed
* s390: 12 total, 12 passed, 0 failed
* sh: 24 total, 24 passed, 0 failed
* sparc: 12 total, 12 passed, 0 failed
* x15: 1 total, 1 passed, 0 failed
* x86: 1 total, 1 passed, 0 failed
* x86_64: 39 total, 39 passed, 0 failed
## Test suites summary
* fwts
* igt-gpu-tools
* kselftest-android
* kselftest-arm64
* kselftest-arm64/arm64.btitest.bti_c_func
* kselftest-arm64/arm64.btitest.bti_j_func
* kselftest-arm64/arm64.btitest.bti_jc_func
* kselftest-arm64/arm64.btitest.bti_none_func
* kselftest-arm64/arm64.btitest.nohint_func
* kselftest-arm64/arm64.btitest.paciasp_func
* kselftest-arm64/arm64.nobtitest.bti_c_func
* kselftest-arm64/arm64.nobtitest.bti_j_func
* kselftest-arm64/arm64.nobtitest.bti_jc_func
* kselftest-arm64/arm64.nobtitest.bti_none_func
* kselftest-arm64/arm64.nobtitest.nohint_func
* kselftest-arm64/arm64.nobtitest.paciasp_func
* kselftest-bpf
* kselftest-breakpoints
* kselftest-capabilities
* kselftest-cgroup
* kselftest-clone3
* kselftest-core
* kselftest-cpu-hotplug
* kselftest-cpufreq
* kselftest-drivers
* kselftest-efivarfs
* kselftest-filesystems
* kselftest-firmware
* kselftest-fpu
* kselftest-futex
* kselftest-gpio
* kselftest-intel_pstate
* kselftest-ipc
* kselftest-ir
* kselftest-kcmp
* kselftest-kexec
* kselftest-kvm
* kselftest-lib
* kselftest-livepatch
* kselftest-membarrier
* kselftest-memfd
* kselftest-memory-hotplug
* kselftest-mincore
* kselftest-mount
* kselftest-mqueue
* kselftest-net
* kselftest-netfilter
* kselftest-nsfs
* kselftest-openat2
* kselftest-pid_namespace
* kselftest-pidfd
* kselftest-proc
* kselftest-pstore
* kselftest-ptrace
* kselftest-rseq
* kselftest-rtc
* kselftest-seccomp
* kselftest-sigaltstack
* kselftest-size
* kselftest-splice
* kselftest-static_keys
* kselftest-sync
* kselftest-sysctl
* kselftest-tc-testing
* kselftest-timens
* kselftest-timers
* kselftest-tmpfs
* kselftest-tpm2
* kselftest-user
* kselftest-vm
* kselftest-x86
* kselftest-zram
* kvm-unit-tests
* libgpiod
* libhugetlbfs
* linux-log-parser
* ltp-cap_bounds-tests
* ltp-commands-tests
* ltp-containers-tests
* ltp-controllers-tests
* ltp-cpuhotplug-tests
* ltp-crypto-tests
* ltp-cve-tests
* ltp-dio-tests
* ltp-fcntl-locktests-tests
* ltp-filecaps-tests
* ltp-fs-tests
* ltp-fs_bind-tests
* ltp-fs_perms_simple-tests
* ltp-fsx-tests
* ltp-hugetlb-tests
* ltp-io-tests
* ltp-ipc-tests
* ltp-math-tests
* ltp-mm-tests
* ltp-nptl-tests
* ltp-open-posix-tests
* ltp-pty-tests
* ltp-sched-tests
* ltp-securebits-tests
* ltp-syscalls-tests
* ltp-tracing-tests
* network-basic-tests
* packetdrill
* perf
* perf/Zstd-perf.data-compression
* rcutorture
* ssuite
* v4l2-compliance
--
Linaro LKFT
https://lkft.linaro.org
^ permalink raw reply [flat|nested] 15+ messages in thread* Re: [PATCH 5.4 0/9] 5.4.158-rc1 review
2021-11-04 14:12 [PATCH 5.4 0/9] 5.4.158-rc1 review Greg Kroah-Hartman
` (11 preceding siblings ...)
2021-11-05 11:36 ` Naresh Kamboju
@ 2021-11-05 12:48 ` Sudip Mukherjee
2021-11-05 15:13 ` Guenter Roeck
13 siblings, 0 replies; 15+ messages in thread
From: Sudip Mukherjee @ 2021-11-05 12:48 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: linux-kernel, torvalds, akpm, linux, shuah, patches, lkft-triage,
pavel, jonathanh, f.fainelli, stable
Hi Greg,
On Thu, Nov 04, 2021 at 03:12:53PM +0100, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 5.4.158 release.
> There are 9 patches in this series, all will be posted as a response
> to this one. If anyone has any issues with these being applied, please
> let me know.
>
> Responses should be made by Sat, 06 Nov 2021 14:11:51 +0000.
> Anything received after that time might be too late.
Build test:
mips (gcc version 11.2.1 20211104): 65 configs -> no new failure
arm (gcc version 11.2.1 20211104): 107 configs -> no new failure
arm64 (gcc version 11.2.1 20211104): 2 configs -> no failure
x86_64 (gcc version 11.2.1 20211104): 4 configs -> no failure
Boot test:
x86_64: Booted on my test laptop. No regression.
x86_64: Booted on qemu. No regression. [1]
[1]. https://openqa.qa.codethink.co.uk/tests/343
Tested-by: Sudip Mukherjee <sudip.mukherjee@codethink.co.uk>
--
Regards
Sudip
^ permalink raw reply [flat|nested] 15+ messages in thread* Re: [PATCH 5.4 0/9] 5.4.158-rc1 review
2021-11-04 14:12 [PATCH 5.4 0/9] 5.4.158-rc1 review Greg Kroah-Hartman
` (12 preceding siblings ...)
2021-11-05 12:48 ` Sudip Mukherjee
@ 2021-11-05 15:13 ` Guenter Roeck
13 siblings, 0 replies; 15+ messages in thread
From: Guenter Roeck @ 2021-11-05 15:13 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: linux-kernel, torvalds, akpm, shuah, patches, lkft-triage, pavel,
jonathanh, f.fainelli, stable
On Thu, Nov 04, 2021 at 03:12:53PM +0100, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 5.4.158 release.
> There are 9 patches in this series, all will be posted as a response
> to this one. If anyone has any issues with these being applied, please
> let me know.
>
> Responses should be made by Sat, 06 Nov 2021 14:11:51 +0000.
> Anything received after that time might be too late.
>
Build results:
total: 157 pass: 157 fail: 0
Qemu test results:
total: 446 pass: 446 fail: 0
Tested-by: Guenter Roeck <linux@roeck-us.net>
Guenter
^ permalink raw reply [flat|nested] 15+ messages in thread