6.5.13-rc1 review
Subsystems (7)
Greg Kroah-Hartman
maintainerPATCH 117/491 phy: qualcomm: phy-qcom-eusb2-repeater: Zero out untouched tuning regs
In reply to Greg Kroah-Hartman6.5-stable review patch. If anyone has any objections, please let me know.
------------------
From: Konrad Dybcio <[email protected]>
[ Upstream commit 99a517a582fc1272d1d3cf3b9e671a14d7db77b8 ]
The vendor kernel zeroes out all tuning data outside the init sequence as part of initialization. Follow suit to avoid UB.
--- .../phy/qualcomm/phy-qcom-eusb2-repeater.c | 58 ++++++++++++++----- 1 file changed, 44 insertions(+), 14 deletions(-)
drivers/phy/qualcomm/phy-qcom-eusb2-repeater.c +44 -14
@@ -25,9 +25,18 @@#define EUSB2_FORCE_VAL_5 0xeD#define V_CLK_19P2M_EN BIT(6) +#define EUSB2_TUNE_USB2_CROSSOVER 0x50#define EUSB2_TUNE_IUSB2 0x51 +#define EUSB2_TUNE_RES_FSDIF 0x52 +#define EUSB2_TUNE_HSDISC 0x53#define EUSB2_TUNE_SQUELCH_U 0x54 +#define EUSB2_TUNE_USB2_SLEW 0x55 +#define EUSB2_TUNE_USB2_EQU 0x56#define EUSB2_TUNE_USB2_PREEM 0x57 +#define EUSB2_TUNE_USB2_HS_COMP_CUR 0x58 +#define EUSB2_TUNE_EUSB_SLEW 0x59 +#define EUSB2_TUNE_EUSB_EQU 0x5A +#define EUSB2_TUNE_EUSB_HS_COMP_CUR 0x5B#define QCOM_EUSB2_REPEATER_INIT_CFG (r, v) \ { \
@@ -36,9 +45,18 @@ }enum reg_fields { +F_TUNE_EUSB_HS_COMP_CUR , +F_TUNE_EUSB_EQU , +F_TUNE_EUSB_SLEW , +F_TUNE_USB2_HS_COMP_CUR ,F_TUNE_USB2_PREEM , +F_TUNE_USB2_EQU , +F_TUNE_USB2_SLEW ,F_TUNE_SQUELCH_U , +F_TUNE_HSDISC , +F_TUNE_RES_FSDIF ,F_TUNE_IUSB2 , +F_TUNE_USB2_CROSSOVER ,F_NUM_TUNE_FIELDS ,F_FORCE_VAL_5 =F_NUM_TUNE_FIELDS ,
@@ -51,9 +69,18 @@ enum reg_fields { };static struct reg_field eusb2_repeater_tune_reg_fields[F_NUM_FIELDS ] = { + [F_TUNE_EUSB_HS_COMP_CUR ] =REG_FIELD (EUSB2_TUNE_EUSB_HS_COMP_CUR ,0 ,1 ), + [F_TUNE_EUSB_EQU ] =REG_FIELD (EUSB2_TUNE_EUSB_EQU ,0 ,1 ), + [F_TUNE_EUSB_SLEW ] =REG_FIELD (EUSB2_TUNE_EUSB_SLEW ,0 ,1 ), + [F_TUNE_USB2_HS_COMP_CUR ] =REG_FIELD (EUSB2_TUNE_USB2_HS_COMP_CUR ,0 ,1 ), [F_TUNE_USB2_PREEM ] =REG_FIELD (EUSB2_TUNE_USB2_PREEM ,0 ,2 ), + [F_TUNE_USB2_EQU ] =REG_FIELD (EUSB2_TUNE_USB2_EQU ,0 ,1 ), + [F_TUNE_USB2_SLEW ] =REG_FIELD (EUSB2_TUNE_USB2_SLEW ,0 ,1 ), [F_TUNE_SQUELCH_U ] =REG_FIELD (EUSB2_TUNE_SQUELCH_U ,0 ,2 ), + [F_TUNE_HSDISC ] =REG_FIELD (EUSB2_TUNE_HSDISC ,0 ,2 ), + [F_TUNE_RES_FSDIF ] =REG_FIELD (EUSB2_TUNE_RES_FSDIF ,0 ,2 ), [F_TUNE_IUSB2 ] =REG_FIELD (EUSB2_TUNE_IUSB2 ,0 ,3 ), + [F_TUNE_USB2_CROSSOVER ] =REG_FIELD (EUSB2_TUNE_USB2_CROSSOVER ,0 ,2 ), [F_FORCE_VAL_5 ] =REG_FIELD (EUSB2_FORCE_VAL_5 ,0 ,7 ), [F_FORCE_EN_5 ] =REG_FIELD (EUSB2_FORCE_EN_5 ,0 ,7 ),
@@ -63,13 +90,8 @@ static struct reg_field eusb2_repeater_tune_reg_fields[F_NUM_FIELDS] = { [F_RPTR_STATUS] = REG_FIELD(EUSB2_RPTR_STATUS, 0, 7), }; -struct eusb2_repeater_init_tbl { -unsigned int reg; -unsigned int val; -}; -struct eusb2_repeater_cfg { -const struct eusb2_repeater_init_tbl *init_tbl; +const u32 *init_tbl;int init_tbl_num;const char *const *vreg_list;int num_vregs;
@@ -88,10 +110,10 @@ static const char * const pm8550b_vreg_l[] = { "vdd18", "vdd3", }; -static const struct eusb2_repeater_init_tbl pm8550b_init_tbl[] = { -QCOM_EUSB2_REPEATER_INIT_CFG (F_TUNE_IUSB2 ,0x8 ), -QCOM_EUSB2_REPEATER_INIT_CFG (F_TUNE_SQUELCH_U ,0x3 ), -QCOM_EUSB2_REPEATER_INIT_CFG (F_TUNE_USB2_PREEM ,0x5 ), +static const u32 pm8550b_init_tbl[F_NUM_TUNE_FIELDS ] = { + [F_TUNE_IUSB2 ] =0x8 , + [F_TUNE_SQUELCH_U ] =0x3 , + [F_TUNE_USB2_PREEM ] =0x5 , };static const struct eusb2_repeater_cfg pm8550b_eusb2_cfg = {
@@ -119,8 +141,9 @@ static int eusb2_repeater_init_vregs(struct eusb2_repeater *rptr)static int eusb2_repeater_init (struct phy *phy) { +struct reg_field *regfields = eusb2_repeater_tune_reg_fields;struct eusb2_repeater *rptr =phy_get_drvdata (phy); -const struct eusb2_repeater_init_tbl *init_tbl = rptr->cfg->init_tbl; +const u32 *init_tbl = rptr->cfg->init_tbl;u32 val;int ret;int i;
@@ -131,9 +154,16 @@ static int eusb2_repeater_init(struct phy *phy)regmap_field_update_bits (rptr->regs[F_EN_CTL1 ],EUSB2_RPTR_EN ,EUSB2_RPTR_EN ); -for (i =0 ; i < rptr->cfg->init_tbl_num; i++) -regmap_field_update_bits (rptr->regs[init_tbl[i].reg], - init_tbl[i].val, init_tbl[i].val); +for (i =0 ; i <F_NUM_TUNE_FIELDS ; i++) { +if (init_tbl[i]) { +regmap_field_update_bits (rptr->regs[i], init_tbl[i], init_tbl[i]); + }else { +/* Write 0 if there's no value set */ +u32 mask =GENMASK (regfields[i].msb, regfields[i].lsb); + +regmap_field_update_bits (rptr->regs[i], mask,0 ); + } + } ret =regmap_field_read_poll_timeout (rptr->regs[F_RPTR_STATUS ], val, val &RPTR_OK ,10 ,5 );
Signature · 1 line
2.42.0
Greg Kroah-Hartman
maintainerPATCH 118/491 usb: dwc3: core: configure TX/RX threshold for DWC3_IP
In reply to Greg Kroah-Hartman6.5-stable review patch. If anyone has any objections, please let me know.
------------------
From: Stanley Chang <[email protected]>
[ Upstream commit e72fc8d6a12af7ae8dd1b52cf68ed68569d29f80 ]
In Synopsys's dwc3 data book:
To avoid underrun and overrun during the burst, in a high-latency bus system (like USB), threshold and burst size control is provided through GTXTHRCFG and GRXTHRCFG registers.
In Realtek DHC SoC, DWC3 USB 3.0 uses AHB system bus. When dwc3 is connected with USB 2.5G Ethernet, there will be overrun problem. Therefore, setting TX/RX thresholds can avoid this issue.
--- drivers/usb/dwc3/core.c | 160 +++++++++++++++++++++++++++++++--------- drivers/usb/dwc3/core.h | 13 ++++ 2 files changed, 137 insertions(+), 36 deletions(-)
drivers/usb/dwc3/core.c +124 -36
@@ -1094,6 +1094,111 @@ static void dwc3_set_power_down_clk_scale(struct dwc3 *dwc) } } +static void dwc3_config_threshold (struct dwc3 *dwc) +{ +u32 reg; +u8 rx_thr_num; +u8 rx_maxburst; +u8 tx_thr_num; +u8 tx_maxburst; + +/* +* Must config both number of packets and max burst settings to enable +* RX and/or TX threshold. +*/ +if (!DWC3_IP_IS (DWC3 ) && dwc->dr_mode ==USB_DR_MODE_HOST ) { + rx_thr_num = dwc->rx_thr_num_pkt_prd; + rx_maxburst = dwc->rx_max_burst_prd; + tx_thr_num = dwc->tx_thr_num_pkt_prd; + tx_maxburst = dwc->tx_max_burst_prd; + +if (rx_thr_num && rx_maxburst) { + reg =dwc3_readl (dwc->regs,DWC3_GRXTHRCFG ); + reg |=DWC31_RXTHRNUMPKTSEL_PRD ; + + reg &= ~DWC31_RXTHRNUMPKT_PRD (~0 ); + reg |=DWC31_RXTHRNUMPKT_PRD (rx_thr_num); + + reg &= ~DWC31_MAXRXBURSTSIZE_PRD (~0 ); + reg |=DWC31_MAXRXBURSTSIZE_PRD (rx_maxburst); + +dwc3_writel (dwc->regs,DWC3_GRXTHRCFG , reg); + } + +if (tx_thr_num && tx_maxburst) { + reg =dwc3_readl (dwc->regs,DWC3_GTXTHRCFG ); + reg |=DWC31_TXTHRNUMPKTSEL_PRD ; + + reg &= ~DWC31_TXTHRNUMPKT_PRD (~0 ); + reg |=DWC31_TXTHRNUMPKT_PRD (tx_thr_num); + + reg &= ~DWC31_MAXTXBURSTSIZE_PRD (~0 ); + reg |=DWC31_MAXTXBURSTSIZE_PRD (tx_maxburst); + +dwc3_writel (dwc->regs,DWC3_GTXTHRCFG , reg); + } + } + + rx_thr_num = dwc->rx_thr_num_pkt; + rx_maxburst = dwc->rx_max_burst; + tx_thr_num = dwc->tx_thr_num_pkt; + tx_maxburst = dwc->tx_max_burst; + +if (DWC3_IP_IS (DWC3 )) { +if (rx_thr_num && rx_maxburst) { + reg =dwc3_readl (dwc->regs,DWC3_GRXTHRCFG ); + reg |=DWC3_GRXTHRCFG_PKTCNTSEL ; + + reg &= ~DWC3_GRXTHRCFG_RXPKTCNT (~0 ); + reg |=DWC3_GRXTHRCFG_RXPKTCNT (rx_thr_num); + + reg &= ~DWC3_GRXTHRCFG_MAXRXBURSTSIZE (~0 ); + reg |=DWC3_GRXTHRCFG_MAXRXBURSTSIZE (rx_maxburst); + +dwc3_writel (dwc->regs,DWC3_GRXTHRCFG , reg); + } + +if (tx_thr_num && tx_maxburst) { + reg =dwc3_readl (dwc->regs,DWC3_GTXTHRCFG ); + reg |=DWC3_GTXTHRCFG_PKTCNTSEL ; + + reg &= ~DWC3_GTXTHRCFG_TXPKTCNT (~0 ); + reg |=DWC3_GTXTHRCFG_TXPKTCNT (tx_thr_num); + + reg &= ~DWC3_GTXTHRCFG_MAXTXBURSTSIZE (~0 ); + reg |=DWC3_GTXTHRCFG_MAXTXBURSTSIZE (tx_maxburst); + +dwc3_writel (dwc->regs,DWC3_GTXTHRCFG , reg); + } + }else { +if (rx_thr_num && rx_maxburst) { + reg =dwc3_readl (dwc->regs,DWC3_GRXTHRCFG ); + reg |=DWC31_GRXTHRCFG_PKTCNTSEL ; + + reg &= ~DWC31_GRXTHRCFG_RXPKTCNT (~0 ); + reg |=DWC31_GRXTHRCFG_RXPKTCNT (rx_thr_num); + + reg &= ~DWC31_GRXTHRCFG_MAXRXBURSTSIZE (~0 ); + reg |=DWC31_GRXTHRCFG_MAXRXBURSTSIZE (rx_maxburst); + +dwc3_writel (dwc->regs,DWC3_GRXTHRCFG , reg); + } + +if (tx_thr_num && tx_maxburst) { + reg =dwc3_readl (dwc->regs,DWC3_GTXTHRCFG ); + reg |=DWC31_GTXTHRCFG_PKTCNTSEL ; + + reg &= ~DWC31_GTXTHRCFG_TXPKTCNT (~0 ); + reg |=DWC31_GTXTHRCFG_TXPKTCNT (tx_thr_num); + + reg &= ~DWC31_GTXTHRCFG_MAXTXBURSTSIZE (~0 ); + reg |=DWC31_GTXTHRCFG_MAXTXBURSTSIZE (tx_maxburst); + +dwc3_writel (dwc->regs,DWC3_GTXTHRCFG , reg); + } + } +} +/** * dwc3_core_init - Low-level initialization of DWC3 Core * @dwc: Pointer to our controller context structure
@@ -1246,42 +1351,7 @@ static int dwc3_core_init(struct dwc3 *dwc)dwc3_writel (dwc->regs,DWC3_GUCTL1 , reg); } -/* -* Must config both number of packets and max burst settings to enable -* RX and/or TX threshold. -*/ -if (!DWC3_IP_IS (DWC3 ) && dwc->dr_mode ==USB_DR_MODE_HOST ) { -u8 rx_thr_num = dwc->rx_thr_num_pkt_prd; -u8 rx_maxburst = dwc->rx_max_burst_prd; -u8 tx_thr_num = dwc->tx_thr_num_pkt_prd; -u8 tx_maxburst = dwc->tx_max_burst_prd; - -if (rx_thr_num && rx_maxburst) { - reg =dwc3_readl (dwc->regs,DWC3_GRXTHRCFG ); - reg |=DWC31_RXTHRNUMPKTSEL_PRD ; - - reg &= ~DWC31_RXTHRNUMPKT_PRD (~0 ); - reg |=DWC31_RXTHRNUMPKT_PRD (rx_thr_num); - - reg &= ~DWC31_MAXRXBURSTSIZE_PRD (~0 ); - reg |=DWC31_MAXRXBURSTSIZE_PRD (rx_maxburst); - -dwc3_writel (dwc->regs,DWC3_GRXTHRCFG , reg); - } - -if (tx_thr_num && tx_maxburst) { - reg =dwc3_readl (dwc->regs,DWC3_GTXTHRCFG ); - reg |=DWC31_TXTHRNUMPKTSEL_PRD ; - - reg &= ~DWC31_TXTHRNUMPKT_PRD (~0 ); - reg |=DWC31_TXTHRNUMPKT_PRD (tx_thr_num); - - reg &= ~DWC31_MAXTXBURSTSIZE_PRD (~0 ); - reg |=DWC31_MAXTXBURSTSIZE_PRD (tx_maxburst); - -dwc3_writel (dwc->regs,DWC3_GTXTHRCFG , reg); - } - } +dwc3_config_threshold (dwc);return 0 ;
@@ -1417,6 +1487,10 @@ static void dwc3_get_properties(struct dwc3 *dwc)u8 lpm_nyet_threshold;u8 tx_de_emphasis;u8 hird_threshold; +u8 rx_thr_num_pkt =0 ; +u8 rx_max_burst =0 ; +u8 tx_thr_num_pkt =0 ; +u8 tx_max_burst =0 ;u8 rx_thr_num_pkt_prd =0 ;u8 rx_max_burst_prd =0 ;u8 tx_thr_num_pkt_prd =0 ;
@@ -1479,6 +1553,14 @@ static void dwc3_get_properties(struct dwc3 *dwc) "snps,usb2-lpm-disable"); dwc->usb2_gadget_lpm_disable =device_property_read_bool (dev,"snps,usb2-gadget-lpm-disable" ); +device_property_read_u8 (dev,"snps,rx-thr-num-pkt" , + &rx_thr_num_pkt); +device_property_read_u8 (dev,"snps,rx-max-burst" , + &rx_max_burst); +device_property_read_u8 (dev,"snps,tx-thr-num-pkt" , + &tx_thr_num_pkt); +device_property_read_u8 (dev,"snps,tx-max-burst" , + &tx_max_burst);device_property_read_u8 (dev,"snps,rx-thr-num-pkt-prd" , &rx_thr_num_pkt_prd); device_property_read_u8(dev, "snps,rx-max-burst-prd",
@@ -1560,6 +1642,12 @@ static void dwc3_get_properties(struct dwc3 *dwc) dwc->hird_threshold = hird_threshold; + dwc->rx_thr_num_pkt = rx_thr_num_pkt; + dwc->rx_max_burst = rx_max_burst; + + dwc->tx_thr_num_pkt = tx_thr_num_pkt; + dwc->tx_max_burst = tx_max_burst; + dwc->rx_thr_num_pkt_prd = rx_thr_num_pkt_prd; dwc->rx_max_burst_prd = rx_max_burst_prd;
drivers/usb/dwc3/core.h +13 -0
@@ -211,6 +211,11 @@#define DWC3_GRXTHRCFG_RXPKTCNT (n) (((n) & 0xf) << 24)#define DWC3_GRXTHRCFG_PKTCNTSEL BIT(29) +/* Global TX Threshold Configuration Register */ +#define DWC3_GTXTHRCFG_MAXTXBURSTSIZE (n) (((n) & 0xff) << 16) +#define DWC3_GTXTHRCFG_TXPKTCNT (n) (((n) & 0xf) << 24) +#define DWC3_GTXTHRCFG_PKTCNTSEL BIT(29) +/* Global RX Threshold Configuration Register for DWC_usb31 only */ #define DWC31_GRXTHRCFG_MAXRXBURSTSIZE (n) (((n) & 0x1f) << 16)#define DWC31_GRXTHRCFG_RXPKTCNT (n) (((n) & 0x1f) << 21)
@@ -1045,6 +1050,10 @@ struct dwc3_scratchpad_array {* @test_mode_nr: test feature selector * @lpm_nyet_threshold: LPM NYET response threshold * @hird_threshold: HIRD threshold +* @rx_thr_num_pkt: USB receive packet count +* @rx_max_burst: max USB receive burst size +* @tx_thr_num_pkt: USB transmit packet count +* @tx_max_burst: max USB transmit burst size * @rx_thr_num_pkt_prd: periodic ESS receive packet count * @rx_max_burst_prd: max periodic ESS receive burst size * @tx_thr_num_pkt_prd: periodic ESS transmit packet count
@@ -1273,6 +1282,10 @@ struct dwc3 {u8 test_mode_nr;u8 lpm_nyet_threshold;u8 hird_threshold; +u8 rx_thr_num_pkt; +u8 rx_max_burst; +u8 tx_thr_num_pkt; +u8 tx_max_burst;u8 rx_thr_num_pkt_prd;u8 rx_max_burst_prd;u8 tx_thr_num_pkt_prd;
Signature · 1 line
2.42.0
Greg Kroah-Hartman
maintainerPATCH 119/491 usb: ucsi: glink: use the connector orientation GPIO to provide switch events
In reply to Greg Kroah-Hartman6.5-stable review patch. If anyone has any objections, please let me know.
------------------
From: Neil Armstrong <[email protected]>
[ Upstream commit c6165ed2f425c273244191930a47c8be23bc51bd ]
On SM8550, the non-altmode orientation is not given anymore within altmode events, even with USB SVIDs events.
On the other side, the Type-C connector orientation is correctly reported by a signal from the PMIC.
Take this gpio signal when we detect some Type-C port activity to notify any Type-C switches tied to the Type-C port connectors.
--- drivers/usb/typec/ucsi/ucsi_glink.c | 54 ++++++++++++++++++++++++++++- 1 file changed, 53 insertions(+), 1 deletion(-)
drivers/usb/typec/ucsi/ucsi_glink.c +53 -1
@@ -9,9 +9,13 @@#include <linux/mutex.h> #include <linux/property.h> #include <linux/soc/qcom/pdr.h> +#include <linux/usb/typec_mux.h> +#include <linux/gpio/consumer.h> #include <linux/soc/qcom/pmic_glink.h> #include "ucsi.h" +#define PMIC_GLINK_MAX_PORTS 2 +#define UCSI_BUF_SIZE 48#define MSG_TYPE_REQ_RESP 1
@@ -53,6 +57,9 @@ struct ucsi_notify_ind_msg {struct pmic_glink_ucsi {struct device *dev; +struct gpio_desc *port_orientation[PMIC_GLINK_MAX_PORTS ]; +struct typec_switch *port_switch[PMIC_GLINK_MAX_PORTS ]; +struct pmic_glink_client *client;struct ucsi *ucsi;
@@ -221,8 +228,20 @@ static void pmic_glink_ucsi_notify(struct work_struct *work) } con_num =UCSI_CCI_CONNECTOR (cci); -if (con_num) +if (con_num) { +if (con_num <PMIC_GLINK_MAX_PORTS && + ucsi->port_orientation[con_num -1 ]) { +int orientation =gpiod_get_value (ucsi->port_orientation[con_num -1 ]); + +if (orientation >=0 ) { +typec_switch_set (ucsi->port_switch[con_num -1 ], + orientation ?TYPEC_ORIENTATION_REVERSE + :TYPEC_ORIENTATION_NORMAL ); + } + } +ucsi_connector_change (ucsi->ucsi, con_num); + }if (ucsi->sync_pending && cci &UCSI_CCI_BUSY ) { ucsi->sync_val = -EBUSY ;
@@ -283,6 +302,7 @@ static int pmic_glink_ucsi_probe(struct auxiliary_device *adev, {struct pmic_glink_ucsi *ucsi;struct device *dev = &adev->dev; +struct fwnode_handle *fwnode;int ret; ucsi =devm_kzalloc (dev,sizeof (*ucsi),GFP_KERNEL );
@@ -310,6 +330,38 @@ static int pmic_glink_ucsi_probe(struct auxiliary_device *adev,ucsi_set_drvdata (ucsi->ucsi, ucsi); +device_for_each_child_node (dev, fwnode) { +struct gpio_desc *desc; +u32 port; + + ret =fwnode_property_read_u32 (fwnode,"reg" , &port); +if (ret <0 ) { +dev_err (dev,"missing reg property of %pOFn\n" , fwnode); +return ret; + } + +if (port >=PMIC_GLINK_MAX_PORTS ) { +dev_warn (dev,"invalid connector number, ignoring\n" ); +continue ; + } + + desc =devm_gpiod_get_index_optional (&adev->dev,"orientation" , port,GPIOD_IN ); + +/* If GPIO isn't found, continue */ +if (!desc) +continue ; + +if (IS_ERR (desc)) +return dev_err_probe (dev,PTR_ERR (desc), +"unable to acquire orientation gpio\n" ); + ucsi->port_orientation[port] = desc; + + ucsi->port_switch[port] =fwnode_typec_switch_get (fwnode); +if (IS_ERR (ucsi->port_switch[port])) +return dev_err_probe (dev,PTR_ERR (ucsi->port_switch[port]), +"failed to acquire orientation-switch\n" ); + } + ucsi->client = devm_pmic_glink_register_client(dev, PMIC_GLINK_OWNER_USBC, pmic_glink_ucsi_callback,
Signature · 1 line
2.42.0
Greg Kroah-Hartman
maintainerPATCH 120/491 soundwire: dmi-quirks: update HP Omen match
In reply to Greg Kroah-Hartman6.5-stable review patch. If anyone has any objections, please let me know.
------------------
From: Pierre-Louis Bossart <[email protected]>
[ Upstream commit 4ea2b6d3128ea4d502c4015df0dc16b7d1070954 ]
New platforms have a slightly different DMI product name, remove trailing characters/digits to handle all cases
--- drivers/soundwire/dmi-quirks.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/soundwire/dmi-quirks.c +1 -1
@@ -141,7 +141,7 @@ static const struct dmi_system_id adr_remap_quirk_table[] = { { .matches = { DMI_MATCH(DMI_SYS_VENDOR, "HP"), - DMI_MATCH(DMI_PRODUCT_NAME, "OMEN by HP Gaming Laptop 16-k0xxx"), + DMI_MATCH(DMI_PRODUCT_NAME, "OMEN by HP Gaming Laptop 16"), }, .driver_data = (void *)hp_omen_16, },
Signature · 1 line
2.42.0
Greg Kroah-Hartman
maintainerPATCH 121/491 f2fs: fix error path of __f2fs_build_free_nids
In reply to Greg Kroah-Hartman6.5-stable review patch. If anyone has any objections, please let me know.
------------------
From: Zhiguo Niu <[email protected]>
[ Upstream commit a5e80e18f268ea7c7a36bc4159de0deb3b5a2171 ]
If NAT is corrupted, let scan_nat_page() return EFSCORRUPTED, so that, caller can set SBI_NEED_FSCK flag into checkpoint for later repair by fsck.
Also, this patch introduces a new fscorrupted error flag, and in above scenario, it will persist the error flag into superblock synchronously to avoid it has no luck to trigger a checkpoint to record SBI_NEED_FSCK
--- fs/f2fs/node.c | 11 +++++++++-- include/linux/f2fs_fs.h | 1 + 2 files changed, 10 insertions(+), 2 deletions(-)
fs/f2fs/node.c +9 -2
@@ -2389,7 +2389,7 @@ static int scan_nat_page(struct f2fs_sb_info *sbi, blk_addr =le32_to_cpu (nat_blk->entries[i].block_addr);if (blk_addr ==NEW_ADDR ) -return -EINVAL ; +return -EFSCORRUPTED ;if (blk_addr ==NULL_ADDR ) {add_free_nid (sbi, start_nid, true, true);
@@ -2504,7 +2504,14 @@ static int __f2fs_build_free_nids(struct f2fs_sb_info *sbi,if (ret) {f2fs_up_read (&nm_i->nat_tree_lock); -f2fs_err (sbi,"NAT is corrupt, run fsck to fix it" ); + +if (ret == -EFSCORRUPTED ) { +f2fs_err (sbi,"NAT is corrupt, run fsck to fix it" ); +set_sbi_flag (sbi,SBI_NEED_FSCK ); +f2fs_handle_error (sbi, +ERROR_INCONSISTENT_NAT ); + } +return ret; } }
include/linux/f2fs_fs.h +1 -0
@@ -104,6 +104,7 @@ enum f2fs_error {ERROR_CORRUPTED_VERITY_XATTR ,ERROR_CORRUPTED_XATTR ,ERROR_INVALID_NODE_REFERENCE , +ERROR_INCONSISTENT_NAT , ERROR_MAX, };
Signature · 1 line
2.42.0
Greg Kroah-Hartman
maintainerPATCH 122/491 f2fs: fix error handling of __get_node_page
In reply to Greg Kroah-Hartman6.5-stable review patch. If anyone has any objections, please let me know.
------------------
From: Zhiguo Niu <[email protected]>
[ Upstream commit 9b4c8dd99fe48721410741651d426015e03a4b7a ]
Use f2fs_handle_error to record inconsistent node block error and return -EFSCORRUPTED instead of -EINVAL.
--- fs/f2fs/node.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)
fs/f2fs/node.c +2 -1
@@ -1467,7 +1467,8 @@ static struct page *__get_node_page(struct f2fs_sb_info *sbi, pgoff_t nid,ofs_of_node (page),cpver_of_node (page), next_blkaddr_of_node(page));set_sbi_flag (sbi,SBI_NEED_FSCK ); - err = -EINVAL ; +f2fs_handle_error (sbi,ERROR_INCONSISTENT_FOOTER ); + err = -EFSCORRUPTED ; out_err:ClearPageUptodate (page); out_put_err:
Signature · 1 line
2.42.0
Greg Kroah-Hartman
maintainerPATCH 123/491 usb: host: xhci: Avoid XHCI resume delay if SSUSB device is not present
In reply to Greg Kroah-Hartman6.5-stable review patch. If anyone has any objections, please let me know.
------------------
From: Wesley Cheng <[email protected]>
[ Upstream commit 6add6dd345cb754ce18ff992c7264cabf31e59f6 ]
There is a 120ms delay implemented for allowing the XHCI host controller to detect a U3 wakeup pulse. The intention is to wait for the device to retry the wakeup event if the USB3 PORTSC doesn't reflect the RESUME link status by the time it is checked. As per the USB3 specification:
tU3WakeupRetryDelay ("Table 7-12. LTSSM State Transition Timeouts")
This would allow the XHCI resume sequence to determine if the root hub needs to be also resumed. However, in case there is no device connected, or if there is only a HSUSB device connected, this delay would still affect the overall resume timing.
Since this delay is solely for detecting U3 wake events (USB3 specific) then ignore this delay for the disconnected case and the HSUSB connected only case.
[skip helper function, rename usb3_connected variable -Mathias ]
--- drivers/usb/host/xhci.c | 12 ++++++++++-- 1 file changed, 10 insertions(+), 2 deletions(-)
drivers/usb/host/xhci.c +10 -2
@@ -968,6 +968,7 @@ int xhci_resume(struct xhci_hcd *xhci, pm_message_t msg)int retval =0 ;bool comp_timer_running = false;bool pending_portevent = false; +bool suspended_usb3_devs = false;bool reinit_xhc = false;if (!hcd->state)
@@ -1115,10 +1116,17 @@ int xhci_resume(struct xhci_hcd *xhci, pm_message_t msg)/* * Resume roothubs only if there are pending events. * USB 3 devices resend U3 LFPS wake after a 100ms delay if -* the first wake signalling failed, give it that chance. +* the first wake signalling failed, give it that chance if +* there are suspended USB 3 devices. */ +if (xhci->usb3_rhub.bus_state.suspended_ports || + xhci->usb3_rhub.bus_state.bus_suspended) + suspended_usb3_devs = true; + pending_portevent =xhci_pending_portevent (xhci); -if (!pending_portevent && msg.event ==PM_EVENT_AUTO_RESUME ) { + +if (suspended_usb3_devs && !pending_portevent && + msg.event ==PM_EVENT_AUTO_RESUME ) {msleep (120 ); pending_portevent =xhci_pending_portevent (xhci); }
Signature · 1 line
2.42.0
Greg Kroah-Hartman
maintainerPATCH 124/491 usb: gadget: f_ncm: Always set current gadget in ncm_bind()
In reply to Greg Kroah-Hartman6.5-stable review patch. If anyone has any objections, please let me know.
------------------
From: Hardik Gajjar <[email protected]>
[ Upstream commit a04224da1f3424b2c607b12a3bd1f0e302fb8231 ]
Previously, gadget assignment to the net device occurred exclusively during the initial binding attempt.
Nevertheless, the gadget pointer could change during bind/unbind cycles due to various conditions, including the unloading/loading of the UDC device driver or the detachment/reconnection of an OTG-capable USB hub device.
This patch relocates the gether_set_gadget() function out from ncm_opts->bound condition check, ensuring that the correct gadget is assigned during each bind request.
The provided logs demonstrate the consistency of ncm_opts throughout the power cycle, while the gadget may change.
* OTG hub connected during boot up and assignment of gadget and ncm_opts pointer
[ 2.366301] usb 2-1.5: New USB device found, idVendor=2996, idProduct=0105 [ 2.366304] usb 2-1.5: New USB device strings: Mfr=1, Product=2, SerialNumber=3 [ 2.366306] usb 2-1.5: Product: H2H Bridge [ 2.366308] usb 2-1.5: Manufacturer: Aptiv [ 2.366309] usb 2-1.5: SerialNumber: 13FEB2021 [ 2.427989] usb 2-1.5: New USB device found, VID=2996, PID=0105 [ 2.428959] dabridge 2-1.5:1.0: dabridge 2-4 total endpoints=5, 0000000093a8d681 [ 2.429710] dabridge 2-1.5:1.0: P(0105) D(22.06.22) F(17.3.16) H(1.1) high-speed [ 2.429714] dabridge 2-1.5:1.0: Hub 2-2 P(0151) V(06.87) [ 2.429956] dabridge 2-1.5:1.0: All downstream ports in host mode
[ 2.430093] gadget 000000003c414d59 ------> gadget pointer
* NCM opts and associated gadget pointer during First ncm_bind
[ 34.763929] NCM opts 00000000aa304ac9 [ 34.763930] NCM gadget 000000003c414d59
* OTG capable hub disconnecte or assume driver unload.
[ 97.203114] usb 2-1: USB disconnect, device number 2 [ 97.203118] usb 2-1.1: USB disconnect, device number 3 [ 97.209217] usb 2-1.5: USB disconnect, device number 4 [ 97.230990] dabr_udc deleted
* Reconnect the OTG hub or load driver assaign new gadget pointer.
[ 111.534035] usb 2-1.1: New USB device found, idVendor=2996, idProduct=0120, bcdDevice= 6.87 [ 111.534038] usb 2-1.1: New USB device strings: Mfr=1, Product=2, SerialNumber=3 [ 111.534040] usb 2-1.1: Product: Vendor [ 111.534041] usb 2-1.1: Manufacturer: Aptiv [ 111.534042] usb 2-1.1: SerialNumber: Superior [ 111.535175] usb 2-1.1: New USB device found, VID=2996, PID=0120 [ 111.610995] usb 2-1.5: new high-speed USB device number 8 using xhci-hcd [ 111.630052] usb 2-1.5: New USB device found, idVendor=2996, idProduct=0105, bcdDevice=21.02 [ 111.630055] usb 2-1.5: New USB device strings: Mfr=1, Product=2, SerialNumber=3 [ 111.630057] usb 2-1.5: Product: H2H Bridge [ 111.630058] usb 2-1.5: Manufacturer: Aptiv [ 111.630059] usb 2-1.5: SerialNumber: 13FEB2021 [ 111.687464] usb 2-1.5: New USB device found, VID=2996, PID=0105 [ 111.690375] dabridge 2-1.5:1.0: dabridge 2-8 total endpoints=5, 000000000d87c961 [ 111.691172] dabridge 2-1.5:1.0: P(0105) D(22.06.22) F(17.3.16) H(1.1) high-speed [ 111.691176] dabridge 2-1.5:1.0: Hub 2-6 P(0151) V(06.87) [ 111.691646] dabridge 2-1.5:1.0: All downstream ports in host mode
[ 111.692298] gadget 00000000dc72f7a9 --------> new gadget ptr on connect
* NCM opts and associated gadget pointer during second ncm_bind
[ 113.271786] NCM opts 00000000aa304ac9 -----> same opts ptr used during first bind
[ 113.271788] NCM gadget 00000000dc72f7a9 ----> however new gaget ptr, that will not set
in net_device due to ncm_opts->bound = true--- drivers/usb/gadget/function/f_ncm.c | 27 +++++++++++---------------- 1 file changed, 11 insertions(+), 16 deletions(-)
drivers/usb/gadget/function/f_ncm.c +11 -16
@@ -1425,7 +1425,7 @@ static int ncm_bind(struct usb_configuration *c, struct usb_function *f)struct usb_composite_dev *cdev = c->cdev;struct f_ncm *ncm =func_to_ncm (f);struct usb_string *us; -int status; +int status =0 ;struct usb_ep *ep;struct f_ncm_opts *ncm_opts;
@@ -1443,22 +1443,17 @@ static int ncm_bind(struct usb_configuration *c, struct usb_function *f) f->os_desc_table[0 ].os_desc = &ncm_opts->ncm_os_desc; } -/* -* in drivers/usb/gadget/configfs.c:configfs_composite_bind() -* configurations are bound in sequence with list_for_each_entry, -* in each configuration its functions are bound in sequence -* with list_for_each_entry, so we assume no race condition -* with regard to ncm_opts->bound access -*/ -if (!ncm_opts->bound) { -mutex_lock (&ncm_opts->lock); -gether_set_gadget (ncm_opts->net, cdev->gadget); +mutex_lock (&ncm_opts->lock); +gether_set_gadget (ncm_opts->net, cdev->gadget); +if (!ncm_opts->bound) status =gether_register_netdev (ncm_opts->net); -mutex_unlock (&ncm_opts->lock); -if (status) - goto fail; - ncm_opts->bound = true; - } +mutex_unlock (&ncm_opts->lock); + +if (status) + goto fail; + + ncm_opts->bound = true; + us =usb_gstrings_attach (cdev, ncm_strings,ARRAY_SIZE (ncm_string_defs));if (IS_ERR (us)) {
Signature · 1 line
2.42.0
Greg Kroah-Hartman
maintainerPATCH 125/491 9p/trans_fd: Annotate data-racy writes to file::f_flags
In reply to Greg Kroah-Hartman6.5-stable review patch. If anyone has any objections, please let me know.
------------------
From: Marco Elver <[email protected]>
[ Upstream commit 355f074609dbf3042900ea9d30fcd2b0c323a365 ]
syzbot reported:
| BUG: KCSAN: data-race in p9_fd_create / p9_fd_create | | read-write to 0xffff888130fb3d48 of 4 bytes by task 15599 on cpu 0: | p9_fd_open net/9p/trans_fd.c:842 [inline] | p9_fd_create+0x210/0x250 net/9p/trans_fd.c:1092 | p9_client_create+0x595/0xa70 net/9p/client.c:1010 | v9fs_session_init+0xf9/0xd90 fs/9p/v9fs.c:410 | v9fs_mount+0x69/0x630 fs/9p/vfs_super.c:123 | legacy_get_tree+0x74/0xd0 fs/fs_context.c:611 | vfs_get_tree+0x51/0x190 fs/super.c:1519 | do_new_mount+0x203/0x660 fs/namespace.c:3335 | path_mount+0x496/0xb30 fs/namespace.c:3662 | do_mount fs/namespace.c:3675 [inline] | __do_sys_mount fs/namespace.c:3884 [inline] | [...] | | read-write to 0xffff888130fb3d48 of 4 bytes by task 15563 on cpu 1: | p9_fd_open net/9p/trans_fd.c:842 [inline] | p9_fd_create+0x210/0x250 net/9p/trans_fd.c:1092 | p9_client_create+0x595/0xa70 net/9p/client.c:1010 | v9fs_session_init+0xf9/0xd90 fs/9p/v9fs.c:410 | v9fs_mount+0x69/0x630 fs/9p/vfs_super.c:123 | legacy_get_tree+0x74/0xd0 fs/fs_context.c:611 | vfs_get_tree+0x51/0x190 fs/super.c:1519 | do_new_mount+0x203/0x660 fs/namespace.c:3335 | path_mount+0x496/0xb30 fs/namespace.c:3662 | do_mount fs/namespace.c:3675 [inline] | __do_sys_mount fs/namespace.c:3884 [inline] | [...] | | value changed: 0x00008002 -> 0x00008802
Within p9_fd_open(), O_NONBLOCK is added to f_flags of the read and write files. This may happen concurrently if e.g. mounting process modifies the fd in another thread.
Mark the plain read-modify-writes as intentional data-races, with the assumption that the result of executing the accesses concurrently will always result in the same result despite the accesses themselves not being atomic.
Message-ID: <[email protected]>
--- net/9p/trans_fd.c | 13 ++++++++++--- 1 file changed, 10 insertions(+), 3 deletions(-)
net/9p/trans_fd.c +10 -3
@@ -832,14 +832,21 @@ static int p9_fd_open(struct p9_client *client, int rfd, int wfd) goto out_free_ts;if (!(ts->rd->f_mode &FMODE_READ )) goto out_put_rd; -/* prevent workers from hanging on IO when fd is a pipe */ - ts->rd->f_flags |=O_NONBLOCK ; +/* Prevent workers from hanging on IO when fd is a pipe. +* It's technically possible for userspace or concurrent mounts to +* modify this flag concurrently, which will likely result in a +* broken filesystem. However, just having bad flags here should +* not crash the kernel or cause any other sort of bug, so mark this +* particular data race as intentional so that tooling (like KCSAN) +* can allow it and detect further problems. +*/ +data_race (ts->rd->f_flags |=O_NONBLOCK ); ts->wr =fget (wfd);if (!ts->wr) goto out_put_rd;if (!(ts->wr->f_mode &FMODE_WRITE )) goto out_put_wr; - ts->wr->f_flags |=O_NONBLOCK ; +data_race (ts->wr->f_flags |=O_NONBLOCK ); client->trans = ts; client->status = Connected;
Signature · 1 line
2.42.0
Greg Kroah-Hartman
maintainerPATCH 126/491 9p: v9fs_listxattr: fix %s null argument warning
In reply to Greg Kroah-Hartman6.5-stable review patch. If anyone has any objections, please let me know.
------------------
From: Dominique Martinet <[email protected]>
[ Upstream commit 9b5c6281838fc84683dd99b47302d81fce399918 ]
W=1 warns about null argument to kprintf:
In file included from fs/9p/xattr.c:12:
In function ‘v9fs_xattr_get’,
inlined from ‘v9fs_listxattr’ at fs/9p/xattr.c:142:9:include/net/9p/9p.h:55:2: error: ‘%s’ directive argument is null [-Werror=format-overflow=]
55 | _p9_debug(level, __func__, fmt, ##__VA_ARGS__)
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~Use an empty string instead of :
- this is ok 9p-wise because p9pdu_vwritef serializes a null string
and an empty string the same way (one '0' word for length)
- since this degrades the print statements, add new single quotes for
xattr's name delimter (Old: "file = (null)", new: "file = ''")
Message-ID: <[email protected]>
--- fs/9p/xattr.c | 5 +++-- net/9p/client.c | 2 +- 2 files changed, 4 insertions(+), 3 deletions(-)
fs/9p/xattr.c +3 -2
@@ -68,7 +68,7 @@ ssize_t v9fs_xattr_get(struct dentry *dentry, const char *name,struct p9_fid *fid;int ret; -p9_debug (P9_DEBUG_VFS ,"name = %s value_len = %zu\n" , +p9_debug (P9_DEBUG_VFS ,"name = '%s' value_len = %zu\n" , name, buffer_size); fid =v9fs_fid_lookup (dentry);if (IS_ERR (fid))
@@ -139,7 +139,8 @@ int v9fs_fid_xattr_set(struct p9_fid *fid, const char *name,ssize_t v9fs_listxattr (struct dentry *dentry,char *buffer,size_t buffer_size) { -return v9fs_xattr_get (dentry,NULL , buffer, buffer_size); +/* Txattrwalk with an empty string lists xattrs instead */ +return v9fs_xattr_get (dentry,"" , buffer, buffer_size); } static int v9fs_xattr_handler_get(const struct xattr_handler *handler,
net/9p/client.c +1 -1
@@ -1981,7 +1981,7 @@ struct p9_fid *p9_client_xattrwalk(struct p9_fid *file_fid, goto error; }p9_debug (P9_DEBUG_9P , -">>> TXATTRWALK file_fid %d, attr_fid %d name %s\n" , +">>> TXATTRWALK file_fid %d, attr_fid %d name '%s'\n" , file_fid->fid, attr_fid->fid, attr_name); req = p9_client_rpc(clnt, P9_TXATTRWALK, "dds",
Signature · 1 line
2.42.0
Greg Kroah-Hartman
maintainerPATCH 127/491 i3c: mipi-i3c-hci: Fix out of bounds access in hci_dma_irq_handler
In reply to Greg Kroah-Hartman6.5-stable review patch. If anyone has any objections, please let me know.
------------------
From: Jarkko Nikula <[email protected]>
[ Upstream commit 45a832f989e520095429589d5b01b0c65da9b574 ]
Do not loop over ring headers in hci_dma_irq_handler() that are not allocated and enabled in hci_dma_init(). Otherwise out of bounds access will occur from rings->headers[i] access when i >= number of allocated ring headers.
--- drivers/i3c/master/mipi-i3c-hci/dma.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/i3c/master/mipi-i3c-hci/dma.c +1 -1
@@ -734,7 +734,7 @@ static bool hci_dma_irq_handler(struct i3c_hci *hci, unsigned int mask)unsigned int i;bool handled = false; -for (i =0 ; mask && i <8 ; i++) { +for (i =0 ; mask && i < rings->total; i++) {struct hci_rh_data *rh;u32 status;
Signature · 1 line
2.42.0
Greg Kroah-Hartman
maintainerPATCH 128/491 i2c: i801: Add support for Intel Birch Stream SoC
In reply to Greg Kroah-Hartman6.5-stable review patch. If anyone has any objections, please let me know.
------------------
From: Jarkko Nikula <[email protected]>
[ Upstream commit 8c56f9ef25a33e51f09a448d25cf863b61c9658d ]
Add SMBus PCI ID on Intel Birch Stream SoC.
--- Documentation/i2c/busses/i2c-i801.rst | 1 + drivers/i2c/busses/Kconfig | 1 + drivers/i2c/busses/i2c-i801.c | 3 +++ 3 files changed, 5 insertions(+)
Documentation/i2c/busses/i2c-i801.rst +1 -0
@@ -47,6 +47,7 @@ Supported adapters: * Intel Alder Lake (PCH) * Intel Raptor Lake (PCH) * Intel Meteor Lake (SOC and PCH) + * Intel Birch Stream (SOC) Datasheets: Publicly available at the Intel website
drivers/i2c/busses/Kconfig +1 -0
@@ -158,6 +158,7 @@ config I2C_I801 Alder Lake (PCH) Raptor Lake (PCH) Meteor Lake (SOC and PCH) + Birch Stream (SOC) This driver can also be built as a module. If so, the module will be called i2c-i801.
drivers/i2c/busses/i2c-i801.c +3 -0
@@ -79,6 +79,7 @@* Meteor Lake-P (SOC) 0x7e22 32 hard yes yes yes * Meteor Lake SoC-S (SOC) 0xae22 32 hard yes yes yes * Meteor Lake PCH-S (PCH) 0x7f23 32 hard yes yes yes +* Birch Stream (SOC) 0x5796 32 hard yes yes yes * * Features supported by this driver: * Software PEC no
@@ -231,6 +232,7 @@#define PCI_DEVICE_ID_INTEL_JASPER_LAKE_SMBUS 0x4da3#define PCI_DEVICE_ID_INTEL_ALDER_LAKE_P_SMBUS 0x51a3#define PCI_DEVICE_ID_INTEL_ALDER_LAKE_M_SMBUS 0x54a3 +#define PCI_DEVICE_ID_INTEL_BIRCH_STREAM_SMBUS 0x5796#define PCI_DEVICE_ID_INTEL_BROXTON_SMBUS 0x5ad4#define PCI_DEVICE_ID_INTEL_RAPTOR_LAKE_S_SMBUS 0x7a23#define PCI_DEVICE_ID_INTEL_ALDER_LAKE_S_SMBUS 0x7aa3
@@ -1044,6 +1046,7 @@ static const struct pci_device_id i801_ids[] = { { PCI_DEVICE_DATA(INTEL, METEOR_LAKE_P_SMBUS, FEATURES_ICH5 | FEATURE_TCO_CNL) }, { PCI_DEVICE_DATA(INTEL, METEOR_LAKE_SOC_S_SMBUS, FEATURES_ICH5 | FEATURE_TCO_CNL) }, { PCI_DEVICE_DATA(INTEL, METEOR_LAKE_PCH_S_SMBUS, FEATURES_ICH5 | FEATURE_TCO_CNL) }, + { PCI_DEVICE_DATA(INTEL, BIRCH_STREAM_SMBUS, FEATURES_ICH5 | FEATURE_TCO_CNL) }, { 0, } };
Signature · 1 line
2.42.0
Greg Kroah-Hartman
maintainerPATCH 129/491 i2c: fix memleak in i2c_new_client_device()
In reply to Greg Kroah-Hartman6.5-stable review patch. If anyone has any objections, please let me know.
------------------
From: Wolfram Sang <[email protected]>
[ Upstream commit 6af79f7fe748fe6a3c5c3a63d7f35981a82c2769 ]
Yang Yingliang reported a memleak:
===
I got memory leak as follows when doing fault injection test:
unreferenced object 0xffff888014aec078 (size 8):
comm "xrun", pid 356, jiffies 4294910619 (age 16.332s) hex dump (first 8 bytes):
31 2d 30 30 31 63 00 00 1-001c..
backtrace:
[<00000000eb56c0a9>] __kmalloc_track_caller+0x1a6/0x300
[<000000000b220ea3>] kvasprintf+0xad/0x140
[<00000000b83203e5>] kvasprintf_const+0x62/0x190
[<000000002a5eab37>] kobject_set_name_vargs+0x56/0x140
[<00000000300ac279>] dev_set_name+0xb0/0xe0
[<00000000b66ebd6f>] i2c_new_client_device+0x7e4/0x9a0If device_register() returns error in i2c_new_client_device(), the name allocated by i2c_dev_set_name() need be freed. As comment of device_register() says, it should use put_device() to give up the reference in the error path.
===
I think this solution is less intrusive and more robust than he originally proposed solutions, though.
--- drivers/i2c/i2c-core-base.c | 13 +++++++++---- 1 file changed, 9 insertions(+), 4 deletions(-)
drivers/i2c/i2c-core-base.c +9 -4
@@ -931,8 +931,9 @@ int i2c_dev_irq_from_resources(const struct resource *resources,struct i2c_client *i2c_new_client_device (struct i2c_adapter *adap,struct i2c_board_info const *info) { -struct i2c_client *client; -int status; +struct i2c_client *client; +bool need_put = false; +int status; client =kzalloc (sizeof *client,GFP_KERNEL );if (!client)
@@ -970,7 +971,6 @@ i2c_new_client_device(struct i2c_adapter *adap, struct i2c_board_info const *inf client->dev.fwnode = info->fwnode;device_enable_async_suspend (&client->dev); -i2c_dev_set_name (adap, client, info);if (info->swnode) { status =device_add_software_node (&client->dev, info->swnode);
@@ -982,6 +982,7 @@ i2c_new_client_device(struct i2c_adapter *adap, struct i2c_board_info const *inf } } +i2c_dev_set_name (adap, client, info); status =device_register (&client->dev);if (status) goto out_remove_swnode;
@@ -993,6 +994,7 @@ i2c_new_client_device(struct i2c_adapter *adap, struct i2c_board_info const *inf out_remove_swnode:device_remove_software_node (&client->dev); + need_put = true; out_err_put_of_node:of_node_put (info->of_node); out_err:
@@ -1000,7 +1002,10 @@ i2c_new_client_device(struct i2c_adapter *adap, struct i2c_board_info const *inf"Failed to register i2c client %s at 0x%02x (%d)\n" , client->name, client->addr, status); out_err_silent: -kfree (client); +if (need_put) +put_device (&client->dev); +else +kfree (client);return ERR_PTR (status); }EXPORT_SYMBOL_GPL (i2c_new_client_device);
Signature · 1 line
2.42.0
Greg Kroah-Hartman
maintainerPATCH 130/491 i2c: sun6i-p2wi: Prevent potential division by zero
In reply to Greg Kroah-Hartman6.5-stable review patch. If anyone has any objections, please let me know.
------------------
From: Axel Lin <[email protected]>
[ Upstream commit 5ac61d26b8baff5b2e5a9f3dc1ef63297e4b53e7 ]
Make sure we don't OOPS in case clock-frequency is set to 0 in a DT. The variable set here is later used as a divisor.
--- drivers/i2c/busses/i2c-sun6i-p2wi.c | 5 +++++ 1 file changed, 5 insertions(+)
drivers/i2c/busses/i2c-sun6i-p2wi.c +5 -0
@@ -201,6 +201,11 @@ static int p2wi_probe(struct platform_device *pdev)return -EINVAL ; } +if (clk_freq ==0 ) { +dev_err (dev,"clock-frequency is set to 0 in DT\n" ); +return -EINVAL ; + } +if (of_get_child_count (np) >1 ) {dev_err (dev,"P2WI only supports one slave device\n" );return -EINVAL ;
Signature · 1 line
2.42.0
Greg Kroah-Hartman
maintainerPATCH 131/491 virtio-blk: fix implicit overflow on virtio_max_dma_size
In reply to Greg Kroah-Hartman6.5-stable review patch. If anyone has any objections, please let me know.
------------------
From: zhenwei pi <[email protected]>
[ Upstream commit fafb51a67fb883eb2dde352539df939a251851be ]
The following codes have an implicit conversion from size_t to u32:
(u32)max_size = (size_t)virtio_max_dma_size(vdev);
This may lead overflow, Ex (size_t)4G -> (u32)0. Once virtio_max_dma_size() has a larger size than U32_MAX, use U32_MAX instead.
Message-Id: <[email protected]>
--- drivers/block/virtio_blk.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-)
drivers/block/virtio_blk.c +3 -1
@@ -1313,6 +1313,7 @@ static int virtblk_probe(struct virtio_device *vdev)u16 min_io_size;u8 physical_block_exp, alignment_offset;unsigned int queue_depth; +size_t max_dma_size;if (!vdev->config->get) { dev_err(&vdev->dev, "%s failure: config access disabled\n",
@@ -1411,7 +1412,8 @@ static int virtblk_probe(struct virtio_device *vdev)/* No real sector limit. */ blk_queue_max_hw_sectors (q,UINT_MAX ); - max_size =virtio_max_dma_size (vdev); + max_dma_size =virtio_max_dma_size (vdev); + max_size = max_dma_size >U32_MAX ?U32_MAX : max_dma_size;/* Host can optionally specify maximum segment size and number of * segments. */
Signature · 1 line
2.42.0
Greg Kroah-Hartman
maintainerPATCH 132/491 i3c: master: mipi-i3c-hci: Fix a kernel panic for accessing DAT_data.
In reply to Greg Kroah-Hartman6.5-stable review patch. If anyone has any objections, please let me know.
------------------
From: Billy Tsai <[email protected]>
[ Upstream commit b53e9758a31c683fc8615df930262192ed5f034b ]
The i3c_master_bus_init function may attach the I2C devices before the I3C bus initialization. In this flow, the DAT `alloc_entry`` will be used before the DAT init. Additionally, if the i3c_master_bus_init fails, the DAT cleanup will execute before the device is detached, which will execue DAT free_entry function. The above scenario can cause the driver to use DAT_data when it is NULL.
--- drivers/i3c/master/mipi-i3c-hci/dat_v1.c | 29 ++++++++++++++++-------- 1 file changed, 19 insertions(+), 10 deletions(-)
drivers/i3c/master/mipi-i3c-hci/dat_v1.c +19 -10
@@ -64,15 +64,17 @@ static int hci_dat_v1_init(struct i3c_hci *hci)return -EOPNOTSUPP ; } -/* use a bitmap for faster free slot search */ - hci->DAT_data =bitmap_zalloc (hci->DAT_entries,GFP_KERNEL ); -if (!hci->DAT_data) -return -ENOMEM ; - -/* clear them */ -for (dat_idx =0 ; dat_idx < hci->DAT_entries; dat_idx++) { -dat_w0_write (dat_idx,0 ); -dat_w1_write (dat_idx,0 ); +if (!hci->DAT_data) { +/* use a bitmap for faster free slot search */ + hci->DAT_data =bitmap_zalloc (hci->DAT_entries,GFP_KERNEL ); +if (!hci->DAT_data) +return -ENOMEM ; + +/* clear them */ +for (dat_idx =0 ; dat_idx < hci->DAT_entries; dat_idx++) { +dat_w0_write (dat_idx,0 ); +dat_w1_write (dat_idx,0 ); + } }return 0 ;
@@ -87,7 +89,13 @@ static void hci_dat_v1_cleanup(struct i3c_hci *hci)static int hci_dat_v1_alloc_entry (struct i3c_hci *hci) {unsigned int dat_idx; +int ret; +if (!hci->DAT_data) { + ret =hci_dat_v1_init (hci); +if (ret) +return ret; + } dat_idx =find_first_zero_bit (hci->DAT_data, hci->DAT_entries);if (dat_idx >= hci->DAT_entries)return -ENOENT ;
@@ -103,7 +111,8 @@ static void hci_dat_v1_free_entry(struct i3c_hci *hci, unsigned int dat_idx) {dat_w0_write (dat_idx,0 );dat_w1_write (dat_idx,0 ); -__clear_bit (dat_idx, hci->DAT_data); +if (hci->DAT_data) +__clear_bit (dat_idx, hci->DAT_data); } static void hci_dat_v1_set_dynamic_addr(struct i3c_hci *hci,
Signature · 1 line
2.42.0
Greg Kroah-Hartman
maintainerPATCH 133/491 media: gspca: cpia1: shift-out-of-bounds in set_flicker
In reply to Greg Kroah-Hartman6.5-stable review patch. If anyone has any objections, please let me know.
------------------
From: Rajeshwar R Shinde <[email protected]>
[ Upstream commit 099be1822d1f095433f4b08af9cc9d6308ec1953 ]
Syzkaller reported the following issue:
UBSAN: shift-out-of-bounds in drivers/media/usb/gspca/cpia1.c:1031:27
shift exponent 245 is too large for 32-bit type 'int'
When the value of the variable "sd->params.exposure.gain" exceeds the number of bits in an integer, a shift-out-of-bounds error is reported. It is triggered because the variable "currentexp" cannot be left-shifted by more than the number of bits in an integer. In order to avoid invalid range during left-shift, the conditional expression is added.
--- drivers/media/usb/gspca/cpia1.c | 3 +++ 1 file changed, 3 insertions(+)
drivers/media/usb/gspca/cpia1.c +3 -0
@@ -18,6 +18,7 @@#include <linux/input.h> #include <linux/sched/signal.h> +#include <linux/bitops.h> #include "gspca.h"
@@ -1028,6 +1029,8 @@ static int set_flicker(struct gspca_dev *gspca_dev, int on, int apply) sd->params.exposure.expMode =2 ; sd->exposure_status =EXPOSURE_NORMAL ; } +if (sd->params.exposure.gain >=BITS_PER_TYPE (currentexp)) +return -EINVAL ; currentexp = currentexp << sd->params.exposure.gain; sd->params.exposure.gain =0 ;/* round down current exposure to nearest value */
Signature · 1 line
2.42.0
Greg Kroah-Hartman
maintainerPATCH 134/491 media: vivid: avoid integer overflow
In reply to Greg Kroah-Hartman6.5-stable review patch. If anyone has any objections, please let me know.
------------------
From: Hans Verkuil <[email protected]>
[ Upstream commit 4567ebf8e8f9546b373e78e3b7d584cc30b62028 ]
Fixes these compiler warnings:
drivers/media/test-drivers/vivid/vivid-rds-gen.c: In function 'vivid_rds_gen_fill':drivers/media/test-drivers/vivid/vivid-rds-gen.c:147:56: warning: '.' directive output may be truncated writing 1 byte into a region of size between 0 and 3 [-Wformat-truncation=]
147 | snprintf(rds->psname, sizeof(rds->psname), "%6d.%1d",
| ^drivers/media/test-drivers/vivid/vivid-rds-gen.c:147:52: note: directive argument in the range [0, 9]
147 | snprintf(rds->psname, sizeof(rds->psname), "%6d.%1d",
| ^~~~~~~~~drivers/media/test-drivers/vivid/vivid-rds-gen.c:147:9: note: 'snprintf' output between 9 and 12 bytes into a destination of size 9
147 | snprintf(rds->psname, sizeof(rds->psname), "%6d.%1d",
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
148 | freq / 16, ((freq & 0xf) * 10) / 16);
| ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~--- drivers/media/test-drivers/vivid/vivid-rds-gen.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/media/test-drivers/vivid/vivid-rds-gen.c +1 -1
@@ -145,7 +145,7 @@ void vivid_rds_gen_fill(struct vivid_rds_gen *rds, unsigned freq, rds->ta = alt; rds->ms = true;snprintf (rds->psname,sizeof (rds->psname),"%6d.%1d" , - freq /16 , ((freq &0xf ) *10 ) /16 ); + (freq /16 ) %1000000 , (((freq &0xf ) *10 ) /16 ) %10 );if (alt) strscpy(rds->radiotext, " The Radio Data System can switch between different Radio Texts ",
Signature · 1 line
2.42.0
Greg Kroah-Hartman
maintainerPATCH 135/491 media: ipu-bridge: increase sensor_name size
In reply to Greg Kroah-Hartman6.5-stable review patch. If anyone has any objections, please let me know.
------------------
From: Hans Verkuil <[email protected]>
[ Upstream commit 83d0d4cc1423194b580356966107379490edd02e ]
Fixes this compiler warning:
In file included from include/linux/property.h:14,
from include/linux/acpi.h:16,
from drivers/media/pci/intel/ipu-bridge.c:4:
In function 'ipu_bridge_init_swnode_names',
inlined from 'ipu_bridge_create_connection_swnodes' at drivers/media/pci/intel/ipu-bridge.c:445:2,
inlined from 'ipu_bridge_connect_sensor' at drivers/media/pci/intel/ipu-bridge.c:656:3:include/linux/fwnode.h:81:49: warning: '%u' directive output may be truncated writing between 1 and 3 bytes into a region of size 2 [-Wformat-truncation=]
81 | #define SWNODE_GRAPH_PORT_NAME_FMT "port@%u"
| ^~~~~~~~~
drivers/media/pci/intel/ipu-bridge.c:384:18: note: in expansion of macro 'SWNODE_GRAPH_PORT_NAME_FMT'
384 | SWNODE_GRAPH_PORT_NAME_FMT, sensor->link);
| ^~~~~~~~~~~~~~~~~~~~~~~~~~include/linux/fwnode.h: In function 'ipu_bridge_connect_sensor':include/linux/fwnode.h:81:55: note: format string is defined here
81 | #define SWNODE_GRAPH_PORT_NAME_FMT "port@%u"
| ^~
In function 'ipu_bridge_init_swnode_names',
inlined from 'ipu_bridge_create_connection_swnodes' at drivers/media/pci/intel/ipu-bridge.c:445:2, inlined from 'ipu_bridge_connect_sensor' at drivers/media/pci/intel/ipu-bridge.c:656:3:include/linux/fwnode.h:81:49: note: directive argument in the range [0, 255]
81 | #define SWNODE_GRAPH_PORT_NAME_FMT "port@%u"
| ^~~~~~~~~
drivers/media/pci/intel/ipu-bridge.c:384:18: note: in expansion of macro 'SWNODE_GRAPH_PORT_NAME_FMT'
384 | SWNODE_GRAPH_PORT_NAME_FMT, sensor->link);
| ^~~~~~~~~~~~~~~~~~~~~~~~~~
drivers/media/pci/intel/ipu-bridge.c:382:9: note: 'snprintf' output between 7 and 9 bytes into a destination of size 7
382 | snprintf(sensor->node_names.remote_port,
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
383 | sizeof(sensor->node_names.remote_port),
| ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
384 | SWNODE_GRAPH_PORT_NAME_FMT, sensor->link);
| ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~--- drivers/media/pci/intel/ipu-bridge.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/media/pci/intel/ipu-bridge.h +1 -1
@@ -103,7 +103,7 @@ struct ipu_property_names {struct ipu_node_names {char port[7 ];char endpoint[11 ]; -char remote_port[7 ]; +char remote_port[9 ];char vcm[16 ]; };
Signature · 1 line
2.42.0
Greg Kroah-Hartman
maintainerPATCH 136/491 gfs2: ignore negated quota changes
In reply to Greg Kroah-Hartman6.5-stable review patch. If anyone has any objections, please let me know.
------------------
From: Bob Peterson <[email protected]>
[ Upstream commit 4c6a08125f2249531ec01783a5f4317d7342add5 ]
When lots of quota changes are made, there may be cases in which an inode's quota information is increased and then decreased, such as when blocks are added to a file, then deleted from it. If the timing is right, function do_qc can add pending quota changes to a transaction, then later, another call to do_qc can negate those changes, resulting in a net gain of 0. The quota_change information is recorded in the qc buffer (and qd element of the inode as well). The buffer is added to the transaction by the first call to do_qc, but a subsequent call changes the value from non-zero back to zero. At that point it's too late to remove the buffer_head from the transaction. Later, when the quota sync code is called, the zero-change qd element is discovered and flagged as an assert warning. If the fs is mounted with errors=panic, the kernel will panic.
This is usually seen when files are truncated and the quota changes are negated by punch_hole/truncate which uses gfs2_quota_hold and gfs2_quota_unhold rather than block allocations that use gfs2_quota_lock and gfs2_quota_unlock which automatically do quota sync.
This patch solves the problem by adding a check to qd_check_sync such that net-zero quota changes already added to the transaction are no longer deemed necessary to be synced, and skipped.
In this case references are taken for the qd and the slot from do_qc so those need to be put. The normal sequence of events for a normal non-zero quota change is as follows:
gfs2_quota_change
do_qc
qd_hold
slot_hold
Later, when the changes are to be synced:
gfs2_quota_sync
qd_fish
qd_check_sync
gets qd ref via lockref_get_not_dead
do_sync
do_qc(QC_SYNC)
qd_put
lockref_put_or_lock qd_unlock
qd_put
lockref_put_or_lock
In the net-zero change case, we add a check to qd_check_sync so it puts the qd and slot references acquired in gfs2_quota_change and skip the unneeded sync.
--- fs/gfs2/quota.c | 11 +++++++++++ 1 file changed, 11 insertions(+)
fs/gfs2/quota.c +11 -0
@@ -441,6 +441,17 @@ static int qd_check_sync(struct gfs2_sbd *sdp, struct gfs2_quota_data *qd, (sync_gen && (qd->qd_sync_gen >= *sync_gen)))return 0 ; +/* +* If qd_change is 0 it means a pending quota change was negated. +* We should not sync it, but we still have a qd reference and slot +* reference taken by gfs2_quota_change -> do_qc that need to be put. +*/ +if (!qd->qd_change &&test_and_clear_bit (QDF_CHANGE , &qd->qd_flags)) { +slot_put (qd); +qd_put (qd); +return 0 ; + } +if (!lockref_get_not_dead (&qd->qd_lockref))return 0 ;
Signature · 1 line
2.42.0
Greg Kroah-Hartman
maintainerPATCH 137/491 gfs2: fix an oops in gfs2_permission
In reply to Greg Kroah-Hartman6.5-stable review patch. If anyone has any objections, please let me know.
------------------
From: Al Viro <[email protected]>
[ Upstream commit 0abd1557e21c617bd13fc18f7725fc6363c05913 ]
In RCU mode, we might race with gfs2_evict_inode(), which zeroes ->i_gl. Freeing of the object it points to is RCU-delayed, so if we manage to fetch the pointer before it's been replaced with NULL, we are fine. Check if we'd fetched NULL and treat that as "bail out and tell the caller to get out of RCU mode".
--- fs/gfs2/inode.c | 11 +++++++++-- fs/gfs2/super.c | 2 +- 2 files changed, 10 insertions(+), 3 deletions(-)
fs/gfs2/inode.c +9 -2
@@ -1862,14 +1862,21 @@ int gfs2_permission(struct mnt_idmap *idmap, struct inode *inode, {struct gfs2_inode *ip;struct gfs2_holder i_gh; +struct gfs2_glock *gl;int error;gfs2_holder_mark_uninitialized (&i_gh); ip =GFS2_I (inode); -if (gfs2_glock_is_locked_by_me (ip->i_gl) ==NULL ) { + gl =rcu_dereference (ip->i_gl); +if (unlikely (!gl)) { +/* inode is getting torn down, must be RCU mode */ +WARN_ON_ONCE (!(mask &MAY_NOT_BLOCK )); +return -ECHILD ; + } +if (gfs2_glock_is_locked_by_me (gl) ==NULL ) {if (mask &MAY_NOT_BLOCK )return -ECHILD ; - error =gfs2_glock_nq_init (ip->i_gl,LM_ST_SHARED ,LM_FLAG_ANY , &i_gh); + error =gfs2_glock_nq_init (gl,LM_ST_SHARED ,LM_FLAG_ANY , &i_gh);if (error)return error; }
fs/gfs2/super.c +1 -1
@@ -1558,7 +1558,7 @@ static void gfs2_evict_inode(struct inode *inode)wait_on_bit_io (&ip->i_flags,GIF_GLOP_PENDING ,TASK_UNINTERRUPTIBLE );gfs2_glock_add_to_lru (ip->i_gl);gfs2_glock_put_eventually (ip->i_gl); - ip->i_gl =NULL ; +rcu_assign_pointer (ip->i_gl,NULL ); } }
Signature · 1 line
2.42.0
Greg Kroah-Hartman
maintainerPATCH 138/491 media: cobalt: Use FIELD_GET() to extract Link Width
In reply to Greg Kroah-Hartman6.5-stable review patch. If anyone has any objections, please let me know.
------------------
From: Ilpo Järvinen <[email protected]>
[ Upstream commit f301fedbeecfdce91cb898d6fa5e62f269801fee ]
Use FIELD_GET() to extract PCIe Negotiated and Maximum Link Width fields instead of custom masking and shifting.
--- drivers/media/pci/cobalt/cobalt-driver.c | 11 ++++++----- 1 file changed, 6 insertions(+), 5 deletions(-)
drivers/media/pci/cobalt/cobalt-driver.c +6 -5
@@ -8,6 +8,7 @@* All rights reserved. */ +#include <linux/bitfield.h> #include <linux/delay.h> #include <media/i2c/adv7604.h> #include <media/i2c/adv7842.h>
@@ -210,17 +211,17 @@ void cobalt_pcie_status_show(struct cobalt *cobalt)pcie_capability_read_word (pci_dev,PCI_EXP_LNKSTA , &stat);cobalt_info ("PCIe link capability 0x%08x: %s per lane and %u lanes\n" , capa,get_link_speed (capa), - (capa &PCI_EXP_LNKCAP_MLW ) >>4 ); +FIELD_GET (PCI_EXP_LNKCAP_MLW , capa));cobalt_info ("PCIe link control 0x%04x\n" , ctrl);cobalt_info ("PCIe link status 0x%04x: %s per lane and %u lanes\n" , stat,get_link_speed (stat), - (stat &PCI_EXP_LNKSTA_NLW ) >>4 ); +FIELD_GET (PCI_EXP_LNKSTA_NLW , stat));/* Bus */ pcie_capability_read_dword (pci_bus_dev,PCI_EXP_LNKCAP , &capa);cobalt_info ("PCIe bus link capability 0x%08x: %s per lane and %u lanes\n" , capa,get_link_speed (capa), - (capa &PCI_EXP_LNKCAP_MLW ) >>4 ); +FIELD_GET (PCI_EXP_LNKCAP_MLW , capa));/* Slot */ pcie_capability_read_dword (pci_dev,PCI_EXP_SLTCAP , &capa);
@@ -239,7 +240,7 @@ static unsigned pcie_link_get_lanes(struct cobalt *cobalt)if (!pci_is_pcie (pci_dev))return 0 ;pcie_capability_read_word (pci_dev,PCI_EXP_LNKSTA , &link); -return (link &PCI_EXP_LNKSTA_NLW ) >>4 ; +return FIELD_GET (PCI_EXP_LNKSTA_NLW , link); }static unsigned pcie_bus_link_get_lanes (struct cobalt *cobalt)
@@ -250,7 +251,7 @@ static unsigned pcie_bus_link_get_lanes(struct cobalt *cobalt)if (!pci_is_pcie (pci_dev))return 0 ;pcie_capability_read_dword (pci_dev,PCI_EXP_LNKCAP , &link); -return (link &PCI_EXP_LNKCAP_MLW ) >>4 ; +return FIELD_GET (PCI_EXP_LNKCAP_MLW , link); }static void msi_config_show (struct cobalt *cobalt,struct pci_dev *pci_dev)
Signature · 1 line
2.42.0
Greg Kroah-Hartman
maintainerPATCH 139/491 media: ccs: Fix driver quirk struct documentation
In reply to Greg Kroah-Hartman6.5-stable review patch. If anyone has any objections, please let me know.
------------------
From: Sakari Ailus <[email protected]>
[ Upstream commit 441b5c63d71ec9ec5453328f7e83384ecc1dddd9 ]
Fix documentation for struct ccs_quirk, a device specific struct for managing deviations from the standard. The flags field was drifted away from where it should have been.
--- drivers/media/i2c/ccs/ccs-quirk.h | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-)
drivers/media/i2c/ccs/ccs-quirk.h +1 -3
@@ -32,12 +32,10 @@ struct ccs_sensor;* @reg: Pointer to the register to access * @value: Register value, set by the caller on write, or * by the quirk on read -* -* @flags: Quirk flags -* * @return: 0 on success, -ENOIOCTLCMD if no register * access may be done by the caller (default read * value is zero), else negative error code on error +* @flags: Quirk flags */ struct ccs_quirk {int (*limits)(struct ccs_sensor *sensor);
Signature · 1 line
2.42.0
Greg Kroah-Hartman
maintainerPATCH 140/491 media: imon: fix access to invalid resource for the second interface
In reply to Greg Kroah-Hartman6.5-stable review patch. If anyone has any objections, please let me know.
------------------
From: Takashi Iwai <[email protected]>
[ Upstream commit a1766a4fd83befa0b34d932d532e7ebb7fab1fa7 ]
imon driver probes two USB interfaces, and at the probe of the second interface, the driver assumes blindly that the first interface got bound with the same imon driver. It's usually true, but it's still possible that the first interface is bound with another driver via a malformed descriptor. Then it may lead to a memory corruption, as spotted by syzkaller; imon driver accesses the data from drvdata as struct imon_context object although it's a completely different one that was assigned by another driver.
This patch adds a sanity check -- whether the first interface is really bound with the imon driver or not -- for avoiding the problem above at the probe time.
--- drivers/media/rc/imon.c | 6 ++++++ 1 file changed, 6 insertions(+)
drivers/media/rc/imon.c +6 -0
@@ -2427,6 +2427,12 @@ static int imon_probe(struct usb_interface *interface, goto fail; } +if (first_if->dev.driver != interface->dev.driver) { +dev_err (&interface->dev,"inconsistent driver matching\n" ); + ret = -EINVAL ; + goto fail; + } +if (ifnum ==0 ) { ictx =imon_init_intf0 (interface, id);if (!ictx) {
Signature · 1 line
2.42.0
Greg Kroah-Hartman
maintainerPATCH 141/491 drm/amd/display: Avoid NULL dereference of timing generator
In reply to Greg Kroah-Hartman6.5-stable review patch. If anyone has any objections, please let me know.
------------------
From: Wayne Lin <[email protected]>
[ Upstream commit b1904ed480cee3f9f4036ea0e36d139cb5fee2d6 ]
[Why & How]
Check whether assigned timing generator is NULL or not before accessing its funcs to prevent NULL dereference.
--- drivers/gpu/drm/amd/display/dc/core/dc_stream.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
drivers/gpu/drm/amd/display/dc/core/dc_stream.c +2 -2
@@ -556,7 +556,7 @@ uint32_t dc_stream_get_vblank_counter(const struct dc_stream_state *stream)for (i =0 ; i <MAX_PIPES ; i++) {struct timing_generator *tg = res_ctx->pipe_ctx[i].stream_res.tg; -if (res_ctx->pipe_ctx[i].stream != stream) +if (res_ctx->pipe_ctx[i].stream != stream || !tg)continue ;return tg->funcs->get_frame_count (tg);
@@ -615,7 +615,7 @@ bool dc_stream_get_scanoutpos(const struct dc_stream_state *stream,for (i =0 ; i <MAX_PIPES ; i++) {struct timing_generator *tg = res_ctx->pipe_ctx[i].stream_res.tg; -if (res_ctx->pipe_ctx[i].stream != stream) +if (res_ctx->pipe_ctx[i].stream != stream || !tg)continue ; tg->funcs->get_scanoutpos(tg,
Signature · 1 line
2.42.0
Greg Kroah-Hartman
maintainerPATCH 142/491 kgdb: Flush console before entering kgdb on panic
In reply to Greg Kroah-Hartman6.5-stable review patch. If anyone has any objections, please let me know.
------------------
From: Douglas Anderson <[email protected]>
[ Upstream commit dd712d3d45807db9fcae28a522deee85c1f2fde6 ]
When entering kdb/kgdb on a kernel panic, it was be observed that the console isn't flushed before the kdb prompt came up. Specifically, when using the buddy lockup detector on arm64 and running:
echo HARDLOCKUP > /sys/kernel/debug/provoke-crash/DIRECT
I could see:
[ 26.161099] lkdtm: Performing direct entry HARDLOCKUP [ 32.499881] watchdog: Watchdog detected hard LOCKUP on cpu 6 [ 32.552865] Sending NMI from CPU 5 to CPUs 6: [ 32.557359] NMI backtrace for cpu 6 ... [backtrace for cpu 6] ... [ 32.558353] NMI backtrace for cpu 5 ... [backtrace for cpu 5] ... [ 32.867471] Sending NMI from CPU 5 to CPUs 0-4,7: [ 32.872321] NMI backtrace forP cpuANC: Hard LOCKUP
Entering kdb (current=..., pid 0) on processor 5 due to Keyboard Entry [5]kdb>
As you can see, backtraces for the other CPUs start printing and get interleaved with the kdb PANIC print.
Let's replicate the commands to flush the console in the kdb panic entry point to avoid this.
--- kernel/debug/debug_core.c | 3 +++ 1 file changed, 3 insertions(+)
kernel/debug/debug_core.c +3 -0
@@ -1006,6 +1006,9 @@ void kgdb_panic(const char *msg)if (panic_timeout)return ; +debug_locks_off (); +console_flush_on_panic (CONSOLE_FLUSH_PENDING ); +if (dbg_kdb_mode)kdb_printf ("PANIC: %s\n" , msg);
Signature · 1 line
2.42.0
Greg Kroah-Hartman
maintainerPATCH 143/491 riscv: VMAP_STACK overflow detection thread-safe
In reply to Greg Kroah-Hartman6.5-stable review patch. If anyone has any objections, please let me know.
------------------
From: Deepak Gupta <[email protected]>
[ Upstream commit be97d0db5f44c0674480cb79ac6f5b0529b84c76 ]
commit 31da94c25aea ("riscv: add VMAP_STACK overflow detection") added support for CONFIG_VMAP_STACK. If overflow is detected, CPU switches to shadow_stack temporarily before switching finally to per-cpu overflow_stack.
If two CPUs/harts are racing and end up in over flowing kernel stack, one or both will end up corrupting each other state because shadow_stack is not per-cpu. This patch optimizes per-cpu overflow stack switch by directly picking per-cpu overflow_stack and gets rid of shadow_stack.
Following are the changes in this patch
- Defines an asm macro to obtain per-cpu symbols in destination register.
- In entry.S, when overflow is detected, per-cpu overflow stack is located using per-cpu asm macro. Computing per-cpu symbol requires a temporary register. x31 is saved away into CSR_SCRATCH (CSR_SCRATCH is anyways zero since we're in kernel).
Please see Links for additional relevant disccussion and alternative solution.
Tested by echo EXHAUST_STACK > /sys/kernel/debug/provoke-crash/DIRECT Kernel crash log below
Insufficient stack space to handle exception!/debug/provoke-crash/DIRECT
Task stack: [0xff20000010a98000..0xff20000010a9c000]
Overflow stack: [0xff600001f7d98370..0xff600001f7d99370]
CPU: 1 PID: 205 Comm: bash Not tainted 6.1.0-rc2-00001-g328a1f96f7b9 #34 Hardware name: riscv-virtio,qemu (DT) epc : __memset+0x60/0xfc ra : recursive_loop+0x48/0xc6 [lkdtm] epc : ffffffff808de0e4 ra : ffffffff0163a752 sp : ff20000010a97e80 gp : ffffffff815c0330 tp : ff600000820ea280 t0 : ff20000010a97e88 t1 : 000000000000002e t2 : 3233206874706564 s0 : ff20000010a982b0 s1 : 0000000000000012 a0 : ff20000010a97e88 a1 : 0000000000000000 a2 : 0000000000000400 a3 : ff20000010a98288 a4 : 0000000000000000 a5 : 0000000000000000 a6 : fffffffffffe43f0 a7 : 00007fffffffffff s2 : ff20000010a97e88 s3 : ffffffff01644680 s4 : ff20000010a9be90 s5 : ff600000842ba6c0 s6 : 00aaaaaac29e42b0 s7 : 00fffffff0aa3684 s8 : 00aaaaaac2978040 s9 : 0000000000000065 s10: 00ffffff8a7cad10 s11: 00ffffff8a76a4e0 t3 : ffffffff815dbaf4 t4 : ffffffff815dbaf4 t5 : ffffffff815dbab8 t6 : ff20000010a9bb48 status: 0000000200000120 badaddr: ff20000010a97e88 cause: 000000000000000f Kernel panic - not syncing: Kernel stack overflow CPU: 1 PID: 205 Comm: bash Not tainted 6.1.0-rc2-00001-g328a1f96f7b9 #34 Hardware name: riscv-virtio,qemu (DT) Call Trace: [<ffffffff80006754>] dump_backtrace+0x30/0x38 [<ffffffff808de798>] show_stack+0x40/0x4c [<ffffffff808ea2a8>] dump_stack_lvl+0x44/0x5c [<ffffffff808ea2d8>] dump_stack+0x18/0x20 [<ffffffff808dec06>] panic+0x126/0x2fe [<ffffffff800065ea>] walk_stackframe+0x0/0xf0 [<ffffffff0163a752>] recursive_loop+0x48/0xc6 [lkdtm] SMP: stopping secondary CPUs ---[ end Kernel panic - not syncing: Kernel stack overflow ]---
--- arch/riscv/include/asm/asm-prototypes.h | 1 - arch/riscv/include/asm/asm.h | 22 ++++++++ arch/riscv/include/asm/thread_info.h | 3 -- arch/riscv/kernel/asm-offsets.c | 1 + arch/riscv/kernel/entry.S | 70 ++++--------------------- arch/riscv/kernel/traps.c | 36 +------------ 6 files changed, 34 insertions(+), 99 deletions(-)
arch/riscv/include/asm/asm-prototypes.h +0 -1
@@ -25,7 +25,6 @@ DECLARE_DO_ERROR_INFO(do_trap_ecall_s);DECLARE_DO_ERROR_INFO (do_trap_ecall_m);DECLARE_DO_ERROR_INFO (do_trap_break); -asmlinkage unsigned long get_overflow_stack (void ); asmlinkage void handle_bad_stack(struct pt_regs *regs); asmlinkage void do_page_fault(struct pt_regs *regs); asmlinkage void do_irq(struct pt_regs *regs);
arch/riscv/include/asm/asm.h +22 -0
@@ -82,6 +82,28 @@ .endr .endm +#ifdef CONFIG_SMP +#ifdef CONFIG_32BIT +#define PER_CPU_OFFSET_SHIFT 2 +#else +#define PER_CPU_OFFSET_SHIFT 3 +#endif + +.macro asm_per_cpu dst sym tmp + REG_L \tmp, TASK_TI_CPU_NUM(tp) + slli \tmp, \tmp, PER_CPU_OFFSET_SHIFT + la \dst, __per_cpu_offset + add \dst, \dst, \tmp + REG_L \tmp, 0(\dst) + la \dst, \sym + add \dst, \dst, \tmp +.endm +#else /* CONFIG_SMP */ +.macro asm_per_cpu dst sym tmp + la \dst, \sym +.endm +#endif /* CONFIG_SMP */ + /* save all GPs except x1 ~ x5 */ .macro save_from_x6_to_x31 REG_S x6, PT_T1(sp)
arch/riscv/include/asm/thread_info.h +0 -3
@@ -34,9 +34,6 @@#ifndef __ASSEMBLY__ -extern long shadow_stack[SHADOW_OVERFLOW_STACK_SIZE /sizeof (long )]; -extern unsigned long spin_shadow_stack; -#include <asm/processor.h> #include <asm/csr.h>
arch/riscv/kernel/asm-offsets.c +1 -0
@@ -39,6 +39,7 @@ void asm_offsets(void)OFFSET (TASK_TI_KERNEL_SP , task_struct, thread_info.kernel_sp);OFFSET (TASK_TI_USER_SP , task_struct, thread_info.user_sp); +OFFSET (TASK_TI_CPU_NUM , task_struct, thread_info.cpu);OFFSET (TASK_THREAD_F0 , task_struct, thread.fstate.f[0 ]);OFFSET (TASK_THREAD_F1 , task_struct, thread.fstate.f[1 ]);OFFSET (TASK_THREAD_F2 , task_struct, thread.fstate.f[2 ]);
arch/riscv/kernel/entry.S +10 -60
86 lines not on this page · raw message
arch/riscv/kernel/traps.c +1 -35
@@ -408,48 +408,14 @@ int is_valid_bugaddr(unsigned long pc)#endif /* CONFIG_GENERIC_BUG */ #ifdef CONFIG_VMAP_STACK -/* -* Extra stack space that allows us to provide panic messages when the kernel -* has overflowed its stack. -*/ -static DEFINE_PER_CPU(unsigned long [OVERFLOW_STACK_SIZE/sizeof(long)], +DEFINE_PER_CPU(unsigned long [OVERFLOW_STACK_SIZE/sizeof(long)], overflow_stack)__aligned(16); -/* -* A temporary stack for use by handle_kernel_stack_overflow. This is used so -* we can call into C code to get the per-hart overflow stack. Usage of this -* stack must be protected by spin_shadow_stack. -*/ -long shadow_stack[SHADOW_OVERFLOW_STACK_SIZE /sizeof (long )]__aligned(16) ; - -/* -* A pseudo spinlock to protect the shadow stack from being used by multiple -* harts concurrently. This isn't a real spinlock because the lock side must -* be taken without a valid stack and only a single register, it's only taken -* while in the process of panicing anyway so the performance and error -* checking a proper spinlock gives us doesn't matter. -*/ -unsigned long spin_shadow_stack; - -asmlinkage unsigned long get_overflow_stack (void ) -{ -return (unsigned long )this_cpu_ptr (overflow_stack) + -OVERFLOW_STACK_SIZE ; -} asmlinkage void handle_bad_stack(struct pt_regs *regs) {unsigned long tsk_stk = (unsigned long )current->stack;unsigned long ovf_stk = (unsigned long )this_cpu_ptr (overflow_stack); -/* -* We're done with the shadow stack by this point, as we're on the -* overflow stack. Tell any other concurrent overflowing harts that -* they can proceed with panicing by releasing the pseudo-spinlock. -* -* This pairs with an amoswap.aq in handle_kernel_stack_overflow. -*/ -smp_store_release (&spin_shadow_stack,0 ); -console_verbose ();pr_emerg ("Insufficient stack space to handle exception!\n" );
Signature · 1 line
2.42.0
Greg Kroah-Hartman
maintainerPATCH 144/491 i2c: dev: copy userspace array safely
In reply to Greg Kroah-Hartman6.5-stable review patch. If anyone has any objections, please let me know.
------------------
From: Philipp Stanner <[email protected]>
[ Upstream commit cc9c54232f04aef3a5d7f64a0ece7df00f1aaa3d ]
i2c-dev.c utilizes memdup_user() to copy a userspace array. This is done without an overflow check.
Use the new wrapper memdup_array_user() to copy the array more safely.
--- drivers/i2c/i2c-dev.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
drivers/i2c/i2c-dev.c +2 -2
@@ -450,8 +450,8 @@ static long i2cdev_ioctl(struct file *file, unsigned int cmd, unsigned long arg)if (rdwr_arg.nmsgs >I2C_RDWR_IOCTL_MAX_MSGS )return -EINVAL ; - rdwr_pa =memdup_user (rdwr_arg.msgs, - rdwr_arg.nmsgs *sizeof (struct i2c_msg )); + rdwr_pa =memdup_array_user (rdwr_arg.msgs, + rdwr_arg.nmsgs,sizeof (struct i2c_msg ));if (IS_ERR (rdwr_pa))return PTR_ERR (rdwr_pa);
Signature · 1 line
2.42.0
Greg Kroah-Hartman
maintainerPATCH 145/491 ASoC: ti: omap-mcbsp: Fix runtime PM underflow warnings
In reply to Greg Kroah-Hartman6.5-stable review patch. If anyone has any objections, please let me know.
------------------
From: Tony Lindgren <[email protected]>
[ Upstream commit fbb74e56378d8306f214658e3d525a8b3f000c5a ]
We need to check for an active device as otherwise we get warnings for some mcbsp instances for "Runtime PM usage count underflow!".
--- sound/soc/ti/omap-mcbsp.c | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-)
sound/soc/ti/omap-mcbsp.c +4 -2
@@ -74,14 +74,16 @@ static int omap2_mcbsp_set_clks_src(struct omap_mcbsp *mcbsp, u8 fck_src_id)return -EINVAL ; } -pm_runtime_put_sync (mcbsp->dev); +if (mcbsp->active) +pm_runtime_put_sync (mcbsp->dev); r =clk_set_parent (mcbsp->fclk, fck_src);if (r)dev_err (mcbsp->dev,"CLKS: could not clk_set_parent() to %s\n" , src); -pm_runtime_get_sync (mcbsp->dev); +if (mcbsp->active) +pm_runtime_get_sync (mcbsp->dev);clk_put (fck_src);
Signature · 1 line
2.42.0
Greg Kroah-Hartman
maintainerPATCH 146/491 drm/qxl: prevent memory leak
In reply to Greg Kroah-Hartman6.5-stable review patch. If anyone has any objections, please let me know.
------------------
From: Zongmin Zhou <[email protected]>
[ Upstream commit 0e8b9f258baed25f1c5672613699247c76b007b5 ]
The allocated memory for qdev->dumb_heads should be released in qxl_destroy_monitors_object before qxl suspend. otherwise,qxl_create_monitors_object will be called to reallocate memory for qdev->dumb_heads after qxl resume, it will cause memory leak.
--- drivers/gpu/drm/qxl/qxl_display.c | 3 +++ 1 file changed, 3 insertions(+)
drivers/gpu/drm/qxl/qxl_display.c +3 -0
@@ -1229,6 +1229,9 @@ int qxl_destroy_monitors_object(struct qxl_device *qdev)if (!qdev->monitors_config_bo)return 0 ; +kfree (qdev->dumb_heads); + qdev->dumb_heads =NULL ; + qdev->monitors_config =NULL ; qdev->ram_header->monitors_config =0 ;
Signature · 1 line
2.42.0
Greg Kroah-Hartman
maintainerPATCH 147/491 ALSA: hda/realtek: Add quirk for ASUS UX7602ZM
In reply to Greg Kroah-Hartman6.5-stable review patch. If anyone has any objections, please let me know.
------------------
From: Alex Spataru <[email protected]>
[ Upstream commit 26fd31ef9c02a5e91cdb8eea127b056bd7cf0b3b ]
Enables the SPI-connected CSC35L41 audio amplifier for this laptop model.
As of BIOS version 303 it's still necessary to modify the ACPI table to add the related _DSD properties:
https://github.com/alex-spataru/asus_zenbook_ux7602zm_sound/
--- sound/pci/hda/patch_realtek.c | 1 + 1 file changed, 1 insertion(+)
sound/pci/hda/patch_realtek.c +1 -0
@@ -9798,6 +9798,7 @@ static const struct snd_pci_quirk alc269_fixup_tbl[] = {SND_PCI_QUIRK (0x1043 ,0x1d4e ,"ASUS TM420" ,ALC256_FIXUP_ASUS_HPE ),SND_PCI_QUIRK (0x1043 ,0x1e02 ,"ASUS UX3402ZA" ,ALC245_FIXUP_CS35L41_SPI_2 ),SND_PCI_QUIRK (0x1043 ,0x16a3 ,"ASUS UX3402VA" ,ALC245_FIXUP_CS35L41_SPI_2 ), +SND_PCI_QUIRK (0x1043 ,0x1f62 ,"ASUS UX7602ZM" ,ALC245_FIXUP_CS35L41_SPI_2 ),SND_PCI_QUIRK (0x1043 ,0x1e11 ,"ASUS Zephyrus G15" ,ALC289_FIXUP_ASUS_GA502 ),SND_PCI_QUIRK (0x1043 ,0x1e12 ,"ASUS UM3402" ,ALC287_FIXUP_CS35L41_I2C_2 ), SND_PCI_QUIRK(0x1043, 0x1e51, "ASUS Zephyrus M15", ALC294_FIXUP_ASUS_GU502_PINS),
Signature · 1 line
2.42.0
Greg Kroah-Hartman
maintainerPATCH 148/491 drm/amdgpu: fix software pci_unplug on some chips
In reply to Greg Kroah-Hartman6.5-stable review patch. If anyone has any objections, please let me know.
------------------
From: Vitaly Prosyak <[email protected]>
[ Upstream commit 4638e0c29a3f2294d5de0d052a4b8c9f33ccb957 ]
When software 'pci unplug' using IGT is executed we got a sysfs directory entry is NULL for differant ras blocks like hdp, umc, etc. Before call 'sysfs_remove_file_from_group' and 'sysfs_remove_group' check that 'sd' is not NULL.
[ +0.000001] RIP: 0010:sysfs_remove_group+0x83/0x90 [ +0.000002] Code: 31 c0 31 d2 31 f6 31 ff e9 9a a8 b4 00 4c 89 e7 e8 f2 a2 ff ff eb c2 49 8b 55 00 48 8b 33 48 c7 c7 80 65 94 82 e8 cd 82 bb ff <0f> 0b eb cc 66 0f 1f 84 00 00 00 00 00 90 90 90 90 90 90 90 90 90 [ +0.000001] RSP: 0018:ffffc90002067c90 EFLAGS: 00010246 [ +0.000002] RAX: 0000000000000000 RBX: ffffffff824ea180 RCX: 0000000000000000 [ +0.000001] RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000 [ +0.000001] RBP: ffffc90002067ca8 R08: 0000000000000000 R09: 0000000000000000 [ +0.000001] R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000000 [ +0.000001] R13: ffff88810a395f48 R14: ffff888101aab0d0 R15: 0000000000000000 [ +0.000001] FS: 00007f5ddaa43a00(0000) GS:ffff88841e800000(0000) knlGS:0000000000000000 [ +0.000002] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ +0.000001] CR2: 00007f8ffa61ba50 CR3: 0000000106432000 CR4: 0000000000350ef0 [ +0.000001] Call Trace: [ +0.000001] <TASK> [ +0.000001] ? show_regs+0x72/0x90 [ +0.000002] ? sysfs_remove_group+0x83/0x90 [ +0.000002] ? __warn+0x8d/0x160 [ +0.000001] ? sysfs_remove_group+0x83/0x90 [ +0.000001] ? report_bug+0x1bb/0x1d0 [ +0.000003] ? handle_bug+0x46/0x90 [ +0.000001] ? exc_invalid_op+0x19/0x80 [ +0.000002] ? asm_exc_invalid_op+0x1b/0x20 [ +0.000003] ? sysfs_remove_group+0x83/0x90 [ +0.000001] dpm_sysfs_remove+0x61/0x70 [ +0.000002] device_del+0xa3/0x3d0 [ +0.000002] ? ktime_get_mono_fast_ns+0x46/0xb0 [ +0.000002] device_unregister+0x18/0x70 [ +0.000001] i2c_del_adapter+0x26d/0x330 [ +0.000002] arcturus_i2c_control_fini+0x25/0x50 [amdgpu] [ +0.000236] smu_sw_fini+0x38/0x260 [amdgpu] [ +0.000241] amdgpu_device_fini_sw+0x116/0x670 [amdgpu] [ +0.000186] ? mutex_lock+0x13/0x50 [ +0.000003] amdgpu_driver_release_kms+0x16/0x40 [amdgpu] [ +0.000192] drm_minor_release+0x4f/0x80 [drm] [ +0.000025] drm_release+0xfe/0x150 [drm] [ +0.000027] __fput+0x9f/0x290 [ +0.000002] ____fput+0xe/0x20 [ +0.000002] task_work_run+0x61/0xa0 [ +0.000002] exit_to_user_mode_prepare+0x150/0x170 [ +0.000002] syscall_exit_to_user_mode+0x2a/0x50
--- drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c | 9 ++++++--- 1 file changed, 6 insertions(+), 3 deletions(-)
drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c +6 -3
@@ -1380,7 +1380,8 @@ static void amdgpu_ras_sysfs_remove_bad_page_node(struct amdgpu_device *adev) {struct amdgpu_ras *con =amdgpu_ras_get_context (adev); -sysfs_remove_file_from_group (&adev->dev->kobj, +if (adev->dev->kobj.sd) +sysfs_remove_file_from_group (&adev->dev->kobj, &con->badpages_attr.attr,RAS_FS_NAME ); }
@@ -1397,7 +1398,8 @@ static int amdgpu_ras_sysfs_remove_feature_node(struct amdgpu_device *adev) .attrs = attrs, }; -sysfs_remove_group (&adev->dev->kobj, &group); +if (adev->dev->kobj.sd) +sysfs_remove_group (&adev->dev->kobj, &group);return 0 ; }
@@ -1444,7 +1446,8 @@ int amdgpu_ras_sysfs_remove(struct amdgpu_device *adev,if (!obj || !obj->attr_inuse)return -EINVAL ; -sysfs_remove_file_from_group (&adev->dev->kobj, +if (adev->dev->kobj.sd) +sysfs_remove_file_from_group (&adev->dev->kobj, &obj->sysfs_attr.attr,RAS_FS_NAME ); obj->attr_inuse =0 ;
Signature · 1 line
2.42.0
Greg Kroah-Hartman
maintainerPATCH 149/491 pwm: Fix double shift bug
In reply to Greg Kroah-Hartman6.5-stable review patch. If anyone has any objections, please let me know.
------------------
From: Dan Carpenter <[email protected]>
[ Upstream commit d27abbfd4888d79dd24baf50e774631046ac4732 ]
These enums are passed to set/test_bit(). The set/test_bit() functions take a bit number instead of a shifted value. Passing a shifted value is a double shift bug like doing BIT(BIT(1)). The double shift bug doesn't cause a problem here because we are only checking 0 and 1 but if the value was 5 or above then it can lead to a buffer overflow.
--- include/linux/pwm.h | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
include/linux/pwm.h +2 -2
@@ -41,8 +41,8 @@ struct pwm_args { };enum { -PWMF_REQUESTED =1 <<0 , -PWMF_EXPORTED =1 <<1 , +PWMF_REQUESTED =0 , +PWMF_EXPORTED =1 , };/*
Signature · 1 line
2.42.0
Greg Kroah-Hartman
maintainerPATCH 150/491 mtd: rawnand: tegra: add missing check for platform_get_irq()
In reply to Greg Kroah-Hartman6.5-stable review patch. If anyone has any objections, please let me know.
------------------
From: Yi Yang <[email protected]>
[ Upstream commit 0a1166c27d4e53186e6bf9147ea6db9cd1d65847 ]
Add the missing check for platform_get_irq() and return error code if it fails.
--- drivers/mtd/nand/raw/tegra_nand.c | 4 ++++ 1 file changed, 4 insertions(+)
drivers/mtd/nand/raw/tegra_nand.c +4 -0
@@ -1197,6 +1197,10 @@ static int tegra_nand_probe(struct platform_device *pdev)init_completion (&ctrl->dma_complete); ctrl->irq =platform_get_irq (pdev,0 ); +if (ctrl->irq <0 ) { + err = ctrl->irq; + goto err_put_pm; + } err =devm_request_irq (&pdev->dev, ctrl->irq, tegra_nand_irq,0 ,dev_name (&pdev->dev), ctrl);if (err) {
Signature · 1 line
2.42.0
Greg Kroah-Hartman
maintainerPATCH 151/491 wifi: iwlwifi: Use FW rate for non-data frames
In reply to Greg Kroah-Hartman6.5-stable review patch. If anyone has any objections, please let me know.
------------------
From: Miri Korenblit <[email protected]>
[ Upstream commit 499d02790495958506a64f37ceda7e97345a50a8 ]
Currently we are setting the rate in the tx cmd for mgmt frames (e.g. during connection establishment). This was problematic when sending mgmt frames in eSR mode, as we don't know what link this frame will be sent on (This is decided by the FW), so we don't know what is the lowest rate.
Fix this by not setting the rate in tx cmd and rely
on FW to choose the right one.
Set rate only for injected frames with fixed rate,
or when no sta is given.
Also set for important frames (EAPOL etc.) the High Priority flag.
--- drivers/net/wireless/intel/iwlwifi/mvm/tx.c | 14 +++++++++----- 1 file changed, 9 insertions(+), 5 deletions(-)
drivers/net/wireless/intel/iwlwifi/mvm/tx.c +9 -5
@@ -536,16 +536,20 @@ iwl_mvm_set_tx_params(struct iwl_mvm *mvm, struct sk_buff *skb, flags |=IWL_TX_FLAGS_ENCRYPT_DIS ;/* -* For data packets rate info comes from the fw. Only -* set rate/antenna during connection establishment or in case -* no station is given. +* For data and mgmt packets rate info comes from the fw. Only +* set rate/antenna for injected frames with fixed rate, or +* when no sta is given. */ -if (!sta || !ieee80211_is_data (hdr->frame_control) || - mvmsta->sta_state <IEEE80211_STA_AUTHORIZED ) { +if (unlikely (!sta || + info->control.flags &IEEE80211_TX_CTRL_RATE_INJECT )) { flags |=IWL_TX_FLAGS_CMD_RATE ; rate_n_flags =iwl_mvm_get_tx_rate_n_flags (mvm, info, sta, hdr->frame_control); + }else if (!ieee80211_is_data (hdr->frame_control) || + mvmsta->sta_state <IEEE80211_STA_AUTHORIZED ) { +/* These are important frames */ + flags |=IWL_TX_FLAGS_HIGH_PRI ; } if (mvm->trans->trans_cfg->device_family >=
Signature · 1 line
2.42.0
Greg Kroah-Hartman
maintainerPATCH 152/491 sched/core: Optimize in_task() and in_interrupt() a bit
In reply to Greg Kroah-Hartman6.5-stable review patch. If anyone has any objections, please let me know.
------------------
From: Finn Thain <[email protected]>
[ Upstream commit 87c3a5893e865739ce78aa7192d36011022e0af7 ]
Except on x86, preempt_count is always accessed with READ_ONCE(). Repeated invocations in macros like irq_count() produce repeated loads. These redundant instructions appear in various fast paths. In the one shown below, for example, irq_count() is evaluated during kernel entry if !tick_nohz_full_cpu(smp_processor_id()).
0001ed0a <irq_enter_rcu>:
1ed0a: 4e56 0000 linkw %fp,#0 1ed0e: 200f movel %sp,%d0 1ed10: 0280 ffff e000 andil #-8192,%d0 1ed16: 2040 moveal %d0,%a0 1ed18: 2028 0008 movel %a0@(8),%d0 1ed1c: 0680 0001 0000 addil #65536,%d0 1ed22: 2140 0008 movel %d0,%a0@(8) 1ed26: 082a 0001 000f btst #1,%a2@(15) 1ed2c: 670c beqs 1ed3a <irq_enter_rcu+0x30> 1ed2e: 2028 0008 movel %a0@(8),%d0 1ed32: 2028 0008 movel %a0@(8),%d0 1ed36: 2028 0008 movel %a0@(8),%d0 1ed3a: 4e5e unlk %fp 1ed3c: 4e75 rts
This patch doesn't prevent the pointless btst and beqs instructions above, but it does eliminate 2 of the 3 pointless move instructions here and elsewhere.
On x86, preempt_count is per-cpu data and the problem does not arise presumably because the compiler is free to optimize more effectively.
This patch was tested on m68k and x86. I was expecting no changes to object code for x86 and mostly that's what I saw. However, there were a few places where code generation was perturbed for some reason.
The performance issue addressed here is minor on uniprocessor m68k. I got a 0.01% improvement from this patch for a simple "find /sys -false" benchmark. For architectures and workloads susceptible to cache line bounce the improvement is expected to be larger. The only SMP architecture I have is x86, and as x86 unaffected I have not done any further measurements.
--- include/linux/preempt.h | 15 +++++++++++++-- 1 file changed, 13 insertions(+), 2 deletions(-)
include/linux/preempt.h +13 -2
@@ -99,14 +99,21 @@ static __always_inline unsigned char interrupt_context_level(void)return level; } +/* +* These macro definitions avoid redundant invocations of preempt_count() +* because such invocations would result in redundant loads given that +* preempt_count() is commonly implemented with READ_ONCE(). +*/ +#define nmi_count () (preempt_count() & NMI_MASK)#define hardirq_count () (preempt_count() & HARDIRQ_MASK)#ifdef CONFIG_PREEMPT_RT # define softirq_count () (current->softirq_disable_cnt & SOFTIRQ_MASK) +# define irq_count () ((preempt_count() & (NMI_MASK | HARDIRQ_MASK)) | softirq_count())#else # define softirq_count () (preempt_count() & SOFTIRQ_MASK) +# define irq_count () (preempt_count() & (NMI_MASK | HARDIRQ_MASK | SOFTIRQ_MASK))#endif -#define irq_count () (nmi_count() | hardirq_count() | softirq_count())/* * Macros to retrieve the current execution context:
@@ -119,7 +126,11 @@ static __always_inline unsigned char interrupt_context_level(void)#define in_nmi () (nmi_count())#define in_hardirq () (hardirq_count())#define in_serving_softirq () (softirq_count() & SOFTIRQ_OFFSET) -#define in_task () (!(in_nmi() | in_hardirq() | in_serving_softirq())) +#ifdef CONFIG_PREEMPT_RT +# define in_task () (!((preempt_count() & (NMI_MASK | HARDIRQ_MASK)) | in_serving_softirq())) +#else +# define in_task () (!(preempt_count() & (NMI_MASK | HARDIRQ_MASK | SOFTIRQ_OFFSET))) +#endif /* * The following macros are deprecated and should not be used in new code:
Signature · 1 line
2.42.0
Greg Kroah-Hartman
maintainerPATCH 153/491 samples/bpf: syscall_tp_user: Rename num_progs into nr_tests
In reply to Greg Kroah-Hartman6.5-stable review patch. If anyone has any objections, please let me know.
------------------
From: Jinghao Jia <[email protected]>
[ Upstream commit 0ee352fe0d28015cab161b04d202fa3231c0ba3b ]
The variable name num_progs causes confusion because that variable really controls the number of rounds the test should be executed.
Rename num_progs into nr_tests for the sake of clarity.
Stable-dep-of: 9220c3ef6fef ("samples/bpf: syscall_tp_user: Fix array out-of-bound access")
--- samples/bpf/syscall_tp_user.c | 24 ++++++++++++------------ 1 file changed, 12 insertions(+), 12 deletions(-)
samples/bpf/syscall_tp_user.c +12 -12
@@ -17,9 +17,9 @@static void usage (const char *cmd) { -printf ("USAGE: %s [-i num_progs] [-h]\n" , cmd); -printf (" -i num_progs # number of progs of the test\n" ); -printf (" -h # help\n" ); +printf ("USAGE: %s [-i nr_tests] [-h]\n" , cmd); +printf (" -i nr_tests # rounds of test to run\n" ); +printf (" -h # help\n" ); }static void verify_map (int map_id)
@@ -45,14 +45,14 @@ static void verify_map(int map_id) } } -static int test (char *filename,int num_progs) +static int test (char *filename,int nr_tests) { -int map0_fds[num_progs], map1_fds[num_progs], fd, i, j =0 ; -struct bpf_link *links[num_progs *4 ]; -struct bpf_object *objs[num_progs]; +int map0_fds[nr_tests], map1_fds[nr_tests], fd, i, j =0 ; +struct bpf_link *links[nr_tests *4 ]; +struct bpf_object *objs[nr_tests];struct bpf_program *prog; -for (i =0 ; i < num_progs; i++) { +for (i =0 ; i < nr_tests; i++) { objs[i] =bpf_object__open_file (filename,NULL );if (libbpf_get_error (objs[i])) {fprintf (stderr,"opening BPF object file failed\n" );
@@ -101,7 +101,7 @@ static int test(char *filename, int num_progs)close (fd);/* verify the map */ -for (i =0 ; i < num_progs; i++) { +for (i =0 ; i < nr_tests; i++) {verify_map (map0_fds[i]);verify_map (map1_fds[i]); }
@@ -117,13 +117,13 @@ static int test(char *filename, int num_progs)int main (int argc,char **argv) { -int opt, num_progs =1 ; +int opt, nr_tests =1 ;char filename[256 ];while ((opt =getopt (argc, argv,"i:h" )) !=-1 ) {switch (opt) {case 'i' : - num_progs =atoi (optarg); + nr_tests =atoi (optarg);break ;case 'h' :default :
@@ -134,5 +134,5 @@ int main(int argc, char **argv)snprintf (filename,sizeof (filename),"%s_kern.o" , argv[0 ]); -return test (filename, num_progs); +return test (filename, nr_tests); }
Signature · 1 line
2.42.0
Greg Kroah-Hartman
maintainerPATCH 154/491 samples/bpf: syscall_tp_user: Fix array out-of-bound access
In reply to Greg Kroah-Hartman6.5-stable review patch. If anyone has any objections, please let me know.
------------------
From: Jinghao Jia <[email protected]>
[ Upstream commit 9220c3ef6fefbf18f24aeedb1142a642b3de0596 ]
Commit 06744f24696e ("samples/bpf: Add openat2() enter/exit tracepoint to syscall_tp sample") added two more eBPF programs to support the openat2() syscall. However, it did not increase the size of the array that holds the corresponding bpf_links. This leads to an out-of-bound access on that array in the bpf_object__for_each_program loop and could corrupt other variables on the stack. On our testing QEMU, it corrupts the map1_fds array and causes the sample to fail:
# ./syscall_tp prog #0: map ids 4 5 verify map:4 val: 5 map_lookup failed: Bad file descriptor
Dynamically allocate the array based on the number of programs reported by libbpf to prevent similar inconsistencies in the future
--- samples/bpf/syscall_tp_user.c | 23 ++++++++++++++++++++--- 1 file changed, 20 insertions(+), 3 deletions(-)
samples/bpf/syscall_tp_user.c +20 -3
@@ -48,7 +48,7 @@ static void verify_map(int map_id)static int test (char *filename,int nr_tests) {int map0_fds[nr_tests], map1_fds[nr_tests], fd, i, j =0 ; -struct bpf_link *links[nr_tests *4 ]; +struct bpf_link **links =NULL ;struct bpf_object *objs[nr_tests];struct bpf_program *prog;
@@ -60,6 +60,19 @@ static int test(char *filename, int nr_tests) goto cleanup; } +/* One-time initialization */ +if (!links) { +int nr_progs =0 ; + +bpf_object__for_each_program (prog, objs[i]) + nr_progs +=1 ; + + links =calloc (nr_progs * nr_tests,sizeof (struct bpf_link *)); + +if (!links) + goto cleanup; + } +/* load BPF program */ if (bpf_object__load (objs[i])) {fprintf (stderr,"loading BPF object file failed\n" );
@@ -107,8 +120,12 @@ static int test(char *filename, int nr_tests) } cleanup: -for (j--; j >=0 ; j--) -bpf_link__destroy (links[j]); +if (links) { +for (j--; j >=0 ; j--) +bpf_link__destroy (links[j]); + +free (links); + }for (i--; i >=0 ; i--)bpf_object__close (objs[i]);
Signature · 1 line
2.42.0
Greg Kroah-Hartman
maintainerPATCH 155/491 dt-bindings: serial: fix regex pattern for matching serial node children
In reply to Greg Kroah-Hartman6.5-stable review patch. If anyone has any objections, please let me know.
------------------
From: Krzysztof Kozlowski <[email protected]>
[ Upstream commit 42851dfd4dbe38e34724a00063a9fad5cfc48dcd ]
The regular expression pattern for matching serial node children should accept only nodes starting and ending with the set of words: bluetooth, gnss, gps or mcu. Add missing brackets to enforce such matching.
--- Documentation/devicetree/bindings/serial/serial.yaml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
Documentation/devicetree/bindings/serial/serial.yaml +1 -1
@@ -96,7 +96,7 @@ then: rts-gpios: false patternProperties: - "^bluetooth|gnss|gps|mcu$": + "^(bluetooth|gnss|gps|mcu)$": if: type: object then:
Signature · 1 line
2.42.0
Greg Kroah-Hartman
maintainerPATCH 156/491 SUNRPC: ECONNRESET might require a rebind
In reply to Greg Kroah-Hartman6.5-stable review patch. If anyone has any objections, please let me know.
------------------
From: Trond Myklebust <[email protected]>
[ Upstream commit 4b09ca1508a60be30b2e3940264e93d7aeb5c97e ]
If connect() is returning ECONNRESET, it usually means that nothing is listening on that port. If so, a rebind might be required in order to obtain the new port on which the RPC service is listening.
--- net/sunrpc/clnt.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
net/sunrpc/clnt.c +1 -1
@@ -2169,6 +2169,7 @@ call_connect_status(struct rpc_task *task) task->tk_status =0 ;switch (status) {case -ECONNREFUSED : +case -ECONNRESET :/* A positive refusal suggests a rebind is needed. */ if (RPC_IS_SOFTCONN (task))break ;
@@ -2177,7 +2178,6 @@ call_connect_status(struct rpc_task *task) goto out_retry; } fallthrough; -case -ECONNRESET :case -ECONNABORTED :case -ENETDOWN :case -ENETUNREACH :
Signature · 1 line
2.42.0
Greg Kroah-Hartman
maintainerPATCH 157/491 mtd: rawnand: intel: check return value of devm_kasprintf()
In reply to Greg Kroah-Hartman6.5-stable review patch. If anyone has any objections, please let me know.
------------------
From: Yi Yang <[email protected]>
[ Upstream commit 74ac5b5e2375f1e8ef797ac7770887e9969f2516 ]
devm_kasprintf() returns a pointer to dynamically allocated memory which can be NULL upon failure. Ensure the allocation was successful by checking the pointer validity.
--- drivers/mtd/nand/raw/intel-nand-controller.c | 10 ++++++++++ 1 file changed, 10 insertions(+)
drivers/mtd/nand/raw/intel-nand-controller.c +10 -0
@@ -619,6 +619,11 @@ static int ebu_nand_probe(struct platform_device *pdev) ebu_host->cs_num = cs; resname =devm_kasprintf (dev,GFP_KERNEL ,"nand_cs%d" , cs); +if (!resname) { + ret = -ENOMEM ; + goto err_of_node_put; + } + ebu_host->cs[cs].chipaddr =devm_platform_ioremap_resource_byname (pdev, resname);if (IS_ERR (ebu_host->cs[cs].chipaddr)) {
@@ -655,6 +660,11 @@ static int ebu_nand_probe(struct platform_device *pdev) } resname =devm_kasprintf (dev,GFP_KERNEL ,"addr_sel%d" , cs); +if (!resname) { + ret = -ENOMEM ; + goto err_cleanup_dma; + } + res =platform_get_resource_byname (pdev,IORESOURCE_MEM , resname);if (!res) { ret = -EINVAL ;
Signature · 1 line
2.42.0
Greg Kroah-Hartman
maintainerPATCH 158/491 mtd: rawnand: meson: check return value of devm_kasprintf()
In reply to Greg Kroah-Hartman6.5-stable review patch. If anyone has any objections, please let me know.
------------------
From: Yi Yang <[email protected]>
[ Upstream commit 5a985960a4dd041c21dbe9956958c1633d2da706 ]
devm_kasprintf() returns a pointer to dynamically allocated memory which can be NULL upon failure. Ensure the allocation was successful by checking the pointer validity.
--- drivers/mtd/nand/raw/meson_nand.c | 3 +++ 1 file changed, 3 insertions(+)
drivers/mtd/nand/raw/meson_nand.c +3 -0
@@ -1115,6 +1115,9 @@ static int meson_nfc_clk_init(struct meson_nfc *nfc) init.name =devm_kasprintf (nfc->dev,GFP_KERNEL ,"%s#div" ,dev_name (nfc->dev)); +if (!init.name) +return -ENOMEM ; + init.ops = &clk_divider_ops; nfc_divider_parent_data[0 ].fw_name ="device" ; init.parent_data = nfc_divider_parent_data;
Signature · 1 line
2.42.0
Greg Kroah-Hartman
maintainerPATCH 159/491 drm/i915/mtl: avoid stringop-overflow warning
In reply to Greg Kroah-Hartman6.5-stable review patch. If anyone has any objections, please let me know.
------------------
From: Arnd Bergmann <[email protected]>
[ Upstream commit 390001d648ffa027b750b7dceb5d43f4c1d1a39e ]
The newly added memset() causes a warning for some reason I could not figure out:
In file included from arch/x86/include/asm/string.h:3,
from drivers/gpu/drm/i915/gt/intel_rc6.c:6:
In function 'rc6_res_reg_init',
inlined from 'intel_rc6_init' at drivers/gpu/drm/i915/gt/intel_rc6.c:610:2:
arch/x86/include/asm/string_32.h:195:29: error: '__builtin_memset' writing 16 bytes into a region of size 0 overflows the destination [-Werror=stringop-overflow=]
195 | #define memset(s, c, count) __builtin_memset(s, c, count)
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~
drivers/gpu/drm/i915/gt/intel_rc6.c:584:9: note: in expansion of macro 'memset'
584 | memset(rc6->res_reg, INVALID_MMIO_REG.reg, sizeof(rc6->res_reg));
| ^~~~~~In function 'intel_rc6_init':
Change it to an normal initializer and an added memcpy() that does not have this problem.
--- drivers/gpu/drm/i915/gt/intel_rc6.c | 16 ++++++++++------ 1 file changed, 10 insertions(+), 6 deletions(-)
drivers/gpu/drm/i915/gt/intel_rc6.c +10 -6
@@ -584,19 +584,23 @@ static void __intel_rc6_disable(struct intel_rc6 *rc6)static void rc6_res_reg_init (struct intel_rc6 *rc6) { -memset (rc6->res_reg,INVALID_MMIO_REG .reg,sizeof (rc6->res_reg)); +i915_reg_t res_reg[INTEL_RC6_RES_MAX ] = { + [0 ...INTEL_RC6_RES_MAX -1 ] =INVALID_MMIO_REG , + };switch (rc6_to_gt (rc6)->type) {case GT_MEDIA : - rc6->res_reg[INTEL_RC6_RES_RC6 ] =MTL_MEDIA_MC6 ; + res_reg[INTEL_RC6_RES_RC6 ] =MTL_MEDIA_MC6 ;break ;default : - rc6->res_reg[INTEL_RC6_RES_RC6_LOCKED ] =GEN6_GT_GFX_RC6_LOCKED ; - rc6->res_reg[INTEL_RC6_RES_RC6 ] =GEN6_GT_GFX_RC6 ; - rc6->res_reg[INTEL_RC6_RES_RC6p] = GEN6_GT_GFX_RC6p; - rc6->res_reg[INTEL_RC6_RES_RC6pp] = GEN6_GT_GFX_RC6pp; + res_reg[INTEL_RC6_RES_RC6_LOCKED ] =GEN6_GT_GFX_RC6_LOCKED ; + res_reg[INTEL_RC6_RES_RC6 ] =GEN6_GT_GFX_RC6 ; + res_reg[INTEL_RC6_RES_RC6p] = GEN6_GT_GFX_RC6p; + res_reg[INTEL_RC6_RES_RC6pp] = GEN6_GT_GFX_RC6pp;break ; } + +memcpy (rc6->res_reg, res_reg,sizeof (res_reg)); }void intel_rc6_init (struct intel_rc6 *rc6)
Signature · 1 line
2.42.0
Greg Kroah-Hartman
maintainerPATCH 160/491 NFSv4.1: fix handling NFS4ERR_DELAY when testing for session trunking
In reply to Greg Kroah-Hartman6.5-stable review patch. If anyone has any objections, please let me know.
------------------
From: Olga Kornievskaia <[email protected]>
[ Upstream commit 6bd1a77dc72dea0b0d8b6014f231143984d18f6d ]
Currently when client sends an EXCHANGE_ID for a possible trunked connection, for any error that happened, the trunk will be thrown out. However, an NFS4ERR_DELAY is a transient error that should be retried instead.
--- fs/nfs/nfs4proc.c | 7 ++++++- 1 file changed, 6 insertions(+), 1 deletion(-)
fs/nfs/nfs4proc.c +6 -1
@@ -8934,6 +8934,7 @@ void nfs4_test_session_trunk(struct rpc_clnt *clnt, struct rpc_xprt *xprt, sp4_how = (adata->clp->cl_sp4_flags ==0 ?SP4_NONE :SP4_MACH_CRED ); +try_again:/* Test connection for session trunking. Async exchange_id call */ task =nfs4_run_exchange_id (adata->clp, adata->cred, sp4_how, xprt);if (IS_ERR (task))
@@ -8946,11 +8947,15 @@ void nfs4_test_session_trunk(struct rpc_clnt *clnt, struct rpc_xprt *xprt,if (status ==0 )rpc_clnt_xprt_switch_add_xprt (clnt, xprt); -else if (rpc_clnt_xprt_switch_has_addr (clnt, +else if (status != -NFS4ERR_DELAY &&rpc_clnt_xprt_switch_has_addr (clnt, (struct sockaddr *)&xprt->addr))rpc_clnt_xprt_switch_remove_xprt (clnt, xprt);rpc_put_task (task); +if (status == -NFS4ERR_DELAY ) { +ssleep (1 ); + goto try_again; + } }EXPORT_SYMBOL_GPL (nfs4_test_session_trunk);
Signature · 1 line
2.42.0
Greg Kroah-Hartman
maintainerPATCH 161/491 SUNRPC: Add an IS_ERR() check back to where it was
In reply to Greg Kroah-Hartman6.5-stable review patch. If anyone has any objections, please let me know.
------------------
From: Dan Carpenter <[email protected]>
[ Upstream commit 4f3ed837186fc0d2722ba8d2457a594322e9c2ef ]
This IS_ERR() check was deleted during in a cleanup because, at the time, the rpcb_call_async() function could not return an error pointer. That changed in commit 25cf32ad5dba ("SUNRPC: Handle allocation failure in rpc_new_task()") and now it can return an error pointer. Put the check back.
A related revert was done in commit 13bd90141804 ("Revert "SUNRPC:
Remove unreachable error condition"").
--- net/sunrpc/rpcb_clnt.c | 4 ++++ 1 file changed, 4 insertions(+)
net/sunrpc/rpcb_clnt.c +4 -0
@@ -769,6 +769,10 @@ void rpcb_getport_async(struct rpc_task *task) child =rpcb_call_async (rpcb_clnt, map, proc);rpc_release_client (rpcb_clnt); +if (IS_ERR (child)) { +/* rpcb_map_release() has freed the arguments */ +return ; + } xprt->stat.bind_count++;rpc_put_task (child);
Signature · 1 line
2.42.0
Greg Kroah-Hartman
maintainerPATCH 162/491 NFSv4.1: fix SP4_MACH_CRED protection for pnfs IO
In reply to Greg Kroah-Hartman6.5-stable review patch. If anyone has any objections, please let me know.
------------------
From: Olga Kornievskaia <[email protected]>
[ Upstream commit 5cc7688bae7f0757c39c1d3dfdd827b724061067 ]
If the client is doing pnfs IO and Kerberos is configured and EXCHANGEID successfully negotiated SP4_MACH_CRED and WRITE/COMMIT are on the list of state protected operations, then we need to make sure to choose the DS's rpc_client structure instead of the MDS's one.
--- fs/nfs/nfs4proc.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-)
fs/nfs/nfs4proc.c +3 -2
@@ -5622,7 +5622,7 @@ static void nfs4_proc_write_setup(struct nfs_pgio_header *hdr, msg->rpc_proc = &nfs4_procedures[NFSPROC4_CLNT_WRITE ];nfs4_init_sequence (&hdr->args.seq_args, &hdr->res.seq_res,0 ,0 ); -nfs4_state_protect_write (server->nfs_client, clnt, msg, hdr); +nfs4_state_protect_write (hdr->ds_clp ? hdr->ds_clp : server->nfs_client, clnt, msg, hdr); }static void nfs4_proc_commit_rpc_prepare (struct rpc_task *task,struct nfs_commit_data *data)
@@ -5663,7 +5663,8 @@ static void nfs4_proc_commit_setup(struct nfs_commit_data *data, struct rpc_mess data->res.server = server; msg->rpc_proc = &nfs4_procedures[NFSPROC4_CLNT_COMMIT ];nfs4_init_sequence (&data->args.seq_args, &data->res.seq_res,1 ,0 ); -nfs4_state_protect (server->nfs_client,NFS_SP4_MACH_CRED_COMMIT , clnt, msg); +nfs4_state_protect (data->ds_clp ? data->ds_clp : server->nfs_client, +NFS_SP4_MACH_CRED_COMMIT , clnt, msg); } static int _nfs4_proc_commit(struct file *dst, struct nfs_commitargs *args,
Signature · 1 line
2.42.0
Greg Kroah-Hartman
maintainerPATCH 163/491 SUNRPC: Fix RPC client cleaned up the freed pipefs dentries
In reply to Greg Kroah-Hartman6.5-stable review patch. If anyone has any objections, please let me know.
------------------
From: felix <[email protected]>
[ Upstream commit bfca5fb4e97c46503ddfc582335917b0cc228264 ]
RPC client pipefs dentries cleanup is in separated rpc_remove_pipedir() workqueue,which takes care about pipefs superblock locking. In some special scenarios, when kernel frees the pipefs sb of the current client and immediately alloctes a new pipefs sb, rpc_remove_pipedir function would misjudge the existence of pipefs sb which is not the one it used to hold. As a result,
the rpc_remove_pipedir would clean the released freed pipefs dentries.
To fix this issue, rpc_remove_pipedir should check whether the current pipefs sb is consistent with the original pipefs sb.
This error can be catched by KASAN:
=========================================================
[ 250.497700] BUG: KASAN: slab-use-after-free in dget_parent+0x195/0x200 [ 250.498315] Read of size 4 at addr ffff88800a2ab804 by task kworker/0:18/106503 [ 250.500549] Workqueue: events rpc_free_client_work [ 250.501001] Call Trace: [ 250.502880] kasan_report+0xb6/0xf0 [ 250.503209] ? dget_parent+0x195/0x200 [ 250.503561] dget_parent+0x195/0x200 [ 250.503897] ? __pfx_rpc_clntdir_depopulate+0x10/0x10 [ 250.504384] rpc_rmdir_depopulate+0x1b/0x90 [ 250.504781] rpc_remove_client_dir+0xf5/0x150 [ 250.505195] rpc_free_client_work+0xe4/0x230 [ 250.505598] process_one_work+0x8ee/0x13b0 ... [ 22.039056] Allocated by task 244: [ 22.039390] kasan_save_stack+0x22/0x50 [ 22.039758] kasan_set_track+0x25/0x30 [ 22.040109] __kasan_slab_alloc+0x59/0x70 [ 22.040487] kmem_cache_alloc_lru+0xf0/0x240 [ 22.040889] __d_alloc+0x31/0x8e0 [ 22.041207] d_alloc+0x44/0x1f0 [ 22.041514] __rpc_lookup_create_exclusive+0x11c/0x140 [ 22.041987] rpc_mkdir_populate.constprop.0+0x5f/0x110 [ 22.042459] rpc_create_client_dir+0x34/0x150 [ 22.042874] rpc_setup_pipedir_sb+0x102/0x1c0 [ 22.043284] rpc_client_register+0x136/0x4e0 [ 22.043689] rpc_new_client+0x911/0x1020 [ 22.044057] rpc_create_xprt+0xcb/0x370 [ 22.044417] rpc_create+0x36b/0x6c0 ... [ 22.049524] Freed by task 0: [ 22.049803] kasan_save_stack+0x22/0x50 [ 22.050165] kasan_set_track+0x25/0x30 [ 22.050520] kasan_save_free_info+0x2b/0x50 [ 22.050921] __kasan_slab_free+0x10e/0x1a0 [ 22.051306] kmem_cache_free+0xa5/0x390 [ 22.051667] rcu_core+0x62c/0x1930 [ 22.051995] __do_softirq+0x165/0x52a [ 22.052347] [ 22.052503] Last potentially related work creation: [ 22.052952] kasan_save_stack+0x22/0x50 [ 22.053313] __kasan_record_aux_stack+0x8e/0xa0 [ 22.053739] __call_rcu_common.constprop.0+0x6b/0x8b0 [ 22.054209] dentry_free+0xb2/0x140 [ 22.054540] __dentry_kill+0x3be/0x540 [ 22.054900] shrink_dentry_list+0x199/0x510 [ 22.055293] shrink_dcache_parent+0x190/0x240 [ 22.055703] do_one_tree+0x11/0x40 [ 22.056028] shrink_dcache_for_umount+0x61/0x140 [ 22.056461] generic_shutdown_super+0x70/0x590 [ 22.056879] kill_anon_super+0x3a/0x60 [ 22.057234] rpc_kill_sb+0x121/0x200
--- include/linux/sunrpc/clnt.h | 1 + net/sunrpc/clnt.c | 5 ++++- 2 files changed, 5 insertions(+), 1 deletion(-)
include/linux/sunrpc/clnt.h +1 -0
@@ -92,6 +92,7 @@ struct rpc_clnt { };const struct cred *cl_cred;unsigned int cl_max_connect;/* max number of transports not to the same IP */ +struct super_block *pipefs_sb; };/*
net/sunrpc/clnt.c +4 -1
@@ -111,7 +111,8 @@ static void rpc_clnt_remove_pipedir(struct rpc_clnt *clnt) pipefs_sb =rpc_get_sb_net (net);if (pipefs_sb) { -__rpc_clnt_remove_pipedir (clnt); +if (pipefs_sb == clnt->pipefs_sb) +__rpc_clnt_remove_pipedir (clnt);rpc_put_sb_net (net); } }
@@ -151,6 +152,8 @@ rpc_setup_pipedir(struct super_block *pipefs_sb, struct rpc_clnt *clnt) {struct dentry *dentry; + clnt->pipefs_sb = pipefs_sb; +if (clnt->cl_program->pipe_dir_name !=NULL ) { dentry =rpc_setup_pipedir_sb (pipefs_sb, clnt);if (IS_ERR (dentry))
Signature · 1 line
2.42.0
Greg Kroah-Hartman
maintainerPATCH 164/491 RISC-V: hwprobe: Fix vDSO SIGSEGV
In reply to Greg Kroah-Hartman6.5-stable review patch. If anyone has any objections, please let me know.
------------------
From: Andrew Jones <[email protected]>
[ Upstream commit e1c05b3bf80f829ced464bdca90f1dfa96e8d251 ]
A hwprobe pair key is signed, but the hwprobe vDSO function was only checking that the upper bound was valid. In order to help avoid this type of problem in the future, and in anticipation of this check becoming more complicated with sparse keys, introduce and use a "key is valid" predicate function for the check.
--- arch/riscv/include/asm/hwprobe.h | 5 +++++ arch/riscv/kernel/vdso/hwprobe.c | 2 +- 2 files changed, 6 insertions(+), 1 deletion(-)
arch/riscv/include/asm/hwprobe.h +5 -0
@@ -10,4 +10,9 @@#define RISCV_HWPROBE_MAX_KEY 5 +static inline bool riscv_hwprobe_key_is_valid (__s64 key) +{ +return key >=0 && key <=RISCV_HWPROBE_MAX_KEY ; +} +#endif
arch/riscv/kernel/vdso/hwprobe.c +1 -1
@@ -37,7 +37,7 @@ int __vdso_riscv_hwprobe(struct riscv_hwprobe *pairs, size_t pair_count,/* This is something we can handle, fill out the pairs. */ while (p < end) { -if (p->key <=RISCV_HWPROBE_MAX_KEY ) { +if (riscv_hwprobe_key_is_valid (p->key)) { p->value = avd->all_cpu_hwprobe_values[p->key]; }else {
Signature · 1 line
2.42.0
Greg Kroah-Hartman
maintainerPATCH 165/491 riscv: provide riscv-specific is_trap_insn()
In reply to Greg Kroah-Hartman6.5-stable review patch. If anyone has any objections, please let me know.
------------------
From: Nam Cao <[email protected]>
[ Upstream commit b701f9e726f0a30a94ea6af596b74c1f07b95b6b ]
uprobes expects is_trap_insn() to return true for any trap instructions, not just the one used for installing uprobe. The current default implementation only returns true for 16-bit c.ebreak if C extension is enabled. This can confuse uprobes if a 32-bit ebreak generates a trap exception from userspace: uprobes asks is_trap_insn() who says there is no trap, so uprobes assume a probe was there before but has been removed, and return to the trap instruction. This causes an infinite loop of entering and exiting trap handler.
Instead of using the default implementation, implement this function speficially for riscv with checks for both ebreak and c.ebreak.
--- arch/riscv/kernel/probes/uprobes.c | 6 ++++++ 1 file changed, 6 insertions(+)
arch/riscv/kernel/probes/uprobes.c +6 -0
@@ -3,6 +3,7 @@#include <linux/highmem.h> #include <linux/ptrace.h> #include <linux/uprobes.h> +#include <asm/insn.h> #include "decode-insn.h"
@@ -17,6 +18,11 @@ bool is_swbp_insn(uprobe_opcode_t *insn)#endif } +bool is_trap_insn (uprobe_opcode_t *insn) +{ +return riscv_insn_is_ebreak (*insn) ||riscv_insn_is_c_ebreak (*insn); +} +unsigned long uprobe_get_swbp_addr (struct pt_regs *regs) {return instruction_pointer (regs);
Signature · 1 line
2.42.0
Greg Kroah-Hartman
maintainerPATCH 166/491 gfs2: Silence "suspicious RCU usage in gfs2_permission" warning
In reply to Greg Kroah-Hartman6.5-stable review patch. If anyone has any objections, please let me know.
------------------
From: Andreas Gruenbacher <[email protected]>
[ Upstream commit 074d7306a4fe22fcac0b53f699f92757ab1cee99 ]
Commit 0abd1557e21c added rcu_dereference() for dereferencing ip->i_gl in gfs2_permission. This now causes lockdep to complain when gfs2_permission is called in non-RCU context:
WARNING: suspicious RCU usage in gfs2_permission
Switch to rcu_dereference_check() and check for the MAY_NOT_BLOCK flag to shut up lockdep when we know that dereferencing ip->i_gl is safe.
--- fs/gfs2/inode.c | 7 ++++--- 1 file changed, 4 insertions(+), 3 deletions(-)
fs/gfs2/inode.c +4 -3
@@ -1860,6 +1860,7 @@ static const char *gfs2_get_link(struct dentry *dentry,int gfs2_permission (struct mnt_idmap *idmap,struct inode *inode,int mask) { +int may_not_block = mask &MAY_NOT_BLOCK ;struct gfs2_inode *ip;struct gfs2_holder i_gh;struct gfs2_glock *gl;
@@ -1867,14 +1868,14 @@ int gfs2_permission(struct mnt_idmap *idmap, struct inode *inode,gfs2_holder_mark_uninitialized (&i_gh); ip =GFS2_I (inode); - gl =rcu_dereference (ip->i_gl); + gl =rcu_dereference_check (ip->i_gl, !may_not_block);if (unlikely (!gl)) {/* inode is getting torn down, must be RCU mode */ -WARN_ON_ONCE (!(mask &MAY_NOT_BLOCK )); +WARN_ON_ONCE (!may_not_block);return -ECHILD ; }if (gfs2_glock_is_locked_by_me (gl) ==NULL ) { -if (mask &MAY_NOT_BLOCK ) +if (may_not_block)return -ECHILD ; error =gfs2_glock_nq_init (gl,LM_ST_SHARED ,LM_FLAG_ANY , &i_gh);if (error)
Signature · 1 line
2.42.0
Greg Kroah-Hartman
maintainerPATCH 167/491 drm/i915/tc: Fix -Wformat-truncation in intel_tc_port_init
In reply to Greg Kroah-Hartman6.5-stable review patch. If anyone has any objections, please let me know.
------------------
From: Nirmoy Das <[email protected]>
[ Upstream commit 9506fba463fcbdf8c8b7af3ec9ee34360df843fe ]
Fix below compiler warning:
intel_tc.c:1879:11: error: ‘%d’ directive output may be truncated writing between 1 and 11 bytes into a region of size 3 [-Werror=format-truncation=]
"%c/TC#%d", port_name(port), tc_port + 1);
^~intel_tc.c:1878:2: note: ‘snprintf’ output between 7 and 17 bytes into a destination of size 8
snprintf(tc->port_name, sizeof(tc->port_name), ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
"%c/TC#%d", port_name(port), tc_port + 1);
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~v2: use kasprintf(Imre)
v3: use const for port_name, and fix tc mem leak(Imre)
--- drivers/gpu/drm/i915/display/intel_tc.c | 11 ++++++++--- 1 file changed, 8 insertions(+), 3 deletions(-)
drivers/gpu/drm/i915/display/intel_tc.c +8 -3
@@ -58,7 +58,7 @@ struct intel_tc_port {struct delayed_work link_reset_work;int link_refcount; bool legacy_port:1; -char port_name[8 ]; +const char *port_name;enum tc_port_mode mode;enum tc_port_mode init_mode;enum phy_fia phy_fia;
@@ -1841,8 +1841,12 @@ int intel_tc_port_init(struct intel_digital_port *dig_port, bool is_legacy)else tc->phy_ops = &icl_tc_phy_ops; -snprintf (tc->port_name,sizeof (tc->port_name), -"%c/TC#%d" ,port_name (port), tc_port +1 ); + tc->port_name =kasprintf (GFP_KERNEL ,"%c/TC#%d" ,port_name (port), + tc_port +1 ); +if (!tc->port_name) { +kfree (tc); +return -ENOMEM ; + }mutex_init (&tc->lock);/* TODO: Combine the two works */
@@ -1863,6 +1867,7 @@ void intel_tc_port_cleanup(struct intel_digital_port *dig_port) {intel_tc_port_suspend (dig_port); +kfree (dig_port->tc->port_name);kfree (dig_port->tc); dig_port->tc =NULL ; }
Signature · 1 line
2.42.0
Greg Kroah-Hartman
maintainerPATCH 168/491 vdpa_sim_blk: allocate the buffer zeroed
In reply to Greg Kroah-Hartman6.5-stable review patch. If anyone has any objections, please let me know.
------------------
From: Stefano Garzarella <[email protected]>
[ Upstream commit 0d82410252ea324f0064e75b9865bb74cccc1dda ]
Deleting and recreating a device can lead to having the same content as the old device, so let's always allocate buffers completely zeroed out.
Message-Id: <[email protected]>
--- drivers/vdpa/vdpa_sim/vdpa_sim_blk.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
drivers/vdpa/vdpa_sim/vdpa_sim_blk.c +2 -2
@@ -437,7 +437,7 @@ static int vdpasim_blk_dev_add(struct vdpa_mgmt_dev *mdev, const char *name,if (blk->shared_backend) { blk->buffer = shared_buffer; }else { - blk->buffer =kvmalloc (VDPASIM_BLK_CAPACITY <<SECTOR_SHIFT , + blk->buffer =kvzalloc (VDPASIM_BLK_CAPACITY <<SECTOR_SHIFT ,GFP_KERNEL );if (!blk->buffer) { ret = -ENOMEM ;
@@ -495,7 +495,7 @@ static int __init vdpasim_blk_init(void) goto parent_err;if (shared_backend) { - shared_buffer =kvmalloc (VDPASIM_BLK_CAPACITY <<SECTOR_SHIFT , + shared_buffer =kvzalloc (VDPASIM_BLK_CAPACITY <<SECTOR_SHIFT ,GFP_KERNEL );if (!shared_buffer) { ret = -ENOMEM ;
Signature · 1 line
2.42.0
Greg Kroah-Hartman
maintainerPATCH 169/491 vhost-vdpa: fix use after free in vhost_vdpa_probe()
In reply to Greg Kroah-Hartman6.5-stable review patch. If anyone has any objections, please let me know.
------------------
From: Dan Carpenter <[email protected]>
[ Upstream commit e07754e0a1ea2d63fb29574253d1fd7405607343 ]
The put_device() calls vhost_vdpa_release_dev() which calls ida_simple_remove() and frees "v". So this call to ida_simple_remove() is a use after free and a double free.
Message-Id: <[email protected]>
--- drivers/vhost/vdpa.c | 1 - 1 file changed, 1 deletion(-)
drivers/vhost/vdpa.c +0 -1
@@ -1498,7 +1498,6 @@ static int vhost_vdpa_probe(struct vdpa_device *vdpa) err:put_device (&v->dev); -ida_simple_remove (&vhost_vdpa_ida, v->minor);return r; }
Signature · 1 line
2.42.0
Greg Kroah-Hartman
maintainerPATCH 170/491 gcc-plugins: randstruct: Only warn about true flexible arrays
In reply to Greg Kroah-Hartman6.5-stable review patch. If anyone has any objections, please let me know.
------------------
From: Kees Cook <[email protected]>
[ Upstream commit 1ee60356c2dca938362528404af95b8ef3e49b6a ]
The randstruct GCC plugin tried to discover "fake" flexible arrays to issue warnings about them in randomized structs. In the future LSM overhead reduction series, it would be legal to have a randomized struct with a 1-element array, and this should _not_ be treated as a flexible array, especially since commit df8fc4e934c1 ("kbuild: Enable -fstrict-flex-arrays=3"). Disable the 0-sized and 1-element array discovery logic in the plugin, but keep the "true" flexible array check.
--- scripts/gcc-plugins/randomize_layout_plugin.c | 10 ---------- 1 file changed, 10 deletions(-)
scripts/gcc-plugins/randomize_layout_plugin.c +0 -10
@@ -273,8 +273,6 @@ static bool is_flexible_array(const_tree field) {const_tree fieldtype;const_tree typesize; -const_tree elemtype; -const_tree elemsize; fieldtype =TREE_TYPE (field); typesize =TYPE_SIZE (fieldtype);
@@ -282,20 +280,12 @@ static bool is_flexible_array(const_tree field)if (TREE_CODE (fieldtype) !=ARRAY_TYPE )return false; - elemtype =TREE_TYPE (fieldtype); - elemsize =TYPE_SIZE (elemtype); -/* size of type is represented in bits */ if (typesize ==NULL_TREE &&TYPE_DOMAIN (fieldtype) !=NULL_TREE &&TYPE_MAX_VALUE (TYPE_DOMAIN (fieldtype)) ==NULL_TREE )return true; -if (typesize !=NULL_TREE && - (TREE_CONSTANT (typesize) && (!tree_to_uhwi (typesize) || -tree_to_uhwi (typesize) ==tree_to_uhwi (elemsize)))) -return true; -return false; }
Signature · 1 line
2.42.0
Greg Kroah-Hartman
maintainerPATCH 171/491 bpf: handle ldimm64 properly in check_cfg()
In reply to Greg Kroah-Hartman6.5-stable review patch. If anyone has any objections, please let me know.
------------------
From: Andrii Nakryiko <[email protected]>
[ Upstream commit 3feb263bb516ee7e1da0acd22b15afbb9a7daa19 ]
ldimm64 instructions are 16-byte long, and so have to be handled appropriately in check_cfg(), just like the rest of BPF verifier does.
This has implications in three places:
- when determining next instruction for non-jump instructions;
- when determining next instruction for callback address ldimm64
instructions (in visit_func_call_insn());
- when checking for unreachable instructions, where second half of
ldimm64 is expected to be unreachable;We take this also as an opportunity to report jump into the middle of ldimm64. And adjust few test_verifier tests accordingly.
--- include/linux/bpf.h | 8 ++++-- kernel/bpf/verifier.c | 27 ++++++++++++++----- .../testing/selftests/bpf/verifier/ld_imm64.c | 8 +++--- 3 files changed, 30 insertions(+), 13 deletions(-)
include/linux/bpf.h +6 -2
@@ -890,10 +890,14 @@ bpf_ctx_record_field_size(struct bpf_insn_access_aux *aux, u32 size) aux->ctx_field_size = size; } +static bool bpf_is_ldimm64 (const struct bpf_insn *insn) +{ +return insn->code == (BPF_LD |BPF_IMM |BPF_DW ); +} +static inline bool bpf_pseudo_func (const struct bpf_insn *insn) { -return insn->code == (BPF_LD |BPF_IMM |BPF_DW ) && - insn->src_reg ==BPF_PSEUDO_FUNC ; +return bpf_is_ldimm64 (insn) && insn->src_reg ==BPF_PSEUDO_FUNC ; }struct bpf_prog_ops {
kernel/bpf/verifier.c +20 -7
@@ -14563,15 +14563,16 @@ static int visit_func_call_insn(int t, struct bpf_insn *insns,struct bpf_verifier_env *env, bool visit_callee) { - int ret; + int ret, insn_sz; - ret =push_insn (t, t +1 ,FALLTHROUGH , env, false); + insn_sz =bpf_is_ldimm64 (&insns[t]) ?2 :1 ; + ret =push_insn (t, t + insn_sz,FALLTHROUGH , env, false);if (ret)return ret; -mark_prune_point (env, t +1 ); +mark_prune_point (env, t + insn_sz);/* when we exit from subprog, we need to record non-linear history */ -mark_jmp_point (env, t +1 ); +mark_jmp_point (env, t + insn_sz);if (visit_callee) {mark_prune_point (env, t);
@@ -14593,15 +14594,17 @@ static int visit_func_call_insn(int t, struct bpf_insn *insns,static int visit_insn (int t,struct bpf_verifier_env *env) {struct bpf_insn *insns = env->prog->insnsi, *insn = &insns[t]; -int ret; +int ret, insn_sz;if (bpf_pseudo_func (insn))return visit_func_call_insn (t, insns, env, true);/* All non-branch instructions have a single fall-through edge. */ if (BPF_CLASS (insn->code) !=BPF_JMP && -BPF_CLASS (insn->code) !=BPF_JMP32 ) -return push_insn (t, t +1 ,FALLTHROUGH , env, false); +BPF_CLASS (insn->code) !=BPF_JMP32 ) { + insn_sz =bpf_is_ldimm64 (insn) ?2 :1 ; +return push_insn (t, t + insn_sz,FALLTHROUGH , env, false); + }switch (BPF_OP (insn->code)) {case BPF_EXIT :
@@ -14715,11 +14718,21 @@ static int check_cfg(struct bpf_verifier_env *env) }for (i =0 ; i < insn_cnt; i++) { +struct bpf_insn *insn = &env->prog->insnsi[i]; +if (insn_state[i] !=EXPLORED ) {verbose (env,"unreachable insn %d\n" , i); ret = -EINVAL ; goto err_free; } +if (bpf_is_ldimm64 (insn)) { +if (insn_state[i +1 ] !=0 ) { +verbose (env,"jump into the middle of ldimm64 insn %d\n" , i); + ret = -EINVAL ; + goto err_free; + } + i++;/* skip second half of ldimm64 */ + } } ret =0 ;/* cfg looks good */
tools/testing/selftests/bpf/verifier/ld_imm64.c +4 -4
@@ -9,8 +9,8 @@BPF_MOV64_IMM (BPF_REG_0 ,2 ), BPF_EXIT_INSN(), }, - .errstr ="invalid BPF_LD_IMM insn" , - .errstr_unpriv = "R1 pointer comparison", + .errstr ="jump into the middle of ldimm64 insn 1" , + .errstr_unpriv = "jump into the middle of ldimm64 insn 1", .result = REJECT, }, {
@@ -23,8 +23,8 @@BPF_LD_IMM64 (BPF_REG_0 ,1 ), BPF_EXIT_INSN(), }, - .errstr ="invalid BPF_LD_IMM insn" , - .errstr_unpriv = "R1 pointer comparison", + .errstr ="jump into the middle of ldimm64 insn 1" , + .errstr_unpriv = "jump into the middle of ldimm64 insn 1", .result = REJECT, }, {
Signature · 1 line
2.42.0
Greg Kroah-Hartman
maintainerPATCH 172/491 bpf: fix precision backtracking instruction iteration
In reply to Greg Kroah-Hartman6.5-stable review patch. If anyone has any objections, please let me know.
------------------
From: Andrii Nakryiko <[email protected]>
[ Upstream commit 4bb7ea946a370707315ab774432963ce47291946 ]
Fix an edge case in __mark_chain_precision() which prematurely stops backtracking instructions in a state if it happens that state's first and last instruction indexes are the same. This situations doesn't necessarily mean that there were no instructions simulated in a state, but rather that we starting from the instruction, jumped around a bit, and then ended up at the same instruction before checkpointing or marking precision.
To distinguish between these two possible situations, we need to consult jump history. If it's empty or contain a single record "bridging" parent state and first instruction of processed state, then we indeed backtracked all instructions in this state. But if history is not empty, we are definitely not done yet.
Move this logic inside get_prev_insn_idx() to contain it more nicely. Use -ENOENT return code to denote "we are out of instructions" situation.
This bug was exposed by verifier_loop1.c's bounded_recursion subtest, once the next fix in this patch set is applied.
--- kernel/bpf/verifier.c | 21 +++++++++++++++++++-- 1 file changed, 19 insertions(+), 2 deletions(-)
kernel/bpf/verifier.c +19 -2
@@ -3193,12 +3193,29 @@ static int push_jmp_history(struct bpf_verifier_env *env,/* Backtrack one insn at a time. If idx is not at the top of recorded * history then previous instruction came from straight line execution. +* Return -ENOENT if we exhausted all instructions within given state. +* +* It's legal to have a bit of a looping with the same starting and ending +* insn index within the same state, e.g.: 3->4->5->3, so just because current +* instruction index is the same as state's first_idx doesn't mean we are +* done. If there is still some jump history left, we should keep going. We +* need to take into account that we might have a jump history between given +* state's parent and itself, due to checkpointing. In this case, we'll have +* history entry recording a jump from last instruction of parent state and +* first instruction of given state. */ static int get_prev_insn_idx (struct bpf_verifier_state *st,int i,u32 *history) {u32 cnt = *history; +if (i == st->first_insn_idx) { +if (cnt ==0 ) +return -ENOENT ; +if (cnt ==1 && st->jmp_history[0 ].idx == i) +return -ENOENT ; + } +if (cnt && st->jmp_history[cnt -1 ].idx == i) { i = st->jmp_history[cnt -1 ].prev_idx; (*history)--;
@@ -4073,10 +4090,10 @@ static int __mark_chain_precision(struct bpf_verifier_env *env, int regno)* Nothing to be tracked further in the parent state. */ return 0 ; -if (i == first_idx) -break ; subseq_idx = i; i =get_prev_insn_idx (st, i, &history); +if (i == -ENOENT ) +break ;if (i >= env->prog->len) {/* This can happen if backtracking reached insn 0 * and there are still reg_mask or stack_mask
Signature · 1 line
2.42.0
Greg Kroah-Hartman
maintainerPATCH 173/491 net: set SOCK_RCU_FREE before inserting socket into hashtable
In reply to Greg Kroah-Hartman6.5-stable review patch. If anyone has any objections, please let me know.
------------------
From: Stanislav Fomichev <[email protected]>
[ Upstream commit 871019b22d1bcc9fab2d1feba1b9a564acbb6e99 ]
We've started to see the following kernel traces:
WARNING: CPU: 83 PID: 0 at net/core/filter.c:6641 sk_lookup+0x1bd/0x1d0 Call Trace: <IRQ> __bpf_skc_lookup+0x10d/0x120 bpf_sk_lookup+0x48/0xd0 bpf_sk_lookup_tcp+0x19/0x20 bpf_prog_<redacted>+0x37c/0x16a3 cls_bpf_classify+0x205/0x2e0 tcf_classify+0x92/0x160 __netif_receive_skb_core+0xe52/0xf10 __netif_receive_skb_list_core+0x96/0x2b0 napi_complete_done+0x7b5/0xb70 <redacted>_poll+0x94/0xb0 net_rx_action+0x163/0x1d70 __do_softirq+0xdc/0x32e asm_call_irq_on_stack+0x12/0x20 </IRQ> do_softirq_own_stack+0x36/0x50 do_softirq+0x44/0x70
__inet_hash can race with lockless (rcu) readers on the other cpus:
__inet_hash
__sk_nulls_add_node_rcu
<- (bpf triggers here)
sock_set_flag(SOCK_RCU_FREE)
Let's move the SOCK_RCU_FREE part up a bit, before we are inserting the socket into hashtables. Note, that the race is really harmless; the bpf callers are handling this situation (where listener socket doesn't have SOCK_RCU_FREE set) correctly, so the only annoyance is a WARN_ONCE.
More details from Eric regarding SOCK_RCU_FREE timeline:
Commit 3b24d854cb35 ("tcp/dccp: do not touch listener sk_refcnt under synflood") added SOCK_RCU_FREE. At that time, the precise location of sock_set_flag(sk, SOCK_RCU_FREE) did not matter, because the thread calling __inet_hash() owns a reference on sk. SOCK_RCU_FREE was only tested at dismantle time.
Commit 6acc9b432e67 ("bpf: Add helper to retrieve socket in BPF") started checking SOCK_RCU_FREE _after_ the lookup to infer whether the refcount has been taken care of.
--- net/ipv4/inet_hashtables.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
net/ipv4/inet_hashtables.c +1 -1
@@ -731,12 +731,12 @@ int __inet_hash(struct sock *sk, struct sock *osk)if (err) goto unlock; } +sock_set_flag (sk,SOCK_RCU_FREE );if (IS_ENABLED (CONFIG_IPV6 ) && sk->sk_reuseport && sk->sk_family ==AF_INET6 )__sk_nulls_add_node_tail_rcu (sk, &ilb2->nulls_head);else __sk_nulls_add_node_rcu (sk, &ilb2->nulls_head); -sock_set_flag (sk,SOCK_RCU_FREE );sock_prot_inuse_add (sock_net (sk), sk->sk_prot,1 ); unlock:spin_unlock (&ilb2->lock);
Signature · 1 line
2.42.0
Greg Kroah-Hartman
maintainerPATCH 174/491 ipvlan: add ipvlan_route_v6_outbound() helper
In reply to Greg Kroah-Hartman6.5-stable review patch. If anyone has any objections, please let me know.
------------------
From: Eric Dumazet <[email protected]>
[ Upstream commit 18f039428c7df183b09c69ebf10ffd4e521035d2 ]
Inspired by syzbot reports using a stack of multiple ipvlan devices.
Reduce stack size needed in ipvlan_process_v6_outbound() by moving the flowi6 struct used for the route lookup in an non inlined helper. ipvlan_route_v6_outbound() needs 120 bytes on the stack, immediately reclaimed.
Also make sure ipvlan_process_v4_outbound() is not inlined.
We might also have to lower MAX_NEST_DEV, because only syzbot uses setups with more than four stacked devices.
BUG: TASK stack guard page was hit at ffffc9000e803ff8 (stack is ffffc9000e804000..ffffc9000e808000) stack guard page: 0000 [#1] SMP KASAN CPU: 0 PID: 13442 Comm: syz-executor.4 Not tainted 6.1.52-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/09/2023 RIP: 0010:kasan_check_range+0x4/0x2a0 mm/kasan/generic.c:188 Code: 48 01 c6 48 89 c7 e8 db 4e c1 03 31 c0 5d c3 cc 0f 0b eb 02 0f 0b b8 ea ff ff ff 5d c3 cc 00 00 cc cc 00 00 cc cc 55 48 89 e5 <41> 57 41 56 41 55 41 54 53 b0 01 48 85 f6 0f 84 a4 01 00 00 48 89 RSP: 0018:ffffc9000e804000 EFLAGS: 00010246 RAX: 0000000000000000 RBX: 0000000000000000 RCX: ffffffff817e5bf2 RDX: 0000000000000000 RSI: 0000000000000008 RDI: ffffffff887c6568 RBP: ffffc9000e804000 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: dffffc0000000001 R12: 1ffff92001d0080c R13: dffffc0000000000 R14: ffffffff87e6b100 R15: 0000000000000000 FS: 00007fd0c55826c0(0000) GS:ffff8881f6800000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: ffffc9000e803ff8 CR3: 0000000170ef7000 CR4: 00000000003506f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <#DF> </#DF> <TASK> [<ffffffff81f281d1>] __kasan_check_read+0x11/0x20 mm/kasan/shadow.c:31 [<ffffffff817e5bf2>] instrument_atomic_read include/linux/instrumented.h:72 [inline] [<ffffffff817e5bf2>] _test_bit include/asm-generic/bitops/instrumented-non-atomic.h:141 [inline] [<ffffffff817e5bf2>] cpumask_test_cpu include/linux/cpumask.h:506 [inline] [<ffffffff817e5bf2>] cpu_online include/linux/cpumask.h:1092 [inline] [<ffffffff817e5bf2>] trace_lock_acquire include/trace/events/lock.h:24 [inline] [<ffffffff817e5bf2>] lock_acquire+0xe2/0x590 kernel/locking/lockdep.c:5632 [<ffffffff8563221e>] rcu_lock_acquire+0x2e/0x40 include/linux/rcupdate.h:306 [<ffffffff8561464d>] rcu_read_lock include/linux/rcupdate.h:747 [inline] [<ffffffff8561464d>] ip6_pol_route+0x15d/0x1440 net/ipv6/route.c:2221 [<ffffffff85618120>] ip6_pol_route_output+0x50/0x80 net/ipv6/route.c:2606 [<ffffffff856f65b5>] pol_lookup_func include/net/ip6_fib.h:584 [inline] [<ffffffff856f65b5>] fib6_rule_lookup+0x265/0x620 net/ipv6/fib6_rules.c:116 [<ffffffff85618009>] ip6_route_output_flags_noref+0x2d9/0x3a0 net/ipv6/route.c:2638 [<ffffffff8561821a>] ip6_route_output_flags+0xca/0x340 net/ipv6/route.c:2651 [<ffffffff838bd5a3>] ip6_route_output include/net/ip6_route.h:100 [inline] [<ffffffff838bd5a3>] ipvlan_process_v6_outbound drivers/net/ipvlan/ipvlan_core.c:473 [inline] [<ffffffff838bd5a3>] ipvlan_process_outbound drivers/net/ipvlan/ipvlan_core.c:529 [inline] [<ffffffff838bd5a3>] ipvlan_xmit_mode_l3 drivers/net/ipvlan/ipvlan_core.c:602 [inline] [<ffffffff838bd5a3>] ipvlan_queue_xmit+0xc33/0x1be0 drivers/net/ipvlan/ipvlan_core.c:677 [<ffffffff838c2909>] ipvlan_start_xmit+0x49/0x100 drivers/net/ipvlan/ipvlan_main.c:229 [<ffffffff84d03900>] netdev_start_xmit include/linux/netdevice.h:4966 [inline] [<ffffffff84d03900>] xmit_one net/core/dev.c:3644 [inline] [<ffffffff84d03900>] dev_hard_start_xmit+0x320/0x980 net/core/dev.c:3660 [<ffffffff84d080e2>] __dev_queue_xmit+0x16b2/0x3370 net/core/dev.c:4324 [<ffffffff855ce4cd>] dev_queue_xmit include/linux/netdevice.h:3067 [inline] [<ffffffff855ce4cd>] neigh_hh_output include/net/neighbour.h:529 [inline] [<ffffffff855ce4cd>] neigh_output include/net/neighbour.h:543 [inline] [<ffffffff855ce4cd>] ip6_finish_output2+0x160d/0x1ae0 net/ipv6/ip6_output.c:139 [<ffffffff855b8616>] __ip6_finish_output net/ipv6/ip6_output.c:200 [inline] [<ffffffff855b8616>] ip6_finish_output+0x6c6/0xb10 net/ipv6/ip6_output.c:211 [<ffffffff855b7e3c>] NF_HOOK_COND include/linux/netfilter.h:298 [inline] [<ffffffff855b7e3c>] ip6_output+0x2bc/0x3d0 net/ipv6/ip6_output.c:232 [<ffffffff8575d27f>] dst_output include/net/dst.h:444 [inline] [<ffffffff8575d27f>] ip6_local_out+0x10f/0x140 net/ipv6/output_core.c:161 [<ffffffff838bdae4>] ipvlan_process_v6_outbound drivers/net/ipvlan/ipvlan_core.c:483 [inline] [<ffffffff838bdae4>] ipvlan_process_outbound drivers/net/ipvlan/ipvlan_core.c:529 [inline] [<ffffffff838bdae4>] ipvlan_xmit_mode_l3 drivers/net/ipvlan/ipvlan_core.c:602 [inline] [<ffffffff838bdae4>] ipvlan_queue_xmit+0x1174/0x1be0 drivers/net/ipvlan/ipvlan_core.c:677 [<ffffffff838c2909>] ipvlan_start_xmit+0x49/0x100 drivers/net/ipvlan/ipvlan_main.c:229 [<ffffffff84d03900>] netdev_start_xmit include/linux/netdevice.h:4966 [inline] [<ffffffff84d03900>] xmit_one net/core/dev.c:3644 [inline] [<ffffffff84d03900>] dev_hard_start_xmit+0x320/0x980 net/core/dev.c:3660 [<ffffffff84d080e2>] __dev_queue_xmit+0x16b2/0x3370 net/core/dev.c:4324 [<ffffffff855ce4cd>] dev_queue_xmit include/linux/netdevice.h:3067 [inline] [<ffffffff855ce4cd>] neigh_hh_output include/net/neighbour.h:529 [inline] [<ffffffff855ce4cd>] neigh_output include/net/neighbour.h:543 [inline] [<ffffffff855ce4cd>] ip6_finish_output2+0x160d/0x1ae0 net/ipv6/ip6_output.c:139 [<ffffffff855b8616>] __ip6_finish_output net/ipv6/ip6_output.c:200 [inline] [<ffffffff855b8616>] ip6_finish_output+0x6c6/0xb10 net/ipv6/ip6_output.c:211 [<ffffffff855b7e3c>] NF_HOOK_COND include/linux/netfilter.h:298 [inline] [<ffffffff855b7e3c>] ip6_output+0x2bc/0x3d0 net/ipv6/ip6_output.c:232 [<ffffffff8575d27f>] dst_output include/net/dst.h:444 [inline] [<ffffffff8575d27f>] ip6_local_out+0x10f/0x140 net/ipv6/output_core.c:161 [<ffffffff838bdae4>] ipvlan_process_v6_outbound drivers/net/ipvlan/ipvlan_core.c:483 [inline] [<ffffffff838bdae4>] ipvlan_process_outbound drivers/net/ipvlan/ipvlan_core.c:529 [inline] [<ffffffff838bdae4>] ipvlan_xmit_mode_l3 drivers/net/ipvlan/ipvlan_core.c:602 [inline] [<ffffffff838bdae4>] ipvlan_queue_xmit+0x1174/0x1be0 drivers/net/ipvlan/ipvlan_core.c:677 [<ffffffff838c2909>] ipvlan_start_xmit+0x49/0x100 drivers/net/ipvlan/ipvlan_main.c:229 [<ffffffff84d03900>] netdev_start_xmit include/linux/netdevice.h:4966 [inline] [<ffffffff84d03900>] xmit_one net/core/dev.c:3644 [inline] [<ffffffff84d03900>] dev_hard_start_xmit+0x320/0x980 net/core/dev.c:3660 [<ffffffff84d080e2>] __dev_queue_xmit+0x16b2/0x3370 net/core/dev.c:4324 [<ffffffff855ce4cd>] dev_queue_xmit include/linux/netdevice.h:3067 [inline] [<ffffffff855ce4cd>] neigh_hh_output include/net/neighbour.h:529 [inline] [<ffffffff855ce4cd>] neigh_output include/net/neighbour.h:543 [inline] [<ffffffff855ce4cd>] ip6_finish_output2+0x160d/0x1ae0 net/ipv6/ip6_output.c:139 [<ffffffff855b8616>] __ip6_finish_output net/ipv6/ip6_output.c:200 [inline] [<ffffffff855b8616>] ip6_finish_output+0x6c6/0xb10 net/ipv6/ip6_output.c:211 [<ffffffff855b7e3c>] NF_HOOK_COND include/linux/netfilter.h:298 [inline] [<ffffffff855b7e3c>] ip6_output+0x2bc/0x3d0 net/ipv6/ip6_output.c:232 [<ffffffff8575d27f>] dst_output include/net/dst.h:444 [inline] [<ffffffff8575d27f>] ip6_local_out+0x10f/0x140 net/ipv6/output_core.c:161 [<ffffffff838bdae4>] ipvlan_process_v6_outbound drivers/net/ipvlan/ipvlan_core.c:483 [inline] [<ffffffff838bdae4>] ipvlan_process_outbound drivers/net/ipvlan/ipvlan_core.c:529 [inline] [<ffffffff838bdae4>] ipvlan_xmit_mode_l3 drivers/net/ipvlan/ipvlan_core.c:602 [inline] [<ffffffff838bdae4>] ipvlan_queue_xmit+0x1174/0x1be0 drivers/net/ipvlan/ipvlan_core.c:677 [<ffffffff838c2909>] ipvlan_start_xmit+0x49/0x100 drivers/net/ipvlan/ipvlan_main.c:229 [<ffffffff84d03900>] netdev_start_xmit include/linux/netdevice.h:4966 [inline] [<ffffffff84d03900>] xmit_one net/core/dev.c:3644 [inline] [<ffffffff84d03900>] dev_hard_start_xmit+0x320/0x980 net/core/dev.c:3660 [<ffffffff84d080e2>] __dev_queue_xmit+0x16b2/0x3370 net/core/dev.c:4324 [<ffffffff855ce4cd>] dev_queue_xmit include/linux/netdevice.h:3067 [inline] [<ffffffff855ce4cd>] neigh_hh_output include/net/neighbour.h:529 [inline] [<ffffffff855ce4cd>] neigh_output include/net/neighbour.h:543 [inline] [<ffffffff855ce4cd>] ip6_finish_output2+0x160d/0x1ae0 net/ipv6/ip6_output.c:139 [<ffffffff855b8616>] __ip6_finish_output net/ipv6/ip6_output.c:200 [inline] [<ffffffff855b8616>] ip6_finish_output+0x6c6/0xb10 net/ipv6/ip6_output.c:211 [<ffffffff855b7e3c>] NF_HOOK_COND include/linux/netfilter.h:298 [inline] [<ffffffff855b7e3c>] ip6_output+0x2bc/0x3d0 net/ipv6/ip6_output.c:232 [<ffffffff8575d27f>] dst_output include/net/dst.h:444 [inline] [<ffffffff8575d27f>] ip6_local_out+0x10f/0x140 net/ipv6/output_core.c:161 [<ffffffff838bdae4>] ipvlan_process_v6_outbound drivers/net/ipvlan/ipvlan_core.c:483 [inline] [<ffffffff838bdae4>] ipvlan_process_outbound drivers/net/ipvlan/ipvlan_core.c:529 [inline] [<ffffffff838bdae4>] ipvlan_xmit_mode_l3 drivers/net/ipvlan/ipvlan_core.c:602 [inline] [<ffffffff838bdae4>] ipvlan_queue_xmit+0x1174/0x1be0 drivers/net/ipvlan/ipvlan_core.c:677 [<ffffffff838c2909>] ipvlan_start_xmit+0x49/0x100 drivers/net/ipvlan/ipvlan_main.c:229 [<ffffffff84d03900>] netdev_start_xmit include/linux/netdevice.h:4966 [inline] [<ffffffff84d03900>] xmit_one net/core/dev.c:3644 [inline] [<ffffffff84d03900>] dev_hard_start_xmit+0x320/0x980 net/core/dev.c:3660 [<ffffffff84d080e2>] __dev_queue_xmit+0x16b2/0x3370 net/core/dev.c:4324 [<ffffffff84d4a65e>] dev_queue_xmit include/linux/netdevice.h:3067 [inline] [<ffffffff84d4a65e>] neigh_resolve_output+0x64e/0x750 net/core/neighbour.c:1560 [<ffffffff855ce503>] neigh_output include/net/neighbour.h:545 [inline] [<ffffffff855ce503>] ip6_finish_output2+0x1643/0x1ae0 net/ipv6/ip6_output.c:139 [<ffffffff855b8616>] __ip6_finish_output net/ipv6/ip6_output.c:200 [inline] [<ffffffff855b8616>] ip6_finish_output+0x6c6/0xb10 net/ipv6/ip6_output.c:211 [<ffffffff855b7e3c>] NF_HOOK_COND include/linux/netfilter.h:298 [inline] [<ffffffff855b7e3c>] ip6_output+0x2bc/0x3d0 net/ipv6/ip6_output.c:232 [<ffffffff855b9ce4>] dst_output include/net/dst.h:444 [inline] [<ffffffff855b9ce4>] NF_HOOK include/linux/netfilter.h:309 [inline] [<ffffffff855b9ce4>] ip6_xmit+0x11a4/0x1b20 net/ipv6/ip6_output.c:352 [<ffffffff8597984e>] sctp_v6_xmit+0x9ae/0x1230 net/sctp/ipv6.c:250 [<ffffffff8594623e>] sctp_packet_transmit+0x25de/0x2bc0 net/sctp/output.c:653 [<ffffffff858f5142>] sctp_packet_singleton+0x202/0x310 net/sctp/outqueue.c:783 [<ffffffff858ea411>] sctp_outq_flush_ctrl net/sctp/outqueue.c:914 [inline] [<ffffffff858ea411>] sctp_outq_flush+0x661/0x3d40 net/sctp/outqueue.c:1212 [<ffffffff858f02f9>] sctp_outq_uncork+0x79/0xb0 net/sctp/outqueue.c:764 [<ffffffff8589f060>] sctp_side_effects net/sctp/sm_sideeffect.c:1199 [inline] [<ffffffff8589f060>] sctp_do_sm+0x55c0/0x5c30 net/sctp/sm_sideeffect.c:1170 [<ffffffff85941567>] sctp_primitive_ASSOCIATE+0x97/0xc0 net/sctp/primitive.c:73 [<ffffffff859408b2>] sctp_sendmsg_to_asoc+0xf62/0x17b0 net/sctp/socket.c:1839 [<ffffffff85910b5e>] sctp_sendmsg+0x212e/0x33b0 net/sctp/socket.c:2029 [<ffffffff8544d559>] inet_sendmsg+0x149/0x310 net/ipv4/af_inet.c:849 [<ffffffff84c6c4d2>] sock_sendmsg_nosec net/socket.c:716 [inline] [<ffffffff84c6c4d2>] sock_sendmsg net/socket.c:736 [inline] [<ffffffff84c6c4d2>] ____sys_sendmsg+0x572/0x8c0 net/socket.c:2504 [<ffffffff84c6ca91>] ___sys_sendmsg net/socket.c:2558 [inline] [<ffffffff84c6ca91>] __sys_sendmsg+0x271/0x360 net/socket.c:2587 [<ffffffff84c6cbff>] __do_sys_sendmsg net/socket.c:2596 [inline] [<ffffffff84c6cbff>] __se_sys_sendmsg net/socket.c:2594 [inline] [<ffffffff84c6cbff>] __x64_sys_sendmsg+0x7f/0x90 net/socket.c:2594 [<ffffffff85b32553>] do_syscall_x64 arch/x86/entry/common.c:51 [inline] [<ffffffff85b32553>] do_syscall_64+0x53/0x80 arch/x86/entry/common.c:84 [<ffffffff85c00087>] entry_SYSCALL_64_after_hwframe+0x63/0xcd
--- drivers/net/ipvlan/ipvlan_core.c | 41 +++++++++++++++++++------------- 1 file changed, 25 insertions(+), 16 deletions(-)
drivers/net/ipvlan/ipvlan_core.c +25 -16
@@ -411,7 +411,7 @@ struct ipvl_addr *ipvlan_addr_lookup(struct ipvl_port *port, void *lyr3h,return addr; } -static int ipvlan_process_v4_outbound (struct sk_buff *skb) +static noinline_for_stack int ipvlan_process_v4_outbound(struct sk_buff *skb) {const struct iphdr *ip4h =ip_hdr (skb);struct net_device *dev = skb->dev;
@@ -453,13 +453,11 @@ static int ipvlan_process_v4_outbound(struct sk_buff *skb) } #if IS_ENABLED(CONFIG_IPV6) -static int ipvlan_process_v6_outbound(struct sk_buff *skb) + +static noinline_for_stack int +ipvlan_route_v6_outbound(struct net_device *dev, struct sk_buff *skb) { const struct ipv6hdr *ip6h = ipv6_hdr(skb); - struct net_device *dev = skb->dev; - struct net *net = dev_net(dev); - struct dst_entry *dst; - int err, ret = NET_XMIT_DROP; struct flowi6 fl6 = { .flowi6_oif = dev->ifindex, .daddr = ip6h->daddr,
@@ -469,27 +467,38 @@ static int ipvlan_process_v6_outbound(struct sk_buff *skb) .flowi6_mark = skb->mark, .flowi6_proto = ip6h->nexthdr, }; +struct dst_entry *dst; +int err; - dst =ip6_route_output (net,NULL , &fl6); -if (dst->error) { - ret = dst->error; + dst =ip6_route_output (dev_net (dev),NULL , &fl6); + err = dst->error; +if (err) {dst_release (dst); - goto err; +return err; }skb_dst_set (skb, dst); +return 0 ; +} + +static int ipvlan_process_v6_outbound (struct sk_buff *skb) +{ +struct net_device *dev = skb->dev; +int err, ret =NET_XMIT_DROP ; + + err =ipvlan_route_v6_outbound (dev, skb); +if (unlikely (err)) { +DEV_STATS_INC (dev, tx_errors); +kfree_skb (skb); +return err; + }memset (IP6CB (skb),0 ,sizeof (*IP6CB (skb))); - err =ip6_local_out (net, skb->sk, skb); + err =ip6_local_out (dev_net (dev), skb->sk, skb);if (unlikely (net_xmit_eval (err)))DEV_STATS_INC (dev, tx_errors);else ret =NET_XMIT_SUCCESS ; - goto out; -err: -DEV_STATS_INC (dev, tx_errors); -kfree_skb (skb); -out:return ret; }#else
Signature · 1 line
2.42.0
Greg Kroah-Hartman
maintainerPATCH 175/491 tty: Fix uninit-value access in ppp_sync_receive()
In reply to Greg Kroah-Hartman6.5-stable review patch. If anyone has any objections, please let me know.
------------------
From: Shigeru Yoshida <[email protected]>
[ Upstream commit 719639853d88071dfdfd8d9971eca9c283ff314c ]
KMSAN reported the following uninit-value access issue:
=====================================================
BUG: KMSAN: uninit-value in ppp_sync_input drivers/net/ppp/ppp_synctty.c:690 [inline] BUG: KMSAN: uninit-value in ppp_sync_receive+0xdc9/0xe70 drivers/net/ppp/ppp_synctty.c:334 ppp_sync_input drivers/net/ppp/ppp_synctty.c:690 [inline] ppp_sync_receive+0xdc9/0xe70 drivers/net/ppp/ppp_synctty.c:334 tiocsti+0x328/0x450 drivers/tty/tty_io.c:2295 tty_ioctl+0x808/0x1920 drivers/tty/tty_io.c:2694 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:871 [inline] __se_sys_ioctl+0x211/0x400 fs/ioctl.c:857 __x64_sys_ioctl+0x97/0xe0 fs/ioctl.c:857 do_syscall_x64 arch/x86/entry/common.c:51 [inline] do_syscall_64+0x44/0x110 arch/x86/entry/common.c:82 entry_SYSCALL_64_after_hwframe+0x63/0x6b
Uninit was created at:
__alloc_pages+0x75d/0xe80 mm/page_alloc.c:4591 __alloc_pages_node include/linux/gfp.h:238 [inline] alloc_pages_node include/linux/gfp.h:261 [inline] __page_frag_cache_refill+0x9a/0x2c0 mm/page_alloc.c:4691 page_frag_alloc_align+0x91/0x5d0 mm/page_alloc.c:4722 page_frag_alloc include/linux/gfp.h:322 [inline] __netdev_alloc_skb+0x215/0x6d0 net/core/skbuff.c:728 netdev_alloc_skb include/linux/skbuff.h:3225 [inline] dev_alloc_skb include/linux/skbuff.h:3238 [inline] ppp_sync_input drivers/net/ppp/ppp_synctty.c:669 [inline] ppp_sync_receive+0x237/0xe70 drivers/net/ppp/ppp_synctty.c:334 tiocsti+0x328/0x450 drivers/tty/tty_io.c:2295 tty_ioctl+0x808/0x1920 drivers/tty/tty_io.c:2694 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:871 [inline] __se_sys_ioctl+0x211/0x400 fs/ioctl.c:857 __x64_sys_ioctl+0x97/0xe0 fs/ioctl.c:857 do_syscall_x64 arch/x86/entry/common.c:51 [inline] do_syscall_64+0x44/0x110 arch/x86/entry/common.c:82 entry_SYSCALL_64_after_hwframe+0x63/0x6b CPU: 0 PID: 12950 Comm: syz-executor.1 Not tainted 6.6.0-14500-g1c41041124bd #10 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.2-1.fc38 04/01/2014 =====================================================
ppp_sync_input() checks the first 2 bytes of the data are PPP_ALLSTATIONS and PPP_UI. However, if the data length is 1 and the first byte is PPP_ALLSTATIONS, an access to an uninitialized value occurs when checking PPP_UI. This patch resolves this issue by checking the data length.
--- drivers/net/ppp/ppp_synctty.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/net/ppp/ppp_synctty.c +1 -1
@@ -697,7 +697,7 @@ ppp_sync_input(struct syncppp *ap, const unsigned char *buf,/* strip address/control field if present */ p = skb->data; -if (p[0 ] ==PPP_ALLSTATIONS && p[1 ] ==PPP_UI ) { +if (skb->len >=2 && p[0 ] ==PPP_ALLSTATIONS && p[1 ] ==PPP_UI ) {/* chop off address/control */ if (skb->len <3 ) goto err;
Signature · 1 line
2.42.0
Greg Kroah-Hartman
maintainerPATCH 176/491 xen/events: avoid using info_for_irq() in xen_send_IPI_one()
In reply to Greg Kroah-Hartman6.5-stable review patch. If anyone has any objections, please let me know.
------------------
From: Juergen Gross <[email protected]>
[ Upstream commit e64e7c74b99ec9e439abca75f522f4b98f220bd1 ]
xen_send_IPI_one() is being used by cpuhp_report_idle_dead() after it calls rcu_report_dead(), meaning that any RCU usage by xen_send_IPI_one() is a bad idea.
Unfortunately xen_send_IPI_one() is using notify_remote_via_irq() today, which is using irq_get_chip_data() via info_for_irq(). And irq_get_chip_data() in turn is using a maple-tree lookup requiring RCU.
Avoid this problem by caching the ipi event channels in another percpu variable, allowing the use notify_remote_via_evtchn() in xen_send_IPI_one().
--- drivers/xen/events/events_base.c | 12 ++++++++---- 1 file changed, 8 insertions(+), 4 deletions(-)
drivers/xen/events/events_base.c +8 -4
@@ -164,6 +164,8 @@ static DEFINE_PER_CPU(int [NR_VIRQS], virq_to_irq) = {[0 ... NR_VIRQS-1] = -1};/* IRQ <-> IPI mapping */ static DEFINE_PER_CPU(int [XEN_NR_IPIS], ipi_to_irq) = {[0 ... XEN_NR_IPIS-1] = -1}; +/* Cache for IPI event channels - needed for hot cpu unplug (avoid RCU usage). */ +static DEFINE_PER_CPU(evtchn_port_t [XEN_NR_IPIS], ipi_to_evtchn) = {[0 ... XEN_NR_IPIS-1] = 0};/* Event channel distribution data */ static atomic_t channels_on_cpu[NR_CPUS ];
@@ -366,6 +368,7 @@ static int xen_irq_info_ipi_setup(unsigned cpu, info->u.ipi = ipi;per_cpu (ipi_to_irq, cpu)[ipi] = irq; +per_cpu (ipi_to_evtchn, cpu)[ipi] = evtchn;return xen_irq_info_common_setup (info, irq,IRQT_IPI , evtchn,0 ); }
@@ -981,6 +984,7 @@ static void __unbind_from_irq(unsigned int irq)break ;case IRQT_IPI :per_cpu (ipi_to_irq, cpu)[ipi_from_irq (irq)] =-1 ; +per_cpu (ipi_to_evtchn, cpu)[ipi_from_irq (irq)] =0 ;break ;case IRQT_EVTCHN : dev = info->u.interdomain;
@@ -1631,7 +1635,7 @@ EXPORT_SYMBOL_GPL(evtchn_put);void xen_send_IPI_one (unsigned int cpu,enum ipi_vector vector) { -int irq; +evtchn_port_t evtchn;#ifdef CONFIG_X86 if (unlikely (vector ==XEN_NMI_VECTOR )) {
@@ -1642,9 +1646,9 @@ void xen_send_IPI_one(unsigned int cpu, enum ipi_vector vector)return ; }#endif - irq =per_cpu (ipi_to_irq, cpu)[vector]; -BUG_ON (irq <0 ); -notify_remote_via_irq (irq); + evtchn =per_cpu (ipi_to_evtchn, cpu)[vector]; +BUG_ON (evtchn ==0 ); +notify_remote_via_evtchn (evtchn); } struct evtchn_loop_ctrl {
Signature · 1 line
2.42.0
Re: [PATCH 6.5 176/491] xen/events: avoid using info_for_irq() in xen_send_IPI_one()
Quoted 12 lines · Greg Kroah-Hartman
6.5-stable review patch. If anyone has any objections, please let me know.
------------------
From: Juergen Gross <[email protected]>
[ Upstream commit
e64e7c74b99ec9e439abca75f522f4b98f220bd1]
xen_send_IPI_one()is being used bycpuhp_report_idle_dead()after it callsrcu_report_dead(), meaning that any RCU usage byxen_send_IPI_one()is a bad idea.
Quoted 8 lines
Unfortunately
xen_send_IPI_one()is usingnotify_remote_via_irq()today, which is usingirq_get_chip_data()viainfo_for_irq(). Andirq_get_chip_data()in turn is using a maple-tree lookup requiring RCU.Avoid this problem by caching the ipi event channels in another percpu variable, allowing the use
notify_remote_via_evtchn()inxen_send_IPI_one().
IIRC, the result of this bug is a mostly harmless lockdep splat.
On the other hand, the result of *fixing* this bug is that lockdep doesn't whine, and lockdep keeps working. Only to later trigger a warning really early during cpu hotplug, causing the whole machine to go down with a triple-fault.
Can we have the backport of
https://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm.git/commit/?h=linux-next&id=9bb69ba4c177dccaa1f5b5cbdf80b67813328348
*first* and then this one?
Greg Kroah-Hartman
maintainerPATCH 177/491 net: hns3: fix add VLAN fail issue
In reply to Greg Kroah-Hartman6.5-stable review patch. If anyone has any objections, please let me know.
------------------
From: Jian Shen <[email protected]>
[ Upstream commit 472a2ff63efb30234cbf6b2cdaf8117f21b4f8bc ]
The hclge_sync_vlan_filter is called in periodic task, trying to remove VLAN from vlan_del_fail_bmap. It can be concurrence with VLAN adding operation from user. So once user failed to delete a VLAN id, and add it again soon, it may be removed by the periodic task, which may cause the software configuration being inconsistent with hardware. So add mutex handling to avoid this.
user hns3 driver
periodic task
│
add vlan 10 ───── hns3_vlan_rx_add_vid │
│ (suppose success) │
│ │
del vlan 10 ───── hns3_vlan_rx_kill_vid │
│ (suppose fail,add to │
│ vlan_del_fail_bmap) │
│ │
add vlan 10 ───── hns3_vlan_rx_add_vid │
(suppose success) │ foreach vlan_del_fail_bmp
del vlan 10
--- .../hisilicon/hns3/hns3pf/hclge_main.c | 28 +++++++++++++------ .../hisilicon/hns3/hns3vf/hclgevf_main.c | 11 ++++++-- 2 files changed, 29 insertions(+), 10 deletions(-)
drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c +20 -8
@@ -10026,8 +10026,6 @@ static void hclge_rm_vport_vlan_table(struct hclge_vport *vport, u16 vlan_id,struct hclge_vport_vlan_cfg *vlan, *tmp;struct hclge_dev *hdev = vport->back; -mutex_lock (&hdev->vport_lock); -list_for_each_entry_safe (vlan, tmp, &vport->vlan_list, node) {if (vlan->vlan_id == vlan_id) {if (is_write_tbl && vlan->hd_tbl_status)
@@ -10042,8 +10040,6 @@ static void hclge_rm_vport_vlan_table(struct hclge_vport *vport, u16 vlan_id,break ; } } - -mutex_unlock (&hdev->vport_lock); }void hclge_rm_vport_all_vlan_table (struct hclge_vport *vport,bool is_del_list)
@@ -10452,11 +10448,16 @@ int hclge_set_vlan_filter(struct hnae3_handle *handle, __be16 proto,* handle mailbox. Just record the vlan id, and remove it after * reset finished. */ +mutex_lock (&hdev->vport_lock);if ((test_bit (HCLGE_STATE_RST_HANDLING , &hdev->state) ||test_bit (HCLGE_STATE_RST_FAIL , &hdev->state)) && is_kill) {set_bit (vlan_id, vport->vlan_del_fail_bmap); +mutex_unlock (&hdev->vport_lock);return -EBUSY ; + }else if (!is_kill &&test_bit (vlan_id, vport->vlan_del_fail_bmap)) { +clear_bit (vlan_id, vport->vlan_del_fail_bmap); } +mutex_unlock (&hdev->vport_lock);/* when port base vlan enabled, we use port base vlan as the vlan * filter entry. In this case, we don't update vlan filter table
@@ -10471,17 +10472,22 @@ int hclge_set_vlan_filter(struct hnae3_handle *handle, __be16 proto, }if (!ret) { -if (!is_kill) +if (!is_kill) {hclge_add_vport_vlan_table (vport, vlan_id, writen_to_tbl); -else if (is_kill && vlan_id !=0 ) + }else if (is_kill && vlan_id !=0 ) { +mutex_lock (&hdev->vport_lock);hclge_rm_vport_vlan_table (vport, vlan_id, false); +mutex_unlock (&hdev->vport_lock); + } }else if (is_kill) {/* when remove hw vlan filter failed, record the vlan id, * and try to remove it from hw later, to be consistence * with stack */ +mutex_lock (&hdev->vport_lock);set_bit (vlan_id, vport->vlan_del_fail_bmap); +mutex_unlock (&hdev->vport_lock); }hclge_set_vport_vlan_fltr_change (vport);
@@ -10521,6 +10527,7 @@ static void hclge_sync_vlan_filter(struct hclge_dev *hdev)int i, ret, sync_cnt =0 ;u16 vlan_id; +mutex_lock (&hdev->vport_lock);/* start from vport 1 for PF is always alive */ for (i =0 ; i < hdev->num_alloc_vport; i++) {struct hclge_vport *vport = &hdev->vport[i];
@@ -10531,21 +10538,26 @@ static void hclge_sync_vlan_filter(struct hclge_dev *hdev) ret =hclge_set_vlan_filter_hw (hdev,htons (ETH_P_8021Q ), vport->vport_id, vlan_id, true); -if (ret && ret != -EINVAL ) +if (ret && ret != -EINVAL ) { +mutex_unlock (&hdev->vport_lock);return ; + }clear_bit (vlan_id, vport->vlan_del_fail_bmap);hclge_rm_vport_vlan_table (vport, vlan_id, false);hclge_set_vport_vlan_fltr_change (vport); sync_cnt++; -if (sync_cnt >=HCLGE_MAX_SYNC_COUNT ) +if (sync_cnt >=HCLGE_MAX_SYNC_COUNT ) { +mutex_unlock (&hdev->vport_lock);return ; + } vlan_id =find_first_bit (vport->vlan_del_fail_bmap,VLAN_N_VID ); } } +mutex_unlock (&hdev->vport_lock);hclge_sync_vlan_fltr_state (hdev); }
drivers/net/ethernet/hisilicon/hns3/hns3vf/hclgevf_main.c +9 -2
@@ -1206,6 +1206,8 @@ static int hclgevf_set_vlan_filter(struct hnae3_handle *handle, test_bit(HCLGEVF_STATE_RST_FAIL, &hdev->state)) && is_kill) {set_bit (vlan_id, hdev->vlan_del_fail_bmap);return -EBUSY ; + } else if (!is_kill && test_bit(vlan_id, hdev->vlan_del_fail_bmap)) { +clear_bit (vlan_id, hdev->vlan_del_fail_bmap); } hclgevf_build_send_msg(&send_msg, HCLGE_MBX_SET_VLAN,
@@ -1233,20 +1235,25 @@ static void hclgevf_sync_vlan_filter(struct hclgevf_dev *hdev)int ret, sync_cnt =0 ;u16 vlan_id; +if (bitmap_empty (hdev->vlan_del_fail_bmap,VLAN_N_VID )) +return ; + +rtnl_lock (); vlan_id =find_first_bit (hdev->vlan_del_fail_bmap,VLAN_N_VID );while (vlan_id !=VLAN_N_VID ) { ret =hclgevf_set_vlan_filter (handle,htons (ETH_P_8021Q ), vlan_id, true);if (ret) -return ; +break ;clear_bit (vlan_id, hdev->vlan_del_fail_bmap); sync_cnt++;if (sync_cnt >=HCLGEVF_MAX_SYNC_COUNT ) -return ; +break ; vlan_id =find_first_bit (hdev->vlan_del_fail_bmap,VLAN_N_VID ); } +rtnl_unlock (); }static int hclgevf_en_hw_strip_rxvtag (struct hnae3_handle *handle,bool enable)
Signature · 1 line
2.42.0
Greg Kroah-Hartman
maintainerPATCH 178/491 net: hns3: add barrier in vf mailbox reply process
In reply to Greg Kroah-Hartman6.5-stable review patch. If anyone has any objections, please let me know.
------------------
From: Yonglong Liu <[email protected]>
[ Upstream commit ac92c0a9a0603fb448e60f38e63302e4eebb8035 ]
In hclgevf_mbx_handler() and hclgevf_get_mbx_resp() functions, there is a typical store-store and load-load scenario between received_resp and additional_info. This patch adds barrier to fix the problem.
--- drivers/net/ethernet/hisilicon/hns3/hns3vf/hclgevf_mbx.c | 7 +++++++ 1 file changed, 7 insertions(+)
drivers/net/ethernet/hisilicon/hns3/hns3vf/hclgevf_mbx.c +7 -0
@@ -63,6 +63,9 @@ static int hclgevf_get_mbx_resp(struct hclgevf_dev *hdev, u16 code0, u16 code1, i++; } +/* ensure additional_info will be seen after received_resp */ +smp_rmb (); +if (i >=HCLGEVF_MAX_TRY_TIMES ) { dev_err(&hdev->pdev->dev, "VF could not get mbx(%u,%u) resp(=%d) from PF in %d tries\n",
@@ -178,6 +181,10 @@ static void hclgevf_handle_mbx_response(struct hclgevf_dev *hdev, resp->resp_status =hclgevf_resp_to_errno (resp_status);memcpy (resp->additional_info, req->msg.resp_data,HCLGE_MBX_MAX_RESP_DATA_SIZE *sizeof (u8)); + +/* ensure additional_info will be seen before setting received_resp */ +smp_wmb (); +if (match_id) {/* If match_id is not zero, it means PF support match_id. * if the match_id is right, VF get the right response, or
Signature · 1 line
2.42.0
Greg Kroah-Hartman
maintainerPATCH 179/491 net: hns3: fix incorrect capability bit display for copper port
In reply to Greg Kroah-Hartman6.5-stable review patch. If anyone has any objections, please let me know.
------------------
From: Jian Shen <[email protected]>
[ Upstream commit 75b247b57d8b71bcb679e4cb37d0db104848806c ]
Currently, the FEC capability bit is default set for device version V2. It's incorrect for the copper port. Eventhough it doesn't make the nic work abnormal, but the capability information display in debugfs may confuse user. So clear it when driver get the port type inforamtion.
--- drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c | 1 + 1 file changed, 1 insertion(+)
drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c +1 -0
@@ -11664,6 +11664,7 @@ static int hclge_init_ae_dev(struct hnae3_ae_dev *ae_dev) goto err_msi_irq_uninit;if (hdev->hw.mac.media_type ==HNAE3_MEDIA_TYPE_COPPER ) { +clear_bit (HNAE3_DEV_SUPPORT_FEC_B , ae_dev->caps);if (hnae3_dev_phy_imp_supported (hdev)) ret =hclge_update_tp_port_info (hdev);else
Signature · 1 line
2.42.0
Greg Kroah-Hartman
maintainerPATCH 180/491 net: hns3: fix out-of-bounds access may occur when coalesce info is read via debugfs
In reply to Greg Kroah-Hartman6.5-stable review patch. If anyone has any objections, please let me know.
------------------
From: Yonglong Liu <[email protected]>
[ Upstream commit 53aba458f23846112c0d44239580ff59bc5c36c3 ]
The hns3 driver define an array of string to show the coalesce info, but if the kernel adds a new mode or a new state, out-of-bounds access may occur when coalesce info is read via debugfs, this patch fix the problem.
--- drivers/net/ethernet/hisilicon/hns3/hns3_debugfs.c | 9 ++++++--- 1 file changed, 6 insertions(+), 3 deletions(-)
drivers/net/ethernet/hisilicon/hns3/hns3_debugfs.c +6 -3
@@ -500,11 +500,14 @@ static void hns3_get_coal_info(struct hns3_enet_tqp_vector *tqp_vector, }sprintf (result[j++],"%d" , i); -sprintf (result[j++],"%s" , dim_state_str[dim->state]); +sprintf (result[j++],"%s" , dim->state <ARRAY_SIZE (dim_state_str) ? + dim_state_str[dim->state] :"unknown" );sprintf (result[j++],"%u" , dim->profile_ix); -sprintf (result[j++],"%s" , dim_cqe_mode_str[dim->mode]); +sprintf (result[j++],"%s" , dim->mode <ARRAY_SIZE (dim_cqe_mode_str) ? + dim_cqe_mode_str[dim->mode] :"unknown" );sprintf (result[j++],"%s" , - dim_tune_stat_str[dim->tune_state]); + dim->tune_state <ARRAY_SIZE (dim_tune_stat_str) ? + dim_tune_stat_str[dim->tune_state] :"unknown" );sprintf (result[j++],"%u" , dim->steps_left);sprintf (result[j++],"%u" , dim->steps_right);sprintf (result[j++],"%u" , dim->tired);
Signature · 1 line
2.42.0
Greg Kroah-Hartman
maintainerPATCH 181/491 net: hns3: fix variable may not initialized problem in hns3_init_mac_addr()
In reply to Greg Kroah-Hartman6.5-stable review patch. If anyone has any objections, please let me know.
------------------
From: Yonglong Liu <[email protected]>
[ Upstream commit dbd2f3b20c6ae425665b6975d766e3653d453e73 ]
When a VF is calling hns3_init_mac_addr(), get_mac_addr() may return fail, then the value of mac_addr_temp is not initialized.
--- drivers/net/ethernet/hisilicon/hns3/hns3_enet.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/net/ethernet/hisilicon/hns3/hns3_enet.c +1 -1
@@ -5139,7 +5139,7 @@ static int hns3_init_mac_addr(struct net_device *netdev)struct hns3_nic_priv *priv =netdev_priv (netdev);char format_mac_addr[HNAE3_FORMAT_MAC_ADDR_LEN ];struct hnae3_handle *h = priv->ae_handle; -u8 mac_addr_temp[ETH_ALEN ]; +u8 mac_addr_temp[ETH_ALEN ] = {0 };int ret =0 ;if (h->ae_algo->ops->get_mac_addr)
Signature · 1 line
2.42.0
Greg Kroah-Hartman
maintainerPATCH 182/491 net: hns3: fix VF reset fail issue
In reply to Greg Kroah-Hartman6.5-stable review patch. If anyone has any objections, please let me know.
------------------
From: Jijie Shao <[email protected]>
[ Upstream commit 65e98bb56fa3ce2edb400930c05238c9b380500e ]
Currently the reset process in hns3 and firmware watchdog init process is asynchronous. We think firmware watchdog initialization is completed before VF clear the interrupt source. However, firmware initialization may not complete early. So VF will receive multiple reset interrupts and fail to reset.
So we add delay before VF interrupt source and 5 ms delay is enough to avoid second reset interrupt.
--- .../ethernet/hisilicon/hns3/hns3vf/hclgevf_main.c | 14 +++++++++++++- .../ethernet/hisilicon/hns3/hns3vf/hclgevf_main.h | 1 + 2 files changed, 14 insertions(+), 1 deletion(-)
drivers/net/ethernet/hisilicon/hns3/hns3vf/hclgevf_main.c +13 -1
@@ -1981,8 +1981,18 @@ static enum hclgevf_evt_cause hclgevf_check_evt_cause(struct hclgevf_dev *hdev,return HCLGEVF_VECTOR0_EVENT_OTHER ; } +static void hclgevf_reset_timer (struct timer_list *t) +{ +struct hclgevf_dev *hdev =from_timer (hdev, t, reset_timer); + +hclgevf_clear_event_cause (hdev,HCLGEVF_VECTOR0_EVENT_RST ); +hclgevf_reset_task_schedule (hdev); +} +static irqreturn_t hclgevf_misc_irq_handle (int irq,void *data) { +#define HCLGEVF_RESET_DELAY 5 +enum hclgevf_evt_cause event_cause;struct hclgevf_dev *hdev = data;u32 clearval;
@@ -1994,7 +2004,8 @@ static irqreturn_t hclgevf_misc_irq_handle(int irq, void *data)switch (event_cause) {case HCLGEVF_VECTOR0_EVENT_RST : -hclgevf_reset_task_schedule (hdev); +mod_timer (&hdev->reset_timer, + jiffies +msecs_to_jiffies (HCLGEVF_RESET_DELAY ));break ;case HCLGEVF_VECTOR0_EVENT_MBX :hclgevf_mbx_handler (hdev);
@@ -2937,6 +2948,7 @@ static int hclgevf_init_hdev(struct hclgevf_dev *hdev) HCLGEVF_DRIVER_NAME);hclgevf_task_schedule (hdev,round_jiffies_relative (HZ )); +timer_setup (&hdev->reset_timer, hclgevf_reset_timer,0 );return 0 ;
drivers/net/ethernet/hisilicon/hns3/hns3vf/hclgevf_main.h +1 -0
@@ -219,6 +219,7 @@ struct hclgevf_dev {enum hnae3_reset_type reset_level;unsigned long reset_pending;enum hnae3_reset_type reset_type; +struct timer_list reset_timer;#define HCLGEVF_RESET_REQUESTED 0#define HCLGEVF_RESET_PENDING 1
Signature · 1 line
2.42.0
Greg Kroah-Hartman
maintainerPATCH 183/491 net: hns3: fix VF wrong speed and duplex issue
In reply to Greg Kroah-Hartman6.5-stable review patch. If anyone has any objections, please let me know.
------------------
From: Jijie Shao <[email protected]>
[ Upstream commit dff655e82faffc287d4a72a59f66fa120bf904e4 ]
If PF is down, firmware will returns 10 Mbit/s rate and half-duplex mode when PF queries the port information from firmware.
After imp reset command is executed, PF status changes to down, and PF will query link status and updates port information from firmware in a periodic scheduled task.
However, there is a low probability that port information is updated when PF is down, and then PF link status changes to up. In this case, PF synchronizes incorrect rate and duplex mode to VF.
This patch fixes it by updating port information before PF synchronizes the rate and duplex to the VF when PF changes to up.
--- drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c | 4 ++++ 1 file changed, 4 insertions(+)
drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c +4 -0
@@ -61,6 +61,7 @@ static void hclge_sync_fd_table(struct hclge_dev *hdev);static void hclge_update_fec_stats (struct hclge_dev *hdev);static int hclge_mac_link_status_wait (struct hclge_dev *hdev,int link_ret,int wait_cnt); +static int hclge_update_port_info (struct hclge_dev *hdev);static struct hnae3_ae_algo ae_algo;
@@ -3043,6 +3044,9 @@ static void hclge_update_link_status(struct hclge_dev *hdev)if (state != hdev->hw.mac.link) { hdev->hw.mac.link = state; +if (state ==HCLGE_LINK_STATUS_UP ) +hclge_update_port_info (hdev); + client->ops->link_status_change (handle, state);hclge_config_mac_tnl_int (hdev, state);if (rclient && rclient->ops->link_status_change)
Signature · 1 line
2.42.0
Greg Kroah-Hartman
maintainerPATCH 184/491 tipc: Fix kernel-infoleak due to uninitialized TLV value
In reply to Greg Kroah-Hartman6.5-stable review patch. If anyone has any objections, please let me know.
------------------
From: Shigeru Yoshida <[email protected]>
[ Upstream commit fb317eb23b5ee4c37b0656a9a52a3db58d9dd072 ]
KMSAN reported the following kernel-infoleak issue:
=====================================================
BUG: KMSAN: kernel-infoleak in instrument_copy_to_user include/linux/instrumented.h:114 [inline] BUG: KMSAN: kernel-infoleak in copy_to_user_iter lib/iov_iter.c:24 [inline] BUG: KMSAN: kernel-infoleak in iterate_ubuf include/linux/iov_iter.h:29 [inline] BUG: KMSAN: kernel-infoleak in iterate_and_advance2 include/linux/iov_iter.h:245 [inline] BUG: KMSAN: kernel-infoleak in iterate_and_advance include/linux/iov_iter.h:271 [inline] BUG: KMSAN: kernel-infoleak in _copy_to_iter+0x4ec/0x2bc0 lib/iov_iter.c:186 instrument_copy_to_user include/linux/instrumented.h:114 [inline] copy_to_user_iter lib/iov_iter.c:24 [inline] iterate_ubuf include/linux/iov_iter.h:29 [inline] iterate_and_advance2 include/linux/iov_iter.h:245 [inline] iterate_and_advance include/linux/iov_iter.h:271 [inline] _copy_to_iter+0x4ec/0x2bc0 lib/iov_iter.c:186 copy_to_iter include/linux/uio.h:197 [inline] simple_copy_to_iter net/core/datagram.c:532 [inline] __skb_datagram_iter.5+0x148/0xe30 net/core/datagram.c:420 skb_copy_datagram_iter+0x52/0x210 net/core/datagram.c:546 skb_copy_datagram_msg include/linux/skbuff.h:3960 [inline] netlink_recvmsg+0x43d/0x1630 net/netlink/af_netlink.c:1967 sock_recvmsg_nosec net/socket.c:1044 [inline] sock_recvmsg net/socket.c:1066 [inline] __sys_recvfrom+0x476/0x860 net/socket.c:2246 __do_sys_recvfrom net/socket.c:2264 [inline] __se_sys_recvfrom net/socket.c:2260 [inline] __x64_sys_recvfrom+0x130/0x200 net/socket.c:2260 do_syscall_x64 arch/x86/entry/common.c:51 [inline] do_syscall_64+0x44/0x110 arch/x86/entry/common.c:82 entry_SYSCALL_64_after_hwframe+0x63/0x6b
Uninit was created at:
slab_post_alloc_hook+0x103/0x9e0 mm/slab.h:768 slab_alloc_node mm/slub.c:3478 [inline] kmem_cache_alloc_node+0x5f7/0xb50 mm/slub.c:3523 kmalloc_reserve+0x13c/0x4a0 net/core/skbuff.c:560 __alloc_skb+0x2fd/0x770 net/core/skbuff.c:651 alloc_skb include/linux/skbuff.h:1286 [inline] tipc_tlv_alloc net/tipc/netlink_compat.c:156 [inline] tipc_get_err_tlv+0x90/0x5d0 net/tipc/netlink_compat.c:170 tipc_nl_compat_recv+0x1042/0x15d0 net/tipc/netlink_compat.c:1324 genl_family_rcv_msg_doit net/netlink/genetlink.c:972 [inline] genl_family_rcv_msg net/netlink/genetlink.c:1052 [inline] genl_rcv_msg+0x1220/0x12c0 net/netlink/genetlink.c:1067 netlink_rcv_skb+0x4a4/0x6a0 net/netlink/af_netlink.c:2545 genl_rcv+0x41/0x60 net/netlink/genetlink.c:1076 netlink_unicast_kernel net/netlink/af_netlink.c:1342 [inline] netlink_unicast+0xf4b/0x1230 net/netlink/af_netlink.c:1368 netlink_sendmsg+0x1242/0x1420 net/netlink/af_netlink.c:1910 sock_sendmsg_nosec net/socket.c:730 [inline] __sock_sendmsg net/socket.c:745 [inline] ____sys_sendmsg+0x997/0xd60 net/socket.c:2588 ___sys_sendmsg+0x271/0x3b0 net/socket.c:2642 __sys_sendmsg net/socket.c:2671 [inline] __do_sys_sendmsg net/socket.c:2680 [inline] __se_sys_sendmsg net/socket.c:2678 [inline] __x64_sys_sendmsg+0x2fa/0x4a0 net/socket.c:2678 do_syscall_x64 arch/x86/entry/common.c:51 [inline] do_syscall_64+0x44/0x110 arch/x86/entry/common.c:82 entry_SYSCALL_64_after_hwframe+0x63/0x6b
Bytes 34-35 of 36 are uninitialized
Memory access of size 36 starts at ffff88802d464a00 Data copied to user address 00007ff55033c0a0
CPU: 0 PID: 30322 Comm: syz-executor.0 Not tainted 6.6.0-14500-g1c41041124bd #10 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.2-1.fc38 04/01/2014 =====================================================
tipc_add_tlv() puts TLV descriptor and value onto skb. This size is calculated with TLV_SPACE() macro. It adds the size of struct tlv_desc and the length of TLV value passed as an argument, and aligns the result to a multiple of TLV_ALIGNTO, i.e., a multiple of 4 bytes.
If the size of struct tlv_desc plus the length of TLV value is not aligned, the current implementation leaves the remaining bytes uninitialized. This is the cause of the above kernel-infoleak issue.
This patch resolves this issue by clearing data up to an aligned size.
--- net/tipc/netlink_compat.c | 1 + 1 file changed, 1 insertion(+)
net/tipc/netlink_compat.c +1 -0
@@ -102,6 +102,7 @@ static int tipc_add_tlv(struct sk_buff *skb, u16 type, void *data, u16 len)return -EMSGSIZE ;skb_put (skb,TLV_SPACE (len)); +memset (tlv,0 ,TLV_SPACE (len)); tlv->tlv_type =htons (type); tlv->tlv_len =htons (TLV_LENGTH (len));if (len && data)
Signature · 1 line
2.42.0
Greg Kroah-Hartman
maintainerPATCH 185/491 net: mvneta: fix calls to page_pool_get_stats
In reply to Greg Kroah-Hartman6.5-stable review patch. If anyone has any objections, please let me know.
------------------
From: Sven Auhagen <[email protected]>
[ Upstream commit ca8add922f9c7f6e2e3c71039da8e0dcc64b87ed ]
Calling page_pool_get_stats in the mvneta driver without checks leads to kernel crashes.
First the page pool is only available if the bm is not used. The page pool is also not allocated when the port is stopped. It can also be not allocated in case of errors.
The current implementation leads to the following crash calling ethstats on a port that is down or when calling it at the wrong moment:
ble to handle kernel NULL pointer dereference at virtual address 00000070 [00000070] *pgd=00000000
Internal error: Oops: 5 [#1] SMP ARM Hardware name: Marvell Armada 380/385 (Device Tree) PC is at page_pool_get_stats+0x18/0x1cc LR is at mvneta_ethtool_get_stats+0xa0/0xe0 [mvneta] pc : [<c0b413cc>] lr : [<bf0a98d8>] psr: a0000013
sp : f1439d48 ip : f1439dc0 fp : 0000001d
r10: 00000100 r9 : c4816b80 r8 : f0d75150
r7 : bf0b400c r6 : c238f000 r5 : 00000000 r4 : f1439d68
r3 : c2091040 r2 : ffffffd8 r1 : f1439d68 r0 : 00000000
Flags: NzCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment none
Control: 10c5387d Table: 066b004a DAC: 00000051
Register r0 information: NULL pointer
Register r1 information: 2-page vmalloc region starting at 0xf1438000 allocated at kernel_clone+0x9c/0x390 Register r2 information: non-paged memory
Register r3 information: slab kmalloc-2k start c2091000 pointer offset 64 size 2048
Register r4 information: 2-page vmalloc region starting at 0xf1438000 allocated at kernel_clone+0x9c/0x390 Register r5 information: NULL pointer
Register r6 information: slab kmalloc-cg-4k start c238f000 pointer offset 0 size 4096
Register r7 information: 15-page vmalloc region starting at 0xbf0a8000 allocated at load_module+0xa30/0x219c Register r8 information: 1-page vmalloc region starting at 0xf0d75000 allocated at ethtool_get_stats+0x138/0x208 Register r9 information: slab task_struct start c4816b80 pointer offset 0
Register r10 information: non-paged memory
Register r11 information: non-paged memory
Register r12 information: 2-page vmalloc region starting at 0xf1438000 allocated at kernel_clone+0x9c/0x390 Process snmpd (pid: 733, stack limit = 0x38de3a88)
Stack: (0xf1439d48 to 0xf143a000)
9d40: 000000c0 00000001 c238f000 bf0b400c f0d75150 c4816b80
9d60: 00000100 bf0a98d8 00000000 00000000 00000000 00000000 00000000 00000000 9d80: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 9da0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 9dc0: 00000dc0 5335509c 00000035 c238f000 bf0b2214 01067f50 f0d75000 c0b9b9c8 9de0: 0000001d 00000035 c2212094 5335509c c4816b80 c238f000 c5ad6e00 01067f50 9e00: c1b0be80 c4816b80 00014813 c0b9d7f0 00000000 00000000 0000001d 0000001d 9e20: 00000000 00001200 00000000 00000000 c216ed90 c73943b8 00000000 00000000 9e40: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 9e60: 00000000 c0ad9034 00000000 00000000 00000000 00000000 00000000 00000000 9e80: 00000000 00000000 00000000 5335509c c1b0be80 f1439ee4 00008946 c1b0be80 9ea0: 01067f50 f1439ee3 00000000 00000046 b6d77ae0 c0b383f0 00008946 becc83e8 9ec0: c1b0be80 00000051 0000000b c68ca480 c7172d00 c0ad8ff0 f1439ee3 cf600e40 9ee0: 01600e40 32687465 00000000 00000000 00000000 01067f50 00000000 00000000 9f00: 00000000 5335509c 00008946 00008946 00000000 c68ca480 becc83e8 c05e2de0 9f20: f1439fb0 c03002f0 00000006 5ac3c35a c4816b80 00000006 b6d77ae0 c030caf0 9f40: c4817350 00000014 f1439e1c 0000000c 00000000 00000051 01000000 00000014 9f60: 00003fec f1439edc 00000001 c0372abc b6d77ae0 c0372abc cf600e40 5335509c 9f80: c21e6800 01015c9c 0000000b 00008946 00000036 c03002f0 c4816b80 00000036 9fa0: b6d77ae0 c03000c0 01015c9c 0000000b 0000000b 00008946 becc83e8 00000000 9fc0: 01015c9c 0000000b 00008946 00000036 00000035 010678a0 b6d797ec b6d77ae0 9fe0: b6dbf738 becc838c b6d186d7 b6baa858 40000030 0000000b 00000000 00000000
page_pool_get_stats from mvneta_ethtool_get_stats+0xa0/0xe0 [mvneta] mvneta_ethtool_get_stats [mvneta] from ethtool_get_stats+0x154/0x208 ethtool_get_stats from dev_ethtool+0xf48/0x2480
dev_ethtool from dev_ioctl+0x538/0x63c
dev_ioctl from sock_ioctl+0x49c/0x53c
sock_ioctl from sys_ioctl+0x134/0xbd8
sys_ioctl from ret_fast_syscall+0x0/0x1c
Exception stack(0xf1439fa8 to 0xf1439ff0) 9fa0: 01015c9c 0000000b 0000000b 00008946 becc83e8 00000000 9fc0: 01015c9c 0000000b 00008946 00000036 00000035 010678a0 b6d797ec b6d77ae0 9fe0: b6dbf738 becc838c b6d186d7 b6baa858 Code: e28dd004 e1a05000 e2514000 0a00006a (e5902070)
This commit adds the proper checks before calling page_pool_get_stats.
--- drivers/net/ethernet/marvell/mvneta.c | 28 +++++++++++++++++++-------- 1 file changed, 20 insertions(+), 8 deletions(-)
drivers/net/ethernet/marvell/mvneta.c +20 -8
@@ -4790,14 +4790,17 @@ static void mvneta_ethtool_get_strings(struct net_device *netdev, u32 sset, u8 *data) {if (sset ==ETH_SS_STATS ) { +struct mvneta_port *pp =netdev_priv (netdev);int i;for (i =0 ; i <ARRAY_SIZE (mvneta_statistics); i++)memcpy (data + i *ETH_GSTRING_LEN , mvneta_statistics[i].name,ETH_GSTRING_LEN ); - data +=ETH_GSTRING_LEN *ARRAY_SIZE (mvneta_statistics); -page_pool_ethtool_stats_get_strings (data); +if (!pp->bm_priv) { + data +=ETH_GSTRING_LEN *ARRAY_SIZE (mvneta_statistics); +page_pool_ethtool_stats_get_strings (data); + } } }
@@ -4915,8 +4918,10 @@ static void mvneta_ethtool_pp_stats(struct mvneta_port *pp, u64 *data)struct page_pool_stats stats = {};int i; -for (i =0 ; i < rxq_number; i++) -page_pool_get_stats (pp->rxqs[i].page_pool, &stats); +for (i =0 ; i < rxq_number; i++) { +if (pp->rxqs[i].page_pool) +page_pool_get_stats (pp->rxqs[i].page_pool, &stats); + }page_pool_ethtool_stats_get (data, &stats); }
@@ -4932,14 +4937,21 @@ static void mvneta_ethtool_get_stats(struct net_device *dev,for (i =0 ; i <ARRAY_SIZE (mvneta_statistics); i++) *data++ = pp->ethtool_stats[i]; -mvneta_ethtool_pp_stats (pp, data); +if (!pp->bm_priv) +mvneta_ethtool_pp_stats (pp, data); }static int mvneta_ethtool_get_sset_count (struct net_device *dev,int sset) { -if (sset ==ETH_SS_STATS ) -return ARRAY_SIZE (mvneta_statistics) + -page_pool_ethtool_stats_get_count (); +if (sset ==ETH_SS_STATS ) { +int count =ARRAY_SIZE (mvneta_statistics); +struct mvneta_port *pp =netdev_priv (dev); + +if (!pp->bm_priv) + count +=page_pool_ethtool_stats_get_count (); + +return count; + }return -EOPNOTSUPP ; }
Signature · 1 line
2.42.0
Greg Kroah-Hartman
maintainerPATCH 186/491 ppp: limit MRU to 64K
In reply to Greg Kroah-Hartman6.5-stable review patch. If anyone has any objections, please let me know.
------------------
From: Willem de Bruijn <[email protected]>
[ Upstream commit c0a2a1b0d631fc460d830f52d06211838874d655 ]
ppp_sync_ioctl allows setting device MRU, but does not sanity check this input.
Limit to a sane upper bound of 64KB.
No implementation I could find generates larger than 64KB frames. RFC 2823 mentions an upper bound of PPP over SDL of 64KB based on the 16-bit length field. Other protocols will be smaller, such as PPPoE (9KB jumbo frame) and PPPoA (18190 maximum CPCS-SDU size, RFC 2364). PPTP and L2TP encapsulate in IP.
Syzbot managed to trigger alloc warning in __alloc_pages:
if (WARN_ON_ONCE_GFP(order > MAX_ORDER, gfp))
WARNING: CPU: 1 PID: 37 at mm/page_alloc.c:4544 __alloc_pages+0x3ab/0x4a0 mm/page_alloc.c:4544
__alloc_skb+0x12b/0x330 net/core/skbuff.c:651
__netdev_alloc_skb+0x72/0x3f0 net/core/skbuff.c:715
netdev_alloc_skb include/linux/skbuff.h:3225 [inline]
dev_alloc_skb include/linux/skbuff.h:3238 [inline]
ppp_sync_input drivers/net/ppp/ppp_synctty.c:669 [inline]
ppp_sync_receive+0xff/0x680 drivers/net/ppp/ppp_synctty.c:334
tty_ldisc_receive_buf+0x14c/0x180 drivers/tty/tty_buffer.c:390
tty_port_default_receive_buf+0x70/0xb0 drivers/tty/tty_port.c:37
receive_buf drivers/tty/tty_buffer.c:444 [inline]
flush_to_ldisc+0x261/0x780 drivers/tty/tty_buffer.c:494
process_one_work+0x884/0x15c0 kernel/workqueue.c:2630With call
ioctl$PPPIOCSMRU1(r1, 0x40047452, &(0x7f0000000100)=0x5e6417a8)
Similar code exists in other drivers that implement ppp_channel_ops ioctl PPPIOCSMRU. Those might also be in scope. Notably excluded from this are pppol2tp_ioctl and pppoe_ioctl.
This code goes back to the start of git history.
--- drivers/net/ppp/ppp_synctty.c | 4 ++++ 1 file changed, 4 insertions(+)
drivers/net/ppp/ppp_synctty.c +4 -0
@@ -462,6 +462,10 @@ ppp_sync_ioctl(struct ppp_channel *chan, unsigned int cmd, unsigned long arg)case PPPIOCSMRU :if (get_user (val, (int __user *) argp))break ; +if (val >U16_MAX ) { + err = -EINVAL ; +break ; + }if (val <PPP_MRU ) val =PPP_MRU ; ap->mru = val;
Signature · 1 line
2.42.0
Greg Kroah-Hartman
maintainerPATCH 187/491 xen/events: fix delayed eoi list handling
In reply to Greg Kroah-Hartman6.5-stable review patch. If anyone has any objections, please let me know.
------------------
From: Juergen Gross <[email protected]>
[ Upstream commit 47d970204054f859f35a2237baa75c2d84fcf436 ]
When delaying eoi handling of events, the related elements are queued into the percpu lateeoi list. In case the list isn't empty, the elements should be sorted by the time when eoi handling is to happen.
Unfortunately a new element will never be queued at the start of the list, even if it has a handling time lower than all other list elements.
Fix that by handling that case the same way as for an empty list.
--- drivers/xen/events/events_base.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-)
drivers/xen/events/events_base.c +3 -1
@@ -604,7 +604,9 @@ static void lateeoi_list_add(struct irq_info *info)spin_lock_irqsave (&eoi->eoi_list_lock, flags); -if (list_empty (&eoi->eoi_list)) { + elem = list_first_entry_or_null(&eoi->eoi_list, struct irq_info, + eoi_list); +if (!elem || info->eoi_time < elem->eoi_time) {list_add (&info->eoi_list, &eoi->eoi_list);mod_delayed_work_on (info->eoi_cpu, system_wq, &eoi->delayed, delay);
Signature · 1 line
2.42.0
Greg Kroah-Hartman
maintainerPATCH 188/491 blk-mq: make sure active queue usage is held for bio_integrity_prep()
In reply to Greg Kroah-Hartman6.5-stable review patch. If anyone has any objections, please let me know.
------------------
From: Christoph Hellwig <[email protected]>
[ Upstream commit b0077e269f6c152e807fdac90b58caf012cdbaab ]
blk_integrity_unregister() can come if queue usage counter isn't held for one bio with integrity prepared, so this request may be completed with calling profile->complete_fn, then kernel panic.
Another constraint is that bio_integrity_prep() needs to be called before bio merge.
Fix the issue by:
- call bio_integrity_prep() with one queue usage counter grabbed reliably
- call bio_integrity_prep() before bio merge
--- block/blk-mq.c | 75 +++++++++++++++++++++++++------------------------- 1 file changed, 38 insertions(+), 37 deletions(-)
block/blk-mq.c +38 -37
@@ -2874,11 +2874,8 @@ static struct request *blk_mq_get_new_requests(struct request_queue *q, };struct request *rq; -if (unlikely (bio_queue_enter (bio))) -return NULL ; -if (blk_mq_attempt_bio_merge (q, bio, nsegs)) - goto queue_exit; +return NULL ;rq_qos_throttle (q, bio);
@@ -2894,35 +2891,23 @@ static struct request *blk_mq_get_new_requests(struct request_queue *q,rq_qos_cleanup (q, bio);if (bio->bi_opf &REQ_NOWAIT )bio_wouldblock_error (bio); -queue_exit: -blk_queue_exit (q);return NULL ; } -static inline struct request *blk_mq_get_cached_request (struct request_queue *q, -struct blk_plug *plug,struct bio **bio,unsigned int nsegs) +/* return true if this @rq can be used for @bio */ +static bool blk_mq_can_use_cached_rq (struct request *rq,struct blk_plug *plug, +struct bio *bio) { -struct request *rq; -enum hctx_type type, hctx_type; +enum hctx_type type =blk_mq_get_hctx_type (bio->bi_opf); +enum hctx_type hctx_type = rq->mq_hctx->type; -if (!plug) -return NULL ; - rq =rq_list_peek (&plug->cached_rq); -if (!rq || rq->q != q) -return NULL ; +WARN_ON_ONCE (rq_list_peek (&plug->cached_rq) != rq); -if (blk_mq_attempt_bio_merge (q, *bio, nsegs)) { - *bio =NULL ; -return NULL ; - } - - type =blk_mq_get_hctx_type ((*bio)->bi_opf); - hctx_type = rq->mq_hctx->type;if (type != hctx_type && !(type ==HCTX_TYPE_READ && hctx_type ==HCTX_TYPE_DEFAULT )) -return NULL ; -if (op_is_flush (rq->cmd_flags) !=op_is_flush ((*bio)->bi_opf)) -return NULL ; +return false; +if (op_is_flush (rq->cmd_flags) !=op_is_flush (bio->bi_opf)) +return false;/* * If any qos ->throttle() end up blocking, we will have flushed the
@@ -2930,12 +2915,12 @@ static inline struct request *blk_mq_get_cached_request(struct request_queue *q,* before we throttle. */ plug->cached_rq =rq_list_next (rq); -rq_qos_throttle (q, *bio); +rq_qos_throttle (rq->q, bio);blk_mq_rq_time_init (rq,0 ); - rq->cmd_flags = (*bio)->bi_opf; + rq->cmd_flags = bio->bi_opf;INIT_LIST_HEAD (&rq->queuelist); -return rq; +return true; }static void bio_set_ioprio (struct bio *bio)
@@ -2965,7 +2950,7 @@ void blk_mq_submit_bio(struct bio *bio)struct blk_plug *plug =blk_mq_plug (bio);const int is_sync =op_is_sync (bio->bi_opf);struct blk_mq_hw_ctx *hctx; -struct request *rq; +struct request *rq =NULL ;unsigned int nr_segs =1 ;blk_status_t ret;
@@ -2976,20 +2961,36 @@ void blk_mq_submit_bio(struct bio *bio)return ; } -if (!bio_integrity_prep (bio)) -return ; -bio_set_ioprio (bio); - rq =blk_mq_get_cached_request (q, plug, &bio, nr_segs); -if (!rq) { -if (!bio) +if (plug) { + rq =rq_list_peek (&plug->cached_rq); +if (rq && rq->q != q) + rq =NULL ; + } +if (rq) { +if (!bio_integrity_prep (bio))return ; - rq =blk_mq_get_new_requests (q, plug, bio, nr_segs); -if (unlikely (!rq)) +if (blk_mq_attempt_bio_merge (q, bio, nr_segs))return ; +if (blk_mq_can_use_cached_rq (rq, plug, bio)) + goto done; +percpu_ref_get (&q->q_usage_counter); + }else { +if (unlikely (bio_queue_enter (bio))) +return ; +if (!bio_integrity_prep (bio)) + goto fail; + } + + rq =blk_mq_get_new_requests (q, plug, bio, nr_segs); +if (unlikely (!rq)) { +fail: +blk_queue_exit (q); +return ; } +done:trace_block_getrq (bio);rq_qos_track (q, rq, bio);
Signature · 1 line
2.42.0
Greg Kroah-Hartman
maintainerPATCH 189/491 ptp: annotate data-race around q->head and q->tail
In reply to Greg Kroah-Hartman6.5-stable review patch. If anyone has any objections, please let me know.
------------------
From: Eric Dumazet <[email protected]>
[ Upstream commit 73bde5a3294853947252cd9092a3517c7cb0cd2d ]
As I was working on a syzbot report, I found that KCSAN would probably complain that reading q->head or q->tail without barriers could lead to invalid results.
Add corresponding READ_ONCE() and WRITE_ONCE() to avoid load-store tearing.
--- drivers/ptp/ptp_chardev.c | 3 ++- drivers/ptp/ptp_clock.c | 5 +++-- drivers/ptp/ptp_private.h | 8 ++++++-- drivers/ptp/ptp_sysfs.c | 3 ++- 4 files changed, 13 insertions(+), 6 deletions(-)
drivers/ptp/ptp_chardev.c +2 -1
@@ -490,7 +490,8 @@ ssize_t ptp_read(struct posix_clock *pc,for (i =0 ; i < cnt; i++) { event[i] = queue->buf[queue->head]; - queue->head = (queue->head +1 ) %PTP_MAX_TIMESTAMPS ; +/* Paired with READ_ONCE() in queue_cnt() */ +WRITE_ONCE (queue->head, (queue->head +1 ) %PTP_MAX_TIMESTAMPS ); }spin_unlock_irqrestore (&queue->lock, flags);
drivers/ptp/ptp_clock.c +3 -2
@@ -56,10 +56,11 @@ static void enqueue_external_timestamp(struct timestamp_event_queue *queue, dst->t.sec = seconds; dst->t.nsec = remainder; +/* Both WRITE_ONCE() are paired with READ_ONCE() in queue_cnt() */ if (!queue_free (queue)) - queue->head = (queue->head +1 ) %PTP_MAX_TIMESTAMPS ; +WRITE_ONCE (queue->head, (queue->head +1 ) %PTP_MAX_TIMESTAMPS ); - queue->tail = (queue->tail +1 ) %PTP_MAX_TIMESTAMPS ; +WRITE_ONCE (queue->tail, (queue->tail +1 ) %PTP_MAX_TIMESTAMPS );spin_unlock_irqrestore (&queue->lock, flags); }
drivers/ptp/ptp_private.h +6 -2
@@ -76,9 +76,13 @@ struct ptp_vclock {* that a writer might concurrently increment the tail does not * matter, since the queue remains nonempty nonetheless. */ -static inline int queue_cnt (struct timestamp_event_queue *q) +static inline int queue_cnt (const struct timestamp_event_queue *q) { -int cnt = q->tail - q->head; +/* +* Paired with WRITE_ONCE() in enqueue_external_timestamp(), +* ptp_read(), extts_fifo_show(). +*/ +int cnt =READ_ONCE (q->tail) -READ_ONCE (q->head);return cnt <0 ?PTP_MAX_TIMESTAMPS + cnt : cnt; }
drivers/ptp/ptp_sysfs.c +2 -1
@@ -90,7 +90,8 @@ static ssize_t extts_fifo_show(struct device *dev, qcnt =queue_cnt (queue);if (qcnt) { event = queue->buf[queue->head]; - queue->head = (queue->head +1 ) %PTP_MAX_TIMESTAMPS ; +/* Paired with READ_ONCE() in queue_cnt() */ +WRITE_ONCE (queue->head, (queue->head +1 ) %PTP_MAX_TIMESTAMPS ); }spin_unlock_irqrestore (&queue->lock, flags);
Signature · 1 line
2.42.0
Greg Kroah-Hartman
maintainerPATCH 190/491 bonding: stop the device in bond_setup_by_slave()
In reply to Greg Kroah-Hartman6.5-stable review patch. If anyone has any objections, please let me know.
------------------
From: Eric Dumazet <[email protected]>
[ Upstream commit 3cffa2ddc4d3fcf70cde361236f5a614f81a09b2 ]
Commit 9eed321cde22 ("net: lapbether: only support ethernet devices") has been able to keep syzbot away from net/lapb, until today.
In the following splat [1], the issue is that a lapbether device has been created on a bonding device without members. Then adding a non ARPHRD_ETHER member forced the bonding master to change its type.
The fix is to make sure we call dev_close() in bond_setup_by_slave() so that the potential linked lapbether devices (or any other devices having assumptions on the physical device) are removed.
A similar bug has been addressed in commit 40baec225765 ("bonding: fix panic on non-ARPHRD_ETHER enslave failure")
[1]
skbuff: skb_under_panic: text:ffff800089508810 len:44 put:40 head:ffff0000c78e7c00 data:ffff0000c78e7bea tail:0x16 end:0x140 dev:bond0 kernel BUG at net/core/skbuff.c:192 !
Internal error: Oops - BUG: 00000000f2000800 [#1] PREEMPT SMP Modules linked in: CPU: 0 PID: 6007 Comm: syz-executor383 Not tainted 6.6.0-rc3-syzkaller-gbf6547d8715b #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/04/2023 pstate: 60400005 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : skb_panic net/core/skbuff.c:188 [inline] pc : skb_under_panic+0x13c/0x140 net/core/skbuff.c:202 lr : skb_panic net/core/skbuff.c:188 [inline] lr : skb_under_panic+0x13c/0x140 net/core/skbuff.c:202
sp : ffff800096a06aa0
x29: ffff800096a06ab0 x28: ffff800096a06ba0 x27: dfff800000000000
x26: ffff0000ce9b9b50 x25: 0000000000000016 x24: ffff0000c78e7bea
x23: ffff0000c78e7c00 x22: 000000000000002c x21: 0000000000000140
x20: 0000000000000028 x19: ffff800089508810 x18: ffff800096a06100
x17: 0000000000000000 x16: ffff80008a629a3c x15: 0000000000000001
x14: 1fffe00036837a32 x13: 0000000000000000 x12: 0000000000000000
x11: 0000000000000201 x10: 0000000000000000 x9 : cb50b496c519aa00 x8 : cb50b496c519aa00 x7 : 0000000000000001 x6 : 0000000000000001 x5 : ffff800096a063b8 x4 : ffff80008e280f80 x3 : ffff8000805ad11c x2 : 0000000000000001 x1 : 0000000100000201 x0 : 0000000000000086
Call trace: skb_panic net/core/skbuff.c:188 [inline] skb_under_panic+0x13c/0x140 net/core/skbuff.c:202 skb_push+0xf0/0x108 net/core/skbuff.c:2446 ip6gre_header+0xbc/0x738 net/ipv6/ip6_gre.c:1384 dev_hard_header include/linux/netdevice.h:3136 [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_disconnect_request+0x9c/0x17c net/lapb/lapb_iface.c:326 lapb_device_event+0x288/0x4e0 net/lapb/lapb_iface.c:492 notifier_call_chain+0x1a4/0x510 kernel/notifier.c:93 raw_notifier_call_chain+0x3c/0x50 kernel/notifier.c:461 call_netdevice_notifiers_info net/core/dev.c:1970 [inline] call_netdevice_notifiers_extack net/core/dev.c:2008 [inline] call_netdevice_notifiers net/core/dev.c:2022 [inline] __dev_close_many+0x1b8/0x3c4 net/core/dev.c:1508 dev_close_many+0x1e0/0x470 net/core/dev.c:1559 dev_close+0x174/0x250 net/core/dev.c:1585 lapbeth_device_event+0x2e4/0x958 drivers/net/wan/lapbether.c:466 notifier_call_chain+0x1a4/0x510 kernel/notifier.c:93 raw_notifier_call_chain+0x3c/0x50 kernel/notifier.c:461 call_netdevice_notifiers_info net/core/dev.c:1970 [inline] call_netdevice_notifiers_extack net/core/dev.c:2008 [inline] call_netdevice_notifiers net/core/dev.c:2022 [inline] __dev_close_many+0x1b8/0x3c4 net/core/dev.c:1508 dev_close_many+0x1e0/0x470 net/core/dev.c:1559 dev_close+0x174/0x250 net/core/dev.c:1585 bond_enslave+0x2298/0x30cc drivers/net/bonding/bond_main.c:2332 bond_do_ioctl+0x268/0xc64 drivers/net/bonding/bond_main.c:4539 dev_ifsioc+0x754/0x9ac dev_ioctl+0x4d8/0xd34 net/core/dev_ioctl.c:786 sock_do_ioctl+0x1d4/0x2d0 net/socket.c:1217 sock_ioctl+0x4e8/0x834 net/socket.c:1322 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:871 [inline] __se_sys_ioctl fs/ioctl.c:857 [inline] __arm64_sys_ioctl+0x14c/0x1c8 fs/ioctl.c:857 __invoke_syscall arch/arm64/kernel/syscall.c:37 [inline] invoke_syscall+0x98/0x2b8 arch/arm64/kernel/syscall.c:51 el0_svc_common+0x130/0x23c arch/arm64/kernel/syscall.c:136 do_el0_svc+0x48/0x58 arch/arm64/kernel/syscall.c:155 el0_svc+0x58/0x16c arch/arm64/kernel/entry-common.c:678 el0t_64_sync_handler+0x84/0xfc arch/arm64/kernel/entry-common.c:696 el0t_64_sync+0x190/0x194 arch/arm64/kernel/entry.S:591 Code: aa1803e6 aa1903e7 a90023f5 94785b8b (d4210000)
--- drivers/net/bonding/bond_main.c | 6 ++++++ 1 file changed, 6 insertions(+)
drivers/net/bonding/bond_main.c +6 -0
@@ -1499,6 +1499,10 @@ static void bond_compute_features(struct bonding *bond)static void bond_setup_by_slave (struct net_device *bond_dev,struct net_device *slave_dev) { +bool was_up = !!(bond_dev->flags &IFF_UP ); + +dev_close (bond_dev); + bond_dev->header_ops = slave_dev->header_ops; bond_dev->type = slave_dev->type;
@@ -1513,6 +1517,8 @@ static void bond_setup_by_slave(struct net_device *bond_dev, bond_dev->flags &= ~(IFF_BROADCAST |IFF_MULTICAST ); bond_dev->flags |= (IFF_POINTOPOINT |IFF_NOARP ); } +if (was_up) +dev_open (bond_dev,NULL ); }/* On bonding slaves other than the currently active slave, suppress
Signature · 1 line
2.42.0
Greg Kroah-Hartman
maintainerPATCH 191/491 net: ethernet: cortina: Fix max RX frame define
In reply to Greg Kroah-Hartman6.5-stable review patch. If anyone has any objections, please let me know.
------------------
From: Linus Walleij <[email protected]>
[ Upstream commit 510e35fb931ffc3b100e5d5ae4595cd3beca9f1a ]
Enumerator 3 is 1548 bytes according to the datasheet. Not 1542.
--- drivers/net/ethernet/cortina/gemini.c | 4 ++-- drivers/net/ethernet/cortina/gemini.h | 2 +- 2 files changed, 3 insertions(+), 3 deletions(-)
drivers/net/ethernet/cortina/gemini.c +2 -2
@@ -432,8 +432,8 @@ static const struct gmac_max_framelen gmac_maxlens[] = { .val = CONFIG0_MAXLEN_1536, }, { - .max_l3_len = 1542, - .val = CONFIG0_MAXLEN_1542, + .max_l3_len = 1548, + .val = CONFIG0_MAXLEN_1548, }, { .max_l3_len = 9212,
drivers/net/ethernet/cortina/gemini.h +1 -1
@@ -787,7 +787,7 @@ union gmac_config0 {#define CONFIG0_MAXLEN_1536 0#define CONFIG0_MAXLEN_1518 1#define CONFIG0_MAXLEN_1522 2 -#define CONFIG0_MAXLEN_1542 3 +#define CONFIG0_MAXLEN_1548 3#define CONFIG0_MAXLEN_9k 4/* 9212 */ #define CONFIG0_MAXLEN_10k 5/* 10236 */ #define CONFIG0_MAXLEN_1518__6 6
Signature · 1 line
2.42.0
Greg Kroah-Hartman
maintainerPATCH 192/491 net: ethernet: cortina: Handle large frames
In reply to Greg Kroah-Hartman6.5-stable review patch. If anyone has any objections, please let me know.
------------------
From: Linus Walleij <[email protected]>
[ Upstream commit d4d0c5b4d279bfe3585fbd806efefd3e51c82afa ]
The Gemini ethernet controller provides hardware checksumming for frames up to 1514 bytes including ethernet headers but not FCS.
If we start sending bigger frames (after first bumping up the MTU on both interfaces sending and receiving the frames), truncated packets start to appear on the target such as in this tcpdump resulting from ping -s 1474:
23:34:17.241983 14:d6:4d:a8:3c:4f (oui Unknown) > bc:ae:c5:6b:a8:3d (oui Unknown), ethertype IPv4 (0x0800), length 1514: truncated-ip - 2 bytes missing! (tos 0x0, ttl 64, id 32653, offset 0, flags [DF], proto ICMP (1), length 1502) OpenWrt.lan > Fecusia: ICMP echo request, id 1672, seq 50, length 1482
If we bypass the hardware checksumming and provide a software fallback, everything starts working fine up to the max TX MTU of 2047 bytes, for example ping -s2000 192.168.1.2:
00:44:29.587598 bc:ae:c5:6b:a8:3d (oui Unknown) > 14:d6:4d:a8:3c:4f (oui Unknown), ethertype IPv4 (0x0800), length 2042:
(tos 0x0, ttl 64, id 51828, offset 0, flags [none], proto ICMP (1), length 2028) Fecusia > OpenWrt.lan: ICMP echo reply, id 1683, seq 4, length 2008
The bit enabling to bypass hardware checksum (or any of the "TSS" bits) are undocumented in the hardware reference manual. The entire hardware checksum unit appears undocumented. The conclusion that we need to use the "bypass" bit was found by trial-and-error.
Since no hardware checksum will happen, we slot in a software checksum fallback.
Check for the condition where we need to compute checksum on the skb with either hardware or software using == CHECKSUM_PARTIAL instead of != CHECKSUM_NONE which is an incomplete check according to <linux/skbuff.h>.
On the D-Link DIR-685 router this fixes a bug on the conduit interface to the RTL8366RB DSA switch: as the switch needs to add space for its tag it increases the MTU on the conduit interface to 1504 and that means that when the router sends packages of 1500 bytes these get an extra 4 bytes of DSA tag and the transfer fails because of the erroneous hardware checksumming, affecting such basic functionality as the LuCI web interface.
--- drivers/net/ethernet/cortina/gemini.c | 24 +++++++++++++++++++++++- 1 file changed, 23 insertions(+), 1 deletion(-)
drivers/net/ethernet/cortina/gemini.c +23 -1
@@ -1145,6 +1145,7 @@ static int gmac_map_tx_bufs(struct net_device *netdev, struct sk_buff *skb,dma_addr_t mapping;unsigned short mtu;void *buffer; +int ret; mtu =ETH_HLEN ; mtu += netdev->mtu;
@@ -1159,9 +1160,30 @@ static int gmac_map_tx_bufs(struct net_device *netdev, struct sk_buff *skb, word3 |= mtu; } -if (skb->ip_summed !=CHECKSUM_NONE ) { +if (skb->len >=ETH_FRAME_LEN ) { +/* Hardware offloaded checksumming isn't working on frames +* bigger than 1514 bytes. A hypothesis about this is that the +* checksum buffer is only 1518 bytes, so when the frames get +* bigger they get truncated, or the last few bytes get +* overwritten by the FCS. +* +* Just use software checksumming and bypass on bigger frames. +*/ +if (skb->ip_summed ==CHECKSUM_PARTIAL ) { + ret =skb_checksum_help (skb); +if (ret) +return ret; + } + word1 |=TSS_BYPASS_BIT ; + }else if (skb->ip_summed ==CHECKSUM_PARTIAL ) {int tcp =0 ; +/* We do not switch off the checksumming on non TCP/UDP +* frames: as is shown from tests, the checksumming engine +* is smart enough to see that a frame is not actually TCP +* or UDP and then just pass it through without any changes +* to the frame. +*/ if (skb->protocol ==htons (ETH_P_IP )) { word1 |=TSS_IP_CHKSUM_BIT ; tcp =ip_hdr (skb)->protocol ==IPPROTO_TCP ;
Signature · 1 line
2.42.0
Greg Kroah-Hartman
maintainerPATCH 193/491 net: ethernet: cortina: Fix MTU max setting
In reply to Greg Kroah-Hartman6.5-stable review patch. If anyone has any objections, please let me know.
------------------
From: Linus Walleij <[email protected]>
[ Upstream commit dc6c0bfbaa947dd7976e30e8c29b10c868b6fa42 ]
The RX max frame size is over 10000 for the Gemini ethernet, but the TX max frame size is actually just 2047 (0x7ff after checking the datasheet). Reflect this in what we offer to Linux, cap the MTU at the TX max frame minus ethernet headers.
We delete the code disabling the hardware checksum for large MTUs as netdev->mtu can no longer be larger than netdev->max_mtu meaning the if()-clause in gmac_fix_features() is never true.
--- drivers/net/ethernet/cortina/gemini.c | 17 ++++------------- drivers/net/ethernet/cortina/gemini.h | 2 +- 2 files changed, 5 insertions(+), 14 deletions(-)
drivers/net/ethernet/cortina/gemini.c +4 -13
@@ -2000,15 +2000,6 @@ static int gmac_change_mtu(struct net_device *netdev, int new_mtu)return 0 ; } -static netdev_features_t gmac_fix_features (struct net_device *netdev, -netdev_features_t features) -{ -if (netdev->mtu +ETH_HLEN +VLAN_HLEN >MTU_SIZE_BIT_MASK ) - features &= ~GMAC_OFFLOAD_FEATURES ; - -return features; -} -static int gmac_set_features (struct net_device *netdev,netdev_features_t features) {
@@ -2234,7 +2225,6 @@ static const struct net_device_ops gmac_351x_ops = { .ndo_set_mac_address = gmac_set_mac_address, .ndo_get_stats64 = gmac_get_stats64, .ndo_change_mtu = gmac_change_mtu, - .ndo_fix_features = gmac_fix_features, .ndo_set_features = gmac_set_features, };
@@ -2486,11 +2476,12 @@ static int gemini_ethernet_port_probe(struct platform_device *pdev) netdev->hw_features =GMAC_OFFLOAD_FEATURES ; netdev->features |=GMAC_OFFLOAD_FEATURES |NETIF_F_GRO ; -/* We can handle jumbo frames up to 10236 bytes so, let's accept -* payloads of 10236 bytes minus VLAN and ethernet header +/* We can receive jumbo frames up to 10236 bytes but only +* transmit 2047 bytes so, let's accept payloads of 2047 +* bytes minus VLAN and ethernet header */ netdev->min_mtu =ETH_MIN_MTU ; - netdev->max_mtu =10236 -VLAN_ETH_HLEN ; + netdev->max_mtu =MTU_SIZE_BIT_MASK -VLAN_ETH_HLEN ; port->freeq_refill =0 ;netif_napi_add (netdev, &port->napi, gmac_napi_poll);
drivers/net/ethernet/cortina/gemini.h +1 -1
@@ -502,7 +502,7 @@ union gmac_txdesc_3 {#define SOF_BIT 0x80000000#define EOF_BIT 0x40000000#define EOFIE_BIT BIT(29) -#define MTU_SIZE_BIT_MASK 0x1fff +#define MTU_SIZE_BIT_MASK 0x7ff/* Max MTU 2047 bytes */ /* GMAC Tx Descriptor */ struct gmac_txdesc {
Signature · 1 line
2.42.0
Greg Kroah-Hartman
maintainerPATCH 194/491 af_unix: fix use-after-free in unix_stream_read_actor()
In reply to Greg Kroah-Hartman6.5-stable review patch. If anyone has any objections, please let me know.
------------------
From: Eric Dumazet <[email protected]>
[ Upstream commit 4b7b492615cf3017190f55444f7016812b66611d ]
syzbot reported the following crash [1]
After releasing unix socket lock, u->oob_skb can be changed by another thread. We must temporarily increase skb refcount to make sure this other thread will not free the skb under us.
[1]
BUG: KASAN: slab-use-after-free in unix_stream_read_actor+0xa7/0xc0 net/unix/af_unix.c:2866 Read of size 4 at addr ffff88801f3b9cc4 by task syz-executor107/5297 CPU: 1 PID: 5297 Comm: syz-executor107 Not tainted 6.6.0-syzkaller-15910-gb8e3a87a627b #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/09/2023 Call Trace: <TASK> __dump_stack lib/dump_stack.c:88 [inline] dump_stack_lvl+0xd9/0x1b0 lib/dump_stack.c:106 print_address_description mm/kasan/report.c:364 [inline] print_report+0xc4/0x620 mm/kasan/report.c:475 kasan_report+0xda/0x110 mm/kasan/report.c:588 unix_stream_read_actor+0xa7/0xc0 net/unix/af_unix.c:2866 unix_stream_recv_urg net/unix/af_unix.c:2587 [inline] unix_stream_read_generic+0x19a5/0x2480 net/unix/af_unix.c:2666 unix_stream_recvmsg+0x189/0x1b0 net/unix/af_unix.c:2903 sock_recvmsg_nosec net/socket.c:1044 [inline] sock_recvmsg+0xe2/0x170 net/socket.c:1066 ____sys_recvmsg+0x21f/0x5c0 net/socket.c:2803 ___sys_recvmsg+0x115/0x1a0 net/socket.c:2845 __sys_recvmsg+0x114/0x1e0 net/socket.c:2875 do_syscall_x64 arch/x86/entry/common.c:51 [inline] do_syscall_64+0x3f/0x110 arch/x86/entry/common.c:82 entry_SYSCALL_64_after_hwframe+0x63/0x6b RIP: 0033:0x7fc67492c559 Code: 28 00 00 00 75 05 48 83 c4 28 c3 e8 51 18 00 00 90 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b0 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007fc6748ab228 EFLAGS: 00000246 ORIG_RAX: 000000000000002f RAX: ffffffffffffffda RBX: 000000000000001c RCX: 00007fc67492c559 RDX: 0000000040010083 RSI: 0000000020000140 RDI: 0000000000000004 RBP: 00007fc6749b6348 R08: 00007fc6748ab6c0 R09: 00007fc6748ab6c0 R10: 0000000000000000 R11: 0000000000000246 R12: 00007fc6749b6340 R13: 00007fc6749b634c R14: 00007ffe9fac52a0 R15: 00007ffe9fac5388 </TASK> Allocated by task 5295: kasan_save_stack+0x33/0x50 mm/kasan/common.c:45 kasan_set_track+0x25/0x30 mm/kasan/common.c:52 __kasan_slab_alloc+0x81/0x90 mm/kasan/common.c:328 kasan_slab_alloc include/linux/kasan.h:188 [inline] slab_post_alloc_hook mm/slab.h:763 [inline] slab_alloc_node mm/slub.c:3478 [inline] kmem_cache_alloc_node+0x180/0x3c0 mm/slub.c:3523 __alloc_skb+0x287/0x330 net/core/skbuff.c:641 alloc_skb include/linux/skbuff.h:1286 [inline] alloc_skb_with_frags+0xe4/0x710 net/core/skbuff.c:6331 sock_alloc_send_pskb+0x7e4/0x970 net/core/sock.c:2780 sock_alloc_send_skb include/net/sock.h:1884 [inline] queue_oob net/unix/af_unix.c:2147 [inline] unix_stream_sendmsg+0xb5f/0x10a0 net/unix/af_unix.c:2301 sock_sendmsg_nosec net/socket.c:730 [inline] __sock_sendmsg+0xd5/0x180 net/socket.c:745 ____sys_sendmsg+0x6ac/0x940 net/socket.c:2584 ___sys_sendmsg+0x135/0x1d0 net/socket.c:2638 __sys_sendmsg+0x117/0x1e0 net/socket.c:2667 do_syscall_x64 arch/x86/entry/common.c:51 [inline] do_syscall_64+0x3f/0x110 arch/x86/entry/common.c:82 entry_SYSCALL_64_after_hwframe+0x63/0x6b Freed by task 5295: kasan_save_stack+0x33/0x50 mm/kasan/common.c:45 kasan_set_track+0x25/0x30 mm/kasan/common.c:52 kasan_save_free_info+0x2b/0x40 mm/kasan/generic.c:522 ____kasan_slab_free mm/kasan/common.c:236 [inline] ____kasan_slab_free+0x15b/0x1b0 mm/kasan/common.c:200 kasan_slab_free include/linux/kasan.h:164 [inline] slab_free_hook mm/slub.c:1800 [inline] slab_free_freelist_hook+0x114/0x1e0 mm/slub.c:1826 slab_free mm/slub.c:3809 [inline] kmem_cache_free+0xf8/0x340 mm/slub.c:3831 kfree_skbmem+0xef/0x1b0 net/core/skbuff.c:1015 __kfree_skb net/core/skbuff.c:1073 [inline] consume_skb net/core/skbuff.c:1288 [inline] consume_skb+0xdf/0x170 net/core/skbuff.c:1282 queue_oob net/unix/af_unix.c:2178 [inline] unix_stream_sendmsg+0xd49/0x10a0 net/unix/af_unix.c:2301 sock_sendmsg_nosec net/socket.c:730 [inline] __sock_sendmsg+0xd5/0x180 net/socket.c:745 ____sys_sendmsg+0x6ac/0x940 net/socket.c:2584 ___sys_sendmsg+0x135/0x1d0 net/socket.c:2638 __sys_sendmsg+0x117/0x1e0 net/socket.c:2667 do_syscall_x64 arch/x86/entry/common.c:51 [inline] do_syscall_64+0x3f/0x110 arch/x86/entry/common.c:82 entry_SYSCALL_64_after_hwframe+0x63/0x6b The buggy address belongs to the object at ffff88801f3b9c80
which belongs to the cache skbuff_head_cache of size 240 The buggy address is located 68 bytes inside of freed 240-byte region [ffff88801f3b9c80, ffff88801f3b9d70)
The buggy address belongs to the physical page: page:ffffea00007cee40 refcount:1 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x1f3b9 flags: 0xfff00000000800(slab|node=0|zone=1|lastcpupid=0x7ff) page_type: 0xffffffff() raw: 00fff00000000800 ffff888142a60640 dead000000000122 0000000000000000 raw: 0000000000000000 00000000000c000c 00000001ffffffff 0000000000000000 page dumped because: kasan: bad access detected page_owner tracks the page as allocated page last allocated via order 0, migratetype Unmovable, gfp_mask 0x12cc0(GFP_KERNEL|__GFP_NOWARN|__GFP_NORETRY), pid 5299, tgid 5283 (syz-executor107), ts 103803840339, free_ts 103600093431 set_page_owner include/linux/page_owner.h:31 [inline] post_alloc_hook+0x2cf/0x340 mm/page_alloc.c:1537 prep_new_page mm/page_alloc.c:1544 [inline] get_page_from_freelist+0xa25/0x36c0 mm/page_alloc.c:3312 __alloc_pages+0x1d0/0x4a0 mm/page_alloc.c:4568 alloc_pages_mpol+0x258/0x5f0 mm/mempolicy.c:2133 alloc_slab_page mm/slub.c:1870 [inline] allocate_slab+0x251/0x380 mm/slub.c:2017 new_slab mm/slub.c:2070 [inline] ___slab_alloc+0x8c7/0x1580 mm/slub.c:3223 __slab_alloc.constprop.0+0x56/0xa0 mm/slub.c:3322 __slab_alloc_node mm/slub.c:3375 [inline] slab_alloc_node mm/slub.c:3468 [inline] kmem_cache_alloc_node+0x132/0x3c0 mm/slub.c:3523 __alloc_skb+0x287/0x330 net/core/skbuff.c:641 alloc_skb include/linux/skbuff.h:1286 [inline] alloc_skb_with_frags+0xe4/0x710 net/core/skbuff.c:6331 sock_alloc_send_pskb+0x7e4/0x970 net/core/sock.c:2780 sock_alloc_send_skb include/net/sock.h:1884 [inline] queue_oob net/unix/af_unix.c:2147 [inline] unix_stream_sendmsg+0xb5f/0x10a0 net/unix/af_unix.c:2301 sock_sendmsg_nosec net/socket.c:730 [inline] __sock_sendmsg+0xd5/0x180 net/socket.c:745 ____sys_sendmsg+0x6ac/0x940 net/socket.c:2584 ___sys_sendmsg+0x135/0x1d0 net/socket.c:2638 __sys_sendmsg+0x117/0x1e0 net/socket.c:2667 page last free stack trace: reset_page_owner include/linux/page_owner.h:24 [inline] free_pages_prepare mm/page_alloc.c:1137 [inline] free_unref_page_prepare+0x4f8/0xa90 mm/page_alloc.c:2347 free_unref_page+0x33/0x3b0 mm/page_alloc.c:2487 __unfreeze_partials+0x21d/0x240 mm/slub.c:2655 qlink_free mm/kasan/quarantine.c:168 [inline] qlist_free_all+0x6a/0x170 mm/kasan/quarantine.c:187 kasan_quarantine_reduce+0x18e/0x1d0 mm/kasan/quarantine.c:294 __kasan_slab_alloc+0x65/0x90 mm/kasan/common.c:305 kasan_slab_alloc include/linux/kasan.h:188 [inline] slab_post_alloc_hook mm/slab.h:763 [inline] slab_alloc_node mm/slub.c:3478 [inline] slab_alloc mm/slub.c:3486 [inline] __kmem_cache_alloc_lru mm/slub.c:3493 [inline] kmem_cache_alloc+0x15d/0x380 mm/slub.c:3502 vm_area_dup+0x21/0x2f0 kernel/fork.c:500 __split_vma+0x17d/0x1070 mm/mmap.c:2365 split_vma mm/mmap.c:2437 [inline] vma_modify+0x25d/0x450 mm/mmap.c:2472 vma_modify_flags include/linux/mm.h:3271 [inline] mprotect_fixup+0x228/0xc80 mm/mprotect.c:635 do_mprotect_pkey+0x852/0xd60 mm/mprotect.c:809 __do_sys_mprotect mm/mprotect.c:830 [inline] __se_sys_mprotect mm/mprotect.c:827 [inline] __x64_sys_mprotect+0x78/0xb0 mm/mprotect.c:827 do_syscall_x64 arch/x86/entry/common.c:51 [inline] do_syscall_64+0x3f/0x110 arch/x86/entry/common.c:82 entry_SYSCALL_64_after_hwframe+0x63/0x6b Memory state around the buggy address: ffff88801f3b9b80: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ffff88801f3b9c00: fb fb fb fb fb fb fc fc fc fc fc fc fc fc fc fc >ffff88801f3b9c80: fa fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
^ffff88801f3b9d00: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fc fcffff88801f3b9d80: fc fc fc fc fc fc fc fc fa fb fb fb fb fb fb fb
--- net/unix/af_unix.c | 9 +++++---- 1 file changed, 5 insertions(+), 4 deletions(-)
net/unix/af_unix.c +5 -4
@@ -2553,15 +2553,16 @@ static int unix_stream_recv_urg(struct unix_stream_read_state *state)if (!(state->flags &MSG_PEEK ))WRITE_ONCE (u->oob_skb,NULL ); - +else +skb_get (oob_skb);unix_state_unlock (sk); chunk = state->recv_actor (oob_skb,0 , chunk, state); -if (!(state->flags &MSG_PEEK )) { +if (!(state->flags &MSG_PEEK ))UNIXCB (oob_skb).consumed +=1 ; -kfree_skb (oob_skb); - } + +consume_skb (oob_skb);mutex_unlock (&u->iolock);
Signature · 1 line
2.42.0
Greg Kroah-Hartman
maintainerPATCH 195/491 netfilter: nf_conntrack_bridge: initialize err to 0
In reply to Greg Kroah-Hartman6.5-stable review patch. If anyone has any objections, please let me know.
------------------
From: Linkui Xiao <[email protected]>
[ Upstream commit a44af08e3d4d7566eeea98d7a29fe06e7b9de944 ]
K2CI reported a problem:
consume_skb(skb); return err;
[nf_br_ip_fragment() error] uninitialized symbol 'err'.
err is not initialized, because returning 0 is expected, initialize err to 0.
--- net/bridge/netfilter/nf_conntrack_bridge.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
net/bridge/netfilter/nf_conntrack_bridge.c +1 -1
@@ -37,7 +37,7 @@ static int nf_br_ip_fragment(struct net *net, struct sock *sk,ktime_t tstamp = skb->tstamp;struct ip_frag_state state;struct iphdr *iph; -int err; +int err =0 ;/* for offloaded checksums cleanup checksum before fragmentation */ if (skb->ip_summed == CHECKSUM_PARTIAL &&
Signature · 1 line
2.42.0
Greg Kroah-Hartman
maintainerPATCH 196/491 netfilter: nf_tables: fix pointer math issue in nft_byteorder_eval()
In reply to Greg Kroah-Hartman6.5-stable review patch. If anyone has any objections, please let me know.
------------------
From: Dan Carpenter <[email protected]>
[ Upstream commit c301f0981fdd3fd1ffac6836b423c4d7a8e0eb63 ]
The problem is in nft_byteorder_eval() where we are iterating through a loop and writing to dst[0], dst[1], dst[2] and so on... On each iteration we are writing 8 bytes. But dst[] is an array of u32 so each element only has space for 4 bytes. That means that every iteration overwrites part of the previous element.
I spotted this bug while reviewing commit caf3ef7468f7 ("netfilter:nf_tables: prevent OOB access in nft_byteorder_eval") which is a related issue. I think that the reason we have not detected this bug in testing is that most of time we only write one element.
--- include/net/netfilter/nf_tables.h | 4 ++-- net/netfilter/nft_byteorder.c | 5 +++-- net/netfilter/nft_meta.c | 2 +- 3 files changed, 6 insertions(+), 5 deletions(-)
include/net/netfilter/nf_tables.h +2 -2
@@ -178,9 +178,9 @@ static inline __be32 nft_reg_load_be32(const u32 *sreg)return *(__force __be32 *)sreg; } -static inline void nft_reg_store64 (u32 *dreg,u64 val) +static inline void nft_reg_store64 (u64 *dreg,u64 val) { -put_unaligned (val, (u64 *)dreg); +put_unaligned (val, dreg); }static inline u64 nft_reg_load64 (const u32 *sreg)
net/netfilter/nft_byteorder.c +3 -2
@@ -38,13 +38,14 @@ void nft_byteorder_eval(const struct nft_expr *expr,switch (priv->size) {case 8 : { +u64 *dst64 = (void *)dst;u64 src64;switch (priv->op) {case NFT_BYTEORDER_NTOH :for (i =0 ; i < priv->len /8 ; i++) { src64 =nft_reg_load64 (&src[i]); -nft_reg_store64 (&dst[i], +nft_reg_store64 (&dst64[i],be64_to_cpu ((__force __be64 )src64)); }break ;
@@ -52,7 +53,7 @@ void nft_byteorder_eval(const struct nft_expr *expr,for (i =0 ; i < priv->len /8 ; i++) { src64 = (__force __u64 )cpu_to_be64 (nft_reg_load64 (&src[i])); -nft_reg_store64 (&dst[i], src64); +nft_reg_store64 (&dst64[i], src64); }break ; }
net/netfilter/nft_meta.c +1 -1
@@ -63,7 +63,7 @@ nft_meta_get_eval_time(enum nft_meta_keys key, {switch (key) {case NFT_META_TIME_NS : -nft_reg_store64 (dest,ktime_get_real_ns ()); +nft_reg_store64 ((u64 *)dest,ktime_get_real_ns ());break ;case NFT_META_TIME_DAY :nft_reg_store8 (dest,nft_meta_weekday ());
Signature · 1 line
2.42.0
Greg Kroah-Hartman
maintainerPATCH 197/491 netfilter: nf_tables: bogus ENOENT when destroying element which does not exist
In reply to Greg Kroah-Hartman6.5-stable review patch. If anyone has any objections, please let me know.
------------------
From: Pablo Neira Ayuso <[email protected]>
[ Upstream commit a7d5a955bfa854ac6b0c53aaf933394b4e6139e4 ]
destroy element command bogusly reports ENOENT in case a set element does not exist. ENOENT errors are skipped, however, err is still set and propagated to userspace.
# nft destroy element ip raw BLACKLIST { 1.2.3.4 }
Error: Could not process rule: No such file or directory
destroy element ip raw BLACKLIST { 1.2.3.4 }
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^--- net/netfilter/nf_tables_api.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-)
net/netfilter/nf_tables_api.c +3 -2
@@ -7202,10 +7202,11 @@ static int nf_tables_delsetelem(struct sk_buff *skb,if (err <0 ) {NL_SET_BAD_ATTR (extack, attr); -break ; +return err; } } -return err; + +return 0 ; }/*
Signature · 1 line
2.42.0
Greg Kroah-Hartman
maintainerPATCH 198/491 net: stmmac: fix rx budget limit check
In reply to Greg Kroah-Hartman6.5-stable review patch. If anyone has any objections, please let me know.
------------------
From: Baruch Siach <[email protected]>
[ Upstream commit fa02de9e75889915b554eda1964a631fd019973b ]
The while loop condition verifies 'count < limit'. Neither value change before the 'count >= limit' check. As is this check is dead code. But code inspection reveals a code path that modifies 'count' and then goto 'drain_data' and back to 'read_again'. So there is a need to verify count value sanity after 'read_again'.
Move 'read_again' up to fix the count limit check.
--- drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/net/ethernet/stmicro/stmmac/stmmac_main.c +1 -1
@@ -5258,10 +5258,10 @@ static int stmmac_rx(struct stmmac_priv *priv, int limit, u32 queue) len =0 ; } +read_again:if (count >= limit)break ; -read_again: buf1_len =0 ; buf2_len =0 ; entry = next_entry;
Signature · 1 line
2.42.0
Greg Kroah-Hartman
maintainerPATCH 199/491 net: stmmac: avoid rx queue overrun
In reply to Greg Kroah-Hartman6.5-stable review patch. If anyone has any objections, please let me know.
------------------
From: Baruch Siach <[email protected]>
[ Upstream commit b6cb4541853c7ee512111b0e7ddf3cb66c99c137 ]
dma_rx_size can be set as low as 64. Rx budget might be higher than that. Make sure to not overrun allocated rx buffers when budget is larger.
Leave one descriptor unused to avoid wrap around of 'dirty_rx' vs 'cur_rx'.
--- drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 1 + 1 file changed, 1 insertion(+)
drivers/net/ethernet/stmicro/stmmac/stmmac_main.c +1 -0
@@ -5223,6 +5223,7 @@ static int stmmac_rx(struct stmmac_priv *priv, int limit, u32 queue) dma_dir =page_pool_get_dma_dir (rx_q->page_pool); buf_sz =DIV_ROUND_UP (priv->dma_conf.dma_buf_sz,PAGE_SIZE ) *PAGE_SIZE ; + limit =min (priv->dma_conf.dma_rx_size -1 , (unsigned int )limit);if (netif_msg_rx_status (priv)) {void *rx_head;
Signature · 1 line
2.42.0
Greg Kroah-Hartman
maintainerPATCH 200/491 pds_core: use correct index to mask irq
In reply to Greg Kroah-Hartman6.5-stable review patch. If anyone has any objections, please let me know.
------------------
From: Shannon Nelson <[email protected]>
[ Upstream commit 09d4c14c6c5e6e781a3879fed7f8e116a18b8c65 ]
Use the qcq's interrupt index, not the irq number, to mask the interrupt. Since the irq number can be out of range from the number of possible interrupts, we can end up accessing and potentially scribbling on out-of-range and/or unmapped memory, making the kernel angry.
[ 3116.039364] BUG: unable to handle page fault for address: ffffbeea1c3edf84
[ 3116.047059] #PF: supervisor write access in kernel mode
[ 3116.052895] #PF: error_code(0x0002) - not-present page
[ 3116.058636] PGD 100000067 P4D 100000067 PUD 1001f2067 PMD 10f82e067 PTE 0
[ 3116.066221] Oops: 0002 [#1] SMP NOPTI
[ 3116.092948] RIP: 0010:iowrite32+0x9/0x76
[ 3116.190452] Call Trace:
[ 3116.193185] <IRQ>
[ 3116.195430] ? show_trace_log_lvl+0x1d6/0x2f9
[ 3116.200298] ? show_trace_log_lvl+0x1d6/0x2f9
[ 3116.205166] ? pdsc_adminq_isr+0x43/0x55 [pds_core]
[ 3116.210618] ? __die_body.cold+0x8/0xa
[ 3116.214806] ? page_fault_oops+0x16d/0x1ac
[ 3116.219382] ? exc_page_fault+0xbe/0x13b
[ 3116.223764] ? asm_exc_page_fault+0x22/0x27
[ 3116.228440] ? iowrite32+0x9/0x76
[ 3116.232143] pdsc_adminq_isr+0x43/0x55 [pds_core]
[ 3116.237627] __handle_irq_event_percpu+0x3a/0x184
[ 3116.243088] handle_irq_event+0x57/0xb0
[ 3116.247575] handle_edge_irq+0x87/0x225
[ 3116.252062] __common_interrupt+0x3e/0xbc
[ 3116.256740] common_interrupt+0x7b/0x98
[ 3116.261216] </IRQ>
[ 3116.263745] <TASK>
[ 3116.266268] asm_common_interrupt+0x22/0x27--- drivers/net/ethernet/amd/pds_core/adminq.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/net/ethernet/amd/pds_core/adminq.c +1 -1
@@ -146,7 +146,7 @@ irqreturn_t pdsc_adminq_isr(int irq, void *data) }queue_work (pdsc->wq, &qcq->work); -pds_core_intr_mask (&pdsc->intr_ctrl[irq],PDS_CORE_INTR_MASK_CLEAR ); +pds_core_intr_mask (&pdsc->intr_ctrl[qcq->intx],PDS_CORE_INTR_MASK_CLEAR );return IRQ_HANDLED ; }
Signature · 1 line
2.42.0
Greg Kroah-Hartman
maintainerPATCH 201/491 pds_core: fix up some format-truncation complaints
In reply to Greg Kroah-Hartman6.5-stable review patch. If anyone has any objections, please let me know.
------------------
From: Shannon Nelson <[email protected]>
[ Upstream commit 7c02f6ae676a954216a192612040f9a0cde3adf7 ]
Our friendly kernel test robot pointed out a couple of potential string truncation issues. None of which were we worried about, but can be relatively easily fixed to quiet the complaints.
--- drivers/net/ethernet/amd/pds_core/core.h | 2 +- drivers/net/ethernet/amd/pds_core/dev.c | 8 ++++++-- drivers/net/ethernet/amd/pds_core/devlink.c | 2 +- 3 files changed, 8 insertions(+), 4 deletions(-)
drivers/net/ethernet/amd/pds_core/core.h +1 -1
@@ -15,7 +15,7 @@#define PDSC_DRV_DESCRIPTION "AMD/Pensando Core Driver"#define PDSC_WATCHDOG_SECS 5 -#define PDSC_QUEUE_NAME_MAX_SZ 32 +#define PDSC_QUEUE_NAME_MAX_SZ 16#define PDSC_ADMINQ_MIN_LENGTH 16/* must be a power of two */ #define PDSC_NOTIFYQ_LENGTH 64/* must be a power of two */ #define PDSC_TEARDOWN_RECOVERY false
drivers/net/ethernet/amd/pds_core/dev.c +6 -2
@@ -254,10 +254,14 @@ static int pdsc_identify(struct pdsc *pdsc)struct pds_core_drv_identity drv = {};size_t sz;int err; +int n; drv.drv_type =cpu_to_le32 (PDS_DRIVER_LINUX ); -snprintf (drv.driver_ver_str,sizeof (drv.driver_ver_str), -"%s %s" ,PDS_CORE_DRV_NAME ,utsname ()->release); +/* Catching the return quiets a Wformat-truncation complaint */ + n =snprintf (drv.driver_ver_str,sizeof (drv.driver_ver_str), +"%s %s" ,PDS_CORE_DRV_NAME ,utsname ()->release); +if (n >sizeof (drv.driver_ver_str)) +dev_dbg (pdsc->dev,"release name truncated, don't care\n" );/* Next let's get some info about the device * We use the devcmd_lock at this level in order to
drivers/net/ethernet/amd/pds_core/devlink.c +1 -1
@@ -104,7 +104,7 @@ int pdsc_dl_info_get(struct devlink *dl, struct devlink_info_req *req,struct pds_core_fw_list_info fw_list;struct pdsc *pdsc =devlink_priv (dl);union pds_core_dev_comp comp; -char buf[16 ]; +char buf[32 ];int listlen;int err;int i;
Signature · 1 line
2.42.0
Greg Kroah-Hartman
maintainerPATCH 202/491 gve: Fixes for napi_poll when budget is 0
In reply to Greg Kroah-Hartman6.5-stable review patch. If anyone has any objections, please let me know.
------------------
From: Ziwei Xiao <[email protected]>
[ Upstream commit 278a370c1766060d2144d6cf0b06c101e1043b6d ]
Netpoll will explicilty pass the polling call with a budget of 0 to indicate it's clearing the Tx path only. For the gve_rx_poll and gve_xdp_poll, they were mistakenly taking the 0 budget as the indication to do all the work. Add check to avoid the rx path and xdp path being called when budget is 0. And also avoid napi_complete_done being called when budget is 0 for netpoll.
--- drivers/net/ethernet/google/gve/gve_main.c | 8 +++++++- drivers/net/ethernet/google/gve/gve_rx.c | 4 ---- drivers/net/ethernet/google/gve/gve_tx.c | 4 ---- 3 files changed, 7 insertions(+), 9 deletions(-)
drivers/net/ethernet/google/gve/gve_main.c +7 -1
@@ -255,10 +255,13 @@ static int gve_napi_poll(struct napi_struct *napi, int budget)if (block->tx) {if (block->tx->q_num < priv->tx_cfg.num_queues) reschedule |=gve_tx_poll (block, budget); -else +else if (budget) reschedule |=gve_xdp_poll (block, budget); } +if (!budget) +return 0 ; +if (block->rx) { work_done =gve_rx_poll (block, budget); reschedule |= work_done == budget;
@@ -299,6 +302,9 @@ static int gve_napi_poll_dqo(struct napi_struct *napi, int budget)if (block->tx) reschedule |=gve_tx_poll_dqo (block,/*do_clean=*/ true); +if (!budget) +return 0 ; +if (block->rx) { work_done =gve_rx_poll_dqo (block, budget); reschedule |= work_done == budget;
drivers/net/ethernet/google/gve/gve_rx.c +0 -4
@@ -1007,10 +1007,6 @@ int gve_rx_poll(struct gve_notify_block *block, int budget) feat = block->napi.dev->features; -/* If budget is 0, do all the work */ -if (budget ==0 ) - budget =INT_MAX ; -if (budget >0 ) work_done =gve_clean_rx_done (rx, budget, feat);
drivers/net/ethernet/google/gve/gve_tx.c +0 -4
@@ -925,10 +925,6 @@ bool gve_xdp_poll(struct gve_notify_block *block, int budget)bool repoll;u32 to_do; -/* If budget is 0, do all the work */ -if (budget ==0 ) - budget =INT_MAX ; -/* Find out how much work there is to be done */ nic_done =gve_tx_load_event_counter (priv, tx); to_do =min_t (u32, (nic_done - tx->done), budget);
Signature · 1 line
2.42.0
Greg Kroah-Hartman
maintainerPATCH 203/491 io_uring/fdinfo: remove need for sqpoll lock for thread/pid retrieval
In reply to Greg Kroah-Hartman6.5-stable review patch. If anyone has any objections, please let me know.
------------------
From: Jens Axboe <[email protected]>
[ Upstream commit a0d45c3f596be53c1bd8822a1984532d14fdcea9 ]
A previous commit added a trylock for getting the SQPOLL thread info via fdinfo, but this introduced a regression where we often fail to get it if the thread is busy. For that case, we end up not printing the current CPU and PID info.
Rather than rely on this lock, just print the pid we already stored in the io_sq_data struct, and ensure we update the current CPU every time we've slept or potentially rescheduled. The latter won't potentially be 100% accurate, but that wasn't the case before either as the task can get migrated at any time unless it has been pinned at creation time.
We retain keeping the io_sq_data dereference inside the ctx->uring_lock, as it has always been, as destruction of the thread and data happen below that. We could make this RCU safe, but there's little point in doing that.
With this, we always print the last valid information we had, rather than have spurious outputs with missing information.
--- io_uring/fdinfo.c | 9 ++------- io_uring/sqpoll.c | 12 ++++++++++-- 2 files changed, 12 insertions(+), 9 deletions(-)
io_uring/fdinfo.c +2 -7
@@ -139,13 +139,8 @@ static __cold void __io_uring_show_fdinfo(struct io_ring_ctx *ctx,if (has_lock && (ctx->flags &IORING_SETUP_SQPOLL )) {struct io_sq_data *sq = ctx->sq_data; -if (mutex_trylock (&sq->lock)) { -if (sq->thread) { - sq_pid =task_pid_nr (sq->thread); - sq_cpu =task_cpu (sq->thread); - } -mutex_unlock (&sq->lock); - } + sq_pid = sq->task_pid; + sq_cpu = sq->sq_cpu; }seq_printf (m,"SqThread:\t%d\n" , sq_pid);
io_uring/sqpoll.c +10 -2
@@ -214,6 +214,7 @@ static bool io_sqd_handle_event(struct io_sq_data *sqd) did_sig =get_signal (&ksig);cond_resched ();mutex_lock (&sqd->lock); + sqd->sq_cpu =raw_smp_processor_id (); }return did_sig ||test_bit (IO_SQ_THREAD_SHOULD_STOP , &sqd->state); }
@@ -229,10 +230,15 @@ static int io_sq_thread(void *data)snprintf (buf,sizeof (buf),"iou-sqp-%d" , sqd->task_pid);set_task_comm (current, buf); -if (sqd->sq_cpu !=-1 ) +/* reset to our pid after we've set task_comm, for fdinfo */ + sqd->task_pid = current->pid; + +if (sqd->sq_cpu !=-1 ) {set_cpus_allowed_ptr (current,cpumask_of (sqd->sq_cpu)); -else + }else {set_cpus_allowed_ptr (current, cpu_online_mask); + sqd->sq_cpu =raw_smp_processor_id (); + }mutex_lock (&sqd->lock);while (1 ) {
@@ -261,6 +267,7 @@ static int io_sq_thread(void *data)mutex_unlock (&sqd->lock);cond_resched ();mutex_lock (&sqd->lock); + sqd->sq_cpu =raw_smp_processor_id (); }continue ; }
@@ -294,6 +301,7 @@ static int io_sq_thread(void *data)mutex_unlock (&sqd->lock);schedule ();mutex_lock (&sqd->lock); + sqd->sq_cpu =raw_smp_processor_id (); }list_for_each_entry (ctx, &sqd->ctx_list, sqd_list) atomic_andnot(IORING_SQ_NEED_WAKEUP,
Signature · 1 line
2.42.0
Greg Kroah-Hartman
maintainerPATCH 204/491 net/mlx5: Decouple PHC .adjtime and .adjphase implementations
In reply to Greg Kroah-Hartman6.5-stable review patch. If anyone has any objections, please let me know.
------------------
From: Rahul Rameshbabu <[email protected]>
[ Upstream commit fd64fd13c49a53012ce9170449dcd9eb71c11284 ]
When running a phase adjustment operation, the free running clock should not be modified at all. The phase control keyword is intended to trigger an internal servo on the device that will converge to the provided delta. A free running counter cannot implement phase adjustment.
--- drivers/net/ethernet/mellanox/mlx5/core/lib/clock.c | 7 ++++++- 1 file changed, 6 insertions(+), 1 deletion(-)
drivers/net/ethernet/mellanox/mlx5/core/lib/clock.c +6 -1
@@ -384,7 +384,12 @@ static int mlx5_ptp_adjtime(struct ptp_clock_info *ptp, s64 delta)static int mlx5_ptp_adjphase (struct ptp_clock_info *ptp,s32 delta) { -return mlx5_ptp_adjtime (ptp, delta); + struct mlx5_clock *clock = container_of(ptp, struct mlx5_clock, ptp_info); +struct mlx5_core_dev *mdev; + + mdev = container_of(clock, struct mlx5_core_dev, clock); + +return mlx5_ptp_adjtime_real_time (mdev, delta); }static int mlx5_ptp_freq_adj_real_time (struct mlx5_core_dev *mdev,long scaled_ppm)
Signature · 1 line
2.42.0
Greg Kroah-Hartman
maintainerPATCH 205/491 net/mlx5e: fix double free of encap_header
In reply to Greg Kroah-Hartman6.5-stable review patch. If anyone has any objections, please let me know.
------------------
From: Dust Li <[email protected]>
[ Upstream commit 6f9b1a0731662648949a1c0587f6acb3b7f8acf1 ]
When mlx5_packet_reformat_alloc() fails, the encap_header allocated in mlx5e_tc_tun_create_header_ipv4{6} will be released within it. However, e->encap_header is already set to the previously freed encap_header before mlx5_packet_reformat_alloc(). As a result, the later mlx5e_encap_put() will free e->encap_header again, causing a double free issue.
mlx5e_encap_put()
--> mlx5e_encap_dealloc()
--> kfree(e->encap_header)This happens when cmd: MLX5_CMD_OP_ALLOC_PACKET_REFORMAT_CONTEXT fail.
This patch fix it by not setting e->encap_header until mlx5_packet_reformat_alloc() success.
--- drivers/net/ethernet/mellanox/mlx5/core/en/tc_tun.c | 10 ++++------ 1 file changed, 4 insertions(+), 6 deletions(-)
drivers/net/ethernet/mellanox/mlx5/core/en/tc_tun.c +4 -6
@@ -300,9 +300,6 @@ int mlx5e_tc_tun_create_header_ipv4(struct mlx5e_priv *priv,if (err) goto destroy_neigh_entry; - e->encap_size = ipv4_encap_size; - e->encap_header = encap_header; -if (!(nud_state &NUD_VALID )) {neigh_event_send (attr.n,NULL );/* the encap entry will be made valid on neigh update event
@@ -322,6 +319,8 @@ int mlx5e_tc_tun_create_header_ipv4(struct mlx5e_priv *priv, goto destroy_neigh_entry; } + e->encap_size = ipv4_encap_size; + e->encap_header = encap_header; e->flags |=MLX5_ENCAP_ENTRY_VALID ;mlx5e_rep_queue_neigh_stats_work (netdev_priv (attr.out_dev));mlx5e_route_lookup_ipv4_put (&attr);
@@ -568,9 +567,6 @@ int mlx5e_tc_tun_create_header_ipv6(struct mlx5e_priv *priv,if (err) goto destroy_neigh_entry; - e->encap_size = ipv6_encap_size; - e->encap_header = encap_header; -if (!(nud_state &NUD_VALID )) {neigh_event_send (attr.n,NULL );/* the encap entry will be made valid on neigh update event
@@ -590,6 +586,8 @@ int mlx5e_tc_tun_create_header_ipv6(struct mlx5e_priv *priv, goto destroy_neigh_entry; } + e->encap_size = ipv6_encap_size; + e->encap_header = encap_header; e->flags |=MLX5_ENCAP_ENTRY_VALID ;mlx5e_rep_queue_neigh_stats_work (netdev_priv (attr.out_dev));mlx5e_route_lookup_ipv6_put (&attr);
Signature · 1 line
2.42.0
Greg Kroah-Hartman
maintainerPATCH 206/491 net/mlx5e: fix double free of encap_header in update funcs
In reply to Greg Kroah-Hartman6.5-stable review patch. If anyone has any objections, please let me know.
------------------
From: Gavin Li <[email protected]>
[ Upstream commit 3a4aa3cb83563df942be49d145ee3b7ddf17d6bb ]
Follow up to the previous patch to fix the same issue for mlx5e_tc_tun_update_header_ipv4{6} when mlx5_packet_reformat_alloc() fails.
When mlx5_packet_reformat_alloc() fails, the encap_header allocated in mlx5e_tc_tun_update_header_ipv4{6} will be released within it. However, e->encap_header is already set to the previously freed encap_header before mlx5_packet_reformat_alloc(). As a result, the later mlx5e_encap_put() will free e->encap_header again, causing a double free issue.
mlx5e_encap_put()
--> mlx5e_encap_dealloc()
--> kfree(e->encap_header)This patch fix it by not setting e->encap_header until mlx5_packet_reformat_alloc() success.
--- .../ethernet/mellanox/mlx5/core/en/tc_tun.c | 20 +++++++++---------- 1 file changed, 10 insertions(+), 10 deletions(-)
drivers/net/ethernet/mellanox/mlx5/core/en/tc_tun.c +10 -10
@@ -403,16 +403,12 @@ int mlx5e_tc_tun_update_header_ipv4(struct mlx5e_priv *priv,if (err) goto free_encap; - e->encap_size = ipv4_encap_size; -kfree (e->encap_header); - e->encap_header = encap_header; -if (!(nud_state &NUD_VALID )) {neigh_event_send (attr.n,NULL );/* the encap entry will be made valid on neigh update event * and not used before that. */ - goto release_neigh; + goto free_encap; }memset (&reformat_params,0 ,sizeof (reformat_params));
@@ -426,6 +422,10 @@ int mlx5e_tc_tun_update_header_ipv4(struct mlx5e_priv *priv, goto free_encap; } + e->encap_size = ipv4_encap_size; +kfree (e->encap_header); + e->encap_header = encap_header; + e->flags |=MLX5_ENCAP_ENTRY_VALID ;mlx5e_rep_queue_neigh_stats_work (netdev_priv (attr.out_dev));mlx5e_route_lookup_ipv4_put (&attr);
@@ -669,16 +669,12 @@ int mlx5e_tc_tun_update_header_ipv6(struct mlx5e_priv *priv,if (err) goto free_encap; - e->encap_size = ipv6_encap_size; -kfree (e->encap_header); - e->encap_header = encap_header; -if (!(nud_state &NUD_VALID )) {neigh_event_send (attr.n,NULL );/* the encap entry will be made valid on neigh update event * and not used before that. */ - goto release_neigh; + goto free_encap; }memset (&reformat_params,0 ,sizeof (reformat_params));
@@ -692,6 +688,10 @@ int mlx5e_tc_tun_update_header_ipv6(struct mlx5e_priv *priv, goto free_encap; } + e->encap_size = ipv6_encap_size; +kfree (e->encap_header); + e->encap_header = encap_header; + e->flags |=MLX5_ENCAP_ENTRY_VALID ;mlx5e_rep_queue_neigh_stats_work (netdev_priv (attr.out_dev));mlx5e_route_lookup_ipv6_put (&attr);
Signature · 1 line
2.42.0
Greg Kroah-Hartman
maintainerPATCH 207/491 net/mlx5e: Fix pedit endianness
In reply to Greg Kroah-Hartman6.5-stable review patch. If anyone has any objections, please let me know.
------------------
From: Vlad Buslov <[email protected]>
[ Upstream commit 0c101a23ca7eaf00eef1328eefb04b3a93401cc8 ]
Referenced commit addressed endianness issue in mlx5 pedit implementation in ad hoc manner instead of systematically treating integer values according to their types which left pedit fields of sizes not equal to 4 and where the bytes being modified are not least significant ones broken on big endian machines since wrong bits will be consumed during parsing which leads to following example error when applying pedit to source and destination MAC addresses:
[Wed Oct 18 12:52:42 2023] mlx5_core 0001:00:00.1 p1v3_r: attempt to offload an unsupported field (cmd 0) [Wed Oct 18 12:52:42 2023] mask: 00000000330c5b68: 00 00 00 00 ff ff 00 00 00 00 ff ff 00 00 00 00 ................ [Wed Oct 18 12:52:42 2023] mask: 0000000017d22fd9: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ [Wed Oct 18 12:52:42 2023] mask: 000000008186d717: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ [Wed Oct 18 12:52:42 2023] mask: 0000000029eb6149: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ [Wed Oct 18 12:52:42 2023] mask: 000000007ed103e4: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ [Wed Oct 18 12:52:42 2023] mask: 00000000db8101a6: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ [Wed Oct 18 12:52:42 2023] mask: 00000000ec3c08a9: 00 00 00 00 00 00 00 00 00 00 00 00 ............
Treat masks and values of pedit and filter match as network byte order, refactor pointers to them to void pointers instead of confusing u32 pointers and only cast to pointer-to-integer when reading a value from them. Treat pedit mlx5_fields->field_mask as host byte order according to its type u32, change the constants in fields array accordingly.
--- .../net/ethernet/mellanox/mlx5/core/en_tc.c | 60 ++++++++++--------- 1 file changed, 32 insertions(+), 28 deletions(-)
drivers/net/ethernet/mellanox/mlx5/core/en_tc.c +32 -28
@@ -3148,7 +3148,7 @@ static struct mlx5_fields fields[] = {OFFLOAD (DIPV6_31_0 ,32 ,U32_MAX , ip6.daddr.s6_addr32[3 ],0 , dst_ipv4_dst_ipv6.ipv6_layout.ipv6[12 ]),OFFLOAD (IPV6_HOPLIMIT ,8 ,U8_MAX , ip6.hop_limit,0 , ttl_hoplimit), -OFFLOAD (IP_DSCP ,16 ,0xc00f , ip6,0 , ip_dscp), +OFFLOAD (IP_DSCP ,16 ,0x0fc0 , ip6,0 , ip_dscp),OFFLOAD (TCP_SPORT ,16 ,U16_MAX , tcp.source,0 , tcp_sport), OFFLOAD(TCP_DPORT, 16, U16_MAX, tcp.dest, 0, tcp_dport),
@@ -3159,21 +3159,31 @@ static struct mlx5_fields fields[] = { OFFLOAD(UDP_DPORT, 16, U16_MAX, udp.dest, 0, udp_dport), }; -static unsigned long mask_to_le (unsigned long mask,int size) +static u32 mask_field_get (void *mask,struct mlx5_fields *f) { -__be32 mask_be32; -__be16 mask_be16; - -if (size ==32 ) { - mask_be32 = (__force __be32)(mask); - mask = (__force unsigned long )cpu_to_le32 (be32_to_cpu (mask_be32)); - }else if (size ==16 ) { - mask_be32 = (__force __be32)(mask); - mask_be16 = *(__be16 *)&mask_be32; - mask = (__force unsigned long )cpu_to_le16 (be16_to_cpu (mask_be16)); +switch (f->field_bsize) { +case 32 : +return be32_to_cpu (*(__be32 *)mask) & f->field_mask; +case 16 : +return be16_to_cpu (*(__be16 *)mask) & (u16 )f->field_mask; +default : +return *(u8 *)mask & (u8 )f->field_mask; } +} -return mask; +static void mask_field_clear (void *mask,struct mlx5_fields *f) +{ +switch (f->field_bsize) { +case 32 : + *(__be32 *)mask &= ~cpu_to_be32 (f->field_mask); +break ; +case 16 : + *(__be16 *)mask &= ~cpu_to_be16 ((u16 )f->field_mask); +break ; +default : + *(u8 *)mask &= ~(u8 )f->field_mask; +break ; + } } static int offload_pedit_fields(struct mlx5e_priv *priv,
@@ -3185,11 +3195,12 @@ static int offload_pedit_fields(struct mlx5e_priv *priv,struct pedit_headers *set_masks, *add_masks, *set_vals, *add_vals;struct pedit_headers_action *hdrs = parse_attr->hdrs;void *headers_c, *headers_v, *action, *vals_p; -u32 *s_masks_p, *a_masks_p, s_mask, a_mask;struct mlx5e_tc_mod_hdr_acts *mod_acts; -unsigned long mask, field_mask; +void *s_masks_p, *a_masks_p;int i, first, last, next_z;struct mlx5_fields *f; +unsigned long mask; +u32 s_mask, a_mask;u8 cmd; mod_acts = &parse_attr->mod_hdr_acts;
@@ -3205,15 +3216,11 @@ static int offload_pedit_fields(struct mlx5e_priv *priv,bool skip; f = &fields[i]; -/* avoid seeing bits set from previous iterations */ - s_mask =0 ; - a_mask =0 ; - s_masks_p = (void *)set_masks + f->offset; a_masks_p = (void *)add_masks + f->offset; - s_mask = *s_masks_p & f->field_mask; - a_mask = *a_masks_p & f->field_mask; + s_mask =mask_field_get (s_masks_p, f); + a_mask =mask_field_get (a_masks_p, f);if (!s_mask && !a_mask)/* nothing to offload here */ continue ;
@@ -3240,22 +3247,20 @@ static int offload_pedit_fields(struct mlx5e_priv *priv, match_mask, f->field_bsize)) skip = true;/* clear to denote we consumed this field */ - *s_masks_p &= ~f->field_mask; +mask_field_clear (s_masks_p, f); }else { cmd =MLX5_ACTION_TYPE_ADD ; mask = a_mask; vals_p = (void *)add_vals + f->offset;/* add 0 is no change */ -if ((*(u32 *)vals_p & f->field_mask) ==0 ) +if (!mask_field_get (vals_p, f)) skip = true;/* clear to denote we consumed this field */ - *a_masks_p &= ~f->field_mask; +mask_field_clear (a_masks_p, f); }if (skip)continue ; - mask =mask_to_le (mask, f->field_bsize); - first =find_first_bit (&mask, f->field_bsize); next_z =find_next_zero_bit (&mask, f->field_bsize, first); last =find_last_bit (&mask, f->field_bsize);
@@ -3282,10 +3287,9 @@ static int offload_pedit_fields(struct mlx5e_priv *priv,MLX5_SET (set_action_in, action, field, f->field);if (cmd ==MLX5_ACTION_TYPE_SET ) { +unsigned long field_mask = f->field_mask;int start; - field_mask =mask_to_le (f->field_mask, f->field_bsize); -/* if field is bit sized it can start not from first bit */ start =find_first_bit (&field_mask, f->field_bsize);
Signature · 1 line
2.42.0
Greg Kroah-Hartman
maintainerPATCH 208/491 net/mlx5: Consolidate devlink documentation in devlink/mlx5.rst
In reply to Greg Kroah-Hartman6.5-stable review patch. If anyone has any objections, please let me know.
------------------
From: Rahul Rameshbabu <[email protected]>
[ Upstream commit b608dd670bb69c89d5074685899d4c1089f57a16 ]
De-duplicate documentation by removing mellanox/mlx5/devlink.rst. Instead, only use the generic devlink documentation directory to document mlx5 devlink parameters. Avoid providing general devlink tool usage information in mlx5-specific documentation.
Stable-dep-of: 92214be5979c ("net/mlx5e: Update doorbell for port timestamping CQ before the software counter")
--- .../ethernet/mellanox/mlx5/devlink.rst | 313 ------------------ .../ethernet/mellanox/mlx5/index.rst | 1 - Documentation/networking/devlink/mlx5.rst | 179 ++++++++++ 3 files changed, 179 insertions(+), 314 deletions(-) delete mode 100644 Documentation/networking/device_drivers/ethernet/mellanox/mlx5/devlink.rst
Documentation/networking/device_drivers/ethernet/mellanox/mlx5/devlink.rst deleted +0 -313
@@ -1,313 +0,0 @@ -.. SPDX-License-Identifier: GPL-2.0 OR Linux-OpenIB -.. include:: <isonum.txt> - -======= -Devlink -======= - -:Copyright: |copy| 2023, NVIDIA CORPORATION & AFFILIATES. All rights reserved. - -Contents -======== - -- `Info`_ -- `Parameters`_ -- `Health reporters`_ - -Info -==== - -The devlink info reports the running and stored firmware versions on device. -It also prints the device PSID which represents the HCA board type ID. - -User command example:: - - $ devlink dev info pci/0000:00:06.0 - pci/0000:00:06.0: - driver mlx5_core - versions: - fixed: - fw.psid MT_0000000009 - running: - fw.version 16.26.0100 - stored: - fw.version 16.26.0100 - -Parameters -========== - -flow_steering_mode: Device flow steering mode ---------------------------------------------- -The flow steering mode parameter controls the flow steering mode of the driver. -Two modes are supported: - -1. 'dmfs' - Device managed flow steering. -2. 'smfs' - Software/Driver managed flow steering. - -In DMFS mode, the HW steering entities are created and managed through the -Firmware. -In SMFS mode, the HW steering entities are created and managed though by -the driver directly into hardware without firmware intervention. - -SMFS mode is faster and provides better rule insertion rate compared to default DMFS mode. - -User command examples: - -- Set SMFS flow steering mode:: - - $ devlink dev param set pci/0000:06:00.0 name flow_steering_mode value "smfs" cmode runtime - -- Read device flow steering mode:: - - $ devlink dev param show pci/0000:06:00.0 name flow_steering_mode - pci/0000:06:00.0: - name flow_steering_mode type driver-specific - values: - cmode runtime value smfs - -enable_roce: RoCE enablement state ----------------------------------- -If the device supports RoCE disablement, RoCE enablement state controls device -support for RoCE capability. Otherwise, the control occurs in the driver stack. -When RoCE is disabled at the driver level, only raw ethernet QPs are supported. - -To change RoCE enablement state, a user must change the driverinit cmode value -and run devlink reload. - -User command examples: - -- Disable RoCE:: - - $ devlink dev param set pci/0000:06:00.0 name enable_roce value false cmode driverinit - $ devlink dev reload pci/0000:06:00.0 - -- Read RoCE enablement state:: - - $ devlink dev param show pci/0000:06:00.0 name enable_roce - pci/0000:06:00.0: - name enable_roce type generic - values: - cmode driverinit value true - -esw_port_metadata: Eswitch port metadata state ----------------------------------------------- -When applicable, disabling eswitch metadata can increase packet rate -up to 20% depending on the use case and packet sizes. - -Eswitch port metadata state controls whether to internally tag packets with -metadata. Metadata tagging must be enabled for multi-port RoCE, failover -between representors and stacked devices. -By default metadata is enabled on the supported devices in E-switch. -Metadata is applicable only for E-switch in switchdev mode and -users may disable it when NONE of the below use cases will be in use: - -1. HCA is in Dual/multi-port RoCE mode. -2. VF/SF representor bonding (Usually used for Live migration) -3. Stacked devices - -When metadata is disabled, the above use cases will fail to initialize if -users try to enable them. - -- Show eswitch port metadata:: - - $ devlink dev param show pci/0000:06:00.0 name esw_port_metadata - pci/0000:06:00.0: - name esw_port_metadata type driver-specific - values: - cmode runtime value true - -- Disable eswitch port metadata:: - - $ devlink dev param set pci/0000:06:00.0 name esw_port_metadata value false cmode runtime - -- Change eswitch mode to switchdev mode where after choosing the metadata value:: - - $ devlink dev eswitch set pci/0000:06:00.0 mode switchdev - -hairpin_num_queues: Number of hairpin queues --------------------------------------------- -We refer to a TC NIC rule that involves forwarding as "hairpin". - -Hairpin queues are mlx5 hardware specific implementation for hardware -forwarding of such packets. - -- Show the number of hairpin queues:: - - $ devlink dev param show pci/0000:06:00.0 name hairpin_num_queues - pci/0000:06:00.0: - name hairpin_num_queues type driver-specific - values: - cmode driverinit value 2 - -- Change the number of hairpin queues:: - - $ devlink dev param set pci/0000:06:00.0 name hairpin_num_queues value 4 cmode driverinit - -hairpin_queue_size: Size of the hairpin queues ----------------------------------------------- -Control the size of the hairpin queues. - -- Show the size of the hairpin queues:: - - $ devlink dev param show pci/0000:06:00.0 name hairpin_queue_size - pci/0000:06:00.0: - name hairpin_queue_size type driver-specific - values: - cmode driverinit value 1024 - -- Change the size (in packets) of the hairpin queues:: - - $ devlink dev param set pci/0000:06:00.0 name hairpin_queue_size value 512 cmode driverinit - -Health reporters -================ - -tx reporter ------------ -The tx reporter is responsible for reporting and recovering of the following two error scenarios: - -- tx timeout - Report on kernel tx timeout detection. - Recover by searching lost interrupts. -- tx error completion - Report on error tx completion. - Recover by flushing the tx queue and reset it. - -tx reporter also support on demand diagnose callback, on which it provides -real time information of its send queues status. - -User commands examples: - -- Diagnose send queues status:: - - $ devlink health diagnose pci/0000:82:00.0 reporter tx - -.. note:: - This command has valid output only when interface is up, otherwise the command has empty output. - -- Show number of tx errors indicated, number of recover flows ended successfully, - is autorecover enabled and graceful period from last recover:: - - $ devlink health show pci/0000:82:00.0 reporter tx - -rx reporter ------------ -The rx reporter is responsible for reporting and recovering of the following two error scenarios: - -- rx queues' initialization (population) timeout - Population of rx queues' descriptors on ring initialization is done - in napi context via triggering an irq. In case of a failure to get - the minimum amount of descriptors, a timeout would occur, and - descriptors could be recovered by polling the EQ (Event Queue). -- rx completions with errors (reported by HW on interrupt context) - Report on rx completion error. - Recover (if needed) by flushing the related queue and reset it. - -rx reporter also supports on demand diagnose callback, on which it -provides real time information of its receive queues' status. - -- Diagnose rx queues' status and corresponding completion queue:: - - $ devlink health diagnose pci/0000:82:00.0 reporter rx - -NOTE: This command has valid output only when interface is up. Otherwise, the command has empty output. - -- Show number of rx errors indicated, number of recover flows ended successfully, - is autorecover enabled, and graceful period from last recover:: - - $ devlink health show pci/0000:82:00.0 reporter rx - -fw reporter ------------ -The fw reporter implements `diagnose` and `dump` callbacks. -It follows symptoms of fw error such as fw syndrome by triggering -fw core dump and storing it into the dump buffer. -The fw reporter diagnose command can be triggered any time by the user to check -current fw status. - -User commands examples: - -- Check fw heath status:: - - $ devlink health diagnose pci/0000:82:00.0 reporter fw - -- Read FW core dump if already stored or trigger new one:: - - $ devlink health dump show pci/0000:82:00.0 reporter fw - -.. note:: - This command can run only on the PF which has fw tracer ownership, - running it on other PF or any VF will return "Operation not permitted". - -fw fatal reporter ------------------ -The fw fatal reporter implements `dump` and `recover` callbacks. -It follows fatal errors indications by CR-space dump and recover flow. -The CR-space dump uses vsc interface which is valid even if the FW command -interface is not functional, which is the case in most FW fatal errors. -The recover function runs recover flow which reloads the driver and triggers fw -reset if needed. -On firmware error, the health buffer is dumped into the dmesg. The log -level is derived from the error's severity (given in health buffer). - -User commands examples: - -- Run fw recover flow manually:: - - $ devlink health recover pci/0000:82:00.0 reporter fw_fatal - -- Read FW CR-space dump if already stored or trigger new one:: - - $ devlink health dump show pci/0000:82:00.1 reporter fw_fatal - -.. note:: - This command can run only on PF. - -vnic reporter -------------- -The vnic reporter implements only the `diagnose` callback. -It is responsible for querying the vnic diagnostic counters from fw and displaying -them in realtime. - -Description of the vnic counters: - -- total_q_under_processor_handle - number of queues in an error state due to - an async error or errored command. -- send_queue_priority_update_flow - number of QP/SQ priority/SL update events. -- cq_overrun - number of times CQ entered an error state due to an overflow. -- async_eq_overrun - number of times an EQ mapped to async events was overrun. - comp_eq_overrun number of times an EQ mapped to completion events was - overrun. -- quota_exceeded_command - number of commands issued and failed due to quota exceeded. -- invalid_command - number of commands issued and failed dues to any reason other than quota - exceeded. -- nic_receive_steering_discard - number of packets that completed RX flow - steering but were discarded due to a mismatch in flow table. -- generated_pkt_steering_fail - number of packets generated by the VNIC experiencing unexpected steering - failure (at any point in steering flow). -- handled_pkt_steering_fail - number of packets handled by the VNIC experiencing unexpected steering - failure (at any point in steering flow owned by the VNIC, including the FDB - for the eswitch owner). - -User commands examples: - -- Diagnose PF/VF vnic counters:: - - $ devlink health diagnose pci/0000:82:00.1 reporter vnic - -- Diagnose representor vnic counters (performed by supplying devlink port of the - representor, which can be obtained via devlink port command):: - - $ devlink health diagnose pci/0000:82:00.1/65537 reporter vnic - -.. note:: - This command can run over all interfaces such as PF/VF and representor ports.
Documentation/networking/device_drivers/ethernet/mellanox/mlx5/index.rst +0 -1
@@ -13,7 +13,6 @@ Contents: :maxdepth: 2 kconfig - devlink switchdev tracepoints counters
Documentation/networking/devlink/mlx5.rst +179 -0
201 lines not on this page · raw message
Signature · 1 line
2.42.0
Greg Kroah-Hartman
maintainerPATCH 209/491 net/mlx5e: Make tx_port_ts logic resilient to out-of-order CQEs
In reply to Greg Kroah-Hartman6.5-stable review patch. If anyone has any objections, please let me know.
------------------
From: Rahul Rameshbabu <[email protected]>
[ Upstream commit 3178308ad4ca38955cad684d235153d4939f1fcd ]
Use a map structure for associating CQEs containing port timestamping information with the appropriate skb. Track order of WQEs submitted using a FIFO. Check if the corresponding port timestamping CQEs from the lookup values in the FIFO are considered dropped due to time elapsed. Return the lookup value to a freelist after consuming the skb. Reuse the freed lookup in future WQE submission iterations.
The map structure uses an integer identifier for the key and returns an skb corresponding to that identifier. Embed the integer identifier in the WQE submitted to the WQ for the transmit path when the SQ is a PTP (port timestamping) SQ. The embedded identifier can then be queried using a field in the CQE of the corresponding port timestamping CQ. In the port timestamping napi_poll context, the identifier is queried from the CQE polled from CQ and used to lookup the corresponding skb from the WQE submit path. The skb reference is removed from map and then embedded with the port HW timestamp information from the CQE and eventually consumed.
The metadata freelist FIFO is an array containing integer identifiers that can be pushed and popped in the FIFO. The purpose of this structure is bookkeeping what identifier values can safely be used in a subsequent WQE submission and should not contain identifiers that have still not been reaped by processing a corresponding CQE completion on the port timestamping CQ.
The ts_cqe_pending_list structure is a combination of an array and linked list. The array is pre-populated with the nodes that will be added and removed from the head of the linked list. Each node contains the unique identifier value associated with the values submitted in the WQEs and retrieved in the port timestamping CQEs. When a WQE is submitted, the node in the array corresponding to the identifier popped from the metadata freelist is added to the end of the CQE pending list and is marked as "in-use". The node is removed from the linked list under two conditions. The first condition is that the corresponding port timestamping CQE is polled in the PTP napi_poll context. The second condition is that more than a second has elapsed since the DMA timestamp value corresponding to the WQE submission. When the first condition occurs, the "in-use" bit in the linked list node is cleared, and the resources corresponding to the WQE submission are then released. The second condition, however, indicates that the port timestamping CQE will likely never be delivered. It's not impossible for the device to post a CQE after an infinite amount of time though highly improbable. In order to be resilient to this improbable case, resources related to the corresponding WQE submission are still kept, the identifier value is not returned to the freelist, and the "in-use" bit is cleared on the node to indicate that it's no longer part of the linked list of "likely to be delivered" port timestamping CQE identifiers. A count for the number of port timestamping CQEs considered highly likely to never be delivered by the device is maintained. This count gets decremented in the unlikely event a port timestamping CQE considered unlikely to ever be delivered is polled in the PTP napi_poll context.
Stable-dep-of: 92214be5979c ("net/mlx5e: Update doorbell for port timestamping CQ before the software counter")
--- .../ethernet/mellanox/mlx5/counters.rst | 6 + .../net/ethernet/mellanox/mlx5/core/en/ptp.c | 215 +++++++++++++----- .../net/ethernet/mellanox/mlx5/core/en/ptp.h | 57 ++++- .../ethernet/mellanox/mlx5/core/en_ethtool.c | 3 +- .../ethernet/mellanox/mlx5/core/en_stats.c | 4 +- .../ethernet/mellanox/mlx5/core/en_stats.h | 4 +- .../net/ethernet/mellanox/mlx5/core/en_tx.c | 28 ++- 7 files changed, 236 insertions(+), 81 deletions(-)
Documentation/networking/device_drivers/ethernet/mellanox/mlx5/counters.rst +6 -0
@@ -683,6 +683,12 @@ the software port. time protocol. - Error + * - `ptp_cq[i]_late_cqe` + - Number of times a CQE has been delivered on the PTP timestamping CQ when + the CQE was not expected since a certain amount of time had elapsed where + the device typically ensures not posting the CQE. + - Error + .. [#ring_global] The corresponding ring and global counters do not share the same name (i.e. do not follow the common naming scheme).
drivers/net/ethernet/mellanox/mlx5/core/en/ptp.c +158 -57
303 lines not on this page · raw message
drivers/net/ethernet/mellanox/mlx5/core/en/ptp.h +50 -7
86 lines not on this page · raw message
drivers/net/ethernet/mellanox/mlx5/core/en_ethtool.c +2 -1
@@ -2061,7 +2061,8 @@ static int set_pflag_tx_port_ts(struct net_device *netdev, bool enable)struct mlx5e_params new_params;int err; -if (!MLX5_CAP_GEN (mdev, ts_cqe_to_dest_cqn)) +if (!MLX5_CAP_GEN (mdev, ts_cqe_to_dest_cqn) || + !MLX5_CAP_GEN_2 (mdev, ts_cqe_metadata_size2wqe_counter))return -EOPNOTSUPP ;/* Don't allow changing the PTP state if HTB offload is active, because
drivers/net/ethernet/mellanox/mlx5/core/en_stats.c +1 -3
@@ -2142,9 +2142,7 @@ static const struct counter_desc ptp_cq_stats_desc[] = { { MLX5E_DECLARE_PTP_CQ_STAT(struct mlx5e_ptp_cq_stats, err_cqe) }, { MLX5E_DECLARE_PTP_CQ_STAT(struct mlx5e_ptp_cq_stats, abort) }, { MLX5E_DECLARE_PTP_CQ_STAT(struct mlx5e_ptp_cq_stats, abort_abs_diff_ns) }, - { MLX5E_DECLARE_PTP_CQ_STAT(struct mlx5e_ptp_cq_stats, resync_cqe) }, - { MLX5E_DECLARE_PTP_CQ_STAT(struct mlx5e_ptp_cq_stats, resync_event) }, - { MLX5E_DECLARE_PTP_CQ_STAT(struct mlx5e_ptp_cq_stats, ooo_cqe_drop) }, + { MLX5E_DECLARE_PTP_CQ_STAT(struct mlx5e_ptp_cq_stats, late_cqe) }, }; static const struct counter_desc ptp_rq_stats_desc[] = {
drivers/net/ethernet/mellanox/mlx5/core/en_stats.h +1 -3
@@ -449,9 +449,7 @@ struct mlx5e_ptp_cq_stats {u64 err_cqe;u64 abort;u64 abort_abs_diff_ns; -u64 resync_cqe; -u64 resync_event; -u64 ooo_cqe_drop; +u64 late_cqe; };struct mlx5e_rep_stats {
drivers/net/ethernet/mellanox/mlx5/core/en_tx.c +18 -10
@@ -372,7 +372,7 @@ mlx5e_txwqe_complete(struct mlx5e_txqsq *sq, struct sk_buff *skb,const struct mlx5e_tx_attr *attr, const struct mlx5e_tx_wqe_attr *wqe_attr, u8 num_dma, struct mlx5e_tx_wqe_info *wi, struct mlx5_wqe_ctrl_seg *cseg, - bool xmit_more) + struct mlx5_wqe_eth_seg *eseg, bool xmit_more) { struct mlx5_wq_cyc *wq = &sq->wq;bool send_doorbell;
@@ -394,11 +394,16 @@ mlx5e_txwqe_complete(struct mlx5e_txqsq *sq, struct sk_buff *skb,mlx5e_tx_check_stop (sq); -if (unlikely (sq->ptpsq)) { +if (unlikely (sq->ptpsq && + (skb_shinfo (skb)->tx_flags &SKBTX_HW_TSTAMP ))) { +u8 metadata_index =be32_to_cpu (eseg->flow_table_metadata); +mlx5e_skb_cb_hwtstamp_init (skb); -mlx5e_skb_fifo_push (&sq->ptpsq->skb_fifo, skb); +mlx5e_ptpsq_track_metadata (sq->ptpsq, metadata_index); +mlx5e_ptp_metadata_map_put (&sq->ptpsq->metadata_map, skb, + metadata_index);if (!netif_tx_queue_stopped (sq->txq) && - !mlx5e_skb_fifo_has_room (&sq->ptpsq->skb_fifo)) { +mlx5e_ptpsq_metadata_freelist_empty (sq->ptpsq)) {netif_tx_stop_queue (sq->txq); sq->stats->stopped++; }
@@ -483,13 +488,16 @@ mlx5e_sq_xmit_wqe(struct mlx5e_txqsq *sq, struct sk_buff *skb,if (unlikely (num_dma <0 )) goto err_drop; -mlx5e_txwqe_complete (sq, skb, attr, wqe_attr, num_dma, wi, cseg, xmit_more); +mlx5e_txwqe_complete (sq, skb, attr, wqe_attr, num_dma, wi, cseg, eseg, xmit_more);return ; err_drop: stats->dropped++;dev_kfree_skb_any (skb); +if (unlikely (sq->ptpsq && (skb_shinfo (skb)->tx_flags &SKBTX_HW_TSTAMP ))) +mlx5e_ptp_metadata_fifo_push (&sq->ptpsq->metadata_freelist, +be32_to_cpu (eseg->flow_table_metadata));mlx5e_tx_flush (sq); }
@@ -645,9 +653,9 @@ void mlx5e_tx_mpwqe_ensure_complete(struct mlx5e_txqsq *sq)static void mlx5e_cqe_ts_id_eseg (struct mlx5e_ptpsq *ptpsq,struct sk_buff *skb,struct mlx5_wqe_eth_seg *eseg) { -if (ptpsq->ts_cqe_ctr_mask &&unlikely (skb_shinfo (skb)->tx_flags &SKBTX_HW_TSTAMP )) - eseg->flow_table_metadata =cpu_to_be32 (ptpsq->skb_fifo_pc & - ptpsq->ts_cqe_ctr_mask); +if (unlikely (skb_shinfo (skb)->tx_flags &SKBTX_HW_TSTAMP )) + eseg->flow_table_metadata = +cpu_to_be32 (mlx5e_ptp_metadata_fifo_pop (&ptpsq->metadata_freelist)); } static void mlx5e_txwqe_build_eseg(struct mlx5e_priv *priv, struct mlx5e_txqsq *sq,
@@ -766,7 +774,7 @@ void mlx5e_txqsq_wake(struct mlx5e_txqsq *sq) {if (netif_tx_queue_stopped (sq->txq) &&mlx5e_wqc_has_room_for (&sq->wq, sq->cc, sq->pc, sq->stop_room) && -mlx5e_ptpsq_fifo_has_room (sq) && + !mlx5e_ptpsq_metadata_freelist_empty (sq->ptpsq) && !test_bit (MLX5E_SQ_STATE_RECOVERING , &sq->state)) {netif_tx_wake_queue (sq->txq); sq->stats->wake++;
@@ -1031,7 +1039,7 @@ void mlx5i_sq_xmit(struct mlx5e_txqsq *sq, struct sk_buff *skb,if (unlikely (num_dma <0 )) goto err_drop; -mlx5e_txwqe_complete (sq, skb, &attr, &wqe_attr, num_dma, wi, cseg, xmit_more); +mlx5e_txwqe_complete (sq, skb, &attr, &wqe_attr, num_dma, wi, cseg, eseg, xmit_more);return ;
Signature · 1 line
2.42.0
Greg Kroah-Hartman
maintainerPATCH 210/491 net/mlx5e: Add recovery flow for tx devlink health reporter for unhealthy PTP SQ
In reply to Greg Kroah-Hartman6.5-stable review patch. If anyone has any objections, please let me know.
------------------
From: Rahul Rameshbabu <[email protected]>
[ Upstream commit 53b836a44db4259b94ffcfff321fb3d63f976b76 ]
A new check for the tx devlink health reporter is introduced for determining when the PTP port timestamping SQ is considered unhealthy. If there are enough CQEs considered never to be delivered, the space that can be utilized on the SQ decreases significantly, impacting performance and usability of the SQ. The health reporter is triggered when the number of likely never delivered port timestamping CQEs that utilize the space of the PTP SQ is greater than 93.75% of the total capacity of the SQ. A devlink health reporter recover method is also provided for this specific TX error context that restarts the PTP SQ.
Stable-dep-of: 92214be5979c ("net/mlx5e: Update doorbell for port timestamping CQ before the software counter")
--- Documentation/networking/devlink/mlx5.rst | 5 +- .../ethernet/mellanox/mlx5/core/en/health.h | 1 + .../net/ethernet/mellanox/mlx5/core/en/ptp.c | 22 +++++++ .../net/ethernet/mellanox/mlx5/core/en/ptp.h | 2 + .../mellanox/mlx5/core/en/reporter_tx.c | 65 +++++++++++++++++++ 5 files changed, 94 insertions(+), 1 deletion(-)
Documentation/networking/devlink/mlx5.rst +4 -1
@@ -135,7 +135,7 @@ Health reporters tx reporter ----------- -The tx reporter is responsible for reporting and recovering of the following two error scenarios: +The tx reporter is responsible for reporting and recovering of the following three error scenarios: - tx timeout Report on kernel tx timeout detection.
@@ -143,6 +143,9 @@ The tx reporter is responsible for reporting and recovering of the following two - tx error completion Report on error tx completion. Recover by flushing the tx queue and reset it. +- tx PTP port timestamping CQ unhealthy + Report too many CQEs never delivered on port ts CQ. + Recover by flushing and re-creating all PTP channels. tx reporter also support on demand diagnose callback, on which it provides real time information of its send queues status.
drivers/net/ethernet/mellanox/mlx5/core/en/health.h +1 -0
@@ -18,6 +18,7 @@ void mlx5e_reporter_tx_create(struct mlx5e_priv *priv);void mlx5e_reporter_tx_destroy (struct mlx5e_priv *priv);void mlx5e_reporter_tx_err_cqe (struct mlx5e_txqsq *sq);int mlx5e_reporter_tx_timeout (struct mlx5e_txqsq *sq); +void mlx5e_reporter_tx_ptpsq_unhealthy (struct mlx5e_ptpsq *ptpsq);int mlx5e_health_cq_diag_fmsg (struct mlx5e_cq *cq,struct devlink_fmsg *fmsg);int mlx5e_health_cq_common_diag_fmsg (struct mlx5e_cq *cq,struct devlink_fmsg *fmsg);
drivers/net/ethernet/mellanox/mlx5/core/en/ptp.c +22 -0
@@ -2,6 +2,7 @@// Copyright (c) 2020 Mellanox Technologies #include "en/ptp.h" +#include "en/health.h" #include "en/txrx.h" #include "en/params.h" #include "en/fs_tt_redirect.h"
@@ -140,6 +141,12 @@ mlx5e_ptp_metadata_map_remove(struct mlx5e_ptp_metadata_map *map, u16 metadata)return skb; } +static bool mlx5e_ptp_metadata_map_unhealthy (struct mlx5e_ptp_metadata_map *map) +{ +/* Considered beginning unhealthy state if size * 15 / 2^4 cannot be reclaimed. */ +return map->undelivered_counter > (map->capacity >>4 ) *15 ; +} +static void mlx5e_ptpsq_mark_ts_cqes_undelivered (struct mlx5e_ptpsq *ptpsq,ktime_t port_tstamp) {
@@ -205,6 +212,9 @@ static void mlx5e_ptp_handle_ts_cqe(struct mlx5e_ptpsq *ptpsq, out:napi_consume_skb (skb, budget);mlx5e_ptp_metadata_fifo_push (&ptpsq->metadata_freelist, metadata_id); +if (unlikely (mlx5e_ptp_metadata_map_unhealthy (&ptpsq->metadata_map)) && + !test_and_set_bit (MLX5E_SQ_STATE_RECOVERING , &sq->state)) +queue_work (ptpsq->txqsq.priv->wq, &ptpsq->report_unhealthy_work); }static bool mlx5e_ptp_poll_ts_cq (struct mlx5e_cq *cq,int budget)
@@ -422,6 +432,14 @@ static void mlx5e_ptp_free_traffic_db(struct mlx5e_ptpsq *ptpsq)kvfree (ptpsq->ts_cqe_pending_list); } +static void mlx5e_ptpsq_unhealthy_work (struct work_struct *work) +{ +struct mlx5e_ptpsq *ptpsq = + container_of(work, struct mlx5e_ptpsq, report_unhealthy_work); + +mlx5e_reporter_tx_ptpsq_unhealthy (ptpsq); +} +static int mlx5e_ptp_open_txqsq (struct mlx5e_ptp *c,u32 tisn,int txq_ix,struct mlx5e_ptp_params *cparams,int tc,struct mlx5e_ptpsq *ptpsq)
@@ -451,6 +469,8 @@ static int mlx5e_ptp_open_txqsq(struct mlx5e_ptp *c, u32 tisn,if (err) goto err_free_txqsq; +INIT_WORK (&ptpsq->report_unhealthy_work, mlx5e_ptpsq_unhealthy_work); +return 0 ; err_free_txqsq:
@@ -464,6 +484,8 @@ static void mlx5e_ptp_close_txqsq(struct mlx5e_ptpsq *ptpsq)struct mlx5e_txqsq *sq = &ptpsq->txqsq;struct mlx5_core_dev *mdev = sq->mdev; +if (current_work () != &ptpsq->report_unhealthy_work) +cancel_work_sync (&ptpsq->report_unhealthy_work);mlx5e_ptp_free_traffic_db (ptpsq);cancel_work_sync (&sq->recover_work);mlx5e_ptp_destroy_sq (mdev, sq->sqn);
drivers/net/ethernet/mellanox/mlx5/core/en/ptp.h +2 -0
@@ -10,6 +10,7 @@#include <linux/ktime.h> #include <linux/ptp_classify.h> #include <linux/time64.h> +#include <linux/workqueue.h> #define MLX5E_PTP_CHANNEL_IX 0#define MLX5E_PTP_MAX_LOG_SQ_SIZE (8U)
@@ -34,6 +35,7 @@ struct mlx5e_ptpsq {struct mlx5e_ptp_cq_stats *cq_stats;u16 ts_cqe_ctr_mask; +struct work_struct report_unhealthy_work;struct mlx5e_ptp_port_ts_cqe_list *ts_cqe_pending_list;struct mlx5e_ptp_metadata_fifo metadata_freelist;struct mlx5e_ptp_metadata_map metadata_map;
drivers/net/ethernet/mellanox/mlx5/core/en/reporter_tx.c +65 -0
83 lines not on this page · raw message
Signature · 1 line
2.42.0
Greg Kroah-Hartman
maintainerPATCH 211/491 net/mlx5e: Update doorbell for port timestamping CQ before the software counter
In reply to Greg Kroah-Hartman6.5-stable review patch. If anyone has any objections, please let me know.
------------------
From: Rahul Rameshbabu <[email protected]>
[ Upstream commit 92214be5979c0961a471b7eaaaeacab41bdf456c ]
Previously, mlx5e_ptp_poll_ts_cq would update the device doorbell with the incremented consumer index after the relevant software counters in the kernel were updated. In the mlx5e_sq_xmit_wqe context, this would lead to either overrunning the device CQ or exceeding the expected software buffer size in the device CQ if the device CQ size was greater than the software buffer size. Update the relevant software counter only after updating the device CQ consumer index in the port timestamping napi_poll context.
Log:
mlx5_core 0000:08:00.0: cq_err_event_notifier:517:(pid 0): CQ error on CQN 0x487, syndrome 0x1
mlx5_core 0000:08:00.0 eth2: mlx5e_cq_error_event: cqn=0x000487 event=0x04--- .../net/ethernet/mellanox/mlx5/core/en/ptp.c | 20 +++++++++++++++---- 1 file changed, 16 insertions(+), 4 deletions(-)
drivers/net/ethernet/mellanox/mlx5/core/en/ptp.c +16 -4
@@ -177,6 +177,8 @@ static void mlx5e_ptpsq_mark_ts_cqes_undelivered(struct mlx5e_ptpsq *ptpsq,static void mlx5e_ptp_handle_ts_cqe (struct mlx5e_ptpsq *ptpsq,struct mlx5_cqe64 *cqe, +u8 *md_buff, +u8 *md_buff_sz,int budget) {struct mlx5e_ptp_port_ts_cqe_list *pending_cqe_list = ptpsq->ts_cqe_pending_list;
@@ -211,19 +213,24 @@ static void mlx5e_ptp_handle_ts_cqe(struct mlx5e_ptpsq *ptpsq,mlx5e_ptpsq_mark_ts_cqes_undelivered (ptpsq, hwtstamp); out:napi_consume_skb (skb, budget); -mlx5e_ptp_metadata_fifo_push (&ptpsq->metadata_freelist, metadata_id); + md_buff[*md_buff_sz++] = metadata_id;if (unlikely (mlx5e_ptp_metadata_map_unhealthy (&ptpsq->metadata_map)) && !test_and_set_bit (MLX5E_SQ_STATE_RECOVERING , &sq->state))queue_work (ptpsq->txqsq.priv->wq, &ptpsq->report_unhealthy_work); } -static bool mlx5e_ptp_poll_ts_cq (struct mlx5e_cq *cq,int budget) +static bool mlx5e_ptp_poll_ts_cq (struct mlx5e_cq *cq,int napi_budget) { struct mlx5e_ptpsq *ptpsq = container_of(cq, struct mlx5e_ptpsq, ts_cq); -struct mlx5_cqwq *cqwq = &cq->wq; +int budget =min (napi_budget,MLX5E_TX_CQ_POLL_BUDGET ); +u8 metadata_buff[MLX5E_TX_CQ_POLL_BUDGET ]; +u8 metadata_buff_sz =0 ; +struct mlx5_cqwq *cqwq;struct mlx5_cqe64 *cqe;int work_done =0 ; + cqwq = &cq->wq; +if (unlikely (!test_bit (MLX5E_SQ_STATE_ENABLED , &ptpsq->txqsq.state)))return false;
@@ -234,7 +241,8 @@ static bool mlx5e_ptp_poll_ts_cq(struct mlx5e_cq *cq, int budget)do {mlx5_cqwq_pop (cqwq); -mlx5e_ptp_handle_ts_cqe (ptpsq, cqe, budget); +mlx5e_ptp_handle_ts_cqe (ptpsq, cqe, + metadata_buff, &metadata_buff_sz, napi_budget); }while ((++work_done < budget) && (cqe =mlx5_cqwq_get_cqe (cqwq)));mlx5_cqwq_update_db_record (cqwq);
@@ -242,6 +250,10 @@ static bool mlx5e_ptp_poll_ts_cq(struct mlx5e_cq *cq, int budget)/* ensure cq space is freed before enabling more cqes */ wmb (); +while (metadata_buff_sz >0 ) +mlx5e_ptp_metadata_fifo_push (&ptpsq->metadata_freelist, + metadata_buff[--metadata_buff_sz]); +mlx5e_txqsq_wake (&ptpsq->txqsq);return work_done == budget;
Signature · 1 line
2.42.0
Greg Kroah-Hartman
maintainerPATCH 212/491 net/mlx5: Increase size of irq name buffer
In reply to Greg Kroah-Hartman6.5-stable review patch. If anyone has any objections, please let me know.
------------------
From: Rahul Rameshbabu <[email protected]>
[ Upstream commit 3338bebfc26a1e2cebbba82a1cf12c0159608e73 ]
Without increased buffer size, will trigger -Wformat-truncation with W=1 for the snprintf operation writing to the buffer.
drivers/net/ethernet/mellanox/mlx5/core/pci_irq.c: In function 'mlx5_irq_alloc':
drivers/net/ethernet/mellanox/mlx5/core/pci_irq.c:296:7: error: '@pci:' directive output may be truncated writing 5 bytes into a region of size between 1 and 32 [-Werror=format-truncation=]
296 | "%s@pci:%s", name, pci_name(dev->pdev));
| ^~~~~
drivers/net/ethernet/mellanox/mlx5/core/pci_irq.c:295:2: note: 'snprintf' output 6 or more bytes (assuming 37) into a destination of size 32
295 | snprintf(irq->name, MLX5_MAX_IRQ_NAME,
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
296 | "%s@pci:%s", name, pci_name(dev->pdev));
| ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~--- drivers/net/ethernet/mellanox/mlx5/core/pci_irq.c | 6 +++--- drivers/net/ethernet/mellanox/mlx5/core/pci_irq.h | 3 +++ 2 files changed, 6 insertions(+), 3 deletions(-)
drivers/net/ethernet/mellanox/mlx5/core/pci_irq.c +3 -3
@@ -28,7 +28,7 @@struct mlx5_irq {struct atomic_notifier_head nh;cpumask_var_t mask; -char name[MLX5_MAX_IRQ_NAME ]; +char name[MLX5_MAX_IRQ_FORMATTED_NAME ];struct mlx5_irq_pool *pool;int refcount;struct msi_map map;
@@ -289,8 +289,8 @@ struct mlx5_irq *mlx5_irq_alloc(struct mlx5_irq_pool *pool, int i,else irq_sf_set_name (pool, name, i);ATOMIC_INIT_NOTIFIER_HEAD (&irq->nh); -snprintf (irq->name,MLX5_MAX_IRQ_NAME , -"%s@pci:%s" , name,pci_name (dev->pdev)); +snprintf (irq->name,MLX5_MAX_IRQ_FORMATTED_NAME , +MLX5_IRQ_NAME_FORMAT_STR , name,pci_name (dev->pdev)); err =request_irq (irq->map.virq, irq_int_handler,0 , irq->name, &irq->nh);if (err) {
drivers/net/ethernet/mellanox/mlx5/core/pci_irq.h +3 -0
@@ -7,6 +7,9 @@#include <linux/mlx5/driver.h> #define MLX5_MAX_IRQ_NAME (32) +#define MLX5_IRQ_NAME_FORMAT_STR ("%s@pci:%s") +#define MLX5_MAX_IRQ_FORMATTED_NAME \ + (MLX5_MAX_IRQ_NAME + sizeof(MLX5_IRQ_NAME_FORMAT_STR))/* max irq_index is 2047, so four chars */ #define MLX5_MAX_IRQ_IDX_CHARS (4)#define MLX5_EQ_REFS_PER_IRQ (2)
Signature · 1 line
2.42.0
Greg Kroah-Hartman
maintainerPATCH 213/491 net/mlx5e: Reduce the size of icosq_str
In reply to Greg Kroah-Hartman6.5-stable review patch. If anyone has any objections, please let me know.
------------------
From: Saeed Mahameed <[email protected]>
[ Upstream commit dce94142842e119b982c27c1b62bd20890c7fd21 ]
icosq_str size is unnecessarily too long, and it causes a build warning -Wformat-truncation with W=1. Looking closely, It doesn't need to be 255B, hence this patch reduces the size to 32B which should be more than enough to host the string: "ICOSQ: 0x%x, ".
While here, add a missing space in the formatted string.
This fixes the following build warning:
$ KCFLAGS='-Wall -Werror' $ make O=/tmp/kbuild/linux W=1 -s -j12 drivers/net/ethernet/mellanox/mlx5/core/
drivers/net/ethernet/mellanox/mlx5/core/en/reporter_rx.c: In function 'mlx5e_reporter_rx_timeout':drivers/net/ethernet/mellanox/mlx5/core/en/reporter_rx.c:718:56:
error: ', CQ: 0x' directive output may be truncated writing 8 bytes into a region of size between 0 and 255 [-Werror=format-truncation=]
718 | "RX timeout on channel: %d, %sRQ: 0x%x, CQ: 0x%x",
| ^~~~~~~~drivers/net/ethernet/mellanox/mlx5/core/en/reporter_rx.c:717:9: note: 'snprintf' output between 43 and 322 bytes into a destination of size 288
717 | snprintf(err_str, sizeof(err_str),
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
718 | "RX timeout on channel: %d, %sRQ: 0x%x, CQ: 0x%x",
| ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
719 | rq->ix, icosq_str, rq->rqn, rq->cq.mcq.cqn);
| ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~--- drivers/net/ethernet/mellanox/mlx5/core/en/reporter_rx.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
drivers/net/ethernet/mellanox/mlx5/core/en/reporter_rx.c +2 -2
@@ -702,11 +702,11 @@ static int mlx5e_rx_reporter_dump(struct devlink_health_reporter *reporter,void mlx5e_reporter_rx_timeout (struct mlx5e_rq *rq) { -char icosq_str[MLX5E_REPORTER_PER_Q_MAX_LEN ] = {};char err_str[MLX5E_REPORTER_PER_Q_MAX_LEN ];struct mlx5e_icosq *icosq = rq->icosq;struct mlx5e_priv *priv = rq->priv;struct mlx5e_err_ctx err_ctx = {}; +char icosq_str[32 ] = {}; err_ctx.ctx = rq; err_ctx.recover = mlx5e_rx_reporter_timeout_recover;
@@ -715,7 +715,7 @@ void mlx5e_reporter_rx_timeout(struct mlx5e_rq *rq)if (icosq)snprintf (icosq_str,sizeof (icosq_str),"ICOSQ: 0x%x, " , icosq->sqn);snprintf (err_str,sizeof (err_str), -"RX timeout on channel: %d, %sRQ: 0x%x, CQ: 0x%x" , +"RX timeout on channel: %d, %s RQ: 0x%x, CQ: 0x%x" , rq->ix, icosq_str, rq->rqn, rq->cq.mcq.cqn);mlx5e_health_report (priv, priv->rx_reporter, err_str, &err_ctx);
Signature · 1 line
2.42.0
Greg Kroah-Hartman
maintainerPATCH 214/491 net/mlx5e: Check return value of snprintf writing to fw_version buffer
In reply to Greg Kroah-Hartman6.5-stable review patch. If anyone has any objections, please let me know.
------------------
From: Rahul Rameshbabu <[email protected]>
[ Upstream commit 41e63c2baa11dc2aa71df5dd27a5bd87d11b6bbb ]
Treat the operation as an error case when the return value is equivalent to the size of the name buffer. Failed to write null terminator to the name buffer, making the string malformed and should not be used. Provide a string with only the firmware version when forming the string with the board id fails.
Without check, will trigger -Wformat-truncation with W=1.
drivers/net/ethernet/mellanox/mlx5/core/en_ethtool.c: In function 'mlx5e_ethtool_get_drvinfo':
drivers/net/ethernet/mellanox/mlx5/core/en_ethtool.c:49:31: warning: '%.16s' directive output may be truncated writing up to 16 bytes into a region of size between 13 and 22 [-Wformat-truncation=]
49 | "%d.%d.%04d (%.16s)",
| ^~~~~
drivers/net/ethernet/mellanox/mlx5/core/en_ethtool.c:48:9: note: 'snprintf' output between 12 and 37 bytes into a destination of size 32
48 | snprintf(drvinfo->fw_version, sizeof(drvinfo->fw_version),
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
49 | "%d.%d.%04d (%.16s)",
| ~~~~~~~~~~~~~~~~~~~~~
50 | fw_rev_maj(mdev), fw_rev_min(mdev), fw_rev_sub(mdev),
| ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
51 | mdev->board_id);
| ~~~~~~~~~~~~~~~--- .../net/ethernet/mellanox/mlx5/core/en_ethtool.c | 13 +++++++++---- 1 file changed, 9 insertions(+), 4 deletions(-)
drivers/net/ethernet/mellanox/mlx5/core/en_ethtool.c +9 -4
@@ -43,12 +43,17 @@ void mlx5e_ethtool_get_drvinfo(struct mlx5e_priv *priv, struct ethtool_drvinfo *drvinfo) {struct mlx5_core_dev *mdev = priv->mdev; +int count;strscpy (drvinfo->driver,KBUILD_MODNAME ,sizeof (drvinfo->driver)); -snprintf (drvinfo->fw_version,sizeof (drvinfo->fw_version), -"%d.%d.%04d (%.16s)" , -fw_rev_maj (mdev),fw_rev_min (mdev),fw_rev_sub (mdev), - mdev->board_id); + count =snprintf (drvinfo->fw_version,sizeof (drvinfo->fw_version), +"%d.%d.%04d (%.16s)" ,fw_rev_maj (mdev), +fw_rev_min (mdev),fw_rev_sub (mdev), mdev->board_id); +if (count ==sizeof (drvinfo->fw_version)) +snprintf (drvinfo->fw_version,sizeof (drvinfo->fw_version), +"%d.%d.%04d" ,fw_rev_maj (mdev), +fw_rev_min (mdev),fw_rev_sub (mdev)); +strscpy (drvinfo->bus_info,dev_name (mdev->device),sizeof (drvinfo->bus_info)); }
Signature · 1 line
2.42.0
Greg Kroah-Hartman
maintainerPATCH 215/491 net/mlx5e: Check return value of snprintf writing to fw_version buffer for representors
In reply to Greg Kroah-Hartman6.5-stable review patch. If anyone has any objections, please let me know.
------------------
From: Rahul Rameshbabu <[email protected]>
[ Upstream commit 1b2bd0c0264febcd8d47209079a6671c38e6558b ]
Treat the operation as an error case when the return value is equivalent to the size of the name buffer. Failed to write null terminator to the name buffer, making the string malformed and should not be used. Provide a string with only the firmware version when forming the string with the board id fails. This logic for representors is identical to normal flow with ethtool.
Without check, will trigger -Wformat-truncation with W=1.
drivers/net/ethernet/mellanox/mlx5/core/en_rep.c: In function 'mlx5e_rep_get_drvinfo':
drivers/net/ethernet/mellanox/mlx5/core/en_rep.c:78:31: warning: '%.16s' directive output may be truncated writing up to 16 bytes into a region of size between 13 and 22 [-Wformat-truncation=]
78 | "%d.%d.%04d (%.16s)",
| ^~~~~
drivers/net/ethernet/mellanox/mlx5/core/en_rep.c:77:9: note: 'snprintf' output between 12 and 37 bytes into a destination of size 32
77 | snprintf(drvinfo->fw_version, sizeof(drvinfo->fw_version),
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
78 | "%d.%d.%04d (%.16s)",
| ~~~~~~~~~~~~~~~~~~~~~
79 | fw_rev_maj(mdev), fw_rev_min(mdev),
| ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
80 | fw_rev_sub(mdev), mdev->board_id);
| ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~--- drivers/net/ethernet/mellanox/mlx5/core/en_rep.c | 12 ++++++++---- 1 file changed, 8 insertions(+), 4 deletions(-)
drivers/net/ethernet/mellanox/mlx5/core/en_rep.c +8 -4
@@ -71,13 +71,17 @@ static void mlx5e_rep_get_drvinfo(struct net_device *dev, {struct mlx5e_priv *priv =netdev_priv (dev);struct mlx5_core_dev *mdev = priv->mdev; +int count;strscpy (drvinfo->driver, mlx5e_rep_driver_name,sizeof (drvinfo->driver)); -snprintf (drvinfo->fw_version,sizeof (drvinfo->fw_version), -"%d.%d.%04d (%.16s)" , -fw_rev_maj (mdev),fw_rev_min (mdev), -fw_rev_sub (mdev), mdev->board_id); + count =snprintf (drvinfo->fw_version,sizeof (drvinfo->fw_version), +"%d.%d.%04d (%.16s)" ,fw_rev_maj (mdev), +fw_rev_min (mdev),fw_rev_sub (mdev), mdev->board_id); +if (count ==sizeof (drvinfo->fw_version)) +snprintf (drvinfo->fw_version,sizeof (drvinfo->fw_version), +"%d.%d.%04d" ,fw_rev_maj (mdev), +fw_rev_min (mdev),fw_rev_sub (mdev)); }static const struct counter_desc sw_rep_stats_desc[] = {
Signature · 1 line
2.42.0
Greg Kroah-Hartman
maintainerPATCH 216/491 net: sched: do not offload flows with a helper in act_ct
In reply to Greg Kroah-Hartman6.5-stable review patch. If anyone has any objections, please let me know.
------------------
From: Xin Long <[email protected]>
[ Upstream commit 7cd5af0e937a197295f3aa3721031f0fbae49cff ]
There is no hardware supporting ct helper offload. However, prior to this patch, a flower filter with a helper in the ct action can be successfully set into the HW, for example (eth1 is a bnxt NIC):
# tc qdisc add dev eth1 ingress_block 22 ingress
# tc filter add block 22 proto ip flower skip_sw ip_proto tcp \
dst_port 21 ct_state -trk action ct helper ipv4-tcp-ftp
# tc filter show dev eth1 ingress filter block 22 protocol ip pref 49152 flower chain 0 handle 0x1
eth_type ipv4
ip_proto tcp
dst_port 21
ct_state -trk
skip_sw
in_hw in_hw_count 1 <----
action order 1: ct zone 0 helper ipv4-tcp-ftp pipe
index 2 ref 1 bind 1
used_hw_stats delayedThis might cause the flower filter not to work as expected in the HW.
This patch avoids this problem by simply returning -EOPNOTSUPP in tcf_ct_offload_act_setup() to not allow to offload flows with a helper in act_ct.
--- include/net/tc_act/tc_ct.h | 9 +++++++++ net/sched/act_ct.c | 3 +++ 2 files changed, 12 insertions(+)
include/net/tc_act/tc_ct.h +9 -0
@@ -57,6 +57,11 @@ static inline struct nf_flowtable *tcf_ct_ft(const struct tc_action *a) return to_ct_params(a)->nf_ft; } +static inline struct nf_conntrack_helper *tcf_ct_helper (const struct tc_action *a) +{ +return to_ct_params (a)->helper; +} +#else static inline uint16_t tcf_ct_zone (const struct tc_action *a) {return 0 ; }static inline int tcf_ct_action (const struct tc_action *a) {return 0 ; }
@@ -64,6 +69,10 @@ static inline struct nf_flowtable *tcf_ct_ft(const struct tc_action *a) {return NULL ; } +static inline struct nf_conntrack_helper *tcf_ct_helper (const struct tc_action *a) +{ +return NULL ; +}#endif /* CONFIG_NF_CONNTRACK */ #if IS_ENABLED (CONFIG_NET_ACT_CT )
net/sched/act_ct.c +3 -0
@@ -1534,6 +1534,9 @@ static int tcf_ct_offload_act_setup(struct tc_action *act, void *entry_data,if (bind) {struct flow_action_entry *entry = entry_data; +if (tcf_ct_helper (act)) +return -EOPNOTSUPP ; + entry->id =FLOW_ACTION_CT ; entry->ct.action =tcf_ct_action (act); entry->ct.zone =tcf_ct_zone (act);
Signature · 1 line
2.42.0
Greg Kroah-Hartman
maintainerPATCH 217/491 macvlan: Dont propagate promisc change to lower dev in passthru
In reply to Greg Kroah-Hartman6.5-stable review patch. If anyone has any objections, please let me know.
------------------
From: Vlad Buslov <[email protected]>
[ Upstream commit 7e1caeace0418381f36b3aa8403dfd82fc57fc53 ]
Macvlan device in passthru mode sets its lower device promiscuous mode according to its MACVLAN_FLAG_NOPROMISC flag instead of synchronizing it to its own promiscuity setting. However, macvlan_change_rx_flags() function doesn't check the mode before propagating such changes to the lower device which can cause net_device->promiscuity counter overflow as illustrated by reproduction example [0] and resulting dmesg log [1]. Fix the issue by first verifying the mode in macvlan_change_rx_flags() function before propagating promiscuous mode change to the lower device.
[0]:
ip link add macvlan1 link enp8s0f0 type macvlan mode passthru ip link set macvlan1 promisc on
ip l set dev macvlan1 up
ip link set macvlan1 promisc off
ip l set dev macvlan1 down
ip l set dev macvlan1 up
[1]:
[ 5156.281724] macvlan1: entered promiscuous mode [ 5156.285467] mlx5_core 0000:08:00.0 enp8s0f0: entered promiscuous mode [ 5156.287639] macvlan1: left promiscuous mode [ 5156.288339] mlx5_core 0000:08:00.0 enp8s0f0: left promiscuous mode [ 5156.290907] mlx5_core 0000:08:00.0 enp8s0f0: entered promiscuous mode [ 5156.317197] mlx5_core 0000:08:00.0 enp8s0f0: promiscuity touches roof, set promiscuity failed. promiscuity feature of device might be broken.
--- drivers/net/macvlan.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/net/macvlan.c +1 -1
@@ -780,7 +780,7 @@ static void macvlan_change_rx_flags(struct net_device *dev, int change)if (dev->flags &IFF_UP ) {if (change &IFF_ALLMULTI )dev_set_allmulti (lowerdev, dev->flags &IFF_ALLMULTI ?1 :-1 ); -if (change &IFF_PROMISC ) +if (!macvlan_passthru (vlan->port) && change &IFF_PROMISC )dev_set_promiscuity (lowerdev, dev->flags &IFF_PROMISC ?1 :-1 );
Signature · 1 line
2.42.0
Greg Kroah-Hartman
maintainerPATCH 218/491 tools/power/turbostat: Fix a knl bug
In reply to Greg Kroah-Hartman6.5-stable review patch. If anyone has any objections, please let me know.
------------------
From: Zhang Rui <[email protected]>
[ Upstream commit 137f01b3529d292a68d22e9681e2f903c768f790 ]
MSR_KNL_CORE_C6_RESIDENCY should be evaluated only if
1. this is KNL platform
AND
2. need to get C6 residency or need to calculate C1 residency
Fix the broken logic introduced by commit 1e9042b9c8d4 ("tools/power
turbostat: Fix CPU%C1 display value").
--- tools/power/x86/turbostat/turbostat.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
tools/power/x86/turbostat/turbostat.c +1 -1
@@ -2180,7 +2180,7 @@ int get_counters(struct thread_data *t, struct core_data *c, struct pkg_data *p)if ((DO_BIC (BIC_CPU_c6) ||soft_c1_residency_display (BIC_CPU_c6)) && !do_knl_cstates) {if (get_msr (cpu,MSR_CORE_C6_RESIDENCY , &c->c6))return -7 ; - }else if (do_knl_cstates ||soft_c1_residency_display (BIC_CPU_c6)) { + }else if (do_knl_cstates &&soft_c1_residency_display (BIC_CPU_c6)) {if (get_msr (cpu,MSR_KNL_CORE_C6_RESIDENCY , &c->c6))return -7 ; }
Signature · 1 line
2.42.0
Greg Kroah-Hartman
maintainerPATCH 219/491 tools/power/turbostat: Enable the C-state Pre-wake printing
In reply to Greg Kroah-Hartman6.5-stable review patch. If anyone has any objections, please let me know.
------------------
From: Chen Yu <[email protected]>
[ Upstream commit b61b7d8c4c22c4298a50ae5d0ee88facb85ce665 ]
Currently the C-state Pre-wake will not be printed due to the probe has not been invoked. Invoke the probe function accordingly.
--- tools/power/x86/turbostat/turbostat.c | 1 + 1 file changed, 1 insertion(+)
tools/power/x86/turbostat/turbostat.c +1 -0
@@ -5790,6 +5790,7 @@ void process_cpuid()rapl_probe (family, model);perf_limit_reasons_probe (family, model);automatic_cstate_conversion_probe (family, model); +prewake_cstate_probe (family, model);check_tcc_offset (model_orig);
Signature · 1 line
2.42.0
Greg Kroah-Hartman
maintainerPATCH 220/491 scsi: ufs: core: Expand MCQ queue slot to DeviceQueueDepth + 1
In reply to Greg Kroah-Hartman6.5-stable review patch. If anyone has any objections, please let me know.
------------------
From: Naomi Chu <[email protected]>
[ Upstream commit defde5a50d91c74e1ce71a7f0bce7fb1ae311d84 ]
The UFSHCI 4.0 specification mandates that there should always be at least one empty slot in each queue for distinguishing between full and empty states. Enlarge 'hwq->max_entries' to 'DeviceQueueDepth + 1' to allow UFSHCI 4.0 controllers to fully utilize MCQ queue slots.
--- drivers/ufs/core/ufs-mcq.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/ufs/core/ufs-mcq.c +1 -1
@@ -433,7 +433,7 @@ int ufshcd_mcq_init(struct ufs_hba *hba)for (i =0 ; i < hba->nr_hw_queues; i++) { hwq = &hba->uhq[i]; - hwq->max_entries = hba->nutrs; + hwq->max_entries = hba->nutrs +1 ;spin_lock_init (&hwq->sq_lock);spin_lock_init (&hwq->cq_lock);mutex_init (&hwq->sq_mutex);
Signature · 1 line
2.42.0
Greg Kroah-Hartman
maintainerPATCH 221/491 cifs: spnego: add ; in HOST_KEY_LEN
In reply to Greg Kroah-Hartman6.5-stable review patch. If anyone has any objections, please let me know.
------------------
From: Anastasia Belova <[email protected]>
[ Upstream commit ff31ba19d732efb9aca3633935d71085e68d5076 ]
"host=" should start with ';' (as in cifs_get_spnego_key) So its length should be 6.
Found by Linux Verification Center (linuxtesting.org) with SVACE.
--- fs/smb/client/cifs_spnego.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
fs/smb/client/cifs_spnego.c +2 -2
@@ -64,8 +64,8 @@ struct key_type cifs_spnego_key_type = {* strlen(";sec=ntlmsspi") */ #define MAX_MECH_STR_LEN 13 -/* strlen of "host=" */ -#define HOST_KEY_LEN 5 +/* strlen of ";host=" */ +#define HOST_KEY_LEN 6/* strlen of ";ip4=" or ";ip6=" */ #define IP_KEY_LEN 5
Signature · 1 line
2.42.0
Greg Kroah-Hartman
maintainerPATCH 222/491 cifs: fix check of rc in function generate_smb3signingkey
In reply to Greg Kroah-Hartman6.5-stable review patch. If anyone has any objections, please let me know.
------------------
From: Ekaterina Esina <[email protected]>
[ Upstream commit 181724fc72486dec2bec8803459be05b5162aaa8 ]
Remove extra check after condition, add check after generating key for encryption. The check is needed to return non zero rc before rewriting it with generating key for decryption.
Found by Linux Verification Center (linuxtesting.org) with SVACE.
--- fs/smb/client/smb2transport.c | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-)
fs/smb/client/smb2transport.c +2 -3
@@ -452,6 +452,8 @@ generate_smb3signingkey(struct cifs_ses *ses, ptriplet->encryption.context, ses->smb3encryptionkey, SMB3_ENC_DEC_KEY_SIZE); +if (rc) +return rc; rc = generate_key(ses, ptriplet->decryption.label, ptriplet->decryption.context, ses->smb3decryptionkey,
@@ -460,9 +462,6 @@ generate_smb3signingkey(struct cifs_ses *ses,return rc; } -if (rc) -return rc; -#ifdef CONFIG_CIFS_DEBUG_DUMP_KEYS cifs_dbg (VFS ,"%s: dumping generated AES session keys\n" , __func__);/*
Signature · 1 line
2.42.0
Greg Kroah-Hartman
maintainerPATCH 223/491 perf/core: Fix cpuctx refcounting
In reply to Greg Kroah-Hartman6.5-stable review patch. If anyone has any objections, please let me know.
------------------
From: Peter Zijlstra <[email protected]>
commit 889c58b3155ff4c8e8671c95daef63d6fabbb6b1 upstream.
Audit of the refcounting turned up that perf_pmu_migrate_context() fails to migrate the ctx refcount.
--- include/linux/perf_event.h | 13 ++++++++----- kernel/events/core.c | 17 +++++++++++++++++ 2 files changed, 25 insertions(+), 5 deletions(-)
include/linux/perf_event.h +8 -5
@@ -843,11 +843,11 @@ struct perf_event { };/* -* ,-----------------------[1:n]----------------------. -* V V -* perf_event_context <-[1:n]-> perf_event_pmu_context <--- perf_event -* ^ ^ | | -* `--------[1:n]---------' `-[n:1]-> pmu <-[1:n]-' +* ,-----------------------[1:n]------------------------. +* V V +* perf_event_context <-[1:n]-> perf_event_pmu_context <-[1:n]- perf_event +* | | +* `--[n:1]-> pmu <-[1:n]--' * * * struct perf_event_pmu_context lifetime is refcount based and RCU freed
@@ -865,6 +865,9 @@ struct perf_event {* ctx->mutex pinning the configuration. Since we hold a reference on * group_leader (through the filedesc) it can't go away, therefore it's * associated pmu_ctx must exist and cannot change due to ctx->mutex. +* +* perf_event holds a refcount on perf_event_context +* perf_event holds a refcount on perf_event_pmu_context */ struct perf_event_pmu_context {struct pmu *pmu;
kernel/events/core.c +17 -0
@@ -4816,6 +4816,11 @@ find_get_pmu_context(struct pmu *pmu, stvoid *task_ctx_data =NULL ;if (!ctx->task) { +/* +* perf_pmu_migrate_context() / __perf_pmu_install_event() +* relies on the fact that find_get_pmu_context() cannot fail +* for CPU contexts. +*/ struct perf_cpu_pmu_context *cpc; cpc =per_cpu_ptr (pmu->cpu_pmu_context, event->cpu);
@@ -12888,6 +12893,9 @@ static void __perf_pmu_install_event(str int cpu, struct perf_event *event) { struct perf_event_pmu_context *epc; +struct perf_event_context *old_ctx = event->ctx; + +get_ctx (ctx);/* normally find_get_context() */ event->cpu = cpu; epc =find_get_pmu_context (pmu, ctx, event);
@@ -12896,6 +12904,11 @@ static void __perf_pmu_install_event(strif (event->state >=PERF_EVENT_STATE_OFF ) event->state =PERF_EVENT_STATE_INACTIVE ;perf_install_in_context (ctx, event, cpu); + +/* +* Now that event->ctx is updated and visible, put the old ctx. +*/ +put_ctx (old_ctx); } static void __perf_pmu_install(struct perf_event_context *ctx,
@@ -12934,6 +12947,10 @@ void perf_pmu_migrate_context(struct pmustruct perf_event_context *src_ctx, *dst_ctx;LIST_HEAD (events); +/* +* Since per-cpu context is persistent, no need to grab an extra +* reference. +*/ src_ctx = &per_cpu_ptr (&perf_cpu_context, src_cpu)->ctx; dst_ctx = &per_cpu_ptr (&perf_cpu_context, dst_cpu)->ctx;
Greg Kroah-Hartman
maintainerPATCH 224/491 i915/perf: Fix NULL deref bugs with drm_dbg() calls
In reply to Greg Kroah-Hartman6.5-stable review patch. If anyone has any objections, please let me know.
------------------
From: Harshit Mogalapalli <[email protected]>
commit 471aa951bf1206d3c10d0daa67005b8e4db4ff83 upstream.
When i915 perf interface is not available dereferencing it will lead to NULL dereferences.
As returning -ENOTSUPP is pretty clear return when perf interface is not available.
--- drivers/gpu/drm/i915/i915_perf.c | 15 +++------------ 1 file changed, 3 insertions(+), 12 deletions(-)
drivers/gpu/drm/i915/i915_perf.c +3 -12
@@ -4286,11 +4286,8 @@ int i915_perf_open_ioctl(struct drm_deviu32 known_open_flags;int ret; -if (!perf->i915) { -drm_dbg (&perf->i915->drm, -"i915 perf interface not available for this system\n" ); +if (!perf->i915)return -ENOTSUPP ; - } known_open_flags =I915_PERF_FLAG_FD_CLOEXEC | I915_PERF_FLAG_FD_NONBLOCK |
@@ -4666,11 +4663,8 @@ int i915_perf_add_config_ioctl(struct drstruct i915_oa_reg *regs;int err, id; -if (!perf->i915) { -drm_dbg (&perf->i915->drm, -"i915 perf interface not available for this system\n" ); +if (!perf->i915)return -ENOTSUPP ; - }if (!perf->metrics_kobj) { drm_dbg(&perf->i915->drm,
@@ -4832,11 +4826,8 @@ int i915_perf_remove_config_ioctl(structstruct i915_oa_config *oa_config;int ret; -if (!perf->i915) { -drm_dbg (&perf->i915->drm, -"i915 perf interface not available for this system\n" ); +if (!perf->i915)return -ENOTSUPP ; - }if (i915_perf_stream_paranoid && !perfmon_capable ()) { drm_dbg(&perf->i915->drm,
Greg Kroah-Hartman
maintainerPATCH 225/491 perf: arm_cspmu: Reject events meant for other PMUs
In reply to Greg Kroah-Hartman6.5-stable review patch. If anyone has any objections, please let me know.
------------------
From: Ilkka Koskinen <[email protected]>
commit 15c7ef7341a2e54cfa12ac502c65d6fd2cce2b62 upstream.
Coresight PMU driver didn't reject events meant for other PMUs. This caused some of the Core PMU events disappearing from the output of "perf list". In addition, trying to run e.g.
$ perf stat -e r2 sleep 1
made Coresight PMU driver to handle the event instead of letting Core PMU driver to deal with it.
--- drivers/perf/arm_cspmu/arm_cspmu.c | 3 +++ 1 file changed, 3 insertions(+)
drivers/perf/arm_cspmu/arm_cspmu.c +3 -0
@@ -635,6 +635,9 @@ static int arm_cspmu_event_init(struct p cspmu =to_arm_cspmu (event->pmu); +if (event->attr.type != event->pmu->type) +return -ENOENT ; +/* * Following other "uncore" PMUs, we do not support sampling mode or * attach to a task (per-process mode).
Greg Kroah-Hartman
maintainerPATCH 226/491 drivers: perf: Check find_first_bit() return value
In reply to Greg Kroah-Hartman6.5-stable review patch. If anyone has any objections, please let me know.
------------------
From: Alexandre Ghiti <[email protected]>
commit c6e316ac05532febb0c966fa9b55f5258ed037be upstream.
We must check the return value of find_first_bit() before using the return value as an index array since it happens to overflow the array and then panic:
[ 107.318430] Kernel BUG [#1] [ 107.319434] CPU: 3 PID: 1238 Comm: kill Tainted: G E 6.6.0-rc6ubuntu-defconfig #2 [ 107.319465] Hardware name: riscv-virtio,qemu (DT) [ 107.319551] epc : pmu_sbi_ovf_handler+0x3a4/0x3ae [ 107.319840] ra : pmu_sbi_ovf_handler+0x52/0x3ae [ 107.319868] epc : ffffffff80a0a77c ra : ffffffff80a0a42a sp : ffffaf83fecda350 [ 107.319884] gp : ffffffff823961a8 tp : ffffaf8083db1dc0 t0 : ffffaf83fecda480 [ 107.319899] t1 : ffffffff80cafe62 t2 : 000000000000ff00 s0 : ffffaf83fecda520 [ 107.319921] s1 : ffffaf83fecda380 a0 : 00000018fca29df0 a1 : ffffffffffffffff [ 107.319936] a2 : 0000000001073734 a3 : 0000000000000004 a4 : 0000000000000000 [ 107.319951] a5 : 0000000000000040 a6 : 000000001d1c8774 a7 : 0000000000504d55 [ 107.319965] s2 : ffffffff82451f10 s3 : ffffffff82724e70 s4 : 000000000000003f [ 107.319980] s5 : 0000000000000011 s6 : ffffaf8083db27c0 s7 : 0000000000000000 [ 107.319995] s8 : 0000000000000001 s9 : 00007fffb45d6558 s10: 00007fffb45d81a0 [ 107.320009] s11: ffffaf7ffff60000 t3 : 0000000000000004 t4 : 0000000000000000 [ 107.320023] t5 : ffffaf7f80000000 t6 : ffffaf8000000000 [ 107.320037] status: 0000000200000100 badaddr: 0000000000000000 cause: 0000000000000003 [ 107.320081] [<ffffffff80a0a77c>] pmu_sbi_ovf_handler+0x3a4/0x3ae [ 107.320112] [<ffffffff800b42d0>] handle_percpu_devid_irq+0x9e/0x1a0 [ 107.320131] [<ffffffff800ad92c>] generic_handle_domain_irq+0x28/0x36 [ 107.320148] [<ffffffff8065f9f8>] riscv_intc_irq+0x36/0x4e [ 107.320166] [<ffffffff80caf4a0>] handle_riscv_irq+0x54/0x86 [ 107.320189] [<ffffffff80cb0036>] do_irq+0x64/0x96 [ 107.320271] Code: 85a6 855e b097 ff7f 80e7 9220 b709 9002 4501 bbd9 (9002) 6097 [ 107.320585] ---[ end trace 0000000000000000 ]--- [ 107.320704] Kernel panic - not syncing: Fatal exception in interrupt [ 107.320775] SMP: stopping secondary CPUs [ 107.321219] Kernel Offset: 0x0 from 0xffffffff80000000 [ 107.333051] ---[ end Kernel panic - not syncing: Fatal exception in interrupt ]---
--- drivers/perf/riscv_pmu_sbi.c | 5 +++++ 1 file changed, 5 insertions(+)
drivers/perf/riscv_pmu_sbi.c +5 -0
@@ -629,6 +629,11 @@ static irqreturn_t pmu_sbi_ovf_handler(i/* Firmware counter don't support overflow yet */ fidx =find_first_bit (cpu_hw_evt->used_hw_ctrs,RISCV_MAX_COUNTERS ); +if (fidx ==RISCV_MAX_COUNTERS ) { +csr_clear (CSR_SIP ,BIT (riscv_pmu_irq_num)); +return IRQ_NONE ; + } + event = cpu_hw_evt->events[fidx];if (!event) {csr_clear (CSR_SIP ,BIT (riscv_pmu_irq_num));
Greg Kroah-Hartman
maintainerPATCH 227/491 media: venus: hfi: add checks to perform sanity on queue pointers
In reply to Greg Kroah-Hartman6.5-stable review patch. If anyone has any objections, please let me know.
------------------
From: Vikash Garodia <[email protected]>
commit 5e538fce33589da6d7cb2de1445b84d3a8a692f7 upstream.
Read and write pointers are used to track the packet index in the memory shared between video driver and firmware. There is a possibility of OOB access if the read or write pointer goes beyond the queue memory size. Add checks for the read and write pointer to avoid OOB access.
--- drivers/media/platform/qcom/venus/hfi_venus.c | 10 ++++++++++ 1 file changed, 10 insertions(+)
drivers/media/platform/qcom/venus/hfi_venus.c +10 -0
@@ -205,6 +205,11 @@ static int venus_write_queue(struct venu new_wr_idx = wr_idx + dwords; wr_ptr = (u32 *)(queue->qmem.kva + (wr_idx <<2 )); + +if (wr_ptr < (u32 *)queue->qmem.kva || + wr_ptr > (u32 *)(queue->qmem.kva + queue->qmem.size -sizeof (*wr_ptr))) +return -EINVAL ; +if (new_wr_idx < qsize) {memcpy (wr_ptr, packet, dwords <<2 ); }else {
@@ -272,6 +277,11 @@ static int venus_read_queue(struct venus } rd_ptr = (u32 *)(queue->qmem.kva + (rd_idx <<2 )); + +if (rd_ptr < (u32 *)queue->qmem.kva || + rd_ptr > (u32 *)(queue->qmem.kva + queue->qmem.size -sizeof (*rd_ptr))) +return -EINVAL ; + dwords = *rd_ptr >>2 ;if (!dwords)return -EINVAL ;
Greg Kroah-Hartman
maintainerPATCH 228/491 perf intel-pt: Fix async branch flags
In reply to Greg Kroah-Hartman6.5-stable review patch. If anyone has any objections, please let me know.
------------------
From: Adrian Hunter <[email protected]>
commit f2d87895cbc4af80649850dcf5da36de6b2ed3dd upstream.
Ensure PERF_IP_FLAG_ASYNC is set always for asynchronous branches (i.e. interrupts etc).
--- tools/perf/util/intel-pt.c | 2 ++ 1 file changed, 2 insertions(+)
tools/perf/util/intel-pt.c +2 -0
@@ -1512,9 +1512,11 @@ static void intel_pt_sample_flags(struct }else if (ptq->state->flags &INTEL_PT_ASYNC ) {if (!ptq->state->to_ip) ptq->flags =PERF_IP_FLAG_BRANCH | +PERF_IP_FLAG_ASYNC |PERF_IP_FLAG_TRACE_END ;else if (ptq->state->from_nr && !ptq->state->to_nr) ptq->flags =PERF_IP_FLAG_BRANCH |PERF_IP_FLAG_CALL | +PERF_IP_FLAG_ASYNC |PERF_IP_FLAG_VMEXIT ;else ptq->flags = PERF_IP_FLAG_BRANCH | PERF_IP_FLAG_CALL |
Greg Kroah-Hartman
maintainerPATCH 229/491 powerpc/perf: Fix disabling BHRB and instruction sampling
In reply to Greg Kroah-Hartman6.5-stable review patch. If anyone has any objections, please let me know.
------------------
From: Nicholas Piggin <[email protected]>
commit ea142e590aec55ba40c5affb4d49e68c713c63dc upstream.
When the PMU is disabled, MMCRA is not updated to disable BHRB and instruction sampling. This can lead to those features remaining enabled, which can slow down a real or emulated CPU.
--- arch/powerpc/perf/core-book3s.c | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-)
arch/powerpc/perf/core-book3s.c +2 -3
@@ -1371,8 +1371,7 @@ static void power_pmu_disable(struct pmu/* * Disable instruction sampling if it was enabled */ -if (cpuhw->mmcr.mmcra &MMCRA_SAMPLE_ENABLE ) - val &= ~MMCRA_SAMPLE_ENABLE ; + val &= ~MMCRA_SAMPLE_ENABLE ;/* Disable BHRB via mmcra (BHRBRD) for p10 */ if (ppmu->flags &PPMU_ARCH_31 )
@@ -1383,7 +1382,7 @@ static void power_pmu_disable(struct pmu* instruction sampling or BHRB. */ if (val != mmcra) { -mtspr (SPRN_MMCRA , mmcra); +mtspr (SPRN_MMCRA , val);mb ();isync (); }
Greg Kroah-Hartman
maintainerPATCH 230/491 randstruct: Fix gcc-plugin performance mode to stay in group
In reply to Greg Kroah-Hartman6.5-stable review patch. If anyone has any objections, please let me know.
------------------
From: Kees Cook <[email protected]>
commit 381fdb73d1e2a48244de7260550e453d1003bb8e upstream.
The performance mode of the gcc-plugin randstruct was shuffling struct members outside of the cache-line groups. Limit the range to the specified group indexes.
--- scripts/gcc-plugins/randomize_layout_plugin.c | 11 ++++++++--- 1 file changed, 8 insertions(+), 3 deletions(-)
scripts/gcc-plugins/randomize_layout_plugin.c +8 -3
@@ -191,12 +191,14 @@ static void partition_struct(tree *fieldstatic void performance_shuffle (tree *newtree,unsigned long length,ranctx *prng_state) { -unsigned long i, x; +unsigned long i, x, index;struct partition_group size_group[length];unsigned long num_groups =0 ;unsigned long randnum;partition_struct (newtree, length, (struct partition_group *)&size_group, &num_groups); + +/* FIXME: this group shuffle is currently a no-op. */ for (i = num_groups -1 ; i >0 ; i--) {struct partition_group tmp; randnum =ranval (prng_state) % (i +1 );
@@ -206,11 +208,14 @@ static void performance_shuffle(tree *ne }for (x =0 ; x < num_groups; x++) { -for (i = size_group[x].start + size_group[x].length -1 ; i > size_group[x].start; i--) { +for (index = size_group[x].length -1 ; index >0 ; index--) {tree tmp; + + i = size_group[x].start + index;if (DECL_BIT_FIELD_TYPE (newtree[i]))continue ; - randnum =ranval (prng_state) % (i +1 ); + randnum =ranval (prng_state) % (index +1 ); + randnum += size_group[x].start;// we could handle this case differently if desired if (DECL_BIT_FIELD_TYPE (newtree[randnum]))continue ;
Greg Kroah-Hartman
maintainerPATCH 231/491 bpf: Fix check_stack_write_fixed_off() to correctly spill imm
In reply to Greg Kroah-Hartman6.5-stable review patch. If anyone has any objections, please let me know.
------------------
From: Hao Sun <[email protected]>
commit 811c363645b33e6e22658634329e95f383dfc705 upstream.
In check_stack_write_fixed_off(), imm value is cast to u32 before being spilled to the stack. Therefore, the sign information is lost, and the range information is incorrect when load from the stack again.
For the following prog:
0: r2 = r10
1: *(u64*)(r2 -40) = -44
2: r0 = *(u64*)(r2 - 40)
3: if r0 s<= 0xa goto +2
4: r0 = 1
5: exit
6: r0 = 0
7: exit
The verifier gives:
func#0 @0
0: R1=ctx(off=0,imm=0) R10=fp0
0: (bf) r2 = r10 ; R2_w=fp0 R10=fp0 1: (7a) *(u64 *)(r2 -40) = -44 ; R2_w=fp0 fp-40_w=4294967252 2: (79) r0 = *(u64 *)(r2 -40) ; R0_w=4294967252 R2_w=fp0
fp-40_w=4294967252
3: (c5) if r0 s< 0xa goto pc+2mark_precise: frame0: last_idx 3 first_idx 0 subseq_idx -1mark_precise: frame0: regs=r0 stack= before 2: (79) r0 = *(u64 *)(r2 -40) 3: R0_w=4294967252
4: (b7) r0 = 1 ; R0_w=1
5: (95) exit
verification time 7971 usec
stack depth 40
processed 6 insns (limit 1000000) max_states_per_insn 0 total_states 0 peak_states 0 mark_read 0
So remove the incorrect cast, since imm field is declared as s32, and __mark_reg_known() takes u64, so imm would be correctly sign extended by compiler.
--- kernel/bpf/verifier.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
kernel/bpf/verifier.c +1 -1
@@ -4368,7 +4368,7 @@ static int check_stack_write_fixed_off(s insn->imm != 0 && env->bpf_capable) {struct bpf_reg_state fake_reg = {}; -__mark_reg_known (&fake_reg, (u32 )insn->imm); +__mark_reg_known (&fake_reg, insn->imm); fake_reg.type =SCALAR_VALUE ;save_register_state (state, spi, &fake_reg, size); } else if (reg && is_spillable_regtype(reg->type)) {
Greg Kroah-Hartman
maintainerPATCH 232/491 bpf: Fix precision tracking for BPF_ALU | BPF_TO_BE | BPF_END
In reply to Greg Kroah-Hartman6.5-stable review patch. If anyone has any objections, please let me know.
------------------
From: Shung-Hsi Yu <[email protected]>
commit 291d044fd51f8484066300ee42afecf8c8db7b3a upstream.
BPF_END and BPF_NEG has a different specification for the source bit in the opcode compared to other ALU/ALU64 instructions, and is either reserved or use to specify the byte swap endianness. In both cases the source bit does not encode source operand location, and src_reg is a reserved field.
backtrack_insn() currently does not differentiate BPF_END and BPF_NEG from other ALU/ALU64 instructions, which leads to r0 being incorrectly marked as precise when processing BPF_ALU | BPF_TO_BE | BPF_END instructions. This commit teaches backtrack_insn() to correctly mark precision for such case.
While precise tracking of BPF_NEG and other BPF_END instructions are correct and does not need fixing, this commit opt to process all BPF_NEG and BPF_END instructions within the same if-clause to better align with current convention used in the verifier (e.g. check_alu_op).
--- kernel/bpf/verifier.c | 7 ++++++- 1 file changed, 6 insertions(+), 1 deletion(-)
kernel/bpf/verifier.c +6 -1
@@ -3436,7 +3436,12 @@ static int backtrack_insn(struct bpf_verif (class ==BPF_ALU || class ==BPF_ALU64 ) {if (!bt_is_reg_set (bt, dreg))return 0 ; -if (opcode ==BPF_MOV ) { +if (opcode ==BPF_END || opcode ==BPF_NEG ) { +/* sreg is reserved and unused +* dreg still need precision before this insn +*/ +return 0 ; + }else if (opcode ==BPF_MOV ) {if (BPF_SRC (insn->code) ==BPF_X ) {/* dreg = sreg * dreg needs precision after this insn
Greg Kroah-Hartman
maintainerPATCH 233/491 scsi: mpt3sas: Fix loop logic
In reply to Greg Kroah-Hartman6.5-stable review patch. If anyone has any objections, please let me know.
------------------
From: Ranjan Kumar <[email protected]>
commit 3c978492c333f0c08248a8d51cecbe5eb5f617c9 upstream.
The retry loop continues to iterate until the count reaches 30, even after receiving the correct value. Exit loop when a non-zero value is read.
--- drivers/scsi/mpt3sas/mpt3sas_base.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
drivers/scsi/mpt3sas/mpt3sas_base.c +2 -2
@@ -223,8 +223,8 @@ _base_readl_ext_retry(const volatile voifor (i =0 ; i <30 ; i++) { ret_val =readl (addr); -if (ret_val ==0 ) -continue ; +if (ret_val !=0 ) +break ; }return ret_val;
Greg Kroah-Hartman
maintainerPATCH 234/491 scsi: megaraid_sas: Increase register read retry rount from 3 to 30 for selected registers
In reply to Greg Kroah-Hartman6.5-stable review patch. If anyone has any objections, please let me know.
------------------
From: Chandrakanth patil <[email protected]>
commit 8e3ed9e786511ad800c33605ed904b9de49323cf upstream.
In BMC environments with concurrent access to multiple registers, certain registers occasionally yield a value of 0 even after 3 retries due to hardware errata. As a fix, we have extended the retry count from 3 to 30.
The same errata applies to the mpt3sas driver, and a similar patch has been accepted. Please find more details in the mpt3sas patch reference link.
--- drivers/scsi/megaraid/megaraid_sas_base.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
drivers/scsi/megaraid/megaraid_sas_base.c +2 -2
@@ -263,13 +263,13 @@ u32 megasas_readl(struct megasas_instanc* Fusion registers could intermittently return all zeroes. * This behavior is transient in nature and subsequent reads will * return valid value. As a workaround in driver, retry readl for -* upto three times until a non-zero value is read. +* up to thirty times until a non-zero value is read. */ if (instance->adapter_type ==AERO_SERIES ) {do { ret_val =readl (addr); i++; - }while (ret_val ==0 && i <3 ); + }while (ret_val ==0 && i <30 );return ret_val; }else {return readl (addr);
Greg Kroah-Hartman
maintainerPATCH 235/491 scsi: ufs: qcom: Update PHY settings only when scaling to higher gears
In reply to Greg Kroah-Hartman6.5-stable review patch. If anyone has any objections, please let me know.
------------------
From: Manivannan Sadhasivam <[email protected]>
commit fc88ca19ad0989dc0e4d4b126d5d0ba91f6cb616 upstream.
The "hs_gear" variable is used to program the PHY settings (submode) during ufs_qcom_power_up_sequence(). Currently, it is being updated every time the agreed gear changes. Due to this, if the gear got downscaled before suspend (runtime/system), then while resuming, the PHY settings for the lower gear will be applied first and later when scaling to max gear with REINIT, the PHY settings for the max gear will be applied.
This adds a latency while resuming and also really not needed as the PHY gear settings are backwards compatible i.e., we can continue using the PHY settings for max gear with lower gear speed.
So let's update the "hs_gear" variable _only_ when the agreed gear is greater than the current one. This guarantees that the PHY settings will be changed only during probe time and fatal error condition.
Due to this, UFSHCD_QUIRK_REINIT_AFTER_MAX_GEAR_SWITCH can now be skipped when the PM operation is in progress.
--- drivers/ufs/core/ufshcd.c | 3 ++- drivers/ufs/host/ufs-qcom.c | 9 +++++++-- 2 files changed, 9 insertions(+), 3 deletions(-)
drivers/ufs/core/ufshcd.c +2 -1
@@ -8798,7 +8798,8 @@ static int ufshcd_probe_hba(struct ufs_hif (ret) goto out; -if (hba->quirks &UFSHCD_QUIRK_REINIT_AFTER_MAX_GEAR_SWITCH ) { +if (!hba->pm_op_in_progress && + (hba->quirks &UFSHCD_QUIRK_REINIT_AFTER_MAX_GEAR_SWITCH )) {/* Reset the device and controller before doing reinit */ ufshcd_device_reset (hba);ufshcd_hba_stop (hba);
drivers/ufs/host/ufs-qcom.c +7 -2
@@ -820,8 +820,13 @@ static int ufs_qcom_pwr_change_notify(streturn ret; } -/* Use the agreed gear */ - host->hs_gear = dev_req_params->gear_tx; +/* +* Update hs_gear only when the gears are scaled to a higher value. This is because, +* the PHY gear settings are backwards compatible and we only need to change the PHY +* settings while scaling to higher gears. +*/ +if (dev_req_params->gear_tx > host->hs_gear) + host->hs_gear = dev_req_params->gear_tx;/* enable the device ref clock before changing to HS mode */ if (!ufshcd_is_hs_mode(&hba->pwr_info) &&
Greg Kroah-Hartman
maintainerPATCH 236/491 scsi: qla2xxx: Fix system crash due to bad pointer access
In reply to Greg Kroah-Hartman6.5-stable review patch. If anyone has any objections, please let me know.
------------------
From: Quinn Tran <[email protected]>
commit 19597cad64d608aa8ac2f8aef50a50187a565223 upstream.
User experiences system crash when running AER error injection. The perturbation causes the abort-all-I/O path to trigger. The driver assumes all I/O on this path is FCP only. If there is both NVMe & FCP traffic, a system crash happens. Add additional check to see if I/O is FCP or not before access.
PID: 999019 TASK: ff35d769f24722c0 CPU: 53 COMMAND: "kworker/53:1"
0 [ff3f78b964847b58] machine_kexec at ffffffffae86973d
1 [ff3f78b964847ba8] __crash_kexec at ffffffffae9be29d
2 [ff3f78b964847c70] crash_kexec at ffffffffae9bf528
3 [ff3f78b964847c78] oops_end at ffffffffae8282ab
4 [ff3f78b964847c98] exc_page_fault at ffffffffaf2da502
5 [ff3f78b964847cc0] asm_exc_page_fault at ffffffffaf400b62
[exception RIP: qla2x00_abort_srb+444]
RIP: ffffffffc07b5f8c RSP: ff3f78b964847d78 RFLAGS: 00010046 RAX: 0000000000000282 RBX: ff35d74a0195a200 RCX: ff35d76886fd03a0 RDX: 0000000000000001 RSI: ffffffffc07c5ec8 RDI: ff35d74a0195a200 RBP: ff35d76913d22080 R8: ff35d7694d103200 R9: ff35d7694d103200 R10: 0000000100000000 R11: ffffffffb05d6630 R12: 0000000000010000 R13: ff3f78b964847df8 R14: ff35d768d8754000 R15: ff35d768877248e0 ORIG_RAX: ffffffffffffffff CS: 0010 SS: 0018 6 [ff3f78b964847d70] qla2x00_abort_srb at ffffffffc07b5f84 [qla2xxx] 7 [ff3f78b964847de0] __qla2x00_abort_all_cmds at ffffffffc07b6238 [qla2xxx] 8 [ff3f78b964847e38] qla2x00_abort_all_cmds at ffffffffc07ba635 [qla2xxx] 9 [ff3f78b964847e58] qla2x00_terminate_rport_io at ffffffffc08145eb [qla2xxx]
10 [ff3f78b964847e70] fc_terminate_rport_io at ffffffffc045987e [scsi_transport_fc] 11 [ff3f78b964847e88] process_one_work at ffffffffae914f15
12 [ff3f78b964847ed0] worker_thread at ffffffffae9154c0
13 [ff3f78b964847f10] kthread at ffffffffae91c456
14 [ff3f78b964847f50] ret_from_fork at ffffffffae8036ef
--- drivers/scsi/qla2xxx/qla_os.c | 12 ++++++++++-- 1 file changed, 10 insertions(+), 2 deletions(-)
drivers/scsi/qla2xxx/qla_os.c +10 -2
@@ -1835,8 +1835,16 @@ static void qla2x00_abort_srb(struct qla }spin_lock_irqsave (qp->qp_lock_ptr, *flags); -if (ret_cmd &&blk_mq_request_started (scsi_cmd_to_rq (cmd))) - sp->done (sp, res); +switch (sp->type) { +case SRB_SCSI_CMD : +if (ret_cmd &&blk_mq_request_started (scsi_cmd_to_rq (cmd))) + sp->done (sp, res); +break ; +default : +if (ret_cmd) + sp->done (sp, res); +break ; + } }else { sp->done (sp, res); }
Greg Kroah-Hartman
maintainerPATCH 237/491 scsi: ufs: core: Fix racing issue between ufshcd_mcq_abort() and ISR
In reply to Greg Kroah-Hartman6.5-stable review patch. If anyone has any objections, please let me know.
------------------
From: Peter Wang <[email protected]>
commit 27900d7119c464b43cd9eac69c85884d17bae240 upstream.
If command timeout happens and cq complete IRQ is raised at the same time, ufshcd_mcq_abort clears lprb->cmd and a NULL pointer deref happens in the ISR. Error log:
ufshcd_abort: Device abort task at tag 18
Unable to handle kernel NULL pointer dereference at virtual address 0000000000000108 pc : [0xffffffe27ef867ac] scsi_dma_unmap+0xc/0x44 lr : [0xffffffe27f1b898c] ufshcd_release_scsi_cmd+0x24/0x114
--- drivers/ufs/core/ufs-mcq.c | 3 +++ 1 file changed, 3 insertions(+)
drivers/ufs/core/ufs-mcq.c +3 -0
@@ -632,6 +632,7 @@ int ufshcd_mcq_abort(struct scsi_cmnd *cint tag =scsi_cmd_to_rq (cmd)->tag;struct ufshcd_lrb *lrbp = &hba->lrb[tag];struct ufs_hw_queue *hwq; +unsigned long flags;int err =FAILED ;if (!ufshcd_cmd_inflight (lrbp->cmd)) {
@@ -672,8 +673,10 @@ int ufshcd_mcq_abort(struct scsi_cmnd *c } err =SUCCESS ; +spin_lock_irqsave (&hwq->cq_lock, flags);if (ufshcd_cmd_inflight (lrbp->cmd))ufshcd_release_scsi_cmd (hba, lrbp); +spin_unlock_irqrestore (&hwq->cq_lock, flags); out:return err;
Greg Kroah-Hartman
maintainerPATCH 238/491 crypto: x86/sha - load modules based on CPU features
In reply to Greg Kroah-Hartman6.5-stable review patch. If anyone has any objections, please let me know.
------------------
From: Roxana Nicolescu <[email protected]>
commit 1c43c0f1f84aa59dfc98ce66f0a67b2922aa7f9d upstream.
x86 optimized crypto modules are built as modules rather than build-in and they are not loaded when the crypto API is initialized, resulting in the generic builtin module (sha1-generic) being used instead.
It was discovered when creating a sha1/sha256 checksum of a 2Gb file by using kcapi-tools because it would take significantly longer than creating a sha512 checksum of the same file. trace-cmd showed that for sha1/256 the generic module was used, whereas for sha512 the optimized module was used instead.
Add module aliases() for these x86 optimized crypto modules based on CPU feature bits so udev gets a chance to load them later in the boot process. This resulted in ~3x decrease in the real-time execution of kcapi-dsg.
Fix is inspired from commitaa031b8f702e ("crypto: x86/sha512 - load based on CPU features") where a similar fix was done for sha512.
--- arch/x86/crypto/sha1_ssse3_glue.c | 12 ++++++++++++ arch/x86/crypto/sha256_ssse3_glue.c | 12 ++++++++++++ 2 files changed, 24 insertions(+)
arch/x86/crypto/sha1_ssse3_glue.c +12 -0
@@ -24,8 +24,17 @@#include <linux/types.h> #include <crypto/sha1.h> #include <crypto/sha1_base.h> +#include <asm/cpu_device_id.h> #include <asm/simd.h> +static const struct x86_cpu_id module_cpu_ids[] = { +X86_MATCH_FEATURE (X86_FEATURE_AVX2 ,NULL ), +X86_MATCH_FEATURE (X86_FEATURE_AVX ,NULL ), +X86_MATCH_FEATURE (X86_FEATURE_SSSE3 ,NULL ), + {} +}; +MODULE_DEVICE_TABLE (x86cpu, module_cpu_ids); +static int sha1_update (struct shash_desc *desc,const u8 *data,unsigned int len,sha1_block_fn *sha1_xform) {
@@ -301,6 +310,9 @@ static inline void unregister_sha1_ni(vostatic int __init sha1_ssse3_mod_init (void ) { +if (!x86_match_cpu (module_cpu_ids)) +return -ENODEV ; +if (register_sha1_ssse3 ()) goto fail;
arch/x86/crypto/sha256_ssse3_glue.c +12 -0
@@ -38,11 +38,20 @@#include <crypto/sha2.h> #include <crypto/sha256_base.h> #include <linux/string.h> +#include <asm/cpu_device_id.h> #include <asm/simd.h> asmlinkage void sha256_transform_ssse3(struct sha256_state *state,const u8 *data,int blocks); +static const struct x86_cpu_id module_cpu_ids[] = { +X86_MATCH_FEATURE (X86_FEATURE_AVX2 ,NULL ), +X86_MATCH_FEATURE (X86_FEATURE_AVX ,NULL ), +X86_MATCH_FEATURE (X86_FEATURE_SSSE3 ,NULL ), + {} +}; +MODULE_DEVICE_TABLE (x86cpu, module_cpu_ids); +static int _sha256_update (struct shash_desc *desc,const u8 *data,unsigned int len,sha256_block_fn *sha256_xform) {
@@ -366,6 +375,9 @@ static inline void unregister_sha256_ni(static int __init sha256_ssse3_mod_init (void ) { +if (!x86_match_cpu (module_cpu_ids)) +return -ENODEV ; +if (register_sha256_ssse3 ()) goto fail;
Greg Kroah-Hartman
maintainerPATCH 239/491 x86/PCI: Avoid PME from D3hot/D3cold for AMD Rembrandt and Phoenix USB4
In reply to Greg Kroah-Hartman6.5-stable review patch. If anyone has any objections, please let me know.
------------------
From: Mario Limonciello <[email protected]>
commit 7d08f21f8c6307cb05cabb8d86e90ff6ccba57e9 upstream.
Iain reports that USB devices can't be used to wake a Lenovo Z13 from suspend. This occurs because on some AMD platforms, even though the Root Ports advertise PME_Support for D3hot and D3cold, wakeup events from devices on a USB4 controller don't result in wakeup interrupts from the Root Port when amd-pmc has put the platform in a hardware sleep state.
If amd-pmc will be involved in the suspend, remove D3hot and D3cold from the PME_Support mask of Root Ports above USB4 controllers so we avoid those states if we need wakeups.
Restore D3 support at resume so that it can be used by runtime suspend.
This affects both AMD Rembrandt and Phoenix SoCs.
"pm_suspend_target_state == PM_SUSPEND_ON" means we're doing runtime suspend, and amd-pmc will not be involved. In that case PMEs work as advertised in D3hot/D3cold, so we don't need to do anything.
Note that amd-pmc is technically optional, and there's no need for this quirk if it's not present, but we assume it's always present because power consumption is so high without it.
--- arch/x86/pci/fixup.c | 59 +++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 59 insertions(+)
arch/x86/pci/fixup.c +59 -0
@@ -3,9 +3,11 @@* Exceptions for specific devices. Usually work-arounds for fatal design flaws. */ +#include <linux/bitfield.h> #include <linux/delay.h> #include <linux/dmi.h> #include <linux/pci.h> +#include <linux/suspend.h> #include <linux/vgaarb.h> #include <asm/amd_nb.h> #include <asm/hpet.h>
@@ -904,3 +906,60 @@ static void chromeos_fixup_apl_pci_l1ss_ }DECLARE_PCI_FIXUP_FINAL (PCI_VENDOR_ID_INTEL ,0x5ad6 , chromeos_save_apl_pci_l1ss_capability);DECLARE_PCI_FIXUP_RESUME (PCI_VENDOR_ID_INTEL ,0x5ad6 , chromeos_fixup_apl_pci_l1ss_capability); + +#ifdef CONFIG_SUSPEND +/* +* Root Ports on some AMD SoCs advertise PME_Support for D3hot and D3cold, but +* if the SoC is put into a hardware sleep state by the amd-pmc driver, the +* Root Ports don't generate wakeup interrupts for USB devices. +* +* When suspending, remove D3hot and D3cold from the PME_Support advertised +* by the Root Port so we don't use those states if we're expecting wakeup +* interrupts. Restore the advertised PME_Support when resuming. +*/ +static void amd_rp_pme_suspend (struct pci_dev *dev) +{ +struct pci_dev *rp; + +/* +* PM_SUSPEND_ON means we're doing runtime suspend, which means +* amd-pmc will not be involved so PMEs during D3 work as advertised. +* +* The PMEs *do* work if amd-pmc doesn't put the SoC in the hardware +* sleep state, but we assume amd-pmc is always present. +*/ +if (pm_suspend_target_state ==PM_SUSPEND_ON ) +return ; + + rp =pcie_find_root_port (dev); +if (!rp->pm_cap) +return ; + + rp->pme_support &= ~((PCI_PM_CAP_PME_D3hot|PCI_PM_CAP_PME_D3cold) >> +PCI_PM_CAP_PME_SHIFT ); +dev_info_once (&rp->dev,"quirk: disabling D3cold for suspend\n" ); +} + +static void amd_rp_pme_resume (struct pci_dev *dev) +{ +struct pci_dev *rp; +u16 pmc; + + rp =pcie_find_root_port (dev); +if (!rp->pm_cap) +return ; + +pci_read_config_word (rp, rp->pm_cap +PCI_PM_PMC , &pmc); + rp->pme_support =FIELD_GET (PCI_PM_CAP_PME_MASK , pmc); +} +/* Rembrandt (yellow_carp) */ +DECLARE_PCI_FIXUP_SUSPEND (PCI_VENDOR_ID_AMD ,0x162e , amd_rp_pme_suspend); +DECLARE_PCI_FIXUP_RESUME (PCI_VENDOR_ID_AMD ,0x162e , amd_rp_pme_resume); +DECLARE_PCI_FIXUP_SUSPEND (PCI_VENDOR_ID_AMD ,0x162f , amd_rp_pme_suspend); +DECLARE_PCI_FIXUP_RESUME (PCI_VENDOR_ID_AMD ,0x162f , amd_rp_pme_resume); +/* Phoenix (pink_sardine) */ +DECLARE_PCI_FIXUP_SUSPEND (PCI_VENDOR_ID_AMD ,0x1668 , amd_rp_pme_suspend); +DECLARE_PCI_FIXUP_RESUME (PCI_VENDOR_ID_AMD ,0x1668 , amd_rp_pme_resume); +DECLARE_PCI_FIXUP_SUSPEND (PCI_VENDOR_ID_AMD ,0x1669 , amd_rp_pme_suspend); +DECLARE_PCI_FIXUP_RESUME (PCI_VENDOR_ID_AMD ,0x1669 , amd_rp_pme_resume); +#endif /* CONFIG_SUSPEND */
Greg Kroah-Hartman
maintainerPATCH 240/491 x86/apic/msi: Fix misconfigured non-maskable MSI quirk
In reply to Greg Kroah-Hartman6.5-stable review patch. If anyone has any objections, please let me know.
------------------
From: Koichiro Den <[email protected]>
commit b56ebe7c896dc78b5865ec2c4b1dae3c93537517 upstream.
commit ef8dd01538ea ("genirq/msi: Make interrupt allocation less convoluted"), reworked the code so that the x86 specific quirk for affinity setting of non-maskable PCI/MSI interrupts is not longer activated if necessary.
This could be solved by restoring the original logic in the core MSI code, but after a deeper analysis it turned out that the quirk flag is not required at all.
The quirk is only required when the PCI/MSI device cannot mask the MSI interrupts, which in turn also prevents reservation mode from being enabled for the affected interrupt.
This allows ot remove the NOMASK quirk bit completely as msi_set_affinity() can instead check whether reservation mode is enabled for the interrupt, which gives exactly the same answer.
Even in the momentary non-existing case that the reservation mode would be not set for a maskable MSI interrupt this would not cause any harm as it just would cause msi_set_affinity() to go needlessly through the functionaly equivalent slow path, which works perfectly fine with maskable interrupts as well.
Rework msi_set_affinity() to query the reservation mode and remove all NOMASK quirk logic from the core code.
[ tglx: Massaged changelog ]
--- arch/x86/kernel/apic/msi.c | 8 +++----- include/linux/irq.h | 26 ++++---------------------- include/linux/msi.h | 6 ------ kernel/irq/debugfs.c | 1 - kernel/irq/msi.c | 12 +----------- 5 files changed, 8 insertions(+), 45 deletions(-)
arch/x86/kernel/apic/msi.c +3 -5
@@ -55,14 +55,14 @@ msi_set_affinity(struct irq_data *irqd,* caused by the non-atomic update of the address/data pair. * * Direct update is possible when: -* - The MSI is maskable (remapped MSI does not use this code path)). -* The quirk bit is not set in this case. +* - The MSI is maskable (remapped MSI does not use this code path). +* The reservation mode bit is set in this case. * - The new vector is the same as the old vector * - The old vector is MANAGED_IRQ_SHUTDOWN_VECTOR (interrupt starts up) * - The interrupt is not yet started up * - The new destination CPU is the same as the old destination CPU */ - if (!irqd_msi_nomask_quirk(irqd) || + if (!irqd_can_reserve(irqd) || cfg->vector == old_cfg.vector || old_cfg.vector == MANAGED_IRQ_SHUTDOWN_VECTOR || !irqd_is_started(irqd) ||
@@ -215,8 +215,6 @@ static bool x86_init_dev_msi_info(structif (WARN_ON_ONCE (domain != real_parent))return false; info->chip->irq_set_affinity = msi_set_affinity; -/* See msi_set_affinity() for the gory details */ - info->flags |=MSI_FLAG_NOMASK_QUIRK ;break ;case DOMAIN_BUS_DMAR :case DOMAIN_BUS_AMDVI :
include/linux/irq.h +4 -22
@@ -215,8 +215,6 @@ struct irq_data {* IRQD_SINGLE_TARGET - IRQ allows only a single affinity target * IRQD_DEFAULT_TRIGGER_SET - Expected trigger already been set * IRQD_CAN_RESERVE - Can use reservation mode -* IRQD_MSI_NOMASK_QUIRK - Non-maskable MSI quirk for affinity change -* required * IRQD_HANDLE_ENFORCE_IRQCTX - Enforce that handle_irq_*() is only invoked * from actual interrupt context. * IRQD_AFFINITY_ON_ACTIVATE - Affinity is set on activation. Don't call
@@ -247,11 +245,10 @@ enum {IRQD_SINGLE_TARGET =BIT (24 ),IRQD_DEFAULT_TRIGGER_SET =BIT (25 ),IRQD_CAN_RESERVE =BIT (26 ), -IRQD_MSI_NOMASK_QUIRK =BIT (27 ), -IRQD_HANDLE_ENFORCE_IRQCTX =BIT (28 ), -IRQD_AFFINITY_ON_ACTIVATE =BIT (29 ), -IRQD_IRQ_ENABLED_ON_SUSPEND =BIT (30 ), - IRQD_RESEND_WHEN_IN_PROGRESS = BIT(31), +IRQD_HANDLE_ENFORCE_IRQCTX =BIT (27 ), +IRQD_AFFINITY_ON_ACTIVATE =BIT (28 ), +IRQD_IRQ_ENABLED_ON_SUSPEND =BIT (29 ), + IRQD_RESEND_WHEN_IN_PROGRESS = BIT(30), };#define __irqd_to_state (d) ACCESS_PRIVATE((d)->common, state_use_accessors)
@@ -426,21 +423,6 @@ static inline bool irqd_can_reserve(strureturn __irqd_to_state (d) &IRQD_CAN_RESERVE ; } -static inline void irqd_set_msi_nomask_quirk (struct irq_data *d) -{ -__irqd_to_state (d) |=IRQD_MSI_NOMASK_QUIRK ; -} - -static inline void irqd_clr_msi_nomask_quirk (struct irq_data *d) -{ -__irqd_to_state (d) &= ~IRQD_MSI_NOMASK_QUIRK ; -} - -static inline bool irqd_msi_nomask_quirk (struct irq_data *d) -{ -return __irqd_to_state (d) &IRQD_MSI_NOMASK_QUIRK ; -} -static inline void irqd_set_affinity_on_activate (struct irq_data *d) {__irqd_to_state (d) |=IRQD_AFFINITY_ON_ACTIVATE ;
include/linux/msi.h +0 -6
@@ -547,12 +547,6 @@ enum {MSI_FLAG_ALLOC_SIMPLE_MSI_DESCS = (1 <<5 ),/* Free MSI descriptors */ MSI_FLAG_FREE_MSI_DESCS = (1 <<6 ), -/* -* Quirk to handle MSI implementations which do not provide -* masking. Currently known to affect x86, but has to be partially -* handled in the core MSI code. -*/ -MSI_FLAG_NOMASK_QUIRK = (1 <<7 ),/* Mask for the generic functionality */ MSI_GENERIC_FLAGS_MASK = GENMASK(15, 0),
kernel/irq/debugfs.c +0 -1
@@ -121,7 +121,6 @@ static const struct irq_bit_descr irqdatBIT_MASK_DESCR (IRQD_AFFINITY_ON_ACTIVATE ),BIT_MASK_DESCR (IRQD_MANAGED_SHUTDOWN ),BIT_MASK_DESCR (IRQD_CAN_RESERVE ), -BIT_MASK_DESCR (IRQD_MSI_NOMASK_QUIRK ), BIT_MASK_DESCR(IRQD_FORWARDED_TO_VCPU),
kernel/irq/msi.c +1 -11
@@ -1204,7 +1204,6 @@ static int msi_handle_pci_fail(struct ir#define VIRQ_CAN_RESERVE 0x01#define VIRQ_ACTIVATE 0x02 -#define VIRQ_NOMASK_QUIRK 0x04static int msi_init_virq (struct irq_domain *domain,int virq,unsigned int vflags) {
@@ -1213,8 +1212,6 @@ static int msi_init_virq(struct irq_domaif (!(vflags &VIRQ_CAN_RESERVE )) {irqd_clr_can_reserve (irqd); -if (vflags &VIRQ_NOMASK_QUIRK ) -irqd_set_msi_nomask_quirk (irqd);/* * If the interrupt is managed but no CPU is available to
@@ -1275,15 +1272,8 @@ static int __msi_domain_alloc_irqs(struc* Interrupt can use a reserved vector and will not occupy * a real device vector until the interrupt is requested. */ -if (msi_check_reservation_mode (domain, info, dev)) { +if (msi_check_reservation_mode (domain, info, dev)) vflags |=VIRQ_CAN_RESERVE ; -/* -* MSI affinity setting requires a special quirk (X86) when -* reservation mode is active. -*/ -if (info->flags &MSI_FLAG_NOMASK_QUIRK ) - vflags |=VIRQ_NOMASK_QUIRK ; - }xa_for_each_range (xa, idx, desc, ctrl->first, ctrl->last) {if (!msi_desc_match (desc,MSI_DESC_NOTASSOCIATED ))
Greg Kroah-Hartman
maintainerPATCH 241/491 x86/cpu/hygon: Fix the CPU topology evaluation for real
In reply to Greg Kroah-Hartman6.5-stable review patch. If anyone has any objections, please let me know.
------------------
From: Pu Wen <[email protected]>
commit ee545b94d39a00c93dc98b1dbcbcf731d2eadeb4 upstream.
Hygon processors with a model ID > 3 have CPUID leaf 0xB correctly populated and don't need the fixed package ID shift workaround. The fixup is also incorrect when running in a guest.
--- arch/x86/kernel/cpu/hygon.c | 8 ++++++-- 1 file changed, 6 insertions(+), 2 deletions(-)
arch/x86/kernel/cpu/hygon.c +6 -2
@@ -86,8 +86,12 @@ static void hygon_get_topology(struct cpif (!err) c->x86_coreid_bits =get_count_order (c->x86_max_cores); -/* Socket ID is ApicId[6] for these processors. */ - c->phys_proc_id = c->apicid >>APICID_SOCKET_ID_BIT ; +/* +* Socket ID is ApicId[6] for the processors with model <= 0x3 +* when running on host. +*/ +if (!boot_cpu_has (X86_FEATURE_HYPERVISOR ) && c->x86_model <=0x3 ) + c->phys_proc_id = c->apicid >>APICID_SOCKET_ID_BIT ;cacheinfo_hygon_init_llc_id (c, cpu); }else if (cpu_has (c,X86_FEATURE_NODEID_MSR )) {
Greg Kroah-Hartman
maintainerPATCH 242/491 KVM: x86: hyper-v: Dont auto-enable stimer on write from user-space
In reply to Greg Kroah-Hartman6.5-stable review patch. If anyone has any objections, please let me know.
------------------
From: Nicolas Saenz Julienne <[email protected]>
commit d6800af51c76b6dae20e6023bbdc9b3da3ab5121 upstream.
Don't apply the stimer's counter side effects when modifying its value from user-space, as this may trigger spurious interrupts.
For example:
- The stimer is configured in auto-enable mode.
- The stimer's count is set and the timer enabled.
- The stimer expires, an interrupt is injected.
- The VM is live migrated.
- The stimer config and count are deserialized, auto-enable is ON, the stimer is re-enabled.
- The stimer expires right away, and injects an unwarranted interrupt.
--- arch/x86/kvm/hyperv.c | 10 ++++++---- 1 file changed, 6 insertions(+), 4 deletions(-)
arch/x86/kvm/hyperv.c +6 -4
@@ -727,10 +727,12 @@ static int stimer_set_count(struct kvm_vstimer_cleanup (stimer); stimer->count = count; -if (stimer->count ==0 ) - stimer->config.enable =0 ; -else if (stimer->config.auto_enable) - stimer->config.enable =1 ; +if (!host) { +if (stimer->count ==0 ) + stimer->config.enable =0 ; +else if (stimer->config.auto_enable) + stimer->config.enable =1 ; + }if (stimer->config.enable)stimer_mark_pending (stimer, false);
Greg Kroah-Hartman
maintainerPATCH 243/491 KVM: x86: Ignore MSR_AMD64_TW_CFG access
In reply to Greg Kroah-Hartman6.5-stable review patch. If anyone has any objections, please let me know.
------------------
From: Maciej S. Szmigiero <[email protected]>
commit 2770d4722036d6bd24bcb78e9cd7f6e572077d03 upstream.
Hyper-V enabled Windows Server 2022 KVM VM cannot be started on Zen1 Ryzen since it crashes at boot with SYSTEM_THREAD_EXCEPTION_NOT_HANDLED + STATUS_PRIVILEGED_INSTRUCTION (in other words, because of an unexpected #GP in the guest kernel).
This is because Windows tries to set bit 8 in MSR_AMD64_TW_CFG and can't handle receiving a #GP when doing so.
Give this MSR the same treatment that commit 2e32b7190641 ("x86, kvm: Add MSR_AMD64_BU_CFG2 to the list of ignored MSRs") gave MSR_AMD64_BU_CFG2 under justification that this MSR is baremetal-relevant only.
Although apparently it was then needed for Linux guests, not Windows as in this case.
With this change, the aforementioned guest setup is able to finish booting successfully.
This issue can be reproduced either on a Summit Ridge Ryzen (with just "-cpu host") or on a Naples EPYC (with "-cpu host,stepping=1" since EPYC is ordinarily stepping 2).
Alternatively, userspace could solve the problem by using MSR filters, but forcing every userspace to define a filter isn't very friendly and doesn't add much, if any, value. The only potential hiccup is if one of these "baremetal-only" MSRs ever requires actual emulation and/or has F/M/S specific behavior. But if that happens, then KVM can still punt *that* handling to userspace since userspace MSR filters "win" over KVM's default handling.
--- arch/x86/include/asm/msr-index.h | 1 + arch/x86/kvm/x86.c | 2 ++ 2 files changed, 3 insertions(+)
arch/x86/include/asm/msr-index.h +1 -0
@@ -553,6 +553,7 @@#define MSR_AMD64_CPUID_FN_1 0xc0011004#define MSR_AMD64_LS_CFG 0xc0011020#define MSR_AMD64_DC_CFG 0xc0011022 +#define MSR_AMD64_TW_CFG 0xc0011023#define MSR_AMD64_DE_CFG 0xc0011029#define MSR_AMD64_DE_CFG_LFENCE_SERIALIZE_BIT 1
arch/x86/kvm/x86.c +2 -0
@@ -3643,6 +3643,7 @@ int kvm_set_msr_common(struct kvm_vcpu *case MSR_AMD64_PATCH_LOADER :case MSR_AMD64_BU_CFG2 :case MSR_AMD64_DC_CFG : +case MSR_AMD64_TW_CFG :case MSR_F15H_EX_CFG :break ;
@@ -4067,6 +4068,7 @@ int kvm_get_msr_common(struct kvm_vcpu *case MSR_AMD64_BU_CFG2 :case MSR_IA32_PERF_CTL :case MSR_AMD64_DC_CFG : +case MSR_AMD64_TW_CFG :case MSR_F15H_EX_CFG :/* * Intel Sandy Bridge CPUs must support the RAPL (running average power
Greg Kroah-Hartman
maintainerPATCH 244/491 KVM: x86: Clear bit12 of ICR after APIC-write VM-exit
In reply to Greg Kroah-Hartman6.5-stable review patch. If anyone has any objections, please let me know.
------------------
From: Tao Su <[email protected]>
commit 629d3698f6958ee6f8131ea324af794f973b12ac upstream.
When IPI virtualization is enabled, a WARN is triggered if bit12 of ICR MSR is set after APIC-write VM-exit. The reason is kvm_apic_send_ipi() thinks the APIC_ICR_BUSY bit should be cleared because KVM has no delay, but kvm_apic_write_nodecode() doesn't clear the APIC_ICR_BUSY bit.
Under the x2APIC section, regarding ICR, the SDM says:
It remains readable only to aid in debugging; however, software should not assume the value returned by reading the ICR is the last written value.
I.e. the guest is allowed to set bit 12. However, the SDM also gives KVM free reign to do whatever it wants with the bit, so long as KVM's behavior doesn't confuse userspace or break KVM's ABI.
Clear bit 12 so that it reads back as '0'. This approach is safer than "do nothing" and is consistent with the case where IPI virtualization is disabled or not supported, i.e.,
handle_fastpath_set_x2apic_icr_irqoff() -> kvm_x2apic_icr_write()
Opportunistically replace the TODO with a comment calling out that eating the write is likely faster than a conditional branch around the busy bit.
--- arch/x86/kvm/lapic.c | 26 +++++++++++++------------- 1 file changed, 13 insertions(+), 13 deletions(-)
arch/x86/kvm/lapic.c +13 -13
@@ -2423,22 +2423,22 @@ EXPORT_SYMBOL_GPL(kvm_lapic_set_eoi);void kvm_apic_write_nodecode (struct kvm_vcpu *vcpu,u32 offset) {struct kvm_lapic *apic = vcpu->arch.apic; -u64 val;/* -* ICR is a single 64-bit register when x2APIC is enabled. For legacy -* xAPIC, ICR writes need to go down the common (slightly slower) path -* to get the upper half from ICR2. +* ICR is a single 64-bit register when x2APIC is enabled, all others +* registers hold 32-bit values. For legacy xAPIC, ICR writes need to +* go down the common path to get the upper half from ICR2. +* +* Note, using the write helpers may incur an unnecessary write to the +* virtual APIC state, but KVM needs to conditionally modify the value +* in certain cases, e.g. to clear the ICR busy bit. The cost of extra +* conditional branches is likely a wash relative to the cost of the +* maybe-unecessary write, and both are in the noise anyways. */ -if (apic_x2apic_mode (apic) && offset ==APIC_ICR ) { - val =kvm_lapic_get_reg64 (apic,APIC_ICR ); -kvm_apic_send_ipi (apic, (u32 )val, (u32)(val >>32 )); -trace_kvm_apic_write (APIC_ICR , val); - }else { -/* TODO: optimize to just emulate side effect w/o one more write */ - val =kvm_lapic_get_reg (apic, offset); -kvm_lapic_reg_write (apic, offset, (u32 )val); - } +if (apic_x2apic_mode (apic) && offset ==APIC_ICR ) +kvm_x2apic_icr_write (apic,kvm_lapic_get_reg64 (apic,APIC_ICR )); +else +kvm_lapic_reg_write (apic, offset,kvm_lapic_get_reg (apic, offset)); }EXPORT_SYMBOL_GPL (kvm_apic_write_nodecode);
Greg Kroah-Hartman
maintainerPATCH 245/491 KVM: x86: Fix lapic timer interrupt lost after loading a snapshot.
In reply to Greg Kroah-Hartman6.5-stable review patch. If anyone has any objections, please let me know.
------------------
From: Haitao Shan <[email protected]>
commit 9cfec6d097c607e36199cf0cfbb8cf5acbd8e9b2 upstream.
When running android emulator (which is based on QEMU 2.12) on certain Intel hosts with kernel version 6.3-rc1 or above, guest will freeze after loading a snapshot. This is almost 100% reproducible. By default, the android emulator will use snapshot to speed up the next launching of the same android guest. So this breaks the android emulator badly.
I tested QEMU 8.0.4 from Debian 12 with an Ubuntu 22.04 guest by running command "loadvm" after "savevm". The same issue is observed. At the same time, none of our AMD platforms is impacted. More experiments show that loading the KVM module with "enable_apicv=false" can workaround it.
The issue started to show up after commit 8e6ed96cdd50 ("KVM: x86:
fire timer when it is migrated and expired, and in oneshot mode"). However, as is pointed out by Sean Christopherson, it is introduced by commit 967235d32032 ("KVM: vmx: clear pending interrupts on KVM_SET_LAPIC"). commit 8e6ed96cdd50 ("KVM: x86: fire timer when it is migrated and expired, and in oneshot mode") just makes it easier to hit the issue.
Having both commits, the oneshot lapic timer gets fired immediately inside the KVM_SET_LAPIC call when loading the snapshot. On Intel platforms with APIC virtualization and posted interrupt processing, this eventually leads to setting the corresponding PIR bit. However, the whole PIR bits get cleared later in the same KVM_SET_LAPIC call by apicv_post_state_restore. This leads to timer interrupt lost.
The fix is to move vmx_apicv_post_state_restore to the beginning of the KVM_SET_LAPIC call and rename to vmx_apicv_pre_state_restore. What vmx_apicv_post_state_restore does is actually clearing any former apicv state and this behavior is more suitable to carry out in the beginning.
--- arch/x86/include/asm/kvm-x86-ops.h | 1 + arch/x86/include/asm/kvm_host.h | 1 + arch/x86/kvm/lapic.c | 4 ++++ arch/x86/kvm/vmx/vmx.c | 4 ++-- 4 files changed, 8 insertions(+), 2 deletions(-)
arch/x86/include/asm/kvm-x86-ops.h +1 -0
@@ -108,6 +108,7 @@ KVM_X86_OP_OPTIONAL(vcpu_blocking) KVM_X86_OP_OPTIONAL(vcpu_unblocking) KVM_X86_OP_OPTIONAL(pi_update_irte) KVM_X86_OP_OPTIONAL(pi_start_assignment) +KVM_X86_OP_OPTIONAL(apicv_pre_state_restore) KVM_X86_OP_OPTIONAL(apicv_post_state_restore) KVM_X86_OP_OPTIONAL_RET0(dy_apicv_has_pending_interrupt) KVM_X86_OP_OPTIONAL(set_hv_timer)
arch/x86/include/asm/kvm_host.h +1 -0
@@ -1690,6 +1690,7 @@ struct kvm_x86_ops {int (*pi_update_irte)(struct kvm *kvm,unsigned int host_irq,uint32_t guest_irq,bool set);void (*pi_start_assignment)(struct kvm *kvm); +void (*apicv_pre_state_restore)(struct kvm_vcpu *vcpu);void (*apicv_post_state_restore)(struct kvm_vcpu *vcpu);bool (*dy_apicv_has_pending_interrupt)(struct kvm_vcpu *vcpu);
arch/x86/kvm/lapic.c +4 -0
@@ -2649,6 +2649,8 @@ void kvm_lapic_reset(struct kvm_vcpu *vcu64 msr_val;int i; +static_call_cond (kvm_x86_apicv_pre_state_restore)(vcpu); +if (!init_event) { msr_val =APIC_DEFAULT_PHYS_BASE |MSR_IA32_APICBASE_ENABLE ;if (kvm_vcpu_is_reset_bsp (vcpu))
@@ -2960,6 +2962,8 @@ int kvm_apic_set_state(struct kvm_vcpu *struct kvm_lapic *apic = vcpu->arch.apic;int r; +static_call_cond (kvm_x86_apicv_pre_state_restore)(vcpu); +kvm_lapic_set_base (vcpu, vcpu->arch.apic_base);/* set SPIV separately to get count of SW disabled APICs right */ apic_set_spiv (apic, *((u32 *)(s->regs +APIC_SPIV )));
arch/x86/kvm/vmx/vmx.c +2 -2
@@ -6909,7 +6909,7 @@ static void vmx_load_eoi_exitmap(structvmcs_write64 (EOI_EXIT_BITMAP3 , eoi_exit_bitmap[3 ]); } -static void vmx_apicv_post_state_restore (struct kvm_vcpu *vcpu) +static void vmx_apicv_pre_state_restore (struct kvm_vcpu *vcpu) {struct vcpu_vmx *vmx =to_vmx (vcpu);
@@ -8275,7 +8275,7 @@ static struct kvm_x86_ops vmx_x86_ops __ .set_apic_access_page_addr = vmx_set_apic_access_page_addr, .refresh_apicv_exec_ctrl = vmx_refresh_apicv_exec_ctrl, .load_eoi_exitmap = vmx_load_eoi_exitmap, - .apicv_post_state_restore = vmx_apicv_post_state_restore, + .apicv_pre_state_restore = vmx_apicv_pre_state_restore, .required_apicv_inhibits = VMX_REQUIRED_APICV_INHIBITS, .hwapic_irr_update = vmx_hwapic_irr_update, .hwapic_isr_update = vmx_hwapic_isr_update,
Greg Kroah-Hartman
maintainerPATCH 246/491 mmc: sdhci-pci-gli: GL9755: Mask the replay timer timeout of AER
In reply to Greg Kroah-Hartman6.5-stable review patch. If anyone has any objections, please let me know.
------------------
From: Victor Shih <[email protected]>
commit 85dd3af64965c1c0eb7373b340a1b1f7773586b0 upstream.
Due to a flaw in the hardware design, the GL9755 replay timer frequently times out when ASPM is enabled. As a result, the warning messages will often appear in the system log when the system accesses the GL9755 PCI config. Therefore, the replay timer timeout must be masked.
--- drivers/mmc/host/sdhci-pci-gli.c | 8 ++++++++ 1 file changed, 8 insertions(+)
drivers/mmc/host/sdhci-pci-gli.c +8 -0
@@ -149,6 +149,9 @@#define PCI_GLI_9755_PM_CTRL 0xFC#define PCI_GLI_9755_PM_STATE GENMASK(1, 0) +#define PCI_GLI_9755_CORRERR_MASK 0x214 +#define PCI_GLI_9755_CORRERR_MASK_REPLAY_TIMER_TIMEOUT BIT(12) +#define SDHCI_GLI_9767_GM_BURST_SIZE 0x510#define SDHCI_GLI_9767_GM_BURST_SIZE_AXI_ALWAYS_SET BIT(8)
@@ -756,6 +759,11 @@ static void gl9755_hw_setting(struct sdh value &= ~PCI_GLI_9755_PM_STATE ;pci_write_config_dword (pdev,PCI_GLI_9755_PM_CTRL , value); +/* mask the replay timer timeout of AER */ +pci_read_config_dword (pdev,PCI_GLI_9755_CORRERR_MASK , &value); + value |=PCI_GLI_9755_CORRERR_MASK_REPLAY_TIMER_TIMEOUT ; +pci_write_config_dword (pdev,PCI_GLI_9755_CORRERR_MASK , value); +gl9755_wt_off (pdev); }
Greg Kroah-Hartman
maintainerPATCH 247/491 sched: psi: fix unprivileged polling against cgroups
In reply to Greg Kroah-Hartman6.5-stable review patch. If anyone has any objections, please let me know.
------------------
From: Johannes Weiner <[email protected]>
commit 8b39d20eceeda6c4eb23df1497f9ed2fffdc8f69 upstream.
519fabc7aaba ("psi: remove 500ms min window size limitation for triggers") breaks unprivileged psi polling on cgroups.
Historically, we had a privilege check for polling in the open() of a pressure file in /proc, but were erroneously missing it for the open() of cgroup pressure files.
When unprivileged polling was introduced in d82caa273565 ("sched/psi:
Allow unprivileged polling of N*2s period"), it needed to filter privileges depending on the exact polling parameters, and as such moved the CAP_SYS_RESOURCE check from the proc open() callback to psi_trigger_create(). Both the proc files as well as cgroup files go through this during write(). This implicitly added the missing check for privileges required for HT polling for cgroups.
When 519fabc7aaba ("psi: remove 500ms min window size limitation for triggers") followed right after to remove further restrictions on the RT polling window, it incorrectly assumed the cgroup privilege check was still missing and added it to the cgroup open(), mirroring what we used to do for proc files in the past.
As a result, unprivileged poll requests that would be supported now get rejected when opening the cgroup pressure file for writing.
Remove the cgroup open() check. psi_trigger_create() handles it.
--- kernel/cgroup/cgroup.c | 12 ------------ 1 file changed, 12 deletions(-)
kernel/cgroup/cgroup.c +0 -12
@@ -3836,14 +3836,6 @@ static __poll_t cgroup_pressure_poll(strreturn psi_trigger_poll (&ctx->psi.trigger, of->file, pt); } -static int cgroup_pressure_open (struct kernfs_open_file *of) -{ -if (of->file->f_mode &FMODE_WRITE && !capable (CAP_SYS_RESOURCE )) -return -EPERM ; - -return 0 ; -} -static void cgroup_pressure_release (struct kernfs_open_file *of) {struct cgroup_file_ctx *ctx = of->priv;
@@ -5243,7 +5235,6 @@ static struct cftype cgroup_psi_files[] { .name = "io.pressure", .file_offset = offsetof(struct cgroup, psi_files[PSI_IO]), - .open = cgroup_pressure_open, .seq_show = cgroup_io_pressure_show, .write = cgroup_io_pressure_write, .poll = cgroup_pressure_poll,
@@ -5252,7 +5243,6 @@ static struct cftype cgroup_psi_files[] { .name = "memory.pressure", .file_offset = offsetof(struct cgroup, psi_files[PSI_MEM]), - .open = cgroup_pressure_open, .seq_show = cgroup_memory_pressure_show, .write = cgroup_memory_pressure_write, .poll = cgroup_pressure_poll,
@@ -5261,7 +5251,6 @@ static struct cftype cgroup_psi_files[] { .name = "cpu.pressure", .file_offset = offsetof(struct cgroup, psi_files[PSI_CPU]), - .open = cgroup_pressure_open, .seq_show = cgroup_cpu_pressure_show, .write = cgroup_cpu_pressure_write, .poll = cgroup_pressure_poll,
@@ -5271,7 +5260,6 @@ static struct cftype cgroup_psi_files[] { .name = "irq.pressure", .file_offset = offsetof(struct cgroup, psi_files[PSI_IRQ]), - .open = cgroup_pressure_open, .seq_show = cgroup_irq_pressure_show, .write = cgroup_irq_pressure_write, .poll = cgroup_pressure_poll,
Greg Kroah-Hartman
maintainerPATCH 248/491 audit: dont take task_lock() in audit_exe_compare() code path
In reply to Greg Kroah-Hartman6.5-stable review patch. If anyone has any objections, please let me know.
------------------
From: Paul Moore <[email protected]>
commit 47846d51348dd62e5231a83be040981b17c955fa upstream.
The get_task_exe_file() function locks the given task with task_lock() which when used inside audit_exe_compare() can cause deadlocks on systems that generate audit records when the task_lock() is held. We resolve this problem with two changes: ignoring those cases where the task being audited is not the current task, and changing our approach to obtaining the executable file struct to not require task_lock().
With the intent of the audit exe filter being to filter on audit events generated by processes started by the specified executable, it makes sense that we would only want to use the exe filter on audit records associated with the currently executing process, e.g. @current. If we are asked to filter records using a non-@current task_struct we can safely ignore the exe filter without negatively impacting the admin's expectations for the exe filter.
Knowing that we only have to worry about filtering the currently executing task in audit_exe_compare() we can do away with the task_lock() and call get_mm_exe_file() with @current->mm directly.
--- kernel/audit_watch.c | 9 ++++++++- 1 file changed, 8 insertions(+), 1 deletion(-)
kernel/audit_watch.c +8 -1
@@ -527,11 +527,18 @@ int audit_exe_compare(struct task_structunsigned long ino;dev_t dev; - exe_file =get_task_exe_file (tsk); +/* only do exe filtering if we are recording @current events/records */ +if (tsk != current) +return 0 ; + +if (WARN_ON_ONCE (!current->mm)) +return 0 ; + exe_file =get_mm_exe_file (current->mm);if (!exe_file)return 0 ; ino =file_inode (exe_file)->i_ino; dev =file_inode (exe_file)->i_sb->s_dev;fput (exe_file); +return audit_mark_compare (mark, ino, dev); }
Greg Kroah-Hartman
maintainerPATCH 249/491 audit: dont WARN_ON_ONCE(!current->mm) in audit_exe_compare()
In reply to Greg Kroah-Hartman6.5-stable review patch. If anyone has any objections, please let me know.
------------------
From: Paul Moore <[email protected]>
commit 969d90ec212bae4b45bf9d21d7daa30aa6cf055e upstream.
eBPF can end up calling into the audit code from some odd places, and some of these places don't have @current set properly so we end up tripping the WARN_ON_ONCE(!current->mm) near the top of audit_exe_compare(). While the basic !current->mm check is good, the WARN_ON_ONCE() results in some scary console messages so let's drop that and just do the regular !current->mm check to avoid problems.
--- kernel/audit_watch.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
kernel/audit_watch.c +1 -1
@@ -531,7 +531,7 @@ int audit_exe_compare(struct task_structif (tsk != current)return 0 ; -if (WARN_ON_ONCE (!current->mm)) +if (!current->mm)return 0 ; exe_file =get_mm_exe_file (current->mm);if (!exe_file)
Greg Kroah-Hartman
maintainerPATCH 250/491 proc: sysctl: prevent aliased sysctls from getting passed to init
In reply to Greg Kroah-Hartman6.5-stable review patch. If anyone has any objections, please let me know.
------------------
From: Krister Johansen <[email protected]>
commit 8001f49394e353f035306a45bcf504f06fca6355 upstream.
The code that checks for unknown boot options is unaware of the sysctl alias facility, which maps bootparams to sysctl values. If a user sets an old value that has a valid alias, a message about an invalid parameter will be printed during boot, and the parameter will get passed to init. Fix by checking for the existence of aliased parameters in the unknown boot parameter code. If an alias exists, don't return an error or pass the value to init.
--- fs/proc/proc_sysctl.c | 7 +++++++ include/linux/sysctl.h | 6 ++++++ init/main.c | 4 ++++ 3 files changed, 17 insertions(+)
fs/proc/proc_sysctl.c +7 -0
@@ -1590,6 +1590,13 @@ static const char *sysctl_find_alias(chareturn NULL ; } +bool sysctl_is_alias (char *param) +{ +const char *alias =sysctl_find_alias (param); + +return alias !=NULL ; +} +/* Set sysctl value passed on kernel command line. */ static int process_sysctl_arg (char *param,char *val,const char *unused,void *arg)
include/linux/sysctl.h +6 -0
@@ -227,6 +227,7 @@ extern void __register_sysctl_init(constextern struct ctl_table_header *register_sysctl_mount_point (const char *path);void do_sysctl_args (void ); +bool sysctl_is_alias (char *param); int do_proc_douintvec(struct ctl_table *table, int write, void *buffer, size_t *lenp, loff_t *ppos, int (*conv)(unsigned long *lvalp,
@@ -270,6 +271,11 @@ static inline void setup_sysctl_set(strustatic inline void do_sysctl_args (void ) { } + +static inline bool sysctl_is_alias (char *param) +{ +return false; +}#endif /* CONFIG_SYSCTL */ int sysctl_max_threads(struct ctl_table *table, int write, void *buffer,
init/main.c +4 -0
@@ -530,6 +530,10 @@ static int __init unknown_bootoption(cha {size_t len =strlen (param); +/* Handle params aliased to sysctls */ +if (sysctl_is_alias (param)) +return 0 ; +repair_env_string (param, val);/* Handle obsolete-style parameters */
Greg Kroah-Hartman
maintainerPATCH 251/491 tty/sysrq: replace smp_processor_id() with get_cpu()
In reply to Greg Kroah-Hartman6.5-stable review patch. If anyone has any objections, please let me know.
------------------
From: Muhammad Usama Anjum <[email protected]>
commit dd976a97d15b47656991e185a94ef42a0fa5cfd4 upstream.
The smp_processor_id() shouldn't be called from preemptible code. Instead use get_cpu() and put_cpu() which disables preemption in addition to getting the processor id. Enable preemption back after calling schedule_work() to make sure that the work gets scheduled on all cores other than the current core. We want to avoid a scenario where current core's stack trace is printed multiple times and one core's stack trace isn't printed because of scheduling of current task.
This fixes the following bug:
[ 119.143590] sysrq: Show backtrace of all active CPUs [ 119.143902] BUG: using smp_processor_id() in preemptible [00000000] code: bash/873 [ 119.144586] caller is debug_smp_processor_id+0x20/0x30 [ 119.144827] CPU: 6 PID: 873 Comm: bash Not tainted 5.10.124-dirty #3 [ 119.144861] Hardware name: QEMU QEMU Virtual Machine, BIOS 2023.05-1 07/22/2023 [ 119.145053] Call trace: [ 119.145093] dump_backtrace+0x0/0x1a0 [ 119.145122] show_stack+0x18/0x70 [ 119.145141] dump_stack+0xc4/0x11c [ 119.145159] check_preemption_disabled+0x100/0x110 [ 119.145175] debug_smp_processor_id+0x20/0x30 [ 119.145195] sysrq_handle_showallcpus+0x20/0xc0 [ 119.145211] __handle_sysrq+0x8c/0x1a0 [ 119.145227] write_sysrq_trigger+0x94/0x12c [ 119.145247] proc_reg_write+0xa8/0xe4 [ 119.145266] vfs_write+0xec/0x280 [ 119.145282] ksys_write+0x6c/0x100 [ 119.145298] __arm64_sys_write+0x20/0x30 [ 119.145315] el0_svc_common.constprop.0+0x78/0x1e4 [ 119.145332] do_el0_svc+0x24/0x8c [ 119.145348] el0_svc+0x10/0x20 [ 119.145364] el0_sync_handler+0x134/0x140 [ 119.145381] el0_sync+0x180/0x1c0
--- drivers/tty/sysrq.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)
drivers/tty/sysrq.c +2 -1
@@ -263,13 +263,14 @@ static void sysrq_handle_showallcpus(intif (in_hardirq ()) regs =get_irq_regs (); -pr_info ("CPU%d:\n" ,smp_processor_id ()); +pr_info ("CPU%d:\n" ,get_cpu ());if (regs)show_regs (regs);else show_stack (NULL ,NULL ,KERN_INFO );schedule_work (&sysrq_showallcpus); +put_cpu (); } }
Greg Kroah-Hartman
maintainerPATCH 252/491 tty: serial: meson: fix hard LOCKUP on crtscts mode
In reply to Greg Kroah-Hartman6.5-stable review patch. If anyone has any objections, please let me know.
------------------
From: Pavel Krasavin <[email protected]>
commit 2a1d728f20edeee7f26dc307ed9df4e0d23947ab upstream.
There might be hard lockup if we set crtscts mode on port without RTS/CTS configured:
# stty -F /dev/ttyAML6 crtscts; echo 1 > /dev/ttyAML6; echo 2 > /dev/ttyAML6 [ 95.890386] rcu: INFO: rcu_preempt detected stalls on CPUs/tasks: [ 95.890857] rcu: 3-...0: (201 ticks this GP) idle=e33c/1/0x4000000000000000 softirq=5844/5846 fqs=4984 [ 95.900212] rcu: (detected by 2, t=21016 jiffies, g=7753, q=296 ncpus=4) [ 95.906972] Task dump for CPU 3: [ 95.910178] task:bash state:R running task stack:0 pid:205 ppid:1 flags:0x00000202 [ 95.920059] Call trace: [ 95.922485] __switch_to+0xe4/0x168 [ 95.925951] 0xffffff8003477508 [ 95.974379] watchdog: Watchdog detected hard LOCKUP on cpu 3 [ 95.974424] Modules linked in: 88x2cs(O) rtc_meson_vrtc
Possible solution would be to not allow to setup crtscts on such port.
Tested on S905X3 based board.
--- drivers/tty/serial/meson_uart.c | 14 +++++++++++--- 1 file changed, 11 insertions(+), 3 deletions(-)
drivers/tty/serial/meson_uart.c +11 -3
@@ -379,10 +379,14 @@ static void meson_uart_set_termios(strucelse val |=AML_UART_STOP_BIT_1SB ; -if (cflags &CRTSCTS ) - val &= ~AML_UART_TWO_WIRE_EN ; -else +if (cflags &CRTSCTS ) { +if (port->flags &UPF_HARD_FLOW ) + val &= ~AML_UART_TWO_WIRE_EN ; +else + termios->c_cflag &= ~CRTSCTS ; + }else { val |=AML_UART_TWO_WIRE_EN ; + }writel (val, port->membase +AML_UART_CONTROL );
@@ -697,6 +701,7 @@ static int meson_uart_probe(struct platfu32 fifosize =64 ;/* Default is 64, 128 for EE UART_0 */ int ret =0 ;int irq; +bool has_rtscts;if (pdev->dev.of_node) pdev->id =of_alias_get_id (pdev->dev.of_node,"serial" );
@@ -724,6 +729,7 @@ static int meson_uart_probe(struct platfreturn irq;of_property_read_u32 (pdev->dev.of_node,"fifo-size" , &fifosize); + has_rtscts =of_property_read_bool (pdev->dev.of_node,"uart-has-rtscts" );if (meson_ports[pdev->id]) {dev_err (&pdev->dev,"port %d already allocated\n" , pdev->id);
@@ -743,6 +749,8 @@ static int meson_uart_probe(struct platf port->mapsize =resource_size (res_mem); port->irq = irq; port->flags =UPF_BOOT_AUTOCONF |UPF_LOW_LATENCY ; +if (has_rtscts) + port->flags |=UPF_HARD_FLOW ; port->has_sysrq =IS_ENABLED (CONFIG_SERIAL_MESON_CONSOLE ); port->dev = &pdev->dev; port->line = pdev->id;
Greg Kroah-Hartman
maintainerPATCH 253/491 hvc/xen: fix console unplug
In reply to Greg Kroah-Hartman6.5-stable review patch. If anyone has any objections, please let me know.
------------------
From: David Woodhouse <[email protected]>
commit a30badfd7c13fc8763a9e10c5a12ba7f81515a55 upstream.
On unplug of a Xen console, xencons_disconnect_backend() unconditionally calls free_irq() via unbind_from_irqhandler(), causing a warning of freeing an already-free IRQ:
(qemu) device_del con1
[ 32.050919] ------------[ cut here ]------------ [ 32.050942] Trying to free already-free IRQ 33 [ 32.050990] WARNING: CPU: 0 PID: 51 at kernel/irq/manage.c:1895 __free_irq+0x1d4/0x330
It should be using evtchn_put() to tear down the event channel binding, and let the Linux IRQ side of it be handled by notifier_del_irq() through the HVC code.
On which topic... xencons_disconnect_backend() should call hvc_remove() *first*, rather than tearing down the event channel and grant mapping while they are in use. And then the IRQ is guaranteed to be freed by the time it's torn down by evtchn_put().
Since evtchn_put() also closes the actual event channel, avoid calling xenbus_free_evtchn() except in the failure path where the IRQ was not successfully set up.
However, calling hvc_remove() at the start of xencons_disconnect_backend() still isn't early enough. An unplug request is indicated by the backend setting its state to XenbusStateClosing, which triggers a notification to xencons_backend_changed(), which... does nothing except set its own frontend state directly to XenbusStateClosed without *actually* tearing down the HVC device or, you know, making sure it isn't actively in use.
So the backend sees the guest frontend set its state to XenbusStateClosed and stops servicing the interrupt... and the guest spins for ever in the domU_write_console() function waiting for the ring to drain.
Fix that one by calling hvc_remove() from xencons_backend_changed() before signalling to the backend that it's OK to proceed with the removal.
Tested with 'dd if=/dev/zero of=/dev/hvc1' while telling Qemu to remove the console device.
--- drivers/tty/hvc/hvc_xen.c | 32 ++++++++++++++++++++++++-------- 1 file changed, 24 insertions(+), 8 deletions(-)
drivers/tty/hvc/hvc_xen.c +24 -8
@@ -377,18 +377,21 @@ void xen_console_resume(void)#ifdef CONFIG_HVC_XEN_FRONTEND static void xencons_disconnect_backend (struct xencons_info *info) { -if (info->irq >0 ) -unbind_from_irqhandler (info->irq,NULL ); - info->irq =0 ; +if (info->hvc !=NULL ) +hvc_remove (info->hvc); + info->hvc =NULL ; +if (info->irq >0 ) { +evtchn_put (info->evtchn); + info->irq =0 ; + info->evtchn =0 ; + } +/* evtchn_put() will also close it so this is only an error path */ if (info->evtchn >0 )xenbus_free_evtchn (info->xbdev, info->evtchn); info->evtchn =0 ;if (info->gntref >0 )gnttab_free_grant_references (info->gntref); info->gntref =0 ; -if (info->hvc !=NULL ) -hvc_remove (info->hvc); - info->hvc =NULL ; }static void xencons_free (struct xencons_info *info)
@@ -553,10 +556,23 @@ static void xencons_backend_changed(struif (dev->state == XenbusStateClosed)break ; fallthrough;/* Missed the backend's CLOSING state */ -case XenbusStateClosing: +case XenbusStateClosing: { +struct xencons_info *info =dev_get_drvdata (&dev->dev);; + +/* +* Don't tear down the evtchn and grant ref before the other +* end has disconnected, but do stop userspace from trying +* to use the device before we allow the backend to close. +*/ +if (info->hvc) { +hvc_remove (info->hvc); + info->hvc =NULL ; + } +xenbus_frontend_closed (dev);break ; } + } }static const struct xenbus_device_id xencons_ids[] = {
@@ -616,7 +632,7 @@ static int __init xen_hvc_init(void)list_del (&info->list);spin_unlock_irqrestore (&xencons_lock, flags);if (info->irq) -unbind_from_irqhandler (info->irq,NULL ); +evtchn_put (info->evtchn);kfree (info);return r; }
Greg Kroah-Hartman
maintainerPATCH 254/491 hvc/xen: fix error path in xen_hvc_init() to always register frontend driver
In reply to Greg Kroah-Hartman6.5-stable review patch. If anyone has any objections, please let me know.
------------------
From: David Woodhouse <[email protected]>
commit 2704c9a5593f4a47620c12dad78838ca62b52f48 upstream.
The xen_hvc_init() function should always register the frontend driver, even when there's no primary console — as there may be secondary consoles. (Qemu can always add secondary consoles, but only the toolstack can add the primary because it's special.)
--- drivers/tty/hvc/hvc_xen.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-)
drivers/tty/hvc/hvc_xen.c +3 -2
@@ -604,7 +604,7 @@ static int __init xen_hvc_init(void) ops = &dom0_hvc_ops; r =xen_initial_domain_console_init ();if (r <0 ) -return r; + goto register_fe; info =vtermno_to_xencons (HVC_COOKIE ); }else { ops = &domU_hvc_ops;
@@ -613,7 +613,7 @@ static int __init xen_hvc_init(void)else r =xen_pv_console_init ();if (r <0 ) -return r; + goto register_fe; info =vtermno_to_xencons (HVC_COOKIE ); info->irq =bind_evtchn_to_irq_lateeoi (info->evtchn);
@@ -638,6 +638,7 @@ static int __init xen_hvc_init(void) } r =0 ; + register_fe: #ifdef CONFIG_HVC_XEN_FRONTEND r =xenbus_register_frontend (&xencons_driver);#endif