* [PATCH AUTOSEL 4.4 02/16] serial: 8250_omap: Fix sleeping function called from invalid context during probe
2020-04-11 23:14 [PATCH AUTOSEL 4.4 01/16] net: wan: wanxl: use allow to pass CROSS_COMPILE_M68k for rebuilding firmware Sasha Levin
@ 2020-04-11 23:14 ` Sasha Levin
2020-04-11 23:14 ` [PATCH AUTOSEL 4.4 03/16] RDMA/cm: Add missing locking around id.state in cm_dup_req_handler Sasha Levin
` (13 subsequent siblings)
14 siblings, 0 replies; 22+ messages in thread
From: Sasha Levin @ 2020-04-11 23:14 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Peter Ujfalusi, Tomi Valkeinen, Greg Kroah-Hartman, Sasha Levin,
linux-serial
From: Peter Ujfalusi <peter.ujfalusi@ti.com>
[ Upstream commit 4ce35a3617c0ac758c61122b2218b6c8c9ac9398 ]
When booting j721e the following bug is printed:
[ 1.154821] BUG: sleeping function called from invalid context at kernel/sched/completion.c:99
[ 1.154827] in_atomic(): 0, irqs_disabled(): 128, non_block: 0, pid: 12, name: kworker/0:1
[ 1.154832] 3 locks held by kworker/0:1/12:
[ 1.154836] #0: ffff000840030728 ((wq_completion)events){+.+.}, at: process_one_work+0x1d4/0x6e8
[ 1.154852] #1: ffff80001214fdd8 (deferred_probe_work){+.+.}, at: process_one_work+0x1d4/0x6e8
[ 1.154860] #2: ffff00084060b170 (&dev->mutex){....}, at: __device_attach+0x38/0x138
[ 1.154872] irq event stamp: 63096
[ 1.154881] hardirqs last enabled at (63095): [<ffff800010b74318>] _raw_spin_unlock_irqrestore+0x70/0x78
[ 1.154887] hardirqs last disabled at (63096): [<ffff800010b740d8>] _raw_spin_lock_irqsave+0x28/0x80
[ 1.154893] softirqs last enabled at (62254): [<ffff800010080c88>] _stext+0x488/0x564
[ 1.154899] softirqs last disabled at (62247): [<ffff8000100fdb3c>] irq_exit+0x114/0x140
[ 1.154906] CPU: 0 PID: 12 Comm: kworker/0:1 Not tainted 5.6.0-rc6-next-20200318-00094-g45e4089b0bd3 #221
[ 1.154911] Hardware name: Texas Instruments K3 J721E SoC (DT)
[ 1.154917] Workqueue: events deferred_probe_work_func
[ 1.154923] Call trace:
[ 1.154928] dump_backtrace+0x0/0x190
[ 1.154933] show_stack+0x14/0x20
[ 1.154940] dump_stack+0xe0/0x148
[ 1.154946] ___might_sleep+0x150/0x1f0
[ 1.154952] __might_sleep+0x4c/0x80
[ 1.154957] wait_for_completion_timeout+0x40/0x140
[ 1.154964] ti_sci_set_device_state+0xa0/0x158
[ 1.154969] ti_sci_cmd_get_device_exclusive+0x14/0x20
[ 1.154977] ti_sci_dev_start+0x34/0x50
[ 1.154984] genpd_runtime_resume+0x78/0x1f8
[ 1.154991] __rpm_callback+0x3c/0x140
[ 1.154996] rpm_callback+0x20/0x80
[ 1.155001] rpm_resume+0x568/0x758
[ 1.155007] __pm_runtime_resume+0x44/0xb0
[ 1.155013] omap8250_probe+0x2b4/0x508
[ 1.155019] platform_drv_probe+0x50/0xa0
[ 1.155023] really_probe+0xd4/0x318
[ 1.155028] driver_probe_device+0x54/0xe8
[ 1.155033] __device_attach_driver+0x80/0xb8
[ 1.155039] bus_for_each_drv+0x74/0xc0
[ 1.155044] __device_attach+0xdc/0x138
[ 1.155049] device_initial_probe+0x10/0x18
[ 1.155053] bus_probe_device+0x98/0xa0
[ 1.155058] deferred_probe_work_func+0x74/0xb0
[ 1.155063] process_one_work+0x280/0x6e8
[ 1.155068] worker_thread+0x48/0x430
[ 1.155073] kthread+0x108/0x138
[ 1.155079] ret_from_fork+0x10/0x18
To fix the bug we need to first call pm_runtime_enable() prior to any
pm_runtime calls.
Reported-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
Link: https://lore.kernel.org/r/20200320125200.6772-1-peter.ujfalusi@ti.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/tty/serial/8250/8250_omap.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/tty/serial/8250/8250_omap.c b/drivers/tty/serial/8250/8250_omap.c
index c4383573cf668..0377b35d62b80 100644
--- a/drivers/tty/serial/8250/8250_omap.c
+++ b/drivers/tty/serial/8250/8250_omap.c
@@ -1188,11 +1188,11 @@ static int omap8250_probe(struct platform_device *pdev)
spin_lock_init(&priv->rx_dma_lock);
device_init_wakeup(&pdev->dev, true);
+ pm_runtime_enable(&pdev->dev);
pm_runtime_use_autosuspend(&pdev->dev);
pm_runtime_set_autosuspend_delay(&pdev->dev, -1);
pm_runtime_irq_safe(&pdev->dev);
- pm_runtime_enable(&pdev->dev);
pm_runtime_get_sync(&pdev->dev);
--
2.20.1
^ permalink raw reply related [flat|nested] 22+ messages in thread* [PATCH AUTOSEL 4.4 03/16] RDMA/cm: Add missing locking around id.state in cm_dup_req_handler
2020-04-11 23:14 [PATCH AUTOSEL 4.4 01/16] net: wan: wanxl: use allow to pass CROSS_COMPILE_M68k for rebuilding firmware Sasha Levin
2020-04-11 23:14 ` [PATCH AUTOSEL 4.4 02/16] serial: 8250_omap: Fix sleeping function called from invalid context during probe Sasha Levin
@ 2020-04-11 23:14 ` Sasha Levin
2020-04-11 23:14 ` [PATCH AUTOSEL 4.4 04/16] mwifiex: set needed_headroom, not hard_header_len Sasha Levin
` (12 subsequent siblings)
14 siblings, 0 replies; 22+ messages in thread
From: Sasha Levin @ 2020-04-11 23:14 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Jason Gunthorpe, Leon Romanovsky, Sasha Levin, linux-rdma
From: Jason Gunthorpe <jgg@mellanox.com>
[ Upstream commit d1de9a88074b66482443f0cd91618d7b51a7c9b6 ]
All accesses to id.state must be done under the spinlock.
Fixes: a977049dacde ("[PATCH] IB: Add the kernel CM implementation")
Link: https://lore.kernel.org/r/20200310092545.251365-10-leon@kernel.org
Signed-off-by: Leon Romanovsky <leonro@mellanox.com>
Signed-off-by: Jason Gunthorpe <jgg@mellanox.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/infiniband/core/cm.c | 6 +++++-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/drivers/infiniband/core/cm.c b/drivers/infiniband/core/cm.c
index 53c622c99ee40..7bf98d72a4559 100644
--- a/drivers/infiniband/core/cm.c
+++ b/drivers/infiniband/core/cm.c
@@ -1544,8 +1544,12 @@ static void cm_dup_req_handler(struct cm_work *work,
counter[CM_REQ_COUNTER]);
/* Quick state check to discard duplicate REQs. */
- if (cm_id_priv->id.state == IB_CM_REQ_RCVD)
+ spin_lock_irq(&cm_id_priv->lock);
+ if (cm_id_priv->id.state == IB_CM_REQ_RCVD) {
+ spin_unlock_irq(&cm_id_priv->lock);
return;
+ }
+ spin_unlock_irq(&cm_id_priv->lock);
ret = cm_alloc_response_msg(work->port, work->mad_recv_wc, &msg);
if (ret)
--
2.20.1
^ permalink raw reply related [flat|nested] 22+ messages in thread* [PATCH AUTOSEL 4.4 04/16] mwifiex: set needed_headroom, not hard_header_len
2020-04-11 23:14 [PATCH AUTOSEL 4.4 01/16] net: wan: wanxl: use allow to pass CROSS_COMPILE_M68k for rebuilding firmware Sasha Levin
2020-04-11 23:14 ` [PATCH AUTOSEL 4.4 02/16] serial: 8250_omap: Fix sleeping function called from invalid context during probe Sasha Levin
2020-04-11 23:14 ` [PATCH AUTOSEL 4.4 03/16] RDMA/cm: Add missing locking around id.state in cm_dup_req_handler Sasha Levin
@ 2020-04-11 23:14 ` Sasha Levin
2020-04-11 23:14 ` [PATCH AUTOSEL 4.4 05/16] Bluetooth: L2CAP: handle l2cap config request during open state Sasha Levin
` (11 subsequent siblings)
14 siblings, 0 replies; 22+ messages in thread
From: Sasha Levin @ 2020-04-11 23:14 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Brian Norris, Ganapathi Bhat, Kalle Valo, Sasha Levin,
linux-wireless, netdev
From: Brian Norris <briannorris@chromium.org>
[ Upstream commit 9454f7a895b822dd8fb4588fc55fda7c96728869 ]
hard_header_len provides limitations for things like AF_PACKET, such
that we don't allow transmitting packets smaller than this.
needed_headroom provides a suggested minimum headroom for SKBs, so that
we can trivally add our headers to the front.
The latter is the correct field to use in this case, while the former
mostly just prevents sending small AF_PACKET frames.
In any case, mwifiex already does its own bounce buffering [1] if we
don't have enough headroom, so hints (not hard limits) are all that are
needed.
This is the essentially the same bug (and fix) that brcmfmac had, fixed
in commit cb39288fd6bb ("brcmfmac: use ndev->needed_headroom to reserve
additional header space").
[1] mwifiex_hard_start_xmit():
if (skb_headroom(skb) < MWIFIEX_MIN_DATA_HEADER_LEN) {
[...]
/* Insufficient skb headroom - allocate a new skb */
Fixes: 5e6e3a92b9a4 ("wireless: mwifiex: initial commit for Marvell mwifiex driver")
Signed-off-by: Brian Norris <briannorris@chromium.org>
Acked-by: Ganapathi Bhat <ganapathi.gbhat@nxp.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/net/wireless/mwifiex/cfg80211.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/wireless/mwifiex/cfg80211.c b/drivers/net/wireless/mwifiex/cfg80211.c
index c6c2d3304dba7..4f4af48fc3fc6 100644
--- a/drivers/net/wireless/mwifiex/cfg80211.c
+++ b/drivers/net/wireless/mwifiex/cfg80211.c
@@ -2755,7 +2755,7 @@ struct wireless_dev *mwifiex_add_virtual_intf(struct wiphy *wiphy,
dev->flags |= IFF_BROADCAST | IFF_MULTICAST;
dev->watchdog_timeo = MWIFIEX_DEFAULT_WATCHDOG_TIMEOUT;
- dev->hard_header_len += MWIFIEX_MIN_DATA_HEADER_LEN;
+ dev->needed_headroom = MWIFIEX_MIN_DATA_HEADER_LEN;
dev->ethtool_ops = &mwifiex_ethtool_ops;
mdev_priv = netdev_priv(dev);
--
2.20.1
^ permalink raw reply related [flat|nested] 22+ messages in thread* [PATCH AUTOSEL 4.4 05/16] Bluetooth: L2CAP: handle l2cap config request during open state
2020-04-11 23:14 [PATCH AUTOSEL 4.4 01/16] net: wan: wanxl: use allow to pass CROSS_COMPILE_M68k for rebuilding firmware Sasha Levin
` (2 preceding siblings ...)
2020-04-11 23:14 ` [PATCH AUTOSEL 4.4 04/16] mwifiex: set needed_headroom, not hard_header_len Sasha Levin
@ 2020-04-11 23:14 ` Sasha Levin
2020-04-11 23:14 ` [PATCH AUTOSEL 4.4 06/16] Bluetooth: Fix calculation of SCO handle for packet processing Sasha Levin
` (10 subsequent siblings)
14 siblings, 0 replies; 22+ messages in thread
From: Sasha Levin @ 2020-04-11 23:14 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Howard Chung, Marcel Holtmann, Sasha Levin, linux-bluetooth, netdev
From: Howard Chung <howardchung@google.com>
[ Upstream commit 96298f640104e4cd9a913a6e50b0b981829b94ff ]
According to Core Spec Version 5.2 | Vol 3, Part A 6.1.5,
the incoming L2CAP_ConfigReq should be handled during
OPEN state.
The section below shows the btmon trace when running
L2CAP/COS/CFD/BV-12-C before and after this change.
=== Before ===
...
> ACL Data RX: Handle 256 flags 0x02 dlen 12 #22
L2CAP: Connection Request (0x02) ident 2 len 4
PSM: 1 (0x0001)
Source CID: 65
< ACL Data TX: Handle 256 flags 0x00 dlen 16 #23
L2CAP: Connection Response (0x03) ident 2 len 8
Destination CID: 64
Source CID: 65
Result: Connection successful (0x0000)
Status: No further information available (0x0000)
< ACL Data TX: Handle 256 flags 0x00 dlen 12 #24
L2CAP: Configure Request (0x04) ident 2 len 4
Destination CID: 65
Flags: 0x0000
> HCI Event: Number of Completed Packets (0x13) plen 5 #25
Num handles: 1
Handle: 256
Count: 1
> HCI Event: Number of Completed Packets (0x13) plen 5 #26
Num handles: 1
Handle: 256
Count: 1
> ACL Data RX: Handle 256 flags 0x02 dlen 16 #27
L2CAP: Configure Request (0x04) ident 3 len 8
Destination CID: 64
Flags: 0x0000
Option: Unknown (0x10) [hint]
01 00 ..
< ACL Data TX: Handle 256 flags 0x00 dlen 18 #28
L2CAP: Configure Response (0x05) ident 3 len 10
Source CID: 65
Flags: 0x0000
Result: Success (0x0000)
Option: Maximum Transmission Unit (0x01) [mandatory]
MTU: 672
> HCI Event: Number of Completed Packets (0x13) plen 5 #29
Num handles: 1
Handle: 256
Count: 1
> ACL Data RX: Handle 256 flags 0x02 dlen 14 #30
L2CAP: Configure Response (0x05) ident 2 len 6
Source CID: 64
Flags: 0x0000
Result: Success (0x0000)
> ACL Data RX: Handle 256 flags 0x02 dlen 20 #31
L2CAP: Configure Request (0x04) ident 3 len 12
Destination CID: 64
Flags: 0x0000
Option: Unknown (0x10) [hint]
01 00 91 02 11 11 ......
< ACL Data TX: Handle 256 flags 0x00 dlen 14 #32
L2CAP: Command Reject (0x01) ident 3 len 6
Reason: Invalid CID in request (0x0002)
Destination CID: 64
Source CID: 65
> HCI Event: Number of Completed Packets (0x13) plen 5 #33
Num handles: 1
Handle: 256
Count: 1
...
=== After ===
...
> ACL Data RX: Handle 256 flags 0x02 dlen 12 #22
L2CAP: Connection Request (0x02) ident 2 len 4
PSM: 1 (0x0001)
Source CID: 65
< ACL Data TX: Handle 256 flags 0x00 dlen 16 #23
L2CAP: Connection Response (0x03) ident 2 len 8
Destination CID: 64
Source CID: 65
Result: Connection successful (0x0000)
Status: No further information available (0x0000)
< ACL Data TX: Handle 256 flags 0x00 dlen 12 #24
L2CAP: Configure Request (0x04) ident 2 len 4
Destination CID: 65
Flags: 0x0000
> HCI Event: Number of Completed Packets (0x13) plen 5 #25
Num handles: 1
Handle: 256
Count: 1
> HCI Event: Number of Completed Packets (0x13) plen 5 #26
Num handles: 1
Handle: 256
Count: 1
> ACL Data RX: Handle 256 flags 0x02 dlen 16 #27
L2CAP: Configure Request (0x04) ident 3 len 8
Destination CID: 64
Flags: 0x0000
Option: Unknown (0x10) [hint]
01 00 ..
< ACL Data TX: Handle 256 flags 0x00 dlen 18 #28
L2CAP: Configure Response (0x05) ident 3 len 10
Source CID: 65
Flags: 0x0000
Result: Success (0x0000)
Option: Maximum Transmission Unit (0x01) [mandatory]
MTU: 672
> HCI Event: Number of Completed Packets (0x13) plen 5 #29
Num handles: 1
Handle: 256
Count: 1
> ACL Data RX: Handle 256 flags 0x02 dlen 14 #30
L2CAP: Configure Response (0x05) ident 2 len 6
Source CID: 64
Flags: 0x0000
Result: Success (0x0000)
> ACL Data RX: Handle 256 flags 0x02 dlen 20 #31
L2CAP: Configure Request (0x04) ident 3 len 12
Destination CID: 64
Flags: 0x0000
Option: Unknown (0x10) [hint]
01 00 91 02 11 11 .....
< ACL Data TX: Handle 256 flags 0x00 dlen 18 #32
L2CAP: Configure Response (0x05) ident 3 len 10
Source CID: 65
Flags: 0x0000
Result: Success (0x0000)
Option: Maximum Transmission Unit (0x01) [mandatory]
MTU: 672
< ACL Data TX: Handle 256 flags 0x00 dlen 12 #33
L2CAP: Configure Request (0x04) ident 3 len 4
Destination CID: 65
Flags: 0x0000
> HCI Event: Number of Completed Packets (0x13) plen 5 #34
Num handles: 1
Handle: 256
Count: 1
> HCI Event: Number of Completed Packets (0x13) plen 5 #35
Num handles: 1
Handle: 256
Count: 1
...
Signed-off-by: Howard Chung <howardchung@google.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
net/bluetooth/l2cap_core.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/net/bluetooth/l2cap_core.c b/net/bluetooth/l2cap_core.c
index 0e31bbe1256cd..a9d1355dd1d08 100644
--- a/net/bluetooth/l2cap_core.c
+++ b/net/bluetooth/l2cap_core.c
@@ -4093,7 +4093,8 @@ static inline int l2cap_config_req(struct l2cap_conn *conn,
return 0;
}
- if (chan->state != BT_CONFIG && chan->state != BT_CONNECT2) {
+ if (chan->state != BT_CONFIG && chan->state != BT_CONNECT2 &&
+ chan->state != BT_CONNECTED) {
cmd_reject_invalid_cid(conn, cmd->ident, chan->scid,
chan->dcid);
goto unlock;
--
2.20.1
^ permalink raw reply related [flat|nested] 22+ messages in thread* [PATCH AUTOSEL 4.4 06/16] Bluetooth: Fix calculation of SCO handle for packet processing
2020-04-11 23:14 [PATCH AUTOSEL 4.4 01/16] net: wan: wanxl: use allow to pass CROSS_COMPILE_M68k for rebuilding firmware Sasha Levin
` (3 preceding siblings ...)
2020-04-11 23:14 ` [PATCH AUTOSEL 4.4 05/16] Bluetooth: L2CAP: handle l2cap config request during open state Sasha Levin
@ 2020-04-11 23:14 ` Sasha Levin
2020-04-11 23:14 ` [PATCH AUTOSEL 4.4 07/16] Bluetooth: guard against controllers sending zero'd events Sasha Levin
` (9 subsequent siblings)
14 siblings, 0 replies; 22+ messages in thread
From: Sasha Levin @ 2020-04-11 23:14 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Marcel Holtmann, Johan Hedberg, Sasha Levin, linux-bluetooth, netdev
From: Marcel Holtmann <marcel@holtmann.org>
[ Upstream commit debdedf2eb5a2d9777cabff40900772be13cd9f9 ]
When processing SCO packets, the handle is wrongly assumed as 16-bit
value. The actual size is 12-bits and the other 4-bits are used for
packet flags.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
net/bluetooth/hci_core.c | 7 +++++--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/net/bluetooth/hci_core.c b/net/bluetooth/hci_core.c
index 4bce3ef2c392a..119a86a4c24e2 100644
--- a/net/bluetooth/hci_core.c
+++ b/net/bluetooth/hci_core.c
@@ -4324,13 +4324,16 @@ static void hci_scodata_packet(struct hci_dev *hdev, struct sk_buff *skb)
{
struct hci_sco_hdr *hdr = (void *) skb->data;
struct hci_conn *conn;
- __u16 handle;
+ __u16 handle, flags;
skb_pull(skb, HCI_SCO_HDR_SIZE);
handle = __le16_to_cpu(hdr->handle);
+ flags = hci_flags(handle);
+ handle = hci_handle(handle);
- BT_DBG("%s len %d handle 0x%4.4x", hdev->name, skb->len, handle);
+ BT_DBG("%s len %d handle 0x%4.4x flags 0x%4.4x", hdev->name, skb->len,
+ handle, flags);
hdev->stat.sco_rx++;
--
2.20.1
^ permalink raw reply related [flat|nested] 22+ messages in thread* [PATCH AUTOSEL 4.4 07/16] Bluetooth: guard against controllers sending zero'd events
2020-04-11 23:14 [PATCH AUTOSEL 4.4 01/16] net: wan: wanxl: use allow to pass CROSS_COMPILE_M68k for rebuilding firmware Sasha Levin
` (4 preceding siblings ...)
2020-04-11 23:14 ` [PATCH AUTOSEL 4.4 06/16] Bluetooth: Fix calculation of SCO handle for packet processing Sasha Levin
@ 2020-04-11 23:14 ` Sasha Levin
2020-04-11 23:14 ` [Intel-wired-lan] " Sasha Levin
` (8 subsequent siblings)
14 siblings, 0 replies; 22+ messages in thread
From: Sasha Levin @ 2020-04-11 23:14 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Alain Michaud, Marcel Holtmann, Sasha Levin, linux-bluetooth, netdev
From: Alain Michaud <alainm@chromium.org>
[ Upstream commit 08bb4da90150e2a225f35e0f642cdc463958d696 ]
Some controllers have been observed to send zero'd events under some
conditions. This change guards against this condition as well as adding
a trace to facilitate diagnosability of this condition.
Signed-off-by: Alain Michaud <alainm@chromium.org>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
net/bluetooth/hci_event.c | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/net/bluetooth/hci_event.c b/net/bluetooth/hci_event.c
index 37fe2b158c2a7..2dc44fe4136f7 100644
--- a/net/bluetooth/hci_event.c
+++ b/net/bluetooth/hci_event.c
@@ -5222,6 +5222,11 @@ void hci_event_packet(struct hci_dev *hdev, struct sk_buff *skb)
u8 status = 0, event = hdr->evt, req_evt = 0;
u16 opcode = HCI_OP_NOP;
+ if (!event) {
+ bt_dev_warn(hdev, "Received unexpected HCI Event 00000000");
+ goto done;
+ }
+
if (hdev->sent_cmd && bt_cb(hdev->sent_cmd)->hci.req_event == event) {
struct hci_command_hdr *cmd_hdr = (void *) hdev->sent_cmd->data;
opcode = __le16_to_cpu(cmd_hdr->opcode);
@@ -5433,6 +5438,7 @@ void hci_event_packet(struct hci_dev *hdev, struct sk_buff *skb)
req_complete_skb(hdev, status, opcode, orig_skb);
}
+done:
kfree_skb(orig_skb);
kfree_skb(skb);
hdev->stat.evt_rx++;
--
2.20.1
^ permalink raw reply related [flat|nested] 22+ messages in thread* [PATCH AUTOSEL 4.4 08/16] net: intel: e1000e: fix possible sleep-in-atomic-context bugs in e1000e_get_hw_semaphore()
2020-04-11 23:14 [PATCH AUTOSEL 4.4 01/16] net: wan: wanxl: use allow to pass CROSS_COMPILE_M68k for rebuilding firmware Sasha Levin
@ 2020-04-11 23:14 ` Sasha Levin
2020-04-11 23:14 ` [PATCH AUTOSEL 4.4 03/16] RDMA/cm: Add missing locking around id.state in cm_dup_req_handler Sasha Levin
` (13 subsequent siblings)
14 siblings, 0 replies; 22+ messages in thread
From: Sasha Levin @ 2020-04-11 23:14 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Jia-Ju Bai, Aaron Brown, Jeff Kirsher, Sasha Levin,
intel-wired-lan, netdev
From: Jia-Ju Bai <baijiaju1990@gmail.com>
[ Upstream commit 2e05f756c7099c8991142382648a37b0d4c85943 ]
The driver may sleep while holding a spinlock.
The function call path (from bottom to top) in Linux 4.19 is:
drivers/net/ethernet/intel/e1000e/mac.c, 1366:
usleep_range in e1000e_get_hw_semaphore
drivers/net/ethernet/intel/e1000e/80003es2lan.c, 322:
e1000e_get_hw_semaphore in e1000_release_swfw_sync_80003es2lan
drivers/net/ethernet/intel/e1000e/80003es2lan.c, 197:
e1000_release_swfw_sync_80003es2lan in e1000_release_phy_80003es2lan
drivers/net/ethernet/intel/e1000e/netdev.c, 4883:
(FUNC_PTR) e1000_release_phy_80003es2lan in e1000e_update_phy_stats
drivers/net/ethernet/intel/e1000e/netdev.c, 4917:
e1000e_update_phy_stats in e1000e_update_stats
drivers/net/ethernet/intel/e1000e/netdev.c, 5945:
e1000e_update_stats in e1000e_get_stats64
drivers/net/ethernet/intel/e1000e/netdev.c, 5944:
spin_lock in e1000e_get_stats64
drivers/net/ethernet/intel/e1000e/mac.c, 1384:
usleep_range in e1000e_get_hw_semaphore
drivers/net/ethernet/intel/e1000e/80003es2lan.c, 322:
e1000e_get_hw_semaphore in e1000_release_swfw_sync_80003es2lan
drivers/net/ethernet/intel/e1000e/80003es2lan.c, 197:
e1000_release_swfw_sync_80003es2lan in e1000_release_phy_80003es2lan
drivers/net/ethernet/intel/e1000e/netdev.c, 4883:
(FUNC_PTR) e1000_release_phy_80003es2lan in e1000e_update_phy_stats
drivers/net/ethernet/intel/e1000e/netdev.c, 4917:
e1000e_update_phy_stats in e1000e_update_stats
drivers/net/ethernet/intel/e1000e/netdev.c, 5945:
e1000e_update_stats in e1000e_get_stats64
drivers/net/ethernet/intel/e1000e/netdev.c, 5944:
spin_lock in e1000e_get_stats64
(FUNC_PTR) means a function pointer is called.
To fix these bugs, usleep_range() is replaced with udelay().
These bugs are found by a static analysis tool STCheck written by myself.
Signed-off-by: Jia-Ju Bai <baijiaju1990@gmail.com>
Tested-by: Aaron Brown <aaron.f.brown@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/net/ethernet/intel/e1000e/mac.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/intel/e1000e/mac.c b/drivers/net/ethernet/intel/e1000e/mac.c
index fe133f33a6c6a..e0b187dc37385 100644
--- a/drivers/net/ethernet/intel/e1000e/mac.c
+++ b/drivers/net/ethernet/intel/e1000e/mac.c
@@ -1386,7 +1386,7 @@ s32 e1000e_get_hw_semaphore(struct e1000_hw *hw)
if (!(swsm & E1000_SWSM_SMBI))
break;
- usleep_range(50, 100);
+ udelay(100);
i++;
}
@@ -1404,7 +1404,7 @@ s32 e1000e_get_hw_semaphore(struct e1000_hw *hw)
if (er32(SWSM) & E1000_SWSM_SWESMBI)
break;
- usleep_range(50, 100);
+ udelay(100);
}
if (i == timeout) {
--
2.20.1
^ permalink raw reply related [flat|nested] 22+ messages in thread* [Intel-wired-lan] [PATCH AUTOSEL 4.4 08/16] net: intel: e1000e: fix possible sleep-in-atomic-context bugs in e1000e_get_hw_semaphore()
@ 2020-04-11 23:14 ` Sasha Levin
0 siblings, 0 replies; 22+ messages in thread
From: Sasha Levin @ 2020-04-11 23:14 UTC (permalink / raw)
To: intel-wired-lan
From: Jia-Ju Bai <baijiaju1990@gmail.com>
[ Upstream commit 2e05f756c7099c8991142382648a37b0d4c85943 ]
The driver may sleep while holding a spinlock.
The function call path (from bottom to top) in Linux 4.19 is:
drivers/net/ethernet/intel/e1000e/mac.c, 1366:
usleep_range in e1000e_get_hw_semaphore
drivers/net/ethernet/intel/e1000e/80003es2lan.c, 322:
e1000e_get_hw_semaphore in e1000_release_swfw_sync_80003es2lan
drivers/net/ethernet/intel/e1000e/80003es2lan.c, 197:
e1000_release_swfw_sync_80003es2lan in e1000_release_phy_80003es2lan
drivers/net/ethernet/intel/e1000e/netdev.c, 4883:
(FUNC_PTR) e1000_release_phy_80003es2lan in e1000e_update_phy_stats
drivers/net/ethernet/intel/e1000e/netdev.c, 4917:
e1000e_update_phy_stats in e1000e_update_stats
drivers/net/ethernet/intel/e1000e/netdev.c, 5945:
e1000e_update_stats in e1000e_get_stats64
drivers/net/ethernet/intel/e1000e/netdev.c, 5944:
spin_lock in e1000e_get_stats64
drivers/net/ethernet/intel/e1000e/mac.c, 1384:
usleep_range in e1000e_get_hw_semaphore
drivers/net/ethernet/intel/e1000e/80003es2lan.c, 322:
e1000e_get_hw_semaphore in e1000_release_swfw_sync_80003es2lan
drivers/net/ethernet/intel/e1000e/80003es2lan.c, 197:
e1000_release_swfw_sync_80003es2lan in e1000_release_phy_80003es2lan
drivers/net/ethernet/intel/e1000e/netdev.c, 4883:
(FUNC_PTR) e1000_release_phy_80003es2lan in e1000e_update_phy_stats
drivers/net/ethernet/intel/e1000e/netdev.c, 4917:
e1000e_update_phy_stats in e1000e_update_stats
drivers/net/ethernet/intel/e1000e/netdev.c, 5945:
e1000e_update_stats in e1000e_get_stats64
drivers/net/ethernet/intel/e1000e/netdev.c, 5944:
spin_lock in e1000e_get_stats64
(FUNC_PTR) means a function pointer is called.
To fix these bugs, usleep_range() is replaced with udelay().
These bugs are found by a static analysis tool STCheck written by myself.
Signed-off-by: Jia-Ju Bai <baijiaju1990@gmail.com>
Tested-by: Aaron Brown <aaron.f.brown@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/net/ethernet/intel/e1000e/mac.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/intel/e1000e/mac.c b/drivers/net/ethernet/intel/e1000e/mac.c
index fe133f33a6c6a..e0b187dc37385 100644
--- a/drivers/net/ethernet/intel/e1000e/mac.c
+++ b/drivers/net/ethernet/intel/e1000e/mac.c
@@ -1386,7 +1386,7 @@ s32 e1000e_get_hw_semaphore(struct e1000_hw *hw)
if (!(swsm & E1000_SWSM_SMBI))
break;
- usleep_range(50, 100);
+ udelay(100);
i++;
}
@@ -1404,7 +1404,7 @@ s32 e1000e_get_hw_semaphore(struct e1000_hw *hw)
if (er32(SWSM) & E1000_SWSM_SWESMBI)
break;
- usleep_range(50, 100);
+ udelay(100);
}
if (i == timeout) {
--
2.20.1
^ permalink raw reply related [flat|nested] 22+ messages in thread
* [PATCH AUTOSEL 4.4 09/16] drm/omap: fix possible object reference leak
2020-04-11 23:14 [PATCH AUTOSEL 4.4 01/16] net: wan: wanxl: use allow to pass CROSS_COMPILE_M68k for rebuilding firmware Sasha Levin
2020-04-11 23:14 ` [PATCH AUTOSEL 4.4 02/16] serial: 8250_omap: Fix sleeping function called from invalid context during probe Sasha Levin
@ 2020-04-11 23:14 ` Sasha Levin
2020-04-11 23:14 ` [PATCH AUTOSEL 4.4 04/16] mwifiex: set needed_headroom, not hard_header_len Sasha Levin
` (12 subsequent siblings)
14 siblings, 0 replies; 22+ messages in thread
From: Sasha Levin @ 2020-04-11 23:14 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Wen Yang, Laurent Pinchart, Mukesh Ojha, Tomi Valkeinen,
David Airlie, Daniel Vetter, Sebastian Reichel, dri-devel,
Markus Elfring, Sasha Levin, linux-omap, linux-fbdev
From: Wen Yang <wen.yang99@zte.com.cn>
[ Upstream commit 47340e46f34a3b1d80e40b43ae3d7a8da34a3541 ]
The call to of_find_matching_node returns a node pointer with refcount
incremented thus it must be explicitly decremented after the last
usage.
Detected by coccinelle with the following warnings:
drivers/gpu/drm/omapdrm/dss/omapdss-boot-init.c:212:2-8: ERROR: missing of_node_put; acquired a node pointer with refcount incremented on line 209, but without a corresponding object release within this function.
drivers/gpu/drm/omapdrm/dss/omapdss-boot-init.c:237:1-7: ERROR: missing of_node_put; acquired a node pointer with refcount incremented on line 209, but without a corresponding object release within this function.
Signed-off-by: Wen Yang <wen.yang99@zte.com.cn>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Mukesh Ojha <mojha@codeaurora.org>
Cc: Tomi Valkeinen <tomi.valkeinen@ti.com>
Cc: David Airlie <airlied@linux.ie>
Cc: Daniel Vetter <daniel@ffwll.ch>
Cc: Sebastian Reichel <sebastian.reichel@collabora.com>
Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Cc: dri-devel@lists.freedesktop.org
Cc: linux-kernel@vger.kernel.org
Cc: Markus Elfring <Markus.Elfring@web.de>
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Link: https://patchwork.freedesktop.org/patch/msgid/1554692313-28882-2-git-send-email-wen.yang99@zte.com.cn
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/video/fbdev/omap2/dss/omapdss-boot-init.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/video/fbdev/omap2/dss/omapdss-boot-init.c b/drivers/video/fbdev/omap2/dss/omapdss-boot-init.c
index 8b6f6d5fdd68b..43186fa8a13c9 100644
--- a/drivers/video/fbdev/omap2/dss/omapdss-boot-init.c
+++ b/drivers/video/fbdev/omap2/dss/omapdss-boot-init.c
@@ -194,7 +194,7 @@ static int __init omapdss_boot_init(void)
dss = of_find_matching_node(NULL, omapdss_of_match);
if (dss == NULL || !of_device_is_available(dss))
- return 0;
+ goto put_node;
omapdss_walk_device(dss, true);
@@ -221,6 +221,8 @@ static int __init omapdss_boot_init(void)
kfree(n);
}
+put_node:
+ of_node_put(dss);
return 0;
}
--
2.20.1
^ permalink raw reply related [flat|nested] 22+ messages in thread* [PATCH AUTOSEL 4.4 09/16] drm/omap: fix possible object reference leak
@ 2020-04-11 23:14 ` Sasha Levin
0 siblings, 0 replies; 22+ messages in thread
From: Sasha Levin @ 2020-04-11 23:14 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Sasha Levin, linux-fbdev, David Airlie, Mukesh Ojha,
Sebastian Reichel, dri-devel, Tomi Valkeinen, Markus Elfring,
Laurent Pinchart, linux-omap, Wen Yang
From: Wen Yang <wen.yang99@zte.com.cn>
[ Upstream commit 47340e46f34a3b1d80e40b43ae3d7a8da34a3541 ]
The call to of_find_matching_node returns a node pointer with refcount
incremented thus it must be explicitly decremented after the last
usage.
Detected by coccinelle with the following warnings:
drivers/gpu/drm/omapdrm/dss/omapdss-boot-init.c:212:2-8: ERROR: missing of_node_put; acquired a node pointer with refcount incremented on line 209, but without a corresponding object release within this function.
drivers/gpu/drm/omapdrm/dss/omapdss-boot-init.c:237:1-7: ERROR: missing of_node_put; acquired a node pointer with refcount incremented on line 209, but without a corresponding object release within this function.
Signed-off-by: Wen Yang <wen.yang99@zte.com.cn>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Mukesh Ojha <mojha@codeaurora.org>
Cc: Tomi Valkeinen <tomi.valkeinen@ti.com>
Cc: David Airlie <airlied@linux.ie>
Cc: Daniel Vetter <daniel@ffwll.ch>
Cc: Sebastian Reichel <sebastian.reichel@collabora.com>
Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Cc: dri-devel@lists.freedesktop.org
Cc: linux-kernel@vger.kernel.org
Cc: Markus Elfring <Markus.Elfring@web.de>
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Link: https://patchwork.freedesktop.org/patch/msgid/1554692313-28882-2-git-send-email-wen.yang99@zte.com.cn
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/video/fbdev/omap2/dss/omapdss-boot-init.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/video/fbdev/omap2/dss/omapdss-boot-init.c b/drivers/video/fbdev/omap2/dss/omapdss-boot-init.c
index 8b6f6d5fdd68b..43186fa8a13c9 100644
--- a/drivers/video/fbdev/omap2/dss/omapdss-boot-init.c
+++ b/drivers/video/fbdev/omap2/dss/omapdss-boot-init.c
@@ -194,7 +194,7 @@ static int __init omapdss_boot_init(void)
dss = of_find_matching_node(NULL, omapdss_of_match);
if (dss == NULL || !of_device_is_available(dss))
- return 0;
+ goto put_node;
omapdss_walk_device(dss, true);
@@ -221,6 +221,8 @@ static int __init omapdss_boot_init(void)
kfree(n);
}
+put_node:
+ of_node_put(dss);
return 0;
}
--
2.20.1
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply related [flat|nested] 22+ messages in thread
* [PATCH AUTOSEL 4.4 09/16] drm/omap: fix possible object reference leak
@ 2020-04-11 23:14 ` Sasha Levin
0 siblings, 0 replies; 22+ messages in thread
From: Sasha Levin @ 2020-04-11 23:14 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Sasha Levin, linux-fbdev, David Airlie, Mukesh Ojha,
Sebastian Reichel, dri-devel, Tomi Valkeinen, Markus Elfring,
Laurent Pinchart, linux-omap, Wen Yang
From: Wen Yang <wen.yang99@zte.com.cn>
[ Upstream commit 47340e46f34a3b1d80e40b43ae3d7a8da34a3541 ]
The call to of_find_matching_node returns a node pointer with refcount
incremented thus it must be explicitly decremented after the last
usage.
Detected by coccinelle with the following warnings:
drivers/gpu/drm/omapdrm/dss/omapdss-boot-init.c:212:2-8: ERROR: missing of_node_put; acquired a node pointer with refcount incremented on line 209, but without a corresponding object release within this function.
drivers/gpu/drm/omapdrm/dss/omapdss-boot-init.c:237:1-7: ERROR: missing of_node_put; acquired a node pointer with refcount incremented on line 209, but without a corresponding object release within this function.
Signed-off-by: Wen Yang <wen.yang99@zte.com.cn>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Mukesh Ojha <mojha@codeaurora.org>
Cc: Tomi Valkeinen <tomi.valkeinen@ti.com>
Cc: David Airlie <airlied@linux.ie>
Cc: Daniel Vetter <daniel@ffwll.ch>
Cc: Sebastian Reichel <sebastian.reichel@collabora.com>
Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Cc: dri-devel@lists.freedesktop.org
Cc: linux-kernel@vger.kernel.org
Cc: Markus Elfring <Markus.Elfring@web.de>
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Link: https://patchwork.freedesktop.org/patch/msgid/1554692313-28882-2-git-send-email-wen.yang99@zte.com.cn
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/video/fbdev/omap2/dss/omapdss-boot-init.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/video/fbdev/omap2/dss/omapdss-boot-init.c b/drivers/video/fbdev/omap2/dss/omapdss-boot-init.c
index 8b6f6d5fdd68b..43186fa8a13c9 100644
--- a/drivers/video/fbdev/omap2/dss/omapdss-boot-init.c
+++ b/drivers/video/fbdev/omap2/dss/omapdss-boot-init.c
@@ -194,7 +194,7 @@ static int __init omapdss_boot_init(void)
dss = of_find_matching_node(NULL, omapdss_of_match);
if (dss = NULL || !of_device_is_available(dss))
- return 0;
+ goto put_node;
omapdss_walk_device(dss, true);
@@ -221,6 +221,8 @@ static int __init omapdss_boot_init(void)
kfree(n);
}
+put_node:
+ of_node_put(dss);
return 0;
}
--
2.20.1
^ permalink raw reply related [flat|nested] 22+ messages in thread
* [PATCH AUTOSEL 4.4 10/16] audit: CONFIG_CHANGE don't log internal bookkeeping as an event
2020-04-11 23:14 [PATCH AUTOSEL 4.4 01/16] net: wan: wanxl: use allow to pass CROSS_COMPILE_M68k for rebuilding firmware Sasha Levin
@ 2020-04-11 23:14 ` Sasha Levin
2020-04-11 23:14 ` [PATCH AUTOSEL 4.4 03/16] RDMA/cm: Add missing locking around id.state in cm_dup_req_handler Sasha Levin
` (13 subsequent siblings)
14 siblings, 0 replies; 22+ messages in thread
From: Sasha Levin @ 2020-04-11 23:14 UTC (permalink / raw)
To: linux-kernel, stable; +Cc: Steve Grubb, Paul Moore, Sasha Levin, linux-audit
From: Steve Grubb <sgrubb@redhat.com>
[ Upstream commit 70b3eeed49e8190d97139806f6fbaf8964306cdb ]
Common Criteria calls out for any action that modifies the audit trail to
be recorded. That usually is interpreted to mean insertion or removal of
rules. It is not required to log modification of the inode information
since the watch is still in effect. Additionally, if the rule is a never
rule and the underlying file is one they do not want events for, they
get an event for this bookkeeping update against their wishes.
Since no device/inode info is logged at insertion and no device/inode
information is logged on update, there is nothing meaningful being
communicated to the admin by the CONFIG_CHANGE updated_rules event. One
can assume that the rule was not "modified" because it is still watching
the intended target. If the device or inode cannot be resolved, then
audit_panic is called which is sufficient.
The correct resolution is to drop logging config_update events since
the watch is still in effect but just on another unknown inode.
Signed-off-by: Steve Grubb <sgrubb@redhat.com>
Signed-off-by: Paul Moore <paul@paul-moore.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
kernel/audit_watch.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/kernel/audit_watch.c b/kernel/audit_watch.c
index f45a9a5d3e47a..af453f3c2b3dd 100644
--- a/kernel/audit_watch.c
+++ b/kernel/audit_watch.c
@@ -316,8 +316,6 @@ static void audit_update_watch(struct audit_parent *parent,
if (oentry->rule.exe)
audit_remove_mark(oentry->rule.exe);
- audit_watch_log_rule_change(r, owatch, "updated_rules");
-
call_rcu(&oentry->rcu, audit_free_rule_rcu);
}
--
2.20.1
^ permalink raw reply related [flat|nested] 22+ messages in thread* [PATCH AUTOSEL 4.4 10/16] audit: CONFIG_CHANGE don't log internal bookkeeping as an event
@ 2020-04-11 23:14 ` Sasha Levin
0 siblings, 0 replies; 22+ messages in thread
From: Sasha Levin @ 2020-04-11 23:14 UTC (permalink / raw)
To: linux-kernel, stable; +Cc: Sasha Levin, linux-audit
From: Steve Grubb <sgrubb@redhat.com>
[ Upstream commit 70b3eeed49e8190d97139806f6fbaf8964306cdb ]
Common Criteria calls out for any action that modifies the audit trail to
be recorded. That usually is interpreted to mean insertion or removal of
rules. It is not required to log modification of the inode information
since the watch is still in effect. Additionally, if the rule is a never
rule and the underlying file is one they do not want events for, they
get an event for this bookkeeping update against their wishes.
Since no device/inode info is logged at insertion and no device/inode
information is logged on update, there is nothing meaningful being
communicated to the admin by the CONFIG_CHANGE updated_rules event. One
can assume that the rule was not "modified" because it is still watching
the intended target. If the device or inode cannot be resolved, then
audit_panic is called which is sufficient.
The correct resolution is to drop logging config_update events since
the watch is still in effect but just on another unknown inode.
Signed-off-by: Steve Grubb <sgrubb@redhat.com>
Signed-off-by: Paul Moore <paul@paul-moore.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
kernel/audit_watch.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/kernel/audit_watch.c b/kernel/audit_watch.c
index f45a9a5d3e47a..af453f3c2b3dd 100644
--- a/kernel/audit_watch.c
+++ b/kernel/audit_watch.c
@@ -316,8 +316,6 @@ static void audit_update_watch(struct audit_parent *parent,
if (oentry->rule.exe)
audit_remove_mark(oentry->rule.exe);
- audit_watch_log_rule_change(r, owatch, "updated_rules");
-
call_rcu(&oentry->rcu, audit_free_rule_rcu);
}
--
2.20.1
--
Linux-audit mailing list
Linux-audit@redhat.com
https://www.redhat.com/mailman/listinfo/linux-audit
^ permalink raw reply related [flat|nested] 22+ messages in thread
* [PATCH AUTOSEL 4.4 11/16] Bluetooth: btusb: Add support for 13d3:3548 Realtek 8822CE device
2020-04-11 23:14 [PATCH AUTOSEL 4.4 01/16] net: wan: wanxl: use allow to pass CROSS_COMPILE_M68k for rebuilding firmware Sasha Levin
` (8 preceding siblings ...)
2020-04-11 23:14 ` Sasha Levin
@ 2020-04-11 23:14 ` Sasha Levin
2020-04-11 23:14 ` [PATCH AUTOSEL 4.4 12/16] scsi: lpfc: Fix RQ buffer leakage when no IOCBs available Sasha Levin
` (4 subsequent siblings)
14 siblings, 0 replies; 22+ messages in thread
From: Sasha Levin @ 2020-04-11 23:14 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Sergey Shatunov, Marcel Holtmann, Sasha Levin, linux-bluetooth
From: Sergey Shatunov <me@prok.pw>
[ Upstream commit eb3939e386ec8df6049697d388298590231ac79c ]
The ASUS FX505DV laptop contains RTL8822CE device with an
associated BT chip using a USB ID of 13d3:3548.
This patch add fw download support for it.
T: Bus=03 Lev=01 Prnt=01 Port=03 Cnt=03 Dev#= 4 Spd=12 MxCh= 0
D: Ver= 1.00 Cls=e0(wlcon) Sub=01 Prot=01 MxPS=64 #Cfgs= 1
P: Vendor=13d3 ProdID=3548 Rev= 0.00
S: Manufacturer=Realtek
S: Product=Bluetooth Radio
S: SerialNumber=00e04c000001
C:* #Ifs= 2 Cfg#= 1 Atr=a0 MxPwr=500mA
I:* If#= 0 Alt= 0 #EPs= 3 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E: Ad=81(I) Atr=03(Int.) MxPS= 16 Ivl=1ms
E: Ad=02(O) Atr=02(Bulk) MxPS= 64 Ivl=0ms
E: Ad=82(I) Atr=02(Bulk) MxPS= 64 Ivl=0ms
I:* If#= 1 Alt= 0 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E: Ad=03(O) Atr=01(Isoc) MxPS= 0 Ivl=1ms
E: Ad=83(I) Atr=01(Isoc) MxPS= 0 Ivl=1ms
I: If#= 1 Alt= 1 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E: Ad=03(O) Atr=01(Isoc) MxPS= 9 Ivl=1ms
E: Ad=83(I) Atr=01(Isoc) MxPS= 9 Ivl=1ms
I: If#= 1 Alt= 2 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E: Ad=03(O) Atr=01(Isoc) MxPS= 17 Ivl=1ms
E: Ad=83(I) Atr=01(Isoc) MxPS= 17 Ivl=1ms
I: If#= 1 Alt= 3 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E: Ad=03(O) Atr=01(Isoc) MxPS= 25 Ivl=1ms
E: Ad=83(I) Atr=01(Isoc) MxPS= 25 Ivl=1ms
I: If#= 1 Alt= 4 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E: Ad=03(O) Atr=01(Isoc) MxPS= 33 Ivl=1ms
E: Ad=83(I) Atr=01(Isoc) MxPS= 33 Ivl=1ms
I: If#= 1 Alt= 5 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E: Ad=03(O) Atr=01(Isoc) MxPS= 49 Ivl=1ms
E: Ad=83(I) Atr=01(Isoc) MxPS= 49 Ivl=1ms
Signed-off-by: Sergey Shatunov <me@prok.pw>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/bluetooth/btusb.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/bluetooth/btusb.c b/drivers/bluetooth/btusb.c
index 7039a58a6a4ec..cc133863c7fce 100644
--- a/drivers/bluetooth/btusb.c
+++ b/drivers/bluetooth/btusb.c
@@ -355,6 +355,7 @@ static const struct usb_device_id blacklist_table[] = {
/* Additional Realtek 8822CE Bluetooth devices */
{ USB_DEVICE(0x04ca, 0x4005), .driver_info = BTUSB_REALTEK },
+ { USB_DEVICE(0x13d3, 0x3548), .driver_info = BTUSB_REALTEK },
/* Silicon Wave based devices */
{ USB_DEVICE(0x0c10, 0x0000), .driver_info = BTUSB_SWAVE },
--
2.20.1
^ permalink raw reply related [flat|nested] 22+ messages in thread* [PATCH AUTOSEL 4.4 12/16] scsi: lpfc: Fix RQ buffer leakage when no IOCBs available
2020-04-11 23:14 [PATCH AUTOSEL 4.4 01/16] net: wan: wanxl: use allow to pass CROSS_COMPILE_M68k for rebuilding firmware Sasha Levin
` (9 preceding siblings ...)
2020-04-11 23:14 ` [PATCH AUTOSEL 4.4 11/16] Bluetooth: btusb: Add support for 13d3:3548 Realtek 8822CE device Sasha Levin
@ 2020-04-11 23:14 ` Sasha Levin
2020-04-11 23:14 ` [PATCH AUTOSEL 4.4 13/16] Bluetooth: RFCOMM: fix ODEBUG bug in rfcomm_dev_ioctl Sasha Levin
` (3 subsequent siblings)
14 siblings, 0 replies; 22+ messages in thread
From: Sasha Levin @ 2020-04-11 23:14 UTC (permalink / raw)
To: linux-kernel, stable
Cc: James Smart, Dick Kennedy, Martin K . Petersen, Sasha Levin, linux-scsi
From: James Smart <jsmart2021@gmail.com>
[ Upstream commit 39c4f1a965a9244c3ba60695e8ff8da065ec6ac4 ]
The driver is occasionally seeing the following SLI Port error, requiring
reset and reinit:
Port Status Event: ... error 1=0x52004a01, error 2=0x218
The failure means an RQ timeout. That is, the adapter had received
asynchronous receive frames, ran out of buffer slots to place the frames,
and the driver did not replenish the buffer slots before a timeout
occurred. The driver should not be so slow in replenishing buffers that a
timeout can occur.
When the driver received all the frames of a sequence, it allocates an IOCB
to put the frames in. In a situation where there was no IOCB available for
the frame of a sequence, the RQ buffer corresponding to the first frame of
the sequence was not returned to the FW. Eventually, with enough traffic
encountering the situation, the timeout occurred.
Fix by releasing the buffer back to firmware whenever there is no IOCB for
the first frame.
[mkp: typo]
Link: https://lore.kernel.org/r/20200128002312.16346-2-jsmart2021@gmail.com
Signed-off-by: Dick Kennedy <dick.kennedy@broadcom.com>
Signed-off-by: James Smart <jsmart2021@gmail.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/scsi/lpfc/lpfc_sli.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/drivers/scsi/lpfc/lpfc_sli.c b/drivers/scsi/lpfc/lpfc_sli.c
index 065fdc17bbfbb..0b2c6e0f0de59 100644
--- a/drivers/scsi/lpfc/lpfc_sli.c
+++ b/drivers/scsi/lpfc/lpfc_sli.c
@@ -15443,6 +15443,10 @@ lpfc_prep_seq(struct lpfc_vport *vport, struct hbq_dmabuf *seq_dmabuf)
list_add_tail(&iocbq->list, &first_iocbq->list);
}
}
+ /* Free the sequence's header buffer */
+ if (!first_iocbq)
+ lpfc_in_buf_free(vport->phba, &seq_dmabuf->dbuf);
+
return first_iocbq;
}
--
2.20.1
^ permalink raw reply related [flat|nested] 22+ messages in thread* [PATCH AUTOSEL 4.4 13/16] Bluetooth: RFCOMM: fix ODEBUG bug in rfcomm_dev_ioctl
2020-04-11 23:14 [PATCH AUTOSEL 4.4 01/16] net: wan: wanxl: use allow to pass CROSS_COMPILE_M68k for rebuilding firmware Sasha Levin
` (10 preceding siblings ...)
2020-04-11 23:14 ` [PATCH AUTOSEL 4.4 12/16] scsi: lpfc: Fix RQ buffer leakage when no IOCBs available Sasha Levin
@ 2020-04-11 23:14 ` Sasha Levin
2020-04-11 23:14 ` [PATCH AUTOSEL 4.4 14/16] brcmfmac: Fix driver crash on USB control transfer timeout Sasha Levin
` (2 subsequent siblings)
14 siblings, 0 replies; 22+ messages in thread
From: Sasha Levin @ 2020-04-11 23:14 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Qiujun Huang, syzbot+4496e82090657320efc6, Hillf Danton,
Marcel Holtmann, Sasha Levin, linux-bluetooth, netdev
From: Qiujun Huang <hqjagain@gmail.com>
[ Upstream commit 71811cac8532b2387b3414f7cd8fe9e497482864 ]
Needn't call 'rfcomm_dlc_put' here, because 'rfcomm_dlc_exists' didn't
increase dlc->refcnt.
Reported-by: syzbot+4496e82090657320efc6@syzkaller.appspotmail.com
Signed-off-by: Qiujun Huang <hqjagain@gmail.com>
Suggested-by: Hillf Danton <hdanton@sina.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
net/bluetooth/rfcomm/tty.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/net/bluetooth/rfcomm/tty.c b/net/bluetooth/rfcomm/tty.c
index 8e385a0ae60e0..939fbf7b352d4 100644
--- a/net/bluetooth/rfcomm/tty.c
+++ b/net/bluetooth/rfcomm/tty.c
@@ -413,10 +413,8 @@ static int __rfcomm_create_dev(struct sock *sk, void __user *arg)
dlc = rfcomm_dlc_exists(&req.src, &req.dst, req.channel);
if (IS_ERR(dlc))
return PTR_ERR(dlc);
- else if (dlc) {
- rfcomm_dlc_put(dlc);
+ if (dlc)
return -EBUSY;
- }
dlc = rfcomm_dlc_alloc(GFP_KERNEL);
if (!dlc)
return -ENOMEM;
--
2.20.1
^ permalink raw reply related [flat|nested] 22+ messages in thread* [PATCH AUTOSEL 4.4 14/16] brcmfmac: Fix driver crash on USB control transfer timeout
2020-04-11 23:14 [PATCH AUTOSEL 4.4 01/16] net: wan: wanxl: use allow to pass CROSS_COMPILE_M68k for rebuilding firmware Sasha Levin
` (11 preceding siblings ...)
2020-04-11 23:14 ` [PATCH AUTOSEL 4.4 13/16] Bluetooth: RFCOMM: fix ODEBUG bug in rfcomm_dev_ioctl Sasha Levin
@ 2020-04-11 23:14 ` Sasha Levin
2020-04-11 23:14 ` [PATCH AUTOSEL 4.4 15/16] RDMA/cm: Update num_paths in cma_resolve_iboe_route error flow Sasha Levin
2020-04-11 23:14 ` Sasha Levin
14 siblings, 0 replies; 22+ messages in thread
From: Sasha Levin @ 2020-04-11 23:14 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Raveendran Somu, Chi-hsien Lin, Kalle Valo, Sasha Levin,
linux-wireless, netdev
From: Raveendran Somu <raveendran.somu@cypress.com>
[ Upstream commit 93a5bfbc7cad8bf3dea81c9bc07761c1226a0860 ]
When the control transfer gets timed out, the error status
was returned without killing that urb, this leads to using
the same urb. This issue causes the kernel crash as the same
urb is sumbitted multiple times. The fix is to kill the
urb for timeout transfer before returning error
Signed-off-by: Raveendran Somu <raveendran.somu@cypress.com>
Signed-off-by: Chi-hsien Lin <chi-hsien.lin@cypress.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/1585124429-97371-2-git-send-email-chi-hsien.lin@cypress.com
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/net/wireless/brcm80211/brcmfmac/usb.c | 6 ++++--
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/net/wireless/brcm80211/brcmfmac/usb.c b/drivers/net/wireless/brcm80211/brcmfmac/usb.c
index 2cb3f12dccbd8..a4eb1ef18143f 100644
--- a/drivers/net/wireless/brcm80211/brcmfmac/usb.c
+++ b/drivers/net/wireless/brcm80211/brcmfmac/usb.c
@@ -324,11 +324,12 @@ static int brcmf_usb_tx_ctlpkt(struct device *dev, u8 *buf, u32 len)
return err;
}
timeout = brcmf_usb_ioctl_resp_wait(devinfo);
- clear_bit(0, &devinfo->ctl_op);
if (!timeout) {
brcmf_err("Txctl wait timed out\n");
+ usb_kill_urb(devinfo->ctl_urb);
err = -EIO;
}
+ clear_bit(0, &devinfo->ctl_op);
return err;
}
@@ -354,11 +355,12 @@ static int brcmf_usb_rx_ctlpkt(struct device *dev, u8 *buf, u32 len)
}
timeout = brcmf_usb_ioctl_resp_wait(devinfo);
err = devinfo->ctl_urb_status;
- clear_bit(0, &devinfo->ctl_op);
if (!timeout) {
brcmf_err("rxctl wait timed out\n");
+ usb_kill_urb(devinfo->ctl_urb);
err = -EIO;
}
+ clear_bit(0, &devinfo->ctl_op);
if (!err)
return devinfo->ctl_urb_actual_length;
else
--
2.20.1
^ permalink raw reply related [flat|nested] 22+ messages in thread* [PATCH AUTOSEL 4.4 15/16] RDMA/cm: Update num_paths in cma_resolve_iboe_route error flow
2020-04-11 23:14 [PATCH AUTOSEL 4.4 01/16] net: wan: wanxl: use allow to pass CROSS_COMPILE_M68k for rebuilding firmware Sasha Levin
` (12 preceding siblings ...)
2020-04-11 23:14 ` [PATCH AUTOSEL 4.4 14/16] brcmfmac: Fix driver crash on USB control transfer timeout Sasha Levin
@ 2020-04-11 23:14 ` Sasha Levin
2020-04-11 23:14 ` Sasha Levin
14 siblings, 0 replies; 22+ messages in thread
From: Sasha Levin @ 2020-04-11 23:14 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Avihai Horon, Maor Gottlieb, Leon Romanovsky, Jason Gunthorpe,
Sasha Levin, linux-rdma
From: Avihai Horon <avihaih@mellanox.com>
[ Upstream commit 987914ab841e2ec281a35b54348ab109b4c0bb4e ]
After a successful allocation of path_rec, num_paths is set to 1, but any
error after such allocation will leave num_paths uncleared.
This causes to de-referencing a NULL pointer later on. Hence, num_paths
needs to be set back to 0 if such an error occurs.
The following crash from syzkaller revealed it.
kasan: CONFIG_KASAN_INLINE enabled
kasan: GPF could be caused by NULL-ptr deref or user memory access
general protection fault: 0000 [#1] SMP DEBUG_PAGEALLOC KASAN PTI
CPU: 0 PID: 357 Comm: syz-executor060 Not tainted 4.18.0+ #311
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS
rel-1.11.0-0-g63451fca13-prebuilt.qemu-project.org 04/01/2014
RIP: 0010:ib_copy_path_rec_to_user+0x94/0x3e0
Code: f1 f1 f1 f1 c7 40 0c 00 00 f4 f4 65 48 8b 04 25 28 00 00 00 48 89
45 c8 31 c0 e8 d7 60 24 ff 48 8d 7b 4c 48 89 f8 48 c1 e8 03 <42> 0f b6
14 30 48 89 f8 83 e0 07 83 c0 03 38 d0 7c 08 84 d2 0f 85
RSP: 0018:ffff88006586f980 EFLAGS: 00010207
RAX: 0000000000000009 RBX: 0000000000000000 RCX: 1ffff1000d5fe475
RDX: ffff8800621e17c0 RSI: ffffffff820d45f9 RDI: 000000000000004c
RBP: ffff88006586fa50 R08: ffffed000cb0df73 R09: ffffed000cb0df72
R10: ffff88006586fa70 R11: ffffed000cb0df73 R12: 1ffff1000cb0df30
R13: ffff88006586fae8 R14: dffffc0000000000 R15: ffff88006aff2200
FS: 00000000016fc880(0000) GS:ffff88006d000000(0000)
knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000000020000040 CR3: 0000000063fec000 CR4: 00000000000006b0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
Call Trace:
? ib_copy_path_rec_from_user+0xcc0/0xcc0
? __mutex_unlock_slowpath+0xfc/0x670
? wait_for_completion+0x3b0/0x3b0
? ucma_query_route+0x818/0xc60
ucma_query_route+0x818/0xc60
? ucma_listen+0x1b0/0x1b0
? sched_clock_cpu+0x18/0x1d0
? sched_clock_cpu+0x18/0x1d0
? ucma_listen+0x1b0/0x1b0
? ucma_write+0x292/0x460
ucma_write+0x292/0x460
? ucma_close_id+0x60/0x60
? sched_clock_cpu+0x18/0x1d0
? sched_clock_cpu+0x18/0x1d0
__vfs_write+0xf7/0x620
? ucma_close_id+0x60/0x60
? kernel_read+0x110/0x110
? time_hardirqs_on+0x19/0x580
? lock_acquire+0x18b/0x3a0
? finish_task_switch+0xf3/0x5d0
? _raw_spin_unlock_irq+0x29/0x40
? _raw_spin_unlock_irq+0x29/0x40
? finish_task_switch+0x1be/0x5d0
? __switch_to_asm+0x34/0x70
? __switch_to_asm+0x40/0x70
? security_file_permission+0x172/0x1e0
vfs_write+0x192/0x460
ksys_write+0xc6/0x1a0
? __ia32_sys_read+0xb0/0xb0
? entry_SYSCALL_64_after_hwframe+0x3e/0xbe
? do_syscall_64+0x1d/0x470
do_syscall_64+0x9e/0x470
entry_SYSCALL_64_after_hwframe+0x49/0xbe
Fixes: 3c86aa70bf67 ("RDMA/cm: Add RDMA CM support for IBoE devices")
Link: https://lore.kernel.org/r/20200318101741.47211-1-leon@kernel.org
Signed-off-by: Avihai Horon <avihaih@mellanox.com>
Reviewed-by: Maor Gottlieb <maorg@mellanox.com>
Signed-off-by: Leon Romanovsky <leonro@mellanox.com>
Signed-off-by: Jason Gunthorpe <jgg@mellanox.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/infiniband/core/cma.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/infiniband/core/cma.c b/drivers/infiniband/core/cma.c
index 5ed9b5f8a0377..b59a4a819aaaa 100644
--- a/drivers/infiniband/core/cma.c
+++ b/drivers/infiniband/core/cma.c
@@ -2378,6 +2378,7 @@ static int cma_resolve_iboe_route(struct rdma_id_private *id_priv)
err2:
kfree(route->path_rec);
route->path_rec = NULL;
+ route->num_paths = 0;
err1:
kfree(work);
return ret;
--
2.20.1
^ permalink raw reply related [flat|nested] 22+ messages in thread* [PATCH AUTOSEL 4.4 16/16] scsi: ufs: Fix ufshcd_hold() caused scheduling while atomic
2020-04-11 23:14 [PATCH AUTOSEL 4.4 01/16] net: wan: wanxl: use allow to pass CROSS_COMPILE_M68k for rebuilding firmware Sasha Levin
2020-04-11 23:14 ` [PATCH AUTOSEL 4.4 02/16] serial: 8250_omap: Fix sleeping function called from invalid context during probe Sasha Levin
@ 2020-04-11 23:14 ` Sasha Levin
2020-04-11 23:14 ` [PATCH AUTOSEL 4.4 04/16] mwifiex: set needed_headroom, not hard_header_len Sasha Levin
` (12 subsequent siblings)
14 siblings, 0 replies; 22+ messages in thread
From: Sasha Levin @ 2020-04-11 23:14 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Can Guo, Hongwu Su, Asutosh Das, Bean Huo, Stanley Chu,
Martin K . Petersen, Sasha Levin, linux-scsi, linux-arm-kernel,
linux-mediatek
From: Can Guo <cang@codeaurora.org>
[ Upstream commit c63d6099a7959ecc919b2549dc6b71f53521f819 ]
The async version of ufshcd_hold(async == true), which is only called in
queuecommand path as for now, is expected to work in atomic context, thus
it should not sleep or schedule out. When it runs into the condition that
clocks are ON but link is still in hibern8 state, it should bail out
without flushing the clock ungate work.
Fixes: f2a785ac2312 ("scsi: ufshcd: Fix race between clk scaling and ungate work")
Link: https://lore.kernel.org/r/1581392451-28743-6-git-send-email-cang@codeaurora.org
Reviewed-by: Hongwu Su <hongwus@codeaurora.org>
Reviewed-by: Asutosh Das <asutoshd@codeaurora.org>
Reviewed-by: Bean Huo <beanhuo@micron.com>
Reviewed-by: Stanley Chu <stanley.chu@mediatek.com>
Signed-off-by: Can Guo <cang@codeaurora.org>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/scsi/ufs/ufshcd.c | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/drivers/scsi/ufs/ufshcd.c b/drivers/scsi/ufs/ufshcd.c
index 19f82069c68ac..bc7f8d634c805 100644
--- a/drivers/scsi/ufs/ufshcd.c
+++ b/drivers/scsi/ufs/ufshcd.c
@@ -595,6 +595,11 @@ int ufshcd_hold(struct ufs_hba *hba, bool async)
*/
if (ufshcd_can_hibern8_during_gating(hba) &&
ufshcd_is_link_hibern8(hba)) {
+ if (async) {
+ rc = -EAGAIN;
+ hba->clk_gating.active_reqs--;
+ break;
+ }
spin_unlock_irqrestore(hba->host->host_lock, flags);
flush_work(&hba->clk_gating.ungate_work);
spin_lock_irqsave(hba->host->host_lock, flags);
--
2.20.1
^ permalink raw reply related [flat|nested] 22+ messages in thread* [PATCH AUTOSEL 4.4 16/16] scsi: ufs: Fix ufshcd_hold() caused scheduling while atomic
@ 2020-04-11 23:14 ` Sasha Levin
0 siblings, 0 replies; 22+ messages in thread
From: Sasha Levin @ 2020-04-11 23:14 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Sasha Levin, linux-scsi, Martin K . Petersen, Asutosh Das,
Can Guo, linux-mediatek, linux-arm-kernel, Stanley Chu,
Hongwu Su, Bean Huo
From: Can Guo <cang@codeaurora.org>
[ Upstream commit c63d6099a7959ecc919b2549dc6b71f53521f819 ]
The async version of ufshcd_hold(async == true), which is only called in
queuecommand path as for now, is expected to work in atomic context, thus
it should not sleep or schedule out. When it runs into the condition that
clocks are ON but link is still in hibern8 state, it should bail out
without flushing the clock ungate work.
Fixes: f2a785ac2312 ("scsi: ufshcd: Fix race between clk scaling and ungate work")
Link: https://lore.kernel.org/r/1581392451-28743-6-git-send-email-cang@codeaurora.org
Reviewed-by: Hongwu Su <hongwus@codeaurora.org>
Reviewed-by: Asutosh Das <asutoshd@codeaurora.org>
Reviewed-by: Bean Huo <beanhuo@micron.com>
Reviewed-by: Stanley Chu <stanley.chu@mediatek.com>
Signed-off-by: Can Guo <cang@codeaurora.org>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/scsi/ufs/ufshcd.c | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/drivers/scsi/ufs/ufshcd.c b/drivers/scsi/ufs/ufshcd.c
index 19f82069c68ac..bc7f8d634c805 100644
--- a/drivers/scsi/ufs/ufshcd.c
+++ b/drivers/scsi/ufs/ufshcd.c
@@ -595,6 +595,11 @@ int ufshcd_hold(struct ufs_hba *hba, bool async)
*/
if (ufshcd_can_hibern8_during_gating(hba) &&
ufshcd_is_link_hibern8(hba)) {
+ if (async) {
+ rc = -EAGAIN;
+ hba->clk_gating.active_reqs--;
+ break;
+ }
spin_unlock_irqrestore(hba->host->host_lock, flags);
flush_work(&hba->clk_gating.ungate_work);
spin_lock_irqsave(hba->host->host_lock, flags);
--
2.20.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related [flat|nested] 22+ messages in thread* [PATCH AUTOSEL 4.4 16/16] scsi: ufs: Fix ufshcd_hold() caused scheduling while atomic
@ 2020-04-11 23:14 ` Sasha Levin
0 siblings, 0 replies; 22+ messages in thread
From: Sasha Levin @ 2020-04-11 23:14 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Sasha Levin, linux-scsi, Martin K . Petersen, Asutosh Das,
Can Guo, linux-mediatek, linux-arm-kernel, Stanley Chu,
Hongwu Su, Bean Huo
From: Can Guo <cang@codeaurora.org>
[ Upstream commit c63d6099a7959ecc919b2549dc6b71f53521f819 ]
The async version of ufshcd_hold(async == true), which is only called in
queuecommand path as for now, is expected to work in atomic context, thus
it should not sleep or schedule out. When it runs into the condition that
clocks are ON but link is still in hibern8 state, it should bail out
without flushing the clock ungate work.
Fixes: f2a785ac2312 ("scsi: ufshcd: Fix race between clk scaling and ungate work")
Link: https://lore.kernel.org/r/1581392451-28743-6-git-send-email-cang@codeaurora.org
Reviewed-by: Hongwu Su <hongwus@codeaurora.org>
Reviewed-by: Asutosh Das <asutoshd@codeaurora.org>
Reviewed-by: Bean Huo <beanhuo@micron.com>
Reviewed-by: Stanley Chu <stanley.chu@mediatek.com>
Signed-off-by: Can Guo <cang@codeaurora.org>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/scsi/ufs/ufshcd.c | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/drivers/scsi/ufs/ufshcd.c b/drivers/scsi/ufs/ufshcd.c
index 19f82069c68ac..bc7f8d634c805 100644
--- a/drivers/scsi/ufs/ufshcd.c
+++ b/drivers/scsi/ufs/ufshcd.c
@@ -595,6 +595,11 @@ int ufshcd_hold(struct ufs_hba *hba, bool async)
*/
if (ufshcd_can_hibern8_during_gating(hba) &&
ufshcd_is_link_hibern8(hba)) {
+ if (async) {
+ rc = -EAGAIN;
+ hba->clk_gating.active_reqs--;
+ break;
+ }
spin_unlock_irqrestore(hba->host->host_lock, flags);
flush_work(&hba->clk_gating.ungate_work);
spin_lock_irqsave(hba->host->host_lock, flags);
--
2.20.1
_______________________________________________
Linux-mediatek mailing list
Linux-mediatek@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-mediatek
^ permalink raw reply related [flat|nested] 22+ messages in thread