6.3.9-rc1 review
Subsystems (2)
Greg Kroah-Hartman
maintainerPATCH 153/187 igb: fix nvm.ops.read() error handling
In reply to Greg Kroah-HartmanFrom: Aleksandr Loktionov <[email protected]>
[ Upstream commit 48a821fd58837800750ec1b3962f0f799630a844 ]
Add error handling into igb_set_eeprom() function, in case nvm.ops.read() fails just quit with error code asap.
--- drivers/net/ethernet/intel/igb/igb_ethtool.c | 3 +++ 1 file changed, 3 insertions(+)
drivers/net/ethernet/intel/igb/igb_ethtool.c +3 -0
@@ -822,6 +822,8 @@ static int igb_set_eeprom(struct net_device *netdev,*/ ret_val = hw->nvm.ops.read (hw, last_word,1 , &eeprom_buff[last_word - first_word]); +if (ret_val) + goto out; }/* Device's eeprom is always little-endian, word addressable */
@@ -841,6 +843,7 @@ static int igb_set_eeprom(struct net_device *netdev, hw->nvm.ops.update (hw);igb_set_fw_version (adapter); +out:kfree (eeprom_buff);return ret_val; }
Signature · 1 line
2.39.2
Greg Kroah-Hartman
maintainerPATCH 154/187 net: phylink: report correct max speed for QUSGMII
In reply to Greg Kroah-HartmanFrom: Maxime Chevallier <[email protected]>
[ Upstream commit b9dc1046edfeb7d9dbc2272c8d9ad5a8c47f3199 ]
Q-USGMII is the quad port version of USGMII, and supports a max speed of 1Gbps on each line. Make so that phylink_interface_max_speed() reports this information correctly.
--- drivers/net/phy/phylink.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/net/phy/phylink.c +1 -1
@@ -188,6 +188,7 @@ static int phylink_interface_max_speed(phy_interface_t interface)case PHY_INTERFACE_MODE_RGMII_ID :case PHY_INTERFACE_MODE_RGMII :case PHY_INTERFACE_MODE_QSGMII : +case PHY_INTERFACE_MODE_QUSGMII :case PHY_INTERFACE_MODE_SGMII :case PHY_INTERFACE_MODE_GMII :return SPEED_1000 ;
@@ -204,7 +205,6 @@ static int phylink_interface_max_speed(phy_interface_t interface)case PHY_INTERFACE_MODE_10GBASER :case PHY_INTERFACE_MODE_10GKR :case PHY_INTERFACE_MODE_USXGMII : -case PHY_INTERFACE_MODE_QUSGMII :return SPEED_10000 ;case PHY_INTERFACE_MODE_25GBASER :
Signature · 1 line
2.39.2
Greg Kroah-Hartman
maintainerPATCH 155/187 net: phylink: use a dedicated helper to parse usgmii control word
In reply to Greg Kroah-HartmanFrom: Maxime Chevallier <[email protected]>
[ Upstream commit 923454c0368b8092e9d05c020f50abca577e7290 ]
Q-USGMII is a derivative of USGMII, that uses a specific formatting for the control word. The layout is close to the USXGMII control word, but doesn't support speeds over 1Gbps. Use a dedicated decoding logic for the USGMII control word, re-using USXGMII definitions but only considering 10/100/1000Mbps speeds
--- drivers/net/phy/phylink.c | 39 ++++++++++++++++++++++++++++++++++++++- 1 file changed, 38 insertions(+), 1 deletion(-)
drivers/net/phy/phylink.c +38 -1
@@ -3297,6 +3297,41 @@ void phylink_decode_usxgmii_word(struct phylink_link_state *state, }EXPORT_SYMBOL_GPL (phylink_decode_usxgmii_word); +/** +* phylink_decode_usgmii_word() - decode the USGMII word from a MAC PCS +* @state: a pointer to a struct phylink_link_state. +* @lpa: a 16 bit value which stores the USGMII auto-negotiation word +* +* Helper for MAC PCS supporting the USGMII protocol and the auto-negotiation +* code word. Decode the USGMII code word and populate the corresponding fields +* (speed, duplex) into the phylink_link_state structure. The structure for this +* word is the same as the USXGMII word, except it only supports speeds up to +* 1Gbps. +*/ +static void phylink_decode_usgmii_word (struct phylink_link_state *state, +uint16_t lpa) +{ +switch (lpa &MDIO_USXGMII_SPD_MASK ) { +case MDIO_USXGMII_10 : + state->speed =SPEED_10 ; +break ; +case MDIO_USXGMII_100 : + state->speed =SPEED_100 ; +break ; +case MDIO_USXGMII_1000 : + state->speed =SPEED_1000 ; +break ; +default : + state->link = false; +return ; + } + +if (lpa &MDIO_USXGMII_FULL_DUPLEX ) + state->duplex =DUPLEX_FULL ; +else + state->duplex =DUPLEX_HALF ; +} +/** * phylink_mii_c22_pcs_decode_state() - Decode MAC PCS state from MII registers * @state: a pointer to a &struct phylink_link_state.
@@ -3333,9 +3368,11 @@ void phylink_mii_c22_pcs_decode_state(struct phylink_link_state *state,case PHY_INTERFACE_MODE_SGMII :case PHY_INTERFACE_MODE_QSGMII : -case PHY_INTERFACE_MODE_QUSGMII :phylink_decode_sgmii_word (state, lpa);break ; +case PHY_INTERFACE_MODE_QUSGMII : +phylink_decode_usgmii_word (state, lpa); +break ;default : state->link = false;
Signature · 1 line
2.39.2
Greg Kroah-Hartman
maintainerPATCH 156/187 drm/nouveau: dont detect DSM for non-NVIDIA device
In reply to Greg Kroah-HartmanFrom: Ratchanan Srirattanamet <[email protected]>
[ Upstream commit 11d24327c2d7ad7f24fcc44fb00e1fa91ebf6525 ]
The call site of nouveau_dsm_pci_probe() uses single set of output variables for all invocations. So, we must not write anything to them unless it's an NVIDIA device. Otherwise, if we are called with another device after the NVIDIA device, we'll clober the result of the NVIDIA device.
For example, if the other device doesn't have _PR3 resources, the detection later would miss the presence of power resource support, and the rest of the code will keep using Optimus DSM, breaking power management for that machine.
Also, because we're detecting NVIDIA's DSM, it doesn't make sense to run this detection on a non-NVIDIA device anyway. Thus, check at the beginning of the detection code if this is an NVIDIA card, and just return if it isn't.
This, together with commit d22915d22ded ("drm/nouveau/devinit/tu102-:
wait for GFW_BOOT_PROGRESS == COMPLETED") developed independently and landed earlier, fixes runtime power management of the NVIDIA card in Lenovo Legion 5-15ARH05. Without this patch, the GPU resumption code will "timeout", sometimes hanging userspace.
As a bonus, we'll also stop preventing _PR3 usage from the bridge for unrelated devices, which is always nice, I guess.
--- drivers/gpu/drm/nouveau/nouveau_acpi.c | 3 +++ 1 file changed, 3 insertions(+)
drivers/gpu/drm/nouveau/nouveau_acpi.c +3 -0
@@ -220,6 +220,9 @@ static void nouveau_dsm_pci_probe(struct pci_dev *pdev, acpi_handle *dhandle_outint optimus_funcs;struct pci_dev *parent_pdev; +if (pdev->vendor !=PCI_VENDOR_ID_NVIDIA ) +return ; + *has_pr3 = false; parent_pdev =pci_upstream_bridge (pdev);if (parent_pdev) {
Signature · 1 line
2.39.2
Greg Kroah-Hartman
maintainerPATCH 157/187 drm/bridge: ti-sn65dsi86: Avoid possible buffer overflow
In reply to Greg Kroah-HartmanFrom: Su Hui <[email protected]>
[ Upstream commit 95011f267c44a4d1f9ca1769e8a29ab2c559e004 ]
Smatch error:buffer overflow 'ti_sn_bridge_refclk_lut' 5 <= 5.
--- drivers/gpu/drm/bridge/ti-sn65dsi86.c | 4 ++++ 1 file changed, 4 insertions(+)
drivers/gpu/drm/bridge/ti-sn65dsi86.c +4 -0
@@ -298,6 +298,10 @@ static void ti_sn_bridge_set_refclk_freq(struct ti_sn65dsi86 *pdata)if (refclk_lut[i] == refclk_rate)break ; +/* avoid buffer overflow and "1" is the default rate in the datasheet. */ +if (i >= refclk_lut_size) + i =1 ; +regmap_update_bits (pdata->regmap,SN_DPPLL_SRC_REG ,REFCLK_FREQ_MASK ,REFCLK_FREQ (i));
Signature · 1 line
2.39.2
Greg Kroah-Hartman
maintainerPATCH 158/187 drm/nouveau/dp: check for NULL nv_connector->native_mode
In reply to Greg Kroah-HartmanFrom: Natalia Petrova <[email protected]>
[ Upstream commit 20a2ce87fbaf81e4c3dcb631d738e423959eb320 ]
Add checking for NULL before calling nouveau_connector_detect_depth() in nouveau_connector_get_modes() function because nv_connector->native_mode could be dereferenced there since connector pointer passed to nouveau_connector_detect_depth() and the same value of nv_connector->native_mode is used there.
Found by Linux Verification Center (linuxtesting.org) with SVACE.
--- drivers/gpu/drm/nouveau/nouveau_connector.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
drivers/gpu/drm/nouveau/nouveau_connector.c +2 -2
@@ -966,7 +966,7 @@ nouveau_connector_get_modes(struct drm_connector *connector)/* Determine display colour depth for everything except LVDS now, * DP requires this before mode_valid() is called. */ -if (connector->connector_type !=DRM_MODE_CONNECTOR_LVDS ) +if (connector->connector_type !=DRM_MODE_CONNECTOR_LVDS && nv_connector->native_mode)nouveau_connector_detect_depth (connector);/* Find the native mode if this is a digital panel, if we didn't
@@ -987,7 +987,7 @@ nouveau_connector_get_modes(struct drm_connector *connector)* "native" mode as some VBIOS tables require us to use the * pixel clock as part of the lookup... */ -if (connector->connector_type ==DRM_MODE_CONNECTOR_LVDS ) +if (connector->connector_type ==DRM_MODE_CONNECTOR_LVDS && nv_connector->native_mode)nouveau_connector_detect_depth (connector);if (nv_encoder->dcb->type ==DCB_OUTPUT_TV )
Signature · 1 line
2.39.2
Greg Kroah-Hartman
maintainerPATCH 159/187 drm/nouveau: add nv_encoder pointer check for NULL
In reply to Greg Kroah-HartmanFrom: Natalia Petrova <[email protected]>
[ Upstream commit 55b94bb8c42464bad3d2217f6874aa1a85664eac ]
Pointer nv_encoder could be dereferenced at nouveau_connector.c in case it's equal to NULL by jumping to goto label. This patch adds a NULL-check to avoid it.
Found by Linux Verification Center (linuxtesting.org) with SVACE.
--- drivers/gpu/drm/nouveau/nouveau_connector.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)
drivers/gpu/drm/nouveau/nouveau_connector.c +2 -1
@@ -730,7 +730,8 @@ nouveau_connector_detect_lvds(struct drm_connector *connector, bool force)#endif nouveau_connector_set_edid (nv_connector, edid); -nouveau_connector_set_encoder (connector, nv_encoder); +if (nv_encoder) +nouveau_connector_set_encoder (connector, nv_encoder);return status; }
Signature · 1 line
2.39.2
Greg Kroah-Hartman
maintainerPATCH 160/187 net: ethernet: ti: am65-cpsw: Call of_node_put() on error path
In reply to Greg Kroah-HartmanFrom: Dan Carpenter <[email protected]>
[ Upstream commit 374283a1001277e4d07491387aac1fad5aa08d43 ]
This code returns directly but it should instead call of_node_put() to drop some reference counts.
--- drivers/net/ethernet/ti/am65-cpsw-nuss.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/net/ethernet/ti/am65-cpsw-nuss.c +1 -1
@@ -2031,7 +2031,7 @@ static int am65_cpsw_nuss_init_slave_ports(struct am65_cpsw_common *common)/* Initialize the Serdes PHY for the port */ ret =am65_cpsw_init_serdes_phy (dev, port_np, port);if (ret) -return ret; + goto of_node_put; port->slave.mac_only =of_property_read_bool (port_np,"ti,mac-only" );
Signature · 1 line
2.39.2
Greg Kroah-Hartman
maintainerPATCH 161/187 selftests/tc-testing: Fix Error: Specified qdisc kind is unknown.
In reply to Greg Kroah-HartmanFrom: Vlad Buslov <[email protected]>
[ Upstream commit aef6e908b54200d04f2d77dab31509fcff2e60ae ]
All TEQL tests assume that sch_teql module is loaded. Load module in tdc.sh before running qdisc tests.
Fixes following example error when running tests via tdc.sh for all TEQL tests:
# $ sudo ./tdc.py -d eth2 -e 84a0
# -- ns/SubPlugin.__init__
# Test 84a0: Create TEQL with default setting
# exit: 2
# exit: 0
# Error: Specified qdisc kind is unknown.
#
# -----> teardown stage *** Could not execute: "$TC qdisc del dev $DUMMY handle 1: root" #
# -----> teardown stage *** Error message: "Error: Invalid handle.
# "
# returncode 2; expected [0]
#
# -----> teardown stage *** Aborting test run.
#
# <_io.BufferedReader name=3> *** stdout ***
#
# <_io.BufferedReader name=5> *** stderr ***
# "-----> teardown stage" did not complete successfully
# Exception <class '__main__.PluginMgrTestFail'> ('teardown', 'Error: Specified qdisc kind is unknown.\n', '"-----> teardown stage" did not complete successfully') (caught in test_runner, running test 2 84a0 Create TEQL with default setting stage teardown)
# ---------------
# traceback
# File "/images/src/linux/tools/testing/selftests/tc-testing/./tdc.py", line 495, in test_runner
# res = run_one_test(pm, args, index, tidx)
# File "/images/src/linux/tools/testing/selftests/tc-testing/./tdc.py", line 434, in run_one_test
# prepare_env(args, pm, 'teardown', '-----> teardown stage', tidx['teardown'], procout)
# File "/images/src/linux/tools/testing/selftests/tc-testing/./tdc.py", line 245, in prepare_env
# raise PluginMgrTestFail(
# ---------------
# accumulated output for this test:
# Error: Specified qdisc kind is unknown.
#
# ---------------
#
# All test results:
#
# 1..1
# ok 1 84a0 - Create TEQL with default setting # skipped - "-----> teardown stage" did not complete successfully--- tools/testing/selftests/tc-testing/tdc.sh | 1 + 1 file changed, 1 insertion(+)
tools/testing/selftests/tc-testing/tdc.sh +1 -0
@@ -2,5 +2,6 @@ # SPDX-License-Identifier: GPL-2.0 modprobe netdevsim +modprobe sch_teql ./tdc.py -c actions --nobuildebpf ./tdc.py -c qdisc
Signature · 1 line
2.39.2
Greg Kroah-Hartman
maintainerPATCH 162/187 selftests/tc-testing: Fix Error: failed to find target LOG
In reply to Greg Kroah-HartmanFrom: Vlad Buslov <[email protected]>
[ Upstream commit b849c566ee9c6ed78288a522278dcaf419f8e239 ]
Add missing netfilter config dependency.
Fixes following example error when running tests via tdc.sh for all XT tests:
# $ sudo ./tdc.py -d eth2 -e 2029
# Test 2029: Add xt action with log-prefix
# exit: 255
# exit: 0
# failed to find target LOG
#
# bad action parsing
# parse_action: bad value (7:xt)!
# Illegal "action"
#
# -----> teardown stage *** Could not execute: "$TC actions flush action xt"
#
# -----> teardown stage *** Error message: "Error: Cannot flush unknown TC action.
# We have an error flushing
# "
# returncode 1; expected [0]
#
# -----> teardown stage *** Aborting test run.
#
# <_io.BufferedReader name=3> *** stdout ***
#
# <_io.BufferedReader name=5> *** stderr ***
# "-----> teardown stage" did not complete successfully
# Exception <class '__main__.PluginMgrTestFail'> ('teardown', ' failed to find target LOG\n\nbad action parsing\nparse_action: bad value (7:xt)!\nIllegal "action"\n', '"-----> teardown stage" did not complete successfully') (caught in test_runner, running test 2 2029 Add xt action with log-prefix stage teardown)
# ---------------
# traceback
# File "/images/src/linux/tools/testing/selftests/tc-testing/./tdc.py", line 495, in test_runner
# res = run_one_test(pm, args, index, tidx)
# File "/images/src/linux/tools/testing/selftests/tc-testing/./tdc.py", line 434, in run_one_test
# prepare_env(args, pm, 'teardown', '-----> teardown stage', tidx['teardown'], procout)
# File "/images/src/linux/tools/testing/selftests/tc-testing/./tdc.py", line 245, in prepare_env
# raise PluginMgrTestFail(
# ---------------
# accumulated output for this test:
# failed to find target LOG
#
# bad action parsing
# parse_action: bad value (7:xt)!
# Illegal "action"
#
# ---------------
#
# All test results:
#
# 1..1
# ok 1 2029 - Add xt action with log-prefix # skipped - "-----> teardown stage" did not complete successfully--- tools/testing/selftests/tc-testing/config | 1 + 1 file changed, 1 insertion(+)
tools/testing/selftests/tc-testing/config +1 -0
@@ -6,6 +6,7 @@ CONFIG_NF_CONNTRACK_MARK=y CONFIG_NF_CONNTRACK_ZONES=y CONFIG_NF_CONNTRACK_LABELS=y CONFIG_NF_NAT=m +CONFIG_NETFILTER_XT_TARGET_LOG=m CONFIG_NET_SCHED=y
Signature · 1 line
2.39.2
Greg Kroah-Hartman
maintainerPATCH 163/187 selftests/tc-testing: Fix SFB db test
In reply to Greg Kroah-HartmanFrom: Vlad Buslov <[email protected]>
[ Upstream commit b39d8c41c7a8336ce85c376b5d4906089524a0ae ]
Setting very small value of db like 10ms introduces rounding errors when converting to/from jiffies on some kernel configs. For example, on 250hz the actual value will be set to 12ms which causes the test to fail:
# $ sudo ./tdc.py -d eth2 -e 3410
# -- ns/SubPlugin.__init__
# Test 3410: Create SFB with db setting
#
# All test results:
#
# 1..1
# not ok 1 3410 - Create SFB with db setting # Could not match regex pattern. Verify command output: # qdisc sfb 1: root refcnt 2 rehash 600s db 12ms limit 1000p max 25p target 20p increment 0.000503548 decrement 4.57771e-05 penalty_rate 10pps penalty_burst 20p
Set the value to 100ms instead which currently seem to work on 100hz, 250hz, 300hz and 1000hz kernel configs.
--- tools/testing/selftests/tc-testing/tc-tests/qdiscs/sfb.json | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
tools/testing/selftests/tc-testing/tc-tests/qdiscs/sfb.json +2 -2
@@ -58,10 +58,10 @@ "setup": [ "$IP link add dev $DUMMY type dummy || /bin/true" ], - "cmdUnderTest": "$TC qdisc add dev $DUMMY handle 1: root sfb db 10", + "cmdUnderTest": "$TC qdisc add dev $DUMMY handle 1: root sfb db 100", "expExitCode": "0", "verifyCmd": "$TC qdisc show dev $DUMMY", - "matchPattern": "qdisc sfb 1: root refcnt [0-9]+ rehash 600s db 10ms", + "matchPattern": "qdisc sfb 1: root refcnt [0-9]+ rehash 600s db 100ms", "matchCount": "1", "teardown": [ "$TC qdisc del dev $DUMMY handle 1: root",
Signature · 1 line
2.39.2
Greg Kroah-Hartman
maintainerPATCH 164/187 net/sched: act_ct: Fix promotion of offloaded unreplied tuple
In reply to Greg Kroah-HartmanFrom: Paul Blakey <[email protected]>
[ Upstream commit 41f2c7c342d3adb1c4dd5f2e3dd831adff16a669 ]
Currently UNREPLIED and UNASSURED connections are added to the nf flow table. This causes the following connection packets to be processed by the flow table which then skips conntrack_in(), and thus such the connections will remain UNREPLIED and UNASSURED even if reply traffic is then seen. Even still, the unoffloaded reply packets are the ones triggering hardware update from new to established state, and if there aren't any to triger an update and/or previous update was missed, hardware can get out of sync with sw and still mark packets as new.
Fix the above by:
1) Not skipping conntrack_in() for UNASSURED packets, but still refresh for hardware, as before the cited patch.
2) Try and force a refresh by reply-direction packets that update the hardware rules from new to established state.
3) Remove any bidirectional flows that didn't failed to update in hardware for re-insertion as bidrectional once any new packet arrives.
--- include/net/netfilter/nf_flow_table.h | 2 +- net/netfilter/nf_flow_table_core.c | 13 ++++++++++--- net/netfilter/nf_flow_table_ip.c | 4 ++-- net/sched/act_ct.c | 9 ++++++++- 4 files changed, 21 insertions(+), 7 deletions(-)
include/net/netfilter/nf_flow_table.h +1 -1
@@ -268,7 +268,7 @@ int flow_offload_route_init(struct flow_offload *flow,int flow_offload_add (struct nf_flowtable *flow_table,struct flow_offload *flow);void flow_offload_refresh (struct nf_flowtable *flow_table, -struct flow_offload *flow); +struct flow_offload *flow,bool force);struct flow_offload_tuple_rhash *flow_offload_lookup (struct nf_flowtable *flow_table,struct flow_offload_tuple *tuple);
net/netfilter/nf_flow_table_core.c +10 -3
@@ -317,12 +317,12 @@ int flow_offload_add(struct nf_flowtable *flow_table, struct flow_offload *flow)EXPORT_SYMBOL_GPL (flow_offload_add);void flow_offload_refresh (struct nf_flowtable *flow_table, -struct flow_offload *flow) +struct flow_offload *flow,bool force) {u32 timeout; timeout = nf_flowtable_time_stamp +flow_offload_get_timeout (flow); -if (timeout -READ_ONCE (flow->timeout) >HZ ) +if (force || timeout -READ_ONCE (flow->timeout) >HZ )WRITE_ONCE (flow->timeout, timeout);else return ;
@@ -334,6 +334,12 @@ void flow_offload_refresh(struct nf_flowtable *flow_table, }EXPORT_SYMBOL_GPL (flow_offload_refresh); +static bool nf_flow_is_outdated (const struct flow_offload *flow) +{ +return test_bit (IPS_SEEN_REPLY_BIT , &flow->ct->status) && + !test_bit (NF_FLOW_HW_ESTABLISHED , &flow->flags); +} +static inline bool nf_flow_has_expired (const struct flow_offload *flow) {return nf_flow_timeout_delta (flow->timeout) <=0 ;
@@ -423,7 +429,8 @@ static void nf_flow_offload_gc_step(struct nf_flowtable *flow_table, struct flow_offload *flow, void *data) { if (nf_flow_has_expired(flow) || - nf_ct_is_dying(flow->ct)) + nf_ct_is_dying(flow->ct) || + nf_flow_is_outdated(flow)) flow_offload_teardown(flow); if (test_bit(NF_FLOW_TEARDOWN, &flow->flags)) {
net/netfilter/nf_flow_table_ip.c +2 -2
@@ -384,7 +384,7 @@ nf_flow_offload_ip_hook(void *priv, struct sk_buff *skb,if (skb_try_make_writable (skb, thoff + hdrsize))return NF_DROP ; -flow_offload_refresh (flow_table, flow); +flow_offload_refresh (flow_table, flow, false);nf_flow_encap_pop (skb, tuplehash); thoff -= offset;
@@ -650,7 +650,7 @@ nf_flow_offload_ipv6_hook(void *priv, struct sk_buff *skb,if (skb_try_make_writable (skb, thoff + hdrsize))return NF_DROP ; -flow_offload_refresh (flow_table, flow); +flow_offload_refresh (flow_table, flow, false);nf_flow_encap_pop (skb, tuplehash);
net/sched/act_ct.c +8 -1
@@ -610,6 +610,7 @@ static bool tcf_ct_flow_table_lookup(struct tcf_ct_params *p,struct flow_offload_tuple tuple = {};enum ip_conntrack_info ctinfo;struct tcphdr *tcph =NULL ; +bool force_refresh = false;struct flow_offload *flow;struct nf_conn *ct;u8 dir;
@@ -647,6 +648,7 @@ static bool tcf_ct_flow_table_lookup(struct tcf_ct_params *p,* established state, then don't refresh. */ return false; + force_refresh = true; }if (tcph && (unlikely (tcph->fin || tcph->rst))) {
@@ -660,7 +662,12 @@ static bool tcf_ct_flow_table_lookup(struct tcf_ct_params *p,else ctinfo =IP_CT_ESTABLISHED_REPLY ; -flow_offload_refresh (nf_ft, flow); +flow_offload_refresh (nf_ft, flow, force_refresh); +if (!test_bit (IPS_ASSURED_BIT , &ct->status)) { +/* Process this flow in SW to allow promoting to ASSURED */ +return false; + } +nf_conntrack_get (&ct->ct_general);nf_ct_set (skb, ct, ctinfo);if (nf_ft->flags &NF_FLOWTABLE_COUNTER )
Signature · 1 line
2.39.2
Greg Kroah-Hartman
maintainerPATCH 165/187 net/sched: Refactor qdisc_graft() for ingress and clsact Qdiscs
In reply to Greg Kroah-HartmanFrom: Peilin Ye <[email protected]>
[ Upstream commit 2d5f6a8d7aef7852a9ecc555f88c673a1c91754f ]
Grafting ingress and clsact Qdiscs does not need a for-loop in qdisc_graft(). Refactor it. No functional changes intended.
Stable-dep-of: 84ad0af0bccd ("net/sched: qdisc_destroy() old ingress and clsact Qdiscs before grafting")
--- net/sched/sch_api.c | 20 ++++++++++---------- 1 file changed, 10 insertions(+), 10 deletions(-)
net/sched/sch_api.c +10 -10
@@ -1077,12 +1077,12 @@ static int qdisc_graft(struct net_device *dev, struct Qdisc *parent,if (parent ==NULL ) {unsigned int i, num_q, ingress; +struct netdev_queue *dev_queue; ingress =0 ; num_q = dev->num_tx_queues;if ((q && q->flags &TCQ_F_INGRESS ) || (new && new->flags &TCQ_F_INGRESS )) { - num_q =1 ; ingress =1 ;if (!dev_ingress_queue (dev)) {NL_SET_ERR_MSG (extack,"Device does not have an ingress queue" );
@@ -1098,18 +1098,18 @@ static int qdisc_graft(struct net_device *dev, struct Qdisc *parent,if (new && new->ops->attach && !ingress) goto skip; -for (i =0 ; i < num_q; i++) { -struct netdev_queue *dev_queue =dev_ingress_queue (dev); - -if (!ingress) +if (!ingress) { +for (i =0 ; i < num_q; i++) { dev_queue =netdev_get_tx_queue (dev, i); + old =dev_graft_qdisc (dev_queue, new); - old =dev_graft_qdisc (dev_queue, new); -if (new && i >0 ) -qdisc_refcount_inc (new); - -if (!ingress) +if (new && i >0 ) +qdisc_refcount_inc (new);qdisc_put (old); + } + }else { + dev_queue =dev_ingress_queue (dev); + old =dev_graft_qdisc (dev_queue, new); } skip:
Signature · 1 line
2.39.2
Greg Kroah-Hartman
maintainerPATCH 166/187 net/sched: qdisc_destroy() old ingress and clsact Qdiscs before grafting
In reply to Greg Kroah-HartmanFrom: Peilin Ye <[email protected]>
[ Upstream commit 84ad0af0bccd3691cb951c2974c5cb2c10594d4a ]
mini_Qdisc_pair::p_miniq is a double pointer to mini_Qdisc, initialized in ingress_init() to point to net_device::miniq_ingress. ingress Qdiscs access this per-net_device pointer in mini_qdisc_pair_swap(). Similar for clsact Qdiscs and miniq_egress.
Unfortunately, after introducing RTNL-unlocked RTM_{NEW,DEL,GET}TFILTER requests (thanks Hillf Danton for the hint), when replacing ingress or clsact Qdiscs, for example, the old Qdisc ("@old") could access the same miniq_{in,e}gress pointer(s) concurrently with the new Qdisc ("@new"), causing race conditions [1] including a use-after-free bug in mini_qdisc_pair_swap() reported by syzbot:
BUG: KASAN: slab-use-after-free in mini_qdisc_pair_swap+0x1c2/0x1f0 net/sched/sch_generic.c:1573 Write of size 8 at addr ffff888045b31308 by task syz-executor690/14901 ... Call Trace: <TASK> __dump_stack lib/dump_stack.c:88 [inline] dump_stack_lvl+0xd9/0x150 lib/dump_stack.c:106 print_address_description.constprop.0+0x2c/0x3c0 mm/kasan/report.c:319 print_report mm/kasan/report.c:430 [inline] kasan_report+0x11c/0x130 mm/kasan/report.c:536 mini_qdisc_pair_swap+0x1c2/0x1f0 net/sched/sch_generic.c:1573 tcf_chain_head_change_item net/sched/cls_api.c:495 [inline] tcf_chain0_head_change.isra.0+0xb9/0x120 net/sched/cls_api.c:509 tcf_chain_tp_insert net/sched/cls_api.c:1826 [inline] tcf_chain_tp_insert_unique net/sched/cls_api.c:1875 [inline] tc_new_tfilter+0x1de6/0x2290 net/sched/cls_api.c:2266
...
@old and @new should not affect each other. In other words, @old should never modify miniq_{in,e}gress after @new, and @new should not update @old's RCU state.
Fixing without changing sch_api.c turned out to be difficult (please refer to Closes: for discussions). Instead, make sure @new's first call always happen after @old's last call (in {ingress,clsact}_destroy()) has finished:
In qdisc_graft(), return -EBUSY if @old has any ongoing filter requests, and call qdisc_destroy() for @old before grafting @new.
Introduce qdisc_refcount_dec_if_one() as the counterpart of qdisc_refcount_inc_nz() used for filter requests. Introduce a non-static version of qdisc_destroy() that does a TCQ_F_BUILTIN check, just like qdisc_put() etc.
Depends on patch "net/sched: Refactor qdisc_graft() for ingress and clsact Qdiscs".
[1] To illustrate, the syzkaller reproducer adds ingress Qdiscs under TC_H_ROOT (no longer possible after commit c7cfbd115001 ("net/sched:sch_ingress: Only create under TC_H_INGRESS")) on eth0 that has 8 transmission queues:
Thread 1 creates ingress Qdisc A (containing mini Qdisc a1 and a2), then adds a flower filter X to A.
Thread 2 creates another ingress Qdisc B (containing mini Qdisc b1 and b2) to replace A, then adds a flower filter Y to B.
Thread 1 A's refcnt Thread 2
RTM_NEWQDISC (A, RTNL-locked)
qdisc_create(A) 1
qdisc_graft(A) 9
RTM_NEWTFILTER (X, RTNL-unlocked)
__tcf_qdisc_find(A) 10
tcf_chain0_head_change(A)
mini_qdisc_pair_swap(A) (1st)
|
| RTM_NEWQDISC (B, RTNL-locked)
RCU sync 2 qdisc_graft(B)
| 1 notify_and_destroy(A)
|
tcf_block_release(A) 0 RTM_NEWTFILTER (Y, RTNL-unlocked)
qdisc_destroy(A) tcf_chain0_head_change(B)
tcf_chain0_head_change_cb_del(A) mini_qdisc_pair_swap(B) (2nd)
mini_qdisc_pair_swap(A) (3rd) |
... ...
Here, B calls mini_qdisc_pair_swap(), pointing eth0->miniq_ingress to its mini Qdisc, b1. Then, A calls mini_qdisc_pair_swap() again during ingress_destroy(), setting eth0->miniq_ingress to NULL, so ingress packets on eth0 will not find filter Y in sch_handle_ingress().
This is just one of the possible consequences of concurrently accessing miniq_{in,e}gress pointers.
--- include/net/sch_generic.h | 8 ++++++++ net/sched/sch_api.c | 28 +++++++++++++++++++++++----- net/sched/sch_generic.c | 14 +++++++++++--- 3 files changed, 42 insertions(+), 8 deletions(-)
include/net/sch_generic.h +8 -0
@@ -137,6 +137,13 @@ static inline void qdisc_refcount_inc(struct Qdisc *qdisc)refcount_inc (&qdisc->refcnt); } +static inline bool qdisc_refcount_dec_if_one (struct Qdisc *qdisc) +{ +if (qdisc->flags &TCQ_F_BUILTIN ) +return true; +return refcount_dec_if_one (&qdisc->refcnt); +} +/* Intended to be used by unlocked users, when concurrent qdisc release is * possible. */
@@ -652,6 +659,7 @@ void dev_deactivate_many(struct list_head *head);struct Qdisc *dev_graft_qdisc (struct netdev_queue *dev_queue,struct Qdisc *qdisc);void qdisc_reset (struct Qdisc *qdisc); +void qdisc_destroy (struct Qdisc *qdisc);void qdisc_put (struct Qdisc *qdisc);void qdisc_put_unlocked (struct Qdisc *qdisc);void qdisc_tree_reduce_backlog (struct Qdisc *qdisc,int n,int len);
net/sched/sch_api.c +23 -5
@@ -1084,10 +1084,22 @@ static int qdisc_graft(struct net_device *dev, struct Qdisc *parent,if ((q && q->flags &TCQ_F_INGRESS ) || (new && new->flags &TCQ_F_INGRESS )) { ingress =1 ; -if (!dev_ingress_queue (dev)) { + dev_queue =dev_ingress_queue (dev); +if (!dev_queue) {NL_SET_ERR_MSG (extack,"Device does not have an ingress queue" );return -ENOENT ; } + + q =rtnl_dereference (dev_queue->qdisc_sleeping); + +/* This is the counterpart of that qdisc_refcount_inc_nz() call in +* __tcf_qdisc_find() for filter requests. +*/ +if (!qdisc_refcount_dec_if_one (q)) { +NL_SET_ERR_MSG (extack, +"Current ingress or clsact Qdisc has ongoing filter requests" ); +return -EBUSY ; + } }if (dev->flags &IFF_UP )
@@ -1108,8 +1120,16 @@ static int qdisc_graft(struct net_device *dev, struct Qdisc *parent,qdisc_put (old); } }else { - dev_queue =dev_ingress_queue (dev); - old =dev_graft_qdisc (dev_queue, new); + old =dev_graft_qdisc (dev_queue,NULL ); + +/* {ingress,clsact}_destroy() @old before grafting @new to avoid +* unprotected concurrent accesses to net_device::miniq_{in,e}gress +* pointer(s) in mini_qdisc_pair_swap(). +*/ +qdisc_notify (net, skb, n, classid, old, new, extack); +qdisc_destroy (old); + +dev_graft_qdisc (dev_queue, new); } skip:
@@ -1123,8 +1143,6 @@ static int qdisc_graft(struct net_device *dev, struct Qdisc *parent,if (new && new->ops->attach) new->ops->attach (new); - }else { -notify_and_destroy (net, skb, n, classid, old, new, extack); }if (dev->flags &IFF_UP )
net/sched/sch_generic.c +11 -3
@@ -1046,7 +1046,7 @@ static void qdisc_free_cb(struct rcu_head *head)qdisc_free (q); } -static void qdisc_destroy (struct Qdisc *qdisc) +static void __qdisc_destroy (struct Qdisc *qdisc) {const struct Qdisc_ops *ops = qdisc->ops;
@@ -1070,6 +1070,14 @@ static void qdisc_destroy(struct Qdisc *qdisc)call_rcu (&qdisc->rcu, qdisc_free_cb); } +void qdisc_destroy (struct Qdisc *qdisc) +{ +if (qdisc->flags &TCQ_F_BUILTIN ) +return ; + +__qdisc_destroy (qdisc); +} +void qdisc_put (struct Qdisc *qdisc) {if (!qdisc)
@@ -1079,7 +1087,7 @@ void qdisc_put(struct Qdisc *qdisc) !refcount_dec_and_test(&qdisc->refcnt))return ; -qdisc_destroy (qdisc); +__qdisc_destroy (qdisc); }EXPORT_SYMBOL (qdisc_put);
@@ -1094,7 +1102,7 @@ void qdisc_put_unlocked(struct Qdisc *qdisc) !refcount_dec_and_rtnl_lock(&qdisc->refcnt)) return; -qdisc_destroy (qdisc); +__qdisc_destroy (qdisc);rtnl_unlock (); }EXPORT_SYMBOL (qdisc_put_unlocked);
Signature · 1 line
2.39.2
Greg Kroah-Hartman
maintainerPATCH 167/187 selftests: forwarding: hw_stats_l3: Set addrgenmode in a separate step
In reply to Greg Kroah-HartmanFrom: Danielle Ratson <[email protected]>
[ Upstream commit bef68e201e538eaa3a91f97aae8161eb2d0a8ed7 ]
Setting the IPv6 address generation mode of a net device during its creation never worked, but after commit b0ad3c179059 ("rtnetlink: call validate_linkmsg in rtnl_create_link") it explicitly fails [1]. The failure is caused by the fact that validate_linkmsg() is called before the net device is registered, when it still does not have an 'inet6_dev'.
Likewise, raising the net device before setting the address generation mode is meaningless, because by the time the mode is set, the address has already been generated.
Therefore, fix the test to first create the net device, then set its IPv6 address generation mode and finally bring it up.
[1]
# ip link add name mydev addrgenmode eui64 type dummy RTNETLINK answers: Address family not supported by protocol
--- tools/testing/selftests/net/forwarding/hw_stats_l3.sh | 11 +++++++---- 1 file changed, 7 insertions(+), 4 deletions(-)
tools/testing/selftests/net/forwarding/hw_stats_l3.sh +7 -4
@@ -84,8 +84,9 @@ h2_destroy() router_rp1_200_create() { - ip link add name $rp1.200 up \ - link $rp1 addrgenmode eui64 type vlan id 200 + ip link add name $rp1.200 link $rp1 type vlan id 200 + ip link set dev $rp1.200 addrgenmode eui64 + ip link set dev $rp1.200 up ip address add dev $rp1.200 192.0.2.2/28 ip address add dev $rp1.200 2001:db8:1::2/64 ip stats set dev $rp1.200 l3_stats on
@@ -256,9 +257,11 @@ reapply_config() router_rp1_200_destroy - ip link add name $rp1.200 link $rp1 addrgenmode none type vlan id 200 + ip link add name $rp1.200 link $rp1 type vlan id 200 + ip link set dev $rp1.200 addrgenmode none ip stats set dev $rp1.200 l3_stats on - ip link set dev $rp1.200 up addrgenmode eui64 + ip link set dev $rp1.200 addrgenmode eui64 + ip link set dev $rp1.200 up ip address add dev $rp1.200 192.0.2.2/28 ip address add dev $rp1.200 2001:db8:1::2/64 }
Signature · 1 line
2.39.2
Greg Kroah-Hartman
maintainerPATCH 168/187 cifs: fix lease break oops in xfstest generic/098
In reply to Greg Kroah-HartmanFrom: Steve French <[email protected]>
[ Upstream commit c774e6779f38bf36f0cce65e30793704bab4b0d7 ]
umount can race with lease break so need to check if tcon->ses->server is still valid to send the lease break response.
--- fs/cifs/file.c | 8 ++++++-- 1 file changed, 6 insertions(+), 2 deletions(-)
fs/cifs/file.c +6 -2
@@ -4942,9 +4942,13 @@ void cifs_oplock_break(struct work_struct *work)* disconnected since oplock already released by the server */ if (!oplock_break_cancelled) { - rc = tcon->ses->server->ops->oplock_response (tcon, persistent_fid, +/* check for server null since can race with kill_sb calling tree disconnect */ +if (tcon->ses && tcon->ses->server) { + rc = tcon->ses->server->ops->oplock_response (tcon, persistent_fid, volatile_fid, net_fid, cinode); -cifs_dbg (FYI ,"Oplock release rc = %d\n" , rc); +cifs_dbg (FYI ,"Oplock release rc = %d\n" , rc); + }else +pr_warn_once ("lease break not sent for unmounted share\n" ); }cifs_done_oplock_break (cinode);
Signature · 1 line
2.39.2
Greg Kroah-Hartman
maintainerPATCH 169/187 RDMA/rxe: Fix rxe_cq_post
In reply to Greg Kroah-HartmanFrom: Bob Pearson <[email protected]>
[ Upstream commit 0c7e314a6352664e12ec465f576cf039e95f8369 ]
A recent patch replaced a tasklet execution of cq->comp_handler by a direct call. While this made sense it let changes to cq->notify state be unprotected and assumed that the cq completion machinery and the ulp done callbacks were reentrant. The result is that in some cases completion events can be lost. This patch moves the cq->comp_handler call inside of the spinlock in rxe_cq_post which solves both issues. This is compatible with the matching code in the request notify verb.
--- drivers/infiniband/sw/rxe/rxe_cq.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
drivers/infiniband/sw/rxe/rxe_cq.c +2 -2
@@ -112,8 +112,6 @@ int rxe_cq_post(struct rxe_cq *cq, struct rxe_cqe *cqe, int solicited)queue_advance_producer (cq->queue,QUEUE_TYPE_TO_CLIENT ); -spin_unlock_irqrestore (&cq->cq_lock, flags); -if ((cq->notify ==IB_CQ_NEXT_COMP ) || (cq->notify ==IB_CQ_SOLICITED && solicited)) { cq->notify =0 ;
@@ -121,6 +119,8 @@ int rxe_cq_post(struct rxe_cq *cq, struct rxe_cqe *cqe, int solicited) cq->ibcq.comp_handler (&cq->ibcq, cq->ibcq.cq_context); } +spin_unlock_irqrestore (&cq->cq_lock, flags); +return 0 ; }
Signature · 1 line
2.39.2
Greg Kroah-Hartman
maintainerPATCH 170/187 Revert "media: dvb-core: Fix use-after-free on race condition at dvb_frontend"
In reply to Greg Kroah-HartmanFrom: Mauro Carvalho Chehab <[email protected]>
[ Upstream commit ec21a38df77a5aefbd2f70c48127003b6f259cf3 ]
As reported by Thomas Voegtle <[email protected]>, sometimes a DVB card does not initialize properly booting Linux 6.4-rc4. This is not always, maybe in 3 out of 4 attempts.
After double-checking, the root cause seems to be related to the UAF fix, which is causing a race issue:
[ 26.332149] tda10071 7-0005: found a 'NXP TDA10071' in cold state, will try to load a firmware [ 26.340779] tda10071 7-0005: downloading firmware from file 'dvb-fe-tda10071.fw' [ 989.277402] INFO: task vdr:743 blocked for more than 491 seconds. [ 989.283504] Not tainted 6.4.0-rc5-i5 #249 [ 989.288036] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. [ 989.295860] task:vdr state:D stack:0 pid:743 ppid:711 flags:0x00004002 [ 989.295865] Call Trace: [ 989.295867] <TASK> [ 989.295869] __schedule+0x2ea/0x12d0 [ 989.295877] ? asm_sysvec_apic_timer_interrupt+0x16/0x20 [ 989.295881] schedule+0x57/0xc0 [ 989.295884] schedule_preempt_disabled+0xc/0x20 [ 989.295887] __mutex_lock.isra.16+0x237/0x480 [ 989.295891] ? dvb_get_property.isra.10+0x1bc/0xa50 [ 989.295898] ? dvb_frontend_stop+0x36/0x180 [ 989.338777] dvb_frontend_stop+0x36/0x180 [ 989.338781] dvb_frontend_open+0x2f1/0x470 [ 989.338784] dvb_device_open+0x81/0xf0 [ 989.338804] ? exact_lock+0x20/0x20 [ 989.338808] chrdev_open+0x7f/0x1c0 [ 989.338811] ? generic_permission+0x1a2/0x230 [ 989.338813] ? link_path_walk.part.63+0x340/0x380 [ 989.338815] ? exact_lock+0x20/0x20 [ 989.338817] do_dentry_open+0x18e/0x450 [ 989.374030] path_openat+0xca5/0xe00 [ 989.374031] ? terminate_walk+0xec/0x100 [ 989.374034] ? path_lookupat+0x93/0x140 [ 989.374036] do_filp_open+0xc0/0x140 [ 989.374038] ? __call_rcu_common.constprop.91+0x92/0x240 [ 989.374041] ? __check_object_size+0x147/0x260 [ 989.374043] ? __check_object_size+0x147/0x260 [ 989.374045] ? alloc_fd+0xbb/0x180 [ 989.374048] ? do_sys_openat2+0x243/0x310 [ 989.374050] do_sys_openat2+0x243/0x310 [ 989.374052] do_sys_open+0x52/0x80 [ 989.374055] do_syscall_64+0x5b/0x80 [ 989.421335] ? __task_pid_nr_ns+0x92/0xa0 [ 989.421337] ? syscall_exit_to_user_mode+0x20/0x40 [ 989.421339] ? do_syscall_64+0x67/0x80 [ 989.421341] ? syscall_exit_to_user_mode+0x20/0x40 [ 989.421343] ? do_syscall_64+0x67/0x80 [ 989.421345] entry_SYSCALL_64_after_hwframe+0x63/0xcd [ 989.421348] RIP: 0033:0x7fe895d067e3 [ 989.421349] RSP: 002b:00007fff933c2ba0 EFLAGS: 00000293 ORIG_RAX: 0000000000000101 [ 989.421351] RAX: ffffffffffffffda RBX: 00007fff933c2c10 RCX: 00007fe895d067e3 [ 989.421352] RDX: 0000000000000802 RSI: 00005594acdce160 RDI: 00000000ffffff9c [ 989.421353] RBP: 0000000000000802 R08: 0000000000000000 R09: 0000000000000000 [ 989.421353] R10: 0000000000000000 R11: 0000000000000293 R12: 0000000000000001 [ 989.421354] R13: 00007fff933c2ca0 R14: 00000000ffffffff R15: 00007fff933c2c90 [ 989.421355] </TASK>
This reverts commit 6769a0b7ee0c3b31e1b22c3fadff2bfb642de23f.
--- drivers/media/dvb-core/dvb_frontend.c | 53 +++++---------------------- include/media/dvb_frontend.h | 6 +-- 2 files changed, 10 insertions(+), 49 deletions(-)
drivers/media/dvb-core/dvb_frontend.c +9 -44
@@ -817,26 +817,15 @@ static void dvb_frontend_stop(struct dvb_frontend *fe)dev_dbg (fe->dvb->device,"%s:\n" , __func__); -mutex_lock (&fe->remove_mutex); -if (fe->exit !=DVB_FE_DEVICE_REMOVED ) fe->exit =DVB_FE_NORMAL_EXIT ;mb (); -if (!fepriv->thread) { -mutex_unlock (&fe->remove_mutex); +if (!fepriv->thread)return ; - }kthread_stop (fepriv->thread); -mutex_unlock (&fe->remove_mutex); - -if (fepriv->dvbdev->users <-1 ) { -wait_event (fepriv->dvbdev->wait_queue, - fepriv->dvbdev->users ==-1 ); - } -sema_init (&fepriv->sem,1 ); fepriv->state =FESTATE_IDLE ;
@@ -2780,13 +2769,9 @@ static int dvb_frontend_open(struct inode *inode, struct file *file)struct dvb_adapter *adapter = fe->dvb;int ret; -mutex_lock (&fe->remove_mutex); -dev_dbg (fe->dvb->device,"%s:\n" , __func__); -if (fe->exit ==DVB_FE_DEVICE_REMOVED ) { - ret = -ENODEV ; - goto err_remove_mutex; - } +if (fe->exit ==DVB_FE_DEVICE_REMOVED ) +return -ENODEV ;if (adapter->mfe_shared ==2 ) {mutex_lock (&adapter->mfe_lock);
@@ -2794,8 +2779,7 @@ static int dvb_frontend_open(struct inode *inode, struct file *file)if (adapter->mfe_dvbdev && !adapter->mfe_dvbdev->writers) {mutex_unlock (&adapter->mfe_lock); - ret = -EBUSY ; - goto err_remove_mutex; +return -EBUSY ; } adapter->mfe_dvbdev = dvbdev; }
@@ -2818,10 +2802,8 @@ static int dvb_frontend_open(struct inode *inode, struct file *file)while (mferetry-- && (mfedev->users !=-1 || mfepriv->thread)) {if (msleep_interruptible (500 )) { -if (signal_pending (current)) { - ret = -EINTR ; - goto err_remove_mutex; - } +if (signal_pending (current)) +return -EINTR ; } }
@@ -2833,8 +2815,7 @@ static int dvb_frontend_open(struct inode *inode, struct file *file)if (mfedev->users !=-1 || mfepriv->thread) {mutex_unlock (&adapter->mfe_lock); - ret = -EBUSY ; - goto err_remove_mutex; +return -EBUSY ; } adapter->mfe_dvbdev = dvbdev; }
@@ -2893,8 +2874,6 @@ static int dvb_frontend_open(struct inode *inode, struct file *file)if (adapter->mfe_shared)mutex_unlock (&adapter->mfe_lock); - -mutex_unlock (&fe->remove_mutex);return ret; err3:
@@ -2916,9 +2895,6 @@ static int dvb_frontend_open(struct inode *inode, struct file *file) err0:if (adapter->mfe_shared)mutex_unlock (&adapter->mfe_lock); - -err_remove_mutex: -mutex_unlock (&fe->remove_mutex);return ret; }
@@ -2929,8 +2905,6 @@ static int dvb_frontend_release(struct inode *inode, struct file *file)struct dvb_frontend_private *fepriv = fe->frontend_priv;int ret; -mutex_lock (&fe->remove_mutex); -dev_dbg (fe->dvb->device,"%s:\n" , __func__);if ((file->f_flags &O_ACCMODE ) !=O_RDONLY ) {
@@ -2952,18 +2926,10 @@ static int dvb_frontend_release(struct inode *inode, struct file *file) }mutex_unlock (&fe->dvb->mdev_lock);#endif +if (fe->exit !=DVB_FE_NO_EXIT ) +wake_up (&dvbdev->wait_queue);if (fe->ops.ts_bus_ctrl) fe->ops.ts_bus_ctrl (fe,0 ); - -if (fe->exit !=DVB_FE_NO_EXIT ) { -mutex_unlock (&fe->remove_mutex); -wake_up (&dvbdev->wait_queue); - }else { -mutex_unlock (&fe->remove_mutex); - } - - }else { -mutex_unlock (&fe->remove_mutex); }dvb_frontend_put (fe);
@@ -3064,7 +3030,6 @@ int dvb_register_frontend(struct dvb_adapter *dvb, fepriv = fe->frontend_priv;kref_init (&fe->refcount); -mutex_init (&fe->remove_mutex);/* * After initialization, there need to be two references: one
include/media/dvb_frontend.h +1 -5
@@ -686,10 +686,7 @@ struct dtv_frontend_properties {* @id: Frontend ID * @exit: Used to inform the DVB core that the frontend * thread should exit (usually, means that the hardware -* got disconnected). -* @remove_mutex: mutex that avoids a race condition between a callback -* called when the hardware is disconnected and the -* file_operations of dvb_frontend. +* got disconnected. */ struct dvb_frontend {
@@ -707,7 +704,6 @@ struct dvb_frontend {int (*callback)(void *adapter_priv,int component,int cmd,int arg);int id;unsigned int exit; -struct mutex remove_mutex; };/**
Signature · 1 line
2.39.2
Greg Kroah-Hartman
maintainerPATCH 171/187 ext4: drop the call to ext4_error() from ext4_get_group_info()
In reply to Greg Kroah-HartmanFrom: Fabio M. De Francesco <[email protected]>
[ Upstream commit f451fd97dd2b78f286379203a47d9d295c467255 ]
A recent patch added a call to ext4_error() which is problematic since some callers of the ext4_get_group_info() function may be holding a spinlock, whereas ext4_error() must never be called in atomic context.
This triggered a report from Syzbot: "BUG: sleeping function called from invalid context in ext4_update_super" (see the link below).
Therefore, drop the call to ext4_error() from ext4_get_group_info(). In the meantime use eight characters tabs instead of nine characters ones.
--- fs/ext4/balloc.c | 20 +++++++++----------- 1 file changed, 9 insertions(+), 11 deletions(-)
fs/ext4/balloc.c +9 -11
@@ -322,17 +322,15 @@ static ext4_fsblk_t ext4_valid_block_bitmap_padding(struct super_block *sb,struct ext4_group_info *ext4_get_group_info (struct super_block *sb,ext4_group_t group) { -struct ext4_group_info **grp_info; -long indexv, indexh; - -if (unlikely (group >=EXT4_SB (sb)->s_groups_count)) { -ext4_error (sb,"invalid group %u" , group); -return NULL ; - } - indexv = group >> (EXT4_DESC_PER_BLOCK_BITS (sb)); - indexh = group & ((EXT4_DESC_PER_BLOCK (sb)) -1 ); - grp_info =sbi_array_rcu_deref (EXT4_SB (sb), s_group_info, indexv); -return grp_info[indexh]; +struct ext4_group_info **grp_info; +long indexv, indexh; + +if (unlikely (group >=EXT4_SB (sb)->s_groups_count)) +return NULL ; + indexv = group >> (EXT4_DESC_PER_BLOCK_BITS (sb)); + indexh = group & ((EXT4_DESC_PER_BLOCK (sb)) -1 ); + grp_info =sbi_array_rcu_deref (EXT4_SB (sb), s_group_info, indexv); +return grp_info[indexh]; }/*
Signature · 1 line
2.39.2
Greg Kroah-Hartman
maintainerPATCH 172/187 ice: Fix ice module unload
In reply to Greg Kroah-HartmanFrom: Jakub Buchocki <[email protected]>
[ Upstream commit 24b454bc354ab7b1aa918a4fe3d7696516f592d4 ]
Clearing the interrupt scheme before PFR reset, during the removal routine, could cause the hardware errors and possibly lead to system reboot, as the PF reset can cause the interrupt to be generated.
Place the call for PFR reset inside ice_deinit_dev(), wait until reset and all pending transactions are done, then call ice_clear_interrupt_scheme().
This introduces a PFR reset to multiple error paths.
Additionally, remove the call for the reset from ice_load() - it will be a part of ice_unload() now.
Error example:
[ 75.229328] ice 0000:ca:00.1: Failed to read Tx Scheduler Tree - User Selection data from flash
[ 77.571315] {1}[Hardware Error]: Hardware error from APEI Generic Hardware Error Source: 1
[ 77.571418] {1}[Hardware Error]: event severity: recoverable
[ 77.571459] {1}[Hardware Error]: Error 0, type: recoverable
[ 77.571500] {1}[Hardware Error]: section_type: PCIe error
[ 77.571540] {1}[Hardware Error]: port_type: 4, root port
[ 77.571580] {1}[Hardware Error]: version: 3.0
[ 77.571615] {1}[Hardware Error]: command: 0x0547, status: 0x4010
[ 77.571661] {1}[Hardware Error]: device_id: 0000:c9:02.0
[ 77.571703] {1}[Hardware Error]: slot: 25
[ 77.571736] {1}[Hardware Error]: secondary_bus: 0xca
[ 77.571773] {1}[Hardware Error]: vendor_id: 0x8086, device_id: 0x347a
[ 77.571821] {1}[Hardware Error]: class_code: 060400
[ 77.571858] {1}[Hardware Error]: bridge: secondary_status: 0x2800, control: 0x0013
[ 77.572490] pcieport 0000:c9:02.0: AER: aer_status: 0x00200000, aer_mask: 0x00100020
[ 77.572870] pcieport 0000:c9:02.0: [21] ACSViol (First)
[ 77.573222] pcieport 0000:c9:02.0: AER: aer_layer=Transaction Layer, aer_agent=Receiver ID
[ 77.573554] pcieport 0000:c9:02.0: AER: aer_uncor_severity: 0x00463010
[ 77.691273] {2}[Hardware Error]: Hardware error from APEI Generic Hardware Error Source: 1
[ 77.691738] {2}[Hardware Error]: event severity: recoverable
[ 77.691971] {2}[Hardware Error]: Error 0, type: recoverable
[ 77.692192] {2}[Hardware Error]: section_type: PCIe error
[ 77.692403] {2}[Hardware Error]: port_type: 4, root port
[ 77.692616] {2}[Hardware Error]: version: 3.0
[ 77.692825] {2}[Hardware Error]: command: 0x0547, status: 0x4010
[ 77.693032] {2}[Hardware Error]: device_id: 0000:c9:02.0
[ 77.693238] {2}[Hardware Error]: slot: 25
[ 77.693440] {2}[Hardware Error]: secondary_bus: 0xca
[ 77.693641] {2}[Hardware Error]: vendor_id: 0x8086, device_id: 0x347a
[ 77.693853] {2}[Hardware Error]: class_code: 060400
[ 77.694054] {2}[Hardware Error]: bridge: secondary_status: 0x0800, control: 0x0013
[ 77.719115] pci 0000:ca:00.1: AER: can't recover (no error_detected callback)
[ 77.719140] pcieport 0000:c9:02.0: AER: device recovery failed
[ 77.719216] pcieport 0000:c9:02.0: AER: aer_status: 0x00200000, aer_mask: 0x00100020
[ 77.719390] pcieport 0000:c9:02.0: [21] ACSViol (First)
[ 77.719557] pcieport 0000:c9:02.0: AER: aer_layer=Transaction Layer, aer_agent=Receiver ID
[ 77.719723] pcieport 0000:c9:02.0: AER: aer_uncor_severity: 0x00463010--- drivers/net/ethernet/intel/ice/ice_main.c | 16 +++++----------- 1 file changed, 5 insertions(+), 11 deletions(-)
drivers/net/ethernet/intel/ice/ice_main.c +5 -11
@@ -4794,9 +4794,13 @@ static int ice_init_dev(struct ice_pf *pf)static void ice_deinit_dev (struct ice_pf *pf) {ice_free_irq_msix_misc (pf); -ice_clear_interrupt_scheme (pf);ice_deinit_pf (pf);ice_deinit_hw (&pf->hw); + +/* Service task is already stopped, so call reset directly. */ +ice_reset (&pf->hw,ICE_RESET_PFR ); +pci_wait_for_pending_transaction (pf->pdev); +ice_clear_interrupt_scheme (pf); }static void ice_init_features (struct ice_pf *pf)
@@ -5086,10 +5090,6 @@ int ice_load(struct ice_pf *pf)struct ice_vsi *vsi;int err; - err =ice_reset (&pf->hw,ICE_RESET_PFR ); -if (err) -return err; - err =ice_init_dev (pf);if (err)return err;
@@ -5346,12 +5346,6 @@ static void ice_remove(struct pci_dev *pdev)ice_setup_mc_magic_wake (pf);ice_set_wake (pf); -/* Issue a PFR as part of the prescribed driver unload flow. Do not -* do it via ice_schedule_reset() since there is no need to rebuild -* and the service task is already stopped. -*/ -ice_reset (&pf->hw,ICE_RESET_PFR ); -pci_wait_for_pending_transaction (pdev);pci_disable_device (pdev); }
Signature · 1 line
2.39.2
Greg Kroah-Hartman
maintainerPATCH 173/187 net/sched: cls_api: Fix lockup on flushing explicitly created chain
In reply to Greg Kroah-HartmanFrom: Vlad Buslov <[email protected]>
[ Upstream commit c9a82bec02c339cdda99b37c5e62b3b71fc4209c ]
Mingshuai Ren reports:
When a new chain is added by using tc, one soft lockup alarm will be
generated after delete the prio 0 filter of the chain. To reproduce the problem, perform the following steps:
(1) tc qdisc add dev eth0 root handle 1: htb default 1
(2) tc chain add dev eth0
(3) tc filter del dev eth0 chain 0 parent 1: prio 0
(4) tc filter add dev eth0 chain 0 parent 1:
Fix the issue by accounting for additional reference to chains that are explicitly created by RTM_NEWCHAIN message as opposed to implicitly by RTM_NEWTFILTER message.
--- net/sched/cls_api.c | 12 +++++++----- 1 file changed, 7 insertions(+), 5 deletions(-)
net/sched/cls_api.c +7 -5
@@ -657,8 +657,8 @@ static void __tcf_chain_put(struct tcf_chain *chain, bool by_act, {struct tcf_block *block = chain->block;const struct tcf_proto_ops *tmplt_ops; +unsigned int refcnt, non_act_refcnt;bool free_block = false; -unsigned int refcnt;void *tmplt_priv;mutex_lock (&block->lock);
@@ -678,13 +678,15 @@ static void __tcf_chain_put(struct tcf_chain *chain, bool by_act,* save these to temporary variables. */ refcnt = --chain->refcnt; + non_act_refcnt = refcnt - chain->action_refcnt; tmplt_ops = chain->tmplt_ops; tmplt_priv = chain->tmplt_priv; -/* The last dropped non-action reference will trigger notification. */ -if (refcnt - chain->action_refcnt ==0 && !by_act) { -tc_chain_notify_delete (tmplt_ops, tmplt_priv, chain->index, - block,NULL ,0 ,0 , false); +if (non_act_refcnt == chain->explicitly_created && !by_act) { +if (non_act_refcnt ==0 ) +tc_chain_notify_delete (tmplt_ops, tmplt_priv, + chain->index, block,NULL ,0 ,0 , + false);/* Last reference to chain, no need to lock. */ chain->flushing = false; }
Signature · 1 line
2.39.2
Greg Kroah-Hartman
maintainerPATCH 174/187 net: dsa: felix: fix taprio guard band overflow at 10Mbps with jumbo frames
In reply to Greg Kroah-HartmanFrom: Vladimir Oltean <[email protected]>
[ Upstream commit 6ac7a27a8b07588497ed53dfd885df9c72bc67e0 ]
The DEV_MAC_MAXLEN_CFG register contains a 16-bit value - up to 65535. Plus 2 * VLAN_HLEN (4), that is up to 65543.
The picos_per_byte variable is the largest when "speed" is lowest - SPEED_10 = 10. In that case it is (1000000L * 8) / 10 = 800000.
Their product - 52434400000 - exceeds 32 bits, which is a problem, because apparently, a multiplication between two 32-bit factors is evaluated as 32-bit before being assigned to a 64-bit variable. In fact it's a problem for any MTU value larger than 5368.
Cast one of the factors of the multiplication to u64 to force the multiplication to take place on 64 bits.
Issue found by Coverity.
--- drivers/net/dsa/ocelot/felix_vsc9959.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/net/dsa/ocelot/felix_vsc9959.c +1 -1
@@ -1263,7 +1263,7 @@ static void vsc9959_tas_guard_bands_update(struct ocelot *ocelot, int port)/* Consider the standard Ethernet overhead of 8 octets preamble+SFD, * 4 octets FCS, 12 octets IFG. */ - needed_bit_time_ps = (maxlen +24 ) * picos_per_byte; + needed_bit_time_ps = (u64)(maxlen +24 ) * picos_per_byte; dev_dbg(ocelot->dev, "port %d: max frame size %d needs %llu ps at speed %d\n",
Signature · 1 line
2.39.2
Greg Kroah-Hartman
maintainerPATCH 175/187 net: lapbether: only support ethernet devices
In reply to Greg Kroah-HartmanFrom: Eric Dumazet <[email protected]>
[ Upstream commit 9eed321cde22fc1afd76eac563ce19d899e0d6b2 ]
It probbaly makes no sense to support arbitrary network devices for lapbether.
syzbot reported:
skbuff: skb_under_panic: text:ffff80008934c100 len:44 put:40 head:ffff0000d18dd200 data:ffff0000d18dd1ea tail:0x16 end:0x140 dev:bond1 kernel BUG at net/core/skbuff.c:200 !
Internal error: Oops - BUG: 00000000f2000800 [#1] PREEMPT SMP Modules linked in: CPU: 0 PID: 5643 Comm: dhcpcd Not tainted 6.4.0-rc5-syzkaller-g4641cff8e810 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 05/25/2023 pstate: 60400005 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : skb_panic net/core/skbuff.c:196 [inline] pc : skb_under_panic+0x13c/0x140 net/core/skbuff.c:210 lr : skb_panic net/core/skbuff.c:196 [inline] lr : skb_under_panic+0x13c/0x140 net/core/skbuff.c:210
sp : ffff8000973b7260
x29: ffff8000973b7270 x28: ffff8000973b7360 x27: dfff800000000000
x26: ffff0000d85d8150 x25: 0000000000000016 x24: ffff0000d18dd1ea
x23: ffff0000d18dd200 x22: 000000000000002c x21: 0000000000000140
x20: 0000000000000028 x19: ffff80008934c100 x18: ffff8000973b68a0
x17: 0000000000000000 x16: ffff80008a43bfbc x15: 0000000000000202
x14: 0000000000000000 x13: 0000000000000001 x12: 0000000000000001
x11: 0000000000000201 x10: 0000000000000000 x9 : f22f7eb937cced00 x8 : f22f7eb937cced00 x7 : 0000000000000001 x6 : 0000000000000001 x5 : ffff8000973b6b78 x4 : ffff80008df9ee80 x3 : ffff8000805974f4 x2 : 0000000000000001 x1 : 0000000100000201 x0 : 0000000000000086
Call trace: skb_panic net/core/skbuff.c:196 [inline] skb_under_panic+0x13c/0x140 net/core/skbuff.c:210 skb_push+0xf0/0x108 net/core/skbuff.c:2409 ip6gre_header+0xbc/0x738 net/ipv6/ip6_gre.c:1383 dev_hard_header include/linux/netdevice.h:3137 [inline] lapbeth_data_transmit+0x1c4/0x298 drivers/net/wan/lapbether.c:257 lapb_data_transmit+0x8c/0xb0 net/lapb/lapb_iface.c:447 lapb_transmit_buffer+0x178/0x204 net/lapb/lapb_out.c:149 lapb_send_control+0x220/0x320 net/lapb/lapb_subr.c:251 lapb_establish_data_link+0x94/0xec lapb_device_event+0x348/0x4e0 notifier_call_chain+0x1a4/0x510 kernel/notifier.c:93 raw_notifier_call_chain+0x3c/0x50 kernel/notifier.c:461 __dev_notify_flags+0x2bc/0x544 dev_change_flags+0xd0/0x15c net/core/dev.c:8643 devinet_ioctl+0x858/0x17e4 net/ipv4/devinet.c:1150 inet_ioctl+0x2ac/0x4d8 net/ipv4/af_inet.c:979 sock_do_ioctl+0x134/0x2dc net/socket.c:1201 sock_ioctl+0x4ec/0x858 net/socket.c:1318 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:870 [inline] __se_sys_ioctl fs/ioctl.c:856 [inline] __arm64_sys_ioctl+0x14c/0x1c8 fs/ioctl.c:856 __invoke_syscall arch/arm64/kernel/syscall.c:38 [inline] invoke_syscall+0x98/0x2c0 arch/arm64/kernel/syscall.c:52 el0_svc_common+0x138/0x244 arch/arm64/kernel/syscall.c:142 do_el0_svc+0x64/0x198 arch/arm64/kernel/syscall.c:191 el0_svc+0x4c/0x160 arch/arm64/kernel/entry-common.c:647 el0t_64_sync_handler+0x84/0xfc arch/arm64/kernel/entry-common.c:665 el0t_64_sync+0x190/0x194 arch/arm64/kernel/entry.S:591 Code: aa1803e6 aa1903e7 a90023f5 947730f5 (d4210000)
--- drivers/net/wan/lapbether.c | 3 +++ 1 file changed, 3 insertions(+)
drivers/net/wan/lapbether.c +3 -0
@@ -384,6 +384,9 @@ static int lapbeth_new_device(struct net_device *dev)ASSERT_RTNL (); +if (dev->type !=ARPHRD_ETHER ) +return -EINVAL ; + ndev =alloc_netdev (sizeof (*lapbeth),"lapb%d" ,NET_NAME_UNKNOWN , lapbeth_setup);if (!ndev)
Signature · 1 line
2.39.2
Greg Kroah-Hartman
maintainerPATCH 176/187 net: macsec: fix double free of percpu stats
In reply to Greg Kroah-HartmanFrom: Fedor Pchelkin <[email protected]>
[ Upstream commit 0c0cf3db83f8c7c9bb141c2771a34043bcf952ef ]
Inside macsec_add_dev() we free percpu macsec->secy.tx_sc.stats and macsec->stats on some of the memory allocation failure paths. However, the net_device is already registered to that moment: in macsec_newlink(), just before calling macsec_add_dev(). This means that during unregister process its priv_destructor - macsec_free_netdev() - will be called and will free the stats again.
Remove freeing percpu stats inside macsec_add_dev() because macsec_free_netdev() will correctly free the already allocated ones. The pointers to unallocated stats stay NULL, and free_percpu() treats that correctly.
Found by Linux Verification Center (linuxtesting.org) with Syzkaller.
--- drivers/net/macsec.c | 12 +++++------- 1 file changed, 5 insertions(+), 7 deletions(-)
drivers/net/macsec.c +5 -7
@@ -3987,17 +3987,15 @@ static int macsec_add_dev(struct net_device *dev, sci_t sci, u8 icv_len)return -ENOMEM ; secy->tx_sc.stats = netdev_alloc_pcpu_stats(struct pcpu_tx_sc_stats); -if (!secy->tx_sc.stats) { -free_percpu (macsec->stats); +if (!secy->tx_sc.stats)return -ENOMEM ; - } secy->tx_sc.md_dst =metadata_dst_alloc (0 ,METADATA_MACSEC ,GFP_KERNEL ); -if (!secy->tx_sc.md_dst) { -free_percpu (secy->tx_sc.stats); -free_percpu (macsec->stats); +if (!secy->tx_sc.md_dst) +/* macsec and secy percpu stats will be freed when unregistering +* net_device in macsec_free_netdev() +*/ return -ENOMEM ; - }if (sci ==MACSEC_UNDEF_SCI ) sci =dev_to_sci (dev,MACSEC_PORT_ES );
Signature · 1 line
2.39.2
Greg Kroah-Hartman
maintainerPATCH 177/187 sfc: fix XDP queues mode with legacy IRQ
In reply to Greg Kroah-HartmanFrom: Íñigo Huguet <[email protected]>
[ Upstream commit e84a1e1e683f3558e30f437d7c99df35afb8b52c ]
In systems without MSI-X capabilities, xdp_txq_queues_mode is calculated in efx_allocate_msix_channels, but when enabling MSI-X fails, it was not changed to a proper default value. This was leading to the driver thinking that it has dedicated XDP queues, when it didn't.
Fix it by setting xdp_txq_queues_mode to the correct value if the driver fallbacks to MSI or legacy IRQ mode. The correct value is EFX_XDP_TX_QUEUES_BORROWED because there are no XDP dedicated queues.
The issue can be easily visible if the kernel is started with pci=nomsi, then a call trace is shown. It is not shown only with sfc's modparam interrupt_mode=2. Call trace example:
WARNING: CPU: 2 PID: 663 at drivers/net/ethernet/sfc/efx_channels.c:828 efx_set_xdp_channels+0x124/0x260 [sfc] [...skip...] Call Trace: <TASK> efx_set_channels+0x5c/0xc0 [sfc] efx_probe_nic+0x9b/0x15a [sfc] efx_probe_all+0x10/0x1a2 [sfc] efx_pci_probe_main+0x12/0x156 [sfc] efx_pci_probe_post_io+0x18/0x103 [sfc] efx_pci_probe.cold+0x154/0x257 [sfc] local_pci_probe+0x42/0x80
--- drivers/net/ethernet/sfc/efx_channels.c | 2 ++ drivers/net/ethernet/sfc/siena/efx_channels.c | 2 ++ 2 files changed, 4 insertions(+)
drivers/net/ethernet/sfc/efx_channels.c +2 -0
@@ -301,6 +301,7 @@ int efx_probe_interrupts(struct efx_nic *efx) efx->tx_channel_offset =0 ; efx->n_xdp_channels =0 ; efx->xdp_channel_offset = efx->n_channels; + efx->xdp_txq_queues_mode =EFX_XDP_TX_QUEUES_BORROWED ; rc =pci_enable_msi (efx->pci_dev);if (rc ==0 ) {efx_get_channel (efx,0 )->irq = efx->pci_dev->irq;
@@ -322,6 +323,7 @@ int efx_probe_interrupts(struct efx_nic *efx) efx->tx_channel_offset = efx_separate_tx_channels ?1 :0 ; efx->n_xdp_channels =0 ; efx->xdp_channel_offset = efx->n_channels; + efx->xdp_txq_queues_mode =EFX_XDP_TX_QUEUES_BORROWED ; efx->legacy_irq = efx->pci_dev->irq; }
drivers/net/ethernet/sfc/siena/efx_channels.c +2 -0
@@ -302,6 +302,7 @@ int efx_siena_probe_interrupts(struct efx_nic *efx) efx->tx_channel_offset =0 ; efx->n_xdp_channels =0 ; efx->xdp_channel_offset = efx->n_channels; + efx->xdp_txq_queues_mode =EFX_XDP_TX_QUEUES_BORROWED ; rc =pci_enable_msi (efx->pci_dev);if (rc ==0 ) {efx_get_channel (efx,0 )->irq = efx->pci_dev->irq;
@@ -323,6 +324,7 @@ int efx_siena_probe_interrupts(struct efx_nic *efx) efx->tx_channel_offset = efx_siena_separate_tx_channels ?1 :0 ; efx->n_xdp_channels =0 ; efx->xdp_channel_offset = efx->n_channels; + efx->xdp_txq_queues_mode =EFX_XDP_TX_QUEUES_BORROWED ; efx->legacy_irq = efx->pci_dev->irq; }
Signature · 1 line
2.39.2
Greg Kroah-Hartman
maintainerPATCH 178/187 dm: dont lock fs when the map is NULL during suspend or resume
In reply to Greg Kroah-HartmanFrom: Li Lingfeng <[email protected]>
[ Upstream commit 2760904d895279f87196f0fa9ec570c79fe6a2e4 ]
As described in commit 38d11da522aa ("dm: don't lock fs when the map is NULL in process of resume"), a deadlock may be triggered between do_resume() and do_mount().
This commit preserves the fix from commit 38d11da522aa but moves it to where it also serves to fix a similar deadlock between do_suspend() and do_mount(). It does so, if the active map is NULL, by clearing DM_SUSPEND_LOCKFS_FLAG in dm_suspend() which is called by both do_suspend() and do_resume().
--- drivers/md/dm-ioctl.c | 5 +---- drivers/md/dm.c | 4 ++++ 2 files changed, 5 insertions(+), 4 deletions(-)
drivers/md/dm-ioctl.c +1 -4
@@ -1168,13 +1168,10 @@ static int do_resume(struct dm_ioctl *param)/* Do we need to load a new map ? */ if (new_map) {sector_t old_size, new_size; -int srcu_idx;/* Suspend if it isn't already suspended */ - old_map =dm_get_live_table (md, &srcu_idx); -if ((param->flags &DM_SKIP_LOCKFS_FLAG ) || !old_map) +if (param->flags &DM_SKIP_LOCKFS_FLAG ) suspend_flags &= ~DM_SUSPEND_LOCKFS_FLAG ; -dm_put_live_table (md, srcu_idx);if (param->flags &DM_NOFLUSH_FLAG ) suspend_flags |=DM_SUSPEND_NOFLUSH_FLAG ;if (!dm_suspended_md (md))
drivers/md/dm.c +4 -0
@@ -2795,6 +2795,10 @@ int dm_suspend(struct mapped_device *md, unsigned int suspend_flags) } map =rcu_dereference_protected (md->map,lockdep_is_held (&md->suspend_lock)); +if (!map) { +/* avoid deadlock with fs/namespace.c:do_mount() */ + suspend_flags &= ~DM_SUSPEND_LOCKFS_FLAG ; + } r =__dm_suspend (md, map, suspend_flags,TASK_INTERRUPTIBLE ,DMF_SUSPENDED );if (r)
Signature · 1 line
2.39.2
Greg Kroah-Hartman
maintainerPATCH 179/187 net: tipc: resize nlattr array to correct size
In reply to Greg Kroah-HartmanFrom: Lin Ma <[email protected]>
[ Upstream commit 44194cb1b6045dea33ae9a0d54fb7e7cd93a2e09 ]
According to nla_parse_nested_deprecated(), the tb[] is supposed to the destination array with maxtype+1 elements. In current tipc_nl_media_get() and __tipc_nl_media_set(), a larger array is used which is unnecessary. This patch resize them to a proper size.
--- net/tipc/bearer.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
net/tipc/bearer.c +2 -2
@@ -1258,7 +1258,7 @@ int tipc_nl_media_get(struct sk_buff *skb, struct genl_info *info)struct tipc_nl_msg msg;struct tipc_media *media;struct sk_buff *rep; -struct nlattr *attrs[TIPC_NLA_BEARER_MAX +1 ]; +struct nlattr *attrs[TIPC_NLA_MEDIA_MAX +1 ];if (!info->attrs[TIPC_NLA_MEDIA ])return -EINVAL ;
@@ -1307,7 +1307,7 @@ int __tipc_nl_media_set(struct sk_buff *skb, struct genl_info *info)int err;char *name;struct tipc_media *m; -struct nlattr *attrs[TIPC_NLA_BEARER_MAX +1 ]; +struct nlattr *attrs[TIPC_NLA_MEDIA_MAX +1 ];if (!info->attrs[TIPC_NLA_MEDIA ])return -EINVAL ;
Signature · 1 line
2.39.2
Greg Kroah-Hartman
maintainerPATCH 180/187 selftests/ptp: Fix timestamp printf format for PTP_SYS_OFFSET
In reply to Greg Kroah-HartmanFrom: Alex Maftei <[email protected]>
[ Upstream commit 76a4c8b82938bc5020b67663db41f451684bf327 ]
Previously, timestamps were printed using "%lld.%u" which is incorrect for nanosecond values lower than 100,000,000 as they're fractional digits, therefore leading zeros are meaningful.
This patch changes the format strings to "%lld.%09u" in order to add leading zeros to the nanosecond value.
--- tools/testing/selftests/ptp/testptp.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-)
tools/testing/selftests/ptp/testptp.c +3 -3
@@ -502,11 +502,11 @@ int main(int argc, char *argv[]) interval = t2 - t1; offset = (t2 + t1) /2 - tp; -printf ("system time: %lld.%u\n" , +printf ("system time: %lld.%09u\n" , (pct+2 *i)->sec, (pct+2 *i)->nsec); -printf ("phc time: %lld.%u\n" , +printf ("phc time: %lld.%09u\n" , (pct+2 *i+1 )->sec, (pct+2 *i+1 )->nsec); -printf ("system time: %lld.%u\n" , +printf ("system time: %lld.%09u\n" , (pct+2 *i+2 )->sec, (pct+2 *i+2 )->nsec); printf("system/phc clock time offset is %" PRId64 " ns\n" "system clock time delay is %" PRId64 " ns\n",
Signature · 1 line
2.39.2
Greg Kroah-Hartman
maintainerPATCH 181/187 octeon_ep: Add missing check for ioremap
In reply to Greg Kroah-HartmanFrom: Jiasheng Jiang <[email protected]>
[ Upstream commit 9a36e2d44d122fe73a2a76ba73f1d50a65cf8210 ]
Add check for ioremap() and return the error if it fails in order to guarantee the success of ioremap().
--- drivers/net/ethernet/marvell/octeon_ep/octep_main.c | 7 ++++++- 1 file changed, 6 insertions(+), 1 deletion(-)
drivers/net/ethernet/marvell/octeon_ep/octep_main.c +6 -1
@@ -941,6 +941,9 @@ int octep_device_setup(struct octep_device *oct) oct->mmio[i].hw_addr =ioremap (pci_resource_start (oct->pdev, i *2 ),pci_resource_len (oct->pdev, i *2 )); +if (!oct->mmio[i].hw_addr) + goto unmap_prev; + oct->mmio[i].mapped =1 ; }
@@ -980,7 +983,9 @@ int octep_device_setup(struct octep_device *oct)return 0 ; unsupported_dev: -for (i =0 ; i <OCTEP_MMIO_REGIONS ; i++) + i =OCTEP_MMIO_REGIONS ; +unmap_prev: +while (i--)iounmap (oct->mmio[i].hw_addr);kfree (oct->conf);
Signature · 1 line
2.39.2
Greg Kroah-Hartman
maintainerPATCH 182/187 afs: Fix vlserver probe RTT handling
In reply to Greg Kroah-HartmanFrom: David Howells <[email protected]>
[ Upstream commit ba00b190670809c1a89326d80de96d714f6004f2 ]
In the same spirit as commit ca57f02295f1 ("afs: Fix fileserver probe RTT handling"), don't rule out using a vlserver just because there haven't been enough packets yet to calculate a real rtt. Always set the server's probe rtt from the estimate provided by rxrpc_kernel_get_srtt, which is capped at 1 second.
This could lead to EDESTADDRREQ errors when accessing a cell for the first time, even though the vl servers are known and have responded to a probe.
--- fs/afs/vl_probe.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
fs/afs/vl_probe.c +2 -2
@@ -115,8 +115,8 @@ void afs_vlserver_probe_result(struct afs_call *call) } } -if (rxrpc_kernel_get_srtt (call->net->socket, call->rxcall, &rtt_us) && - rtt_us < server->probe.rtt) { +rxrpc_kernel_get_srtt (call->net->socket, call->rxcall, &rtt_us); +if (rtt_us < server->probe.rtt) { server->probe.rtt = rtt_us; server->rtt = rtt_us; alist->preferred = index;
Signature · 1 line
2.39.2
Greg Kroah-Hartman
maintainerPATCH 183/187 parisc: Delete redundant register definitions in <asm/assembly.h>
In reply to Greg Kroah-HartmanFrom: Ben Hutchings <[email protected]>
commit b5b2a02bcaac7c287694aa0db4837a07bf178626 upstream.
We define sp and ipsw in <asm/asmregs.h> using ".reg", and when using current binutils (snapshot 2.40.50.20230611) the definitions in <asm/assembly.h> using "=" conflict with those:
arch/parisc/include/asm/assembly.h: Assembler messages:arch/parisc/include/asm/assembly.h:93: Error: symbol sp' is already defined arch/parisc/include/asm/assembly.h:95: Error: symbol ipsw' is already defined
Delete the duplicate definitions in <asm/assembly.h>.
Also delete the definition of gp, which isn't used anywhere.
--- arch/parisc/include/asm/assembly.h | 4 ---- 1 file changed, 4 deletions(-)
arch/parisc/include/asm/assembly.h +0 -4
@@ -90,10 +90,6 @@#include <asm/asmregs.h> #include <asm/psw.h> - sp = 30 - gp = 27 - ipsw =22 -/* * We provide two versions of each macro to convert from physical * to virtual and vice versa. The "_r1" versions take one argument
Greg Kroah-Hartman
maintainerPATCH 184/187 arm64: dts: qcom: sm8550: Use the correct LLCC register scheme
In reply to Greg Kroah-HartmanFrom: Konrad Dybcio <[email protected]>
commit 661a4f089317c877aecd598fb70cd46510cc8d29 upstream.
During the ABI-breaking (for good reasons) conversion of the LLCC register description, SM8550 was not taken into account, resulting in LLCC being broken on any kernel containing the patch referenced in the fixes tag.
Fix it by describing the regions properly.
--- arch/arm64/boot/dts/qcom/sm8550.dtsi | 11 +++++++++-- 1 file changed, 9 insertions(+), 2 deletions(-)
arch/arm64/boot/dts/qcom/sm8550.dtsi +9 -2
@@ -3423,9 +3423,16 @@ system-cache-controller@25000000 { compatible = "qcom,sm8550-llcc"; - reg = <0 0x25000000 0 0x800000>, + reg = <0 0x25000000 0 0x200000>, + <0 0x25200000 0 0x200000>, + <0 0x25400000 0 0x200000>, + <0 0x25600000 0 0x200000>, <0 0x25800000 0 0x200000>; - reg-names = "llcc_base", "llcc_broadcast_base"; + reg-names = "llcc0_base", + "llcc1_base", + "llcc2_base", + "llcc3_base", + "llcc_broadcast_base"; interrupts = <GIC_SPI 266 IRQ_TYPE_LEVEL_HIGH>; };
Greg Kroah-Hartman
maintainerPATCH 185/187 neighbour: delete neigh_lookup_nodev as not used
In reply to Greg Kroah-HartmanFrom: Leon Romanovsky <[email protected]>
commit 76b9bf965c98c9b53ef7420b3b11438dbd764f92 upstream.
neigh_lookup_nodev isn't used in the kernel after removal of DECnet. So let's remove it.
--- include/net/neighbour.h | 2 -- net/core/neighbour.c | 31 ------------------------------- 2 files changed, 33 deletions(-)
include/net/neighbour.h +0 -2
@@ -336,8 +336,6 @@ void neigh_table_init(int index, structint neigh_table_clear (int index,struct neigh_table *tbl);struct neighbour *neigh_lookup (struct neigh_table *tbl,const void *pkey,struct net_device *dev); -struct neighbour *neigh_lookup_nodev (struct neigh_table *tbl,struct net *net, -const void *pkey);struct neighbour *__neigh_create (struct neigh_table *tbl,const void *pkey,struct net_device *dev,bool want_ref); static inline struct neighbour *neigh_create(struct neigh_table *tbl,
net/core/neighbour.c +0 -31
@@ -627,37 +627,6 @@ struct neighbour *neigh_lookup(struct ne }EXPORT_SYMBOL (neigh_lookup); -struct neighbour *neigh_lookup_nodev (struct neigh_table *tbl,struct net *net, -const void *pkey) -{ -struct neighbour *n; -unsigned int key_len = tbl->key_len; -u32 hash_val; -struct neigh_hash_table *nht; - -NEIGH_CACHE_STAT_INC (tbl, lookups); - -rcu_read_lock_bh (); - nht =rcu_dereference_bh (tbl->nht); - hash_val = tbl->hash (pkey,NULL , nht->hash_rnd) >> (32 - nht->hash_shift); - -for (n =rcu_dereference_bh (nht->hash_buckets[hash_val]); - n !=NULL ; - n =rcu_dereference_bh (n->next)) { -if (!memcmp (n->primary_key, pkey, key_len) && -net_eq (dev_net (n->dev), net)) { -if (!refcount_inc_not_zero (&n->refcnt)) - n =NULL ; -NEIGH_CACHE_STAT_INC (tbl, hits); -break ; - } - } - -rcu_read_unlock_bh (); -return n; -} -EXPORT_SYMBOL (neigh_lookup_nodev); -static struct neighbour * ___neigh_create(struct neigh_table *tbl, const void *pkey, struct net_device *dev, u32 flags,
Greg Kroah-Hartman
maintainerPATCH 186/187 scsi: target: core: Fix error path in target_setup_session()
In reply to Greg Kroah-HartmanFrom: Bob Pearson <[email protected]>
commit 91271699228bfc66f1bc8abc0327169dc156d854 upstream.
In the error exits in target_setup_session(), if a branch is taken tofree_sess: transport_free_session() may call to target_free_cmd_counter() and then fall through to call target_free_cmd_counter() a second time. This can, and does, sometimes cause seg faults since the data field in cmd_cnt->refcnt has been freed in the first call.
Fix this problem by simply returning after the call to transport_free_session(). The second call is redundant for those cases.
--- drivers/target/target_core_transport.c | 2 ++ 1 file changed, 2 insertions(+)
drivers/target/target_core_transport.c +2 -0
@@ -504,6 +504,8 @@ target_setup_session(struct se_portal_gr free_sess:transport_free_session (sess); +return ERR_PTR (rc); + free_cnt:target_free_cmd_counter (cmd_cnt);return ERR_PTR (rc);
Greg Kroah-Hartman
maintainerPATCH 187/187 blk-cgroup: Flush stats before releasing blkcg_gq
In reply to Greg Kroah-HartmanFrom: Ming Lei <[email protected]>
commit 20cb1c2fb7568a6054c55defe044311397e01ddb upstream.
As noted by Michal, the blkg_iostat_set's in the lockless list hold reference to blkg's to protect against their removal. Those blkg's hold reference to blkcg. When a cgroup is being destroyed, cgroup_rstat_flush() is only called at css_release_work_fn() which is called when the blkcg reference count reaches 0. This circular dependency will prevent blkcg and some blkgs from being freed after they are made offline.
It is less a problem if the cgroup to be destroyed also has other controllers like memory that will call cgroup_rstat_flush() which will clean up the reference count. If block is the only controller that uses rstat, these offline blkcg and blkgs may never be freed leaking more and more memory over time.
To prevent this potential memory leak:
- flush blkcg per-cpu stats list in __blkg_release(), when no new stat can be added
- add global blkg_stat_lock for covering concurrent parent blkg stat update
- don't grab bio->bi_blkg reference when adding the stats into blkcg's per-cpu stat list since all stats are guaranteed to be consumed before releasing blkg instance, and grabbing blkg reference for stats was the most fragile part of original patch
Based on Waiman's patch:
https://lore.kernel.org/linux-block/[email protected]/
--- block/blk-cgroup.c | 40 +++++++++++++++++++++++++++++++--------- 1 file changed, 31 insertions(+), 9 deletions(-)
block/blk-cgroup.c +31 -9
@@ -35,6 +35,8 @@#include "blk-throttle.h" #include "blk-rq-qos.h" +static void __blkcg_rstat_flush (struct blkcg *blkcg,int cpu); +/* * blkcg_pol_mutex protects blkcg_policy[] and policy [de]activation. * blkcg_pol_register_mutex nests outside of it and synchronizes entire
@@ -58,6 +60,8 @@ static LIST_HEAD(all_blkcgs); /* protecbool blkcg_debug_stats = false;static struct workqueue_struct *blkcg_punt_bio_wq; +static DEFINE_RAW_SPINLOCK (blkg_stat_lock); +#define BLKG_DESTROY_BATCH_SIZE 64/*
@@ -165,8 +169,18 @@ static void blkg_free(struct blkcg_gq *bstatic void __blkg_release (struct rcu_head *rcu) { struct blkcg_gq *blkg = container_of(rcu, struct blkcg_gq, rcu_head); +struct blkcg *blkcg = blkg->blkcg; +int cpu;WARN_ON (!bio_list_empty (&blkg->async_bios)); +/* +* Flush all the non-empty percpu lockless lists before releasing +* us, given these stat belongs to us. +* +* blkg_stat_lock is for serializing blkg stat update +*/ +for_each_possible_cpu (cpu) +__blkcg_rstat_flush (blkcg, cpu);/* release the blkcg and parent blkg refs this blkg has been holding */ css_put (&blkg->blkcg->css);
@@ -888,17 +902,12 @@ static void blkcg_iostat_update(struct bu64_stats_update_end_irqrestore (&blkg->iostat.sync, flags); } -static void blkcg_rstat_flush (struct cgroup_subsys_state *css,int cpu) +static void __blkcg_rstat_flush (struct blkcg *blkcg,int cpu) { -struct blkcg *blkcg =css_to_blkcg (css);struct llist_head *lhead =per_cpu_ptr (blkcg->lhead, cpu);struct llist_node *lnode;struct blkg_iostat_set *bisc, *next_bisc; -/* Root-level stats are sourced from system-wide IO stats */ -if (!cgroup_parent (css->cgroup)) -return ; -rcu_read_lock (); lnode =llist_del_all (lhead);
@@ -906,6 +915,14 @@ static void blkcg_rstat_flush(struct cgr goto out;/* +* For covering concurrent parent blkg update from blkg_release(). +* +* When flushing from cgroup, cgroup_rstat_lock is always held, so +* this lock won't cause contention most of time. +*/ +raw_spin_lock (&blkg_stat_lock); + +/* * Iterate only the iostat_cpu's queued in the lockless list. */ llist_for_each_entry_safe (bisc, next_bisc, lnode, lnode) {
@@ -928,13 +945,19 @@ static void blkcg_rstat_flush(struct cgrif (parent && parent->parent)blkcg_iostat_update (parent, &blkg->iostat.cur, &blkg->iostat.last); -percpu_ref_put (&blkg->refcnt); } - +raw_spin_unlock (&blkg_stat_lock); out:rcu_read_unlock (); } +static void blkcg_rstat_flush (struct cgroup_subsys_state *css,int cpu) +{ +/* Root-level stats are sourced from system-wide IO stats */ +if (cgroup_parent (css->cgroup)) +__blkcg_rstat_flush (css_to_blkcg (css), cpu); +} +/* * We source root cgroup stats from the system-wide stats to avoid * tracking the same information twice and incurring overhead when no
@@ -2063,7 +2086,6 @@ void blk_cgroup_bio_start(struct bio *billist_add (&bis->lnode, lhead);WRITE_ONCE (bis->lqueued, true); -percpu_ref_get (&bis->blkg->refcnt); }u64_stats_update_end_irqrestore (&bis->sync, flags);
Quoted 7 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 6.3.9 release. There are 187 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 Wed, 21 Jun 2023 10:21:12 +0000. Anything received after that time might be too late.
Hi Greg
6.3.9-rc1
compiles, boots and runs here on x86_64
(AMD Ryzen 5 PRO 4650G, Slackware64-15.0)
Quoted 9 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 6.3.9 release. There are 187 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 Wed, 21 Jun 2023 10:21:12 +0000. Anything received after that time might be too late.
The whole patch series can be found in one patch at:
Quoted 8 lines
https://www.kernel.org/pub/linux/kernel/v6.x/stable-review/patch-6.3.9-rc1.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-6.3.y
and the diffstat can be found below.thanks,
greg k-h
On ARCH_BRCMSTB using 32-bit and 64-bit ARM kernels, build tested on BMIPS_GENERIC:
Signature · 1 line
Florian
Quoted 9 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 6.3.9 release. There are 187 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 Wed, 21 Jun 2023 10:21:12 +0000. Anything received after that time might be too late.
The whole patch series can be found in one patch at:
Quoted 8 lines
https://www.kernel.org/pub/linux/kernel/v6.x/stable-review/patch-6.3.9-rc1.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-6.3.y
and the diffstat can be found below.thanks,
greg k-h
Built and booted successfully on RISC-V RV64 (HiFive Unmatched).
Quoted 10 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 6.3.9 release. There are 187 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 Wed, 21 Jun 2023 10:21:12 +0000. Anything received after that time might be too late.
The whole patch series can be found in one patch at:
Quoted 8 lines
https://www.kernel.org/pub/linux/kernel/v6.x/stable-review/patch-6.3.9-rc1.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-6.3.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.
## Build
* kernel: 6.3.9-rc1
* git: https://gitlab.com/Linaro/lkft/mirrors/stable/linux-stable-rc
* git branch: linux-6.3.y
* git commit: c4f2a2d855d4abab5f904b8deec55ff390f954e0
* git describe: v6.3.8-188-gc4f2a2d855d4
* test details:
https://qa-reports.linaro.org/lkft/linux-stable-rc-linux-6.3.y/build/v6.3.8-188-gc4f2a2d855d4
## Test Regressions (compared to v6.3.7)
## Metric Regressions (compared to v6.3.7)
## Test Fixes (compared to v6.3.7)
## Metric Fixes (compared to v6.3.7)
## Test result summary
total: 181373, pass: 152623, fail: 3225, skip: 25380, xfail: 145
## Build Summary
* arc: 5 total, 5 passed, 0 failed
* arm: 145 total, 144 passed, 1 failed
* arm64: 54 total, 53 passed, 1 failed
* i386: 41 total, 40 passed, 1 failed
* mips: 30 total, 28 passed, 2 failed
* parisc: 4 total, 4 passed, 0 failed
* powerpc: 38 total, 36 passed, 2 failed
* riscv: 26 total, 25 passed, 1 failed
* s390: 16 total, 14 passed, 2 failed
* sh: 14 total, 12 passed, 2 failed
* sparc: 8 total, 8 passed, 0 failed
* x86_64: 46 total, 46 passed, 0 failed
## Test suites summary
* boot
* fwts
* igt-gpu-tools
* kselftest-android
* kselftest-arm64
* kselftest-breakpoints
* kselftest-capabilities
* kselftest-cgroup
* kselftest-clone3
* kselftest-core
* kselftest-cpu-hotplug
* kselftest-cpufreq
* kselftest-drivers-dma-buf
* kselftest-efivarfs
* kselftest-exec
* kselftest-filesystems
* kselftest-filesystems-binderfs
* kselftest-firmware
* kselftest-fpu
* kselftest-ftrace
* kselftest-futex
* kselftest-gpio
* kselftest-intel_pstate
* kselftest-ipc
* kselftest-ir
* kselftest-kcmp
* kselftest-kexec
* kselftest-kvm
* kselftest-lib
* kselftest-livepatch
* kselftest-membarrier
* kselftest-mincore
* kselftest-mqueue
* kselftest-net
* kselftest-net-forwarding
* kselftest-net-mptcp
* 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-user_events
* kselftest-vDSO
* kselftest-watchdog
* kselftest-x86
* kselftest-zram
* kunit
* kvm-unit-tests
* libgpiod
* libhugetlbfs
* log-parser-boot
* log-parser-test
* ltp-cap_bounds
* ltp-commands
* ltp-containers
* ltp-controllers
* ltp-cpuhotplug
* ltp-crypto
* ltp-cve
* ltp-dio
* ltp-fcntl-locktests
* ltp-filecaps
* ltp-fs
* ltp-fs_bind
* ltp-fs_perms_simple
* ltp-fsx
* ltp-hugetlb
* ltp-io
* ltp-ipc
* ltp-math
* ltp-mm
* ltp-nptl
* ltp-pty
* ltp-sched
* ltp-securebits
* ltp-smoke
* ltp-syscalls
* ltp-tracing
* network-basic-tests
* perf
* rcutorture
* v4l2-compliance
* vdso
--
Linaro LKFT
https://lkft.linaro.org
Hello Greg,
Quoted 10 lines
From: Greg Kroah-Hartman <[email protected]>
Sent: Monday, June 19, 2023 11:27 AMThis is the start of the stable review cycle for the 6.3.9 release. There are 187 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 Wed, 21 Jun 2023 10:21:12 +0000. Anything received after that time might be too late.
Thank you for the release!
CIP configurations built and booted okay with Linux 6.3.9-rc1 (c4f2a2d855d4):
https://gitlab.com/cip-project/cip-testing/linux-stable-rc-ci/-/pipelines/904358168
https://gitlab.com/cip-project/cip-testing/linux-stable-rc-ci/-/commits/linux-6.3.y
Kind regards, Chris
Quoted 9 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 6.3.9 release. There are 187 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 Wed, 21 Jun 2023 10:21:12 +0000. Anything received after that time might be too late.
The whole patch series can be found in one patch at:
Quoted 8 lines
https://www.kernel.org/pub/linux/kernel/v6.x/stable-review/patch-6.3.9-rc1.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-6.3.y
and the diffstat can be found below.thanks,
greg k-h
All tests passing for Tegra ...
Test results for stable-v6.3:
11 builds: 11 pass, 0 fail
28 boots: 28 pass, 0 fail
130 tests: 130 pass, 0 failLinux version: 6.3.9-rc1-gc4f2a2d855d4
Boards tested: tegra124-jetson-tk1, tegra186-p2771-0000,
tegra194-p2972-0000, tegra194-p3509-0000+p3668-0000,
tegra20-ventana, tegra210-p2371-2180,
tegra210-p3450-0000, tegra30-cardhu-a04Jon
Quoted 4 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 6.3.9 release. There are 187 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.
Cheers,
Conor.
Hi Greg,
Quoted 4 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 6.3.9 release. There are 187 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.
Build test (gcc version 12.2.1 20230511):
mips: 52 configs -> no failure
arm: 71 configs -> no failure
arm64: 3 configs -> no failurex86_64: 4 configs -> no failure
alpha allmodconfig -> no failure
csky allmodconfig -> no failure
powerpc allmodconfig -> no failure
riscv allmodconfig -> no failure
s390 allmodconfig -> no failure
xtensa allmodconfig -> no failure
Boot test:x86_64: Booted on my test laptop. No regression.x86_64: Booted on qemu. No regression. [1]
arm64: Booted on rpi4b (4GB model). No regression. [2]
mips: Booted on ci20 board. No regression. [3]
[1]. https://openqa.qa.codethink.co.uk/tests/4085
[2]. https://openqa.qa.codethink.co.uk/tests/4081
[3]. https://openqa.qa.codethink.co.uk/tests/4079
Signature · 2 lines
Regards Sudip
Quoted 9 lines
This is the start of the stable review cycle for the 6.3.9 release. There are 187 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 Wed, 21 Jun 2023 10:21:12 +0000. Anything received after that time might be too late.
The whole patch series can be found in one patch at:
Quoted 9 lines
https://www.kernel.org/pub/linux/kernel/v6.x/stable-review/patch-6.3.9-rc1.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-6.3.y
and the diffstat can be found below.thanks,
greg k-h
Compiled and booted on my x86_64 and ARM64 test systems. No errors or regressions.
Thanks.
Quoted 9 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 6.3.9 release. There are 187 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 Wed, 21 Jun 2023 10:21:12 +0000. Anything received after that time might be too late.
The whole patch series can be found in one patch at:
Quoted 9 lines
https://www.kernel.org/pub/linux/kernel/v6.x/stable-review/patch-6.3.9-rc1.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-6.3.y
and the diffstat can be found below.thanks,
greg k-h
Compiled and booted on my test system. No dmesg regressions.
thanks,
-- Shuah
Quoted 8 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 6.3.9 release. There are 187 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 Wed, 21 Jun 2023 10:21:12 +0000. Anything received after that time might be too late.
Build results:
total: 153 pass: 153 fail: 0 Qemu test results: total: 520 pass: 520 fail: 0
Guenter
Quoted 9 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 6.3.9 release. There are 187 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 Wed, 21 Jun 2023 10:21:12 +0000. Anything received after that time might be too late.
The whole patch series can be found in one patch at:
Quoted 8 lines
https://www.kernel.org/pub/linux/kernel/v6.x/stable-review/patch-6.3.9-rc1.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-6.3.y
and the diffstat can be found below.thanks,
greg k-h
Tested rc1 against the Fedora build system (aarch64, ppc64le, s390x, x86_64), and boot tested x86_64. No regressions noted.