Currently if ucsi_send_command() fails, then we bail out without
clearing EVENT_PENDING flag. So when the next connector change
event comes, ucsi_connector_change() won't queue the con->work,
because of which none of the new events will be processed.
Fix this by clearing EVENT_PENDING flag if ucsi_send_command()
fails.
Cc: <stable(a)vger.kernel.org> # 5.16
Fixes: 512df95b9432 ("usb: typec: ucsi: Better fix for missing unplug events issue")
Signed-off-by: Prashanth K <quic_prashk(a)quicinc.com>
---
drivers/usb/typec/ucsi/ucsi.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/usb/typec/ucsi/ucsi.c b/drivers/usb/typec/ucsi/ucsi.c
index c6dfe3d..509c67c 100644
--- a/drivers/usb/typec/ucsi/ucsi.c
+++ b/drivers/usb/typec/ucsi/ucsi.c
@@ -884,6 +884,7 @@ static void ucsi_handle_connector_change(struct work_struct *work)
if (ret < 0) {
dev_err(ucsi->dev, "%s: GET_CONNECTOR_STATUS failed (%d)\n",
__func__, ret);
+ clear_bit(EVENT_PENDING, &con->ucsi->flags);
goto out_unlock;
}
--
2.7.4
Hi Pavel,
We have running systems that use COLOR_ID_MULTI. The GPIO toggles
between two colors and we have used the identifier. RGB is not a good
fit since it is not a RGB LED. Please provide guidance.
This patch causes the system to not start: f741121a2251 leds: Fix
BUG_ON check for LED_COLOR_ID_MULTI that is always false
It was also backported to stable causing previously booting systems to
no longer boot.
Best,
Da Xue
Since commit 2d47c6956ab3 ("ubsan: Tighten UBSAN_BOUNDS on GCC"),
UBSAN_BOUNDS no longer pretends 1-element arrays are unbounded. Walking
'element' and 'channel_list' will trigger warnings, so make them proper
flexible arrays.
False positive warnings were:
UBSAN: array-index-out-of-bounds in drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c:6984:20
index 1 is out of range for type '__le32 [1]'
UBSAN: array-index-out-of-bounds in drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c:1126:27
index 1 is out of range for type '__le16 [1]'
for these lines of code:
6884 ch.chspec = (u16)le32_to_cpu(list->element[i]);
1126 params_le->channel_list[i] = cpu_to_le16(chanspec);
Cc: stable(a)vger.kernel.org # 6.5+
Signed-off-by: Juerg Haefliger <juerg.haefliger(a)canonical.com>
---
v2:
- Use element[] instead of DFA() in brcmf_chanspec_list.
- Add Cc: stable tag
---
.../wireless/broadcom/brcm80211/brcmfmac/fwil_types.h | 9 +++++++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/fwil_types.h b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/fwil_types.h
index bece26741d3a..611d1a6aabb9 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/fwil_types.h
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/fwil_types.h
@@ -442,7 +442,12 @@ struct brcmf_scan_params_v2_le {
* fixed parameter portion is assumed, otherwise
* ssid in the fixed portion is ignored
*/
- __le16 channel_list[1]; /* list of chanspecs */
+ union {
+ __le16 padding; /* Reserve space for at least 1 entry for abort
+ * which uses an on stack brcmf_scan_params_v2_le
+ */
+ DECLARE_FLEX_ARRAY(__le16, channel_list); /* chanspecs */
+ };
};
struct brcmf_scan_results {
@@ -702,7 +707,7 @@ struct brcmf_sta_info_le {
struct brcmf_chanspec_list {
__le32 count; /* # of entries */
- __le32 element[1]; /* variable length uint32 list */
+ __le32 element[]; /* variable length uint32 list */
};
/*
--
2.39.2
Hi Greg, Sasha,
This batch contains a fixes for 4.19:
1) Missing fix in 4.19, you can cherry-pick it from
8ca79606cdfd ("netfilter: nft_flow_offload: fix underflow in flowtable reference counter")
2) Oneliner that includes missing chunk in 4.19 backport.
Fixes: 1df28fde1270 ("netfilter: nf_tables: add NFT_TRANS_PREPARE_ERROR to deal with bound set/chain") in 4.19
This patch you have to manually apply it.
Thanks.
Pablo Neira Ayuso (1):
netfilter: nf_tables: missing NFT_TRANS_PREPARE_ERROR in flowtable deactivatation
wenxu (1):
netfilter: nft_flow_offload: fix underflow in flowtable reference counter
net/netfilter/nf_tables_api.c | 1 +
net/netfilter/nft_flow_offload.c | 3 ---
2 files changed, 1 insertion(+), 3 deletions(-)
--
2.30.2
Daire reported a few issues with MPTCP where some connections were
stalled in different states. Paolo did a great job fixing them.
Patch 1 fixes bogus receive window shrinkage with multiple subflows. Due
to a race condition and unlucky circumstances, that may lead to
TCP-level window shrinkage, and the connection being stalled on the
sender end.
Patch 2 is a preparation for patch 3 which processes pending subflow
errors on close. Without that and under specific circumstances, the
MPTCP-level socket might not switch to the CLOSE state and stall.
Patch 4 is also a preparation patch for the next one. Patch 5 fixes
MPTCP connections not switching to the CLOSE state when all subflows
have been closed but no DATA_FIN have been exchanged to explicitly close
the MPTCP connection. Now connections in such state will switch to the
CLOSE state after a timeout, still allowing the "make-after-break"
feature but making sure connections don't stall forever. It will be
possible to modify this timeout -- currently matching TCP TIMEWAIT value
(60 seconds) -- in a future version.
Signed-off-by: Matthieu Baerts <matthieu.baerts(a)tessares.net>
---
Paolo Abeni (5):
mptcp: fix bogus receive window shrinkage with multiple subflows
mptcp: move __mptcp_error_report in protocol.c
mptcp: process pending subflow error on close
mptcp: rename timer related helper to less confusing names
mptcp: fix dangling connection hang-up
net/mptcp/options.c | 5 +-
net/mptcp/protocol.c | 165 +++++++++++++++++++++++++++++++--------------------
net/mptcp/protocol.h | 24 +++++++-
net/mptcp/subflow.c | 39 +-----------
4 files changed, 130 insertions(+), 103 deletions(-)
---
base-commit: 615efed8b63f60ddd69c0b8f32f7783859034fc2
change-id: 20230915-upstream-net-20230915-mptcp-hanging-conn-0609338b1728
Best regards,
--
Matthieu Baerts <matthieu.baerts(a)tessares.net>