* [PATCH 5.10 001/120] USB: serial: cp210x: add pid/vid for WSDA-200-USB
2021-02-08 14:59 [PATCH 5.10 000/120] 5.10.15-rc1 review Greg Kroah-Hartman
@ 2021-02-08 14:59 ` Greg Kroah-Hartman
2021-02-08 14:59 ` [PATCH 5.10 002/120] USB: serial: cp210x: add new VID/PID for supporting Teraoka AD2000 Greg Kroah-Hartman
` (125 subsequent siblings)
126 siblings, 0 replies; 140+ messages in thread
From: Greg Kroah-Hartman @ 2021-02-08 14:59 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, Pho Tran, Johan Hovold
From: Pho Tran <Pho.Tran@silabs.com>
commit 3c4f6ecd93442f4376a58b38bb40ee0b8c46e0e6 upstream.
Information pid/vid of WSDA-200-USB, Lord corporation company:
vid: 199b
pid: ba30
Signed-off-by: Pho Tran <pho.tran@silabs.com>
[ johan: amend comment with product name ]
Cc: stable@vger.kernel.org
Signed-off-by: Johan Hovold <johan@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/usb/serial/cp210x.c | 1 +
1 file changed, 1 insertion(+)
--- a/drivers/usb/serial/cp210x.c
+++ b/drivers/usb/serial/cp210x.c
@@ -204,6 +204,7 @@ static const struct usb_device_id id_tab
{ USB_DEVICE(0x1901, 0x0194) }, /* GE Healthcare Remote Alarm Box */
{ USB_DEVICE(0x1901, 0x0195) }, /* GE B850/B650/B450 CP2104 DP UART interface */
{ USB_DEVICE(0x1901, 0x0196) }, /* GE B850 CP2105 DP UART interface */
+ { USB_DEVICE(0x199B, 0xBA30) }, /* LORD WSDA-200-USB */
{ USB_DEVICE(0x19CF, 0x3000) }, /* Parrot NMEA GPS Flight Recorder */
{ USB_DEVICE(0x1ADB, 0x0001) }, /* Schweitzer Engineering C662 Cable */
{ USB_DEVICE(0x1B1C, 0x1C00) }, /* Corsair USB Dongle */
^ permalink raw reply [flat|nested] 140+ messages in thread* [PATCH 5.10 002/120] USB: serial: cp210x: add new VID/PID for supporting Teraoka AD2000
2021-02-08 14:59 [PATCH 5.10 000/120] 5.10.15-rc1 review Greg Kroah-Hartman
2021-02-08 14:59 ` [PATCH 5.10 001/120] USB: serial: cp210x: add pid/vid for WSDA-200-USB Greg Kroah-Hartman
@ 2021-02-08 14:59 ` Greg Kroah-Hartman
2021-02-08 14:59 ` [PATCH 5.10 003/120] USB: serial: option: Adding support for Cinterion MV31 Greg Kroah-Hartman
` (124 subsequent siblings)
126 siblings, 0 replies; 140+ messages in thread
From: Greg Kroah-Hartman @ 2021-02-08 14:59 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, Chenxin Jin, Johan Hovold
From: Chenxin Jin <bg4akv@hotmail.com>
commit 43377df70480f82919032eb09832e9646a8a5efb upstream.
Teraoka AD2000 uses the CP210x driver, but the chip VID/PID is
customized with 0988/0578. We need the driver to support the new
VID/PID.
Signed-off-by: Chenxin Jin <bg4akv@hotmail.com>
Cc: stable@vger.kernel.org
Signed-off-by: Johan Hovold <johan@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/usb/serial/cp210x.c | 1 +
1 file changed, 1 insertion(+)
--- a/drivers/usb/serial/cp210x.c
+++ b/drivers/usb/serial/cp210x.c
@@ -64,6 +64,7 @@ static const struct usb_device_id id_tab
{ USB_DEVICE(0x08e6, 0x5501) }, /* Gemalto Prox-PU/CU contactless smartcard reader */
{ USB_DEVICE(0x08FD, 0x000A) }, /* Digianswer A/S , ZigBee/802.15.4 MAC Device */
{ USB_DEVICE(0x0908, 0x01FF) }, /* Siemens RUGGEDCOM USB Serial Console */
+ { USB_DEVICE(0x0988, 0x0578) }, /* Teraoka AD2000 */
{ USB_DEVICE(0x0B00, 0x3070) }, /* Ingenico 3070 */
{ USB_DEVICE(0x0BED, 0x1100) }, /* MEI (TM) Cashflow-SC Bill/Voucher Acceptor */
{ USB_DEVICE(0x0BED, 0x1101) }, /* MEI series 2000 Combo Acceptor */
^ permalink raw reply [flat|nested] 140+ messages in thread* [PATCH 5.10 003/120] USB: serial: option: Adding support for Cinterion MV31
2021-02-08 14:59 [PATCH 5.10 000/120] 5.10.15-rc1 review Greg Kroah-Hartman
2021-02-08 14:59 ` [PATCH 5.10 001/120] USB: serial: cp210x: add pid/vid for WSDA-200-USB Greg Kroah-Hartman
2021-02-08 14:59 ` [PATCH 5.10 002/120] USB: serial: cp210x: add new VID/PID for supporting Teraoka AD2000 Greg Kroah-Hartman
@ 2021-02-08 14:59 ` Greg Kroah-Hartman
2021-02-08 14:59 ` [PATCH 5.10 004/120] usb: host: xhci: mvebu: make USB 3.0 PHY optional for Armada 3720 Greg Kroah-Hartman
` (123 subsequent siblings)
126 siblings, 0 replies; 140+ messages in thread
From: Greg Kroah-Hartman @ 2021-02-08 14:59 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, Christoph Schemmel, Johan Hovold
From: Christoph Schemmel <christoph.schemmel@gmail.com>
commit e478d6029dca9d8462f426aee0d32896ef64f10f upstream.
Adding support for Cinterion device MV31 for enumeration with
PID 0x00B3 and 0x00B7.
usb-devices output for 0x00B3
T: Bus=04 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#= 6 Spd=5000 MxCh= 0
D: Ver= 3.20 Cls=ef(misc ) Sub=02 Prot=01 MxPS= 9 #Cfgs= 1
P: Vendor=1e2d ProdID=00b3 Rev=04.14
S: Manufacturer=Cinterion
S: Product=Cinterion PID 0x00B3 USB Mobile Broadband
S: SerialNumber=b3246eed
C: #Ifs= 6 Cfg#= 1 Atr=a0 MxPwr=896mA
I: If#=0x0 Alt= 0 #EPs= 1 Cls=02(commc) Sub=0e Prot=00 Driver=cdc_mbim
I: If#=0x1 Alt= 1 #EPs= 2 Cls=0a(data ) Sub=00 Prot=02 Driver=cdc_mbim
I: If#=0x2 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=option
I: If#=0x3 Alt= 0 #EPs= 1 Cls=ff(vend.) Sub=ff Prot=ff Driver=cdc_wdm
I: If#=0x4 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=option
I: If#=0x5 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=30 Driver=option
usb-devices output for 0x00B7
T: Bus=04 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#= 5 Spd=5000 MxCh= 0
D: Ver= 3.20 Cls=ef(misc ) Sub=02 Prot=01 MxPS= 9 #Cfgs= 1
P: Vendor=1e2d ProdID=00b7 Rev=04.14
S: Manufacturer=Cinterion
S: Product=Cinterion PID 0x00B3 USB Mobile Broadband
S: SerialNumber=b3246eed
C: #Ifs= 4 Cfg#= 1 Atr=a0 MxPwr=896mA
I: If#=0x0 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=ff Driver=qmi_wwan
I: If#=0x1 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=option
I: If#=0x2 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=option
I: If#=0x3 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=30 Driver=option
Signed-off-by: Christoph Schemmel <christoph.schemmel@gmail.com>
Cc: stable@vger.kernel.org
Signed-off-by: Johan Hovold <johan@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/usb/serial/option.c | 6 ++++++
1 file changed, 6 insertions(+)
--- a/drivers/usb/serial/option.c
+++ b/drivers/usb/serial/option.c
@@ -425,6 +425,8 @@ static void option_instat_callback(struc
#define CINTERION_PRODUCT_AHXX_2RMNET 0x0084
#define CINTERION_PRODUCT_AHXX_AUDIO 0x0085
#define CINTERION_PRODUCT_CLS8 0x00b0
+#define CINTERION_PRODUCT_MV31_MBIM 0x00b3
+#define CINTERION_PRODUCT_MV31_RMNET 0x00b7
/* Olivetti products */
#define OLIVETTI_VENDOR_ID 0x0b3c
@@ -1914,6 +1916,10 @@ static const struct usb_device_id option
{ USB_DEVICE(SIEMENS_VENDOR_ID, CINTERION_PRODUCT_HC25_MDMNET) },
{ USB_DEVICE(SIEMENS_VENDOR_ID, CINTERION_PRODUCT_HC28_MDM) }, /* HC28 enumerates with Siemens or Cinterion VID depending on FW revision */
{ USB_DEVICE(SIEMENS_VENDOR_ID, CINTERION_PRODUCT_HC28_MDMNET) },
+ { USB_DEVICE_INTERFACE_CLASS(CINTERION_VENDOR_ID, CINTERION_PRODUCT_MV31_MBIM, 0xff),
+ .driver_info = RSVD(3)},
+ { USB_DEVICE_INTERFACE_CLASS(CINTERION_VENDOR_ID, CINTERION_PRODUCT_MV31_RMNET, 0xff),
+ .driver_info = RSVD(0)},
{ USB_DEVICE(OLIVETTI_VENDOR_ID, OLIVETTI_PRODUCT_OLICARD100),
.driver_info = RSVD(4) },
{ USB_DEVICE(OLIVETTI_VENDOR_ID, OLIVETTI_PRODUCT_OLICARD120),
^ permalink raw reply [flat|nested] 140+ messages in thread* [PATCH 5.10 004/120] usb: host: xhci: mvebu: make USB 3.0 PHY optional for Armada 3720
2021-02-08 14:59 [PATCH 5.10 000/120] 5.10.15-rc1 review Greg Kroah-Hartman
` (2 preceding siblings ...)
2021-02-08 14:59 ` [PATCH 5.10 003/120] USB: serial: option: Adding support for Cinterion MV31 Greg Kroah-Hartman
@ 2021-02-08 14:59 ` Greg Kroah-Hartman
2021-02-08 14:59 ` [PATCH 5.10 005/120] USB: gadget: legacy: fix an error code in eth_bind() Greg Kroah-Hartman
` (122 subsequent siblings)
126 siblings, 0 replies; 140+ messages in thread
From: Greg Kroah-Hartman @ 2021-02-08 14:59 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Tomasz Maciej Nowak, Mathias Nyman,
Pali Rohár, Yoshihiro Shimoda
From: Pali Rohár <pali@kernel.org>
commit 3241929b67d28c83945d3191c6816a3271fd6b85 upstream.
Older ATF does not provide SMC call for USB 3.0 phy power on functionality
and therefore initialization of xhci-hcd is failing when older version of
ATF is used. In this case phy_power_on() function returns -EOPNOTSUPP.
[ 3.108467] mvebu-a3700-comphy d0018300.phy: unsupported SMC call, try updating your firmware
[ 3.117250] phy phy-d0018300.phy.0: phy poweron failed --> -95
[ 3.123465] xhci-hcd: probe of d0058000.usb failed with error -95
This patch introduces a new plat_setup callback for xhci platform drivers
which is called prior calling usb_add_hcd() function. This function at its
beginning skips PHY init if hcd->skip_phy_initialization is set.
Current init_quirk callback for xhci platform drivers is called from
xhci_plat_setup() function which is called after chip reset completes.
It happens in the middle of the usb_add_hcd() function and therefore this
callback cannot be used for setting if PHY init should be skipped or not.
For Armada 3720 this patch introduce a new xhci_mvebu_a3700_plat_setup()
function configured as a xhci platform plat_setup callback. This new
function calls phy_power_on() and in case it returns -EOPNOTSUPP then
XHCI_SKIP_PHY_INIT quirk is set to instruct xhci-plat to skip PHY
initialization.
This patch fixes above failure by ignoring 'not supported' error in
xhci-hcd driver. In this case it is expected that phy is already power on.
It fixes initialization of xhci-hcd on Espressobin boards where is older
Marvell's Arm Trusted Firmware without SMC call for USB 3.0 phy power.
This is regression introduced in commit bd3d25b07342 ("arm64: dts: marvell:
armada-37xx: link USB hosts with their PHYs") where USB 3.0 phy was defined
and therefore xhci-hcd on Espressobin with older ATF started failing.
Fixes: bd3d25b07342 ("arm64: dts: marvell: armada-37xx: link USB hosts with their PHYs")
Cc: <stable@vger.kernel.org> # 5.1+: ea17a0f153af: phy: marvell: comphy: Convert internal SMCC firmware return codes to errno
Cc: <stable@vger.kernel.org> # 5.1+: f768e718911e: usb: host: xhci-plat: add priv quirk for skip PHY initialization
Tested-by: Tomasz Maciej Nowak <tmn505@gmail.com>
Tested-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com> # On R-Car
Reviewed-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com> # xhci-plat
Acked-by: Mathias Nyman <mathias.nyman@linux.intel.com>
Signed-off-by: Pali Rohár <pali@kernel.org>
Link: https://lore.kernel.org/r/20210201150803.7305-1-pali@kernel.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/usb/host/xhci-mvebu.c | 42 ++++++++++++++++++++++++++++++++++++++++++
drivers/usb/host/xhci-mvebu.h | 6 ++++++
drivers/usb/host/xhci-plat.c | 20 +++++++++++++++++++-
drivers/usb/host/xhci-plat.h | 1 +
4 files changed, 68 insertions(+), 1 deletion(-)
--- a/drivers/usb/host/xhci-mvebu.c
+++ b/drivers/usb/host/xhci-mvebu.c
@@ -8,6 +8,7 @@
#include <linux/mbus.h>
#include <linux/of.h>
#include <linux/platform_device.h>
+#include <linux/phy/phy.h>
#include <linux/usb.h>
#include <linux/usb/hcd.h>
@@ -73,6 +74,47 @@ int xhci_mvebu_mbus_init_quirk(struct us
return 0;
}
+
+int xhci_mvebu_a3700_plat_setup(struct usb_hcd *hcd)
+{
+ struct xhci_hcd *xhci = hcd_to_xhci(hcd);
+ struct device *dev = hcd->self.controller;
+ struct phy *phy;
+ int ret;
+
+ /* Old bindings miss the PHY handle */
+ phy = of_phy_get(dev->of_node, "usb3-phy");
+ if (IS_ERR(phy) && PTR_ERR(phy) == -EPROBE_DEFER)
+ return -EPROBE_DEFER;
+ else if (IS_ERR(phy))
+ goto phy_out;
+
+ ret = phy_init(phy);
+ if (ret)
+ goto phy_put;
+
+ ret = phy_set_mode(phy, PHY_MODE_USB_HOST_SS);
+ if (ret)
+ goto phy_exit;
+
+ ret = phy_power_on(phy);
+ if (ret == -EOPNOTSUPP) {
+ /* Skip initializatin of XHCI PHY when it is unsupported by firmware */
+ dev_warn(dev, "PHY unsupported by firmware\n");
+ xhci->quirks |= XHCI_SKIP_PHY_INIT;
+ }
+ if (ret)
+ goto phy_exit;
+
+ phy_power_off(phy);
+phy_exit:
+ phy_exit(phy);
+phy_put:
+ of_phy_put(phy);
+phy_out:
+
+ return 0;
+}
int xhci_mvebu_a3700_init_quirk(struct usb_hcd *hcd)
{
--- a/drivers/usb/host/xhci-mvebu.h
+++ b/drivers/usb/host/xhci-mvebu.h
@@ -12,12 +12,18 @@ struct usb_hcd;
#if IS_ENABLED(CONFIG_USB_XHCI_MVEBU)
int xhci_mvebu_mbus_init_quirk(struct usb_hcd *hcd);
+int xhci_mvebu_a3700_plat_setup(struct usb_hcd *hcd);
int xhci_mvebu_a3700_init_quirk(struct usb_hcd *hcd);
#else
static inline int xhci_mvebu_mbus_init_quirk(struct usb_hcd *hcd)
{
return 0;
}
+
+static inline int xhci_mvebu_a3700_plat_setup(struct usb_hcd *hcd)
+{
+ return 0;
+}
static inline int xhci_mvebu_a3700_init_quirk(struct usb_hcd *hcd)
{
--- a/drivers/usb/host/xhci-plat.c
+++ b/drivers/usb/host/xhci-plat.c
@@ -44,6 +44,16 @@ static void xhci_priv_plat_start(struct
priv->plat_start(hcd);
}
+static int xhci_priv_plat_setup(struct usb_hcd *hcd)
+{
+ struct xhci_plat_priv *priv = hcd_to_xhci_priv(hcd);
+
+ if (!priv->plat_setup)
+ return 0;
+
+ return priv->plat_setup(hcd);
+}
+
static int xhci_priv_init_quirk(struct usb_hcd *hcd)
{
struct xhci_plat_priv *priv = hcd_to_xhci_priv(hcd);
@@ -111,6 +121,7 @@ static const struct xhci_plat_priv xhci_
};
static const struct xhci_plat_priv xhci_plat_marvell_armada3700 = {
+ .plat_setup = xhci_mvebu_a3700_plat_setup,
.init_quirk = xhci_mvebu_a3700_init_quirk,
};
@@ -330,7 +341,14 @@ static int xhci_plat_probe(struct platfo
hcd->tpl_support = of_usb_host_tpl_support(sysdev->of_node);
xhci->shared_hcd->tpl_support = hcd->tpl_support;
- if (priv && (priv->quirks & XHCI_SKIP_PHY_INIT))
+
+ if (priv) {
+ ret = xhci_priv_plat_setup(hcd);
+ if (ret)
+ goto disable_usb_phy;
+ }
+
+ if ((xhci->quirks & XHCI_SKIP_PHY_INIT) || (priv && (priv->quirks & XHCI_SKIP_PHY_INIT)))
hcd->skip_phy_initialization = 1;
if (priv && (priv->quirks & XHCI_SG_TRB_CACHE_SIZE_QUIRK))
--- a/drivers/usb/host/xhci-plat.h
+++ b/drivers/usb/host/xhci-plat.h
@@ -13,6 +13,7 @@
struct xhci_plat_priv {
const char *firmware_name;
unsigned long long quirks;
+ int (*plat_setup)(struct usb_hcd *);
void (*plat_start)(struct usb_hcd *);
int (*init_quirk)(struct usb_hcd *);
int (*suspend_quirk)(struct usb_hcd *);
^ permalink raw reply [flat|nested] 140+ messages in thread* [PATCH 5.10 005/120] USB: gadget: legacy: fix an error code in eth_bind()
2021-02-08 14:59 [PATCH 5.10 000/120] 5.10.15-rc1 review Greg Kroah-Hartman
` (3 preceding siblings ...)
2021-02-08 14:59 ` [PATCH 5.10 004/120] usb: host: xhci: mvebu: make USB 3.0 PHY optional for Armada 3720 Greg Kroah-Hartman
@ 2021-02-08 14:59 ` Greg Kroah-Hartman
2021-02-08 14:59 ` [PATCH 5.10 006/120] usb: gadget: aspeed: add missing of_node_put Greg Kroah-Hartman
` (121 subsequent siblings)
126 siblings, 0 replies; 140+ messages in thread
From: Greg Kroah-Hartman @ 2021-02-08 14:59 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, Dan Carpenter
From: Dan Carpenter <dan.carpenter@oracle.com>
commit 3e1f4a2e1184ae6ad7f4caf682ced9554141a0f4 upstream.
This code should return -ENOMEM if the allocation fails but it currently
returns success.
Fixes: 9b95236eebdb ("usb: gadget: ether: allocate and init otg descriptor by otg capabilities")
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Link: https://lore.kernel.org/r/YBKE9rqVuJEOUWpW@mwanda
Cc: stable <stable@vger.kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/usb/gadget/legacy/ether.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
--- a/drivers/usb/gadget/legacy/ether.c
+++ b/drivers/usb/gadget/legacy/ether.c
@@ -403,8 +403,10 @@ static int eth_bind(struct usb_composite
struct usb_descriptor_header *usb_desc;
usb_desc = usb_otg_descriptor_alloc(gadget);
- if (!usb_desc)
+ if (!usb_desc) {
+ status = -ENOMEM;
goto fail1;
+ }
usb_otg_descriptor_init(gadget, usb_desc);
otg_desc[0] = usb_desc;
otg_desc[1] = NULL;
^ permalink raw reply [flat|nested] 140+ messages in thread* [PATCH 5.10 006/120] usb: gadget: aspeed: add missing of_node_put
2021-02-08 14:59 [PATCH 5.10 000/120] 5.10.15-rc1 review Greg Kroah-Hartman
` (4 preceding siblings ...)
2021-02-08 14:59 ` [PATCH 5.10 005/120] USB: gadget: legacy: fix an error code in eth_bind() Greg Kroah-Hartman
@ 2021-02-08 14:59 ` Greg Kroah-Hartman
2021-02-08 14:59 ` [PATCH 5.10 007/120] USB: usblp: dont call usb_set_interface if theres a single alt Greg Kroah-Hartman
` (120 subsequent siblings)
126 siblings, 0 replies; 140+ messages in thread
From: Greg Kroah-Hartman @ 2021-02-08 14:59 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Sumera Priyadarsini,
kernel test robot, Julia Lawall
From: kernel test robot <lkp@intel.com>
commit a55a9a4c5c6253f6e4dea268af728664ac997790 upstream.
Breaking out of for_each_child_of_node requires a put on the
child value.
Generated by: scripts/coccinelle/iterators/for_each_child.cocci
Fixes: 82c2d81361ec ("coccinelle: iterators: Add for_each_child.cocci script")
CC: Sumera Priyadarsini <sylphrenadin@gmail.com>
Reported-by: kernel test robot <lkp@intel.com>
Signed-off-by: kernel test robot <lkp@intel.com>
Signed-off-by: Julia Lawall <julia.lawall@inria.fr>
Cc: stable <stable@vger.kernel.org>
Link: https://lore.kernel.org/r/alpine.DEB.2.22.394.2101211907060.14700@hadrien
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/usb/gadget/udc/aspeed-vhub/hub.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
--- a/drivers/usb/gadget/udc/aspeed-vhub/hub.c
+++ b/drivers/usb/gadget/udc/aspeed-vhub/hub.c
@@ -999,8 +999,10 @@ static int ast_vhub_of_parse_str_desc(st
str_array[offset].s = NULL;
ret = ast_vhub_str_alloc_add(vhub, &lang_str);
- if (ret)
+ if (ret) {
+ of_node_put(child);
break;
+ }
}
return ret;
^ permalink raw reply [flat|nested] 140+ messages in thread* [PATCH 5.10 007/120] USB: usblp: dont call usb_set_interface if theres a single alt
2021-02-08 14:59 [PATCH 5.10 000/120] 5.10.15-rc1 review Greg Kroah-Hartman
` (5 preceding siblings ...)
2021-02-08 14:59 ` [PATCH 5.10 006/120] usb: gadget: aspeed: add missing of_node_put Greg Kroah-Hartman
@ 2021-02-08 14:59 ` Greg Kroah-Hartman
2021-02-08 14:59 ` [PATCH 5.10 008/120] usb: renesas_usbhs: Clear pipe running flag in usbhs_pkt_pop() Greg Kroah-Hartman
` (119 subsequent siblings)
126 siblings, 0 replies; 140+ messages in thread
From: Greg Kroah-Hartman @ 2021-02-08 14:59 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, Pete Zaitcev, Jeremy Figgins
From: Jeremy Figgins <kernel@jeremyfiggins.com>
commit d8c6edfa3f4ee0d45d7ce5ef18d1245b78774b9d upstream.
Some devices, such as the Winbond Electronics Corp. Virtual Com Port
(Vendor=0416, ProdId=5011), lockup when usb_set_interface() or
usb_clear_halt() are called. This device has only a single
altsetting, so it should not be necessary to call usb_set_interface().
Acked-by: Pete Zaitcev <zaitcev@redhat.com>
Signed-off-by: Jeremy Figgins <kernel@jeremyfiggins.com>
Link: https://lore.kernel.org/r/YAy9kJhM/rG8EQXC@watson
Cc: stable <stable@vger.kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/usb/class/usblp.c | 19 +++++++++++--------
1 file changed, 11 insertions(+), 8 deletions(-)
--- a/drivers/usb/class/usblp.c
+++ b/drivers/usb/class/usblp.c
@@ -1329,14 +1329,17 @@ static int usblp_set_protocol(struct usb
if (protocol < USBLP_FIRST_PROTOCOL || protocol > USBLP_LAST_PROTOCOL)
return -EINVAL;
- alts = usblp->protocol[protocol].alt_setting;
- if (alts < 0)
- return -EINVAL;
- r = usb_set_interface(usblp->dev, usblp->ifnum, alts);
- if (r < 0) {
- printk(KERN_ERR "usblp: can't set desired altsetting %d on interface %d\n",
- alts, usblp->ifnum);
- return r;
+ /* Don't unnecessarily set the interface if there's a single alt. */
+ if (usblp->intf->num_altsetting > 1) {
+ alts = usblp->protocol[protocol].alt_setting;
+ if (alts < 0)
+ return -EINVAL;
+ r = usb_set_interface(usblp->dev, usblp->ifnum, alts);
+ if (r < 0) {
+ printk(KERN_ERR "usblp: can't set desired altsetting %d on interface %d\n",
+ alts, usblp->ifnum);
+ return r;
+ }
}
usblp->bidir = (usblp->protocol[protocol].epread != NULL);
^ permalink raw reply [flat|nested] 140+ messages in thread* [PATCH 5.10 008/120] usb: renesas_usbhs: Clear pipe running flag in usbhs_pkt_pop()
2021-02-08 14:59 [PATCH 5.10 000/120] 5.10.15-rc1 review Greg Kroah-Hartman
` (6 preceding siblings ...)
2021-02-08 14:59 ` [PATCH 5.10 007/120] USB: usblp: dont call usb_set_interface if theres a single alt Greg Kroah-Hartman
@ 2021-02-08 14:59 ` Greg Kroah-Hartman
2021-02-08 14:59 ` [PATCH 5.10 009/120] usb: dwc2: Fix endpoint direction check in ep_from_windex Greg Kroah-Hartman
` (118 subsequent siblings)
126 siblings, 0 replies; 140+ messages in thread
From: Greg Kroah-Hartman @ 2021-02-08 14:59 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, Tho Vu, Yoshihiro Shimoda
From: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
commit 9917f0e3cdba7b9f1a23f70e3f70b1a106be54a8 upstream.
Should clear the pipe running flag in usbhs_pkt_pop(). Otherwise,
we cannot use this pipe after dequeue was called while the pipe was
running.
Fixes: 8355b2b3082d ("usb: renesas_usbhs: fix the behavior of some usbhs_pkt_handle")
Reported-by: Tho Vu <tho.vu.wh@renesas.com>
Signed-off-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
Link: https://lore.kernel.org/r/1612183640-8898-1-git-send-email-yoshihiro.shimoda.uh@renesas.com
Cc: stable <stable@vger.kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/usb/renesas_usbhs/fifo.c | 1 +
1 file changed, 1 insertion(+)
--- a/drivers/usb/renesas_usbhs/fifo.c
+++ b/drivers/usb/renesas_usbhs/fifo.c
@@ -126,6 +126,7 @@ struct usbhs_pkt *usbhs_pkt_pop(struct u
}
usbhs_pipe_clear_without_sequence(pipe, 0, 0);
+ usbhs_pipe_running(pipe, 0);
__usbhsf_pkt_del(pkt);
}
^ permalink raw reply [flat|nested] 140+ messages in thread* [PATCH 5.10 009/120] usb: dwc2: Fix endpoint direction check in ep_from_windex
2021-02-08 14:59 [PATCH 5.10 000/120] 5.10.15-rc1 review Greg Kroah-Hartman
` (7 preceding siblings ...)
2021-02-08 14:59 ` [PATCH 5.10 008/120] usb: renesas_usbhs: Clear pipe running flag in usbhs_pkt_pop() Greg Kroah-Hartman
@ 2021-02-08 14:59 ` Greg Kroah-Hartman
2021-02-08 14:59 ` [PATCH 5.10 010/120] usb: dwc3: fix clock issue during resume in OTG mode Greg Kroah-Hartman
` (117 subsequent siblings)
126 siblings, 0 replies; 140+ messages in thread
From: Greg Kroah-Hartman @ 2021-02-08 14:59 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Gerhard Klostermeier, Heiko Stuebner
From: Heiko Stuebner <heiko.stuebner@theobroma-systems.com>
commit f670e9f9c8cac716c3506c6bac9e997b27ad441a upstream.
dwc2_hsotg_process_req_status uses ep_from_windex() to retrieve
the endpoint for the index provided in the wIndex request param.
In a test-case with a rndis gadget running and sending a malformed
packet to it like:
dev.ctrl_transfer(
0x82, # bmRequestType
0x00, # bRequest
0x0000, # wValue
0x0001, # wIndex
0x00 # wLength
)
it is possible to cause a crash:
[ 217.533022] dwc2 ff300000.usb: dwc2_hsotg_process_req_status: USB_REQ_GET_STATUS
[ 217.559003] Unable to handle kernel read from unreadable memory at virtual address 0000000000000088
...
[ 218.313189] Call trace:
[ 218.330217] ep_from_windex+0x3c/0x54
[ 218.348565] usb_gadget_giveback_request+0x10/0x20
[ 218.368056] dwc2_hsotg_complete_request+0x144/0x184
This happens because ep_from_windex wants to compare the endpoint
direction even if index_to_ep() didn't return an endpoint due to
the direction not matching.
The fix is easy insofar that the actual direction check is already
happening when calling index_to_ep() which will return NULL if there
is no endpoint for the targeted direction, so the offending check
can go away completely.
Fixes: c6f5c050e2a7 ("usb: dwc2: gadget: add bi-directional endpoint support")
Cc: stable@vger.kernel.org
Reported-by: Gerhard Klostermeier <gerhard.klostermeier@syss.de>
Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com>
Link: https://lore.kernel.org/r/20210127103919.58215-1-heiko@sntech.de
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/usb/dwc2/gadget.c | 8 +-------
1 file changed, 1 insertion(+), 7 deletions(-)
--- a/drivers/usb/dwc2/gadget.c
+++ b/drivers/usb/dwc2/gadget.c
@@ -1543,7 +1543,6 @@ static void dwc2_hsotg_complete_oursetup
static struct dwc2_hsotg_ep *ep_from_windex(struct dwc2_hsotg *hsotg,
u32 windex)
{
- struct dwc2_hsotg_ep *ep;
int dir = (windex & USB_DIR_IN) ? 1 : 0;
int idx = windex & 0x7F;
@@ -1553,12 +1552,7 @@ static struct dwc2_hsotg_ep *ep_from_win
if (idx > hsotg->num_of_eps)
return NULL;
- ep = index_to_ep(hsotg, idx, dir);
-
- if (idx && ep->dir_in != dir)
- return NULL;
-
- return ep;
+ return index_to_ep(hsotg, idx, dir);
}
/**
^ permalink raw reply [flat|nested] 140+ messages in thread* [PATCH 5.10 010/120] usb: dwc3: fix clock issue during resume in OTG mode
2021-02-08 14:59 [PATCH 5.10 000/120] 5.10.15-rc1 review Greg Kroah-Hartman
` (8 preceding siblings ...)
2021-02-08 14:59 ` [PATCH 5.10 009/120] usb: dwc2: Fix endpoint direction check in ep_from_windex Greg Kroah-Hartman
@ 2021-02-08 14:59 ` Greg Kroah-Hartman
2021-02-08 14:59 ` [PATCH 5.10 011/120] usb: xhci-mtk: fix unreleased bandwidth data Greg Kroah-Hartman
` (116 subsequent siblings)
126 siblings, 0 replies; 140+ messages in thread
From: Greg Kroah-Hartman @ 2021-02-08 14:59 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, Gary Bisson
From: Gary Bisson <gary.bisson@boundarydevices.com>
commit 0e5a3c8284a30f4c43fd81d7285528ece74563b5 upstream.
Commit fe8abf332b8f ("usb: dwc3: support clocks and resets for DWC3
core") introduced clock support and a new function named
dwc3_core_init_for_resume() which enables the clock before calling
dwc3_core_init() during resume as clocks get disabled during suspend.
Unfortunately in this commit the DWC3_GCTL_PRTCAP_OTG case was forgotten
and therefore during resume, a platform could call dwc3_core_init()
without re-enabling the clocks first, preventing to resume properly.
So update the resume path to call dwc3_core_init_for_resume() as it
should.
Fixes: fe8abf332b8f ("usb: dwc3: support clocks and resets for DWC3 core")
Cc: stable@vger.kernel.org
Signed-off-by: Gary Bisson <gary.bisson@boundarydevices.com>
Link: https://lore.kernel.org/r/20210125161934.527820-1-gary.bisson@boundarydevices.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/usb/dwc3/core.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/usb/dwc3/core.c
+++ b/drivers/usb/dwc3/core.c
@@ -1758,7 +1758,7 @@ static int dwc3_resume_common(struct dwc
if (PMSG_IS_AUTO(msg))
break;
- ret = dwc3_core_init(dwc);
+ ret = dwc3_core_init_for_resume(dwc);
if (ret)
return ret;
^ permalink raw reply [flat|nested] 140+ messages in thread* [PATCH 5.10 011/120] usb: xhci-mtk: fix unreleased bandwidth data
2021-02-08 14:59 [PATCH 5.10 000/120] 5.10.15-rc1 review Greg Kroah-Hartman
` (9 preceding siblings ...)
2021-02-08 14:59 ` [PATCH 5.10 010/120] usb: dwc3: fix clock issue during resume in OTG mode Greg Kroah-Hartman
@ 2021-02-08 14:59 ` Greg Kroah-Hartman
2021-02-08 14:59 ` [PATCH 5.10 012/120] usb: xhci-mtk: skip dropping bandwidth of unchecked endpoints Greg Kroah-Hartman
` (115 subsequent siblings)
126 siblings, 0 replies; 140+ messages in thread
From: Greg Kroah-Hartman @ 2021-02-08 14:59 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, Ikjoon Jang
From: Ikjoon Jang <ikjn@chromium.org>
commit 1d69f9d901ef14d81c3b004e3282b8cc7b456280 upstream.
xhci-mtk needs XHCI_MTK_HOST quirk functions in add_endpoint() and
drop_endpoint() to handle its own sw bandwidth management.
It stores bandwidth data into an internal table every time
add_endpoint() is called, and drops those in drop_endpoint().
But when bandwidth allocation fails at one endpoint, all earlier
allocation from the same interface could still remain at the table.
This patch moves bandwidth management codes to check_bandwidth() and
reset_bandwidth() path. To do so, this patch also adds those functions
to xhci_driver_overrides and lets mtk-xhci to release all failed
endpoints in reset_bandwidth() path.
Fixes: 08e469de87a2 ("usb: xhci-mtk: supports bandwidth scheduling with multi-TT")
Signed-off-by: Ikjoon Jang <ikjn@chromium.org>
Link: https://lore.kernel.org/r/20210113180444.v6.1.Id0d31b5f3ddf5e734d2ab11161ac5821921b1e1e@changeid
Cc: stable <stable@vger.kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/usb/host/xhci-mtk-sch.c | 123 +++++++++++++++++++++++++++-------------
drivers/usb/host/xhci-mtk.c | 2
drivers/usb/host/xhci-mtk.h | 13 ++++
drivers/usb/host/xhci.c | 8 +-
drivers/usb/host/xhci.h | 4 +
5 files changed, 111 insertions(+), 39 deletions(-)
--- a/drivers/usb/host/xhci-mtk-sch.c
+++ b/drivers/usb/host/xhci-mtk-sch.c
@@ -200,6 +200,7 @@ static struct mu3h_sch_ep_info *create_s
sch_ep->sch_tt = tt;
sch_ep->ep = ep;
+ INIT_LIST_HEAD(&sch_ep->tt_endpoint);
return sch_ep;
}
@@ -583,6 +584,8 @@ int xhci_mtk_sch_init(struct xhci_hcd_mt
mtk->sch_array = sch_array;
+ INIT_LIST_HEAD(&mtk->bw_ep_list_new);
+
return 0;
}
EXPORT_SYMBOL_GPL(xhci_mtk_sch_init);
@@ -601,19 +604,14 @@ int xhci_mtk_add_ep_quirk(struct usb_hcd
struct xhci_ep_ctx *ep_ctx;
struct xhci_slot_ctx *slot_ctx;
struct xhci_virt_device *virt_dev;
- struct mu3h_sch_bw_info *sch_bw;
struct mu3h_sch_ep_info *sch_ep;
- struct mu3h_sch_bw_info *sch_array;
unsigned int ep_index;
- int bw_index;
- int ret = 0;
xhci = hcd_to_xhci(hcd);
virt_dev = xhci->devs[udev->slot_id];
ep_index = xhci_get_endpoint_index(&ep->desc);
slot_ctx = xhci_get_slot_ctx(xhci, virt_dev->in_ctx);
ep_ctx = xhci_get_ep_ctx(xhci, virt_dev->in_ctx, ep_index);
- sch_array = mtk->sch_array;
xhci_dbg(xhci, "%s() type:%d, speed:%d, mpkt:%d, dir:%d, ep:%p\n",
__func__, usb_endpoint_type(&ep->desc), udev->speed,
@@ -632,39 +630,34 @@ int xhci_mtk_add_ep_quirk(struct usb_hcd
return 0;
}
- bw_index = get_bw_index(xhci, udev, ep);
- sch_bw = &sch_array[bw_index];
-
sch_ep = create_sch_ep(udev, ep, ep_ctx);
if (IS_ERR_OR_NULL(sch_ep))
return -ENOMEM;
setup_sch_info(udev, ep_ctx, sch_ep);
- ret = check_sch_bw(udev, sch_bw, sch_ep);
- if (ret) {
- xhci_err(xhci, "Not enough bandwidth!\n");
- if (is_fs_or_ls(udev->speed))
- drop_tt(udev);
-
- kfree(sch_ep);
- return -ENOSPC;
- }
+ list_add_tail(&sch_ep->endpoint, &mtk->bw_ep_list_new);
- list_add_tail(&sch_ep->endpoint, &sch_bw->bw_ep_list);
+ return 0;
+}
+EXPORT_SYMBOL_GPL(xhci_mtk_add_ep_quirk);
- ep_ctx->reserved[0] |= cpu_to_le32(EP_BPKTS(sch_ep->pkts)
- | EP_BCSCOUNT(sch_ep->cs_count) | EP_BBM(sch_ep->burst_mode));
- ep_ctx->reserved[1] |= cpu_to_le32(EP_BOFFSET(sch_ep->offset)
- | EP_BREPEAT(sch_ep->repeat));
+static void xhci_mtk_drop_ep(struct xhci_hcd_mtk *mtk, struct usb_device *udev,
+ struct mu3h_sch_ep_info *sch_ep)
+{
+ struct xhci_hcd *xhci = hcd_to_xhci(mtk->hcd);
+ int bw_index = get_bw_index(xhci, udev, sch_ep->ep);
+ struct mu3h_sch_bw_info *sch_bw = &mtk->sch_array[bw_index];
- xhci_dbg(xhci, " PKTS:%x, CSCOUNT:%x, BM:%x, OFFSET:%x, REPEAT:%x\n",
- sch_ep->pkts, sch_ep->cs_count, sch_ep->burst_mode,
- sch_ep->offset, sch_ep->repeat);
+ update_bus_bw(sch_bw, sch_ep, 0);
+ list_del(&sch_ep->endpoint);
- return 0;
+ if (sch_ep->sch_tt) {
+ list_del(&sch_ep->tt_endpoint);
+ drop_tt(udev);
+ }
+ kfree(sch_ep);
}
-EXPORT_SYMBOL_GPL(xhci_mtk_add_ep_quirk);
void xhci_mtk_drop_ep_quirk(struct usb_hcd *hcd, struct usb_device *udev,
struct usb_host_endpoint *ep)
@@ -675,7 +668,7 @@ void xhci_mtk_drop_ep_quirk(struct usb_h
struct xhci_virt_device *virt_dev;
struct mu3h_sch_bw_info *sch_array;
struct mu3h_sch_bw_info *sch_bw;
- struct mu3h_sch_ep_info *sch_ep;
+ struct mu3h_sch_ep_info *sch_ep, *tmp;
int bw_index;
xhci = hcd_to_xhci(hcd);
@@ -694,17 +687,73 @@ void xhci_mtk_drop_ep_quirk(struct usb_h
bw_index = get_bw_index(xhci, udev, ep);
sch_bw = &sch_array[bw_index];
- list_for_each_entry(sch_ep, &sch_bw->bw_ep_list, endpoint) {
+ list_for_each_entry_safe(sch_ep, tmp, &sch_bw->bw_ep_list, endpoint) {
if (sch_ep->ep == ep) {
- update_bus_bw(sch_bw, sch_ep, 0);
- list_del(&sch_ep->endpoint);
- if (is_fs_or_ls(udev->speed)) {
- list_del(&sch_ep->tt_endpoint);
- drop_tt(udev);
- }
- kfree(sch_ep);
- break;
+ xhci_mtk_drop_ep(mtk, udev, sch_ep);
}
}
}
EXPORT_SYMBOL_GPL(xhci_mtk_drop_ep_quirk);
+
+int xhci_mtk_check_bandwidth(struct usb_hcd *hcd, struct usb_device *udev)
+{
+ struct xhci_hcd_mtk *mtk = hcd_to_mtk(hcd);
+ struct xhci_hcd *xhci = hcd_to_xhci(hcd);
+ struct xhci_virt_device *virt_dev = xhci->devs[udev->slot_id];
+ struct mu3h_sch_bw_info *sch_bw;
+ struct mu3h_sch_ep_info *sch_ep, *tmp;
+ int bw_index, ret;
+
+ dev_dbg(&udev->dev, "%s\n", __func__);
+
+ list_for_each_entry(sch_ep, &mtk->bw_ep_list_new, endpoint) {
+ bw_index = get_bw_index(xhci, udev, sch_ep->ep);
+ sch_bw = &mtk->sch_array[bw_index];
+
+ ret = check_sch_bw(udev, sch_bw, sch_ep);
+ if (ret) {
+ xhci_err(xhci, "Not enough bandwidth!\n");
+ return -ENOSPC;
+ }
+ }
+
+ list_for_each_entry_safe(sch_ep, tmp, &mtk->bw_ep_list_new, endpoint) {
+ struct xhci_ep_ctx *ep_ctx;
+ struct usb_host_endpoint *ep = sch_ep->ep;
+ unsigned int ep_index = xhci_get_endpoint_index(&ep->desc);
+
+ bw_index = get_bw_index(xhci, udev, ep);
+ sch_bw = &mtk->sch_array[bw_index];
+
+ list_move_tail(&sch_ep->endpoint, &sch_bw->bw_ep_list);
+
+ ep_ctx = xhci_get_ep_ctx(xhci, virt_dev->in_ctx, ep_index);
+ ep_ctx->reserved[0] |= cpu_to_le32(EP_BPKTS(sch_ep->pkts)
+ | EP_BCSCOUNT(sch_ep->cs_count)
+ | EP_BBM(sch_ep->burst_mode));
+ ep_ctx->reserved[1] |= cpu_to_le32(EP_BOFFSET(sch_ep->offset)
+ | EP_BREPEAT(sch_ep->repeat));
+
+ xhci_dbg(xhci, " PKTS:%x, CSCOUNT:%x, BM:%x, OFFSET:%x, REPEAT:%x\n",
+ sch_ep->pkts, sch_ep->cs_count, sch_ep->burst_mode,
+ sch_ep->offset, sch_ep->repeat);
+ }
+
+ return xhci_check_bandwidth(hcd, udev);
+}
+EXPORT_SYMBOL_GPL(xhci_mtk_check_bandwidth);
+
+void xhci_mtk_reset_bandwidth(struct usb_hcd *hcd, struct usb_device *udev)
+{
+ struct xhci_hcd_mtk *mtk = hcd_to_mtk(hcd);
+ struct mu3h_sch_ep_info *sch_ep, *tmp;
+
+ dev_dbg(&udev->dev, "%s\n", __func__);
+
+ list_for_each_entry_safe(sch_ep, tmp, &mtk->bw_ep_list_new, endpoint) {
+ xhci_mtk_drop_ep(mtk, udev, sch_ep);
+ }
+
+ xhci_reset_bandwidth(hcd, udev);
+}
+EXPORT_SYMBOL_GPL(xhci_mtk_reset_bandwidth);
--- a/drivers/usb/host/xhci-mtk.c
+++ b/drivers/usb/host/xhci-mtk.c
@@ -347,6 +347,8 @@ static void usb_wakeup_set(struct xhci_h
static int xhci_mtk_setup(struct usb_hcd *hcd);
static const struct xhci_driver_overrides xhci_mtk_overrides __initconst = {
.reset = xhci_mtk_setup,
+ .check_bandwidth = xhci_mtk_check_bandwidth,
+ .reset_bandwidth = xhci_mtk_reset_bandwidth,
};
static struct hc_driver __read_mostly xhci_mtk_hc_driver;
--- a/drivers/usb/host/xhci-mtk.h
+++ b/drivers/usb/host/xhci-mtk.h
@@ -130,6 +130,7 @@ struct mu3c_ippc_regs {
struct xhci_hcd_mtk {
struct device *dev;
struct usb_hcd *hcd;
+ struct list_head bw_ep_list_new;
struct mu3h_sch_bw_info *sch_array;
struct mu3c_ippc_regs __iomem *ippc_regs;
bool has_ippc;
@@ -166,6 +167,8 @@ int xhci_mtk_add_ep_quirk(struct usb_hcd
struct usb_host_endpoint *ep);
void xhci_mtk_drop_ep_quirk(struct usb_hcd *hcd, struct usb_device *udev,
struct usb_host_endpoint *ep);
+int xhci_mtk_check_bandwidth(struct usb_hcd *hcd, struct usb_device *udev);
+void xhci_mtk_reset_bandwidth(struct usb_hcd *hcd, struct usb_device *udev);
#else
static inline int xhci_mtk_add_ep_quirk(struct usb_hcd *hcd,
@@ -179,6 +182,16 @@ static inline void xhci_mtk_drop_ep_quir
{
}
+static inline int xhci_mtk_check_bandwidth(struct usb_hcd *hcd,
+ struct usb_device *udev)
+{
+ return 0;
+}
+
+static inline void xhci_mtk_reset_bandwidth(struct usb_hcd *hcd,
+ struct usb_device *udev)
+{
+}
#endif
#endif /* _XHCI_MTK_H_ */
--- a/drivers/usb/host/xhci.c
+++ b/drivers/usb/host/xhci.c
@@ -2861,7 +2861,7 @@ static void xhci_check_bw_drop_ep_stream
* else should be touching the xhci->devs[slot_id] structure, so we
* don't need to take the xhci->lock for manipulating that.
*/
-static int xhci_check_bandwidth(struct usb_hcd *hcd, struct usb_device *udev)
+int xhci_check_bandwidth(struct usb_hcd *hcd, struct usb_device *udev)
{
int i;
int ret = 0;
@@ -2959,7 +2959,7 @@ command_cleanup:
return ret;
}
-static void xhci_reset_bandwidth(struct usb_hcd *hcd, struct usb_device *udev)
+void xhci_reset_bandwidth(struct usb_hcd *hcd, struct usb_device *udev)
{
struct xhci_hcd *xhci;
struct xhci_virt_device *virt_dev;
@@ -5385,6 +5385,10 @@ void xhci_init_driver(struct hc_driver *
drv->reset = over->reset;
if (over->start)
drv->start = over->start;
+ if (over->check_bandwidth)
+ drv->check_bandwidth = over->check_bandwidth;
+ if (over->reset_bandwidth)
+ drv->reset_bandwidth = over->reset_bandwidth;
}
}
EXPORT_SYMBOL_GPL(xhci_init_driver);
--- a/drivers/usb/host/xhci.h
+++ b/drivers/usb/host/xhci.h
@@ -1916,6 +1916,8 @@ struct xhci_driver_overrides {
size_t extra_priv_size;
int (*reset)(struct usb_hcd *hcd);
int (*start)(struct usb_hcd *hcd);
+ int (*check_bandwidth)(struct usb_hcd *, struct usb_device *);
+ void (*reset_bandwidth)(struct usb_hcd *, struct usb_device *);
};
#define XHCI_CFC_DELAY 10
@@ -2070,6 +2072,8 @@ int xhci_gen_setup(struct usb_hcd *hcd,
void xhci_shutdown(struct usb_hcd *hcd);
void xhci_init_driver(struct hc_driver *drv,
const struct xhci_driver_overrides *over);
+int xhci_check_bandwidth(struct usb_hcd *hcd, struct usb_device *udev);
+void xhci_reset_bandwidth(struct usb_hcd *hcd, struct usb_device *udev);
int xhci_disable_slot(struct xhci_hcd *xhci, u32 slot_id);
int xhci_ext_cap_init(struct xhci_hcd *xhci);
^ permalink raw reply [flat|nested] 140+ messages in thread* [PATCH 5.10 012/120] usb: xhci-mtk: skip dropping bandwidth of unchecked endpoints
2021-02-08 14:59 [PATCH 5.10 000/120] 5.10.15-rc1 review Greg Kroah-Hartman
` (10 preceding siblings ...)
2021-02-08 14:59 ` [PATCH 5.10 011/120] usb: xhci-mtk: fix unreleased bandwidth data Greg Kroah-Hartman
@ 2021-02-08 14:59 ` Greg Kroah-Hartman
2021-02-08 15:00 ` [PATCH 5.10 013/120] usb: xhci-mtk: break loop when find the endpoint to drop Greg Kroah-Hartman
` (114 subsequent siblings)
126 siblings, 0 replies; 140+ messages in thread
From: Greg Kroah-Hartman @ 2021-02-08 14:59 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, Chunfeng Yun, Ikjoon Jang
From: Chunfeng Yun <chunfeng.yun@mediatek.com>
commit 54f6a8af372213a254af6609758d99f7c0b6b5ad upstream.
For those unchecked endpoints, we don't allocate bandwidth for
them, so no need free the bandwidth, otherwise will decrease
the allocated bandwidth.
Meanwhile use xhci_dbg() instead of dev_dbg() to print logs and
rename bw_ep_list_new as bw_ep_chk_list.
Fixes: 1d69f9d901ef ("usb: xhci-mtk: fix unreleased bandwidth data")
Cc: stable <stable@vger.kernel.org>
Reviewed-and-tested-by: Ikjoon Jang <ikjn@chromium.org>
Signed-off-by: Chunfeng Yun <chunfeng.yun@mediatek.com>
Link: https://lore.kernel.org/r/1612159064-28413-1-git-send-email-chunfeng.yun@mediatek.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/usb/host/xhci-mtk-sch.c | 61 +++++++++++++++++++++-------------------
drivers/usb/host/xhci-mtk.h | 4 +-
2 files changed, 36 insertions(+), 29 deletions(-)
--- a/drivers/usb/host/xhci-mtk-sch.c
+++ b/drivers/usb/host/xhci-mtk-sch.c
@@ -200,6 +200,7 @@ static struct mu3h_sch_ep_info *create_s
sch_ep->sch_tt = tt;
sch_ep->ep = ep;
+ INIT_LIST_HEAD(&sch_ep->endpoint);
INIT_LIST_HEAD(&sch_ep->tt_endpoint);
return sch_ep;
@@ -374,6 +375,7 @@ static void update_bus_bw(struct mu3h_sc
sch_ep->bw_budget_table[j];
}
}
+ sch_ep->allocated = used;
}
static int check_sch_tt(struct usb_device *udev,
@@ -542,6 +544,22 @@ static int check_sch_bw(struct usb_devic
return 0;
}
+static void destroy_sch_ep(struct usb_device *udev,
+ struct mu3h_sch_bw_info *sch_bw, struct mu3h_sch_ep_info *sch_ep)
+{
+ /* only release ep bw check passed by check_sch_bw() */
+ if (sch_ep->allocated)
+ update_bus_bw(sch_bw, sch_ep, 0);
+
+ list_del(&sch_ep->endpoint);
+
+ if (sch_ep->sch_tt) {
+ list_del(&sch_ep->tt_endpoint);
+ drop_tt(udev);
+ }
+ kfree(sch_ep);
+}
+
static bool need_bw_sch(struct usb_host_endpoint *ep,
enum usb_device_speed speed, int has_tt)
{
@@ -584,7 +602,7 @@ int xhci_mtk_sch_init(struct xhci_hcd_mt
mtk->sch_array = sch_array;
- INIT_LIST_HEAD(&mtk->bw_ep_list_new);
+ INIT_LIST_HEAD(&mtk->bw_ep_chk_list);
return 0;
}
@@ -636,29 +654,12 @@ int xhci_mtk_add_ep_quirk(struct usb_hcd
setup_sch_info(udev, ep_ctx, sch_ep);
- list_add_tail(&sch_ep->endpoint, &mtk->bw_ep_list_new);
+ list_add_tail(&sch_ep->endpoint, &mtk->bw_ep_chk_list);
return 0;
}
EXPORT_SYMBOL_GPL(xhci_mtk_add_ep_quirk);
-static void xhci_mtk_drop_ep(struct xhci_hcd_mtk *mtk, struct usb_device *udev,
- struct mu3h_sch_ep_info *sch_ep)
-{
- struct xhci_hcd *xhci = hcd_to_xhci(mtk->hcd);
- int bw_index = get_bw_index(xhci, udev, sch_ep->ep);
- struct mu3h_sch_bw_info *sch_bw = &mtk->sch_array[bw_index];
-
- update_bus_bw(sch_bw, sch_ep, 0);
- list_del(&sch_ep->endpoint);
-
- if (sch_ep->sch_tt) {
- list_del(&sch_ep->tt_endpoint);
- drop_tt(udev);
- }
- kfree(sch_ep);
-}
-
void xhci_mtk_drop_ep_quirk(struct usb_hcd *hcd, struct usb_device *udev,
struct usb_host_endpoint *ep)
{
@@ -688,9 +689,8 @@ void xhci_mtk_drop_ep_quirk(struct usb_h
sch_bw = &sch_array[bw_index];
list_for_each_entry_safe(sch_ep, tmp, &sch_bw->bw_ep_list, endpoint) {
- if (sch_ep->ep == ep) {
- xhci_mtk_drop_ep(mtk, udev, sch_ep);
- }
+ if (sch_ep->ep == ep)
+ destroy_sch_ep(udev, sch_bw, sch_ep);
}
}
EXPORT_SYMBOL_GPL(xhci_mtk_drop_ep_quirk);
@@ -704,9 +704,9 @@ int xhci_mtk_check_bandwidth(struct usb_
struct mu3h_sch_ep_info *sch_ep, *tmp;
int bw_index, ret;
- dev_dbg(&udev->dev, "%s\n", __func__);
+ xhci_dbg(xhci, "%s() udev %s\n", __func__, dev_name(&udev->dev));
- list_for_each_entry(sch_ep, &mtk->bw_ep_list_new, endpoint) {
+ list_for_each_entry(sch_ep, &mtk->bw_ep_chk_list, endpoint) {
bw_index = get_bw_index(xhci, udev, sch_ep->ep);
sch_bw = &mtk->sch_array[bw_index];
@@ -717,7 +717,7 @@ int xhci_mtk_check_bandwidth(struct usb_
}
}
- list_for_each_entry_safe(sch_ep, tmp, &mtk->bw_ep_list_new, endpoint) {
+ list_for_each_entry_safe(sch_ep, tmp, &mtk->bw_ep_chk_list, endpoint) {
struct xhci_ep_ctx *ep_ctx;
struct usb_host_endpoint *ep = sch_ep->ep;
unsigned int ep_index = xhci_get_endpoint_index(&ep->desc);
@@ -746,12 +746,17 @@ EXPORT_SYMBOL_GPL(xhci_mtk_check_bandwid
void xhci_mtk_reset_bandwidth(struct usb_hcd *hcd, struct usb_device *udev)
{
struct xhci_hcd_mtk *mtk = hcd_to_mtk(hcd);
+ struct xhci_hcd *xhci = hcd_to_xhci(hcd);
+ struct mu3h_sch_bw_info *sch_bw;
struct mu3h_sch_ep_info *sch_ep, *tmp;
+ int bw_index;
- dev_dbg(&udev->dev, "%s\n", __func__);
+ xhci_dbg(xhci, "%s() udev %s\n", __func__, dev_name(&udev->dev));
- list_for_each_entry_safe(sch_ep, tmp, &mtk->bw_ep_list_new, endpoint) {
- xhci_mtk_drop_ep(mtk, udev, sch_ep);
+ list_for_each_entry_safe(sch_ep, tmp, &mtk->bw_ep_chk_list, endpoint) {
+ bw_index = get_bw_index(xhci, udev, sch_ep->ep);
+ sch_bw = &mtk->sch_array[bw_index];
+ destroy_sch_ep(udev, sch_bw, sch_ep);
}
xhci_reset_bandwidth(hcd, udev);
--- a/drivers/usb/host/xhci-mtk.h
+++ b/drivers/usb/host/xhci-mtk.h
@@ -59,6 +59,7 @@ struct mu3h_sch_bw_info {
* @ep_type: endpoint type
* @maxpkt: max packet size of endpoint
* @ep: address of usb_host_endpoint struct
+ * @allocated: the bandwidth is aready allocated from bus_bw
* @offset: which uframe of the interval that transfer should be
* scheduled first time within the interval
* @repeat: the time gap between two uframes that transfers are
@@ -86,6 +87,7 @@ struct mu3h_sch_ep_info {
u32 ep_type;
u32 maxpkt;
void *ep;
+ bool allocated;
/*
* mtk xHCI scheduling information put into reserved DWs
* in ep context
@@ -130,8 +132,8 @@ struct mu3c_ippc_regs {
struct xhci_hcd_mtk {
struct device *dev;
struct usb_hcd *hcd;
- struct list_head bw_ep_list_new;
struct mu3h_sch_bw_info *sch_array;
+ struct list_head bw_ep_chk_list;
struct mu3c_ippc_regs __iomem *ippc_regs;
bool has_ippc;
int num_u2_ports;
^ permalink raw reply [flat|nested] 140+ messages in thread* [PATCH 5.10 013/120] usb: xhci-mtk: break loop when find the endpoint to drop
2021-02-08 14:59 [PATCH 5.10 000/120] 5.10.15-rc1 review Greg Kroah-Hartman
` (11 preceding siblings ...)
2021-02-08 14:59 ` [PATCH 5.10 012/120] usb: xhci-mtk: skip dropping bandwidth of unchecked endpoints Greg Kroah-Hartman
@ 2021-02-08 15:00 ` Greg Kroah-Hartman
2021-02-08 15:00 ` [PATCH 5.10 014/120] ARM: OMAP1: OSK: fix ohci-omap breakage Greg Kroah-Hartman
` (113 subsequent siblings)
126 siblings, 0 replies; 140+ messages in thread
From: Greg Kroah-Hartman @ 2021-02-08 15:00 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, Ikjoon Jang, Chunfeng Yun
From: Chunfeng Yun <chunfeng.yun@mediatek.com>
commit a50ea34d6dd00a12c9cd29cf7b0fa72816bffbcb upstream.
No need to check the following endpoints after finding the endpoint
wanted to drop.
Fixes: 54f6a8af3722 ("usb: xhci-mtk: skip dropping bandwidth of unchecked endpoints")
Cc: stable <stable@vger.kernel.org>
Reported-by: Ikjoon Jang <ikjn@chromium.org>
Signed-off-by: Chunfeng Yun <chunfeng.yun@mediatek.com>
Link: https://lore.kernel.org/r/1612255104-5363-1-git-send-email-chunfeng.yun@mediatek.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/usb/host/xhci-mtk-sch.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
--- a/drivers/usb/host/xhci-mtk-sch.c
+++ b/drivers/usb/host/xhci-mtk-sch.c
@@ -689,8 +689,10 @@ void xhci_mtk_drop_ep_quirk(struct usb_h
sch_bw = &sch_array[bw_index];
list_for_each_entry_safe(sch_ep, tmp, &sch_bw->bw_ep_list, endpoint) {
- if (sch_ep->ep == ep)
+ if (sch_ep->ep == ep) {
destroy_sch_ep(udev, sch_bw, sch_ep);
+ break;
+ }
}
}
EXPORT_SYMBOL_GPL(xhci_mtk_drop_ep_quirk);
^ permalink raw reply [flat|nested] 140+ messages in thread* [PATCH 5.10 014/120] ARM: OMAP1: OSK: fix ohci-omap breakage
2021-02-08 14:59 [PATCH 5.10 000/120] 5.10.15-rc1 review Greg Kroah-Hartman
` (12 preceding siblings ...)
2021-02-08 15:00 ` [PATCH 5.10 013/120] usb: xhci-mtk: break loop when find the endpoint to drop Greg Kroah-Hartman
@ 2021-02-08 15:00 ` Greg Kroah-Hartman
2021-02-08 15:00 ` [PATCH 5.10 015/120] arm64: dts: qcom: c630: keep both touchpad devices enabled Greg Kroah-Hartman
` (112 subsequent siblings)
126 siblings, 0 replies; 140+ messages in thread
From: Greg Kroah-Hartman @ 2021-02-08 15:00 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Linus Walleij, Aaro Koskinen,
Tony Lindgren, Sasha Levin
From: Linus Walleij <linus.walleij@linaro.org>
[ Upstream commit 6efac0173cd15460b48c91e1b0a000379f341f00 ]
Commit 45c5775460f3 ("usb: ohci-omap: Fix descriptor conversion") tried to
fix all issues related to ohci-omap descriptor conversion, but a wrong
patch was applied, and one needed change to the OSK board file is still
missing. Fix that.
Fixes: 45c5775460f3 ("usb: ohci-omap: Fix descriptor conversion")
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
[aaro.koskinen@iki.fi: rebased and updated the changelog]
Signed-off-by: Aaro Koskinen <aaro.koskinen@iki.fi>
Signed-off-by: Tony Lindgren <tony@atomide.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
arch/arm/mach-omap1/board-osk.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/arm/mach-omap1/board-osk.c b/arch/arm/mach-omap1/board-osk.c
index a720259099edf..0a4c9b0b13b0c 100644
--- a/arch/arm/mach-omap1/board-osk.c
+++ b/arch/arm/mach-omap1/board-osk.c
@@ -203,6 +203,8 @@ static int osk_tps_setup(struct i2c_client *client, void *context)
*/
gpio_request(OSK_TPS_GPIO_USB_PWR_EN, "n_vbus_en");
gpio_direction_output(OSK_TPS_GPIO_USB_PWR_EN, 1);
+ /* Free the GPIO again as the driver will request it */
+ gpio_free(OSK_TPS_GPIO_USB_PWR_EN);
/* Set GPIO 2 high so LED D3 is off by default */
tps65010_set_gpio_out_value(GPIO2, HIGH);
--
2.27.0
^ permalink raw reply related [flat|nested] 140+ messages in thread* [PATCH 5.10 015/120] arm64: dts: qcom: c630: keep both touchpad devices enabled
2021-02-08 14:59 [PATCH 5.10 000/120] 5.10.15-rc1 review Greg Kroah-Hartman
` (13 preceding siblings ...)
2021-02-08 15:00 ` [PATCH 5.10 014/120] ARM: OMAP1: OSK: fix ohci-omap breakage Greg Kroah-Hartman
@ 2021-02-08 15:00 ` Greg Kroah-Hartman
2021-02-08 15:00 ` [PATCH 5.10 016/120] Input: i8042 - unbreak Pegatron C15B Greg Kroah-Hartman
` (111 subsequent siblings)
126 siblings, 0 replies; 140+ messages in thread
From: Greg Kroah-Hartman @ 2021-02-08 15:00 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Shawn Guo, Bjorn Andersson, Sasha Levin
From: Shawn Guo <shawn.guo@linaro.org>
[ Upstream commit a9164910c5ceed63551280a4a0b85d37ac2b19a5 ]
Indicated by AML code in ACPI table, the touchpad in-use could be found
on two possible slave addresses on &i2c3, i.e. hid@15 and hid@2c. And
which one is in-use can be determined by reading another address on the
I2C bus. Unfortunately, for DT boot, there is currently no support in
firmware to make this check and patch DT accordingly. This results in
a non-functional touchpad on those C630 devices with hid@2c.
As i2c-hid driver will stop probing the device if there is nothing on
the slave address, we can actually keep both devices enabled in DT, and
i2c-hid driver will only probe the existing one. The only problem is
that we cannot set up pinctrl in both device nodes, as two devices with
the same pinctrl will cause pin conflict that makes the second device
fail to probe. Let's move the pinctrl state up to parent node to solve
this problem. As the pinctrl state of parent node is already defined in
sdm845.dtsi, it ends up with overwriting pinctrl-0 with i2c3_hid_active
state added in there.
Fixes: 11d0e4f28156 ("arm64: dts: qcom: c630: Polish i2c-hid devices")
Signed-off-by: Shawn Guo <shawn.guo@linaro.org>
Link: https://lore.kernel.org/r/20210102045940.26874-1-shawn.guo@linaro.org
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
arch/arm64/boot/dts/qcom/sdm850-lenovo-yoga-c630.dts | 10 ++--------
1 file changed, 2 insertions(+), 8 deletions(-)
diff --git a/arch/arm64/boot/dts/qcom/sdm850-lenovo-yoga-c630.dts b/arch/arm64/boot/dts/qcom/sdm850-lenovo-yoga-c630.dts
index 76a8c996d497f..d70aae77a6e84 100644
--- a/arch/arm64/boot/dts/qcom/sdm850-lenovo-yoga-c630.dts
+++ b/arch/arm64/boot/dts/qcom/sdm850-lenovo-yoga-c630.dts
@@ -263,6 +263,8 @@
&i2c3 {
status = "okay";
clock-frequency = <400000>;
+ /* Overwrite pinctrl-0 from sdm845.dtsi */
+ pinctrl-0 = <&qup_i2c3_default &i2c3_hid_active>;
tsel: hid@15 {
compatible = "hid-over-i2c";
@@ -270,9 +272,6 @@
hid-descr-addr = <0x1>;
interrupts-extended = <&tlmm 37 IRQ_TYPE_LEVEL_HIGH>;
-
- pinctrl-names = "default";
- pinctrl-0 = <&i2c3_hid_active>;
};
tsc2: hid@2c {
@@ -281,11 +280,6 @@
hid-descr-addr = <0x20>;
interrupts-extended = <&tlmm 37 IRQ_TYPE_LEVEL_HIGH>;
-
- pinctrl-names = "default";
- pinctrl-0 = <&i2c3_hid_active>;
-
- status = "disabled";
};
};
--
2.27.0
^ permalink raw reply related [flat|nested] 140+ messages in thread* [PATCH 5.10 016/120] Input: i8042 - unbreak Pegatron C15B
2021-02-08 14:59 [PATCH 5.10 000/120] 5.10.15-rc1 review Greg Kroah-Hartman
` (14 preceding siblings ...)
2021-02-08 15:00 ` [PATCH 5.10 015/120] arm64: dts: qcom: c630: keep both touchpad devices enabled Greg Kroah-Hartman
@ 2021-02-08 15:00 ` Greg Kroah-Hartman
2021-02-08 15:00 ` [PATCH 5.10 017/120] arm64: dts: amlogic: meson-g12: Set FL-adj property value Greg Kroah-Hartman
` (110 subsequent siblings)
126 siblings, 0 replies; 140+ messages in thread
From: Greg Kroah-Hartman @ 2021-02-08 15:00 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Alexey Dobriyan, Po-Hsu Lin,
Dmitry Torokhov, Sasha Levin
From: Alexey Dobriyan <adobriyan@gmail.com>
[ Upstream commit a3a9060ecad030e2c7903b2b258383d2c716b56c ]
g++ reports
drivers/input/serio/i8042-x86ia64io.h:225:3: error: ‘.matches’ designator used multiple times in the same initializer list
C99 semantics is that last duplicated initialiser wins,
so DMI entry gets overwritten.
Fixes: a48491c65b51 ("Input: i8042 - add ByteSpeed touchpad to noloop table")
Signed-off-by: Alexey Dobriyan <adobriyan@gmail.com>
Acked-by: Po-Hsu Lin <po-hsu.lin@canonical.com>
Link: https://lore.kernel.org/r/20201228072335.GA27766@localhost.localdomain
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/input/serio/i8042-x86ia64io.h | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/input/serio/i8042-x86ia64io.h b/drivers/input/serio/i8042-x86ia64io.h
index 3a2dcf0805f12..c74b020796a94 100644
--- a/drivers/input/serio/i8042-x86ia64io.h
+++ b/drivers/input/serio/i8042-x86ia64io.h
@@ -219,6 +219,8 @@ static const struct dmi_system_id __initconst i8042_dmi_noloop_table[] = {
DMI_MATCH(DMI_SYS_VENDOR, "PEGATRON CORPORATION"),
DMI_MATCH(DMI_PRODUCT_NAME, "C15B"),
},
+ },
+ {
.matches = {
DMI_MATCH(DMI_SYS_VENDOR, "ByteSpeed LLC"),
DMI_MATCH(DMI_PRODUCT_NAME, "ByteSpeed Laptop C15B"),
--
2.27.0
^ permalink raw reply related [flat|nested] 140+ messages in thread* [PATCH 5.10 017/120] arm64: dts: amlogic: meson-g12: Set FL-adj property value
2021-02-08 14:59 [PATCH 5.10 000/120] 5.10.15-rc1 review Greg Kroah-Hartman
` (15 preceding siblings ...)
2021-02-08 15:00 ` [PATCH 5.10 016/120] Input: i8042 - unbreak Pegatron C15B Greg Kroah-Hartman
@ 2021-02-08 15:00 ` Greg Kroah-Hartman
2021-02-08 15:00 ` [PATCH 5.10 018/120] arm64: dts: rockchip: fix vopl iommu irq on px30 Greg Kroah-Hartman
` (109 subsequent siblings)
126 siblings, 0 replies; 140+ messages in thread
From: Greg Kroah-Hartman @ 2021-02-08 15:00 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Serge Semin, Martin Blumenstingl,
Neil Armstrong, Krzysztof Kozlowski, Kevin Hilman, Sasha Levin
From: Serge Semin <Sergey.Semin@baikalelectronics.ru>
[ Upstream commit 7386a559caa6414e74578172c2bc4e636d6bd0a0 ]
In accordance with the DWC USB3 bindings the property is supposed to have
uint32 type. It's erroneous from the DT schema and driver points of view
to declare it as boolean. As Neil suggested set it to 0x20 so not break
the platform and to make the dtbs checker happy.
Link: https://lore.kernel.org/linux-usb/20201010224121.12672-16-Sergey.Semin@baikalelectronics.ru/
Signed-off-by: Serge Semin <Sergey.Semin@baikalelectronics.ru>
Reviewed-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
Reviewed-by: Neil Armstrong <narmstrong@baylibre.com>
Reviewed-by: Krzysztof Kozlowski <krzk@kernel.org>
Fixes: 9baf7d6be730 ("arm64: dts: meson: g12a: Add G12A USB nodes")
Signed-off-by: Kevin Hilman <khilman@baylibre.com>
Link: https://lore.kernel.org/r/20201210091756.18057-3-Sergey.Semin@baikalelectronics.ru
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
arch/arm64/boot/dts/amlogic/meson-g12-common.dtsi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm64/boot/dts/amlogic/meson-g12-common.dtsi b/arch/arm64/boot/dts/amlogic/meson-g12-common.dtsi
index 8514fe6a275a3..a6127002573bd 100644
--- a/arch/arm64/boot/dts/amlogic/meson-g12-common.dtsi
+++ b/arch/arm64/boot/dts/amlogic/meson-g12-common.dtsi
@@ -2384,7 +2384,7 @@
interrupts = <GIC_SPI 30 IRQ_TYPE_LEVEL_HIGH>;
dr_mode = "host";
snps,dis_u2_susphy_quirk;
- snps,quirk-frame-length-adjustment;
+ snps,quirk-frame-length-adjustment = <0x20>;
snps,parkmode-disable-ss-quirk;
};
};
--
2.27.0
^ permalink raw reply related [flat|nested] 140+ messages in thread* [PATCH 5.10 018/120] arm64: dts: rockchip: fix vopl iommu irq on px30
2021-02-08 14:59 [PATCH 5.10 000/120] 5.10.15-rc1 review Greg Kroah-Hartman
` (16 preceding siblings ...)
2021-02-08 15:00 ` [PATCH 5.10 017/120] arm64: dts: amlogic: meson-g12: Set FL-adj property value Greg Kroah-Hartman
@ 2021-02-08 15:00 ` Greg Kroah-Hartman
2021-02-08 15:00 ` [PATCH 5.10 019/120] arm64: dts: rockchip: Use only supported PCIe link speed on Pinebook Pro Greg Kroah-Hartman
` (108 subsequent siblings)
126 siblings, 0 replies; 140+ messages in thread
From: Greg Kroah-Hartman @ 2021-02-08 15:00 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Sandy Huang, Heiko Stuebner,
Ezequiel Garcia, Paul Kocialkowski, Sasha Levin
From: Sandy Huang <hjc@rock-chips.com>
[ Upstream commit 656c648354e1561fa4f445b0b3252ec1d24e3951 ]
The vop-mmu shares the irq with its matched vop but not the vpu.
Fixes: 7053e06b1422 ("arm64: dts: rockchip: add core dtsi file for PX30 SoCs")
Signed-off-by: Sandy Huang <hjc@rock-chips.com>
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Reviewed-by: Ezequiel Garcia <ezequiel@collabora.com>
Reviewed-by: Paul Kocialkowski <paul.kocialkowski@bootlin.com>
Tested-by: Paul Kocialkowski <paul.kocialkowski@bootlin.com>
Link: https://lore.kernel.org/r/20210108110627.3231226-1-heiko@sntech.de
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
arch/arm64/boot/dts/rockchip/px30.dtsi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm64/boot/dts/rockchip/px30.dtsi b/arch/arm64/boot/dts/rockchip/px30.dtsi
index 2695ea8cda142..64193292d26c3 100644
--- a/arch/arm64/boot/dts/rockchip/px30.dtsi
+++ b/arch/arm64/boot/dts/rockchip/px30.dtsi
@@ -1097,7 +1097,7 @@
vopl_mmu: iommu@ff470f00 {
compatible = "rockchip,iommu";
reg = <0x0 0xff470f00 0x0 0x100>;
- interrupts = <GIC_SPI 79 IRQ_TYPE_LEVEL_HIGH>;
+ interrupts = <GIC_SPI 78 IRQ_TYPE_LEVEL_HIGH>;
interrupt-names = "vopl_mmu";
clocks = <&cru ACLK_VOPL>, <&cru HCLK_VOPL>;
clock-names = "aclk", "iface";
--
2.27.0
^ permalink raw reply related [flat|nested] 140+ messages in thread* [PATCH 5.10 019/120] arm64: dts: rockchip: Use only supported PCIe link speed on Pinebook Pro
2021-02-08 14:59 [PATCH 5.10 000/120] 5.10.15-rc1 review Greg Kroah-Hartman
` (17 preceding siblings ...)
2021-02-08 15:00 ` [PATCH 5.10 018/120] arm64: dts: rockchip: fix vopl iommu irq on px30 Greg Kroah-Hartman
@ 2021-02-08 15:00 ` Greg Kroah-Hartman
2021-02-08 15:00 ` [PATCH 5.10 020/120] ARM: dts: stm32: Fix polarity of the DH DRC02 uSD card detect Greg Kroah-Hartman
` (107 subsequent siblings)
126 siblings, 0 replies; 140+ messages in thread
From: Greg Kroah-Hartman @ 2021-02-08 15:00 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Simon South, Heiko Stuebner, Sasha Levin
From: Simon South <simon@simonsouth.net>
[ Upstream commit 642fb2795290c4abe629ca34fb8ff6d78baa9fd3 ]
On Pinebook Pro laptops with an NVMe SSD installed, prevent random
crashes in the NVMe driver by not attempting to use a PCIe link speed
higher than that supported by the RK3399 SoC.
See commit 712fa1777207 ("arm64: dts: rockchip: add max-link-speed for
rk3399").
Fixes: 5a65505a6988 ("arm64: dts: rockchip: Add initial support for Pinebook Pro")
Signed-off-by: Simon South <simon@simonsouth.net>
Link: https://lore.kernel.org/r/20200930185627.5918-1-simon@simonsouth.net
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
arch/arm64/boot/dts/rockchip/rk3399-pinebook-pro.dts | 1 -
1 file changed, 1 deletion(-)
diff --git a/arch/arm64/boot/dts/rockchip/rk3399-pinebook-pro.dts b/arch/arm64/boot/dts/rockchip/rk3399-pinebook-pro.dts
index 06d48338c8362..219b7507a10fb 100644
--- a/arch/arm64/boot/dts/rockchip/rk3399-pinebook-pro.dts
+++ b/arch/arm64/boot/dts/rockchip/rk3399-pinebook-pro.dts
@@ -790,7 +790,6 @@
&pcie0 {
bus-scan-delay-ms = <1000>;
ep-gpios = <&gpio2 RK_PD4 GPIO_ACTIVE_HIGH>;
- max-link-speed = <2>;
num-lanes = <4>;
pinctrl-names = "default";
pinctrl-0 = <&pcie_clkreqn_cpm>;
--
2.27.0
^ permalink raw reply related [flat|nested] 140+ messages in thread* [PATCH 5.10 020/120] ARM: dts: stm32: Fix polarity of the DH DRC02 uSD card detect
2021-02-08 14:59 [PATCH 5.10 000/120] 5.10.15-rc1 review Greg Kroah-Hartman
` (18 preceding siblings ...)
2021-02-08 15:00 ` [PATCH 5.10 019/120] arm64: dts: rockchip: Use only supported PCIe link speed on Pinebook Pro Greg Kroah-Hartman
@ 2021-02-08 15:00 ` Greg Kroah-Hartman
2021-02-08 15:00 ` [PATCH 5.10 021/120] ARM: dts: stm32: Connect card-detect signal on DHCOM Greg Kroah-Hartman
` (106 subsequent siblings)
126 siblings, 0 replies; 140+ messages in thread
From: Greg Kroah-Hartman @ 2021-02-08 15:00 UTC (permalink / raw)
To: linux-kernel, linux-arm-kernel
Cc: Greg Kroah-Hartman, stable, Marek Vasut, Alexandre Torgue,
Maxime Coquelin, Patrice Chotard, Patrick Delaunay, linux-stm32,
Alexandre Torgue, Sasha Levin
From: Marek Vasut <marex@denx.de>
[ Upstream commit a0572c0734e4926ac51a31f97c12f752e1cdc7c8 ]
The uSD card detect signal on the DH DRC02 is active-high, with
a default pull down resistor on the board. Invert the polarity.
Fixes: fde180f06d7b ("ARM: dts: stm32: Add DHSOM based DRC02 board")
Signed-off-by: Marek Vasut <marex@denx.de>
Cc: Alexandre Torgue <alexandre.torgue@st.com>
Cc: Maxime Coquelin <mcoquelin.stm32@gmail.com>
Cc: Patrice Chotard <patrice.chotard@st.com>
Cc: Patrick Delaunay <patrick.delaunay@st.com>
Cc: linux-stm32@st-md-mailman.stormreply.com
To: linux-arm-kernel@lists.infradead.org
--
Note that this could not be tested on prototype SoMs, now that it is
tested, this issue surfaced, so it needs to be fixed.
Signed-off-by: Alexandre Torgue <alexandre.torgue@foss.st.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
arch/arm/boot/dts/stm32mp15xx-dhcom-drc02.dtsi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/stm32mp15xx-dhcom-drc02.dtsi b/arch/arm/boot/dts/stm32mp15xx-dhcom-drc02.dtsi
index 62ab23824a3e7..3299a42d80633 100644
--- a/arch/arm/boot/dts/stm32mp15xx-dhcom-drc02.dtsi
+++ b/arch/arm/boot/dts/stm32mp15xx-dhcom-drc02.dtsi
@@ -104,7 +104,7 @@
* are used for on-board microSD slot instead.
*/
/delete-property/broken-cd;
- cd-gpios = <&gpioi 10 (GPIO_ACTIVE_LOW | GPIO_PULL_UP)>;
+ cd-gpios = <&gpioi 10 GPIO_ACTIVE_HIGH>;
disable-wp;
};
--
2.27.0
^ permalink raw reply related [flat|nested] 140+ messages in thread* [PATCH 5.10 021/120] ARM: dts: stm32: Connect card-detect signal on DHCOM
2021-02-08 14:59 [PATCH 5.10 000/120] 5.10.15-rc1 review Greg Kroah-Hartman
` (19 preceding siblings ...)
2021-02-08 15:00 ` [PATCH 5.10 020/120] ARM: dts: stm32: Fix polarity of the DH DRC02 uSD card detect Greg Kroah-Hartman
@ 2021-02-08 15:00 ` Greg Kroah-Hartman
2021-02-08 15:00 ` [PATCH 5.10 022/120] ARM: dts: stm32: Disable WP on DHCOM uSD slot Greg Kroah-Hartman
` (105 subsequent siblings)
126 siblings, 0 replies; 140+ messages in thread
From: Greg Kroah-Hartman @ 2021-02-08 15:00 UTC (permalink / raw)
To: linux-kernel, linux-arm-kernel
Cc: Greg Kroah-Hartman, stable, Marek Vasut, Alexandre Torgue,
Maxime Coquelin, Patrice Chotard, Patrick Delaunay, linux-stm32,
Alexandre Torgue, Sasha Levin
From: Marek Vasut <marex@denx.de>
[ Upstream commit 1a9b001237f85d3cf11a408c2daca6a2245b2add ]
The DHCOM SoM uSD slot card detect signal is connected to GPIO PG1,
describe it in the DT.
Fixes: 34e0c7847dcf ("ARM: dts: stm32: Add DH Electronics DHCOM STM32MP1 SoM and PDK2 board")
Signed-off-by: Marek Vasut <marex@denx.de>
Cc: Alexandre Torgue <alexandre.torgue@st.com>
Cc: Maxime Coquelin <mcoquelin.stm32@gmail.com>
Cc: Patrice Chotard <patrice.chotard@st.com>
Cc: Patrick Delaunay <patrick.delaunay@st.com>
Cc: linux-stm32@st-md-mailman.stormreply.com
To: linux-arm-kernel@lists.infradead.org
Signed-off-by: Alexandre Torgue <alexandre.torgue@foss.st.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
arch/arm/boot/dts/stm32mp15xx-dhcom-som.dtsi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/stm32mp15xx-dhcom-som.dtsi b/arch/arm/boot/dts/stm32mp15xx-dhcom-som.dtsi
index f796a6150313e..90523a44d2541 100644
--- a/arch/arm/boot/dts/stm32mp15xx-dhcom-som.dtsi
+++ b/arch/arm/boot/dts/stm32mp15xx-dhcom-som.dtsi
@@ -353,7 +353,7 @@
pinctrl-0 = <&sdmmc1_b4_pins_a &sdmmc1_dir_pins_a>;
pinctrl-1 = <&sdmmc1_b4_od_pins_a &sdmmc1_dir_pins_a>;
pinctrl-2 = <&sdmmc1_b4_sleep_pins_a &sdmmc1_dir_sleep_pins_a>;
- broken-cd;
+ cd-gpios = <&gpiog 1 (GPIO_ACTIVE_LOW | GPIO_PULL_UP)>;
st,sig-dir;
st,neg-edge;
st,use-ckin;
--
2.27.0
^ permalink raw reply related [flat|nested] 140+ messages in thread* [PATCH 5.10 022/120] ARM: dts: stm32: Disable WP on DHCOM uSD slot
2021-02-08 14:59 [PATCH 5.10 000/120] 5.10.15-rc1 review Greg Kroah-Hartman
` (20 preceding siblings ...)
2021-02-08 15:00 ` [PATCH 5.10 021/120] ARM: dts: stm32: Connect card-detect signal on DHCOM Greg Kroah-Hartman
@ 2021-02-08 15:00 ` Greg Kroah-Hartman
2021-02-08 15:00 ` [PATCH 5.10 023/120] ARM: dts: stm32: Disable optional TSC2004 on DRC02 board Greg Kroah-Hartman
` (104 subsequent siblings)
126 siblings, 0 replies; 140+ messages in thread
From: Greg Kroah-Hartman @ 2021-02-08 15:00 UTC (permalink / raw)
To: linux-kernel, linux-arm-kernel
Cc: Greg Kroah-Hartman, stable, Marek Vasut, Alexandre Torgue,
Maxime Coquelin, Patrice Chotard, Patrick Delaunay, linux-stm32,
Alexandre Torgue, Sasha Levin
From: Marek Vasut <marex@denx.de>
[ Upstream commit 063a60634d48ee89f697371c9850c9370e494f22 ]
The uSD slot has no WP detection, disable it.
Fixes: 34e0c7847dcf ("ARM: dts: stm32: Add DH Electronics DHCOM STM32MP1 SoM and PDK2 board")
Signed-off-by: Marek Vasut <marex@denx.de>
Cc: Alexandre Torgue <alexandre.torgue@st.com>
Cc: Maxime Coquelin <mcoquelin.stm32@gmail.com>
Cc: Patrice Chotard <patrice.chotard@st.com>
Cc: Patrick Delaunay <patrick.delaunay@st.com>
Cc: linux-stm32@st-md-mailman.stormreply.com
To: linux-arm-kernel@lists.infradead.org
Signed-off-by: Alexandre Torgue <alexandre.torgue@foss.st.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
arch/arm/boot/dts/stm32mp15xx-dhcom-som.dtsi | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm/boot/dts/stm32mp15xx-dhcom-som.dtsi b/arch/arm/boot/dts/stm32mp15xx-dhcom-som.dtsi
index 90523a44d2541..2d027dafb7bce 100644
--- a/arch/arm/boot/dts/stm32mp15xx-dhcom-som.dtsi
+++ b/arch/arm/boot/dts/stm32mp15xx-dhcom-som.dtsi
@@ -354,6 +354,7 @@
pinctrl-1 = <&sdmmc1_b4_od_pins_a &sdmmc1_dir_pins_a>;
pinctrl-2 = <&sdmmc1_b4_sleep_pins_a &sdmmc1_dir_sleep_pins_a>;
cd-gpios = <&gpiog 1 (GPIO_ACTIVE_LOW | GPIO_PULL_UP)>;
+ disable-wp;
st,sig-dir;
st,neg-edge;
st,use-ckin;
--
2.27.0
^ permalink raw reply related [flat|nested] 140+ messages in thread* [PATCH 5.10 023/120] ARM: dts: stm32: Disable optional TSC2004 on DRC02 board
2021-02-08 14:59 [PATCH 5.10 000/120] 5.10.15-rc1 review Greg Kroah-Hartman
` (21 preceding siblings ...)
2021-02-08 15:00 ` [PATCH 5.10 022/120] ARM: dts: stm32: Disable WP on DHCOM uSD slot Greg Kroah-Hartman
@ 2021-02-08 15:00 ` Greg Kroah-Hartman
2021-02-08 15:00 ` [PATCH 5.10 024/120] ARM: dts: stm32: Fix GPIO hog flags on DHCOM DRC02 Greg Kroah-Hartman
` (103 subsequent siblings)
126 siblings, 0 replies; 140+ messages in thread
From: Greg Kroah-Hartman @ 2021-02-08 15:00 UTC (permalink / raw)
To: linux-kernel, linux-arm-kernel
Cc: Greg Kroah-Hartman, stable, Marek Vasut, Alexandre Torgue,
Maxime Coquelin, Patrice Chotard, Patrick Delaunay, linux-stm32,
Alexandre Torgue, Sasha Levin
From: Marek Vasut <marex@denx.de>
[ Upstream commit 087698939f30d489e785d7df3e6aa5dce2487b39 ]
The DRC02 has no use for the on-SoM touchscreen controller, and the
on-SoM touchscreen controller may not even be populated, which then
results in error messages in kernel log. Disable the touchscreen
controller in DT.
Fixes: fde180f06d7b ("ARM: dts: stm32: Add DHSOM based DRC02 board")
Signed-off-by: Marek Vasut <marex@denx.de>
Cc: Alexandre Torgue <alexandre.torgue@st.com>
Cc: Maxime Coquelin <mcoquelin.stm32@gmail.com>
Cc: Patrice Chotard <patrice.chotard@st.com>
Cc: Patrick Delaunay <patrick.delaunay@st.com>
Cc: linux-stm32@st-md-mailman.stormreply.com
To: linux-arm-kernel@lists.infradead.org
Signed-off-by: Alexandre Torgue <alexandre.torgue@foss.st.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
arch/arm/boot/dts/stm32mp15xx-dhcom-drc02.dtsi | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/arch/arm/boot/dts/stm32mp15xx-dhcom-drc02.dtsi b/arch/arm/boot/dts/stm32mp15xx-dhcom-drc02.dtsi
index 3299a42d80633..4cabdade6432b 100644
--- a/arch/arm/boot/dts/stm32mp15xx-dhcom-drc02.dtsi
+++ b/arch/arm/boot/dts/stm32mp15xx-dhcom-drc02.dtsi
@@ -87,6 +87,12 @@
};
};
+&i2c4 {
+ touchscreen@49 {
+ status = "disabled";
+ };
+};
+
&i2c5 { /* TP7/TP8 */
pinctrl-names = "default";
pinctrl-0 = <&i2c5_pins_a>;
--
2.27.0
^ permalink raw reply related [flat|nested] 140+ messages in thread* [PATCH 5.10 024/120] ARM: dts: stm32: Fix GPIO hog flags on DHCOM DRC02
2021-02-08 14:59 [PATCH 5.10 000/120] 5.10.15-rc1 review Greg Kroah-Hartman
` (22 preceding siblings ...)
2021-02-08 15:00 ` [PATCH 5.10 023/120] ARM: dts: stm32: Disable optional TSC2004 on DRC02 board Greg Kroah-Hartman
@ 2021-02-08 15:00 ` Greg Kroah-Hartman
2021-02-08 15:00 ` [PATCH 5.10 025/120] vdpa/mlx5: Fix memory key MTT population Greg Kroah-Hartman
` (102 subsequent siblings)
126 siblings, 0 replies; 140+ messages in thread
From: Greg Kroah-Hartman @ 2021-02-08 15:00 UTC (permalink / raw)
To: linux-kernel, linux-arm-kernel
Cc: Greg Kroah-Hartman, stable, Marek Vasut, Alexandre Torgue,
Maxime Coquelin, Patrice Chotard, Patrick Delaunay, linux-stm32,
Alexandre Torgue, Sasha Levin
From: Marek Vasut <marex@denx.de>
[ Upstream commit 83d411224025ac1baab981e3d2f5d29e7761541d ]
The GPIO hog flags are ignored by gpiolib-of.c now, set the flags to 0.
Since GPIO_ACTIVE_HIGH is defined as 0, this change only increases the
correctness of the DT.
Fixes: fde180f06d7b ("ARM: dts: stm32: Add DHSOM based DRC02 board")
Signed-off-by: Marek Vasut <marex@denx.de>
Cc: Alexandre Torgue <alexandre.torgue@st.com>
Cc: Maxime Coquelin <mcoquelin.stm32@gmail.com>
Cc: Patrice Chotard <patrice.chotard@st.com>
Cc: Patrick Delaunay <patrick.delaunay@st.com>
Cc: linux-stm32@st-md-mailman.stormreply.com
To: linux-arm-kernel@lists.infradead.org
Signed-off-by: Alexandre Torgue <alexandre.torgue@foss.st.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
arch/arm/boot/dts/stm32mp15xx-dhcom-drc02.dtsi | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm/boot/dts/stm32mp15xx-dhcom-drc02.dtsi b/arch/arm/boot/dts/stm32mp15xx-dhcom-drc02.dtsi
index 4cabdade6432b..e4d287d994214 100644
--- a/arch/arm/boot/dts/stm32mp15xx-dhcom-drc02.dtsi
+++ b/arch/arm/boot/dts/stm32mp15xx-dhcom-drc02.dtsi
@@ -35,7 +35,7 @@
*/
rs485-rx-en {
gpio-hog;
- gpios = <8 GPIO_ACTIVE_HIGH>;
+ gpios = <8 0>;
output-low;
line-name = "rs485-rx-en";
};
@@ -63,7 +63,7 @@
*/
usb-hub {
gpio-hog;
- gpios = <2 GPIO_ACTIVE_HIGH>;
+ gpios = <2 0>;
output-high;
line-name = "usb-hub-reset";
};
--
2.27.0
^ permalink raw reply related [flat|nested] 140+ messages in thread* [PATCH 5.10 025/120] vdpa/mlx5: Fix memory key MTT population
2021-02-08 14:59 [PATCH 5.10 000/120] 5.10.15-rc1 review Greg Kroah-Hartman
` (23 preceding siblings ...)
2021-02-08 15:00 ` [PATCH 5.10 024/120] ARM: dts: stm32: Fix GPIO hog flags on DHCOM DRC02 Greg Kroah-Hartman
@ 2021-02-08 15:00 ` Greg Kroah-Hartman
2021-02-08 15:00 ` [PATCH 5.10 026/120] bpf, cgroup: Fix optlen WARN_ON_ONCE toctou Greg Kroah-Hartman
` (101 subsequent siblings)
126 siblings, 0 replies; 140+ messages in thread
From: Greg Kroah-Hartman @ 2021-02-08 15:00 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Eli Cohen, Michael S. Tsirkin,
Jason Wang, Sasha Levin
From: Eli Cohen <elic@nvidia.com>
[ Upstream commit 710eb8e32d04714452759f2b66884bfa7e97d495 ]
map_direct_mr() assumed that the number of scatter/gather entries
returned by dma_map_sg_attrs() was equal to the number of segments in
the sgl list. This led to wrong population of the mkey object. Fix this
by properly referring to the returned value.
The hardware expects each MTT entry to contain the DMA address of a
contiguous block of memory of size (1 << mr->log_size) bytes.
dma_map_sg_attrs() can coalesce several sg entries into a single
scatter/gather entry of contiguous DMA range so we need to scan the list
and refer to the size of each s/g entry.
In addition, get rid of fill_sg() which effect is overwritten by
populate_mtts().
Fixes: 94abbccdf291 ("vdpa/mlx5: Add shared memory registration code")
Signed-off-by: Eli Cohen <elic@nvidia.com>
Link: https://lore.kernel.org/r/20210107071845.GA224876@mtl-vdi-166.wap.labs.mlnx
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Acked-by: Jason Wang <jasowang@redhat.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/vdpa/mlx5/core/mlx5_vdpa.h | 1 +
drivers/vdpa/mlx5/core/mr.c | 28 ++++++++++++----------------
2 files changed, 13 insertions(+), 16 deletions(-)
diff --git a/drivers/vdpa/mlx5/core/mlx5_vdpa.h b/drivers/vdpa/mlx5/core/mlx5_vdpa.h
index 5c92a576edae8..08f742fd24099 100644
--- a/drivers/vdpa/mlx5/core/mlx5_vdpa.h
+++ b/drivers/vdpa/mlx5/core/mlx5_vdpa.h
@@ -15,6 +15,7 @@ struct mlx5_vdpa_direct_mr {
struct sg_table sg_head;
int log_size;
int nsg;
+ int nent;
struct list_head list;
u64 offset;
};
diff --git a/drivers/vdpa/mlx5/core/mr.c b/drivers/vdpa/mlx5/core/mr.c
index 4b6195666c589..d300f799efcd1 100644
--- a/drivers/vdpa/mlx5/core/mr.c
+++ b/drivers/vdpa/mlx5/core/mr.c
@@ -25,17 +25,6 @@ static int get_octo_len(u64 len, int page_shift)
return (npages + 1) / 2;
}
-static void fill_sg(struct mlx5_vdpa_direct_mr *mr, void *in)
-{
- struct scatterlist *sg;
- __be64 *pas;
- int i;
-
- pas = MLX5_ADDR_OF(create_mkey_in, in, klm_pas_mtt);
- for_each_sg(mr->sg_head.sgl, sg, mr->nsg, i)
- (*pas) = cpu_to_be64(sg_dma_address(sg));
-}
-
static void mlx5_set_access_mode(void *mkc, int mode)
{
MLX5_SET(mkc, mkc, access_mode_1_0, mode & 0x3);
@@ -45,10 +34,18 @@ static void mlx5_set_access_mode(void *mkc, int mode)
static void populate_mtts(struct mlx5_vdpa_direct_mr *mr, __be64 *mtt)
{
struct scatterlist *sg;
+ int nsg = mr->nsg;
+ u64 dma_addr;
+ u64 dma_len;
+ int j = 0;
int i;
- for_each_sg(mr->sg_head.sgl, sg, mr->nsg, i)
- mtt[i] = cpu_to_be64(sg_dma_address(sg));
+ for_each_sg(mr->sg_head.sgl, sg, mr->nent, i) {
+ for (dma_addr = sg_dma_address(sg), dma_len = sg_dma_len(sg);
+ nsg && dma_len;
+ nsg--, dma_addr += BIT(mr->log_size), dma_len -= BIT(mr->log_size))
+ mtt[j++] = cpu_to_be64(dma_addr);
+ }
}
static int create_direct_mr(struct mlx5_vdpa_dev *mvdev, struct mlx5_vdpa_direct_mr *mr)
@@ -64,7 +61,6 @@ static int create_direct_mr(struct mlx5_vdpa_dev *mvdev, struct mlx5_vdpa_direct
return -ENOMEM;
MLX5_SET(create_mkey_in, in, uid, mvdev->res.uid);
- fill_sg(mr, in);
mkc = MLX5_ADDR_OF(create_mkey_in, in, memory_key_mkey_entry);
MLX5_SET(mkc, mkc, lw, !!(mr->perm & VHOST_MAP_WO));
MLX5_SET(mkc, mkc, lr, !!(mr->perm & VHOST_MAP_RO));
@@ -276,8 +272,8 @@ static int map_direct_mr(struct mlx5_vdpa_dev *mvdev, struct mlx5_vdpa_direct_mr
done:
mr->log_size = log_entity_size;
mr->nsg = nsg;
- err = dma_map_sg_attrs(dma, mr->sg_head.sgl, mr->nsg, DMA_BIDIRECTIONAL, 0);
- if (!err)
+ mr->nent = dma_map_sg_attrs(dma, mr->sg_head.sgl, mr->nsg, DMA_BIDIRECTIONAL, 0);
+ if (!mr->nent)
goto err_map;
err = create_direct_mr(mvdev, mr);
--
2.27.0
^ permalink raw reply related [flat|nested] 140+ messages in thread* [PATCH 5.10 026/120] bpf, cgroup: Fix optlen WARN_ON_ONCE toctou
2021-02-08 14:59 [PATCH 5.10 000/120] 5.10.15-rc1 review Greg Kroah-Hartman
` (24 preceding siblings ...)
2021-02-08 15:00 ` [PATCH 5.10 025/120] vdpa/mlx5: Fix memory key MTT population Greg Kroah-Hartman
@ 2021-02-08 15:00 ` Greg Kroah-Hartman
2021-02-08 15:00 ` [PATCH 5.10 027/120] bpf, cgroup: Fix problematic bounds check Greg Kroah-Hartman
` (100 subsequent siblings)
126 siblings, 0 replies; 140+ messages in thread
From: Greg Kroah-Hartman @ 2021-02-08 15:00 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Loris Reiff, Daniel Borkmann,
Stanislav Fomichev, Sasha Levin
From: Loris Reiff <loris.reiff@liblor.ch>
[ Upstream commit bb8b81e396f7afbe7c50d789e2107512274d2a35 ]
A toctou issue in `__cgroup_bpf_run_filter_getsockopt` can trigger a
WARN_ON_ONCE in a check of `copy_from_user`.
`*optlen` is checked to be non-negative in the individual getsockopt
functions beforehand. Changing `*optlen` in a race to a negative value
will result in a `copy_from_user(ctx.optval, optval, ctx.optlen)` with
`ctx.optlen` being a negative integer.
Fixes: 0d01da6afc54 ("bpf: implement getsockopt and setsockopt hooks")
Signed-off-by: Loris Reiff <loris.reiff@liblor.ch>
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
Reviewed-by: Stanislav Fomichev <sdf@google.com>
Link: https://lore.kernel.org/bpf/20210122164232.61770-1-loris.reiff@liblor.ch
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
kernel/bpf/cgroup.c | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/kernel/bpf/cgroup.c b/kernel/bpf/cgroup.c
index 96555a8a2c545..6ec8f02f463b6 100644
--- a/kernel/bpf/cgroup.c
+++ b/kernel/bpf/cgroup.c
@@ -1442,6 +1442,11 @@ int __cgroup_bpf_run_filter_getsockopt(struct sock *sk, int level,
goto out;
}
+ if (ctx.optlen < 0) {
+ ret = -EFAULT;
+ goto out;
+ }
+
if (copy_from_user(ctx.optval, optval,
min(ctx.optlen, max_optlen)) != 0) {
ret = -EFAULT;
--
2.27.0
^ permalink raw reply related [flat|nested] 140+ messages in thread* [PATCH 5.10 027/120] bpf, cgroup: Fix problematic bounds check
2021-02-08 14:59 [PATCH 5.10 000/120] 5.10.15-rc1 review Greg Kroah-Hartman
` (25 preceding siblings ...)
2021-02-08 15:00 ` [PATCH 5.10 026/120] bpf, cgroup: Fix optlen WARN_ON_ONCE toctou Greg Kroah-Hartman
@ 2021-02-08 15:00 ` Greg Kroah-Hartman
2021-02-08 15:00 ` [PATCH 5.10 028/120] bpf, inode_storage: Put file handler if no storage was found Greg Kroah-Hartman
` (99 subsequent siblings)
126 siblings, 0 replies; 140+ messages in thread
From: Greg Kroah-Hartman @ 2021-02-08 15:00 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Loris Reiff, Daniel Borkmann,
Stanislav Fomichev, Sasha Levin
From: Loris Reiff <loris.reiff@liblor.ch>
[ Upstream commit f4a2da755a7e1f5d845c52aee71336cee289935a ]
Since ctx.optlen is signed, a larger value than max_value could be
passed, as it is later on used as unsigned, which causes a WARN_ON_ONCE
in the copy_to_user.
Fixes: 0d01da6afc54 ("bpf: implement getsockopt and setsockopt hooks")
Signed-off-by: Loris Reiff <loris.reiff@liblor.ch>
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
Reviewed-by: Stanislav Fomichev <sdf@google.com>
Link: https://lore.kernel.org/bpf/20210122164232.61770-2-loris.reiff@liblor.ch
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
kernel/bpf/cgroup.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/kernel/bpf/cgroup.c b/kernel/bpf/cgroup.c
index 6ec8f02f463b6..6aa9e10c6335a 100644
--- a/kernel/bpf/cgroup.c
+++ b/kernel/bpf/cgroup.c
@@ -1464,7 +1464,7 @@ int __cgroup_bpf_run_filter_getsockopt(struct sock *sk, int level,
goto out;
}
- if (ctx.optlen > max_optlen) {
+ if (ctx.optlen > max_optlen || ctx.optlen < 0) {
ret = -EFAULT;
goto out;
}
--
2.27.0
^ permalink raw reply related [flat|nested] 140+ messages in thread* [PATCH 5.10 028/120] bpf, inode_storage: Put file handler if no storage was found
2021-02-08 14:59 [PATCH 5.10 000/120] 5.10.15-rc1 review Greg Kroah-Hartman
` (26 preceding siblings ...)
2021-02-08 15:00 ` [PATCH 5.10 027/120] bpf, cgroup: Fix problematic bounds check Greg Kroah-Hartman
@ 2021-02-08 15:00 ` Greg Kroah-Hartman
2021-02-08 15:00 ` [PATCH 5.10 029/120] um: virtio: free vu_dev only with the contained struct device Greg Kroah-Hartman
` (98 subsequent siblings)
126 siblings, 0 replies; 140+ messages in thread
From: Greg Kroah-Hartman @ 2021-02-08 15:00 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Pan Bian, Daniel Borkmann, KP Singh,
Sasha Levin
From: Pan Bian <bianpan2016@163.com>
[ Upstream commit b9557caaf872271671bdc1ef003d72f421eb72f6 ]
Put file f if inode_storage_ptr() returns NULL.
Fixes: 8ea636848aca ("bpf: Implement bpf_local_storage for inodes")
Signed-off-by: Pan Bian <bianpan2016@163.com>
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
Acked-by: KP Singh <kpsingh@kernel.org>
Link: https://lore.kernel.org/bpf/20210121020856.25507-1-bianpan2016@163.com
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
kernel/bpf/bpf_inode_storage.c | 6 +++++-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/kernel/bpf/bpf_inode_storage.c b/kernel/bpf/bpf_inode_storage.c
index dbc1dbdd2cbf0..c2a501cd90eba 100644
--- a/kernel/bpf/bpf_inode_storage.c
+++ b/kernel/bpf/bpf_inode_storage.c
@@ -125,8 +125,12 @@ static int bpf_fd_inode_storage_update_elem(struct bpf_map *map, void *key,
fd = *(int *)key;
f = fget_raw(fd);
- if (!f || !inode_storage_ptr(f->f_inode))
+ if (!f)
+ return -EBADF;
+ if (!inode_storage_ptr(f->f_inode)) {
+ fput(f);
return -EBADF;
+ }
sdata = bpf_local_storage_update(f->f_inode,
(struct bpf_local_storage_map *)map,
--
2.27.0
^ permalink raw reply related [flat|nested] 140+ messages in thread* [PATCH 5.10 029/120] um: virtio: free vu_dev only with the contained struct device
2021-02-08 14:59 [PATCH 5.10 000/120] 5.10.15-rc1 review Greg Kroah-Hartman
` (27 preceding siblings ...)
2021-02-08 15:00 ` [PATCH 5.10 028/120] bpf, inode_storage: Put file handler if no storage was found Greg Kroah-Hartman
@ 2021-02-08 15:00 ` Greg Kroah-Hartman
2021-02-08 15:00 ` [PATCH 5.10 030/120] bpf, preload: Fix build when $(O) points to a relative path Greg Kroah-Hartman
` (97 subsequent siblings)
126 siblings, 0 replies; 140+ messages in thread
From: Greg Kroah-Hartman @ 2021-02-08 15:00 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Johannes Berg, Richard Weinberger,
Sasha Levin
From: Johannes Berg <johannes.berg@intel.com>
[ Upstream commit f4172b084342fd3f9e38c10650ffe19eac30d8ce ]
Since struct device is refcounted, we shouldn't free the vu_dev
immediately when it's removed from the platform device, but only
when the references actually all go away. Move the freeing to
the release to accomplish that.
Fixes: 5d38f324993f ("um: drivers: Add virtio vhost-user driver")
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Richard Weinberger <richard@nod.at>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
arch/um/drivers/virtio_uml.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/arch/um/drivers/virtio_uml.c b/arch/um/drivers/virtio_uml.c
index a6c4bb6c2c012..c17b8e5ec1869 100644
--- a/arch/um/drivers/virtio_uml.c
+++ b/arch/um/drivers/virtio_uml.c
@@ -1083,6 +1083,7 @@ static void virtio_uml_release_dev(struct device *d)
}
os_close_file(vu_dev->sock);
+ kfree(vu_dev);
}
/* Platform device */
@@ -1096,7 +1097,7 @@ static int virtio_uml_probe(struct platform_device *pdev)
if (!pdata)
return -EINVAL;
- vu_dev = devm_kzalloc(&pdev->dev, sizeof(*vu_dev), GFP_KERNEL);
+ vu_dev = kzalloc(sizeof(*vu_dev), GFP_KERNEL);
if (!vu_dev)
return -ENOMEM;
--
2.27.0
^ permalink raw reply related [flat|nested] 140+ messages in thread* [PATCH 5.10 030/120] bpf, preload: Fix build when $(O) points to a relative path
2021-02-08 14:59 [PATCH 5.10 000/120] 5.10.15-rc1 review Greg Kroah-Hartman
` (28 preceding siblings ...)
2021-02-08 15:00 ` [PATCH 5.10 029/120] um: virtio: free vu_dev only with the contained struct device Greg Kroah-Hartman
@ 2021-02-08 15:00 ` Greg Kroah-Hartman
2021-02-08 15:00 ` [PATCH 5.10 031/120] arm64: dts: meson: switch TFLASH_VDD_EN pin to open drain on Odroid-C4 Greg Kroah-Hartman
` (96 subsequent siblings)
126 siblings, 0 replies; 140+ messages in thread
From: Greg Kroah-Hartman @ 2021-02-08 15:00 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, David Gow, Quentin Monnet,
Daniel Borkmann, Andrii Nakryiko, Brendan Higgins,
Masahiro Yamada, Sasha Levin
From: Quentin Monnet <quentin@isovalent.com>
[ Upstream commit 150a27328b681425c8cab239894a48f2aeb870e9 ]
Building the kernel with CONFIG_BPF_PRELOAD, and by providing a relative
path for the output directory, may fail with the following error:
$ make O=build bindeb-pkg
...
/.../linux/tools/scripts/Makefile.include:5: *** O=build does not exist. Stop.
make[7]: *** [/.../linux/kernel/bpf/preload/Makefile:9: kernel/bpf/preload/libbpf.a] Error 2
make[6]: *** [/.../linux/scripts/Makefile.build:500: kernel/bpf/preload] Error 2
make[5]: *** [/.../linux/scripts/Makefile.build:500: kernel/bpf] Error 2
make[4]: *** [/.../linux/Makefile:1799: kernel] Error 2
make[4]: *** Waiting for unfinished jobs....
In the case above, for the "bindeb-pkg" target, the error is produced by
the "dummy" check in Makefile.include, called from libbpf's Makefile.
This check changes directory to $(PWD) before checking for the existence
of $(O). But at this step we have $(PWD) pointing to "/.../linux/build",
and $(O) pointing to "build". So the Makefile.include tries in fact to
assert the existence of a directory named "/.../linux/build/build",
which does not exist.
Note that the error does not occur for all make targets and
architectures combinations. This was observed on x86 for "bindeb-pkg",
or for a regular build for UML [0].
Here are some details. The root Makefile recursively calls itself once,
after changing directory to $(O). The content for the variable $(PWD) is
preserved across recursive calls to make, so it is unchanged at this
step. For "bindeb-pkg", $(PWD) is eventually updated because the target
writes a new Makefile (as debian/rules) and calls it indirectly through
dpkg-buildpackage. This script does not preserve $(PWD), which is reset
to the current working directory when the target in debian/rules is
called.
Although not investigated, it seems likely that something similar causes
UML to change its value for $(PWD).
Non-trivial fixes could be to remove the use of $(PWD) from the "dummy"
check, or to make sure that $(PWD) and $(O) are preserved or updated to
always play well and form a valid $(PWD)/$(O) path across the different
targets and architectures. Instead, we take a simpler approach and just
update $(O) when calling libbpf's Makefile, so it points to an absolute
path which should always resolve for the "dummy" check run (through
includes) by that Makefile.
David Gow previously posted a slightly different version of this patch
as a RFC [0], two months ago or so.
[0] https://lore.kernel.org/bpf/20201119085022.3606135-1-davidgow@google.com/t/#u
Fixes: d71fa5c9763c ("bpf: Add kernel module with user mode driver that populates bpffs.")
Reported-by: David Gow <davidgow@google.com>
Signed-off-by: Quentin Monnet <quentin@isovalent.com>
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
Acked-by: Andrii Nakryiko <andrii@kernel.org>
Cc: Brendan Higgins <brendanhiggins@google.com>
Cc: Masahiro Yamada <masahiroy@kernel.org>
Link: https://lore.kernel.org/bpf/20210126161320.24561-1-quentin@isovalent.com
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
kernel/bpf/preload/Makefile | 5 ++++-
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/kernel/bpf/preload/Makefile b/kernel/bpf/preload/Makefile
index 23ee310b6eb49..1951332dd15f5 100644
--- a/kernel/bpf/preload/Makefile
+++ b/kernel/bpf/preload/Makefile
@@ -4,8 +4,11 @@ LIBBPF_SRCS = $(srctree)/tools/lib/bpf/
LIBBPF_A = $(obj)/libbpf.a
LIBBPF_OUT = $(abspath $(obj))
+# Although not in use by libbpf's Makefile, set $(O) so that the "dummy" test
+# in tools/scripts/Makefile.include always succeeds when building the kernel
+# with $(O) pointing to a relative path, as in "make O=build bindeb-pkg".
$(LIBBPF_A):
- $(Q)$(MAKE) -C $(LIBBPF_SRCS) OUTPUT=$(LIBBPF_OUT)/ $(LIBBPF_OUT)/libbpf.a
+ $(Q)$(MAKE) -C $(LIBBPF_SRCS) O=$(LIBBPF_OUT)/ OUTPUT=$(LIBBPF_OUT)/ $(LIBBPF_OUT)/libbpf.a
userccflags += -I $(srctree)/tools/include/ -I $(srctree)/tools/include/uapi \
-I $(srctree)/tools/lib/ -Wno-unused-result
--
2.27.0
^ permalink raw reply related [flat|nested] 140+ messages in thread* [PATCH 5.10 031/120] arm64: dts: meson: switch TFLASH_VDD_EN pin to open drain on Odroid-C4
2021-02-08 14:59 [PATCH 5.10 000/120] 5.10.15-rc1 review Greg Kroah-Hartman
` (29 preceding siblings ...)
2021-02-08 15:00 ` [PATCH 5.10 030/120] bpf, preload: Fix build when $(O) points to a relative path Greg Kroah-Hartman
@ 2021-02-08 15:00 ` Greg Kroah-Hartman
2021-02-08 15:00 ` [PATCH 5.10 032/120] r8169: work around RTL8125 UDP hw bug Greg Kroah-Hartman
` (95 subsequent siblings)
126 siblings, 0 replies; 140+ messages in thread
From: Greg Kroah-Hartman @ 2021-02-08 15:00 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Neil Armstrong, Marek Szyprowski,
Martin Blumenstingl, Kevin Hilman, Sasha Levin
From: Marek Szyprowski <m.szyprowski@samsung.com>
[ Upstream commit daf12bee07b9e2f38216f58aca7ac4e4e66a7146 ]
For the proper reboot Odroid-C4 board requires to switch TFLASH_VDD_EN
pin to the high impedance mode, otherwise the board is stuck in the
middle of loading early stages of the bootloader from SD card.
This can be achieved by using the OPEN_DRAIN flag instead of the
ACTIVE_HIGH, what will leave the pin in input mode to achieve high state
(pin has the pull-up) and solve the issue.
Suggested-by: Neil Armstrong <narmstrong@baylibre.com>
Fixes: 326e57518b0d ("arm64: dts: meson-sm1: add support for Hardkernel ODROID-C4")
Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
Acked-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
Signed-off-by: Kevin Hilman <khilman@baylibre.com>
Link: https://lore.kernel.org/r/20210122055218.27241-1-m.szyprowski@samsung.com
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
arch/arm64/boot/dts/amlogic/meson-sm1-odroid-c4.dts | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm64/boot/dts/amlogic/meson-sm1-odroid-c4.dts b/arch/arm64/boot/dts/amlogic/meson-sm1-odroid-c4.dts
index cf5a98f0e47c8..a712273c905af 100644
--- a/arch/arm64/boot/dts/amlogic/meson-sm1-odroid-c4.dts
+++ b/arch/arm64/boot/dts/amlogic/meson-sm1-odroid-c4.dts
@@ -52,7 +52,7 @@
regulator-min-microvolt = <3300000>;
regulator-max-microvolt = <3300000>;
- gpio = <&gpio_ao GPIOAO_3 GPIO_ACTIVE_HIGH>;
+ gpio = <&gpio_ao GPIOAO_3 GPIO_OPEN_DRAIN>;
enable-active-high;
regulator-always-on;
};
--
2.27.0
^ permalink raw reply related [flat|nested] 140+ messages in thread* [PATCH 5.10 032/120] r8169: work around RTL8125 UDP hw bug
2021-02-08 14:59 [PATCH 5.10 000/120] 5.10.15-rc1 review Greg Kroah-Hartman
` (30 preceding siblings ...)
2021-02-08 15:00 ` [PATCH 5.10 031/120] arm64: dts: meson: switch TFLASH_VDD_EN pin to open drain on Odroid-C4 Greg Kroah-Hartman
@ 2021-02-08 15:00 ` Greg Kroah-Hartman
2021-02-08 15:00 ` [PATCH 5.10 033/120] rxrpc: Fix deadlock around release of dst cached on udp tunnel Greg Kroah-Hartman
` (94 subsequent siblings)
126 siblings, 0 replies; 140+ messages in thread
From: Greg Kroah-Hartman @ 2021-02-08 15:00 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, xplo, Heiner Kallweit,
Willem de Bruijn, Jakub Kicinski, Sasha Levin
From: Heiner Kallweit <hkallweit1@gmail.com>
[ Upstream commit 8d520b4de3edca4f4fb242b5ddc659b6a9b9e65e ]
It was reported that on RTL8125 network breaks under heavy UDP load,
e.g. torrent traffic ([0], from comment 27). Realtek confirmed a hw bug
and provided me with a test version of the r8125 driver including a
workaround. Tests confirmed that the workaround fixes the issue.
I modified the original version of the workaround to meet mainline
code style.
[0] https://bugzilla.kernel.org/show_bug.cgi?id=209839
v2:
- rebased to net
v3:
- make rtl_skb_is_udp() more robust and use skb_header_pointer()
to access the ip(v6) header
v4:
- remove dependency on ptp_classify.h
- replace magic number with offsetof(struct udphdr, len)
Fixes: f1bce4ad2f1c ("r8169: add support for RTL8125")
Tested-by: xplo <xplo.bn@gmail.com>
Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
Acked-by: Willem de Bruijn <willemb@google.com>
Link: https://lore.kernel.org/r/6e453d49-1801-e6de-d5f7-d7e6c7526c8f@gmail.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/net/ethernet/realtek/r8169_main.c | 71 +++++++++++++++++++++--
1 file changed, 65 insertions(+), 6 deletions(-)
diff --git a/drivers/net/ethernet/realtek/r8169_main.c b/drivers/net/ethernet/realtek/r8169_main.c
index 762cabf16157b..64b77d415a525 100644
--- a/drivers/net/ethernet/realtek/r8169_main.c
+++ b/drivers/net/ethernet/realtek/r8169_main.c
@@ -4082,17 +4082,72 @@ err_out:
return -EIO;
}
-static bool rtl_test_hw_pad_bug(struct rtl8169_private *tp)
+static bool rtl_skb_is_udp(struct sk_buff *skb)
+{
+ int no = skb_network_offset(skb);
+ struct ipv6hdr *i6h, _i6h;
+ struct iphdr *ih, _ih;
+
+ switch (vlan_get_protocol(skb)) {
+ case htons(ETH_P_IP):
+ ih = skb_header_pointer(skb, no, sizeof(_ih), &_ih);
+ return ih && ih->protocol == IPPROTO_UDP;
+ case htons(ETH_P_IPV6):
+ i6h = skb_header_pointer(skb, no, sizeof(_i6h), &_i6h);
+ return i6h && i6h->nexthdr == IPPROTO_UDP;
+ default:
+ return false;
+ }
+}
+
+#define RTL_MIN_PATCH_LEN 47
+
+/* see rtl8125_get_patch_pad_len() in r8125 vendor driver */
+static unsigned int rtl8125_quirk_udp_padto(struct rtl8169_private *tp,
+ struct sk_buff *skb)
{
+ unsigned int padto = 0, len = skb->len;
+
+ if (rtl_is_8125(tp) && len < 128 + RTL_MIN_PATCH_LEN &&
+ rtl_skb_is_udp(skb) && skb_transport_header_was_set(skb)) {
+ unsigned int trans_data_len = skb_tail_pointer(skb) -
+ skb_transport_header(skb);
+
+ if (trans_data_len >= offsetof(struct udphdr, len) &&
+ trans_data_len < RTL_MIN_PATCH_LEN) {
+ u16 dest = ntohs(udp_hdr(skb)->dest);
+
+ /* dest is a standard PTP port */
+ if (dest == 319 || dest == 320)
+ padto = len + RTL_MIN_PATCH_LEN - trans_data_len;
+ }
+
+ if (trans_data_len < sizeof(struct udphdr))
+ padto = max_t(unsigned int, padto,
+ len + sizeof(struct udphdr) - trans_data_len);
+ }
+
+ return padto;
+}
+
+static unsigned int rtl_quirk_packet_padto(struct rtl8169_private *tp,
+ struct sk_buff *skb)
+{
+ unsigned int padto;
+
+ padto = rtl8125_quirk_udp_padto(tp, skb);
+
switch (tp->mac_version) {
case RTL_GIGA_MAC_VER_34:
case RTL_GIGA_MAC_VER_60:
case RTL_GIGA_MAC_VER_61:
case RTL_GIGA_MAC_VER_63:
- return true;
+ padto = max_t(unsigned int, padto, ETH_ZLEN);
default:
- return false;
+ break;
}
+
+ return padto;
}
static void rtl8169_tso_csum_v1(struct sk_buff *skb, u32 *opts)
@@ -4164,9 +4219,10 @@ static bool rtl8169_tso_csum_v2(struct rtl8169_private *tp,
opts[1] |= transport_offset << TCPHO_SHIFT;
} else {
- if (unlikely(skb->len < ETH_ZLEN && rtl_test_hw_pad_bug(tp)))
- /* eth_skb_pad would free the skb on error */
- return !__skb_put_padto(skb, ETH_ZLEN, false);
+ unsigned int padto = rtl_quirk_packet_padto(tp, skb);
+
+ /* skb_padto would free the skb on error */
+ return !__skb_put_padto(skb, padto, false);
}
return true;
@@ -4349,6 +4405,9 @@ static netdev_features_t rtl8169_features_check(struct sk_buff *skb,
if (skb->len < ETH_ZLEN)
features &= ~NETIF_F_CSUM_MASK;
+ if (rtl_quirk_packet_padto(tp, skb))
+ features &= ~NETIF_F_CSUM_MASK;
+
if (transport_offset > TCPHO_MAX &&
rtl_chip_supports_csum_v2(tp))
features &= ~NETIF_F_CSUM_MASK;
--
2.27.0
^ permalink raw reply related [flat|nested] 140+ messages in thread* [PATCH 5.10 033/120] rxrpc: Fix deadlock around release of dst cached on udp tunnel
2021-02-08 14:59 [PATCH 5.10 000/120] 5.10.15-rc1 review Greg Kroah-Hartman
` (31 preceding siblings ...)
2021-02-08 15:00 ` [PATCH 5.10 032/120] r8169: work around RTL8125 UDP hw bug Greg Kroah-Hartman
@ 2021-02-08 15:00 ` Greg Kroah-Hartman
2021-02-08 15:00 ` [PATCH 5.10 034/120] arm64: dts: ls1046a: fix dcfg address range Greg Kroah-Hartman
` (93 subsequent siblings)
126 siblings, 0 replies; 140+ messages in thread
From: Greg Kroah-Hartman @ 2021-02-08 15:00 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, syzbot+df400f2f24a1677cd7e0,
Vadim Fedorenko, David Howells, Jakub Kicinski, Sasha Levin
From: David Howells <dhowells@redhat.com>
[ Upstream commit 5399d52233c47905bbf97dcbaa2d7a9cc31670ba ]
AF_RXRPC sockets use UDP ports in encap mode. This causes socket and dst
from an incoming packet to get stolen and attached to the UDP socket from
whence it is leaked when that socket is closed.
When a network namespace is removed, the wait for dst records to be cleaned
up happens before the cleanup of the rxrpc and UDP socket, meaning that the
wait never finishes.
Fix this by moving the rxrpc (and, by dependence, the afs) private
per-network namespace registrations to the device group rather than subsys
group. This allows cached rxrpc local endpoints to be cleared and their
UDP sockets closed before we try waiting for the dst records.
The symptom is that lines looking like the following:
unregister_netdevice: waiting for lo to become free
get emitted at regular intervals after running something like the
referenced syzbot test.
Thanks to Vadim for tracking this down and work out the fix.
Reported-by: syzbot+df400f2f24a1677cd7e0@syzkaller.appspotmail.com
Reported-by: Vadim Fedorenko <vfedorenko@novek.ru>
Fixes: 5271953cad31 ("rxrpc: Use the UDP encap_rcv hook")
Signed-off-by: David Howells <dhowells@redhat.com>
Acked-by: Vadim Fedorenko <vfedorenko@novek.ru>
Link: https://lore.kernel.org/r/161196443016.3868642.5577440140646403533.stgit@warthog.procyon.org.uk
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
fs/afs/main.c | 6 +++---
net/rxrpc/af_rxrpc.c | 6 +++---
2 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/fs/afs/main.c b/fs/afs/main.c
index accdd8970e7c0..b2975256dadbd 100644
--- a/fs/afs/main.c
+++ b/fs/afs/main.c
@@ -193,7 +193,7 @@ static int __init afs_init(void)
goto error_cache;
#endif
- ret = register_pernet_subsys(&afs_net_ops);
+ ret = register_pernet_device(&afs_net_ops);
if (ret < 0)
goto error_net;
@@ -213,7 +213,7 @@ static int __init afs_init(void)
error_proc:
afs_fs_exit();
error_fs:
- unregister_pernet_subsys(&afs_net_ops);
+ unregister_pernet_device(&afs_net_ops);
error_net:
#ifdef CONFIG_AFS_FSCACHE
fscache_unregister_netfs(&afs_cache_netfs);
@@ -244,7 +244,7 @@ static void __exit afs_exit(void)
proc_remove(afs_proc_symlink);
afs_fs_exit();
- unregister_pernet_subsys(&afs_net_ops);
+ unregister_pernet_device(&afs_net_ops);
#ifdef CONFIG_AFS_FSCACHE
fscache_unregister_netfs(&afs_cache_netfs);
#endif
diff --git a/net/rxrpc/af_rxrpc.c b/net/rxrpc/af_rxrpc.c
index 0a2f4817ec6cf..41671af6b33f9 100644
--- a/net/rxrpc/af_rxrpc.c
+++ b/net/rxrpc/af_rxrpc.c
@@ -990,7 +990,7 @@ static int __init af_rxrpc_init(void)
goto error_security;
}
- ret = register_pernet_subsys(&rxrpc_net_ops);
+ ret = register_pernet_device(&rxrpc_net_ops);
if (ret)
goto error_pernet;
@@ -1035,7 +1035,7 @@ error_key_type:
error_sock:
proto_unregister(&rxrpc_proto);
error_proto:
- unregister_pernet_subsys(&rxrpc_net_ops);
+ unregister_pernet_device(&rxrpc_net_ops);
error_pernet:
rxrpc_exit_security();
error_security:
@@ -1057,7 +1057,7 @@ static void __exit af_rxrpc_exit(void)
unregister_key_type(&key_type_rxrpc);
sock_unregister(PF_RXRPC);
proto_unregister(&rxrpc_proto);
- unregister_pernet_subsys(&rxrpc_net_ops);
+ unregister_pernet_device(&rxrpc_net_ops);
ASSERTCMP(atomic_read(&rxrpc_n_tx_skbs), ==, 0);
ASSERTCMP(atomic_read(&rxrpc_n_rx_skbs), ==, 0);
--
2.27.0
^ permalink raw reply related [flat|nested] 140+ messages in thread* [PATCH 5.10 034/120] arm64: dts: ls1046a: fix dcfg address range
2021-02-08 14:59 [PATCH 5.10 000/120] 5.10.15-rc1 review Greg Kroah-Hartman
` (32 preceding siblings ...)
2021-02-08 15:00 ` [PATCH 5.10 033/120] rxrpc: Fix deadlock around release of dst cached on udp tunnel Greg Kroah-Hartman
@ 2021-02-08 15:00 ` Greg Kroah-Hartman
2021-02-08 15:00 ` [PATCH 5.10 035/120] SUNRPC: Fix NFS READs that start at non-page-aligned offsets Greg Kroah-Hartman
` (92 subsequent siblings)
126 siblings, 0 replies; 140+ messages in thread
From: Greg Kroah-Hartman @ 2021-02-08 15:00 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Zyta Szpak, Shawn Guo, Sasha Levin
From: Zyta Szpak <zr@semihalf.com>
[ Upstream commit aa880c6f3ee6dbd0d5ab02026a514ff8ea0a3328 ]
Dcfg was overlapping with clockgen address space which resulted
in failure in memory allocation for dcfg. According regs description
dcfg size should not be bigger than 4KB.
Signed-off-by: Zyta Szpak <zr@semihalf.com>
Fixes: 8126d88162a5 ("arm64: dts: add QorIQ LS1046A SoC support")
Signed-off-by: Shawn Guo <shawnguo@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
arch/arm64/boot/dts/freescale/fsl-ls1046a.dtsi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm64/boot/dts/freescale/fsl-ls1046a.dtsi b/arch/arm64/boot/dts/freescale/fsl-ls1046a.dtsi
index 1fa39bacff4b3..0b4545012d43e 100644
--- a/arch/arm64/boot/dts/freescale/fsl-ls1046a.dtsi
+++ b/arch/arm64/boot/dts/freescale/fsl-ls1046a.dtsi
@@ -385,7 +385,7 @@
dcfg: dcfg@1ee0000 {
compatible = "fsl,ls1046a-dcfg", "syscon";
- reg = <0x0 0x1ee0000 0x0 0x10000>;
+ reg = <0x0 0x1ee0000 0x0 0x1000>;
big-endian;
};
--
2.27.0
^ permalink raw reply related [flat|nested] 140+ messages in thread* [PATCH 5.10 035/120] SUNRPC: Fix NFS READs that start at non-page-aligned offsets
2021-02-08 14:59 [PATCH 5.10 000/120] 5.10.15-rc1 review Greg Kroah-Hartman
` (33 preceding siblings ...)
2021-02-08 15:00 ` [PATCH 5.10 034/120] arm64: dts: ls1046a: fix dcfg address range Greg Kroah-Hartman
@ 2021-02-08 15:00 ` Greg Kroah-Hartman
2021-02-08 15:00 ` [PATCH 5.10 036/120] igc: set the default return value to -IGC_ERR_NVM in igc_write_nvm_srwr Greg Kroah-Hartman
` (91 subsequent siblings)
126 siblings, 0 replies; 140+ messages in thread
From: Greg Kroah-Hartman @ 2021-02-08 15:00 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, A. Duvnjak, Chuck Lever, Sasha Levin
From: Chuck Lever <chuck.lever@oracle.com>
[ Upstream commit bad4c6eb5eaa8300e065bd4426727db5141d687d ]
Anj Duvnjak reports that the Kodi.tv NFS client is not able to read
video files from a v5.10.11 Linux NFS server.
The new sendpage-based TCP sendto logic was not attentive to non-
zero page_base values. nfsd_splice_read() sets that field when a
READ payload starts in the middle of a page.
The Linux NFS client rarely emits an NFS READ that is not page-
aligned. All of my testing so far has been with Linux clients, so I
missed this one.
Reported-by: A. Duvnjak <avian@extremenerds.net>
BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=211471
Fixes: 4a85a6a3320b ("SUNRPC: Handle TCP socket sends with kernel_sendpage() again")
Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
Tested-by: A. Duvnjak <avian@extremenerds.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
net/sunrpc/svcsock.c | 7 ++++---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/net/sunrpc/svcsock.c b/net/sunrpc/svcsock.c
index 4404c491eb388..fa7b7ae2c2c5f 100644
--- a/net/sunrpc/svcsock.c
+++ b/net/sunrpc/svcsock.c
@@ -1113,14 +1113,15 @@ static int svc_tcp_sendmsg(struct socket *sock, struct msghdr *msg,
unsigned int offset, len, remaining;
struct bio_vec *bvec;
- bvec = xdr->bvec;
- offset = xdr->page_base;
+ bvec = xdr->bvec + (xdr->page_base >> PAGE_SHIFT);
+ offset = offset_in_page(xdr->page_base);
remaining = xdr->page_len;
flags = MSG_MORE | MSG_SENDPAGE_NOTLAST;
while (remaining > 0) {
if (remaining <= PAGE_SIZE && tail->iov_len == 0)
flags = 0;
- len = min(remaining, bvec->bv_len);
+
+ len = min(remaining, bvec->bv_len - offset);
ret = kernel_sendpage(sock, bvec->bv_page,
bvec->bv_offset + offset,
len, flags);
--
2.27.0
^ permalink raw reply related [flat|nested] 140+ messages in thread* [PATCH 5.10 036/120] igc: set the default return value to -IGC_ERR_NVM in igc_write_nvm_srwr
2021-02-08 14:59 [PATCH 5.10 000/120] 5.10.15-rc1 review Greg Kroah-Hartman
` (34 preceding siblings ...)
2021-02-08 15:00 ` [PATCH 5.10 035/120] SUNRPC: Fix NFS READs that start at non-page-aligned offsets Greg Kroah-Hartman
@ 2021-02-08 15:00 ` Greg Kroah-Hartman
2021-02-08 15:00 ` [PATCH 5.10 037/120] igc: check return value of ret_val in igc_config_fc_after_link_up Greg Kroah-Hartman
` (90 subsequent siblings)
126 siblings, 0 replies; 140+ messages in thread
From: Greg Kroah-Hartman @ 2021-02-08 15:00 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Kevin Lo, Tony Nguyen, Sasha Levin
From: Kevin Lo <kevlo@kevlo.org>
[ Upstream commit ebc8d125062e7dccb7922b2190b097c20d88ad96 ]
This patch sets the default return value to -IGC_ERR_NVM in
igc_write_nvm_srwr. Without this change it wouldn't lead to a shadow RAM
write EEWR timeout.
Fixes: ab4056126813 ("igc: Add NVM support")
Signed-off-by: Kevin Lo <kevlo@kevlo.org>
Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/net/ethernet/intel/igc/igc_i225.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/intel/igc/igc_i225.c b/drivers/net/ethernet/intel/igc/igc_i225.c
index 8b67d9b49a83a..7ec04e48860c6 100644
--- a/drivers/net/ethernet/intel/igc/igc_i225.c
+++ b/drivers/net/ethernet/intel/igc/igc_i225.c
@@ -219,9 +219,9 @@ static s32 igc_write_nvm_srwr(struct igc_hw *hw, u16 offset, u16 words,
u16 *data)
{
struct igc_nvm_info *nvm = &hw->nvm;
+ s32 ret_val = -IGC_ERR_NVM;
u32 attempts = 100000;
u32 i, k, eewr = 0;
- s32 ret_val = 0;
/* A check for invalid values: offset too large, too many words,
* too many words for the offset, and not enough words.
@@ -229,7 +229,6 @@ static s32 igc_write_nvm_srwr(struct igc_hw *hw, u16 offset, u16 words,
if (offset >= nvm->word_size || (words > (nvm->word_size - offset)) ||
words == 0) {
hw_dbg("nvm parameter(s) out of bounds\n");
- ret_val = -IGC_ERR_NVM;
goto out;
}
--
2.27.0
^ permalink raw reply related [flat|nested] 140+ messages in thread* [PATCH 5.10 037/120] igc: check return value of ret_val in igc_config_fc_after_link_up
2021-02-08 14:59 [PATCH 5.10 000/120] 5.10.15-rc1 review Greg Kroah-Hartman
` (35 preceding siblings ...)
2021-02-08 15:00 ` [PATCH 5.10 036/120] igc: set the default return value to -IGC_ERR_NVM in igc_write_nvm_srwr Greg Kroah-Hartman
@ 2021-02-08 15:00 ` Greg Kroah-Hartman
2021-02-08 15:00 ` [PATCH 5.10 038/120] i40e: Revert "i40e: dont report link up for a VF who hasnt enabled queues" Greg Kroah-Hartman
` (89 subsequent siblings)
126 siblings, 0 replies; 140+ messages in thread
From: Greg Kroah-Hartman @ 2021-02-08 15:00 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Kevin Lo, Sasha Neftin, Tony Nguyen,
Sasha Levin
From: Kevin Lo <kevlo@kevlo.org>
[ Upstream commit b881145642ce0bbe2be521e0882e72a5cebe93b8 ]
Check return value from ret_val to make error check actually work.
Fixes: 4eb8080143a9 ("igc: Add setup link functionality")
Signed-off-by: Kevin Lo <kevlo@kevlo.org>
Acked-by: Sasha Neftin <sasha.neftin@intel.com>
Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/net/ethernet/intel/igc/igc_mac.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/intel/igc/igc_mac.c b/drivers/net/ethernet/intel/igc/igc_mac.c
index 09cd0ec7ee87d..67b8ffd21d8af 100644
--- a/drivers/net/ethernet/intel/igc/igc_mac.c
+++ b/drivers/net/ethernet/intel/igc/igc_mac.c
@@ -638,7 +638,7 @@ s32 igc_config_fc_after_link_up(struct igc_hw *hw)
}
out:
- return 0;
+ return ret_val;
}
/**
--
2.27.0
^ permalink raw reply related [flat|nested] 140+ messages in thread* [PATCH 5.10 038/120] i40e: Revert "i40e: dont report link up for a VF who hasnt enabled queues"
2021-02-08 14:59 [PATCH 5.10 000/120] 5.10.15-rc1 review Greg Kroah-Hartman
` (36 preceding siblings ...)
2021-02-08 15:00 ` [PATCH 5.10 037/120] igc: check return value of ret_val in igc_config_fc_after_link_up Greg Kroah-Hartman
@ 2021-02-08 15:00 ` Greg Kroah-Hartman
2021-02-08 15:00 ` [PATCH 5.10 039/120] ibmvnic: device remove has higher precedence over reset Greg Kroah-Hartman
` (88 subsequent siblings)
126 siblings, 0 replies; 140+ messages in thread
From: Greg Kroah-Hartman @ 2021-02-08 15:00 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Aleksandr Loktionov,
Arkadiusz Kubalewski, Konrad Jankowski, Tony Nguyen, Sasha Levin
From: Aleksandr Loktionov <aleksandr.loktionov@intel.com>
[ Upstream commit f559a356043a55bab25a4c00505ea65c50a956fb ]
This reverts commit 2ad1274fa35ace5c6360762ba48d33b63da2396c
VF queues were not brought up when PF was brought up after being
downed if the VF driver disabled VFs queues during PF down.
This could happen in some older or external VF driver implementations.
The problem was that PF driver used vf->queues_enabled as a condition
to decide what link-state it would send out which caused the issue.
Remove the check for vf->queues_enabled in the VF link notify.
Now VF will always be notified of the current link status.
Also remove the queues_enabled member from i40e_vf structure as it is
not used anymore. Otherwise VNF implementation was broken and caused
a link flap.
The original commit was a workaround to avoid breaking existing VFs though
it's really a fault of the VF code not the PF. The commit should be safe to
revert as all of the VFs we know of have been fixed. Also, since we now
know there is a related bug in the workaround, removing it is preferred.
Fixes: 2ad1274fa35a ("i40e: don't report link up for a VF who hasn't enabled")
Signed-off-by: Aleksandr Loktionov <aleksandr.loktionov@intel.com>
Signed-off-by: Arkadiusz Kubalewski <arkadiusz.kubalewski@intel.com>
Tested-by: Konrad Jankowski <konrad0.jankowski@intel.com>
Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/net/ethernet/intel/i40e/i40e_virtchnl_pf.c | 13 +------------
drivers/net/ethernet/intel/i40e/i40e_virtchnl_pf.h | 1 -
2 files changed, 1 insertion(+), 13 deletions(-)
diff --git a/drivers/net/ethernet/intel/i40e/i40e_virtchnl_pf.c b/drivers/net/ethernet/intel/i40e/i40e_virtchnl_pf.c
index 2872c4dc77f07..3b269c70dcfe1 100644
--- a/drivers/net/ethernet/intel/i40e/i40e_virtchnl_pf.c
+++ b/drivers/net/ethernet/intel/i40e/i40e_virtchnl_pf.c
@@ -55,12 +55,7 @@ static void i40e_vc_notify_vf_link_state(struct i40e_vf *vf)
pfe.event = VIRTCHNL_EVENT_LINK_CHANGE;
pfe.severity = PF_EVENT_SEVERITY_INFO;
-
- /* Always report link is down if the VF queues aren't enabled */
- if (!vf->queues_enabled) {
- pfe.event_data.link_event.link_status = false;
- pfe.event_data.link_event.link_speed = 0;
- } else if (vf->link_forced) {
+ if (vf->link_forced) {
pfe.event_data.link_event.link_status = vf->link_up;
pfe.event_data.link_event.link_speed =
(vf->link_up ? VIRTCHNL_LINK_SPEED_40GB : 0);
@@ -70,7 +65,6 @@ static void i40e_vc_notify_vf_link_state(struct i40e_vf *vf)
pfe.event_data.link_event.link_speed =
i40e_virtchnl_link_speed(ls->link_speed);
}
-
i40e_aq_send_msg_to_vf(hw, abs_vf_id, VIRTCHNL_OP_EVENT,
0, (u8 *)&pfe, sizeof(pfe), NULL);
}
@@ -2443,8 +2437,6 @@ static int i40e_vc_enable_queues_msg(struct i40e_vf *vf, u8 *msg)
}
}
- vf->queues_enabled = true;
-
error_param:
/* send the response to the VF */
return i40e_vc_send_resp_to_vf(vf, VIRTCHNL_OP_ENABLE_QUEUES,
@@ -2466,9 +2458,6 @@ static int i40e_vc_disable_queues_msg(struct i40e_vf *vf, u8 *msg)
struct i40e_pf *pf = vf->pf;
i40e_status aq_ret = 0;
- /* Immediately mark queues as disabled */
- vf->queues_enabled = false;
-
if (!test_bit(I40E_VF_STATE_ACTIVE, &vf->vf_states)) {
aq_ret = I40E_ERR_PARAM;
goto error_param;
diff --git a/drivers/net/ethernet/intel/i40e/i40e_virtchnl_pf.h b/drivers/net/ethernet/intel/i40e/i40e_virtchnl_pf.h
index 5491215d81deb..091e32c1bb46f 100644
--- a/drivers/net/ethernet/intel/i40e/i40e_virtchnl_pf.h
+++ b/drivers/net/ethernet/intel/i40e/i40e_virtchnl_pf.h
@@ -98,7 +98,6 @@ struct i40e_vf {
unsigned int tx_rate; /* Tx bandwidth limit in Mbps */
bool link_forced;
bool link_up; /* only valid if VF link is forced */
- bool queues_enabled; /* true if the VF queues are enabled */
bool spoofchk;
u16 num_vlan;
--
2.27.0
^ permalink raw reply related [flat|nested] 140+ messages in thread* [PATCH 5.10 039/120] ibmvnic: device remove has higher precedence over reset
2021-02-08 14:59 [PATCH 5.10 000/120] 5.10.15-rc1 review Greg Kroah-Hartman
` (37 preceding siblings ...)
2021-02-08 15:00 ` [PATCH 5.10 038/120] i40e: Revert "i40e: dont report link up for a VF who hasnt enabled queues" Greg Kroah-Hartman
@ 2021-02-08 15:00 ` Greg Kroah-Hartman
2021-02-08 15:00 ` [PATCH 5.10 040/120] net/mlx5: Fix function calculation for page trees Greg Kroah-Hartman
` (87 subsequent siblings)
126 siblings, 0 replies; 140+ messages in thread
From: Greg Kroah-Hartman @ 2021-02-08 15:00 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Uwe Kleine-König, Lijun Pan,
Jakub Kicinski, Sasha Levin
From: Lijun Pan <ljp@linux.ibm.com>
[ Upstream commit 5e9eff5dfa460cd1a74b7c1fde4fced7c04383af ]
Returning -EBUSY in ibmvnic_remove() does not actually hold the
removal procedure since driver core doesn't care for the return
value (see __device_release_driver() in drivers/base/dd.c
calling dev->bus->remove()) though vio_bus_remove
(in arch/powerpc/platforms/pseries/vio.c) records the
return value and passes it on. [1]
During the device removal precedure, checking for resetting
bit is dropped so that we can continue executing all the
cleanup calls in the rest of the remove function. Otherwise,
it can cause latent memory leaks and kernel crashes.
[1] https://lore.kernel.org/linuxppc-dev/20210117101242.dpwayq6wdgfdzirl@pengutronix.de/T/#m48f5befd96bc9842ece2a3ad14f4c27747206a53
Reported-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Fixes: 7d7195a026ba ("ibmvnic: Do not process device remove during device reset")
Signed-off-by: Lijun Pan <ljp@linux.ibm.com>
Link: https://lore.kernel.org/r/20210129043402.95744-1-ljp@linux.ibm.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/net/ethernet/ibm/ibmvnic.c | 5 -----
1 file changed, 5 deletions(-)
diff --git a/drivers/net/ethernet/ibm/ibmvnic.c b/drivers/net/ethernet/ibm/ibmvnic.c
index 627ce1a20473a..2f281d0f98070 100644
--- a/drivers/net/ethernet/ibm/ibmvnic.c
+++ b/drivers/net/ethernet/ibm/ibmvnic.c
@@ -5339,11 +5339,6 @@ static int ibmvnic_remove(struct vio_dev *dev)
unsigned long flags;
spin_lock_irqsave(&adapter->state_lock, flags);
- if (test_bit(0, &adapter->resetting)) {
- spin_unlock_irqrestore(&adapter->state_lock, flags);
- return -EBUSY;
- }
-
adapter->state = VNIC_REMOVING;
spin_unlock_irqrestore(&adapter->state_lock, flags);
--
2.27.0
^ permalink raw reply related [flat|nested] 140+ messages in thread* [PATCH 5.10 040/120] net/mlx5: Fix function calculation for page trees
2021-02-08 14:59 [PATCH 5.10 000/120] 5.10.15-rc1 review Greg Kroah-Hartman
` (38 preceding siblings ...)
2021-02-08 15:00 ` [PATCH 5.10 039/120] ibmvnic: device remove has higher precedence over reset Greg Kroah-Hartman
@ 2021-02-08 15:00 ` Greg Kroah-Hartman
2021-02-08 15:00 ` [PATCH 5.10 041/120] net/mlx5: Fix leak upon failure of rule creation Greg Kroah-Hartman
` (86 subsequent siblings)
126 siblings, 0 replies; 140+ messages in thread
From: Greg Kroah-Hartman @ 2021-02-08 15:00 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Daniel Jurgens, Colin Ian King,
Saeed Mahameed, Sasha Levin
From: Daniel Jurgens <danielj@nvidia.com>
[ Upstream commit ed5e83a3c02948dad9dc4e68fb4e535baa5da630 ]
The function calculation always results in a value of 0. This works
generally, but when the release all pages feature is enabled it will
result in crashes.
Fixes: 0aa128475d33 ("net/mlx5: Maintain separate page trees for ECPF and PF functions")
Signed-off-by: Daniel Jurgens <danielj@nvidia.com>
Reported-by: Colin Ian King <colin.king@canonical.com>
Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/net/ethernet/mellanox/mlx5/core/pagealloc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/mellanox/mlx5/core/pagealloc.c b/drivers/net/ethernet/mellanox/mlx5/core/pagealloc.c
index a3e0c71831928..a44a2bad5bbb5 100644
--- a/drivers/net/ethernet/mellanox/mlx5/core/pagealloc.c
+++ b/drivers/net/ethernet/mellanox/mlx5/core/pagealloc.c
@@ -76,7 +76,7 @@ enum {
static u32 get_function(u16 func_id, bool ec_function)
{
- return func_id & (ec_function << 16);
+ return (u32)func_id | (ec_function << 16);
}
static struct rb_root *page_root_per_function(struct mlx5_core_dev *dev, u32 function)
--
2.27.0
^ permalink raw reply related [flat|nested] 140+ messages in thread* [PATCH 5.10 041/120] net/mlx5: Fix leak upon failure of rule creation
2021-02-08 14:59 [PATCH 5.10 000/120] 5.10.15-rc1 review Greg Kroah-Hartman
` (39 preceding siblings ...)
2021-02-08 15:00 ` [PATCH 5.10 040/120] net/mlx5: Fix function calculation for page trees Greg Kroah-Hartman
@ 2021-02-08 15:00 ` Greg Kroah-Hartman
2021-02-08 15:00 ` [PATCH 5.10 042/120] net/mlx5e: Update max_opened_tc also when channels are closed Greg Kroah-Hartman
` (85 subsequent siblings)
126 siblings, 0 replies; 140+ messages in thread
From: Greg Kroah-Hartman @ 2021-02-08 15:00 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Maor Gottlieb, Alaa Hleihel,
Mark Bloch, Saeed Mahameed, Sasha Levin
From: Maor Gottlieb <maorg@nvidia.com>
[ Upstream commit a5bfe6b4675e0eefbd9418055b5cc6e89af27eb4 ]
When creation of a new rule that requires allocation of an FTE fails,
need to call to tree_put_node on the FTE in order to release its'
resource.
Fixes: cefc23554fc2 ("net/mlx5: Fix FTE cleanup")
Signed-off-by: Maor Gottlieb <maorg@nvidia.com>
Reviewed-by: Alaa Hleihel <alaa@nvidia.com>
Reviewed-by: Mark Bloch <mbloch@nvidia.com>
Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/net/ethernet/mellanox/mlx5/core/fs_core.c | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/drivers/net/ethernet/mellanox/mlx5/core/fs_core.c b/drivers/net/ethernet/mellanox/mlx5/core/fs_core.c
index 634c2bfd25be1..79fc5755735fa 100644
--- a/drivers/net/ethernet/mellanox/mlx5/core/fs_core.c
+++ b/drivers/net/ethernet/mellanox/mlx5/core/fs_core.c
@@ -1764,6 +1764,7 @@ search_again_locked:
if (!fte_tmp)
continue;
rule = add_rule_fg(g, spec, flow_act, dest, dest_num, fte_tmp);
+ /* No error check needed here, because insert_fte() is not called */
up_write_ref_node(&fte_tmp->node, false);
tree_put_node(&fte_tmp->node, false);
kmem_cache_free(steering->ftes_cache, fte);
@@ -1816,6 +1817,8 @@ skip_search:
up_write_ref_node(&g->node, false);
rule = add_rule_fg(g, spec, flow_act, dest, dest_num, fte);
up_write_ref_node(&fte->node, false);
+ if (IS_ERR(rule))
+ tree_put_node(&fte->node, false);
return rule;
}
rule = ERR_PTR(-ENOENT);
@@ -1914,6 +1917,8 @@ search_again_locked:
up_write_ref_node(&g->node, false);
rule = add_rule_fg(g, spec, flow_act, dest, dest_num, fte);
up_write_ref_node(&fte->node, false);
+ if (IS_ERR(rule))
+ tree_put_node(&fte->node, false);
tree_put_node(&g->node, false);
return rule;
--
2.27.0
^ permalink raw reply related [flat|nested] 140+ messages in thread* [PATCH 5.10 042/120] net/mlx5e: Update max_opened_tc also when channels are closed
2021-02-08 14:59 [PATCH 5.10 000/120] 5.10.15-rc1 review Greg Kroah-Hartman
` (40 preceding siblings ...)
2021-02-08 15:00 ` [PATCH 5.10 041/120] net/mlx5: Fix leak upon failure of rule creation Greg Kroah-Hartman
@ 2021-02-08 15:00 ` Greg Kroah-Hartman
2021-02-08 15:00 ` [PATCH 5.10 043/120] net/mlx5e: Release skb in case of failure in tc update skb Greg Kroah-Hartman
` (84 subsequent siblings)
126 siblings, 0 replies; 140+ messages in thread
From: Greg Kroah-Hartman @ 2021-02-08 15:00 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Maxim Mikityanskiy, Tariq Toukan,
Saeed Mahameed, Sasha Levin
From: Maxim Mikityanskiy <maximmi@mellanox.com>
[ Upstream commit 5a2ba25a55c4dc0f143567c99aede768b6628ebd ]
max_opened_tc is used for stats, so that potentially non-zero stats
won't disappear when num_tc decreases. However, mlx5e_setup_tc_mqprio
fails to update it in the flow where channels are closed.
This commit fixes it. The new value of priv->channels.params.num_tc is
always checked on exit. In case of errors it will just be the old value,
and in case of success it will be the updated value.
Fixes: 05909babce53 ("net/mlx5e: Avoid reset netdev stats on configuration changes")
Signed-off-by: Maxim Mikityanskiy <maximmi@mellanox.com>
Reviewed-by: Tariq Toukan <tariqt@nvidia.com>
Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/net/ethernet/mellanox/mlx5/core/en_main.c | 6 ++----
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/drivers/net/ethernet/mellanox/mlx5/core/en_main.c b/drivers/net/ethernet/mellanox/mlx5/core/en_main.c
index c9b5d7f29911e..42848db8f8dd6 100644
--- a/drivers/net/ethernet/mellanox/mlx5/core/en_main.c
+++ b/drivers/net/ethernet/mellanox/mlx5/core/en_main.c
@@ -3593,12 +3593,10 @@ static int mlx5e_setup_tc_mqprio(struct mlx5e_priv *priv,
err = mlx5e_safe_switch_channels(priv, &new_channels,
mlx5e_num_channels_changed_ctx, NULL);
- if (err)
- goto out;
- priv->max_opened_tc = max_t(u8, priv->max_opened_tc,
- new_channels.params.num_tc);
out:
+ priv->max_opened_tc = max_t(u8, priv->max_opened_tc,
+ priv->channels.params.num_tc);
mutex_unlock(&priv->state_lock);
return err;
}
--
2.27.0
^ permalink raw reply related [flat|nested] 140+ messages in thread* [PATCH 5.10 043/120] net/mlx5e: Release skb in case of failure in tc update skb
2021-02-08 14:59 [PATCH 5.10 000/120] 5.10.15-rc1 review Greg Kroah-Hartman
` (41 preceding siblings ...)
2021-02-08 15:00 ` [PATCH 5.10 042/120] net/mlx5e: Update max_opened_tc also when channels are closed Greg Kroah-Hartman
@ 2021-02-08 15:00 ` Greg Kroah-Hartman
2021-02-08 15:00 ` [PATCH 5.10 044/120] net: lapb: Copy the skb before sending a packet Greg Kroah-Hartman
` (83 subsequent siblings)
126 siblings, 0 replies; 140+ messages in thread
From: Greg Kroah-Hartman @ 2021-02-08 15:00 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Maor Dickman, Roi Dayan,
Saeed Mahameed, Sasha Levin
From: Maor Dickman <maord@nvidia.com>
[ Upstream commit a34ffec8af8ff1c730697a99e09ec7b74a3423b6 ]
In case of failure in tc update skb the packet is dropped
without freeing the skb.
Fixed by freeing the skb in case failure in tc update skb.
Fixes: d6d27782864f ("net/mlx5: E-Switch, Restore chain id on miss")
Fixes: c75690972228 ("net/mlx5e: Add tc chains offload support for nic flows")
Signed-off-by: Maor Dickman <maord@nvidia.com>
Reviewed-by: Roi Dayan <roid@nvidia.com>
Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/net/ethernet/mellanox/mlx5/core/en_rx.c | 16 ++++++++++++----
1 file changed, 12 insertions(+), 4 deletions(-)
diff --git a/drivers/net/ethernet/mellanox/mlx5/core/en_rx.c b/drivers/net/ethernet/mellanox/mlx5/core/en_rx.c
index 6628a0197b4e0..6d2ba8b84187c 100644
--- a/drivers/net/ethernet/mellanox/mlx5/core/en_rx.c
+++ b/drivers/net/ethernet/mellanox/mlx5/core/en_rx.c
@@ -1262,8 +1262,10 @@ static void mlx5e_handle_rx_cqe(struct mlx5e_rq *rq, struct mlx5_cqe64 *cqe)
mlx5e_complete_rx_cqe(rq, cqe, cqe_bcnt, skb);
if (mlx5e_cqe_regb_chain(cqe))
- if (!mlx5e_tc_update_skb(cqe, skb))
+ if (!mlx5e_tc_update_skb(cqe, skb)) {
+ dev_kfree_skb_any(skb);
goto free_wqe;
+ }
napi_gro_receive(rq->cq.napi, skb);
@@ -1316,8 +1318,10 @@ static void mlx5e_handle_rx_cqe_rep(struct mlx5e_rq *rq, struct mlx5_cqe64 *cqe)
if (rep->vlan && skb_vlan_tag_present(skb))
skb_vlan_pop(skb);
- if (!mlx5e_rep_tc_update_skb(cqe, skb, &tc_priv))
+ if (!mlx5e_rep_tc_update_skb(cqe, skb, &tc_priv)) {
+ dev_kfree_skb_any(skb);
goto free_wqe;
+ }
napi_gro_receive(rq->cq.napi, skb);
@@ -1371,8 +1375,10 @@ static void mlx5e_handle_rx_cqe_mpwrq_rep(struct mlx5e_rq *rq, struct mlx5_cqe64
mlx5e_complete_rx_cqe(rq, cqe, cqe_bcnt, skb);
- if (!mlx5e_rep_tc_update_skb(cqe, skb, &tc_priv))
+ if (!mlx5e_rep_tc_update_skb(cqe, skb, &tc_priv)) {
+ dev_kfree_skb_any(skb);
goto mpwrq_cqe_out;
+ }
napi_gro_receive(rq->cq.napi, skb);
@@ -1528,8 +1534,10 @@ static void mlx5e_handle_rx_cqe_mpwrq(struct mlx5e_rq *rq, struct mlx5_cqe64 *cq
mlx5e_complete_rx_cqe(rq, cqe, cqe_bcnt, skb);
if (mlx5e_cqe_regb_chain(cqe))
- if (!mlx5e_tc_update_skb(cqe, skb))
+ if (!mlx5e_tc_update_skb(cqe, skb)) {
+ dev_kfree_skb_any(skb);
goto mpwrq_cqe_out;
+ }
napi_gro_receive(rq->cq.napi, skb);
--
2.27.0
^ permalink raw reply related [flat|nested] 140+ messages in thread* [PATCH 5.10 044/120] net: lapb: Copy the skb before sending a packet
2021-02-08 14:59 [PATCH 5.10 000/120] 5.10.15-rc1 review Greg Kroah-Hartman
` (42 preceding siblings ...)
2021-02-08 15:00 ` [PATCH 5.10 043/120] net/mlx5e: Release skb in case of failure in tc update skb Greg Kroah-Hartman
@ 2021-02-08 15:00 ` Greg Kroah-Hartman
2021-02-08 15:00 ` [PATCH 5.10 045/120] net: mvpp2: TCAM entry enable should be written after SRAM data Greg Kroah-Hartman
` (82 subsequent siblings)
126 siblings, 0 replies; 140+ messages in thread
From: Greg Kroah-Hartman @ 2021-02-08 15:00 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Xie He, Martin Schiller,
Jakub Kicinski, Sasha Levin
From: Xie He <xie.he.0141@gmail.com>
[ Upstream commit 88c7a9fd9bdd3e453f04018920964c6f848a591a ]
When sending a packet, we will prepend it with an LAPB header.
This modifies the shared parts of a cloned skb, so we should copy the
skb rather than just clone it, before we prepend the header.
In "Documentation/networking/driver.rst" (the 2nd point), it states
that drivers shouldn't modify the shared parts of a cloned skb when
transmitting.
The "dev_queue_xmit_nit" function in "net/core/dev.c", which is called
when an skb is being sent, clones the skb and sents the clone to
AF_PACKET sockets. Because the LAPB drivers first remove a 1-byte
pseudo-header before handing over the skb to us, if we don't copy the
skb before prepending the LAPB header, the first byte of the packets
received on AF_PACKET sockets can be corrupted.
Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
Signed-off-by: Xie He <xie.he.0141@gmail.com>
Acked-by: Martin Schiller <ms@dev.tdt.de>
Link: https://lore.kernel.org/r/20210201055706.415842-1-xie.he.0141@gmail.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
net/lapb/lapb_out.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/net/lapb/lapb_out.c b/net/lapb/lapb_out.c
index 7a4d0715d1c32..a966d29c772d9 100644
--- a/net/lapb/lapb_out.c
+++ b/net/lapb/lapb_out.c
@@ -82,7 +82,8 @@ void lapb_kick(struct lapb_cb *lapb)
skb = skb_dequeue(&lapb->write_queue);
do {
- if ((skbn = skb_clone(skb, GFP_ATOMIC)) == NULL) {
+ skbn = skb_copy(skb, GFP_ATOMIC);
+ if (!skbn) {
skb_queue_head(&lapb->write_queue, skb);
break;
}
--
2.27.0
^ permalink raw reply related [flat|nested] 140+ messages in thread* [PATCH 5.10 045/120] net: mvpp2: TCAM entry enable should be written after SRAM data
2021-02-08 14:59 [PATCH 5.10 000/120] 5.10.15-rc1 review Greg Kroah-Hartman
` (43 preceding siblings ...)
2021-02-08 15:00 ` [PATCH 5.10 044/120] net: lapb: Copy the skb before sending a packet Greg Kroah-Hartman
@ 2021-02-08 15:00 ` Greg Kroah-Hartman
2021-02-08 15:00 ` [PATCH 5.10 046/120] r8169: fix WoL on shutdown if CONFIG_DEBUG_SHIRQ is set Greg Kroah-Hartman
` (81 subsequent siblings)
126 siblings, 0 replies; 140+ messages in thread
From: Greg Kroah-Hartman @ 2021-02-08 15:00 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Stefan Chulski, Jakub Kicinski, Sasha Levin
From: Stefan Chulski <stefanc@marvell.com>
[ Upstream commit 43f4a20a1266d393840ce010f547486d14cc0071 ]
Last TCAM data contains TCAM enable bit.
It should be written after SRAM data before entry enabled.
Fixes: 3f518509dedc ("ethernet: Add new driver for Marvell Armada 375 network unit")
Signed-off-by: Stefan Chulski <stefanc@marvell.com>
Link: https://lore.kernel.org/r/1612172139-28343-1-git-send-email-stefanc@marvell.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/net/ethernet/marvell/mvpp2/mvpp2_prs.c | 10 +++++-----
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/net/ethernet/marvell/mvpp2/mvpp2_prs.c b/drivers/net/ethernet/marvell/mvpp2/mvpp2_prs.c
index a30eb90ba3d28..dd590086fe6a5 100644
--- a/drivers/net/ethernet/marvell/mvpp2/mvpp2_prs.c
+++ b/drivers/net/ethernet/marvell/mvpp2/mvpp2_prs.c
@@ -29,16 +29,16 @@ static int mvpp2_prs_hw_write(struct mvpp2 *priv, struct mvpp2_prs_entry *pe)
/* Clear entry invalidation bit */
pe->tcam[MVPP2_PRS_TCAM_INV_WORD] &= ~MVPP2_PRS_TCAM_INV_MASK;
- /* Write tcam index - indirect access */
- mvpp2_write(priv, MVPP2_PRS_TCAM_IDX_REG, pe->index);
- for (i = 0; i < MVPP2_PRS_TCAM_WORDS; i++)
- mvpp2_write(priv, MVPP2_PRS_TCAM_DATA_REG(i), pe->tcam[i]);
-
/* Write sram index - indirect access */
mvpp2_write(priv, MVPP2_PRS_SRAM_IDX_REG, pe->index);
for (i = 0; i < MVPP2_PRS_SRAM_WORDS; i++)
mvpp2_write(priv, MVPP2_PRS_SRAM_DATA_REG(i), pe->sram[i]);
+ /* Write tcam index - indirect access */
+ mvpp2_write(priv, MVPP2_PRS_TCAM_IDX_REG, pe->index);
+ for (i = 0; i < MVPP2_PRS_TCAM_WORDS; i++)
+ mvpp2_write(priv, MVPP2_PRS_TCAM_DATA_REG(i), pe->tcam[i]);
+
return 0;
}
--
2.27.0
^ permalink raw reply related [flat|nested] 140+ messages in thread* [PATCH 5.10 046/120] r8169: fix WoL on shutdown if CONFIG_DEBUG_SHIRQ is set
2021-02-08 14:59 [PATCH 5.10 000/120] 5.10.15-rc1 review Greg Kroah-Hartman
` (44 preceding siblings ...)
2021-02-08 15:00 ` [PATCH 5.10 045/120] net: mvpp2: TCAM entry enable should be written after SRAM data Greg Kroah-Hartman
@ 2021-02-08 15:00 ` Greg Kroah-Hartman
2021-02-08 15:00 ` [PATCH 5.10 047/120] net: ipa: pass correct dma_handle to dma_free_coherent() Greg Kroah-Hartman
` (80 subsequent siblings)
126 siblings, 0 replies; 140+ messages in thread
From: Greg Kroah-Hartman @ 2021-02-08 15:00 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Heiner Kallweit, Jakub Kicinski, Sasha Levin
From: Heiner Kallweit <hkallweit1@gmail.com>
[ Upstream commit cc9f07a838c4988ed244d0907cb71d54b85482a5 ]
So far phy_disconnect() is called before free_irq(). If CONFIG_DEBUG_SHIRQ
is set and interrupt is shared, then free_irq() creates an "artificial"
interrupt by calling the interrupt handler. The "link change" flag is set
in the interrupt status register, causing phylib to eventually call
phy_suspend(). Because the net_device is detached from the PHY already,
the PHY driver can't recognize that WoL is configured and powers down the
PHY.
Fixes: f1e911d5d0df ("r8169: add basic phylib support")
Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
Link: https://lore.kernel.org/r/fe732c2c-a473-9088-3974-df83cfbd6efd@gmail.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/net/ethernet/realtek/r8169_main.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/realtek/r8169_main.c b/drivers/net/ethernet/realtek/r8169_main.c
index 64b77d415a525..75f774347f6d1 100644
--- a/drivers/net/ethernet/realtek/r8169_main.c
+++ b/drivers/net/ethernet/realtek/r8169_main.c
@@ -4753,10 +4753,10 @@ static int rtl8169_close(struct net_device *dev)
cancel_work_sync(&tp->wk.work);
- phy_disconnect(tp->phydev);
-
free_irq(pci_irq_vector(pdev, 0), tp);
+ phy_disconnect(tp->phydev);
+
dma_free_coherent(&pdev->dev, R8169_RX_RING_BYTES, tp->RxDescArray,
tp->RxPhyAddr);
dma_free_coherent(&pdev->dev, R8169_TX_RING_BYTES, tp->TxDescArray,
--
2.27.0
^ permalink raw reply related [flat|nested] 140+ messages in thread* [PATCH 5.10 047/120] net: ipa: pass correct dma_handle to dma_free_coherent()
2021-02-08 14:59 [PATCH 5.10 000/120] 5.10.15-rc1 review Greg Kroah-Hartman
` (45 preceding siblings ...)
2021-02-08 15:00 ` [PATCH 5.10 046/120] r8169: fix WoL on shutdown if CONFIG_DEBUG_SHIRQ is set Greg Kroah-Hartman
@ 2021-02-08 15:00 ` Greg Kroah-Hartman
2021-02-08 15:00 ` [PATCH 5.10 048/120] ARM: dts: sun7i: a20: bananapro: Fix ethernet phy-mode Greg Kroah-Hartman
` (79 subsequent siblings)
126 siblings, 0 replies; 140+ messages in thread
From: Greg Kroah-Hartman @ 2021-02-08 15:00 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Dan Carpenter, Alex Elder,
Jakub Kicinski, Sasha Levin
From: Dan Carpenter <dan.carpenter@oracle.com>
[ Upstream commit 4ace7a6e287b7e3b33276cd9fe870c326f880480 ]
The "ring->addr = addr;" assignment is done a few lines later so we
can't use "ring->addr" yet. The correct dma_handle is "addr".
Fixes: 650d1603825d ("soc: qcom: ipa: the generic software interface")
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Reviewed-by: Alex Elder <elder@linaro.org>
Link: https://lore.kernel.org/r/YBjpTU2oejkNIULT@mwanda
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/net/ipa/gsi.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ipa/gsi.c b/drivers/net/ipa/gsi.c
index 6bfac1efe037c..4a68da7115d19 100644
--- a/drivers/net/ipa/gsi.c
+++ b/drivers/net/ipa/gsi.c
@@ -1256,7 +1256,7 @@ static int gsi_ring_alloc(struct gsi *gsi, struct gsi_ring *ring, u32 count)
/* Hardware requires a 2^n ring size, with alignment equal to size */
ring->virt = dma_alloc_coherent(dev, size, &addr, GFP_KERNEL);
if (ring->virt && addr % size) {
- dma_free_coherent(dev, size, ring->virt, ring->addr);
+ dma_free_coherent(dev, size, ring->virt, addr);
dev_err(dev, "unable to alloc 0x%zx-aligned ring buffer\n",
size);
return -EINVAL; /* Not a good error value, but distinct */
--
2.27.0
^ permalink raw reply related [flat|nested] 140+ messages in thread* [PATCH 5.10 048/120] ARM: dts: sun7i: a20: bananapro: Fix ethernet phy-mode
2021-02-08 14:59 [PATCH 5.10 000/120] 5.10.15-rc1 review Greg Kroah-Hartman
` (46 preceding siblings ...)
2021-02-08 15:00 ` [PATCH 5.10 047/120] net: ipa: pass correct dma_handle to dma_free_coherent() Greg Kroah-Hartman
@ 2021-02-08 15:00 ` Greg Kroah-Hartman
2021-02-08 15:00 ` [PATCH 5.10 049/120] nvmet-tcp: fix out-of-bounds access when receiving multiple h2cdata PDUs Greg Kroah-Hartman
` (78 subsequent siblings)
126 siblings, 0 replies; 140+ messages in thread
From: Greg Kroah-Hartman @ 2021-02-08 15:00 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Hermann Lauer, Maxime Ripard, Sasha Levin
From: Hermann Lauer <Hermann.Lauer@uni-heidelberg.de>
[ Upstream commit a900cac3750b9f0b8f5ed0503d9c6359532f644d ]
BPi Pro needs TX and RX delay for Gbit to work reliable and avoid high
packet loss rates. The realtek phy driver overrides the settings of the
pull ups for the delays, so fix this for BananaPro.
Fix the phy-mode description to correctly reflect this so that the
implementation doesn't reconfigure the delays incorrectly. This
happened with commit bbc4d71d6354 ("net: phy: realtek: fix rtl8211e
rx/tx delay config").
Fixes: 10662a33dcd9 ("ARM: dts: sun7i: Add dts file for Bananapro board")
Signed-off-by: Hermann Lauer <Hermann.Lauer@uni-heidelberg.de>
Signed-off-by: Maxime Ripard <maxime@cerno.tech>
Link: https://lore.kernel.org/r/20210128111842.GA11919@lemon.iwr.uni-heidelberg.de
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
arch/arm/boot/dts/sun7i-a20-bananapro.dts | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/sun7i-a20-bananapro.dts b/arch/arm/boot/dts/sun7i-a20-bananapro.dts
index 01ccff756996d..5740f9442705c 100644
--- a/arch/arm/boot/dts/sun7i-a20-bananapro.dts
+++ b/arch/arm/boot/dts/sun7i-a20-bananapro.dts
@@ -110,7 +110,7 @@
pinctrl-names = "default";
pinctrl-0 = <&gmac_rgmii_pins>;
phy-handle = <&phy1>;
- phy-mode = "rgmii";
+ phy-mode = "rgmii-id";
phy-supply = <®_gmac_3v3>;
status = "okay";
};
--
2.27.0
^ permalink raw reply related [flat|nested] 140+ messages in thread* [PATCH 5.10 049/120] nvmet-tcp: fix out-of-bounds access when receiving multiple h2cdata PDUs
2021-02-08 14:59 [PATCH 5.10 000/120] 5.10.15-rc1 review Greg Kroah-Hartman
` (47 preceding siblings ...)
2021-02-08 15:00 ` [PATCH 5.10 048/120] ARM: dts: sun7i: a20: bananapro: Fix ethernet phy-mode Greg Kroah-Hartman
@ 2021-02-08 15:00 ` Greg Kroah-Hartman
2021-02-08 15:00 ` [PATCH 5.10 050/120] vdpa/mlx5: Restore the hardware used index after change map Greg Kroah-Hartman
` (77 subsequent siblings)
126 siblings, 0 replies; 140+ messages in thread
From: Greg Kroah-Hartman @ 2021-02-08 15:00 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Narayan Ayalasomayajula,
Sagi Grimberg, Christoph Hellwig, Sasha Levin
From: Sagi Grimberg <sagi@grimberg.me>
[ Upstream commit cb8563f5c735a042ea2dd7df1ad55ae06d63ffeb ]
When the host sends multiple h2cdata PDUs, we keep track on
the receive progress and calculate the scatterlist index and
offsets.
The issue is that sg_offset should only be kept for the first
iov entry we map in the iovec as this is the difference between
our cursor and the sg entry offset itself.
In addition, the sg index was calculated wrong because we should
not round up when dividing the command byte offset with PAG_SIZE.
Fixes: 872d26a391da ("nvmet-tcp: add NVMe over TCP target driver")
Reported-by: Narayan Ayalasomayajula <Narayan.Ayalasomayajula@wdc.com>
Tested-by: Narayan Ayalasomayajula <Narayan.Ayalasomayajula@wdc.com>
Signed-off-by: Sagi Grimberg <sagi@grimberg.me>
Signed-off-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/nvme/target/tcp.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/nvme/target/tcp.c b/drivers/nvme/target/tcp.c
index dc1f0f6471896..aacf06f0b4312 100644
--- a/drivers/nvme/target/tcp.c
+++ b/drivers/nvme/target/tcp.c
@@ -305,7 +305,7 @@ static void nvmet_tcp_map_pdu_iovec(struct nvmet_tcp_cmd *cmd)
length = cmd->pdu_len;
cmd->nr_mapped = DIV_ROUND_UP(length, PAGE_SIZE);
offset = cmd->rbytes_done;
- cmd->sg_idx = DIV_ROUND_UP(offset, PAGE_SIZE);
+ cmd->sg_idx = offset / PAGE_SIZE;
sg_offset = offset % PAGE_SIZE;
sg = &cmd->req.sg[cmd->sg_idx];
@@ -318,6 +318,7 @@ static void nvmet_tcp_map_pdu_iovec(struct nvmet_tcp_cmd *cmd)
length -= iov_len;
sg = sg_next(sg);
iov++;
+ sg_offset = 0;
}
iov_iter_kvec(&cmd->recv_msg.msg_iter, READ, cmd->iov,
--
2.27.0
^ permalink raw reply related [flat|nested] 140+ messages in thread* [PATCH 5.10 050/120] vdpa/mlx5: Restore the hardware used index after change map
2021-02-08 14:59 [PATCH 5.10 000/120] 5.10.15-rc1 review Greg Kroah-Hartman
` (48 preceding siblings ...)
2021-02-08 15:00 ` [PATCH 5.10 049/120] nvmet-tcp: fix out-of-bounds access when receiving multiple h2cdata PDUs Greg Kroah-Hartman
@ 2021-02-08 15:00 ` Greg Kroah-Hartman
2021-02-08 15:00 ` [PATCH 5.10 051/120] memblock: do not start bottom-up allocations with kernel_end Greg Kroah-Hartman
` (76 subsequent siblings)
126 siblings, 0 replies; 140+ messages in thread
From: Greg Kroah-Hartman @ 2021-02-08 15:00 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Eli Cohen, Michael S. Tsirkin,
Jason Wang, Sasha Levin
From: Eli Cohen <elic@nvidia.com>
[ Upstream commit b35ccebe3ef76168aa2edaa35809c0232cb3578e ]
When a change of memory map occurs, the hardware resources are destroyed
and then re-created again with the new memory map. In such case, we need
to restore the hardware available and used indices. The driver failed to
restore the used index which is added here.
Also, since the driver also fails to reset the available and used
indices upon device reset, fix this here to avoid regression caused by
the fact that used index may not be zero upon device reset.
Fixes: 1a86b377aa21 ("vdpa/mlx5: Add VDPA driver for supported mlx5 devices")
Signed-off-by: Eli Cohen <elic@nvidia.com>
Link: https://lore.kernel.org/r/20210204073618.36336-1-elic@nvidia.com
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Acked-by: Jason Wang <jasowang@redhat.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/vdpa/mlx5/net/mlx5_vnet.c | 18 ++++++++++++++++++
1 file changed, 18 insertions(+)
diff --git a/drivers/vdpa/mlx5/net/mlx5_vnet.c b/drivers/vdpa/mlx5/net/mlx5_vnet.c
index 81b932f72e103..c6529f7c3034a 100644
--- a/drivers/vdpa/mlx5/net/mlx5_vnet.c
+++ b/drivers/vdpa/mlx5/net/mlx5_vnet.c
@@ -77,6 +77,7 @@ struct mlx5_vq_restore_info {
u64 device_addr;
u64 driver_addr;
u16 avail_index;
+ u16 used_index;
bool ready;
struct vdpa_callback cb;
bool restore;
@@ -111,6 +112,7 @@ struct mlx5_vdpa_virtqueue {
u32 virtq_id;
struct mlx5_vdpa_net *ndev;
u16 avail_idx;
+ u16 used_idx;
int fw_state;
/* keep last in the struct */
@@ -789,6 +791,7 @@ static int create_virtqueue(struct mlx5_vdpa_net *ndev, struct mlx5_vdpa_virtque
obj_context = MLX5_ADDR_OF(create_virtio_net_q_in, in, obj_context);
MLX5_SET(virtio_net_q_object, obj_context, hw_available_index, mvq->avail_idx);
+ MLX5_SET(virtio_net_q_object, obj_context, hw_used_index, mvq->used_idx);
MLX5_SET(virtio_net_q_object, obj_context, queue_feature_bit_mask_12_3,
get_features_12_3(ndev->mvdev.actual_features));
vq_ctx = MLX5_ADDR_OF(virtio_net_q_object, obj_context, virtio_q_context);
@@ -1007,6 +1010,7 @@ static int connect_qps(struct mlx5_vdpa_net *ndev, struct mlx5_vdpa_virtqueue *m
struct mlx5_virtq_attr {
u8 state;
u16 available_index;
+ u16 used_index;
};
static int query_virtqueue(struct mlx5_vdpa_net *ndev, struct mlx5_vdpa_virtqueue *mvq,
@@ -1037,6 +1041,7 @@ static int query_virtqueue(struct mlx5_vdpa_net *ndev, struct mlx5_vdpa_virtqueu
memset(attr, 0, sizeof(*attr));
attr->state = MLX5_GET(virtio_net_q_object, obj_context, state);
attr->available_index = MLX5_GET(virtio_net_q_object, obj_context, hw_available_index);
+ attr->used_index = MLX5_GET(virtio_net_q_object, obj_context, hw_used_index);
kfree(out);
return 0;
@@ -1520,6 +1525,16 @@ static void teardown_virtqueues(struct mlx5_vdpa_net *ndev)
}
}
+static void clear_virtqueues(struct mlx5_vdpa_net *ndev)
+{
+ int i;
+
+ for (i = ndev->mvdev.max_vqs - 1; i >= 0; i--) {
+ ndev->vqs[i].avail_idx = 0;
+ ndev->vqs[i].used_idx = 0;
+ }
+}
+
/* TODO: cross-endian support */
static inline bool mlx5_vdpa_is_little_endian(struct mlx5_vdpa_dev *mvdev)
{
@@ -1595,6 +1610,7 @@ static int save_channel_info(struct mlx5_vdpa_net *ndev, struct mlx5_vdpa_virtqu
return err;
ri->avail_index = attr.available_index;
+ ri->used_index = attr.used_index;
ri->ready = mvq->ready;
ri->num_ent = mvq->num_ent;
ri->desc_addr = mvq->desc_addr;
@@ -1639,6 +1655,7 @@ static void restore_channels_info(struct mlx5_vdpa_net *ndev)
continue;
mvq->avail_idx = ri->avail_index;
+ mvq->used_idx = ri->used_index;
mvq->ready = ri->ready;
mvq->num_ent = ri->num_ent;
mvq->desc_addr = ri->desc_addr;
@@ -1753,6 +1770,7 @@ static void mlx5_vdpa_set_status(struct vdpa_device *vdev, u8 status)
if (!status) {
mlx5_vdpa_info(mvdev, "performing device reset\n");
teardown_driver(ndev);
+ clear_virtqueues(ndev);
mlx5_vdpa_destroy_mr(&ndev->mvdev);
ndev->mvdev.status = 0;
ndev->mvdev.mlx_features = 0;
--
2.27.0
^ permalink raw reply related [flat|nested] 140+ messages in thread* [PATCH 5.10 051/120] memblock: do not start bottom-up allocations with kernel_end
2021-02-08 14:59 [PATCH 5.10 000/120] 5.10.15-rc1 review Greg Kroah-Hartman
` (49 preceding siblings ...)
2021-02-08 15:00 ` [PATCH 5.10 050/120] vdpa/mlx5: Restore the hardware used index after change map Greg Kroah-Hartman
@ 2021-02-08 15:00 ` Greg Kroah-Hartman
2021-02-09 15:07 ` Thiago Jung Bauermann
2021-02-08 15:00 ` [PATCH 5.10 052/120] kbuild: fix duplicated flags in DEBUG_CFLAGS Greg Kroah-Hartman
` (75 subsequent siblings)
126 siblings, 1 reply; 140+ messages in thread
From: Greg Kroah-Hartman @ 2021-02-08 15:00 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Roman Gushchin, Mike Rapoport,
Joonsoo Kim, Michal Hocko, Rik van Riel, Wonhyuk Yang,
Thiago Jung Bauermann, Andrew Morton, Linus Torvalds,
Sasha Levin
From: Roman Gushchin <guro@fb.com>
[ Upstream commit 2dcb3964544177c51853a210b6ad400de78ef17d ]
With kaslr the kernel image is placed at a random place, so starting the
bottom-up allocation with the kernel_end can result in an allocation
failure and a warning like this one:
hugetlb_cma: reserve 2048 MiB, up to 2048 MiB per node
------------[ cut here ]------------
memblock: bottom-up allocation failed, memory hotremove may be affected
WARNING: CPU: 0 PID: 0 at mm/memblock.c:332 memblock_find_in_range_node+0x178/0x25a
Modules linked in:
CPU: 0 PID: 0 Comm: swapper Not tainted 5.10.0+ #1169
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.14.0-1.fc33 04/01/2014
RIP: 0010:memblock_find_in_range_node+0x178/0x25a
Code: e9 6d ff ff ff 48 85 c0 0f 85 da 00 00 00 80 3d 9b 35 df 00 00 75 15 48 c7 c7 c0 75 59 88 c6 05 8b 35 df 00 01 e8 25 8a fa ff <0f> 0b 48 c7 44 24 20 ff ff ff ff 44 89 e6 44 89 ea 48 c7 c1 70 5c
RSP: 0000:ffffffff88803d18 EFLAGS: 00010086 ORIG_RAX: 0000000000000000
RAX: 0000000000000000 RBX: 0000000240000000 RCX: 00000000ffffdfff
RDX: 00000000ffffdfff RSI: 00000000ffffffea RDI: 0000000000000046
RBP: 0000000100000000 R08: ffffffff88922788 R09: 0000000000009ffb
R10: 00000000ffffe000 R11: 3fffffffffffffff R12: 0000000000000000
R13: 0000000000000000 R14: 0000000080000000 R15: 00000001fb42c000
FS: 0000000000000000(0000) GS:ffffffff88f71000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: ffffa080fb401000 CR3: 00000001fa80a000 CR4: 00000000000406b0
Call Trace:
memblock_alloc_range_nid+0x8d/0x11e
cma_declare_contiguous_nid+0x2c4/0x38c
hugetlb_cma_reserve+0xdc/0x128
flush_tlb_one_kernel+0xc/0x20
native_set_fixmap+0x82/0xd0
flat_get_apic_id+0x5/0x10
register_lapic_address+0x8e/0x97
setup_arch+0x8a5/0xc3f
start_kernel+0x66/0x547
load_ucode_bsp+0x4c/0xcd
secondary_startup_64_no_verify+0xb0/0xbb
random: get_random_bytes called from __warn+0xab/0x110 with crng_init=0
---[ end trace f151227d0b39be70 ]---
At the same time, the kernel image is protected with memblock_reserve(),
so we can just start searching at PAGE_SIZE. In this case the bottom-up
allocation has the same chances to success as a top-down allocation, so
there is no reason to fallback in the case of a failure. All together it
simplifies the logic.
Link: https://lkml.kernel.org/r/20201217201214.3414100-2-guro@fb.com
Fixes: 8fabc623238e ("powerpc: Ensure that swiotlb buffer is allocated from low memory")
Signed-off-by: Roman Gushchin <guro@fb.com>
Reviewed-by: Mike Rapoport <rppt@linux.ibm.com>
Cc: Joonsoo Kim <iamjoonsoo.kim@lge.com>
Cc: Michal Hocko <mhocko@kernel.org>
Cc: Rik van Riel <riel@surriel.com>
Cc: Wonhyuk Yang <vvghjk1234@gmail.com>
Cc: Thiago Jung Bauermann <bauerman@linux.ibm.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
mm/memblock.c | 49 ++++++-------------------------------------------
1 file changed, 6 insertions(+), 43 deletions(-)
diff --git a/mm/memblock.c b/mm/memblock.c
index b68ee86788af9..10bd7d1ef0f49 100644
--- a/mm/memblock.c
+++ b/mm/memblock.c
@@ -275,14 +275,6 @@ __memblock_find_range_top_down(phys_addr_t start, phys_addr_t end,
*
* Find @size free area aligned to @align in the specified range and node.
*
- * When allocation direction is bottom-up, the @start should be greater
- * than the end of the kernel image. Otherwise, it will be trimmed. The
- * reason is that we want the bottom-up allocation just near the kernel
- * image so it is highly likely that the allocated memory and the kernel
- * will reside in the same node.
- *
- * If bottom-up allocation failed, will try to allocate memory top-down.
- *
* Return:
* Found address on success, 0 on failure.
*/
@@ -291,8 +283,6 @@ static phys_addr_t __init_memblock memblock_find_in_range_node(phys_addr_t size,
phys_addr_t end, int nid,
enum memblock_flags flags)
{
- phys_addr_t kernel_end, ret;
-
/* pump up @end */
if (end == MEMBLOCK_ALLOC_ACCESSIBLE ||
end == MEMBLOCK_ALLOC_KASAN)
@@ -301,40 +291,13 @@ static phys_addr_t __init_memblock memblock_find_in_range_node(phys_addr_t size,
/* avoid allocating the first page */
start = max_t(phys_addr_t, start, PAGE_SIZE);
end = max(start, end);
- kernel_end = __pa_symbol(_end);
-
- /*
- * try bottom-up allocation only when bottom-up mode
- * is set and @end is above the kernel image.
- */
- if (memblock_bottom_up() && end > kernel_end) {
- phys_addr_t bottom_up_start;
-
- /* make sure we will allocate above the kernel */
- bottom_up_start = max(start, kernel_end);
- /* ok, try bottom-up allocation first */
- ret = __memblock_find_range_bottom_up(bottom_up_start, end,
- size, align, nid, flags);
- if (ret)
- return ret;
-
- /*
- * we always limit bottom-up allocation above the kernel,
- * but top-down allocation doesn't have the limit, so
- * retrying top-down allocation may succeed when bottom-up
- * allocation failed.
- *
- * bottom-up allocation is expected to be fail very rarely,
- * so we use WARN_ONCE() here to see the stack trace if
- * fail happens.
- */
- WARN_ONCE(IS_ENABLED(CONFIG_MEMORY_HOTREMOVE),
- "memblock: bottom-up allocation failed, memory hotremove may be affected\n");
- }
-
- return __memblock_find_range_top_down(start, end, size, align, nid,
- flags);
+ if (memblock_bottom_up())
+ return __memblock_find_range_bottom_up(start, end, size, align,
+ nid, flags);
+ else
+ return __memblock_find_range_top_down(start, end, size, align,
+ nid, flags);
}
/**
--
2.27.0
^ permalink raw reply related [flat|nested] 140+ messages in thread* Re: [PATCH 5.10 051/120] memblock: do not start bottom-up allocations with kernel_end
2021-02-08 15:00 ` [PATCH 5.10 051/120] memblock: do not start bottom-up allocations with kernel_end Greg Kroah-Hartman
@ 2021-02-09 15:07 ` Thiago Jung Bauermann
2021-02-09 19:10 ` Greg Kroah-Hartman
0 siblings, 1 reply; 140+ messages in thread
From: Thiago Jung Bauermann @ 2021-02-09 15:07 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: linux-kernel, stable, Roman Gushchin, Mike Rapoport, Joonsoo Kim,
Michal Hocko, Rik van Riel, Wonhyuk Yang, Andrew Morton,
Linus Torvalds, Sasha Levin
Greg Kroah-Hartman <gregkh@linuxfoundation.org> writes:
> From: Roman Gushchin <guro@fb.com>
>
> [ Upstream commit 2dcb3964544177c51853a210b6ad400de78ef17d ]
>
> With kaslr the kernel image is placed at a random place, so starting the
> bottom-up allocation with the kernel_end can result in an allocation
> failure and a warning like this one:
Not sure if this is ready for stable yet (including stable branches 4.19
and 5.4), since it seems to uncover latent bugs in x86 early memory
reservation. I asked about this issue here:
https://lore.kernel.org/lkml/87ft26yuwg.fsf@manicouagan.localdomain/
--
Thiago Jung Bauermann
IBM Linux Technology Center
^ permalink raw reply [flat|nested] 140+ messages in thread
* Re: [PATCH 5.10 051/120] memblock: do not start bottom-up allocations with kernel_end
2021-02-09 15:07 ` Thiago Jung Bauermann
@ 2021-02-09 19:10 ` Greg Kroah-Hartman
0 siblings, 0 replies; 140+ messages in thread
From: Greg Kroah-Hartman @ 2021-02-09 19:10 UTC (permalink / raw)
To: Thiago Jung Bauermann
Cc: linux-kernel, stable, Roman Gushchin, Mike Rapoport, Joonsoo Kim,
Michal Hocko, Rik van Riel, Wonhyuk Yang, Andrew Morton,
Linus Torvalds, Sasha Levin
On Tue, Feb 09, 2021 at 12:07:57PM -0300, Thiago Jung Bauermann wrote:
>
> Greg Kroah-Hartman <gregkh@linuxfoundation.org> writes:
>
> > From: Roman Gushchin <guro@fb.com>
> >
> > [ Upstream commit 2dcb3964544177c51853a210b6ad400de78ef17d ]
> >
> > With kaslr the kernel image is placed at a random place, so starting the
> > bottom-up allocation with the kernel_end can result in an allocation
> > failure and a warning like this one:
>
> Not sure if this is ready for stable yet (including stable branches 4.19
> and 5.4), since it seems to uncover latent bugs in x86 early memory
> reservation. I asked about this issue here:
>
> https://lore.kernel.org/lkml/87ft26yuwg.fsf@manicouagan.localdomain/
If there are fixes for this that get merged, please make sure they get
tagged properly to go to the stable trees as well.
thanks,
greg k-h
^ permalink raw reply [flat|nested] 140+ messages in thread
* [PATCH 5.10 052/120] kbuild: fix duplicated flags in DEBUG_CFLAGS
2021-02-08 14:59 [PATCH 5.10 000/120] 5.10.15-rc1 review Greg Kroah-Hartman
` (50 preceding siblings ...)
2021-02-08 15:00 ` [PATCH 5.10 051/120] memblock: do not start bottom-up allocations with kernel_end Greg Kroah-Hartman
@ 2021-02-08 15:00 ` Greg Kroah-Hartman
2021-02-08 15:00 ` [PATCH 5.10 053/120] thunderbolt: Fix possible NULL pointer dereference in tb_acpi_add_link() Greg Kroah-Hartman
` (74 subsequent siblings)
126 siblings, 0 replies; 140+ messages in thread
From: Greg Kroah-Hartman @ 2021-02-08 15:00 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Sedat Dilek, Masahiro Yamada,
Mark Wielaard, Nathan Chancellor, Sasha Levin
From: Masahiro Yamada <masahiroy@kernel.org>
[ Upstream commit 315da87c0f99a4741a639782d59dae44878199f5 ]
Sedat Dilek noticed duplicated flags in DEBUG_CFLAGS when building
deb-pkg with CONFIG_DEBUG_INFO. For example, 'make CC=clang bindeb-pkg'
reproduces the issue.
Kbuild recurses to the top Makefile for some targets such as package
builds.
With commit 121c5d08d53c ("kbuild: Only add -fno-var-tracking-assignments
for old GCC versions") applied, DEBUG_CFLAGS is now reset only when
CONFIG_CC_IS_GCC=y.
Fix it to reset DEBUG_CFLAGS all the time.
Fixes: 121c5d08d53c ("kbuild: Only add -fno-var-tracking-assignments for old GCC versions")
Reported-by: Sedat Dilek <sedat.dilek@gmail.com>
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Tested-by: Sedat Dilek <sedat.dilek@gmail.com>
Reviewed-by: Mark Wielaard <mark@klomp.org>
Reviewed-by: Nathan Chancellor <nathan@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
Makefile | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/Makefile b/Makefile
index bb3770be9779d..535696d39f452 100644
--- a/Makefile
+++ b/Makefile
@@ -812,10 +812,12 @@ KBUILD_CFLAGS += -ftrivial-auto-var-init=zero
KBUILD_CFLAGS += -enable-trivial-auto-var-init-zero-knowing-it-will-be-removed-from-clang
endif
+DEBUG_CFLAGS :=
+
# Workaround for GCC versions < 5.0
# https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61801
ifdef CONFIG_CC_IS_GCC
-DEBUG_CFLAGS := $(call cc-ifversion, -lt, 0500, $(call cc-option, -fno-var-tracking-assignments))
+DEBUG_CFLAGS += $(call cc-ifversion, -lt, 0500, $(call cc-option, -fno-var-tracking-assignments))
endif
ifdef CONFIG_DEBUG_INFO
--
2.27.0
^ permalink raw reply related [flat|nested] 140+ messages in thread* [PATCH 5.10 053/120] thunderbolt: Fix possible NULL pointer dereference in tb_acpi_add_link()
2021-02-08 14:59 [PATCH 5.10 000/120] 5.10.15-rc1 review Greg Kroah-Hartman
` (51 preceding siblings ...)
2021-02-08 15:00 ` [PATCH 5.10 052/120] kbuild: fix duplicated flags in DEBUG_CFLAGS Greg Kroah-Hartman
@ 2021-02-08 15:00 ` Greg Kroah-Hartman
2021-02-08 15:00 ` [PATCH 5.10 054/120] ovl: fix dentry leak in ovl_get_redirect Greg Kroah-Hartman
` (73 subsequent siblings)
126 siblings, 0 replies; 140+ messages in thread
From: Greg Kroah-Hartman @ 2021-02-08 15:00 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Mario Limonciello, Yehezkel Bernat,
Mika Westerberg
From: Mario Limonciello <mario.limonciello@dell.com>
commit 4d395c5e74398f664405819330e5a298da37f655 upstream.
When we walk up the device hierarchy in tb_acpi_add_link() make sure we
break the loop if the device has no parent. Otherwise we may crash the
kernel by dereferencing a NULL pointer.
Fixes: b2be2b05cf3b ("thunderbolt: Create device links from ACPI description")
Cc: stable@vger.kernel.org
Signed-off-by: Mario Limonciello <mario.limonciello@dell.com>
Acked-by: Yehezkel Bernat <YehezkelShB@gmail.com>
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/thunderbolt/acpi.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/thunderbolt/acpi.c
+++ b/drivers/thunderbolt/acpi.c
@@ -56,7 +56,7 @@ static acpi_status tb_acpi_add_link(acpi
* managed with the xHCI and the SuperSpeed hub so we create the
* link from xHCI instead.
*/
- while (!dev_is_pci(dev))
+ while (dev && !dev_is_pci(dev))
dev = dev->parent;
if (!dev)
^ permalink raw reply [flat|nested] 140+ messages in thread* [PATCH 5.10 054/120] ovl: fix dentry leak in ovl_get_redirect
2021-02-08 14:59 [PATCH 5.10 000/120] 5.10.15-rc1 review Greg Kroah-Hartman
` (52 preceding siblings ...)
2021-02-08 15:00 ` [PATCH 5.10 053/120] thunderbolt: Fix possible NULL pointer dereference in tb_acpi_add_link() Greg Kroah-Hartman
@ 2021-02-08 15:00 ` Greg Kroah-Hartman
2021-02-08 15:00 ` [PATCH 5.10 055/120] ovl: avoid deadlock on directory ioctl Greg Kroah-Hartman
` (72 subsequent siblings)
126 siblings, 0 replies; 140+ messages in thread
From: Greg Kroah-Hartman @ 2021-02-08 15:00 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Liangyan, Joseph Qi, Al Viro, Miklos Szeredi
From: Liangyan <liangyan.peng@linux.alibaba.com>
commit e04527fefba6e4e66492f122cf8cc6314f3cf3bf upstream.
We need to lock d_parent->d_lock before dget_dlock, or this may
have d_lockref updated parallelly like calltrace below which will
cause dentry->d_lockref leak and risk a crash.
CPU 0 CPU 1
ovl_set_redirect lookup_fast
ovl_get_redirect __d_lookup
dget_dlock
//no lock protection here spin_lock(&dentry->d_lock)
dentry->d_lockref.count++ dentry->d_lockref.count++
[ 49.799059] PGD 800000061fed7067 P4D 800000061fed7067 PUD 61fec5067 PMD 0
[ 49.799689] Oops: 0002 [#1] SMP PTI
[ 49.800019] CPU: 2 PID: 2332 Comm: node Not tainted 4.19.24-7.20.al7.x86_64 #1
[ 49.800678] Hardware name: Alibaba Cloud Alibaba Cloud ECS, BIOS 8a46cfe 04/01/2014
[ 49.801380] RIP: 0010:_raw_spin_lock+0xc/0x20
[ 49.803470] RSP: 0018:ffffac6fc5417e98 EFLAGS: 00010246
[ 49.803949] RAX: 0000000000000000 RBX: ffff93b8da3446c0 RCX: 0000000a00000000
[ 49.804600] RDX: 0000000000000001 RSI: 000000000000000a RDI: 0000000000000088
[ 49.805252] RBP: 0000000000000000 R08: 0000000000000000 R09: ffffffff993cf040
[ 49.805898] R10: ffff93b92292e580 R11: ffffd27f188a4b80 R12: 0000000000000000
[ 49.806548] R13: 00000000ffffff9c R14: 00000000fffffffe R15: ffff93b8da3446c0
[ 49.807200] FS: 00007ffbedffb700(0000) GS:ffff93b927880000(0000) knlGS:0000000000000000
[ 49.807935] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 49.808461] CR2: 0000000000000088 CR3: 00000005e3f74006 CR4: 00000000003606a0
[ 49.809113] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[ 49.809758] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
[ 49.810410] Call Trace:
[ 49.810653] d_delete+0x2c/0xb0
[ 49.810951] vfs_rmdir+0xfd/0x120
[ 49.811264] do_rmdir+0x14f/0x1a0
[ 49.811573] do_syscall_64+0x5b/0x190
[ 49.811917] entry_SYSCALL_64_after_hwframe+0x44/0xa9
[ 49.812385] RIP: 0033:0x7ffbf505ffd7
[ 49.814404] RSP: 002b:00007ffbedffada8 EFLAGS: 00000297 ORIG_RAX: 0000000000000054
[ 49.815098] RAX: ffffffffffffffda RBX: 00007ffbedffb640 RCX: 00007ffbf505ffd7
[ 49.815744] RDX: 0000000004449700 RSI: 0000000000000000 RDI: 0000000006c8cd50
[ 49.816394] RBP: 00007ffbedffaea0 R08: 0000000000000000 R09: 0000000000017d0b
[ 49.817038] R10: 0000000000000000 R11: 0000000000000297 R12: 0000000000000012
[ 49.817687] R13: 00000000072823d8 R14: 00007ffbedffb700 R15: 00000000072823d8
[ 49.818338] Modules linked in: pvpanic cirrusfb button qemu_fw_cfg atkbd libps2 i8042
[ 49.819052] CR2: 0000000000000088
[ 49.819368] ---[ end trace 4e652b8aa299aa2d ]---
[ 49.819796] RIP: 0010:_raw_spin_lock+0xc/0x20
[ 49.821880] RSP: 0018:ffffac6fc5417e98 EFLAGS: 00010246
[ 49.822363] RAX: 0000000000000000 RBX: ffff93b8da3446c0 RCX: 0000000a00000000
[ 49.823008] RDX: 0000000000000001 RSI: 000000000000000a RDI: 0000000000000088
[ 49.823658] RBP: 0000000000000000 R08: 0000000000000000 R09: ffffffff993cf040
[ 49.825404] R10: ffff93b92292e580 R11: ffffd27f188a4b80 R12: 0000000000000000
[ 49.827147] R13: 00000000ffffff9c R14: 00000000fffffffe R15: ffff93b8da3446c0
[ 49.828890] FS: 00007ffbedffb700(0000) GS:ffff93b927880000(0000) knlGS:0000000000000000
[ 49.830725] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 49.832359] CR2: 0000000000000088 CR3: 00000005e3f74006 CR4: 00000000003606a0
[ 49.834085] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[ 49.835792] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
Cc: <stable@vger.kernel.org>
Fixes: a6c606551141 ("ovl: redirect on rename-dir")
Signed-off-by: Liangyan <liangyan.peng@linux.alibaba.com>
Reviewed-by: Joseph Qi <joseph.qi@linux.alibaba.com>
Suggested-by: Al Viro <viro@zeniv.linux.org.uk>
Signed-off-by: Miklos Szeredi <mszeredi@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
fs/overlayfs/dir.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/fs/overlayfs/dir.c
+++ b/fs/overlayfs/dir.c
@@ -992,8 +992,8 @@ static char *ovl_get_redirect(struct den
buflen -= thislen;
memcpy(&buf[buflen], name, thislen);
- tmp = dget_dlock(d->d_parent);
spin_unlock(&d->d_lock);
+ tmp = dget_parent(d);
dput(d);
d = tmp;
^ permalink raw reply [flat|nested] 140+ messages in thread* [PATCH 5.10 055/120] ovl: avoid deadlock on directory ioctl
2021-02-08 14:59 [PATCH 5.10 000/120] 5.10.15-rc1 review Greg Kroah-Hartman
` (53 preceding siblings ...)
2021-02-08 15:00 ` [PATCH 5.10 054/120] ovl: fix dentry leak in ovl_get_redirect Greg Kroah-Hartman
@ 2021-02-08 15:00 ` Greg Kroah-Hartman
2021-02-08 15:00 ` [PATCH 5.10 056/120] ovl: implement volatile-specific fsync error behaviour Greg Kroah-Hartman
` (71 subsequent siblings)
126 siblings, 0 replies; 140+ messages in thread
From: Greg Kroah-Hartman @ 2021-02-08 15:00 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, Icenowy Zheng, Miklos Szeredi
From: Miklos Szeredi <mszeredi@redhat.com>
commit b854cc659dcb80f172cb35dbedc15d39d49c383f upstream.
The function ovl_dir_real_file() currently uses the inode lock to serialize
writes to the od->upperfile field.
However, this function will get called by ovl_ioctl_set_flags(), which
utilizes the inode lock too. In this case ovl_dir_real_file() will try to
claim a lock that is owned by a function in its call stack, which won't get
released before ovl_dir_real_file() returns.
Fix by replacing the open coded compare and exchange by an explicit atomic
op.
Fixes: 61536bed2149 ("ovl: support [S|G]ETFLAGS and FS[S|G]ETXATTR ioctls for directories")
Cc: stable@vger.kernel.org # v5.10
Reported-by: Icenowy Zheng <icenowy@aosc.io>
Tested-by: Icenowy Zheng <icenowy@aosc.io>
Signed-off-by: Miklos Szeredi <mszeredi@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
fs/overlayfs/readdir.c | 23 +++++++----------------
1 file changed, 7 insertions(+), 16 deletions(-)
--- a/fs/overlayfs/readdir.c
+++ b/fs/overlayfs/readdir.c
@@ -865,7 +865,7 @@ struct file *ovl_dir_real_file(const str
struct ovl_dir_file *od = file->private_data;
struct dentry *dentry = file->f_path.dentry;
- struct file *realfile = od->realfile;
+ struct file *old, *realfile = od->realfile;
if (!OVL_TYPE_UPPER(ovl_path_type(dentry)))
return want_upper ? NULL : realfile;
@@ -874,29 +874,20 @@ struct file *ovl_dir_real_file(const str
* Need to check if we started out being a lower dir, but got copied up
*/
if (!od->is_upper) {
- struct inode *inode = file_inode(file);
-
realfile = READ_ONCE(od->upperfile);
if (!realfile) {
struct path upperpath;
ovl_path_upper(dentry, &upperpath);
realfile = ovl_dir_open_realfile(file, &upperpath);
+ if (IS_ERR(realfile))
+ return realfile;
- inode_lock(inode);
- if (!od->upperfile) {
- if (IS_ERR(realfile)) {
- inode_unlock(inode);
- return realfile;
- }
- smp_store_release(&od->upperfile, realfile);
- } else {
- /* somebody has beaten us to it */
- if (!IS_ERR(realfile))
- fput(realfile);
- realfile = od->upperfile;
+ old = cmpxchg_release(&od->upperfile, NULL, realfile);
+ if (old) {
+ fput(realfile);
+ realfile = old;
}
- inode_unlock(inode);
}
}
^ permalink raw reply [flat|nested] 140+ messages in thread* [PATCH 5.10 056/120] ovl: implement volatile-specific fsync error behaviour
2021-02-08 14:59 [PATCH 5.10 000/120] 5.10.15-rc1 review Greg Kroah-Hartman
` (54 preceding siblings ...)
2021-02-08 15:00 ` [PATCH 5.10 055/120] ovl: avoid deadlock on directory ioctl Greg Kroah-Hartman
@ 2021-02-08 15:00 ` Greg Kroah-Hartman
2021-02-08 15:00 ` [PATCH 5.10 057/120] mac80211: fix station rate table updates on assoc Greg Kroah-Hartman
` (70 subsequent siblings)
126 siblings, 0 replies; 140+ messages in thread
From: Greg Kroah-Hartman @ 2021-02-08 15:00 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Sargun Dhillon, Amir Goldstein,
Vivek Goyal, Jeff Layton, Miklos Szeredi
From: Sargun Dhillon <sargun@sargun.me>
commit 335d3fc57941e5c6164c69d439aec1cb7a800876 upstream.
Overlayfs's volatile option allows the user to bypass all forced sync calls
to the upperdir filesystem. This comes at the cost of safety. We can never
ensure that the user's data is intact, but we can make a best effort to
expose whether or not the data is likely to be in a bad state.
The best way to handle this in the time being is that if an overlayfs's
upperdir experiences an error after a volatile mount occurs, that error
will be returned on fsync, fdatasync, sync, and syncfs. This is
contradictory to the traditional behaviour of VFS which fails the call
once, and only raises an error if a subsequent fsync error has occurred,
and been raised by the filesystem.
One awkward aspect of the patch is that we have to manually set the
superblock's errseq_t after the sync_fs callback as opposed to just
returning an error from syncfs. This is because the call chain looks
something like this:
sys_syncfs ->
sync_filesystem ->
__sync_filesystem ->
/* The return value is ignored here
sb->s_op->sync_fs(sb)
_sync_blockdev
/* Where the VFS fetches the error to raise to userspace */
errseq_check_and_advance
Because of this we call errseq_set every time the sync_fs callback occurs.
Due to the nature of this seen / unseen dichotomy, if the upperdir is an
inconsistent state at the initial mount time, overlayfs will refuse to
mount, as overlayfs cannot get a snapshot of the upperdir's errseq that
will increment on error until the user calls syncfs.
Signed-off-by: Sargun Dhillon <sargun@sargun.me>
Suggested-by: Amir Goldstein <amir73il@gmail.com>
Reviewed-by: Amir Goldstein <amir73il@gmail.com>
Fixes: c86243b090bc ("ovl: provide a mount option "volatile"")
Cc: stable@vger.kernel.org
Reviewed-by: Vivek Goyal <vgoyal@redhat.com>
Reviewed-by: Jeff Layton <jlayton@kernel.org>
Signed-off-by: Miklos Szeredi <mszeredi@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
Documentation/filesystems/overlayfs.rst | 8 +++++++
fs/overlayfs/file.c | 5 ++--
fs/overlayfs/overlayfs.h | 1
fs/overlayfs/ovl_entry.h | 2 +
fs/overlayfs/readdir.c | 5 ++--
fs/overlayfs/super.c | 34 +++++++++++++++++++++++++-------
fs/overlayfs/util.c | 27 +++++++++++++++++++++++++
7 files changed, 71 insertions(+), 11 deletions(-)
--- a/Documentation/filesystems/overlayfs.rst
+++ b/Documentation/filesystems/overlayfs.rst
@@ -575,6 +575,14 @@ without significant effort.
The advantage of mounting with the "volatile" option is that all forms of
sync calls to the upper filesystem are omitted.
+In order to avoid a giving a false sense of safety, the syncfs (and fsync)
+semantics of volatile mounts are slightly different than that of the rest of
+VFS. If any writeback error occurs on the upperdir's filesystem after a
+volatile mount takes place, all sync functions will return an error. Once this
+condition is reached, the filesystem will not recover, and every subsequent sync
+call will return an error, even if the upperdir has not experience a new error
+since the last sync call.
+
When overlay is mounted with "volatile" option, the directory
"$workdir/work/incompat/volatile" is created. During next mount, overlay
checks for this directory and refuses to mount if present. This is a strong
--- a/fs/overlayfs/file.c
+++ b/fs/overlayfs/file.c
@@ -445,8 +445,9 @@ static int ovl_fsync(struct file *file,
const struct cred *old_cred;
int ret;
- if (!ovl_should_sync(OVL_FS(file_inode(file)->i_sb)))
- return 0;
+ ret = ovl_sync_status(OVL_FS(file_inode(file)->i_sb));
+ if (ret <= 0)
+ return ret;
ret = ovl_real_fdget_meta(file, &real, !datasync);
if (ret)
--- a/fs/overlayfs/overlayfs.h
+++ b/fs/overlayfs/overlayfs.h
@@ -322,6 +322,7 @@ int ovl_check_metacopy_xattr(struct ovl_
bool ovl_is_metacopy_dentry(struct dentry *dentry);
char *ovl_get_redirect_xattr(struct ovl_fs *ofs, struct dentry *dentry,
int padding);
+int ovl_sync_status(struct ovl_fs *ofs);
static inline bool ovl_is_impuredir(struct super_block *sb,
struct dentry *dentry)
--- a/fs/overlayfs/ovl_entry.h
+++ b/fs/overlayfs/ovl_entry.h
@@ -79,6 +79,8 @@ struct ovl_fs {
atomic_long_t last_ino;
/* Whiteout dentry cache */
struct dentry *whiteout;
+ /* r/o snapshot of upperdir sb's only taken on volatile mounts */
+ errseq_t errseq;
};
static inline struct vfsmount *ovl_upper_mnt(struct ovl_fs *ofs)
--- a/fs/overlayfs/readdir.c
+++ b/fs/overlayfs/readdir.c
@@ -900,8 +900,9 @@ static int ovl_dir_fsync(struct file *fi
struct file *realfile;
int err;
- if (!ovl_should_sync(OVL_FS(file->f_path.dentry->d_sb)))
- return 0;
+ err = ovl_sync_status(OVL_FS(file->f_path.dentry->d_sb));
+ if (err <= 0)
+ return err;
realfile = ovl_dir_real_file(file, true);
err = PTR_ERR_OR_ZERO(realfile);
--- a/fs/overlayfs/super.c
+++ b/fs/overlayfs/super.c
@@ -261,11 +261,20 @@ static int ovl_sync_fs(struct super_bloc
struct super_block *upper_sb;
int ret;
- if (!ovl_upper_mnt(ofs))
- return 0;
+ ret = ovl_sync_status(ofs);
+ /*
+ * We have to always set the err, because the return value isn't
+ * checked in syncfs, and instead indirectly return an error via
+ * the sb's writeback errseq, which VFS inspects after this call.
+ */
+ if (ret < 0) {
+ errseq_set(&sb->s_wb_err, -EIO);
+ return -EIO;
+ }
+
+ if (!ret)
+ return ret;
- if (!ovl_should_sync(ofs))
- return 0;
/*
* Not called for sync(2) call or an emergency sync (SB_I_SKIP_SYNC).
* All the super blocks will be iterated, including upper_sb.
@@ -1927,6 +1936,8 @@ static int ovl_fill_super(struct super_b
sb->s_op = &ovl_super_operations;
if (ofs->config.upperdir) {
+ struct super_block *upper_sb;
+
if (!ofs->config.workdir) {
pr_err("missing 'workdir'\n");
goto out_err;
@@ -1936,6 +1947,16 @@ static int ovl_fill_super(struct super_b
if (err)
goto out_err;
+ upper_sb = ovl_upper_mnt(ofs)->mnt_sb;
+ if (!ovl_should_sync(ofs)) {
+ ofs->errseq = errseq_sample(&upper_sb->s_wb_err);
+ if (errseq_check(&upper_sb->s_wb_err, ofs->errseq)) {
+ err = -EIO;
+ pr_err("Cannot mount volatile when upperdir has an unseen error. Sync upperdir fs to clear state.\n");
+ goto out_err;
+ }
+ }
+
err = ovl_get_workdir(sb, ofs, &upperpath);
if (err)
goto out_err;
@@ -1943,9 +1964,8 @@ static int ovl_fill_super(struct super_b
if (!ofs->workdir)
sb->s_flags |= SB_RDONLY;
- sb->s_stack_depth = ovl_upper_mnt(ofs)->mnt_sb->s_stack_depth;
- sb->s_time_gran = ovl_upper_mnt(ofs)->mnt_sb->s_time_gran;
-
+ sb->s_stack_depth = upper_sb->s_stack_depth;
+ sb->s_time_gran = upper_sb->s_time_gran;
}
oe = ovl_get_lowerstack(sb, splitlower, numlower, ofs, layers);
err = PTR_ERR(oe);
--- a/fs/overlayfs/util.c
+++ b/fs/overlayfs/util.c
@@ -950,3 +950,30 @@ err_free:
kfree(buf);
return ERR_PTR(res);
}
+
+/*
+ * ovl_sync_status() - Check fs sync status for volatile mounts
+ *
+ * Returns 1 if this is not a volatile mount and a real sync is required.
+ *
+ * Returns 0 if syncing can be skipped because mount is volatile, and no errors
+ * have occurred on the upperdir since the mount.
+ *
+ * Returns -errno if it is a volatile mount, and the error that occurred since
+ * the last mount. If the error code changes, it'll return the latest error
+ * code.
+ */
+
+int ovl_sync_status(struct ovl_fs *ofs)
+{
+ struct vfsmount *mnt;
+
+ if (ovl_should_sync(ofs))
+ return 1;
+
+ mnt = ovl_upper_mnt(ofs);
+ if (!mnt)
+ return 0;
+
+ return errseq_check(&mnt->mnt_sb->s_wb_err, ofs->errseq);
+}
^ permalink raw reply [flat|nested] 140+ messages in thread* [PATCH 5.10 057/120] mac80211: fix station rate table updates on assoc
2021-02-08 14:59 [PATCH 5.10 000/120] 5.10.15-rc1 review Greg Kroah-Hartman
` (55 preceding siblings ...)
2021-02-08 15:00 ` [PATCH 5.10 056/120] ovl: implement volatile-specific fsync error behaviour Greg Kroah-Hartman
@ 2021-02-08 15:00 ` Greg Kroah-Hartman
2021-02-08 15:00 ` [PATCH 5.10 058/120] gpiolib: free device name on error path to fix kmemleak Greg Kroah-Hartman
` (69 subsequent siblings)
126 siblings, 0 replies; 140+ messages in thread
From: Greg Kroah-Hartman @ 2021-02-08 15:00 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, Felix Fietkau, Johannes Berg
From: Felix Fietkau <nbd@nbd.name>
commit 18fe0fae61252b5ae6e26553e2676b5fac555951 upstream.
If the driver uses .sta_add, station entries are only uploaded after the sta
is in assoc state. Fix early station rate table updates by deferring them
until the sta has been uploaded.
Cc: stable@vger.kernel.org
Signed-off-by: Felix Fietkau <nbd@nbd.name>
Link: https://lore.kernel.org/r/20210201083324.3134-1-nbd@nbd.name
[use rcu_access_pointer() instead since we won't dereference here]
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
net/mac80211/driver-ops.c | 5 ++++-
net/mac80211/rate.c | 3 ++-
2 files changed, 6 insertions(+), 2 deletions(-)
--- a/net/mac80211/driver-ops.c
+++ b/net/mac80211/driver-ops.c
@@ -125,8 +125,11 @@ int drv_sta_state(struct ieee80211_local
} else if (old_state == IEEE80211_STA_AUTH &&
new_state == IEEE80211_STA_ASSOC) {
ret = drv_sta_add(local, sdata, &sta->sta);
- if (ret == 0)
+ if (ret == 0) {
sta->uploaded = true;
+ if (rcu_access_pointer(sta->sta.rates))
+ drv_sta_rate_tbl_update(local, sdata, &sta->sta);
+ }
} else if (old_state == IEEE80211_STA_ASSOC &&
new_state == IEEE80211_STA_AUTH) {
drv_sta_remove(local, sdata, &sta->sta);
--- a/net/mac80211/rate.c
+++ b/net/mac80211/rate.c
@@ -960,7 +960,8 @@ int rate_control_set_rates(struct ieee80
if (old)
kfree_rcu(old, rcu_head);
- drv_sta_rate_tbl_update(hw_to_local(hw), sta->sdata, pubsta);
+ if (sta->uploaded)
+ drv_sta_rate_tbl_update(hw_to_local(hw), sta->sdata, pubsta);
ieee80211_sta_set_expected_throughput(pubsta, sta_get_expected_throughput(sta));
^ permalink raw reply [flat|nested] 140+ messages in thread* [PATCH 5.10 058/120] gpiolib: free device name on error path to fix kmemleak
2021-02-08 14:59 [PATCH 5.10 000/120] 5.10.15-rc1 review Greg Kroah-Hartman
` (56 preceding siblings ...)
2021-02-08 15:00 ` [PATCH 5.10 057/120] mac80211: fix station rate table updates on assoc Greg Kroah-Hartman
@ 2021-02-08 15:00 ` Greg Kroah-Hartman
2021-02-08 15:00 ` [PATCH 5.10 059/120] fgraph: Initialize tracing_graph_pause at task creation Greg Kroah-Hartman
` (68 subsequent siblings)
126 siblings, 0 replies; 140+ messages in thread
From: Greg Kroah-Hartman @ 2021-02-08 15:00 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Quanyang Wang, Bartosz Golaszewski
From: Quanyang Wang <quanyang.wang@windriver.com>
commit c351bb64cbe67029c68dea3adbec1b9508c6ff0f upstream.
In gpiochip_add_data_with_key, we should check the return value of
dev_set_name to ensure that device name is allocated successfully
and then add a label on the error path to free device name to fix
kmemleak as below:
unreferenced object 0xc2d6fc40 (size 64):
comm "kworker/0:1", pid 16, jiffies 4294937425 (age 65.120s)
hex dump (first 32 bytes):
67 70 69 6f 63 68 69 70 30 00 1a c0 54 63 1a c0 gpiochip0...Tc..
0c ed 84 c0 48 ed 84 c0 3c ee 84 c0 10 00 00 00 ....H...<.......
backtrace:
[<962810f7>] kobject_set_name_vargs+0x2c/0xa0
[<f50797e6>] dev_set_name+0x2c/0x5c
[<94abbca9>] gpiochip_add_data_with_key+0xfc/0xce8
[<5c4193e0>] omap_gpio_probe+0x33c/0x68c
[<3402f137>] platform_probe+0x58/0xb8
[<7421e210>] really_probe+0xec/0x3b4
[<000f8ada>] driver_probe_device+0x58/0xb4
[<67e0f7f7>] bus_for_each_drv+0x80/0xd0
[<4de545dc>] __device_attach+0xe8/0x15c
[<2e4431e7>] bus_probe_device+0x84/0x8c
[<c18b1de9>] device_add+0x384/0x7c0
[<5aff2995>] of_platform_device_create_pdata+0x8c/0xb8
[<061c3483>] of_platform_bus_create+0x198/0x230
[<5ee6d42a>] of_platform_populate+0x60/0xb8
[<2647300f>] sysc_probe+0xd18/0x135c
[<3402f137>] platform_probe+0x58/0xb8
Signed-off-by: Quanyang Wang <quanyang.wang@windriver.com>
Cc: stable@vger.kernel.org
Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/gpio/gpiolib.c | 10 ++++++++--
1 file changed, 8 insertions(+), 2 deletions(-)
--- a/drivers/gpio/gpiolib.c
+++ b/drivers/gpio/gpiolib.c
@@ -602,7 +602,11 @@ int gpiochip_add_data_with_key(struct gp
ret = gdev->id;
goto err_free_gdev;
}
- dev_set_name(&gdev->dev, GPIOCHIP_NAME "%d", gdev->id);
+
+ ret = dev_set_name(&gdev->dev, GPIOCHIP_NAME "%d", gdev->id);
+ if (ret)
+ goto err_free_ida;
+
device_initialize(&gdev->dev);
dev_set_drvdata(&gdev->dev, gdev);
if (gc->parent && gc->parent->driver)
@@ -616,7 +620,7 @@ int gpiochip_add_data_with_key(struct gp
gdev->descs = kcalloc(gc->ngpio, sizeof(gdev->descs[0]), GFP_KERNEL);
if (!gdev->descs) {
ret = -ENOMEM;
- goto err_free_ida;
+ goto err_free_dev_name;
}
if (gc->ngpio == 0) {
@@ -767,6 +771,8 @@ err_free_label:
kfree_const(gdev->label);
err_free_descs:
kfree(gdev->descs);
+err_free_dev_name:
+ kfree(dev_name(&gdev->dev));
err_free_ida:
ida_free(&gpio_ida, gdev->id);
err_free_gdev:
^ permalink raw reply [flat|nested] 140+ messages in thread* [PATCH 5.10 059/120] fgraph: Initialize tracing_graph_pause at task creation
2021-02-08 14:59 [PATCH 5.10 000/120] 5.10.15-rc1 review Greg Kroah-Hartman
` (57 preceding siblings ...)
2021-02-08 15:00 ` [PATCH 5.10 058/120] gpiolib: free device name on error path to fix kmemleak Greg Kroah-Hartman
@ 2021-02-08 15:00 ` Greg Kroah-Hartman
2021-02-08 15:00 ` [PATCH 5.10 060/120] tracing/kprobe: Fix to support kretprobe events on unloaded modules Greg Kroah-Hartman
` (67 subsequent siblings)
126 siblings, 0 replies; 140+ messages in thread
From: Greg Kroah-Hartman @ 2021-02-08 15:00 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, pierre.gondois, Steven Rostedt (VMware)
From: Steven Rostedt (VMware) <rostedt@goodmis.org>
commit 7e0a9220467dbcfdc5bc62825724f3e52e50ab31 upstream.
On some archs, the idle task can call into cpu_suspend(). The cpu_suspend()
will disable or pause function graph tracing, as there's some paths in
bringing down the CPU that can have issues with its return address being
modified. The task_struct structure has a "tracing_graph_pause" atomic
counter, that when set to something other than zero, the function graph
tracer will not modify the return address.
The problem is that the tracing_graph_pause counter is initialized when the
function graph tracer is enabled. This can corrupt the counter for the idle
task if it is suspended in these architectures.
CPU 1 CPU 2
----- -----
do_idle()
cpu_suspend()
pause_graph_tracing()
task_struct->tracing_graph_pause++ (0 -> 1)
start_graph_tracing()
for_each_online_cpu(cpu) {
ftrace_graph_init_idle_task(cpu)
task-struct->tracing_graph_pause = 0 (1 -> 0)
unpause_graph_tracing()
task_struct->tracing_graph_pause-- (0 -> -1)
The above should have gone from 1 to zero, and enabled function graph
tracing again. But instead, it is set to -1, which keeps it disabled.
There's no reason that the field tracing_graph_pause on the task_struct can
not be initialized at boot up.
Cc: stable@vger.kernel.org
Fixes: 380c4b1411ccd ("tracing/function-graph-tracer: append the tracing_graph_flag")
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=211339
Reported-by: pierre.gondois@arm.com
Signed-off-by: Steven Rostedt (VMware) <rostedt@goodmis.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
init/init_task.c | 3 ++-
kernel/trace/fgraph.c | 2 --
2 files changed, 2 insertions(+), 3 deletions(-)
--- a/init/init_task.c
+++ b/init/init_task.c
@@ -198,7 +198,8 @@ struct task_struct init_task
.lockdep_recursion = 0,
#endif
#ifdef CONFIG_FUNCTION_GRAPH_TRACER
- .ret_stack = NULL,
+ .ret_stack = NULL,
+ .tracing_graph_pause = ATOMIC_INIT(0),
#endif
#if defined(CONFIG_TRACING) && defined(CONFIG_PREEMPTION)
.trace_recursion = 0,
--- a/kernel/trace/fgraph.c
+++ b/kernel/trace/fgraph.c
@@ -395,7 +395,6 @@ static int alloc_retstack_tasklist(struc
}
if (t->ret_stack == NULL) {
- atomic_set(&t->tracing_graph_pause, 0);
atomic_set(&t->trace_overrun, 0);
t->curr_ret_stack = -1;
t->curr_ret_depth = -1;
@@ -490,7 +489,6 @@ static DEFINE_PER_CPU(struct ftrace_ret_
static void
graph_init_task(struct task_struct *t, struct ftrace_ret_stack *ret_stack)
{
- atomic_set(&t->tracing_graph_pause, 0);
atomic_set(&t->trace_overrun, 0);
t->ftrace_timestamp = 0;
/* make curr_ret_stack visible before we add the ret_stack */
^ permalink raw reply [flat|nested] 140+ messages in thread* [PATCH 5.10 060/120] tracing/kprobe: Fix to support kretprobe events on unloaded modules
2021-02-08 14:59 [PATCH 5.10 000/120] 5.10.15-rc1 review Greg Kroah-Hartman
` (58 preceding siblings ...)
2021-02-08 15:00 ` [PATCH 5.10 059/120] fgraph: Initialize tracing_graph_pause at task creation Greg Kroah-Hartman
@ 2021-02-08 15:00 ` Greg Kroah-Hartman
2021-02-08 15:00 ` [PATCH 5.10 061/120] kretprobe: Avoid re-registration of the same kretprobe earlier Greg Kroah-Hartman
` (66 subsequent siblings)
126 siblings, 0 replies; 140+ messages in thread
From: Greg Kroah-Hartman @ 2021-02-08 15:00 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Jianlin Lv, Masami Hiramatsu,
Steven Rostedt (VMware)
From: Masami Hiramatsu <mhiramat@kernel.org>
commit 97c753e62e6c31a404183898d950d8c08d752dbd upstream.
Fix kprobe_on_func_entry() returns error code instead of false so that
register_kretprobe() can return an appropriate error code.
append_trace_kprobe() expects the kprobe registration returns -ENOENT
when the target symbol is not found, and it checks whether the target
module is unloaded or not. If the target module doesn't exist, it
defers to probe the target symbol until the module is loaded.
However, since register_kretprobe() returns -EINVAL instead of -ENOENT
in that case, it always fail on putting the kretprobe event on unloaded
modules. e.g.
Kprobe event:
/sys/kernel/debug/tracing # echo p xfs:xfs_end_io >> kprobe_events
[ 16.515574] trace_kprobe: This probe might be able to register after target module is loaded. Continue.
Kretprobe event: (p -> r)
/sys/kernel/debug/tracing # echo r xfs:xfs_end_io >> kprobe_events
sh: write error: Invalid argument
/sys/kernel/debug/tracing # cat error_log
[ 41.122514] trace_kprobe: error: Failed to register probe event
Command: r xfs:xfs_end_io
^
To fix this bug, change kprobe_on_func_entry() to detect symbol lookup
failure and return -ENOENT in that case. Otherwise it returns -EINVAL
or 0 (succeeded, given address is on the entry).
Link: https://lkml.kernel.org/r/161176187132.1067016.8118042342894378981.stgit@devnote2
Cc: stable@vger.kernel.org
Fixes: 59158ec4aef7 ("tracing/kprobes: Check the probe on unloaded module correctly")
Reported-by: Jianlin Lv <Jianlin.Lv@arm.com>
Signed-off-by: Masami Hiramatsu <mhiramat@kernel.org>
Signed-off-by: Steven Rostedt (VMware) <rostedt@goodmis.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
include/linux/kprobes.h | 2 +-
kernel/kprobes.c | 34 +++++++++++++++++++++++++---------
kernel/trace/trace_kprobe.c | 10 ++++++----
3 files changed, 32 insertions(+), 14 deletions(-)
--- a/include/linux/kprobes.h
+++ b/include/linux/kprobes.h
@@ -251,7 +251,7 @@ extern void kprobes_inc_nmissed_count(st
extern bool arch_within_kprobe_blacklist(unsigned long addr);
extern int arch_populate_kprobe_blacklist(void);
extern bool arch_kprobe_on_func_entry(unsigned long offset);
-extern bool kprobe_on_func_entry(kprobe_opcode_t *addr, const char *sym, unsigned long offset);
+extern int kprobe_on_func_entry(kprobe_opcode_t *addr, const char *sym, unsigned long offset);
extern bool within_kprobe_blacklist(unsigned long addr);
extern int kprobe_add_ksym_blacklist(unsigned long entry);
--- a/kernel/kprobes.c
+++ b/kernel/kprobes.c
@@ -2082,29 +2082,45 @@ bool __weak arch_kprobe_on_func_entry(un
return !offset;
}
-bool kprobe_on_func_entry(kprobe_opcode_t *addr, const char *sym, unsigned long offset)
+/**
+ * kprobe_on_func_entry() -- check whether given address is function entry
+ * @addr: Target address
+ * @sym: Target symbol name
+ * @offset: The offset from the symbol or the address
+ *
+ * This checks whether the given @addr+@offset or @sym+@offset is on the
+ * function entry address or not.
+ * This returns 0 if it is the function entry, or -EINVAL if it is not.
+ * And also it returns -ENOENT if it fails the symbol or address lookup.
+ * Caller must pass @addr or @sym (either one must be NULL), or this
+ * returns -EINVAL.
+ */
+int kprobe_on_func_entry(kprobe_opcode_t *addr, const char *sym, unsigned long offset)
{
kprobe_opcode_t *kp_addr = _kprobe_addr(addr, sym, offset);
if (IS_ERR(kp_addr))
- return false;
+ return PTR_ERR(kp_addr);
- if (!kallsyms_lookup_size_offset((unsigned long)kp_addr, NULL, &offset) ||
- !arch_kprobe_on_func_entry(offset))
- return false;
+ if (!kallsyms_lookup_size_offset((unsigned long)kp_addr, NULL, &offset))
+ return -ENOENT;
- return true;
+ if (!arch_kprobe_on_func_entry(offset))
+ return -EINVAL;
+
+ return 0;
}
int register_kretprobe(struct kretprobe *rp)
{
- int ret = 0;
+ int ret;
struct kretprobe_instance *inst;
int i;
void *addr;
- if (!kprobe_on_func_entry(rp->kp.addr, rp->kp.symbol_name, rp->kp.offset))
- return -EINVAL;
+ ret = kprobe_on_func_entry(rp->kp.addr, rp->kp.symbol_name, rp->kp.offset);
+ if (ret)
+ return ret;
if (kretprobe_blacklist_size) {
addr = kprobe_addr(&rp->kp);
--- a/kernel/trace/trace_kprobe.c
+++ b/kernel/trace/trace_kprobe.c
@@ -221,9 +221,9 @@ bool trace_kprobe_on_func_entry(struct t
{
struct trace_kprobe *tk = trace_kprobe_primary_from_call(call);
- return tk ? kprobe_on_func_entry(tk->rp.kp.addr,
+ return tk ? (kprobe_on_func_entry(tk->rp.kp.addr,
tk->rp.kp.addr ? NULL : tk->rp.kp.symbol_name,
- tk->rp.kp.addr ? 0 : tk->rp.kp.offset) : false;
+ tk->rp.kp.addr ? 0 : tk->rp.kp.offset) == 0) : false;
}
bool trace_kprobe_error_injectable(struct trace_event_call *call)
@@ -828,9 +828,11 @@ static int trace_kprobe_create(int argc,
}
if (is_return)
flags |= TPARG_FL_RETURN;
- if (kprobe_on_func_entry(NULL, symbol, offset))
+ ret = kprobe_on_func_entry(NULL, symbol, offset);
+ if (ret == 0)
flags |= TPARG_FL_FENTRY;
- if (offset && is_return && !(flags & TPARG_FL_FENTRY)) {
+ /* Defer the ENOENT case until register kprobe */
+ if (ret == -EINVAL && is_return) {
trace_probe_log_err(0, BAD_RETPROBE);
goto parse_error;
}
^ permalink raw reply [flat|nested] 140+ messages in thread* [PATCH 5.10 061/120] kretprobe: Avoid re-registration of the same kretprobe earlier
2021-02-08 14:59 [PATCH 5.10 000/120] 5.10.15-rc1 review Greg Kroah-Hartman
` (59 preceding siblings ...)
2021-02-08 15:00 ` [PATCH 5.10 060/120] tracing/kprobe: Fix to support kretprobe events on unloaded modules Greg Kroah-Hartman
@ 2021-02-08 15:00 ` Greg Kroah-Hartman
2021-02-08 15:00 ` [PATCH 5.10 062/120] tracing: Use pause-on-trace with the latency tracers Greg Kroah-Hartman
` (65 subsequent siblings)
126 siblings, 0 replies; 140+ messages in thread
From: Greg Kroah-Hartman @ 2021-02-08 15:00 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Naveen N. Rao,
Ananth N Mavinakayanahalli, Masami Hiramatsu, Wang ShaoBo,
Cheng Jian, Steven Rostedt (VMware)
From: Wang ShaoBo <bobo.shaobowang@huawei.com>
commit 0188b87899ffc4a1d36a0badbe77d56c92fd91dc upstream.
Our system encountered a re-init error when re-registering same kretprobe,
where the kretprobe_instance in rp->free_instances is illegally accessed
after re-init.
Implementation to avoid re-registration has been introduced for kprobe
before, but lags for register_kretprobe(). We must check if kprobe has
been re-registered before re-initializing kretprobe, otherwise it will
destroy the data struct of kretprobe registered, which can lead to memory
leak, system crash, also some unexpected behaviors.
We use check_kprobe_rereg() to check if kprobe has been re-registered
before running register_kretprobe()'s body, for giving a warning message
and terminate registration process.
Link: https://lkml.kernel.org/r/20210128124427.2031088-1-bobo.shaobowang@huawei.com
Cc: stable@vger.kernel.org
Fixes: 1f0ab40976460 ("kprobes: Prevent re-registration of the same kprobe")
[ The above commit should have been done for kretprobes too ]
Acked-by: Naveen N. Rao <naveen.n.rao@linux.vnet.ibm.com>
Acked-by: Ananth N Mavinakayanahalli <ananth@linux.ibm.com>
Acked-by: Masami Hiramatsu <mhiramat@kernel.org>
Signed-off-by: Wang ShaoBo <bobo.shaobowang@huawei.com>
Signed-off-by: Cheng Jian <cj.chengjian@huawei.com>
Signed-off-by: Steven Rostedt (VMware) <rostedt@goodmis.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
kernel/kprobes.c | 4 ++++
1 file changed, 4 insertions(+)
--- a/kernel/kprobes.c
+++ b/kernel/kprobes.c
@@ -2122,6 +2122,10 @@ int register_kretprobe(struct kretprobe
if (ret)
return ret;
+ /* If only rp->kp.addr is specified, check reregistering kprobes */
+ if (rp->kp.addr && check_kprobe_rereg(&rp->kp))
+ return -EINVAL;
+
if (kretprobe_blacklist_size) {
addr = kprobe_addr(&rp->kp);
if (IS_ERR(addr))
^ permalink raw reply [flat|nested] 140+ messages in thread* [PATCH 5.10 062/120] tracing: Use pause-on-trace with the latency tracers
2021-02-08 14:59 [PATCH 5.10 000/120] 5.10.15-rc1 review Greg Kroah-Hartman
` (60 preceding siblings ...)
2021-02-08 15:00 ` [PATCH 5.10 061/120] kretprobe: Avoid re-registration of the same kretprobe earlier Greg Kroah-Hartman
@ 2021-02-08 15:00 ` Greg Kroah-Hartman
2021-02-08 15:00 ` [PATCH 5.10 063/120] tracepoint: Fix race between tracing and removing tracepoint Greg Kroah-Hartman
` (64 subsequent siblings)
126 siblings, 0 replies; 140+ messages in thread
From: Greg Kroah-Hartman @ 2021-02-08 15:00 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Viktor Rosendahl, Steven Rostedt (VMware)
From: Viktor Rosendahl <Viktor.Rosendahl@bmw.de>
commit da7f84cdf02fd5f66864041f45018b328911b722 upstream.
Eaerlier, tracing was disabled when reading the trace file. This behavior
was changed with:
commit 06e0a548bad0 ("tracing: Do not disable tracing when reading the
trace file").
This doesn't seem to work with the latency tracers.
The above mentioned commit dit not only change the behavior but also added
an option to emulate the old behavior. The idea with this patch is to
enable this pause-on-trace option when the latency tracers are used.
Link: https://lkml.kernel.org/r/20210119164344.37500-2-Viktor.Rosendahl@bmw.de
Cc: stable@vger.kernel.org
Fixes: 06e0a548bad0 ("tracing: Do not disable tracing when reading the trace file")
Signed-off-by: Viktor Rosendahl <Viktor.Rosendahl@bmw.de>
Signed-off-by: Steven Rostedt (VMware) <rostedt@goodmis.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
kernel/trace/trace_irqsoff.c | 4 ++++
1 file changed, 4 insertions(+)
--- a/kernel/trace/trace_irqsoff.c
+++ b/kernel/trace/trace_irqsoff.c
@@ -562,6 +562,8 @@ static int __irqsoff_tracer_init(struct
/* non overwrite screws up the latency tracers */
set_tracer_flag(tr, TRACE_ITER_OVERWRITE, 1);
set_tracer_flag(tr, TRACE_ITER_LATENCY_FMT, 1);
+ /* without pause, we will produce garbage if another latency occurs */
+ set_tracer_flag(tr, TRACE_ITER_PAUSE_ON_TRACE, 1);
tr->max_latency = 0;
irqsoff_trace = tr;
@@ -583,11 +585,13 @@ static void __irqsoff_tracer_reset(struc
{
int lat_flag = save_flags & TRACE_ITER_LATENCY_FMT;
int overwrite_flag = save_flags & TRACE_ITER_OVERWRITE;
+ int pause_flag = save_flags & TRACE_ITER_PAUSE_ON_TRACE;
stop_irqsoff_tracer(tr, is_graph(tr));
set_tracer_flag(tr, TRACE_ITER_LATENCY_FMT, lat_flag);
set_tracer_flag(tr, TRACE_ITER_OVERWRITE, overwrite_flag);
+ set_tracer_flag(tr, TRACE_ITER_PAUSE_ON_TRACE, pause_flag);
ftrace_reset_array_ops(tr);
irqsoff_busy = false;
^ permalink raw reply [flat|nested] 140+ messages in thread* [PATCH 5.10 063/120] tracepoint: Fix race between tracing and removing tracepoint
2021-02-08 14:59 [PATCH 5.10 000/120] 5.10.15-rc1 review Greg Kroah-Hartman
` (61 preceding siblings ...)
2021-02-08 15:00 ` [PATCH 5.10 062/120] tracing: Use pause-on-trace with the latency tracers Greg Kroah-Hartman
@ 2021-02-08 15:00 ` Greg Kroah-Hartman
2021-02-08 15:00 ` [PATCH 5.10 064/120] libnvdimm/namespace: Fix visibility of namespace resource attribute Greg Kroah-Hartman
` (63 subsequent siblings)
126 siblings, 0 replies; 140+ messages in thread
From: Greg Kroah-Hartman @ 2021-02-08 15:00 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Peter Zijlstra (Intel),
Alexey Kardashevskiy, Steven Rostedt (VMware)
From: Alexey Kardashevskiy <aik@ozlabs.ru>
commit c8b186a8d54d7e12d28e9f9686cb00ff18fc2ab2 upstream.
When executing a tracepoint, the tracepoint's func is dereferenced twice -
in __DO_TRACE() (where the returned pointer is checked) and later on in
__traceiter_##_name where the returned pointer is dereferenced without
checking which leads to races against tracepoint_removal_sync() and
crashes.
This adds a check before referencing the pointer in tracepoint_ptr_deref.
Link: https://lkml.kernel.org/r/20210202072326.120557-1-aik@ozlabs.ru
Cc: stable@vger.kernel.org
Fixes: d25e37d89dd2f ("tracepoint: Optimize using static_call()")
Acked-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru>
Signed-off-by: Steven Rostedt (VMware) <rostedt@goodmis.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
include/linux/tracepoint.h | 12 +++++++-----
1 file changed, 7 insertions(+), 5 deletions(-)
--- a/include/linux/tracepoint.h
+++ b/include/linux/tracepoint.h
@@ -307,11 +307,13 @@ static inline struct tracepoint *tracepo
\
it_func_ptr = \
rcu_dereference_raw((&__tracepoint_##_name)->funcs); \
- do { \
- it_func = (it_func_ptr)->func; \
- __data = (it_func_ptr)->data; \
- ((void(*)(void *, proto))(it_func))(__data, args); \
- } while ((++it_func_ptr)->func); \
+ if (it_func_ptr) { \
+ do { \
+ it_func = (it_func_ptr)->func; \
+ __data = (it_func_ptr)->data; \
+ ((void(*)(void *, proto))(it_func))(__data, args); \
+ } while ((++it_func_ptr)->func); \
+ } \
return 0; \
} \
DEFINE_STATIC_CALL(tp_func_##_name, __traceiter_##_name);
^ permalink raw reply [flat|nested] 140+ messages in thread* [PATCH 5.10 064/120] libnvdimm/namespace: Fix visibility of namespace resource attribute
2021-02-08 14:59 [PATCH 5.10 000/120] 5.10.15-rc1 review Greg Kroah-Hartman
` (62 preceding siblings ...)
2021-02-08 15:00 ` [PATCH 5.10 063/120] tracepoint: Fix race between tracing and removing tracepoint Greg Kroah-Hartman
@ 2021-02-08 15:00 ` Greg Kroah-Hartman
2021-02-08 15:00 ` [PATCH 5.10 065/120] libnvdimm/dimm: Avoid race between probe and available_slots_show() Greg Kroah-Hartman
` (62 subsequent siblings)
126 siblings, 0 replies; 140+ messages in thread
From: Greg Kroah-Hartman @ 2021-02-08 15:00 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Vishal Verma, Dave Jiang, Ira Weiny,
Dan Williams
From: Dan Williams <dan.j.williams@intel.com>
commit 13f445d65955f388499f00851dc9a86280970f7c upstream.
Legacy pmem namespaces lost support for the "resource" attribute when
the code was cleaned up to put the permission visibility in the
declaration. Restore this by listing 'resource' in the default
attributes.
A new ndctl regression test for pfn_to_online_page() corner cases builds
on this fix.
Fixes: bfd2e9140656 ("libnvdimm: Simplify root read-only definition for the 'resource' attribute")
Cc: Vishal Verma <vishal.l.verma@intel.com>
Cc: Dave Jiang <dave.jiang@intel.com>
Cc: Ira Weiny <ira.weiny@intel.com>
Cc: <stable@vger.kernel.org>
Link: https://lore.kernel.org/r/161052334995.1805594.12054873528154362921.stgit@dwillia2-desk3.amr.corp.intel.com
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/nvdimm/namespace_devs.c | 10 +++++-----
1 file changed, 5 insertions(+), 5 deletions(-)
--- a/drivers/nvdimm/namespace_devs.c
+++ b/drivers/nvdimm/namespace_devs.c
@@ -1635,11 +1635,11 @@ static umode_t namespace_visible(struct
return a->mode;
}
- if (a == &dev_attr_nstype.attr || a == &dev_attr_size.attr
- || a == &dev_attr_holder.attr
- || a == &dev_attr_holder_class.attr
- || a == &dev_attr_force_raw.attr
- || a == &dev_attr_mode.attr)
+ /* base is_namespace_io() attributes */
+ if (a == &dev_attr_nstype.attr || a == &dev_attr_size.attr ||
+ a == &dev_attr_holder.attr || a == &dev_attr_holder_class.attr ||
+ a == &dev_attr_force_raw.attr || a == &dev_attr_mode.attr ||
+ a == &dev_attr_resource.attr)
return a->mode;
return 0;
^ permalink raw reply [flat|nested] 140+ messages in thread* [PATCH 5.10 065/120] libnvdimm/dimm: Avoid race between probe and available_slots_show()
2021-02-08 14:59 [PATCH 5.10 000/120] 5.10.15-rc1 review Greg Kroah-Hartman
` (63 preceding siblings ...)
2021-02-08 15:00 ` [PATCH 5.10 064/120] libnvdimm/namespace: Fix visibility of namespace resource attribute Greg Kroah-Hartman
@ 2021-02-08 15:00 ` Greg Kroah-Hartman
2021-02-08 15:00 ` [PATCH 5.10 066/120] genirq: Prevent [devm_]irq_alloc_desc from returning irq 0 Greg Kroah-Hartman
` (61 subsequent siblings)
126 siblings, 0 replies; 140+ messages in thread
From: Greg Kroah-Hartman @ 2021-02-08 15:00 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Vishal Verma, Dave Jiang, Ira Weiny,
Coly Li, Richard Palethorpe, Dan Williams
From: Dan Williams <dan.j.williams@intel.com>
commit 7018c897c2f243d4b5f1b94bc6b4831a7eab80fb upstream.
Richard reports that the following test:
(while true; do
cat /sys/bus/nd/devices/nmem*/available_slots 2>&1 > /dev/null
done) &
while true; do
for i in $(seq 0 4); do
echo nmem$i > /sys/bus/nd/drivers/nvdimm/bind
done
for i in $(seq 0 4); do
echo nmem$i > /sys/bus/nd/drivers/nvdimm/unbind
done
done
...fails with a crash signature like:
divide error: 0000 [#1] SMP KASAN PTI
RIP: 0010:nd_label_nfree+0x134/0x1a0 [libnvdimm]
[..]
Call Trace:
available_slots_show+0x4e/0x120 [libnvdimm]
dev_attr_show+0x42/0x80
? memset+0x20/0x40
sysfs_kf_seq_show+0x218/0x410
The root cause is that available_slots_show() consults driver-data, but
fails to synchronize against device-unbind setting up a TOCTOU race to
access uninitialized memory.
Validate driver-data under the device-lock.
Fixes: 4d88a97aa9e8 ("libnvdimm, nvdimm: dimm driver and base libnvdimm device-driver infrastructure")
Cc: <stable@vger.kernel.org>
Cc: Vishal Verma <vishal.l.verma@intel.com>
Cc: Dave Jiang <dave.jiang@intel.com>
Cc: Ira Weiny <ira.weiny@intel.com>
Cc: Coly Li <colyli@suse.com>
Reported-by: Richard Palethorpe <rpalethorpe@suse.com>
Acked-by: Richard Palethorpe <rpalethorpe@suse.com>
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/nvdimm/dimm_devs.c | 18 +++++++++++++++---
1 file changed, 15 insertions(+), 3 deletions(-)
--- a/drivers/nvdimm/dimm_devs.c
+++ b/drivers/nvdimm/dimm_devs.c
@@ -335,16 +335,16 @@ static ssize_t state_show(struct device
}
static DEVICE_ATTR_RO(state);
-static ssize_t available_slots_show(struct device *dev,
- struct device_attribute *attr, char *buf)
+static ssize_t __available_slots_show(struct nvdimm_drvdata *ndd, char *buf)
{
- struct nvdimm_drvdata *ndd = dev_get_drvdata(dev);
+ struct device *dev;
ssize_t rc;
u32 nfree;
if (!ndd)
return -ENXIO;
+ dev = ndd->dev;
nvdimm_bus_lock(dev);
nfree = nd_label_nfree(ndd);
if (nfree - 1 > nfree) {
@@ -356,6 +356,18 @@ static ssize_t available_slots_show(stru
nvdimm_bus_unlock(dev);
return rc;
}
+
+static ssize_t available_slots_show(struct device *dev,
+ struct device_attribute *attr, char *buf)
+{
+ ssize_t rc;
+
+ nd_device_lock(dev);
+ rc = __available_slots_show(dev_get_drvdata(dev), buf);
+ nd_device_unlock(dev);
+
+ return rc;
+}
static DEVICE_ATTR_RO(available_slots);
__weak ssize_t security_show(struct device *dev,
^ permalink raw reply [flat|nested] 140+ messages in thread* [PATCH 5.10 066/120] genirq: Prevent [devm_]irq_alloc_desc from returning irq 0
2021-02-08 14:59 [PATCH 5.10 000/120] 5.10.15-rc1 review Greg Kroah-Hartman
` (64 preceding siblings ...)
2021-02-08 15:00 ` [PATCH 5.10 065/120] libnvdimm/dimm: Avoid race between probe and available_slots_show() Greg Kroah-Hartman
@ 2021-02-08 15:00 ` Greg Kroah-Hartman
2021-02-08 15:00 ` [PATCH 5.10 067/120] genirq/msi: Activate Multi-MSI early when MSI_FLAG_ACTIVATE_EARLY is set Greg Kroah-Hartman
` (60 subsequent siblings)
126 siblings, 0 replies; 140+ messages in thread
From: Greg Kroah-Hartman @ 2021-02-08 15:00 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, Hans de Goede, Thomas Gleixner
From: Hans de Goede <hdegoede@redhat.com>
commit 4c7bcb51ae25f79e3733982e5d0cd8ce8640ddfc upstream.
Since commit a85a6c86c25b ("driver core: platform: Clarify that IRQ 0
is invalid"), having a linux-irq with number 0 will trigger a WARN()
when calling platform_get_irq*() to retrieve that linux-irq.
Since [devm_]irq_alloc_desc allocs a single irq and since irq 0 is not used
on some systems, it can return 0, triggering that WARN(). This happens
e.g. on Intel Bay Trail and Cherry Trail devices using the LPE audio engine
for HDMI audio:
0 is an invalid IRQ number
WARNING: CPU: 3 PID: 472 at drivers/base/platform.c:238 platform_get_irq_optional+0x108/0x180
Modules linked in: snd_hdmi_lpe_audio(+) ...
Call Trace:
platform_get_irq+0x17/0x30
hdmi_lpe_audio_probe+0x4a/0x6c0 [snd_hdmi_lpe_audio]
---[ end trace ceece38854223a0b ]---
Change the 'from' parameter passed to __[devm_]irq_alloc_descs() by the
[devm_]irq_alloc_desc macros from 0 to 1, so that these macros will no
longer return 0.
Fixes: a85a6c86c25b ("driver core: platform: Clarify that IRQ 0 is invalid")
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Cc: stable@vger.kernel.org
Link: https://lore.kernel.org/r/20201221185647.226146-1-hdegoede@redhat.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
include/linux/irq.h | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
--- a/include/linux/irq.h
+++ b/include/linux/irq.h
@@ -922,7 +922,7 @@ int __devm_irq_alloc_descs(struct device
__irq_alloc_descs(irq, from, cnt, node, THIS_MODULE, NULL)
#define irq_alloc_desc(node) \
- irq_alloc_descs(-1, 0, 1, node)
+ irq_alloc_descs(-1, 1, 1, node)
#define irq_alloc_desc_at(at, node) \
irq_alloc_descs(at, at, 1, node)
@@ -937,7 +937,7 @@ int __devm_irq_alloc_descs(struct device
__devm_irq_alloc_descs(dev, irq, from, cnt, node, THIS_MODULE, NULL)
#define devm_irq_alloc_desc(dev, node) \
- devm_irq_alloc_descs(dev, -1, 0, 1, node)
+ devm_irq_alloc_descs(dev, -1, 1, 1, node)
#define devm_irq_alloc_desc_at(dev, at, node) \
devm_irq_alloc_descs(dev, at, at, 1, node)
^ permalink raw reply [flat|nested] 140+ messages in thread* [PATCH 5.10 067/120] genirq/msi: Activate Multi-MSI early when MSI_FLAG_ACTIVATE_EARLY is set
2021-02-08 14:59 [PATCH 5.10 000/120] 5.10.15-rc1 review Greg Kroah-Hartman
` (65 preceding siblings ...)
2021-02-08 15:00 ` [PATCH 5.10 066/120] genirq: Prevent [devm_]irq_alloc_desc from returning irq 0 Greg Kroah-Hartman
@ 2021-02-08 15:00 ` Greg Kroah-Hartman
2021-02-08 15:00 ` [PATCH 5.10 068/120] scripts: use pkg-config to locate libcrypto Greg Kroah-Hartman
` (59 subsequent siblings)
126 siblings, 0 replies; 140+ messages in thread
From: Greg Kroah-Hartman @ 2021-02-08 15:00 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Shameer Kolothum, Marc Zyngier,
Thomas Gleixner
From: Marc Zyngier <maz@kernel.org>
commit 4c457e8cb75eda91906a4f89fc39bde3f9a43922 upstream.
When MSI_FLAG_ACTIVATE_EARLY is set (which is the case for PCI),
__msi_domain_alloc_irqs() performs the activation of the interrupt (which
in the case of PCI results in the endpoint being programmed) as soon as the
interrupt is allocated.
But it appears that this is only done for the first vector, introducing an
inconsistent behaviour for PCI Multi-MSI.
Fix it by iterating over the number of vectors allocated to each MSI
descriptor. This is easily achieved by introducing a new
"for_each_msi_vector" iterator, together with a tiny bit of refactoring.
Fixes: f3b0946d629c ("genirq/msi: Make sure PCI MSIs are activated early")
Reported-by: Shameer Kolothum <shameerali.kolothum.thodi@huawei.com>
Signed-off-by: Marc Zyngier <maz@kernel.org>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Tested-by: Shameer Kolothum <shameerali.kolothum.thodi@huawei.com>
Cc: stable@vger.kernel.org
Link: https://lore.kernel.org/r/20210123122759.1781359-1-maz@kernel.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
include/linux/msi.h | 6 ++++++
kernel/irq/msi.c | 44 ++++++++++++++++++++------------------------
2 files changed, 26 insertions(+), 24 deletions(-)
--- a/include/linux/msi.h
+++ b/include/linux/msi.h
@@ -139,6 +139,12 @@ struct msi_desc {
list_for_each_entry((desc), dev_to_msi_list((dev)), list)
#define for_each_msi_entry_safe(desc, tmp, dev) \
list_for_each_entry_safe((desc), (tmp), dev_to_msi_list((dev)), list)
+#define for_each_msi_vector(desc, __irq, dev) \
+ for_each_msi_entry((desc), (dev)) \
+ if ((desc)->irq) \
+ for (__irq = (desc)->irq; \
+ __irq < ((desc)->irq + (desc)->nvec_used); \
+ __irq++)
#ifdef CONFIG_IRQ_MSI_IOMMU
static inline const void *msi_desc_get_iommu_cookie(struct msi_desc *desc)
--- a/kernel/irq/msi.c
+++ b/kernel/irq/msi.c
@@ -436,22 +436,22 @@ int __msi_domain_alloc_irqs(struct irq_d
can_reserve = msi_check_reservation_mode(domain, info, dev);
- for_each_msi_entry(desc, dev) {
- virq = desc->irq;
- if (desc->nvec_used == 1)
- dev_dbg(dev, "irq %d for MSI\n", virq);
- else
+ /*
+ * This flag is set by the PCI layer as we need to activate
+ * the MSI entries before the PCI layer enables MSI in the
+ * card. Otherwise the card latches a random msi message.
+ */
+ if (!(info->flags & MSI_FLAG_ACTIVATE_EARLY))
+ goto skip_activate;
+
+ for_each_msi_vector(desc, i, dev) {
+ if (desc->irq == i) {
+ virq = desc->irq;
dev_dbg(dev, "irq [%d-%d] for MSI\n",
virq, virq + desc->nvec_used - 1);
- /*
- * This flag is set by the PCI layer as we need to activate
- * the MSI entries before the PCI layer enables MSI in the
- * card. Otherwise the card latches a random msi message.
- */
- if (!(info->flags & MSI_FLAG_ACTIVATE_EARLY))
- continue;
+ }
- irq_data = irq_domain_get_irq_data(domain, desc->irq);
+ irq_data = irq_domain_get_irq_data(domain, i);
if (!can_reserve) {
irqd_clr_can_reserve(irq_data);
if (domain->flags & IRQ_DOMAIN_MSI_NOMASK_QUIRK)
@@ -462,28 +462,24 @@ int __msi_domain_alloc_irqs(struct irq_d
goto cleanup;
}
+skip_activate:
/*
* If these interrupts use reservation mode, clear the activated bit
* so request_irq() will assign the final vector.
*/
if (can_reserve) {
- for_each_msi_entry(desc, dev) {
- irq_data = irq_domain_get_irq_data(domain, desc->irq);
+ for_each_msi_vector(desc, i, dev) {
+ irq_data = irq_domain_get_irq_data(domain, i);
irqd_clr_activated(irq_data);
}
}
return 0;
cleanup:
- for_each_msi_entry(desc, dev) {
- struct irq_data *irqd;
-
- if (desc->irq == virq)
- break;
-
- irqd = irq_domain_get_irq_data(domain, desc->irq);
- if (irqd_is_activated(irqd))
- irq_domain_deactivate_irq(irqd);
+ for_each_msi_vector(desc, i, dev) {
+ irq_data = irq_domain_get_irq_data(domain, i);
+ if (irqd_is_activated(irq_data))
+ irq_domain_deactivate_irq(irq_data);
}
msi_domain_free_irqs(domain, dev);
return ret;
^ permalink raw reply [flat|nested] 140+ messages in thread* [PATCH 5.10 068/120] scripts: use pkg-config to locate libcrypto
2021-02-08 14:59 [PATCH 5.10 000/120] 5.10.15-rc1 review Greg Kroah-Hartman
` (66 preceding siblings ...)
2021-02-08 15:00 ` [PATCH 5.10 067/120] genirq/msi: Activate Multi-MSI early when MSI_FLAG_ACTIVATE_EARLY is set Greg Kroah-Hartman
@ 2021-02-08 15:00 ` Greg Kroah-Hartman
2021-02-08 15:00 ` [PATCH 5.10 069/120] xhci: fix bounce buffer usage for non-sg list case Greg Kroah-Hartman
` (58 subsequent siblings)
126 siblings, 0 replies; 140+ messages in thread
From: Greg Kroah-Hartman @ 2021-02-08 15:00 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, Rolf Eike Beer, Masahiro Yamada
From: Rolf Eike Beer <eb@emlix.com>
commit 2cea4a7a1885bd0c765089afc14f7ff0eb77864e upstream.
Otherwise build fails if the headers are not in the default location. While at
it also ask pkg-config for the libs, with fallback to the existing value.
Signed-off-by: Rolf Eike Beer <eb@emlix.com>
Cc: stable@vger.kernel.org # 5.6.x
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
scripts/Makefile | 8 ++++++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/scripts/Makefile b/scripts/Makefile
index b5418ec587fb..9de3c03b94aa 100644
--- a/scripts/Makefile
+++ b/scripts/Makefile
@@ -3,6 +3,9 @@
# scripts contains sources for various helper programs used throughout
# the kernel for the build process.
+CRYPTO_LIBS = $(shell pkg-config --libs libcrypto 2> /dev/null || echo -lcrypto)
+CRYPTO_CFLAGS = $(shell pkg-config --cflags libcrypto 2> /dev/null)
+
hostprogs-always-$(CONFIG_BUILD_BIN2C) += bin2c
hostprogs-always-$(CONFIG_KALLSYMS) += kallsyms
hostprogs-always-$(BUILD_C_RECORDMCOUNT) += recordmcount
@@ -14,8 +17,9 @@ hostprogs-always-$(CONFIG_SYSTEM_EXTRA_CERTIFICATE) += insert-sys-cert
HOSTCFLAGS_sorttable.o = -I$(srctree)/tools/include
HOSTCFLAGS_asn1_compiler.o = -I$(srctree)/include
-HOSTLDLIBS_sign-file = -lcrypto
-HOSTLDLIBS_extract-cert = -lcrypto
+HOSTLDLIBS_sign-file = $(CRYPTO_LIBS)
+HOSTCFLAGS_extract-cert.o = $(CRYPTO_CFLAGS)
+HOSTLDLIBS_extract-cert = $(CRYPTO_LIBS)
ifdef CONFIG_UNWINDER_ORC
ifeq ($(ARCH),x86_64)
--
2.30.0
^ permalink raw reply related [flat|nested] 140+ messages in thread* [PATCH 5.10 069/120] xhci: fix bounce buffer usage for non-sg list case
2021-02-08 14:59 [PATCH 5.10 000/120] 5.10.15-rc1 review Greg Kroah-Hartman
` (67 preceding siblings ...)
2021-02-08 15:00 ` [PATCH 5.10 068/120] scripts: use pkg-config to locate libcrypto Greg Kroah-Hartman
@ 2021-02-08 15:00 ` Greg Kroah-Hartman
2021-02-08 15:00 ` [PATCH 5.10 070/120] RISC-V: Define MAXPHYSMEM_1GB only for RV32 Greg Kroah-Hartman
` (57 subsequent siblings)
126 siblings, 0 replies; 140+ messages in thread
From: Greg Kroah-Hartman @ 2021-02-08 15:00 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, Andreas Hartmann, Mathias Nyman
From: Mathias Nyman <mathias.nyman@linux.intel.com>
commit d4a610635400ccc382792f6be69427078541c678 upstream.
xhci driver may in some special cases need to copy small amounts
of payload data to a bounce buffer in order to meet the boundary
and alignment restrictions set by the xHCI specification.
In the majority of these cases the data is in a sg list, and
driver incorrectly assumed data is always in urb->sg when using
the bounce buffer.
If data instead is contiguous, and in urb->transfer_buffer, we may still
need to bounce buffer a small part if data starts very close (less than
packet size) to a 64k boundary.
Check if sg list is used before copying data to/from it.
Fixes: f9c589e142d0 ("xhci: TD-fragment, align the unsplittable case with a bounce buffer")
Cc: stable@vger.kernel.org
Reported-by: Andreas Hartmann <andihartmann@01019freenet.de>
Tested-by: Andreas Hartmann <andihartmann@01019freenet.de>
Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
Link: https://lore.kernel.org/r/20210203113702.436762-2-mathias.nyman@linux.intel.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/usb/host/xhci-ring.c | 31 ++++++++++++++++++++-----------
1 file changed, 20 insertions(+), 11 deletions(-)
--- a/drivers/usb/host/xhci-ring.c
+++ b/drivers/usb/host/xhci-ring.c
@@ -699,11 +699,16 @@ static void xhci_unmap_td_bounce_buffer(
dma_unmap_single(dev, seg->bounce_dma, ring->bounce_buf_len,
DMA_FROM_DEVICE);
/* for in tranfers we need to copy the data from bounce to sg */
- len = sg_pcopy_from_buffer(urb->sg, urb->num_sgs, seg->bounce_buf,
- seg->bounce_len, seg->bounce_offs);
- if (len != seg->bounce_len)
- xhci_warn(xhci, "WARN Wrong bounce buffer read length: %zu != %d\n",
- len, seg->bounce_len);
+ if (urb->num_sgs) {
+ len = sg_pcopy_from_buffer(urb->sg, urb->num_sgs, seg->bounce_buf,
+ seg->bounce_len, seg->bounce_offs);
+ if (len != seg->bounce_len)
+ xhci_warn(xhci, "WARN Wrong bounce buffer read length: %zu != %d\n",
+ len, seg->bounce_len);
+ } else {
+ memcpy(urb->transfer_buffer + seg->bounce_offs, seg->bounce_buf,
+ seg->bounce_len);
+ }
seg->bounce_len = 0;
seg->bounce_offs = 0;
}
@@ -3275,12 +3280,16 @@ static int xhci_align_td(struct xhci_hcd
/* create a max max_pkt sized bounce buffer pointed to by last trb */
if (usb_urb_dir_out(urb)) {
- len = sg_pcopy_to_buffer(urb->sg, urb->num_sgs,
- seg->bounce_buf, new_buff_len, enqd_len);
- if (len != new_buff_len)
- xhci_warn(xhci,
- "WARN Wrong bounce buffer write length: %zu != %d\n",
- len, new_buff_len);
+ if (urb->num_sgs) {
+ len = sg_pcopy_to_buffer(urb->sg, urb->num_sgs,
+ seg->bounce_buf, new_buff_len, enqd_len);
+ if (len != new_buff_len)
+ xhci_warn(xhci, "WARN Wrong bounce buffer write length: %zu != %d\n",
+ len, new_buff_len);
+ } else {
+ memcpy(seg->bounce_buf, urb->transfer_buffer + enqd_len, new_buff_len);
+ }
+
seg->bounce_dma = dma_map_single(dev, seg->bounce_buf,
max_pkt, DMA_TO_DEVICE);
} else {
^ permalink raw reply [flat|nested] 140+ messages in thread* [PATCH 5.10 070/120] RISC-V: Define MAXPHYSMEM_1GB only for RV32
2021-02-08 14:59 [PATCH 5.10 000/120] 5.10.15-rc1 review Greg Kroah-Hartman
` (68 preceding siblings ...)
2021-02-08 15:00 ` [PATCH 5.10 069/120] xhci: fix bounce buffer usage for non-sg list case Greg Kroah-Hartman
@ 2021-02-08 15:00 ` Greg Kroah-Hartman
2021-02-08 15:00 ` [PATCH 5.10 071/120] cifs: report error instead of invalid when revalidating a dentry fails Greg Kroah-Hartman
` (56 subsequent siblings)
126 siblings, 0 replies; 140+ messages in thread
From: Greg Kroah-Hartman @ 2021-02-08 15:00 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Randy Dunlap, Geert Uytterhoeven,
Atish Patra, Palmer Dabbelt
From: Atish Patra <atish.patra@wdc.com>
commit de5f4b8f634beacf667e6eff334522601dd03b59 upstream.
MAXPHYSMEM_1GB option was added for RV32 because RV32 only supports 1GB
of maximum physical memory. This lead to few compilation errors reported
by kernel test robot which created the following configuration combination
which are not useful but can be configured.
1. MAXPHYSMEM_1GB & RV64
2, MAXPHYSMEM_2GB & RV32
Fix this by restricting MAXPHYSMEM_1GB for RV32 and MAXPHYSMEM_2GB only for
RV64.
Fixes: e557793799c5 ("RISC-V: Fix maximum allowed phsyical memory for RV32")
Cc: stable@vger.kernel.org
Reported-by: Randy Dunlap <rdunlap@infradead.org>
Acked-by: Randy Dunlap <rdunlap@infradead.org>
Tested-by: Geert Uytterhoeven <geert@linux-m68k.org>
Signed-off-by: Atish Patra <atish.patra@wdc.com>
Signed-off-by: Palmer Dabbelt <palmerdabbelt@google.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
arch/riscv/Kconfig | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/riscv/Kconfig b/arch/riscv/Kconfig
index e9e2c1f0a690..e0a34eb5ed3b 100644
--- a/arch/riscv/Kconfig
+++ b/arch/riscv/Kconfig
@@ -252,8 +252,10 @@ choice
default MAXPHYSMEM_128GB if 64BIT && CMODEL_MEDANY
config MAXPHYSMEM_1GB
+ depends on 32BIT
bool "1GiB"
config MAXPHYSMEM_2GB
+ depends on 64BIT && CMODEL_MEDLOW
bool "2GiB"
config MAXPHYSMEM_128GB
depends on 64BIT && CMODEL_MEDANY
--
2.30.0
^ permalink raw reply related [flat|nested] 140+ messages in thread* [PATCH 5.10 071/120] cifs: report error instead of invalid when revalidating a dentry fails
2021-02-08 14:59 [PATCH 5.10 000/120] 5.10.15-rc1 review Greg Kroah-Hartman
` (69 preceding siblings ...)
2021-02-08 15:00 ` [PATCH 5.10 070/120] RISC-V: Define MAXPHYSMEM_1GB only for RV32 Greg Kroah-Hartman
@ 2021-02-08 15:00 ` Greg Kroah-Hartman
2021-02-08 15:00 ` [PATCH 5.10 072/120] iommu: Check dev->iommu in dev_iommu_priv_get() before dereferencing it Greg Kroah-Hartman
` (55 subsequent siblings)
126 siblings, 0 replies; 140+ messages in thread
From: Greg Kroah-Hartman @ 2021-02-08 15:00 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Aurelien Aptel, Shyam Prasad N, Steve French
From: Aurelien Aptel <aaptel@suse.com>
commit 21b200d091826a83aafc95d847139b2b0582f6d1 upstream.
Assuming
- //HOST/a is mounted on /mnt
- //HOST/b is mounted on /mnt/b
On a slow connection, running 'df' and killing it while it's
processing /mnt/b can make cifs_get_inode_info() returns -ERESTARTSYS.
This triggers the following chain of events:
=> the dentry revalidation fail
=> dentry is put and released
=> superblock associated with the dentry is put
=> /mnt/b is unmounted
This patch makes cifs_d_revalidate() return the error instead of 0
(invalid) when cifs_revalidate_dentry() fails, except for ENOENT (file
deleted) and ESTALE (file recreated).
Signed-off-by: Aurelien Aptel <aaptel@suse.com>
Suggested-by: Shyam Prasad N <nspmangalore@gmail.com>
Reviewed-by: Shyam Prasad N <nspmangalore@gmail.com>
CC: stable@vger.kernel.org
Signed-off-by: Steve French <stfrench@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
fs/cifs/dir.c | 22 ++++++++++++++++++++--
1 file changed, 20 insertions(+), 2 deletions(-)
--- a/fs/cifs/dir.c
+++ b/fs/cifs/dir.c
@@ -736,6 +736,7 @@ static int
cifs_d_revalidate(struct dentry *direntry, unsigned int flags)
{
struct inode *inode;
+ int rc;
if (flags & LOOKUP_RCU)
return -ECHILD;
@@ -745,8 +746,25 @@ cifs_d_revalidate(struct dentry *direntr
if ((flags & LOOKUP_REVAL) && !CIFS_CACHE_READ(CIFS_I(inode)))
CIFS_I(inode)->time = 0; /* force reval */
- if (cifs_revalidate_dentry(direntry))
- return 0;
+ rc = cifs_revalidate_dentry(direntry);
+ if (rc) {
+ cifs_dbg(FYI, "cifs_revalidate_dentry failed with rc=%d", rc);
+ switch (rc) {
+ case -ENOENT:
+ case -ESTALE:
+ /*
+ * Those errors mean the dentry is invalid
+ * (file was deleted or recreated)
+ */
+ return 0;
+ default:
+ /*
+ * Otherwise some unexpected error happened
+ * report it as-is to VFS layer
+ */
+ return rc;
+ }
+ }
else {
/*
* If the inode wasn't known to be a dfs entry when
^ permalink raw reply [flat|nested] 140+ messages in thread* [PATCH 5.10 072/120] iommu: Check dev->iommu in dev_iommu_priv_get() before dereferencing it
2021-02-08 14:59 [PATCH 5.10 000/120] 5.10.15-rc1 review Greg Kroah-Hartman
` (70 preceding siblings ...)
2021-02-08 15:00 ` [PATCH 5.10 071/120] cifs: report error instead of invalid when revalidating a dentry fails Greg Kroah-Hartman
@ 2021-02-08 15:00 ` Greg Kroah-Hartman
2021-02-08 15:01 ` [PATCH 5.10 073/120] smb3: Fix out-of-bounds bug in SMB2_negotiate() Greg Kroah-Hartman
` (54 subsequent siblings)
126 siblings, 0 replies; 140+ messages in thread
From: Greg Kroah-Hartman @ 2021-02-08 15:00 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, Joerg Roedel
From: Joerg Roedel <jroedel@suse.de>
commit 4c9fb5d9140802db4db9f66c23887f43174e113c upstream.
The dev_iommu_priv_get() needs a similar check to
dev_iommu_fwspec_get() to make sure no NULL-ptr is dereferenced.
Fixes: 05a0542b456e1 ("iommu/amd: Store dev_data as device iommu private data")
Cc: stable@vger.kernel.org # v5.8+
Link: https://lore.kernel.org/r/20210202145419.29143-1-joro@8bytes.org
Reference: https://bugzilla.kernel.org/show_bug.cgi?id=211241
Signed-off-by: Joerg Roedel <jroedel@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
include/linux/iommu.h | 5 ++++-
1 file changed, 4 insertions(+), 1 deletion(-)
--- a/include/linux/iommu.h
+++ b/include/linux/iommu.h
@@ -614,7 +614,10 @@ static inline void dev_iommu_fwspec_set(
static inline void *dev_iommu_priv_get(struct device *dev)
{
- return dev->iommu->priv;
+ if (dev->iommu)
+ return dev->iommu->priv;
+ else
+ return NULL;
}
static inline void dev_iommu_priv_set(struct device *dev, void *priv)
^ permalink raw reply [flat|nested] 140+ messages in thread* [PATCH 5.10 073/120] smb3: Fix out-of-bounds bug in SMB2_negotiate()
2021-02-08 14:59 [PATCH 5.10 000/120] 5.10.15-rc1 review Greg Kroah-Hartman
` (71 preceding siblings ...)
2021-02-08 15:00 ` [PATCH 5.10 072/120] iommu: Check dev->iommu in dev_iommu_priv_get() before dereferencing it Greg Kroah-Hartman
@ 2021-02-08 15:01 ` Greg Kroah-Hartman
2021-02-08 15:01 ` [PATCH 5.10 074/120] smb3: fix crediting for compounding when only one request in flight Greg Kroah-Hartman
` (53 subsequent siblings)
126 siblings, 0 replies; 140+ messages in thread
From: Greg Kroah-Hartman @ 2021-02-08 15:01 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Gustavo A. R. Silva, Steve French
From: Gustavo A. R. Silva <gustavoars@kernel.org>
commit 8d8d1dbefc423d42d626cf5b81aac214870ebaab upstream.
While addressing some warnings generated by -Warray-bounds, I found this
bug that was introduced back in 2017:
CC [M] fs/cifs/smb2pdu.o
fs/cifs/smb2pdu.c: In function ‘SMB2_negotiate’:
fs/cifs/smb2pdu.c:822:16: warning: array subscript 1 is above array bounds
of ‘__le16[1]’ {aka ‘short unsigned int[1]’} [-Warray-bounds]
822 | req->Dialects[1] = cpu_to_le16(SMB30_PROT_ID);
| ~~~~~~~~~~~~~^~~
fs/cifs/smb2pdu.c:823:16: warning: array subscript 2 is above array bounds
of ‘__le16[1]’ {aka ‘short unsigned int[1]’} [-Warray-bounds]
823 | req->Dialects[2] = cpu_to_le16(SMB302_PROT_ID);
| ~~~~~~~~~~~~~^~~
fs/cifs/smb2pdu.c:824:16: warning: array subscript 3 is above array bounds
of ‘__le16[1]’ {aka ‘short unsigned int[1]’} [-Warray-bounds]
824 | req->Dialects[3] = cpu_to_le16(SMB311_PROT_ID);
| ~~~~~~~~~~~~~^~~
fs/cifs/smb2pdu.c:816:16: warning: array subscript 1 is above array bounds
of ‘__le16[1]’ {aka ‘short unsigned int[1]’} [-Warray-bounds]
816 | req->Dialects[1] = cpu_to_le16(SMB302_PROT_ID);
| ~~~~~~~~~~~~~^~~
At the time, the size of array _Dialects_ was changed from 1 to 3 in struct
validate_negotiate_info_req, and then in 2019 it was changed from 3 to 4,
but those changes were never made in struct smb2_negotiate_req, which has
led to a 3 and a half years old out-of-bounds bug in function
SMB2_negotiate() (fs/cifs/smb2pdu.c).
Fix this by increasing the size of array _Dialects_ in struct
smb2_negotiate_req to 4.
Fixes: 9764c02fcbad ("SMB3: Add support for multidialect negotiate (SMB2.1 and later)")
Fixes: d5c7076b772a ("smb3: add smb3.1.1 to default dialect list")
Cc: stable@vger.kernel.org
Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org>
Signed-off-by: Steve French <stfrench@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
fs/cifs/smb2pdu.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/fs/cifs/smb2pdu.h
+++ b/fs/cifs/smb2pdu.h
@@ -286,7 +286,7 @@ struct smb2_negotiate_req {
__le32 NegotiateContextOffset; /* SMB3.1.1 only. MBZ earlier */
__le16 NegotiateContextCount; /* SMB3.1.1 only. MBZ earlier */
__le16 Reserved2;
- __le16 Dialects[1]; /* One dialect (vers=) at a time for now */
+ __le16 Dialects[4]; /* BB expand this if autonegotiate > 4 dialects */
} __packed;
/* Dialects */
^ permalink raw reply [flat|nested] 140+ messages in thread* [PATCH 5.10 074/120] smb3: fix crediting for compounding when only one request in flight
2021-02-08 14:59 [PATCH 5.10 000/120] 5.10.15-rc1 review Greg Kroah-Hartman
` (72 preceding siblings ...)
2021-02-08 15:01 ` [PATCH 5.10 073/120] smb3: Fix out-of-bounds bug in SMB2_negotiate() Greg Kroah-Hartman
@ 2021-02-08 15:01 ` Greg Kroah-Hartman
2021-02-08 15:01 ` [PATCH 5.10 075/120] mmc: sdhci-pltfm: Fix linking err for sdhci-brcmstb Greg Kroah-Hartman
` (52 subsequent siblings)
126 siblings, 0 replies; 140+ messages in thread
From: Greg Kroah-Hartman @ 2021-02-08 15:01 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Pavel Shilovsky, Tom Talpey,
Shyam Prasad N, Steve French
From: Pavel Shilovsky <pshilov@microsoft.com>
commit 91792bb8089b63b7b780251eb83939348ac58a64 upstream.
Currently we try to guess if a compound request is going to
succeed waiting for credits or not based on the number of
requests in flight. This approach doesn't work correctly
all the time because there may be only one request in
flight which is going to bring multiple credits satisfying
the compound request.
Change the behavior to fail a request only if there are no requests
in flight at all and proceed waiting for credits otherwise.
Cc: <stable@vger.kernel.org> # 5.1+
Signed-off-by: Pavel Shilovsky <pshilov@microsoft.com>
Reviewed-by: Tom Talpey <tom@talpey.com>
Reviewed-by: Shyam Prasad N <nspmangalore@gmail.com>
Signed-off-by: Steve French <stfrench@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
fs/cifs/transport.c | 18 +++++++++++++++---
1 file changed, 15 insertions(+), 3 deletions(-)
--- a/fs/cifs/transport.c
+++ b/fs/cifs/transport.c
@@ -655,10 +655,22 @@ wait_for_compound_request(struct TCP_Ser
spin_lock(&server->req_lock);
if (*credits < num) {
/*
- * Return immediately if not too many requests in flight since
- * we will likely be stuck on waiting for credits.
+ * If the server is tight on resources or just gives us less
+ * credits for other reasons (e.g. requests are coming out of
+ * order and the server delays granting more credits until it
+ * processes a missing mid) and we exhausted most available
+ * credits there may be situations when we try to send
+ * a compound request but we don't have enough credits. At this
+ * point the client needs to decide if it should wait for
+ * additional credits or fail the request. If at least one
+ * request is in flight there is a high probability that the
+ * server will return enough credits to satisfy this compound
+ * request.
+ *
+ * Return immediately if no requests in flight since we will be
+ * stuck on waiting for credits.
*/
- if (server->in_flight < num - *credits) {
+ if (server->in_flight == 0) {
spin_unlock(&server->req_lock);
return -ENOTSUPP;
}
^ permalink raw reply [flat|nested] 140+ messages in thread* [PATCH 5.10 075/120] mmc: sdhci-pltfm: Fix linking err for sdhci-brcmstb
2021-02-08 14:59 [PATCH 5.10 000/120] 5.10.15-rc1 review Greg Kroah-Hartman
` (73 preceding siblings ...)
2021-02-08 15:01 ` [PATCH 5.10 074/120] smb3: fix crediting for compounding when only one request in flight Greg Kroah-Hartman
@ 2021-02-08 15:01 ` Greg Kroah-Hartman
2021-02-08 15:01 ` [PATCH 5.10 076/120] mmc: core: Limit retries when analyse of SDIO tuples fails Greg Kroah-Hartman
` (51 subsequent siblings)
126 siblings, 0 replies; 140+ messages in thread
From: Greg Kroah-Hartman @ 2021-02-08 15:01 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Arnd Bergmann, Florian Fainelli,
Nicolas Schichan, Ulf Hansson
From: Ulf Hansson <ulf.hansson@linaro.org>
commit d7fb9c24209556478e65211d7a1f056f2d43cceb upstream.
The implementation of sdhci_pltfm_suspend() is only available when
CONFIG_PM_SLEEP is set, which triggers a linking error:
"undefined symbol: sdhci_pltfm_suspend" when building sdhci-brcmstb.c.
Fix this by implementing the missing stubs when CONFIG_PM_SLEEP is unset.
Reported-by: Arnd Bergmann <arnd@arndb.de>
Suggested-by: Florian Fainelli <f.fainelli@gmail.com>
Fixes: 5b191dcba719 ("mmc: sdhci-brcmstb: Fix mmc timeout errors on S5 suspend")
Cc: stable@vger.kernel.org
Tested-By: Nicolas Schichan <nschichan@freeebox.fr>
Acked-by: Arnd Bergmann <arnd@arndb.de>
Acked-by: Florian Fainelli <f.fainelli@gmail.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/mmc/host/sdhci-pltfm.h | 7 ++++++-
1 file changed, 6 insertions(+), 1 deletion(-)
--- a/drivers/mmc/host/sdhci-pltfm.h
+++ b/drivers/mmc/host/sdhci-pltfm.h
@@ -111,8 +111,13 @@ static inline void *sdhci_pltfm_priv(str
return host->private;
}
+extern const struct dev_pm_ops sdhci_pltfm_pmops;
+#ifdef CONFIG_PM_SLEEP
int sdhci_pltfm_suspend(struct device *dev);
int sdhci_pltfm_resume(struct device *dev);
-extern const struct dev_pm_ops sdhci_pltfm_pmops;
+#else
+static inline int sdhci_pltfm_suspend(struct device *dev) { return 0; }
+static inline int sdhci_pltfm_resume(struct device *dev) { return 0; }
+#endif
#endif /* _DRIVERS_MMC_SDHCI_PLTFM_H */
^ permalink raw reply [flat|nested] 140+ messages in thread* [PATCH 5.10 076/120] mmc: core: Limit retries when analyse of SDIO tuples fails
2021-02-08 14:59 [PATCH 5.10 000/120] 5.10.15-rc1 review Greg Kroah-Hartman
` (74 preceding siblings ...)
2021-02-08 15:01 ` [PATCH 5.10 075/120] mmc: sdhci-pltfm: Fix linking err for sdhci-brcmstb Greg Kroah-Hartman
@ 2021-02-08 15:01 ` Greg Kroah-Hartman
2021-02-08 15:01 ` [PATCH 5.10 077/120] Fix unsynchronized access to sev members through svm_register_enc_region Greg Kroah-Hartman
` (50 subsequent siblings)
126 siblings, 0 replies; 140+ messages in thread
From: Greg Kroah-Hartman @ 2021-02-08 15:01 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, Fengnan Chang, Ulf Hansson
From: Fengnan Chang <fengnanchang@gmail.com>
commit f92e04f764b86e55e522988e6f4b6082d19a2721 upstream.
When analysing tuples fails we may loop indefinitely to retry. Let's avoid
this by using a 10s timeout and bail if not completed earlier.
Signed-off-by: Fengnan Chang <fengnanchang@gmail.com>
Cc: stable@vger.kernel.org
Link: https://lore.kernel.org/r/20210123033230.36442-1-fengnanchang@gmail.com
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/mmc/core/sdio_cis.c | 6 ++++++
1 file changed, 6 insertions(+)
--- a/drivers/mmc/core/sdio_cis.c
+++ b/drivers/mmc/core/sdio_cis.c
@@ -20,6 +20,8 @@
#include "sdio_cis.h"
#include "sdio_ops.h"
+#define SDIO_READ_CIS_TIMEOUT_MS (10 * 1000) /* 10s */
+
static int cistpl_vers_1(struct mmc_card *card, struct sdio_func *func,
const unsigned char *buf, unsigned size)
{
@@ -274,6 +276,8 @@ static int sdio_read_cis(struct mmc_card
do {
unsigned char tpl_code, tpl_link;
+ unsigned long timeout = jiffies +
+ msecs_to_jiffies(SDIO_READ_CIS_TIMEOUT_MS);
ret = mmc_io_rw_direct(card, 0, 0, ptr++, 0, &tpl_code);
if (ret)
@@ -326,6 +330,8 @@ static int sdio_read_cis(struct mmc_card
prev = &this->next;
if (ret == -ENOENT) {
+ if (time_after(jiffies, timeout))
+ break;
/* warn about unknown tuples */
pr_warn_ratelimited("%s: queuing unknown"
" CIS tuple 0x%02x (%u bytes)\n",
^ permalink raw reply [flat|nested] 140+ messages in thread* [PATCH 5.10 077/120] Fix unsynchronized access to sev members through svm_register_enc_region
2021-02-08 14:59 [PATCH 5.10 000/120] 5.10.15-rc1 review Greg Kroah-Hartman
` (75 preceding siblings ...)
2021-02-08 15:01 ` [PATCH 5.10 076/120] mmc: core: Limit retries when analyse of SDIO tuples fails Greg Kroah-Hartman
@ 2021-02-08 15:01 ` Greg Kroah-Hartman
2021-02-08 15:01 ` [PATCH 5.10 078/120] drm/dp/mst: Export drm_dp_get_vc_payload_bw() Greg Kroah-Hartman
` (49 subsequent siblings)
126 siblings, 0 replies; 140+ messages in thread
From: Greg Kroah-Hartman @ 2021-02-08 15:01 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Thomas Gleixner, Ingo Molnar,
H. Peter Anvin, Paolo Bonzini, Joerg Roedel, Tom Lendacky,
Brijesh Singh, Sean Christopherson, x86, kvm, Peter Gonda
From: Peter Gonda <pgonda@google.com>
commit 19a23da53932bc8011220bd8c410cb76012de004 upstream.
Grab kvm->lock before pinning memory when registering an encrypted
region; sev_pin_memory() relies on kvm->lock being held to ensure
correctness when checking and updating the number of pinned pages.
Add a lockdep assertion to help prevent future regressions.
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: "H. Peter Anvin" <hpa@zytor.com>
Cc: Paolo Bonzini <pbonzini@redhat.com>
Cc: Joerg Roedel <joro@8bytes.org>
Cc: Tom Lendacky <thomas.lendacky@amd.com>
Cc: Brijesh Singh <brijesh.singh@amd.com>
Cc: Sean Christopherson <seanjc@google.com>
Cc: x86@kernel.org
Cc: kvm@vger.kernel.org
Cc: stable@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Fixes: 1e80fdc09d12 ("KVM: SVM: Pin guest memory when SEV is active")
Signed-off-by: Peter Gonda <pgonda@google.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
V2
- Fix up patch description
- Correct file paths svm.c -> sev.c
- Add unlock of kvm->lock on sev_pin_memory error
V1
- https://lore.kernel.org/kvm/20210126185431.1824530-1-pgonda@google.com/
Message-Id: <20210127161524.2832400-1-pgonda@google.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
---
arch/x86/kvm/svm/sev.c | 17 ++++++++++-------
1 file changed, 10 insertions(+), 7 deletions(-)
--- a/arch/x86/kvm/svm/sev.c
+++ b/arch/x86/kvm/svm/sev.c
@@ -320,6 +320,8 @@ static struct page **sev_pin_memory(stru
unsigned long first, last;
int ret;
+ lockdep_assert_held(&kvm->lock);
+
if (ulen == 0 || uaddr + ulen < uaddr)
return ERR_PTR(-EINVAL);
@@ -1001,12 +1003,20 @@ int svm_register_enc_region(struct kvm *
if (!region)
return -ENOMEM;
+ mutex_lock(&kvm->lock);
region->pages = sev_pin_memory(kvm, range->addr, range->size, ®ion->npages, 1);
if (IS_ERR(region->pages)) {
ret = PTR_ERR(region->pages);
+ mutex_unlock(&kvm->lock);
goto e_free;
}
+ region->uaddr = range->addr;
+ region->size = range->size;
+
+ list_add_tail(®ion->list, &sev->regions_list);
+ mutex_unlock(&kvm->lock);
+
/*
* The guest may change the memory encryption attribute from C=0 -> C=1
* or vice versa for this memory range. Lets make sure caches are
@@ -1015,13 +1025,6 @@ int svm_register_enc_region(struct kvm *
*/
sev_clflush_pages(region->pages, region->npages);
- region->uaddr = range->addr;
- region->size = range->size;
-
- mutex_lock(&kvm->lock);
- list_add_tail(®ion->list, &sev->regions_list);
- mutex_unlock(&kvm->lock);
-
return ret;
e_free:
^ permalink raw reply [flat|nested] 140+ messages in thread* [PATCH 5.10 078/120] drm/dp/mst: Export drm_dp_get_vc_payload_bw()
2021-02-08 14:59 [PATCH 5.10 000/120] 5.10.15-rc1 review Greg Kroah-Hartman
` (76 preceding siblings ...)
2021-02-08 15:01 ` [PATCH 5.10 077/120] Fix unsynchronized access to sev members through svm_register_enc_region Greg Kroah-Hartman
@ 2021-02-08 15:01 ` Greg Kroah-Hartman
2021-02-10 12:25 ` Pavel Machek
2021-02-08 15:01 ` [PATCH 5.10 079/120] drm/i915: Fix the MST PBN divider calculation Greg Kroah-Hartman
` (48 subsequent siblings)
126 siblings, 1 reply; 140+ messages in thread
From: Greg Kroah-Hartman @ 2021-02-08 15:01 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Lyude Paul, Ville Syrjala, dri-devel,
Imre Deak, Jani Nikula
From: Imre Deak <imre.deak@intel.com>
commit 83404d581471775f37f85e5261ec0d09407d8bed upstream.
This function will be needed by the next patch where the driver
calculates the BW based on driver specific parameters, so export it.
At the same time sanitize the function params, passing the more natural
link rate instead of the encoding of the same rate.
v2:
- Fix function documentation. (Lyude)
Cc: Lyude Paul <lyude@redhat.com>
Cc: Ville Syrjala <ville.syrjala@intel.com>
Cc: <stable@vger.kernel.org>
Cc: dri-devel@lists.freedesktop.org
Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Lyude Paul <lyude@redhat.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210125173636.1733812-1-imre.deak@intel.com
(cherry picked from commit a321fc2b4e60fc1b39517d26c8104351636a6062)
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/gpu/drm/drm_dp_mst_topology.c | 24 ++++++++++++++++++------
include/drm/drm_dp_mst_helper.h | 1 +
2 files changed, 19 insertions(+), 6 deletions(-)
--- a/drivers/gpu/drm/drm_dp_mst_topology.c
+++ b/drivers/gpu/drm/drm_dp_mst_topology.c
@@ -3629,14 +3629,26 @@ static int drm_dp_send_up_ack_reply(stru
return 0;
}
-static int drm_dp_get_vc_payload_bw(u8 dp_link_bw, u8 dp_link_count)
+/**
+ * drm_dp_get_vc_payload_bw - get the VC payload BW for an MST link
+ * @link_rate: link rate in 10kbits/s units
+ * @link_lane_count: lane count
+ *
+ * Calculate the total bandwidth of a MultiStream Transport link. The returned
+ * value is in units of PBNs/(timeslots/1 MTP). This value can be used to
+ * convert the number of PBNs required for a given stream to the number of
+ * timeslots this stream requires in each MTP.
+ */
+int drm_dp_get_vc_payload_bw(int link_rate, int link_lane_count)
{
- if (dp_link_bw == 0 || dp_link_count == 0)
- DRM_DEBUG_KMS("invalid link bandwidth in DPCD: %x (link count: %d)\n",
- dp_link_bw, dp_link_count);
+ if (link_rate == 0 || link_lane_count == 0)
+ DRM_DEBUG_KMS("invalid link rate/lane count: (%d / %d)\n",
+ link_rate, link_lane_count);
- return dp_link_bw * dp_link_count / 2;
+ /* See DP v2.0 2.6.4.2, VCPayload_Bandwidth_for_OneTimeSlotPer_MTP_Allocation */
+ return link_rate * link_lane_count / 54000;
}
+EXPORT_SYMBOL(drm_dp_get_vc_payload_bw);
/**
* drm_dp_read_mst_cap() - check whether or not a sink supports MST
@@ -3692,7 +3704,7 @@ int drm_dp_mst_topology_mgr_set_mst(stru
goto out_unlock;
}
- mgr->pbn_div = drm_dp_get_vc_payload_bw(mgr->dpcd[1],
+ mgr->pbn_div = drm_dp_get_vc_payload_bw(drm_dp_bw_code_to_link_rate(mgr->dpcd[1]),
mgr->dpcd[2] & DP_MAX_LANE_COUNT_MASK);
if (mgr->pbn_div == 0) {
ret = -EINVAL;
--- a/include/drm/drm_dp_mst_helper.h
+++ b/include/drm/drm_dp_mst_helper.h
@@ -783,6 +783,7 @@ drm_dp_mst_detect_port(struct drm_connec
struct edid *drm_dp_mst_get_edid(struct drm_connector *connector, struct drm_dp_mst_topology_mgr *mgr, struct drm_dp_mst_port *port);
+int drm_dp_get_vc_payload_bw(int link_rate, int link_lane_count);
int drm_dp_calc_pbn_mode(int clock, int bpp, bool dsc);
^ permalink raw reply [flat|nested] 140+ messages in thread* Re: [PATCH 5.10 078/120] drm/dp/mst: Export drm_dp_get_vc_payload_bw()
2021-02-08 15:01 ` [PATCH 5.10 078/120] drm/dp/mst: Export drm_dp_get_vc_payload_bw() Greg Kroah-Hartman
@ 2021-02-10 12:25 ` Pavel Machek
2021-02-10 12:40 ` Imre Deak
0 siblings, 1 reply; 140+ messages in thread
From: Pavel Machek @ 2021-02-10 12:25 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: linux-kernel, stable, Lyude Paul, Ville Syrjala, dri-devel,
Imre Deak, Jani Nikula
[-- Attachment #1: Type: text/plain, Size: 590 bytes --]
Hi!
> commit 83404d581471775f37f85e5261ec0d09407d8bed upstream.
>
> This function will be needed by the next patch where the driver
> calculates the BW based on driver specific parameters, so export it.
>
> At the same time sanitize the function params, passing the more natural
> link rate instead of the encoding of the same rate.
> Cc: <stable@vger.kernel.org>
This adds exports, but there's no user of the export, neither in
5.10-stable nor in linux-next. What is the plan here?
Best regards,
Pavel
--
http://www.livejournal.com/~pavelmachek
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 bytes --]
^ permalink raw reply [flat|nested] 140+ messages in thread
* Re: [PATCH 5.10 078/120] drm/dp/mst: Export drm_dp_get_vc_payload_bw()
2021-02-10 12:25 ` Pavel Machek
@ 2021-02-10 12:40 ` Imre Deak
0 siblings, 0 replies; 140+ messages in thread
From: Imre Deak @ 2021-02-10 12:40 UTC (permalink / raw)
To: Pavel Machek
Cc: Greg Kroah-Hartman, linux-kernel, stable, Lyude Paul,
Ville Syrjala, dri-devel, Jani Nikula
Hi,
On Wed, Feb 10, 2021 at 01:25:17PM +0100, Pavel Machek wrote:
> Hi!
>
> > commit 83404d581471775f37f85e5261ec0d09407d8bed upstream.
> >
> > This function will be needed by the next patch where the driver
> > calculates the BW based on driver specific parameters, so export it.
> >
> > At the same time sanitize the function params, passing the more natural
> > link rate instead of the encoding of the same rate.
>
> > Cc: <stable@vger.kernel.org>
>
> This adds exports, but there's no user of the export, neither in
> 5.10-stable nor in linux-next. What is the plan here?
the export is used by the upstream
commit 882554042d138dbc6fb1a43017d0b9c3b38ee5f5
Author: Imre Deak <imre.deak@intel.com>
Date: Mon Jan 25 19:36:36 2021 +0200
drm/i915: Fix the MST PBN divider calculation
which I can also see now applied to 5.10.15:
commit 0fe98e455784a6c11e0dd48612acd343f4a46fce
Author: Imre Deak <imre.deak@intel.com>
AuthorDate: Mon Jan 25 19:36:36 2021 +0200
Commit: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
CommitDate: Wed Feb 10 09:29:18 2021 +0100
drm/i915: Fix the MST PBN divider calculation
commit 882554042d138dbc6fb1a43017d0b9c3b38ee5f5 upstream.
--Imre
^ permalink raw reply [flat|nested] 140+ messages in thread
* [PATCH 5.10 079/120] drm/i915: Fix the MST PBN divider calculation
2021-02-08 14:59 [PATCH 5.10 000/120] 5.10.15-rc1 review Greg Kroah-Hartman
` (77 preceding siblings ...)
2021-02-08 15:01 ` [PATCH 5.10 078/120] drm/dp/mst: Export drm_dp_get_vc_payload_bw() Greg Kroah-Hartman
@ 2021-02-08 15:01 ` Greg Kroah-Hartman
2021-02-08 15:01 ` [PATCH 5.10 080/120] drm/i915/gem: Drop lru bumping on display unpinning Greg Kroah-Hartman
` (47 subsequent siblings)
126 siblings, 0 replies; 140+ messages in thread
From: Greg Kroah-Hartman @ 2021-02-08 15:01 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Lyude Paul, Ville Syrjala, Imre Deak,
Jani Nikula
From: Imre Deak <imre.deak@intel.com>
commit 882554042d138dbc6fb1a43017d0b9c3b38ee5f5 upstream.
Atm the driver will calculate a wrong MST timeslots/MTP (aka time unit)
value for MST streams if the link parameters (link rate or lane count)
are limited in a way independent of the sink capabilities (reported by
DPCD).
One example of such a limitation is when a MUX between the sink and
source connects only a limited number of lanes to the display and
connects the rest of the lanes to other peripherals (USB).
Another issue is that atm MST core calculates the divider based on the
backwards compatible DPCD (at address 0x0000) vs. the extended
capability info (at address 0x2200). This can result in leaving some
part of the MST BW unused (For instance in case of the WD19TB dock).
Fix the above two issues by calculating the PBN divider value based on
the rate and lane count link parameters that the driver uses for all
other computation.
Bugzilla: https://gitlab.freedesktop.org/drm/intel/-/issues/2977
Cc: Lyude Paul <lyude@redhat.com>
Cc: Ville Syrjala <ville.syrjala@intel.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Ville Syrjala <ville.syrjala@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210125173636.1733812-2-imre.deak@intel.com
(cherry picked from commit b59c27cab257cfbff939615a87b72bce83925710)
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/gpu/drm/i915/display/intel_dp_mst.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
--- a/drivers/gpu/drm/i915/display/intel_dp_mst.c
+++ b/drivers/gpu/drm/i915/display/intel_dp_mst.c
@@ -68,7 +68,9 @@ static int intel_dp_mst_compute_link_con
slots = drm_dp_atomic_find_vcpi_slots(state, &intel_dp->mst_mgr,
connector->port,
- crtc_state->pbn, 0);
+ crtc_state->pbn,
+ drm_dp_get_vc_payload_bw(crtc_state->port_clock,
+ crtc_state->lane_count));
if (slots == -EDEADLK)
return slots;
if (slots >= 0)
^ permalink raw reply [flat|nested] 140+ messages in thread* [PATCH 5.10 080/120] drm/i915/gem: Drop lru bumping on display unpinning
2021-02-08 14:59 [PATCH 5.10 000/120] 5.10.15-rc1 review Greg Kroah-Hartman
` (78 preceding siblings ...)
2021-02-08 15:01 ` [PATCH 5.10 079/120] drm/i915: Fix the MST PBN divider calculation Greg Kroah-Hartman
@ 2021-02-08 15:01 ` Greg Kroah-Hartman
2021-02-08 15:01 ` [PATCH 5.10 081/120] drm/i915/gt: Close race between enable_breadcrumbs and cancel_breadcrumbs Greg Kroah-Hartman
` (46 subsequent siblings)
126 siblings, 0 replies; 140+ messages in thread
From: Greg Kroah-Hartman @ 2021-02-08 15:01 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Chris Wilson, Matthew Auld,
Joonas Lahtinen, Jani Nikula, Matti Hämäläinen
From: Chris Wilson <chris@chris-wilson.co.uk>
commit 761c70a52586a9214b29026d384d2c01b73661a8 upstream.
Simplify the frontbuffer unpin by removing the lock requirement. The LRU
bumping was primarily to protect the GTT from being evicted and from
frontbuffers being eagerly shrunk. Now we protect frontbuffers from the
shrinker, and we avoid accidentally evicting from the GTT, so the
benefit from bumping LRU is no more, and we can save more time by not.
Reported-and-tested-by: Matti Hämäläinen <ccr@tnsp.org>
Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/2905
Fixes: c1793ba86a41 ("drm/i915: Add ww locking to pin_to_display_plane, v2.")
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Matthew Auld <matthew.auld@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210119214336.1463-6-chris@chris-wilson.co.uk
(cherry picked from commit 14ca83eece9565a2d2177291ceb122982dc38420)
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Cc: Jani Nikula <jani.nikula@intel.com>
Cc: <stable@vger.kernel.org> # v5.10+
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/gpu/drm/i915/display/intel_display.c | 7 +---
drivers/gpu/drm/i915/display/intel_overlay.c | 4 +-
drivers/gpu/drm/i915/gem/i915_gem_domain.c | 45 ---------------------------
drivers/gpu/drm/i915/gem/i915_gem_object.h | 1
4 files changed, 4 insertions(+), 53 deletions(-)
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -2294,7 +2294,7 @@ intel_pin_and_fence_fb_obj(struct drm_fr
*/
ret = i915_vma_pin_fence(vma);
if (ret != 0 && INTEL_GEN(dev_priv) < 4) {
- i915_gem_object_unpin_from_display_plane(vma);
+ i915_vma_unpin(vma);
vma = ERR_PTR(ret);
goto err;
}
@@ -2312,12 +2312,9 @@ err:
void intel_unpin_fb_vma(struct i915_vma *vma, unsigned long flags)
{
- i915_gem_object_lock(vma->obj, NULL);
if (flags & PLANE_HAS_FENCE)
i915_vma_unpin_fence(vma);
- i915_gem_object_unpin_from_display_plane(vma);
- i915_gem_object_unlock(vma->obj);
-
+ i915_vma_unpin(vma);
i915_vma_put(vma);
}
--- a/drivers/gpu/drm/i915/display/intel_overlay.c
+++ b/drivers/gpu/drm/i915/display/intel_overlay.c
@@ -359,7 +359,7 @@ static void intel_overlay_release_old_vm
intel_frontbuffer_flip_complete(overlay->i915,
INTEL_FRONTBUFFER_OVERLAY(overlay->crtc->pipe));
- i915_gem_object_unpin_from_display_plane(vma);
+ i915_vma_unpin(vma);
i915_vma_put(vma);
}
@@ -860,7 +860,7 @@ static int intel_overlay_do_put_image(st
return 0;
out_unpin:
- i915_gem_object_unpin_from_display_plane(vma);
+ i915_vma_unpin(vma);
out_pin_section:
atomic_dec(&dev_priv->gpu_error.pending_fb_pin);
--- a/drivers/gpu/drm/i915/gem/i915_gem_domain.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_domain.c
@@ -387,48 +387,6 @@ err:
return vma;
}
-static void i915_gem_object_bump_inactive_ggtt(struct drm_i915_gem_object *obj)
-{
- struct drm_i915_private *i915 = to_i915(obj->base.dev);
- struct i915_vma *vma;
-
- if (list_empty(&obj->vma.list))
- return;
-
- mutex_lock(&i915->ggtt.vm.mutex);
- spin_lock(&obj->vma.lock);
- for_each_ggtt_vma(vma, obj) {
- if (!drm_mm_node_allocated(&vma->node))
- continue;
-
- GEM_BUG_ON(vma->vm != &i915->ggtt.vm);
- list_move_tail(&vma->vm_link, &vma->vm->bound_list);
- }
- spin_unlock(&obj->vma.lock);
- mutex_unlock(&i915->ggtt.vm.mutex);
-
- if (i915_gem_object_is_shrinkable(obj)) {
- unsigned long flags;
-
- spin_lock_irqsave(&i915->mm.obj_lock, flags);
-
- if (obj->mm.madv == I915_MADV_WILLNEED &&
- !atomic_read(&obj->mm.shrink_pin))
- list_move_tail(&obj->mm.link, &i915->mm.shrink_list);
-
- spin_unlock_irqrestore(&i915->mm.obj_lock, flags);
- }
-}
-
-void
-i915_gem_object_unpin_from_display_plane(struct i915_vma *vma)
-{
- /* Bump the LRU to try and avoid premature eviction whilst flipping */
- i915_gem_object_bump_inactive_ggtt(vma->obj);
-
- i915_vma_unpin(vma);
-}
-
/**
* Moves a single object to the CPU read, and possibly write domain.
* @obj: object to act on
@@ -569,9 +527,6 @@ i915_gem_set_domain_ioctl(struct drm_dev
else
err = i915_gem_object_set_to_cpu_domain(obj, write_domain);
- /* And bump the LRU for this access */
- i915_gem_object_bump_inactive_ggtt(obj);
-
i915_gem_object_unlock(obj);
if (write_domain)
--- a/drivers/gpu/drm/i915/gem/i915_gem_object.h
+++ b/drivers/gpu/drm/i915/gem/i915_gem_object.h
@@ -471,7 +471,6 @@ i915_gem_object_pin_to_display_plane(str
u32 alignment,
const struct i915_ggtt_view *view,
unsigned int flags);
-void i915_gem_object_unpin_from_display_plane(struct i915_vma *vma);
void i915_gem_object_make_unshrinkable(struct drm_i915_gem_object *obj);
void i915_gem_object_make_shrinkable(struct drm_i915_gem_object *obj);
^ permalink raw reply [flat|nested] 140+ messages in thread* [PATCH 5.10 081/120] drm/i915/gt: Close race between enable_breadcrumbs and cancel_breadcrumbs
2021-02-08 14:59 [PATCH 5.10 000/120] 5.10.15-rc1 review Greg Kroah-Hartman
` (79 preceding siblings ...)
2021-02-08 15:01 ` [PATCH 5.10 080/120] drm/i915/gem: Drop lru bumping on display unpinning Greg Kroah-Hartman
@ 2021-02-08 15:01 ` Greg Kroah-Hartman
2021-02-08 15:01 ` [PATCH 5.10 082/120] drm/i915/display: Prevent double YUV range correction on HDR planes Greg Kroah-Hartman
` (45 subsequent siblings)
126 siblings, 0 replies; 140+ messages in thread
From: Greg Kroah-Hartman @ 2021-02-08 15:01 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Chris Wilson, Tvrtko Ursulin,
Andi Shyti, Jani Nikula
From: Chris Wilson <chris@chris-wilson.co.uk>
commit e4747cb3ec3c232d65c84cbe77633abd5871fda3 upstream.
If we enable_breadcrumbs for a request while that request is being
removed from HW; we may see that the request is active as we take the
ce->signal_lock and proceed to attach the request to ce->signals.
However, during unsubmission after marking the request as inactive, we
see that the request has not yet been added to ce->signals and so skip
the removal. Pull the check during cancel_breadcrumbs under the same
spinlock as enabling so that we the two tests are consistent in
enable/cancel.
Otherwise, we may insert a request onto ce->signals that we expect should
not be there:
intel_context_remove_breadcrumbs:488 GEM_BUG_ON(!__i915_request_is_complete(rq))
While updating, we can note that we are always called with
irqs-disabled, due to the engine->active.lock being held at the single
caller, and so remove the irqsave/restore making it symmetric to
enable_breadcrumbs.
Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/2931
Fixes: c18636f76344 ("drm/i915: Remove requirement for holding i915_request.lock for breadcrumbs")
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Cc: Andi Shyti <andi.shyti@intel.com>
Cc: <stable@vger.kernel.org> # v5.10+
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210119162057.31097-1-chris@chris-wilson.co.uk
(cherry picked from commit e7004ea4f5f528f5a5018f0b70cab36d25315498)
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/gpu/drm/i915/gt/intel_breadcrumbs.c | 6 ++++--
1 file changed, 4 insertions(+), 2 deletions(-)
--- a/drivers/gpu/drm/i915/gt/intel_breadcrumbs.c
+++ b/drivers/gpu/drm/i915/gt/intel_breadcrumbs.c
@@ -451,10 +451,12 @@ void i915_request_cancel_breadcrumb(stru
struct intel_context *ce = rq->context;
bool release;
- if (!test_and_clear_bit(I915_FENCE_FLAG_SIGNAL, &rq->fence.flags))
+ spin_lock(&ce->signal_lock);
+ if (!test_and_clear_bit(I915_FENCE_FLAG_SIGNAL, &rq->fence.flags)) {
+ spin_unlock(&ce->signal_lock);
return;
+ }
- spin_lock(&ce->signal_lock);
list_del_rcu(&rq->signal_link);
release = remove_signaling_context(rq->engine->breadcrumbs, ce);
spin_unlock(&ce->signal_lock);
^ permalink raw reply [flat|nested] 140+ messages in thread* [PATCH 5.10 082/120] drm/i915/display: Prevent double YUV range correction on HDR planes
2021-02-08 14:59 [PATCH 5.10 000/120] 5.10.15-rc1 review Greg Kroah-Hartman
` (80 preceding siblings ...)
2021-02-08 15:01 ` [PATCH 5.10 081/120] drm/i915/gt: Close race between enable_breadcrumbs and cancel_breadcrumbs Greg Kroah-Hartman
@ 2021-02-08 15:01 ` Greg Kroah-Hartman
2021-02-08 15:01 ` [PATCH 5.10 083/120] drm/i915: Extract intel_ddi_power_up_lanes() Greg Kroah-Hartman
` (44 subsequent siblings)
126 siblings, 0 replies; 140+ messages in thread
From: Greg Kroah-Hartman @ 2021-02-08 15:01 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Andres Calderon Jaramillo,
Ville Syrjälä,
Jani Nikula
From: Andres Calderon Jaramillo <andrescj@chromium.org>
commit 00f9a08fbc3c703b71842a5425c1eb82053c8a70 upstream.
Prevent the ICL HDR plane pipeline from performing YUV color range
correction twice when the input is in limited range. This is done by
removing the limited-range code from icl_program_input_csc().
Before this patch the following could happen: user space gives us a YUV
buffer in limited range; per the pipeline in [1], the plane would first
go through a "YUV Range correct" stage that expands the range; the plane
would then go through the "Input CSC" stage which would also expand the
range because icl_program_input_csc() would use a matrix and an offset
that assume limited-range input; this would ultimately cause dark and
light colors to appear darker and lighter than they should respectively.
This is an issue because if a buffer switches between being scanned out
and being composited with the GPU, the user will see a color difference.
If this switching happens quickly and frequently, the user will perceive
this as a flickering.
[1] https://01.org/sites/default/files/documentation/intel-gfx-prm-osrc-icllp-vol12-displayengine_0.pdf#page=281
Cc: stable@vger.kernel.org
Signed-off-by: Andres Calderon Jaramillo <andrescj@chromium.org>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20201215224219.3896256-1-andrescj@google.com
(cherry picked from commit fed387572040e84ead53852a7820e30a30e515d0)
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210202084553.30691-1-ville.syrjala@linux.intel.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/gpu/drm/i915/display/intel_display.c | 2
drivers/gpu/drm/i915/display/intel_sprite.c | 65 ++++-----------------------
2 files changed, 12 insertions(+), 55 deletions(-)
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -4880,6 +4880,8 @@ u32 glk_plane_color_ctl(const struct int
plane_color_ctl |= PLANE_COLOR_YUV_RANGE_CORRECTION_DISABLE;
} else if (fb->format->is_yuv) {
plane_color_ctl |= PLANE_COLOR_INPUT_CSC_ENABLE;
+ if (plane_state->hw.color_range == DRM_COLOR_YCBCR_FULL_RANGE)
+ plane_color_ctl |= PLANE_COLOR_YUV_RANGE_CORRECTION_DISABLE;
}
return plane_color_ctl;
--- a/drivers/gpu/drm/i915/display/intel_sprite.c
+++ b/drivers/gpu/drm/i915/display/intel_sprite.c
@@ -469,13 +469,19 @@ skl_program_scaler(struct intel_plane *p
/* Preoffset values for YUV to RGB Conversion */
#define PREOFF_YUV_TO_RGB_HI 0x1800
-#define PREOFF_YUV_TO_RGB_ME 0x1F00
+#define PREOFF_YUV_TO_RGB_ME 0x0000
#define PREOFF_YUV_TO_RGB_LO 0x1800
#define ROFF(x) (((x) & 0xffff) << 16)
#define GOFF(x) (((x) & 0xffff) << 0)
#define BOFF(x) (((x) & 0xffff) << 16)
+/*
+ * Programs the input color space conversion stage for ICL HDR planes.
+ * Note that it is assumed that this stage always happens after YUV
+ * range correction. Thus, the input to this stage is assumed to be
+ * in full-range YCbCr.
+ */
static void
icl_program_input_csc(struct intel_plane *plane,
const struct intel_crtc_state *crtc_state,
@@ -523,52 +529,7 @@ icl_program_input_csc(struct intel_plane
0x0, 0x7800, 0x7F10,
},
};
-
- /* Matrix for Limited Range to Full Range Conversion */
- static const u16 input_csc_matrix_lr[][9] = {
- /*
- * BT.601 Limted range YCbCr -> full range RGB
- * The matrix required is :
- * [1.164384, 0.000, 1.596027,
- * 1.164384, -0.39175, -0.812813,
- * 1.164384, 2.017232, 0.0000]
- */
- [DRM_COLOR_YCBCR_BT601] = {
- 0x7CC8, 0x7950, 0x0,
- 0x8D00, 0x7950, 0x9C88,
- 0x0, 0x7950, 0x6810,
- },
- /*
- * BT.709 Limited range YCbCr -> full range RGB
- * The matrix required is :
- * [1.164384, 0.000, 1.792741,
- * 1.164384, -0.213249, -0.532909,
- * 1.164384, 2.112402, 0.0000]
- */
- [DRM_COLOR_YCBCR_BT709] = {
- 0x7E58, 0x7950, 0x0,
- 0x8888, 0x7950, 0xADA8,
- 0x0, 0x7950, 0x6870,
- },
- /*
- * BT.2020 Limited range YCbCr -> full range RGB
- * The matrix required is :
- * [1.164, 0.000, 1.678,
- * 1.164, -0.1873, -0.6504,
- * 1.164, 2.1417, 0.0000]
- */
- [DRM_COLOR_YCBCR_BT2020] = {
- 0x7D70, 0x7950, 0x0,
- 0x8A68, 0x7950, 0xAC00,
- 0x0, 0x7950, 0x6890,
- },
- };
- const u16 *csc;
-
- if (plane_state->hw.color_range == DRM_COLOR_YCBCR_FULL_RANGE)
- csc = input_csc_matrix[plane_state->hw.color_encoding];
- else
- csc = input_csc_matrix_lr[plane_state->hw.color_encoding];
+ const u16 *csc = input_csc_matrix[plane_state->hw.color_encoding];
intel_de_write_fw(dev_priv, PLANE_INPUT_CSC_COEFF(pipe, plane_id, 0),
ROFF(csc[0]) | GOFF(csc[1]));
@@ -585,14 +546,8 @@ icl_program_input_csc(struct intel_plane
intel_de_write_fw(dev_priv, PLANE_INPUT_CSC_PREOFF(pipe, plane_id, 0),
PREOFF_YUV_TO_RGB_HI);
- if (plane_state->hw.color_range == DRM_COLOR_YCBCR_FULL_RANGE)
- intel_de_write_fw(dev_priv,
- PLANE_INPUT_CSC_PREOFF(pipe, plane_id, 1),
- 0);
- else
- intel_de_write_fw(dev_priv,
- PLANE_INPUT_CSC_PREOFF(pipe, plane_id, 1),
- PREOFF_YUV_TO_RGB_ME);
+ intel_de_write_fw(dev_priv, PLANE_INPUT_CSC_PREOFF(pipe, plane_id, 1),
+ PREOFF_YUV_TO_RGB_ME);
intel_de_write_fw(dev_priv, PLANE_INPUT_CSC_PREOFF(pipe, plane_id, 2),
PREOFF_YUV_TO_RGB_LO);
intel_de_write_fw(dev_priv,
^ permalink raw reply [flat|nested] 140+ messages in thread* [PATCH 5.10 083/120] drm/i915: Extract intel_ddi_power_up_lanes()
2021-02-08 14:59 [PATCH 5.10 000/120] 5.10.15-rc1 review Greg Kroah-Hartman
` (81 preceding siblings ...)
2021-02-08 15:01 ` [PATCH 5.10 082/120] drm/i915/display: Prevent double YUV range correction on HDR planes Greg Kroah-Hartman
@ 2021-02-08 15:01 ` Greg Kroah-Hartman
2021-02-08 15:01 ` [PATCH 5.10 084/120] drm/i915: Power up combo PHY lanes for for HDMI as well Greg Kroah-Hartman
` (43 subsequent siblings)
126 siblings, 0 replies; 140+ messages in thread
From: Greg Kroah-Hartman @ 2021-02-08 15:01 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Ville Syrjälä,
Imre Deak, Jani Nikula
From: Ville Syrjälä <ville.syrjala@linux.intel.com>
commit 425cbd1fce10d4d68188123404d1a302a6939e0a upstream.
Reduce the copypasta by pulling the combo PHY lane
power up stuff into a helper. We'll have a third user soon.
Cc: stable@vger.kernel.org
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210128155948.13678-2-ville.syrjala@linux.intel.com
Reviewed-by: Imre Deak <imre.deak@intel.com>
(cherry picked from commit 5cdf706fb91a6e4e6af799bb957c4d598e6a067b)
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/gpu/drm/i915/display/intel_ddi.c | 35 ++++++++++++++++---------------
1 file changed, 19 insertions(+), 16 deletions(-)
--- a/drivers/gpu/drm/i915/display/intel_ddi.c
+++ b/drivers/gpu/drm/i915/display/intel_ddi.c
@@ -3274,6 +3274,23 @@ static void intel_ddi_disable_fec_state(
intel_de_posting_read(dev_priv, intel_dp->regs.dp_tp_ctl);
}
+static void intel_ddi_power_up_lanes(struct intel_encoder *encoder,
+ const struct intel_crtc_state *crtc_state)
+{
+ struct drm_i915_private *i915 = to_i915(encoder->base.dev);
+ struct intel_digital_port *dig_port = enc_to_dig_port(encoder);
+ enum phy phy = intel_port_to_phy(i915, encoder->port);
+
+ if (intel_phy_is_combo(i915, phy)) {
+ bool lane_reversal =
+ dig_port->saved_port_bits & DDI_BUF_PORT_REVERSAL;
+
+ intel_combo_phy_power_up_lanes(i915, phy, false,
+ crtc_state->lane_count,
+ lane_reversal);
+ }
+}
+
static void tgl_ddi_pre_enable_dp(struct intel_atomic_state *state,
struct intel_encoder *encoder,
const struct intel_crtc_state *crtc_state,
@@ -3367,14 +3384,7 @@ static void tgl_ddi_pre_enable_dp(struct
* 7.f Combo PHY: Configure PORT_CL_DW10 Static Power Down to power up
* the used lanes of the DDI.
*/
- if (intel_phy_is_combo(dev_priv, phy)) {
- bool lane_reversal =
- dig_port->saved_port_bits & DDI_BUF_PORT_REVERSAL;
-
- intel_combo_phy_power_up_lanes(dev_priv, phy, false,
- crtc_state->lane_count,
- lane_reversal);
- }
+ intel_ddi_power_up_lanes(encoder, crtc_state);
/*
* 7.g Configure and enable DDI_BUF_CTL
@@ -3458,14 +3468,7 @@ static void hsw_ddi_pre_enable_dp(struct
else
intel_prepare_dp_ddi_buffers(encoder, crtc_state);
- if (intel_phy_is_combo(dev_priv, phy)) {
- bool lane_reversal =
- dig_port->saved_port_bits & DDI_BUF_PORT_REVERSAL;
-
- intel_combo_phy_power_up_lanes(dev_priv, phy, false,
- crtc_state->lane_count,
- lane_reversal);
- }
+ intel_ddi_power_up_lanes(encoder, crtc_state);
intel_ddi_init_dp_buf_reg(encoder);
if (!is_mst)
^ permalink raw reply [flat|nested] 140+ messages in thread* [PATCH 5.10 084/120] drm/i915: Power up combo PHY lanes for for HDMI as well
2021-02-08 14:59 [PATCH 5.10 000/120] 5.10.15-rc1 review Greg Kroah-Hartman
` (82 preceding siblings ...)
2021-02-08 15:01 ` [PATCH 5.10 083/120] drm/i915: Extract intel_ddi_power_up_lanes() Greg Kroah-Hartman
@ 2021-02-08 15:01 ` Greg Kroah-Hartman
2021-02-08 15:01 ` [PATCH 5.10 085/120] drm/amd/display: Revert "Fix EDID parsing after resume from suspend" Greg Kroah-Hartman
` (42 subsequent siblings)
126 siblings, 0 replies; 140+ messages in thread
From: Greg Kroah-Hartman @ 2021-02-08 15:01 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Ville Syrjälä,
Imre Deak, Jani Nikula
From: Ville Syrjälä <ville.syrjala@linux.intel.com>
commit fad9bae9ee5d578afbe6380c82e4715efaddf118 upstream.
Currently we only explicitly power up the combo PHY lanes
for DP. The spec says we should do it for HDMI as well.
Cc: stable@vger.kernel.org
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210128155948.13678-3-ville.syrjala@linux.intel.com
Reviewed-by: Imre Deak <imre.deak@intel.com>
(cherry picked from commit 1e0cb7bef35f0d1aed383bf69a209df218b807c9)
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/gpu/drm/i915/display/intel_ddi.c | 2 ++
1 file changed, 2 insertions(+)
--- a/drivers/gpu/drm/i915/display/intel_ddi.c
+++ b/drivers/gpu/drm/i915/display/intel_ddi.c
@@ -3936,6 +3936,8 @@ static void intel_enable_ddi_hdmi(struct
intel_de_write(dev_priv, reg, val);
}
+ intel_ddi_power_up_lanes(encoder, crtc_state);
+
/* In HDMI/DVI mode, the port width, and swing/emphasis values
* are ignored so nothing special needs to be done besides
* enabling the port.
^ permalink raw reply [flat|nested] 140+ messages in thread* [PATCH 5.10 085/120] drm/amd/display: Revert "Fix EDID parsing after resume from suspend"
2021-02-08 14:59 [PATCH 5.10 000/120] 5.10.15-rc1 review Greg Kroah-Hartman
` (83 preceding siblings ...)
2021-02-08 15:01 ` [PATCH 5.10 084/120] drm/i915: Power up combo PHY lanes for for HDMI as well Greg Kroah-Hartman
@ 2021-02-08 15:01 ` Greg Kroah-Hartman
2021-02-08 15:01 ` [PATCH 5.10 086/120] io_uring: dont modify identitys files uncess identity is cowed Greg Kroah-Hartman
` (41 subsequent siblings)
126 siblings, 0 replies; 140+ messages in thread
From: Greg Kroah-Hartman @ 2021-02-08 15:01 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Stylon Wang, Rodrigo Siqueira,
Anson Jacob, Daniel Wheeler, Alex Deucher
From: Stylon Wang <stylon.wang@amd.com>
commit 1a10e5244778169a5a53a527d7830cf0438132a1 upstream.
This reverts commit b24bdc37d03a0478189e20a50286092840f414fa.
It caused memory leak after S3 on 4K HDMI displays.
Signed-off-by: Stylon Wang <stylon.wang@amd.com>
Reviewed-by: Rodrigo Siqueira <Rodrigo.Siqueira@amd.com>
Acked-by: Anson Jacob <Anson.Jacob@amd.com>
Tested-by: Daniel Wheeler <daniel.wheeler@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 2 --
1 file changed, 2 deletions(-)
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
@@ -2278,8 +2278,6 @@ void amdgpu_dm_update_connector_after_de
drm_connector_update_edid_property(connector,
aconnector->edid);
- drm_add_edid_modes(connector, aconnector->edid);
-
if (aconnector->dc_link->aux_mode)
drm_dp_cec_set_edid(&aconnector->dm_dp_aux.aux,
aconnector->edid);
^ permalink raw reply [flat|nested] 140+ messages in thread* [PATCH 5.10 086/120] io_uring: dont modify identitys files uncess identity is cowed
2021-02-08 14:59 [PATCH 5.10 000/120] 5.10.15-rc1 review Greg Kroah-Hartman
` (84 preceding siblings ...)
2021-02-08 15:01 ` [PATCH 5.10 085/120] drm/amd/display: Revert "Fix EDID parsing after resume from suspend" Greg Kroah-Hartman
@ 2021-02-08 15:01 ` Greg Kroah-Hartman
2021-02-08 15:01 ` [PATCH 5.10 087/120] nvme-pci: avoid the deepest sleep state on Kingston A2000 SSDs Greg Kroah-Hartman
` (40 subsequent siblings)
126 siblings, 0 replies; 140+ messages in thread
From: Greg Kroah-Hartman @ 2021-02-08 15:01 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Abaci Robot, Xiaoguang Wang,
Pavel Begunkov, Jens Axboe
From: Xiaoguang Wang <xiaoguang.wang@linux.alibaba.com>
commit d7e10d47691d1702db1cd1edcc689d3031eefc67 upstream.
Abaci Robot reported following panic:
BUG: kernel NULL pointer dereference, address: 0000000000000000
PGD 800000010ef3f067 P4D 800000010ef3f067 PUD 10d9df067 PMD 0
Oops: 0002 [#1] SMP PTI
CPU: 0 PID: 1869 Comm: io_wqe_worker-0 Not tainted 5.11.0-rc3+ #1
Hardware name: Red Hat KVM, BIOS 0.5.1 01/01/2011
RIP: 0010:put_files_struct+0x1b/0x120
Code: 24 18 c7 00 f4 ff ff ff e9 4d fd ff ff 66 90 0f 1f 44 00 00 41 57 41 56 49 89 fe 41 55 41 54 55 53 48 83 ec 08 e8 b5 6b db ff 41 ff 0e 74 13 48 83 c4 08 5b 5d 41 5c 41 5d 41 5e 41 5f e9 9c
RSP: 0000:ffffc90002147d48 EFLAGS: 00010293
RAX: 0000000000000000 RBX: ffff88810d9a5300 RCX: 0000000000000000
RDX: ffff88810d87c280 RSI: ffffffff8144ba6b RDI: 0000000000000000
RBP: 0000000000000080 R08: 0000000000000001 R09: ffffffff81431500
R10: ffff8881001be000 R11: 0000000000000000 R12: ffff88810ac2f800
R13: ffff88810af38a00 R14: 0000000000000000 R15: ffff8881057130c0
FS: 0000000000000000(0000) GS:ffff88813bc00000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000000000000000 CR3: 000000010dbaa002 CR4: 00000000003706f0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
Call Trace:
__io_clean_op+0x10c/0x2a0
io_dismantle_req+0x3c7/0x600
__io_free_req+0x34/0x280
io_put_req+0x63/0xb0
io_worker_handle_work+0x60e/0x830
? io_wqe_worker+0x135/0x520
io_wqe_worker+0x158/0x520
? __kthread_parkme+0x96/0xc0
? io_worker_handle_work+0x830/0x830
kthread+0x134/0x180
? kthread_create_worker_on_cpu+0x90/0x90
ret_from_fork+0x1f/0x30
Modules linked in:
CR2: 0000000000000000
---[ end trace c358ca86af95b1e7 ]---
I guess case below can trigger above panic: there're two threads which
operates different io_uring ctxs and share same sqthread identity, and
later one thread exits, io_uring_cancel_task_requests() will clear
task->io_uring->identity->files to be NULL in sqpoll mode, then another
ctx that uses same identity will panic.
Indeed we don't need to clear task->io_uring->identity->files here,
io_grab_identity() should handle identity->files changes well, if
task->io_uring->identity->files is not equal to current->files,
io_cow_identity() should handle this changes well.
Cc: stable@vger.kernel.org # 5.5+
Reported-by: Abaci Robot <abaci@linux.alibaba.com>
Signed-off-by: Xiaoguang Wang <xiaoguang.wang@linux.alibaba.com>
Reviewed-by: Pavel Begunkov <asml.silence@gmail.com>
Signed-off-by: Jens Axboe <axboe@kernel.dk>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
fs/io_uring.c | 6 ------
1 file changed, 6 deletions(-)
--- a/fs/io_uring.c
+++ b/fs/io_uring.c
@@ -8782,12 +8782,6 @@ static void io_uring_cancel_task_request
if ((ctx->flags & IORING_SETUP_SQPOLL) && ctx->sq_data) {
atomic_dec(&task->io_uring->in_idle);
- /*
- * If the files that are going away are the ones in the thread
- * identity, clear them out.
- */
- if (task->io_uring->identity->files == files)
- task->io_uring->identity->files = NULL;
io_sq_thread_unpark(ctx->sq_data);
}
}
^ permalink raw reply [flat|nested] 140+ messages in thread* [PATCH 5.10 087/120] nvme-pci: avoid the deepest sleep state on Kingston A2000 SSDs
2021-02-08 14:59 [PATCH 5.10 000/120] 5.10.15-rc1 review Greg Kroah-Hartman
` (85 preceding siblings ...)
2021-02-08 15:01 ` [PATCH 5.10 086/120] io_uring: dont modify identitys files uncess identity is cowed Greg Kroah-Hartman
@ 2021-02-08 15:01 ` Greg Kroah-Hartman
2021-02-08 15:01 ` [PATCH 5.10 088/120] KVM: SVM: Treat SVM as unsupported when running as an SEV guest Greg Kroah-Hartman
` (39 subsequent siblings)
126 siblings, 0 replies; 140+ messages in thread
From: Greg Kroah-Hartman @ 2021-02-08 15:01 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Thorsten Leemhuis, Christoph Hellwig
From: Thorsten Leemhuis <linux@leemhuis.info>
commit 538e4a8c571efdf131834431e0c14808bcfb1004 upstream.
Some Kingston A2000 NVMe SSDs sooner or later get confused and stop
working when they use the deepest APST sleep while running Linux. The
system then crashes and one has to cold boot it to get the SSD working
again.
Kingston seems to known about this since at least mid-September 2020:
https://bbs.archlinux.org/viewtopic.php?pid=1926994#p1926994
Someone working for a German company representing Kingston to the German
press confirmed to me Kingston engineering is aware of the issue and
investigating; the person stated that to their current knowledge only
the deepest APST sleep state causes trouble. Therefore, make Linux avoid
it for now by applying the NVME_QUIRK_NO_DEEPEST_PS to this SSD.
I have two such SSDs, but it seems the problem doesn't occur with them.
I hence couldn't verify if this patch really fixes the problem, but all
the data in front of me suggests it should.
This patch can easily be reverted or improved upon if a better solution
surfaces.
FWIW, there are many reports about the issue scattered around the web;
most of the users disabled APST completely to make things work, some
just made Linux avoid the deepest sleep state:
https://bugzilla.kernel.org/show_bug.cgi?id=195039#c65
https://bugzilla.kernel.org/show_bug.cgi?id=195039#c73
https://bugzilla.kernel.org/show_bug.cgi?id=195039#c74
https://bugzilla.kernel.org/show_bug.cgi?id=195039#c78
https://bugzilla.kernel.org/show_bug.cgi?id=195039#c79
https://bugzilla.kernel.org/show_bug.cgi?id=195039#c80
https://askubuntu.com/questions/1222049/nvmekingston-a2000-sometimes-stops-giving-response-in-ubuntu-18-04dell-inspir
https://community.acer.com/en/discussion/604326/m-2-nvme-ssd-aspire-517-51g-issue-compatibility-kingston-a2000-linux-ubuntu
For the record, some data from 'nvme id-ctrl /dev/nvme0'
NVME Identify Controller:
vid : 0x2646
ssvid : 0x2646
mn : KINGSTON SA2000M81000G
fr : S5Z42105
[...]
ps 0 : mp:9.00W operational enlat:0 exlat:0 rrt:0 rrl:0
rwt:0 rwl:0 idle_power:- active_power:-
ps 1 : mp:4.60W operational enlat:0 exlat:0 rrt:1 rrl:1
rwt:1 rwl:1 idle_power:- active_power:-
ps 2 : mp:3.80W operational enlat:0 exlat:0 rrt:2 rrl:2
rwt:2 rwl:2 idle_power:- active_power:-
ps 3 : mp:0.0450W non-operational enlat:2000 exlat:2000 rrt:3 rrl:3
rwt:3 rwl:3 idle_power:- active_power:-
ps 4 : mp:0.0040W non-operational enlat:15000 exlat:15000 rrt:4 rrl:4
rwt:4 rwl:4 idle_power:- active_power:-
Cc: stable@vger.kernel.org # 4.14+
Signed-off-by: Thorsten Leemhuis <linux@leemhuis.info>
Signed-off-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/nvme/host/pci.c | 2 ++
1 file changed, 2 insertions(+)
--- a/drivers/nvme/host/pci.c
+++ b/drivers/nvme/host/pci.c
@@ -3262,6 +3262,8 @@ static const struct pci_device_id nvme_i
.driver_data = NVME_QUIRK_DISABLE_WRITE_ZEROES, },
{ PCI_DEVICE(0x15b7, 0x2001), /* Sandisk Skyhawk */
.driver_data = NVME_QUIRK_DISABLE_WRITE_ZEROES, },
+ { PCI_DEVICE(0x2646, 0x2263), /* KINGSTON A2000 NVMe SSD */
+ .driver_data = NVME_QUIRK_NO_DEEPEST_PS, },
{ PCI_DEVICE(PCI_VENDOR_ID_APPLE, 0x2001),
.driver_data = NVME_QUIRK_SINGLE_VECTOR },
{ PCI_DEVICE(PCI_VENDOR_ID_APPLE, 0x2003) },
^ permalink raw reply [flat|nested] 140+ messages in thread* [PATCH 5.10 088/120] KVM: SVM: Treat SVM as unsupported when running as an SEV guest
2021-02-08 14:59 [PATCH 5.10 000/120] 5.10.15-rc1 review Greg Kroah-Hartman
` (86 preceding siblings ...)
2021-02-08 15:01 ` [PATCH 5.10 087/120] nvme-pci: avoid the deepest sleep state on Kingston A2000 SSDs Greg Kroah-Hartman
@ 2021-02-08 15:01 ` Greg Kroah-Hartman
2021-02-08 15:01 ` [PATCH 5.10 089/120] KVM: x86/mmu: Fix TDP MMU zap collapsible SPTEs Greg Kroah-Hartman
` (38 subsequent siblings)
126 siblings, 0 replies; 140+ messages in thread
From: Greg Kroah-Hartman @ 2021-02-08 15:01 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Sean Christopherson, Paolo Bonzini
From: Sean Christopherson <seanjc@google.com>
commit ccd85d90ce092bdb047a7f6580f3955393833b22 upstream.
Don't let KVM load when running as an SEV guest, regardless of what
CPUID says. Memory is encrypted with a key that is not accessible to
the host (L0), thus it's impossible for L0 to emulate SVM, e.g. it'll
see garbage when reading the VMCB.
Technically, KVM could decrypt all memory that needs to be accessible to
the L0 and use shadow paging so that L0 does not need to shadow NPT, but
exposing such information to L0 largely defeats the purpose of running as
an SEV guest. This can always be revisited if someone comes up with a
use case for running VMs inside SEV guests.
Note, VMLOAD, VMRUN, etc... will also #GP on GPAs with C-bit set, i.e. KVM
is doomed even if the SEV guest is debuggable and the hypervisor is willing
to decrypt the VMCB. This may or may not be fixed on CPUs that have the
SVME_ADDR_CHK fix.
Cc: stable@vger.kernel.org
Signed-off-by: Sean Christopherson <seanjc@google.com>
Message-Id: <20210202212017.2486595-1-seanjc@google.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
arch/x86/kvm/svm/svm.c | 5 +++++
arch/x86/mm/mem_encrypt.c | 1 +
2 files changed, 6 insertions(+)
--- a/arch/x86/kvm/svm/svm.c
+++ b/arch/x86/kvm/svm/svm.c
@@ -438,6 +438,11 @@ static int has_svm(void)
return 0;
}
+ if (sev_active()) {
+ pr_info("KVM is unsupported when running as an SEV guest\n");
+ return 0;
+ }
+
return 1;
}
--- a/arch/x86/mm/mem_encrypt.c
+++ b/arch/x86/mm/mem_encrypt.c
@@ -351,6 +351,7 @@ bool sev_active(void)
{
return sev_status & MSR_AMD64_SEV_ENABLED;
}
+EXPORT_SYMBOL_GPL(sev_active);
/* Needs to be called from non-instrumentable code */
bool noinstr sev_es_active(void)
^ permalink raw reply [flat|nested] 140+ messages in thread* [PATCH 5.10 089/120] KVM: x86/mmu: Fix TDP MMU zap collapsible SPTEs
2021-02-08 14:59 [PATCH 5.10 000/120] 5.10.15-rc1 review Greg Kroah-Hartman
` (87 preceding siblings ...)
2021-02-08 15:01 ` [PATCH 5.10 088/120] KVM: SVM: Treat SVM as unsupported when running as an SEV guest Greg Kroah-Hartman
@ 2021-02-08 15:01 ` Greg Kroah-Hartman
2021-02-08 15:01 ` [PATCH 5.10 090/120] KVM: x86: Allow guests to see MSR_IA32_TSX_CTRL even if tsx=off Greg Kroah-Hartman
` (37 subsequent siblings)
126 siblings, 0 replies; 140+ messages in thread
From: Greg Kroah-Hartman @ 2021-02-08 15:01 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, Ben Gardon, Paolo Bonzini
From: Ben Gardon <bgardon@google.com>
commit 87aa9ec939ec7277b730786e19c161c9194cc8ca upstream.
There is a bug in the TDP MMU function to zap SPTEs which could be
replaced with a larger mapping which prevents the function from doing
anything. Fix this by correctly zapping the last level SPTEs.
Cc: stable@vger.kernel.org
Fixes: 14881998566d ("kvm: x86/mmu: Support disabling dirty logging for the tdp MMU")
Signed-off-by: Ben Gardon <bgardon@google.com>
Message-Id: <20210202185734.1680553-11-bgardon@google.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
arch/x86/kvm/mmu/tdp_mmu.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
--- a/arch/x86/kvm/mmu/tdp_mmu.c
+++ b/arch/x86/kvm/mmu/tdp_mmu.c
@@ -1037,8 +1037,8 @@ bool kvm_tdp_mmu_slot_set_dirty(struct k
}
/*
- * Clear non-leaf entries (and free associated page tables) which could
- * be replaced by large mappings, for GFNs within the slot.
+ * Clear leaf entries which could be replaced by large mappings, for
+ * GFNs within the slot.
*/
static void zap_collapsible_spte_range(struct kvm *kvm,
struct kvm_mmu_page *root,
@@ -1050,7 +1050,7 @@ static void zap_collapsible_spte_range(s
tdp_root_for_each_pte(iter, root, start, end) {
if (!is_shadow_present_pte(iter.old_spte) ||
- is_last_spte(iter.old_spte, iter.level))
+ !is_last_spte(iter.old_spte, iter.level))
continue;
pfn = spte_to_pfn(iter.old_spte);
^ permalink raw reply [flat|nested] 140+ messages in thread* [PATCH 5.10 090/120] KVM: x86: Allow guests to see MSR_IA32_TSX_CTRL even if tsx=off
2021-02-08 14:59 [PATCH 5.10 000/120] 5.10.15-rc1 review Greg Kroah-Hartman
` (88 preceding siblings ...)
2021-02-08 15:01 ` [PATCH 5.10 089/120] KVM: x86/mmu: Fix TDP MMU zap collapsible SPTEs Greg Kroah-Hartman
@ 2021-02-08 15:01 ` Greg Kroah-Hartman
2021-02-08 15:01 ` [PATCH 5.10 091/120] KVM: x86: fix CPUID entries returned by KVM_GET_CPUID2 ioctl Greg Kroah-Hartman
` (36 subsequent siblings)
126 siblings, 0 replies; 140+ messages in thread
From: Greg Kroah-Hartman @ 2021-02-08 15:01 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, Paolo Bonzini
From: Paolo Bonzini <pbonzini@redhat.com>
commit 7131636e7ea5b50ca910f8953f6365ef2d1f741c upstream.
Userspace that does not know about KVM_GET_MSR_FEATURE_INDEX_LIST
will generally use the default value for MSR_IA32_ARCH_CAPABILITIES.
When this happens and the host has tsx=on, it is possible to end up with
virtual machines that have HLE and RTM disabled, but TSX_CTRL available.
If the fleet is then switched to tsx=off, kvm_get_arch_capabilities()
will clear the ARCH_CAP_TSX_CTRL_MSR bit and it will not be possible to
use the tsx=off hosts as migration destinations, even though the guests
do not have TSX enabled.
To allow this migration, allow guests to write to their TSX_CTRL MSR,
while keeping the host MSR unchanged for the entire life of the guests.
This ensures that TSX remains disabled and also saves MSR reads and
writes, and it's okay to do because with tsx=off we know that guests will
not have the HLE and RTM features in their CPUID. (If userspace sets
bogus CPUID data, we do not expect HLE and RTM to work in guests anyway).
Cc: stable@vger.kernel.org
Fixes: cbbaa2727aa3 ("KVM: x86: fix presentation of TSX feature in ARCH_CAPABILITIES")
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
arch/x86/kvm/vmx/vmx.c | 17 +++++++++++++----
arch/x86/kvm/x86.c | 26 +++++++++++++++++---------
2 files changed, 30 insertions(+), 13 deletions(-)
--- a/arch/x86/kvm/vmx/vmx.c
+++ b/arch/x86/kvm/vmx/vmx.c
@@ -6874,11 +6874,20 @@ static int vmx_create_vcpu(struct kvm_vc
switch (index) {
case MSR_IA32_TSX_CTRL:
/*
- * No need to pass TSX_CTRL_CPUID_CLEAR through, so
- * let's avoid changing CPUID bits under the host
- * kernel's feet.
+ * TSX_CTRL_CPUID_CLEAR is handled in the CPUID
+ * interception. Keep the host value unchanged to avoid
+ * changing CPUID bits under the host kernel's feet.
+ *
+ * hle=0, rtm=0, tsx_ctrl=1 can be found with some
+ * combinations of new kernel and old userspace. If
+ * those guests run on a tsx=off host, do allow guests
+ * to use TSX_CTRL, but do not change the value on the
+ * host so that TSX remains always disabled.
*/
- vmx->guest_uret_msrs[j].mask = ~(u64)TSX_CTRL_CPUID_CLEAR;
+ if (boot_cpu_has(X86_FEATURE_RTM))
+ vmx->guest_uret_msrs[j].mask = ~(u64)TSX_CTRL_CPUID_CLEAR;
+ else
+ vmx->guest_uret_msrs[j].mask = 0;
break;
default:
vmx->guest_uret_msrs[j].mask = -1ull;
--- a/arch/x86/kvm/x86.c
+++ b/arch/x86/kvm/x86.c
@@ -1376,16 +1376,24 @@ static u64 kvm_get_arch_capabilities(voi
if (!boot_cpu_has_bug(X86_BUG_MDS))
data |= ARCH_CAP_MDS_NO;
- /*
- * On TAA affected systems:
- * - nothing to do if TSX is disabled on the host.
- * - we emulate TSX_CTRL if present on the host.
- * This lets the guest use VERW to clear CPU buffers.
- */
- if (!boot_cpu_has(X86_FEATURE_RTM))
- data &= ~(ARCH_CAP_TAA_NO | ARCH_CAP_TSX_CTRL_MSR);
- else if (!boot_cpu_has_bug(X86_BUG_TAA))
+ if (!boot_cpu_has(X86_FEATURE_RTM)) {
+ /*
+ * If RTM=0 because the kernel has disabled TSX, the host might
+ * have TAA_NO or TSX_CTRL. Clear TAA_NO (the guest sees RTM=0
+ * and therefore knows that there cannot be TAA) but keep
+ * TSX_CTRL: some buggy userspaces leave it set on tsx=on hosts,
+ * and we want to allow migrating those guests to tsx=off hosts.
+ */
+ data &= ~ARCH_CAP_TAA_NO;
+ } else if (!boot_cpu_has_bug(X86_BUG_TAA)) {
data |= ARCH_CAP_TAA_NO;
+ } else {
+ /*
+ * Nothing to do here; we emulate TSX_CTRL if present on the
+ * host so the guest can choose between disabling TSX or
+ * using VERW to clear CPU buffers.
+ */
+ }
return data;
}
^ permalink raw reply [flat|nested] 140+ messages in thread* [PATCH 5.10 091/120] KVM: x86: fix CPUID entries returned by KVM_GET_CPUID2 ioctl
2021-02-08 14:59 [PATCH 5.10 000/120] 5.10.15-rc1 review Greg Kroah-Hartman
` (89 preceding siblings ...)
2021-02-08 15:01 ` [PATCH 5.10 090/120] KVM: x86: Allow guests to see MSR_IA32_TSX_CTRL even if tsx=off Greg Kroah-Hartman
@ 2021-02-08 15:01 ` Greg Kroah-Hartman
2021-02-08 15:01 ` [PATCH 5.10 092/120] KVM: x86: Update emulator context mode if SYSENTER xfers to 64-bit mode Greg Kroah-Hartman
` (35 subsequent siblings)
126 siblings, 0 replies; 140+ messages in thread
From: Greg Kroah-Hartman @ 2021-02-08 15:01 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Vitaly Kuznetsov, Michael Roth,
Paolo Bonzini
From: Michael Roth <michael.roth@amd.com>
commit 181f494888d5b178ffda41bed965f187d5e5c432 upstream.
Recent commit 255cbecfe0 modified struct kvm_vcpu_arch to make
'cpuid_entries' a pointer to an array of kvm_cpuid_entry2 entries
rather than embedding the array in the struct. KVM_SET_CPUID and
KVM_SET_CPUID2 were updated accordingly, but KVM_GET_CPUID2 was missed.
As a result, KVM_GET_CPUID2 currently returns random fields from struct
kvm_vcpu_arch to userspace rather than the expected CPUID values. Fix
this by treating 'cpuid_entries' as a pointer when copying its
contents to userspace buffer.
Fixes: 255cbecfe0c9 ("KVM: x86: allocate vcpu->arch.cpuid_entries dynamically")
Cc: Vitaly Kuznetsov <vkuznets@redhat.com>
Signed-off-by: Michael Roth <michael.roth@amd.com.com>
Message-Id: <20210128024451.1816770-1-michael.roth@amd.com>
Cc: stable@vger.kernel.org
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
arch/x86/kvm/cpuid.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/arch/x86/kvm/cpuid.c
+++ b/arch/x86/kvm/cpuid.c
@@ -320,7 +320,7 @@ int kvm_vcpu_ioctl_get_cpuid2(struct kvm
if (cpuid->nent < vcpu->arch.cpuid_nent)
goto out;
r = -EFAULT;
- if (copy_to_user(entries, &vcpu->arch.cpuid_entries,
+ if (copy_to_user(entries, vcpu->arch.cpuid_entries,
vcpu->arch.cpuid_nent * sizeof(struct kvm_cpuid_entry2)))
goto out;
return 0;
^ permalink raw reply [flat|nested] 140+ messages in thread* [PATCH 5.10 092/120] KVM: x86: Update emulator context mode if SYSENTER xfers to 64-bit mode
2021-02-08 14:59 [PATCH 5.10 000/120] 5.10.15-rc1 review Greg Kroah-Hartman
` (90 preceding siblings ...)
2021-02-08 15:01 ` [PATCH 5.10 091/120] KVM: x86: fix CPUID entries returned by KVM_GET_CPUID2 ioctl Greg Kroah-Hartman
@ 2021-02-08 15:01 ` Greg Kroah-Hartman
2021-02-08 15:01 ` [PATCH 5.10 093/120] KVM: x86: Set so called reserved CR3 bits in LM mask at vCPU reset Greg Kroah-Hartman
` (34 subsequent siblings)
126 siblings, 0 replies; 140+ messages in thread
From: Greg Kroah-Hartman @ 2021-02-08 15:01 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Jonny Barker, Sean Christopherson,
Paolo Bonzini
From: Sean Christopherson <seanjc@google.com>
commit 943dea8af21bd896e0d6c30ea221203fb3cd3265 upstream.
Set the emulator context to PROT64 if SYSENTER transitions from 32-bit
userspace (compat mode) to a 64-bit kernel, otherwise the RIP update at
the end of x86_emulate_insn() will incorrectly truncate the new RIP.
Note, this bug is mostly limited to running an Intel virtual CPU model on
an AMD physical CPU, as other combinations of virtual and physical CPUs
do not trigger full emulation. On Intel CPUs, SYSENTER in compatibility
mode is legal, and unconditionally transitions to 64-bit mode. On AMD
CPUs, SYSENTER is illegal in compatibility mode and #UDs. If the vCPU is
AMD, KVM injects a #UD on SYSENTER in compat mode. If the pCPU is Intel,
SYSENTER will execute natively and not trigger #UD->VM-Exit (ignoring
guest TLB shenanigans).
Fixes: fede8076aab4 ("KVM: x86: handle wrap around 32-bit address space")
Cc: stable@vger.kernel.org
Signed-off-by: Jonny Barker <jonny@jonnybarker.com>
[sean: wrote changelog]
Signed-off-by: Sean Christopherson <seanjc@google.com>
Message-Id: <20210202165546.2390296-1-seanjc@google.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
arch/x86/kvm/emulate.c | 2 ++
1 file changed, 2 insertions(+)
--- a/arch/x86/kvm/emulate.c
+++ b/arch/x86/kvm/emulate.c
@@ -2879,6 +2879,8 @@ static int em_sysenter(struct x86_emulat
ops->get_msr(ctxt, MSR_IA32_SYSENTER_ESP, &msr_data);
*reg_write(ctxt, VCPU_REGS_RSP) = (efer & EFER_LMA) ? msr_data :
(u32)msr_data;
+ if (efer & EFER_LMA)
+ ctxt->mode = X86EMUL_MODE_PROT64;
return X86EMUL_CONTINUE;
}
^ permalink raw reply [flat|nested] 140+ messages in thread* [PATCH 5.10 093/120] KVM: x86: Set so called reserved CR3 bits in LM mask at vCPU reset
2021-02-08 14:59 [PATCH 5.10 000/120] 5.10.15-rc1 review Greg Kroah-Hartman
` (91 preceding siblings ...)
2021-02-08 15:01 ` [PATCH 5.10 092/120] KVM: x86: Update emulator context mode if SYSENTER xfers to 64-bit mode Greg Kroah-Hartman
@ 2021-02-08 15:01 ` Greg Kroah-Hartman
2021-02-08 15:01 ` [PATCH 5.10 094/120] DTS: ARM: gta04: remove legacy spi-cs-high to make display work again Greg Kroah-Hartman
` (33 subsequent siblings)
126 siblings, 0 replies; 140+ messages in thread
From: Greg Kroah-Hartman @ 2021-02-08 15:01 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Sean Christopherson, Paolo Bonzini
From: Sean Christopherson <seanjc@google.com>
commit 031b91a5fe6f1ce61b7617614ddde9ed61e252be upstream.
Set cr3_lm_rsvd_bits, which is effectively an invalid GPA mask, at vCPU
reset. The reserved bits check needs to be done even if userspace never
configures the guest's CPUID model.
Cc: stable@vger.kernel.org
Fixes: 0107973a80ad ("KVM: x86: Introduce cr3_lm_rsvd_bits in kvm_vcpu_arch")
Signed-off-by: Sean Christopherson <seanjc@google.com>
Message-Id: <20210204000117.3303214-2-seanjc@google.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
arch/x86/kvm/x86.c | 1 +
1 file changed, 1 insertion(+)
--- a/arch/x86/kvm/x86.c
+++ b/arch/x86/kvm/x86.c
@@ -9915,6 +9915,7 @@ int kvm_arch_vcpu_create(struct kvm_vcpu
fx_init(vcpu);
vcpu->arch.maxphyaddr = cpuid_query_maxphyaddr(vcpu);
+ vcpu->arch.cr3_lm_rsvd_bits = rsvd_bits(cpuid_maxphyaddr(vcpu), 63);
vcpu->arch.pat = MSR_IA32_CR_PAT_DEFAULT;
^ permalink raw reply [flat|nested] 140+ messages in thread* [PATCH 5.10 094/120] DTS: ARM: gta04: remove legacy spi-cs-high to make display work again
2021-02-08 14:59 [PATCH 5.10 000/120] 5.10.15-rc1 review Greg Kroah-Hartman
` (92 preceding siblings ...)
2021-02-08 15:01 ` [PATCH 5.10 093/120] KVM: x86: Set so called reserved CR3 bits in LM mask at vCPU reset Greg Kroah-Hartman
@ 2021-02-08 15:01 ` Greg Kroah-Hartman
2021-02-08 15:01 ` [PATCH 5.10 095/120] ARM: dts; gta04: SPI panel chip select is active low Greg Kroah-Hartman
` (32 subsequent siblings)
126 siblings, 0 replies; 140+ messages in thread
From: Greg Kroah-Hartman @ 2021-02-08 15:01 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, H. Nikolaus Schaller, Tony Lindgren
From: H. Nikolaus Schaller <hns@goldelico.com>
commit 07af7810e0a5bc4e51682c90f9fa19fc4cb93f18 upstream.
This reverts
commit f1f028ff89cb ("DTS: ARM: gta04: introduce legacy spi-cs-high to make display work again")
which had to be intruduced after
commit 6953c57ab172 ("gpio: of: Handle SPI chipselect legacy bindings")
broke the GTA04 display. This contradicted the data sheet but was the only
way to get it as an spi client operational again.
The panel data sheet defines the chip-select to be active low.
Now, with the arrival of
commit 766c6b63aa04 ("spi: fix client driver breakages when using GPIO descriptors")
the logic of interaction between spi-cs-high and the gpio descriptor flags
has been changed a second time, making the display broken again. So we have
to remove the original fix which in retrospect was a workaround of a bug in
the spi subsystem and not a feature of the panel or bug in the device tree.
With this fix the device tree is back in sync with the data sheet and
spi subsystem code.
Fixes: 766c6b63aa04 ("spi: fix client driver breakages when using GPIO descriptors")
CC: stable@vger.kernel.org
Signed-off-by: H. Nikolaus Schaller <hns@goldelico.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
arch/arm/boot/dts/omap3-gta04.dtsi | 1 -
1 file changed, 1 deletion(-)
--- a/arch/arm/boot/dts/omap3-gta04.dtsi
+++ b/arch/arm/boot/dts/omap3-gta04.dtsi
@@ -124,7 +124,6 @@
spi-max-frequency = <100000>;
spi-cpol;
spi-cpha;
- spi-cs-high;
backlight= <&backlight>;
label = "lcd";
^ permalink raw reply [flat|nested] 140+ messages in thread* [PATCH 5.10 095/120] ARM: dts; gta04: SPI panel chip select is active low
2021-02-08 14:59 [PATCH 5.10 000/120] 5.10.15-rc1 review Greg Kroah-Hartman
` (93 preceding siblings ...)
2021-02-08 15:01 ` [PATCH 5.10 094/120] DTS: ARM: gta04: remove legacy spi-cs-high to make display work again Greg Kroah-Hartman
@ 2021-02-08 15:01 ` Greg Kroah-Hartman
2021-02-08 15:01 ` [PATCH 5.10 096/120] ARM: footbridge: fix dc21285 PCI configuration accessors Greg Kroah-Hartman
` (31 subsequent siblings)
126 siblings, 0 replies; 140+ messages in thread
From: Greg Kroah-Hartman @ 2021-02-08 15:01 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, H. Nikolaus Schaller, Tony Lindgren
From: H. Nikolaus Schaller <hns@goldelico.com>
commit 181739822cf6f8f4e12b173913af2967a28906c0 upstream.
With the arrival of
commit 2fee9583198eb9 ("spi: dt-bindings: clarify CS behavior for spi-cs-high and gpio descriptors")
it was clarified what the proper state for cs-gpios should be, even if the
flag is ignored. The driver code is doing the right thing since
766c6b63aa04 ("spi: fix client driver breakages when using GPIO descriptors")
The chip-select of the td028ttec1 panel is active-low, so we must omit spi-cs-high;
attribute (already removed by separate patch) and should now use GPIO_ACTIVE_LOW for
the client device description to be fully consistent.
Fixes: 766c6b63aa04 ("spi: fix client driver breakages when using GPIO descriptors")
CC: stable@vger.kernel.org
Signed-off-by: H. Nikolaus Schaller <hns@goldelico.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
arch/arm/boot/dts/omap3-gta04.dtsi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/omap3-gta04.dtsi b/arch/arm/boot/dts/omap3-gta04.dtsi
index 003202d12990..7b8c18e6605e 100644
--- a/arch/arm/boot/dts/omap3-gta04.dtsi
+++ b/arch/arm/boot/dts/omap3-gta04.dtsi
@@ -114,7 +114,7 @@ spi_lcd: spi_lcd {
gpio-sck = <&gpio1 12 GPIO_ACTIVE_HIGH>;
gpio-miso = <&gpio1 18 GPIO_ACTIVE_HIGH>;
gpio-mosi = <&gpio1 20 GPIO_ACTIVE_HIGH>;
- cs-gpios = <&gpio1 19 GPIO_ACTIVE_HIGH>;
+ cs-gpios = <&gpio1 19 GPIO_ACTIVE_LOW>;
num-chipselects = <1>;
/* lcd panel */
--
2.30.0
^ permalink raw reply related [flat|nested] 140+ messages in thread* [PATCH 5.10 096/120] ARM: footbridge: fix dc21285 PCI configuration accessors
2021-02-08 14:59 [PATCH 5.10 000/120] 5.10.15-rc1 review Greg Kroah-Hartman
` (94 preceding siblings ...)
2021-02-08 15:01 ` [PATCH 5.10 095/120] ARM: dts; gta04: SPI panel chip select is active low Greg Kroah-Hartman
@ 2021-02-08 15:01 ` Greg Kroah-Hartman
2021-02-08 15:01 ` [PATCH 5.10 097/120] ARM: 9043/1: tegra: Fix misplaced tegra_uart_config in decompressor Greg Kroah-Hartman
` (30 subsequent siblings)
126 siblings, 0 replies; 140+ messages in thread
From: Greg Kroah-Hartman @ 2021-02-08 15:01 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, Russell King
From: Russell King <rmk+kernel@armlinux.org.uk>
commit 39d3454c3513840eb123b3913fda6903e45ce671 upstream.
Building with gcc 4.9.2 reveals a latent bug in the PCI accessors
for Footbridge platforms, which causes a fatal alignment fault
while accessing IO memory. Fix this by making the assembly volatile.
Cc: stable@vger.kernel.org
Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
| 12 ++++++------
1 file changed, 6 insertions(+), 6 deletions(-)
--- a/arch/arm/mach-footbridge/dc21285.c
+++ b/arch/arm/mach-footbridge/dc21285.c
@@ -65,15 +65,15 @@ dc21285_read_config(struct pci_bus *bus,
if (addr)
switch (size) {
case 1:
- asm("ldrb %0, [%1, %2]"
+ asm volatile("ldrb %0, [%1, %2]"
: "=r" (v) : "r" (addr), "r" (where) : "cc");
break;
case 2:
- asm("ldrh %0, [%1, %2]"
+ asm volatile("ldrh %0, [%1, %2]"
: "=r" (v) : "r" (addr), "r" (where) : "cc");
break;
case 4:
- asm("ldr %0, [%1, %2]"
+ asm volatile("ldr %0, [%1, %2]"
: "=r" (v) : "r" (addr), "r" (where) : "cc");
break;
}
@@ -99,17 +99,17 @@ dc21285_write_config(struct pci_bus *bus
if (addr)
switch (size) {
case 1:
- asm("strb %0, [%1, %2]"
+ asm volatile("strb %0, [%1, %2]"
: : "r" (value), "r" (addr), "r" (where)
: "cc");
break;
case 2:
- asm("strh %0, [%1, %2]"
+ asm volatile("strh %0, [%1, %2]"
: : "r" (value), "r" (addr), "r" (where)
: "cc");
break;
case 4:
- asm("str %0, [%1, %2]"
+ asm volatile("str %0, [%1, %2]"
: : "r" (value), "r" (addr), "r" (where)
: "cc");
break;
^ permalink raw reply [flat|nested] 140+ messages in thread* [PATCH 5.10 097/120] ARM: 9043/1: tegra: Fix misplaced tegra_uart_config in decompressor
2021-02-08 14:59 [PATCH 5.10 000/120] 5.10.15-rc1 review Greg Kroah-Hartman
` (95 preceding siblings ...)
2021-02-08 15:01 ` [PATCH 5.10 096/120] ARM: footbridge: fix dc21285 PCI configuration accessors Greg Kroah-Hartman
@ 2021-02-08 15:01 ` Greg Kroah-Hartman
2021-02-08 15:01 ` [PATCH 5.10 098/120] mm: hugetlbfs: fix cannot migrate the fallocated HugeTLB page Greg Kroah-Hartman
` (29 subsequent siblings)
126 siblings, 0 replies; 140+ messages in thread
From: Greg Kroah-Hartman @ 2021-02-08 15:01 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Linus Walleij, Dmitry Osipenko, Russell King
From: Dmitry Osipenko <digetx@gmail.com>
commit 538eea5362a1179dfa7770dd2b6607dc30cc50c6 upstream.
The tegra_uart_config of the DEBUG_LL code is now placed right at the
start of the .text section after commit which enabled debug output in the
decompressor. Tegra devices are not booting anymore if DEBUG_LL is enabled
since tegra_uart_config data is executes as a code. Fix the misplaced
tegra_uart_config storage by embedding it into the code.
Cc: stable@vger.kernel.org
Fixes: 2596a72d3384 ("ARM: 9009/1: uncompress: Enable debug in head.S")
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Dmitry Osipenko <digetx@gmail.com>
Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
arch/arm/include/debug/tegra.S | 54 ++++++++++++++++++++---------------------
1 file changed, 27 insertions(+), 27 deletions(-)
--- a/arch/arm/include/debug/tegra.S
+++ b/arch/arm/include/debug/tegra.S
@@ -149,7 +149,34 @@
.align
99: .word .
+#if defined(ZIMAGE)
+ .word . + 4
+/*
+ * Storage for the state maintained by the macro.
+ *
+ * In the kernel proper, this data is located in arch/arm/mach-tegra/tegra.c.
+ * That's because this header is included from multiple files, and we only
+ * want a single copy of the data. In particular, the UART probing code above
+ * assumes it's running using physical addresses. This is true when this file
+ * is included from head.o, but not when included from debug.o. So we need
+ * to share the probe results between the two copies, rather than having
+ * to re-run the probing again later.
+ *
+ * In the decompressor, we put the storage right here, since common.c
+ * isn't included in the decompressor build. This storage data gets put in
+ * .text even though it's really data, since .data is discarded from the
+ * decompressor. Luckily, .text is writeable in the decompressor, unless
+ * CONFIG_ZBOOT_ROM. That dependency is handled in arch/arm/Kconfig.debug.
+ */
+ /* Debug UART initialization required */
+ .word 1
+ /* Debug UART physical address */
+ .word 0
+ /* Debug UART virtual address */
+ .word 0
+#else
.word tegra_uart_config
+#endif
.ltorg
/* Load previously selected UART address */
@@ -189,30 +216,3 @@
.macro waituarttxrdy,rd,rx
.endm
-
-/*
- * Storage for the state maintained by the macros above.
- *
- * In the kernel proper, this data is located in arch/arm/mach-tegra/tegra.c.
- * That's because this header is included from multiple files, and we only
- * want a single copy of the data. In particular, the UART probing code above
- * assumes it's running using physical addresses. This is true when this file
- * is included from head.o, but not when included from debug.o. So we need
- * to share the probe results between the two copies, rather than having
- * to re-run the probing again later.
- *
- * In the decompressor, we put the symbol/storage right here, since common.c
- * isn't included in the decompressor build. This symbol gets put in .text
- * even though it's really data, since .data is discarded from the
- * decompressor. Luckily, .text is writeable in the decompressor, unless
- * CONFIG_ZBOOT_ROM. That dependency is handled in arch/arm/Kconfig.debug.
- */
-#if defined(ZIMAGE)
-tegra_uart_config:
- /* Debug UART initialization required */
- .word 1
- /* Debug UART physical address */
- .word 0
- /* Debug UART virtual address */
- .word 0
-#endif
^ permalink raw reply [flat|nested] 140+ messages in thread* [PATCH 5.10 098/120] mm: hugetlbfs: fix cannot migrate the fallocated HugeTLB page
2021-02-08 14:59 [PATCH 5.10 000/120] 5.10.15-rc1 review Greg Kroah-Hartman
` (96 preceding siblings ...)
2021-02-08 15:01 ` [PATCH 5.10 097/120] ARM: 9043/1: tegra: Fix misplaced tegra_uart_config in decompressor Greg Kroah-Hartman
@ 2021-02-08 15:01 ` Greg Kroah-Hartman
2021-02-08 15:01 ` [PATCH 5.10 099/120] mm: hugetlb: fix a race between freeing and dissolving the page Greg Kroah-Hartman
` (28 subsequent siblings)
126 siblings, 0 replies; 140+ messages in thread
From: Greg Kroah-Hartman @ 2021-02-08 15:01 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Muchun Song, Michal Hocko,
Mike Kravetz, Oscar Salvador, David Hildenbrand, Yang Shi,
Andrew Morton, Linus Torvalds
From: Muchun Song <songmuchun@bytedance.com>
commit 585fc0d2871c9318c949fbf45b1f081edd489e96 upstream.
If a new hugetlb page is allocated during fallocate it will not be
marked as active (set_page_huge_active) which will result in a later
isolate_huge_page failure when the page migration code would like to
move that page. Such a failure would be unexpected and wrong.
Only export set_page_huge_active, just leave clear_page_huge_active as
static. Because there are no external users.
Link: https://lkml.kernel.org/r/20210115124942.46403-3-songmuchun@bytedance.com
Fixes: 70c3547e36f5 (hugetlbfs: add hugetlbfs_fallocate())
Signed-off-by: Muchun Song <songmuchun@bytedance.com>
Acked-by: Michal Hocko <mhocko@suse.com>
Reviewed-by: Mike Kravetz <mike.kravetz@oracle.com>
Reviewed-by: Oscar Salvador <osalvador@suse.de>
Cc: David Hildenbrand <david@redhat.com>
Cc: Yang Shi <shy828301@gmail.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
fs/hugetlbfs/inode.c | 3 ++-
include/linux/hugetlb.h | 2 ++
mm/hugetlb.c | 2 +-
3 files changed, 5 insertions(+), 2 deletions(-)
--- a/fs/hugetlbfs/inode.c
+++ b/fs/hugetlbfs/inode.c
@@ -735,9 +735,10 @@ static long hugetlbfs_fallocate(struct f
mutex_unlock(&hugetlb_fault_mutex_table[hash]);
+ set_page_huge_active(page);
/*
* unlock_page because locked by add_to_page_cache()
- * page_put due to reference from alloc_huge_page()
+ * put_page() due to reference from alloc_huge_page()
*/
unlock_page(page);
put_page(page);
--- a/include/linux/hugetlb.h
+++ b/include/linux/hugetlb.h
@@ -770,6 +770,8 @@ static inline void huge_ptep_modify_prot
}
#endif
+void set_page_huge_active(struct page *page);
+
#else /* CONFIG_HUGETLB_PAGE */
struct hstate {};
--- a/mm/hugetlb.c
+++ b/mm/hugetlb.c
@@ -1349,7 +1349,7 @@ bool page_huge_active(struct page *page)
}
/* never called for tail page */
-static void set_page_huge_active(struct page *page)
+void set_page_huge_active(struct page *page)
{
VM_BUG_ON_PAGE(!PageHeadHuge(page), page);
SetPagePrivate(&page[1]);
^ permalink raw reply [flat|nested] 140+ messages in thread* [PATCH 5.10 099/120] mm: hugetlb: fix a race between freeing and dissolving the page
2021-02-08 14:59 [PATCH 5.10 000/120] 5.10.15-rc1 review Greg Kroah-Hartman
` (97 preceding siblings ...)
2021-02-08 15:01 ` [PATCH 5.10 098/120] mm: hugetlbfs: fix cannot migrate the fallocated HugeTLB page Greg Kroah-Hartman
@ 2021-02-08 15:01 ` Greg Kroah-Hartman
2021-02-08 15:01 ` [PATCH 5.10 100/120] mm: hugetlb: fix a race between isolating and freeing page Greg Kroah-Hartman
` (27 subsequent siblings)
126 siblings, 0 replies; 140+ messages in thread
From: Greg Kroah-Hartman @ 2021-02-08 15:01 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Muchun Song, Mike Kravetz,
Oscar Salvador, Michal Hocko, David Hildenbrand, Yang Shi,
Andrew Morton, Linus Torvalds
From: Muchun Song <songmuchun@bytedance.com>
commit 7ffddd499ba6122b1a07828f023d1d67629aa017 upstream.
There is a race condition between __free_huge_page()
and dissolve_free_huge_page().
CPU0: CPU1:
// page_count(page) == 1
put_page(page)
__free_huge_page(page)
dissolve_free_huge_page(page)
spin_lock(&hugetlb_lock)
// PageHuge(page) && !page_count(page)
update_and_free_page(page)
// page is freed to the buddy
spin_unlock(&hugetlb_lock)
spin_lock(&hugetlb_lock)
clear_page_huge_active(page)
enqueue_huge_page(page)
// It is wrong, the page is already freed
spin_unlock(&hugetlb_lock)
The race window is between put_page() and dissolve_free_huge_page().
We should make sure that the page is already on the free list when it is
dissolved.
As a result __free_huge_page would corrupt page(s) already in the buddy
allocator.
Link: https://lkml.kernel.org/r/20210115124942.46403-4-songmuchun@bytedance.com
Fixes: c8721bbbdd36 ("mm: memory-hotplug: enable memory hotplug to handle hugepage")
Signed-off-by: Muchun Song <songmuchun@bytedance.com>
Reviewed-by: Mike Kravetz <mike.kravetz@oracle.com>
Reviewed-by: Oscar Salvador <osalvador@suse.de>
Acked-by: Michal Hocko <mhocko@suse.com>
Cc: David Hildenbrand <david@redhat.com>
Cc: Yang Shi <shy828301@gmail.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
mm/hugetlb.c | 39 +++++++++++++++++++++++++++++++++++++++
1 file changed, 39 insertions(+)
--- a/mm/hugetlb.c
+++ b/mm/hugetlb.c
@@ -79,6 +79,21 @@ DEFINE_SPINLOCK(hugetlb_lock);
static int num_fault_mutexes;
struct mutex *hugetlb_fault_mutex_table ____cacheline_aligned_in_smp;
+static inline bool PageHugeFreed(struct page *head)
+{
+ return page_private(head + 4) == -1UL;
+}
+
+static inline void SetPageHugeFreed(struct page *head)
+{
+ set_page_private(head + 4, -1UL);
+}
+
+static inline void ClearPageHugeFreed(struct page *head)
+{
+ set_page_private(head + 4, 0);
+}
+
/* Forward declaration */
static int hugetlb_acct_memory(struct hstate *h, long delta);
@@ -1028,6 +1043,7 @@ static void enqueue_huge_page(struct hst
list_move(&page->lru, &h->hugepage_freelists[nid]);
h->free_huge_pages++;
h->free_huge_pages_node[nid]++;
+ SetPageHugeFreed(page);
}
static struct page *dequeue_huge_page_node_exact(struct hstate *h, int nid)
@@ -1044,6 +1060,7 @@ static struct page *dequeue_huge_page_no
list_move(&page->lru, &h->hugepage_activelist);
set_page_refcounted(page);
+ ClearPageHugeFreed(page);
h->free_huge_pages--;
h->free_huge_pages_node[nid]--;
return page;
@@ -1505,6 +1522,7 @@ static void prep_new_huge_page(struct hs
spin_lock(&hugetlb_lock);
h->nr_huge_pages++;
h->nr_huge_pages_node[nid]++;
+ ClearPageHugeFreed(page);
spin_unlock(&hugetlb_lock);
}
@@ -1755,6 +1773,7 @@ int dissolve_free_huge_page(struct page
{
int rc = -EBUSY;
+retry:
/* Not to disrupt normal path by vainly holding hugetlb_lock */
if (!PageHuge(page))
return 0;
@@ -1771,6 +1790,26 @@ int dissolve_free_huge_page(struct page
int nid = page_to_nid(head);
if (h->free_huge_pages - h->resv_huge_pages == 0)
goto out;
+
+ /*
+ * We should make sure that the page is already on the free list
+ * when it is dissolved.
+ */
+ if (unlikely(!PageHugeFreed(head))) {
+ spin_unlock(&hugetlb_lock);
+ cond_resched();
+
+ /*
+ * Theoretically, we should return -EBUSY when we
+ * encounter this race. In fact, we have a chance
+ * to successfully dissolve the page if we do a
+ * retry. Because the race window is quite small.
+ * If we seize this opportunity, it is an optimization
+ * for increasing the success rate of dissolving page.
+ */
+ goto retry;
+ }
+
/*
* Move PageHWPoison flag from head page to the raw error page,
* which makes any subpages rather than the error page reusable.
^ permalink raw reply [flat|nested] 140+ messages in thread* [PATCH 5.10 100/120] mm: hugetlb: fix a race between isolating and freeing page
2021-02-08 14:59 [PATCH 5.10 000/120] 5.10.15-rc1 review Greg Kroah-Hartman
` (98 preceding siblings ...)
2021-02-08 15:01 ` [PATCH 5.10 099/120] mm: hugetlb: fix a race between freeing and dissolving the page Greg Kroah-Hartman
@ 2021-02-08 15:01 ` Greg Kroah-Hartman
2021-02-08 15:01 ` [PATCH 5.10 101/120] mm: hugetlb: remove VM_BUG_ON_PAGE from page_huge_active Greg Kroah-Hartman
` (26 subsequent siblings)
126 siblings, 0 replies; 140+ messages in thread
From: Greg Kroah-Hartman @ 2021-02-08 15:01 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Muchun Song, Mike Kravetz,
Michal Hocko, Oscar Salvador, David Hildenbrand, Yang Shi,
Andrew Morton, Linus Torvalds
From: Muchun Song <songmuchun@bytedance.com>
commit 0eb2df2b5629794020f75e94655e1994af63f0d4 upstream.
There is a race between isolate_huge_page() and __free_huge_page().
CPU0: CPU1:
if (PageHuge(page))
put_page(page)
__free_huge_page(page)
spin_lock(&hugetlb_lock)
update_and_free_page(page)
set_compound_page_dtor(page,
NULL_COMPOUND_DTOR)
spin_unlock(&hugetlb_lock)
isolate_huge_page(page)
// trigger BUG_ON
VM_BUG_ON_PAGE(!PageHead(page), page)
spin_lock(&hugetlb_lock)
page_huge_active(page)
// trigger BUG_ON
VM_BUG_ON_PAGE(!PageHuge(page), page)
spin_unlock(&hugetlb_lock)
When we isolate a HugeTLB page on CPU0. Meanwhile, we free it to the
buddy allocator on CPU1. Then, we can trigger a BUG_ON on CPU0, because
it is already freed to the buddy allocator.
Link: https://lkml.kernel.org/r/20210115124942.46403-5-songmuchun@bytedance.com
Fixes: c8721bbbdd36 ("mm: memory-hotplug: enable memory hotplug to handle hugepage")
Signed-off-by: Muchun Song <songmuchun@bytedance.com>
Reviewed-by: Mike Kravetz <mike.kravetz@oracle.com>
Acked-by: Michal Hocko <mhocko@suse.com>
Reviewed-by: Oscar Salvador <osalvador@suse.de>
Cc: David Hildenbrand <david@redhat.com>
Cc: Yang Shi <shy828301@gmail.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
mm/hugetlb.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
--- a/mm/hugetlb.c
+++ b/mm/hugetlb.c
@@ -5595,9 +5595,9 @@ bool isolate_huge_page(struct page *page
{
bool ret = true;
- VM_BUG_ON_PAGE(!PageHead(page), page);
spin_lock(&hugetlb_lock);
- if (!page_huge_active(page) || !get_page_unless_zero(page)) {
+ if (!PageHeadHuge(page) || !page_huge_active(page) ||
+ !get_page_unless_zero(page)) {
ret = false;
goto unlock;
}
^ permalink raw reply [flat|nested] 140+ messages in thread* [PATCH 5.10 101/120] mm: hugetlb: remove VM_BUG_ON_PAGE from page_huge_active
2021-02-08 14:59 [PATCH 5.10 000/120] 5.10.15-rc1 review Greg Kroah-Hartman
` (99 preceding siblings ...)
2021-02-08 15:01 ` [PATCH 5.10 100/120] mm: hugetlb: fix a race between isolating and freeing page Greg Kroah-Hartman
@ 2021-02-08 15:01 ` Greg Kroah-Hartman
2021-02-08 15:01 ` [PATCH 5.10 102/120] mm, compaction: move high_pfn to the for loop scope Greg Kroah-Hartman
` (25 subsequent siblings)
126 siblings, 0 replies; 140+ messages in thread
From: Greg Kroah-Hartman @ 2021-02-08 15:01 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Muchun Song, Mike Kravetz,
Michal Hocko, Oscar Salvador, David Hildenbrand, Yang Shi,
Andrew Morton, Linus Torvalds
From: Muchun Song <songmuchun@bytedance.com>
commit ecbf4724e6061b4b01be20f6d797d64d462b2bc8 upstream.
The page_huge_active() can be called from scan_movable_pages() which do
not hold a reference count to the HugeTLB page. So when we call
page_huge_active() from scan_movable_pages(), the HugeTLB page can be
freed parallel. Then we will trigger a BUG_ON which is in the
page_huge_active() when CONFIG_DEBUG_VM is enabled. Just remove the
VM_BUG_ON_PAGE.
Link: https://lkml.kernel.org/r/20210115124942.46403-6-songmuchun@bytedance.com
Fixes: 7e1f049efb86 ("mm: hugetlb: cleanup using paeg_huge_active()")
Signed-off-by: Muchun Song <songmuchun@bytedance.com>
Reviewed-by: Mike Kravetz <mike.kravetz@oracle.com>
Acked-by: Michal Hocko <mhocko@suse.com>
Reviewed-by: Oscar Salvador <osalvador@suse.de>
Cc: David Hildenbrand <david@redhat.com>
Cc: Yang Shi <shy828301@gmail.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
mm/hugetlb.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
--- a/mm/hugetlb.c
+++ b/mm/hugetlb.c
@@ -1361,8 +1361,7 @@ struct hstate *size_to_hstate(unsigned l
*/
bool page_huge_active(struct page *page)
{
- VM_BUG_ON_PAGE(!PageHuge(page), page);
- return PageHead(page) && PagePrivate(&page[1]);
+ return PageHeadHuge(page) && PagePrivate(&page[1]);
}
/* never called for tail page */
^ permalink raw reply [flat|nested] 140+ messages in thread* [PATCH 5.10 102/120] mm, compaction: move high_pfn to the for loop scope
2021-02-08 14:59 [PATCH 5.10 000/120] 5.10.15-rc1 review Greg Kroah-Hartman
` (100 preceding siblings ...)
2021-02-08 15:01 ` [PATCH 5.10 101/120] mm: hugetlb: remove VM_BUG_ON_PAGE from page_huge_active Greg Kroah-Hartman
@ 2021-02-08 15:01 ` Greg Kroah-Hartman
2021-02-08 15:01 ` [PATCH 5.10 103/120] mm/vmalloc: separate put pages and flush VM flags Greg Kroah-Hartman
` (24 subsequent siblings)
126 siblings, 0 replies; 140+ messages in thread
From: Greg Kroah-Hartman @ 2021-02-08 15:01 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Rokudo Yan, Mel Gorman,
Vlastimil Babka, Andrew Morton, Linus Torvalds
From: Rokudo Yan <wu-yan@tcl.com>
commit 74e21484e40bb8ce0f9828bbfe1c9fc9b04249c6 upstream.
In fast_isolate_freepages, high_pfn will be used if a prefered one (ie
PFN >= low_fn) not found.
But the high_pfn is not reset before searching an free area, so when it
was used as freepage, it may from another free area searched before. As
a result move_freelist_head(freelist, freepage) will have unexpected
behavior (eg corrupt the MOVABLE freelist)
Unable to handle kernel paging request at virtual address dead000000000200
Mem abort info:
ESR = 0x96000044
Exception class = DABT (current EL), IL = 32 bits
SET = 0, FnV = 0
EA = 0, S1PTW = 0
Data abort info:
ISV = 0, ISS = 0x00000044
CM = 0, WnR = 1
[dead000000000200] address between user and kernel address ranges
-000|list_cut_before(inline)
-000|move_freelist_head(inline)
-000|fast_isolate_freepages(inline)
-000|isolate_freepages(inline)
-000|compaction_alloc(?, ?)
-001|unmap_and_move(inline)
-001|migrate_pages([NSD:0xFFFFFF80088CBBD0] from = 0xFFFFFF80088CBD88, [NSD:0xFFFFFF80088CBBC8] get_new_p
-002|__read_once_size(inline)
-002|static_key_count(inline)
-002|static_key_false(inline)
-002|trace_mm_compaction_migratepages(inline)
-002|compact_zone(?, [NSD:0xFFFFFF80088CBCB0] capc = 0x0)
-003|kcompactd_do_work(inline)
-003|kcompactd([X19] p = 0xFFFFFF93227FBC40)
-004|kthread([X20] _create = 0xFFFFFFE1AFB26380)
-005|ret_from_fork(asm)
The issue was reported on an smart phone product with 6GB ram and 3GB
zram as swap device.
This patch fixes the issue by reset high_pfn before searching each free
area, which ensure freepage and freelist match when call
move_freelist_head in fast_isolate_freepages().
Link: http://lkml.kernel.org/r/20190118175136.31341-12-mgorman@techsingularity.net
Link: https://lkml.kernel.org/r/20210112094720.1238444-1-wu-yan@tcl.com
Fixes: 5a811889de10f1eb ("mm, compaction: use free lists to quickly locate a migration target")
Signed-off-by: Rokudo Yan <wu-yan@tcl.com>
Acked-by: Mel Gorman <mgorman@techsingularity.net>
Acked-by: Vlastimil Babka <vbabka@suse.cz>
Cc: <stable@vger.kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
mm/compaction.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
--- a/mm/compaction.c
+++ b/mm/compaction.c
@@ -1302,7 +1302,7 @@ fast_isolate_freepages(struct compact_co
{
unsigned int limit = min(1U, freelist_scan_limit(cc) >> 1);
unsigned int nr_scanned = 0;
- unsigned long low_pfn, min_pfn, high_pfn = 0, highest = 0;
+ unsigned long low_pfn, min_pfn, highest = 0;
unsigned long nr_isolated = 0;
unsigned long distance;
struct page *page = NULL;
@@ -1347,6 +1347,7 @@ fast_isolate_freepages(struct compact_co
struct page *freepage;
unsigned long flags;
unsigned int order_scanned = 0;
+ unsigned long high_pfn = 0;
if (!area->nr_free)
continue;
^ permalink raw reply [flat|nested] 140+ messages in thread* [PATCH 5.10 103/120] mm/vmalloc: separate put pages and flush VM flags
2021-02-08 14:59 [PATCH 5.10 000/120] 5.10.15-rc1 review Greg Kroah-Hartman
` (101 preceding siblings ...)
2021-02-08 15:01 ` [PATCH 5.10 102/120] mm, compaction: move high_pfn to the for loop scope Greg Kroah-Hartman
@ 2021-02-08 15:01 ` Greg Kroah-Hartman
2021-02-08 15:01 ` [PATCH 5.10 104/120] mm: thp: fix MADV_REMOVE deadlock on shmem THP Greg Kroah-Hartman
` (23 subsequent siblings)
126 siblings, 0 replies; 140+ messages in thread
From: Greg Kroah-Hartman @ 2021-02-08 15:01 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Rick Edgecombe, Matthew Wilcox,
Miaohe Lin, Christoph Hellwig, Daniel Axtens, Andrew Morton,
Linus Torvalds
From: Rick Edgecombe <rick.p.edgecombe@intel.com>
commit 4f6ec8602341e97b364e4e0d41a1ed08148f5e98 upstream.
When VM_MAP_PUT_PAGES was added, it was defined with the same value as
VM_FLUSH_RESET_PERMS. This doesn't seem like it will cause any big
functional problems other than some excess flushing for VM_MAP_PUT_PAGES
allocations.
Redefine VM_MAP_PUT_PAGES to have its own value. Also, rearrange things
so flags are less likely to be missed in the future.
Link: https://lkml.kernel.org/r/20210122233706.9304-1-rick.p.edgecombe@intel.com
Fixes: b944afc9d64d ("mm: add a VM_MAP_PUT_PAGES flag for vmap")
Signed-off-by: Rick Edgecombe <rick.p.edgecombe@intel.com>
Suggested-by: Matthew Wilcox <willy@infradead.org>
Cc: Miaohe Lin <linmiaohe@huawei.com>
Cc: Christoph Hellwig <hch@lst.de>
Cc: Daniel Axtens <dja@axtens.net>
Cc: <stable@vger.kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
include/linux/vmalloc.h | 9 ++-------
1 file changed, 2 insertions(+), 7 deletions(-)
--- a/include/linux/vmalloc.h
+++ b/include/linux/vmalloc.h
@@ -24,7 +24,8 @@ struct notifier_block; /* in notifier.h
#define VM_UNINITIALIZED 0x00000020 /* vm_struct is not fully initialized */
#define VM_NO_GUARD 0x00000040 /* don't add guard page */
#define VM_KASAN 0x00000080 /* has allocated kasan shadow memory */
-#define VM_MAP_PUT_PAGES 0x00000100 /* put pages and free array in vfree */
+#define VM_FLUSH_RESET_PERMS 0x00000100 /* reset direct map and flush TLB on unmap, can't be freed in atomic context */
+#define VM_MAP_PUT_PAGES 0x00000200 /* put pages and free array in vfree */
/*
* VM_KASAN is used slighly differently depending on CONFIG_KASAN_VMALLOC.
@@ -37,12 +38,6 @@ struct notifier_block; /* in notifier.h
* determine which allocations need the module shadow freed.
*/
-/*
- * Memory with VM_FLUSH_RESET_PERMS cannot be freed in an interrupt or with
- * vfree_atomic().
- */
-#define VM_FLUSH_RESET_PERMS 0x00000100 /* Reset direct map and flush TLB on unmap */
-
/* bits [20..32] reserved for arch specific ioremap internals */
/*
^ permalink raw reply [flat|nested] 140+ messages in thread* [PATCH 5.10 104/120] mm: thp: fix MADV_REMOVE deadlock on shmem THP
2021-02-08 14:59 [PATCH 5.10 000/120] 5.10.15-rc1 review Greg Kroah-Hartman
` (102 preceding siblings ...)
2021-02-08 15:01 ` [PATCH 5.10 103/120] mm/vmalloc: separate put pages and flush VM flags Greg Kroah-Hartman
@ 2021-02-08 15:01 ` Greg Kroah-Hartman
2021-02-08 15:01 ` [PATCH 5.10 105/120] mm/filemap: add missing mem_cgroup_uncharge() to __add_to_page_cache_locked() Greg Kroah-Hartman
` (22 subsequent siblings)
126 siblings, 0 replies; 140+ messages in thread
From: Greg Kroah-Hartman @ 2021-02-08 15:01 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Hugh Dickins, Sergey Senozhatsky,
Andrea Arcangeli, Andrew Morton, Linus Torvalds
From: Hugh Dickins <hughd@google.com>
commit 1c2f67308af4c102b4e1e6cd6f69819ae59408e0 upstream.
Sergey reported deadlock between kswapd correctly doing its usual
lock_page(page) followed by down_read(page->mapping->i_mmap_rwsem), and
madvise(MADV_REMOVE) on an madvise(MADV_HUGEPAGE) area doing
down_write(page->mapping->i_mmap_rwsem) followed by lock_page(page).
This happened when shmem_fallocate(punch hole)'s unmap_mapping_range()
reaches zap_pmd_range()'s call to __split_huge_pmd(). The same deadlock
could occur when partially truncating a mapped huge tmpfs file, or using
fallocate(FALLOC_FL_PUNCH_HOLE) on it.
__split_huge_pmd()'s page lock was added in 5.8, to make sure that any
concurrent use of reuse_swap_page() (holding page lock) could not catch
the anon THP's mapcounts and swapcounts while they were being split.
Fortunately, reuse_swap_page() is never applied to a shmem or file THP
(not even by khugepaged, which checks PageSwapCache before calling), and
anonymous THPs are never created in shmem or file areas: so that
__split_huge_pmd()'s page lock can only be necessary for anonymous THPs,
on which there is no risk of deadlock with i_mmap_rwsem.
Link: https://lkml.kernel.org/r/alpine.LSU.2.11.2101161409470.2022@eggly.anvils
Fixes: c444eb564fb1 ("mm: thp: make the THP mapcount atomic against __split_huge_pmd_locked()")
Signed-off-by: Hugh Dickins <hughd@google.com>
Reported-by: Sergey Senozhatsky <sergey.senozhatsky.work@gmail.com>
Reviewed-by: Andrea Arcangeli <aarcange@redhat.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
mm/huge_memory.c | 37 +++++++++++++++++++++++--------------
1 file changed, 23 insertions(+), 14 deletions(-)
--- a/mm/huge_memory.c
+++ b/mm/huge_memory.c
@@ -2188,7 +2188,7 @@ void __split_huge_pmd(struct vm_area_str
{
spinlock_t *ptl;
struct mmu_notifier_range range;
- bool was_locked = false;
+ bool do_unlock_page = false;
pmd_t _pmd;
mmu_notifier_range_init(&range, MMU_NOTIFY_CLEAR, 0, vma, vma->vm_mm,
@@ -2204,7 +2204,6 @@ void __split_huge_pmd(struct vm_area_str
VM_BUG_ON(freeze && !page);
if (page) {
VM_WARN_ON_ONCE(!PageLocked(page));
- was_locked = true;
if (page != pmd_page(*pmd))
goto out;
}
@@ -2213,19 +2212,29 @@ repeat:
if (pmd_trans_huge(*pmd)) {
if (!page) {
page = pmd_page(*pmd);
- if (unlikely(!trylock_page(page))) {
- get_page(page);
- _pmd = *pmd;
- spin_unlock(ptl);
- lock_page(page);
- spin_lock(ptl);
- if (unlikely(!pmd_same(*pmd, _pmd))) {
- unlock_page(page);
+ /*
+ * An anonymous page must be locked, to ensure that a
+ * concurrent reuse_swap_page() sees stable mapcount;
+ * but reuse_swap_page() is not used on shmem or file,
+ * and page lock must not be taken when zap_pmd_range()
+ * calls __split_huge_pmd() while i_mmap_lock is held.
+ */
+ if (PageAnon(page)) {
+ if (unlikely(!trylock_page(page))) {
+ get_page(page);
+ _pmd = *pmd;
+ spin_unlock(ptl);
+ lock_page(page);
+ spin_lock(ptl);
+ if (unlikely(!pmd_same(*pmd, _pmd))) {
+ unlock_page(page);
+ put_page(page);
+ page = NULL;
+ goto repeat;
+ }
put_page(page);
- page = NULL;
- goto repeat;
}
- put_page(page);
+ do_unlock_page = true;
}
}
if (PageMlocked(page))
@@ -2235,7 +2244,7 @@ repeat:
__split_huge_pmd_locked(vma, pmd, range.start, freeze);
out:
spin_unlock(ptl);
- if (!was_locked && page)
+ if (do_unlock_page)
unlock_page(page);
/*
* No need to double call mmu_notifier->invalidate_range() callback.
^ permalink raw reply [flat|nested] 140+ messages in thread* [PATCH 5.10 105/120] mm/filemap: add missing mem_cgroup_uncharge() to __add_to_page_cache_locked()
2021-02-08 14:59 [PATCH 5.10 000/120] 5.10.15-rc1 review Greg Kroah-Hartman
` (103 preceding siblings ...)
2021-02-08 15:01 ` [PATCH 5.10 104/120] mm: thp: fix MADV_REMOVE deadlock on shmem THP Greg Kroah-Hartman
@ 2021-02-08 15:01 ` Greg Kroah-Hartman
2021-02-08 15:01 ` [PATCH 5.10 106/120] x86/build: Disable CET instrumentation in the kernel Greg Kroah-Hartman
` (21 subsequent siblings)
126 siblings, 0 replies; 140+ messages in thread
From: Greg Kroah-Hartman @ 2021-02-08 15:01 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Waiman Long, Alex Shi,
Johannes Weiner, Matthew Wilcox, Miaohe Lin, Muchun Song,
Michal Hocko, Andrew Morton, Linus Torvalds
From: Waiman Long <longman@redhat.com>
commit da74240eb3fcd806edb1643874363e954d9e948b upstream.
Commit 3fea5a499d57 ("mm: memcontrol: convert page cache to a new
mem_cgroup_charge() API") introduced a bug in __add_to_page_cache_locked()
causing the following splat:
page dumped because: VM_BUG_ON_PAGE(page_memcg(page))
pages's memcg:ffff8889a4116000
------------[ cut here ]------------
kernel BUG at mm/memcontrol.c:2924!
invalid opcode: 0000 [#1] SMP KASAN PTI
CPU: 35 PID: 12345 Comm: cat Tainted: G S W I 5.11.0-rc4-debug+ #1
Hardware name: HP HP Z8 G4 Workstation/81C7, BIOS P60 v01.25 12/06/2017
RIP: commit_charge+0xf4/0x130
Call Trace:
mem_cgroup_charge+0x175/0x770
__add_to_page_cache_locked+0x712/0xad0
add_to_page_cache_lru+0xc5/0x1f0
cachefiles_read_or_alloc_pages+0x895/0x2e10 [cachefiles]
__fscache_read_or_alloc_pages+0x6c0/0xa00 [fscache]
__nfs_readpages_from_fscache+0x16d/0x630 [nfs]
nfs_readpages+0x24e/0x540 [nfs]
read_pages+0x5b1/0xc40
page_cache_ra_unbounded+0x460/0x750
generic_file_buffered_read_get_pages+0x290/0x1710
generic_file_buffered_read+0x2a9/0xc30
nfs_file_read+0x13f/0x230 [nfs]
new_sync_read+0x3af/0x610
vfs_read+0x339/0x4b0
ksys_read+0xf1/0x1c0
do_syscall_64+0x33/0x40
entry_SYSCALL_64_after_hwframe+0x44/0xa9
Before that commit, there was a try_charge() and commit_charge() in
__add_to_page_cache_locked(). These two separated charge functions were
replaced by a single mem_cgroup_charge(). However, it forgot to add a
matching mem_cgroup_uncharge() when the xarray insertion failed with the
page released back to the pool.
Fix this by adding a mem_cgroup_uncharge() call when insertion error
happens.
Link: https://lkml.kernel.org/r/20210125042441.20030-1-longman@redhat.com
Fixes: 3fea5a499d57 ("mm: memcontrol: convert page cache to a new mem_cgroup_charge() API")
Signed-off-by: Waiman Long <longman@redhat.com>
Reviewed-by: Alex Shi <alex.shi@linux.alibaba.com>
Acked-by: Johannes Weiner <hannes@cmpxchg.org>
Cc: Matthew Wilcox <willy@infradead.org>
Cc: Miaohe Lin <linmiaohe@huawei.com>
Cc: Muchun Song <smuchun@gmail.com>
Cc: Michal Hocko <mhocko@suse.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
mm/filemap.c | 4 ++++
1 file changed, 4 insertions(+)
--- a/mm/filemap.c
+++ b/mm/filemap.c
@@ -835,6 +835,7 @@ noinline int __add_to_page_cache_locked(
XA_STATE(xas, &mapping->i_pages, offset);
int huge = PageHuge(page);
int error;
+ bool charged = false;
VM_BUG_ON_PAGE(!PageLocked(page), page);
VM_BUG_ON_PAGE(PageSwapBacked(page), page);
@@ -848,6 +849,7 @@ noinline int __add_to_page_cache_locked(
error = mem_cgroup_charge(page, current->mm, gfp);
if (error)
goto error;
+ charged = true;
}
gfp &= GFP_RECLAIM_MASK;
@@ -896,6 +898,8 @@ unlock:
if (xas_error(&xas)) {
error = xas_error(&xas);
+ if (charged)
+ mem_cgroup_uncharge(page);
goto error;
}
^ permalink raw reply [flat|nested] 140+ messages in thread* [PATCH 5.10 106/120] x86/build: Disable CET instrumentation in the kernel
2021-02-08 14:59 [PATCH 5.10 000/120] 5.10.15-rc1 review Greg Kroah-Hartman
` (104 preceding siblings ...)
2021-02-08 15:01 ` [PATCH 5.10 105/120] mm/filemap: add missing mem_cgroup_uncharge() to __add_to_page_cache_locked() Greg Kroah-Hartman
@ 2021-02-08 15:01 ` Greg Kroah-Hartman
2021-02-08 15:01 ` [PATCH 5.10 107/120] x86/debug: Fix DR6 handling Greg Kroah-Hartman
` (20 subsequent siblings)
126 siblings, 0 replies; 140+ messages in thread
From: Greg Kroah-Hartman @ 2021-02-08 15:01 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Nikolay Borisov, Josh Poimboeuf,
Borislav Petkov, Seth Forshee, Masahiro Yamada
From: Josh Poimboeuf <jpoimboe@redhat.com>
commit 20bf2b378729c4a0366a53e2018a0b70ace94bcd upstream.
With retpolines disabled, some configurations of GCC, and specifically
the GCC versions 9 and 10 in Ubuntu will add Intel CET instrumentation
to the kernel by default. That breaks certain tracing scenarios by
adding a superfluous ENDBR64 instruction before the fentry call, for
functions which can be called indirectly.
CET instrumentation isn't currently necessary in the kernel, as CET is
only supported in user space. Disable it unconditionally and move it
into the x86's Makefile as CET/CFI... enablement should be a per-arch
decision anyway.
[ bp: Massage and extend commit message. ]
Fixes: 29be86d7f9cb ("kbuild: add -fcf-protection=none when using retpoline flags")
Reported-by: Nikolay Borisov <nborisov@suse.com>
Signed-off-by: Josh Poimboeuf <jpoimboe@redhat.com>
Signed-off-by: Borislav Petkov <bp@suse.de>
Reviewed-by: Nikolay Borisov <nborisov@suse.com>
Tested-by: Nikolay Borisov <nborisov@suse.com>
Cc: <stable@vger.kernel.org>
Cc: Seth Forshee <seth.forshee@canonical.com>
Cc: Masahiro Yamada <yamada.masahiro@socionext.com>
Link: https://lkml.kernel.org/r/20210128215219.6kct3h2eiustncws@treble
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
Makefile | 6 ------
arch/x86/Makefile | 3 +++
2 files changed, 3 insertions(+), 6 deletions(-)
--- a/Makefile
+++ b/Makefile
@@ -950,12 +950,6 @@ KBUILD_CFLAGS += $(call cc-option,-Wer
# change __FILE__ to the relative path from the srctree
KBUILD_CPPFLAGS += $(call cc-option,-fmacro-prefix-map=$(srctree)/=)
-# ensure -fcf-protection is disabled when using retpoline as it is
-# incompatible with -mindirect-branch=thunk-extern
-ifdef CONFIG_RETPOLINE
-KBUILD_CFLAGS += $(call cc-option,-fcf-protection=none)
-endif
-
# include additional Makefiles when needed
include-y := scripts/Makefile.extrawarn
include-$(CONFIG_KASAN) += scripts/Makefile.kasan
--- a/arch/x86/Makefile
+++ b/arch/x86/Makefile
@@ -127,6 +127,9 @@ else
KBUILD_CFLAGS += -mno-red-zone
KBUILD_CFLAGS += -mcmodel=kernel
+
+ # Intel CET isn't enabled in the kernel
+ KBUILD_CFLAGS += $(call cc-option,-fcf-protection=none)
endif
ifdef CONFIG_X86_X32
^ permalink raw reply [flat|nested] 140+ messages in thread* [PATCH 5.10 107/120] x86/debug: Fix DR6 handling
2021-02-08 14:59 [PATCH 5.10 000/120] 5.10.15-rc1 review Greg Kroah-Hartman
` (105 preceding siblings ...)
2021-02-08 15:01 ` [PATCH 5.10 106/120] x86/build: Disable CET instrumentation in the kernel Greg Kroah-Hartman
@ 2021-02-08 15:01 ` Greg Kroah-Hartman
2021-02-08 15:01 ` [PATCH 5.10 108/120] x86/debug: Prevent data breakpoints on __per_cpu_offset Greg Kroah-Hartman
` (19 subsequent siblings)
126 siblings, 0 replies; 140+ messages in thread
From: Greg Kroah-Hartman @ 2021-02-08 15:01 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Tom de Vries, Peter Zijlstra (Intel),
Borislav Petkov
From: Peter Zijlstra <peterz@infradead.org>
commit 9ad22e165994ccb64d85b68499eaef97342c175b upstream.
Tom reported that one of the GDB test-cases failed, and Boris bisected
it to commit:
d53d9bc0cf78 ("x86/debug: Change thread.debugreg6 to thread.virtual_dr6")
The debugging session led us to commit:
6c0aca288e72 ("x86: Ignore trap bits on single step exceptions")
It turns out that TF and data breakpoints are both traps and will be
merged, while instruction breakpoints are faults and will not be merged.
This means 6c0aca288e72 is wrong, only TF and instruction breakpoints
need to be excluded while TF and data breakpoints can be merged.
[ bp: Massage commit message. ]
Fixes: d53d9bc0cf78 ("x86/debug: Change thread.debugreg6 to thread.virtual_dr6")
Fixes: 6c0aca288e72 ("x86: Ignore trap bits on single step exceptions")
Reported-by: Tom de Vries <tdevries@suse.de>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Signed-off-by: Borislav Petkov <bp@suse.de>
Cc: <stable@vger.kernel.org>
Link: https://lkml.kernel.org/r/YBMAbQGACujjfz%2Bi@hirez.programming.kicks-ass.net
Link: https://lkml.kernel.org/r/20210128211627.GB4348@worktop.programming.kicks-ass.net
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
arch/x86/kernel/hw_breakpoint.c | 39 ++++++++++++++++++---------------------
1 file changed, 18 insertions(+), 21 deletions(-)
--- a/arch/x86/kernel/hw_breakpoint.c
+++ b/arch/x86/kernel/hw_breakpoint.c
@@ -491,15 +491,12 @@ static int hw_breakpoint_handler(struct
struct perf_event *bp;
unsigned long *dr6_p;
unsigned long dr6;
+ bool bpx;
/* The DR6 value is pointed by args->err */
dr6_p = (unsigned long *)ERR_PTR(args->err);
dr6 = *dr6_p;
- /* If it's a single step, TRAP bits are random */
- if (dr6 & DR_STEP)
- return NOTIFY_DONE;
-
/* Do an early return if no trap bits are set in DR6 */
if ((dr6 & DR_TRAP_BITS) == 0)
return NOTIFY_DONE;
@@ -509,28 +506,29 @@ static int hw_breakpoint_handler(struct
if (likely(!(dr6 & (DR_TRAP0 << i))))
continue;
+ bp = this_cpu_read(bp_per_reg[i]);
+ if (!bp)
+ continue;
+
+ bpx = bp->hw.info.type == X86_BREAKPOINT_EXECUTE;
+
/*
- * The counter may be concurrently released but that can only
- * occur from a call_rcu() path. We can then safely fetch
- * the breakpoint, use its callback, touch its counter
- * while we are in an rcu_read_lock() path.
+ * TF and data breakpoints are traps and can be merged, however
+ * instruction breakpoints are faults and will be raised
+ * separately.
+ *
+ * However DR6 can indicate both TF and instruction
+ * breakpoints. In that case take TF as that has precedence and
+ * delay the instruction breakpoint for the next exception.
*/
- rcu_read_lock();
+ if (bpx && (dr6 & DR_STEP))
+ continue;
- bp = this_cpu_read(bp_per_reg[i]);
/*
* Reset the 'i'th TRAP bit in dr6 to denote completion of
* exception handling
*/
(*dr6_p) &= ~(DR_TRAP0 << i);
- /*
- * bp can be NULL due to lazy debug register switching
- * or due to concurrent perf counter removing.
- */
- if (!bp) {
- rcu_read_unlock();
- break;
- }
perf_bp_event(bp, args->regs);
@@ -538,11 +536,10 @@ static int hw_breakpoint_handler(struct
* Set up resume flag to avoid breakpoint recursion when
* returning back to origin.
*/
- if (bp->hw.info.type == X86_BREAKPOINT_EXECUTE)
+ if (bpx)
args->regs->flags |= X86_EFLAGS_RF;
-
- rcu_read_unlock();
}
+
/*
* Further processing in do_debug() is needed for a) user-space
* breakpoints (to generate signals) and b) when the system has
^ permalink raw reply [flat|nested] 140+ messages in thread* [PATCH 5.10 108/120] x86/debug: Prevent data breakpoints on __per_cpu_offset
2021-02-08 14:59 [PATCH 5.10 000/120] 5.10.15-rc1 review Greg Kroah-Hartman
` (106 preceding siblings ...)
2021-02-08 15:01 ` [PATCH 5.10 107/120] x86/debug: Fix DR6 handling Greg Kroah-Hartman
@ 2021-02-08 15:01 ` Greg Kroah-Hartman
2021-02-08 15:01 ` [PATCH 5.10 109/120] x86/debug: Prevent data breakpoints on cpu_dr7 Greg Kroah-Hartman
` (18 subsequent siblings)
126 siblings, 0 replies; 140+ messages in thread
From: Greg Kroah-Hartman @ 2021-02-08 15:01 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, Lai Jiangshan, Thomas Gleixner
From: Lai Jiangshan <laijs@linux.alibaba.com>
commit c4bed4b96918ff1d062ee81fdae4d207da4fa9b0 upstream.
When FSGSBASE is enabled, paranoid_entry() fetches the per-CPU GSBASE value
via __per_cpu_offset or pcpu_unit_offsets.
When a data breakpoint is set on __per_cpu_offset[cpu] (read-write
operation), the specific CPU will be stuck in an infinite #DB loop.
RCU will try to send an NMI to the specific CPU, but it is not working
either since NMI also relies on paranoid_entry(). Which means it's
undebuggable.
Fixes: eaad981291ee3("x86/entry/64: Introduce the FIND_PERCPU_BASE macro")
Signed-off-by: Lai Jiangshan <laijs@linux.alibaba.com>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Cc: stable@vger.kernel.org
Link: https://lore.kernel.org/r/20210204152708.21308-1-jiangshanlai@gmail.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
arch/x86/kernel/hw_breakpoint.c | 14 ++++++++++++++
1 file changed, 14 insertions(+)
--- a/arch/x86/kernel/hw_breakpoint.c
+++ b/arch/x86/kernel/hw_breakpoint.c
@@ -269,6 +269,20 @@ static inline bool within_cpu_entry(unsi
CPU_ENTRY_AREA_TOTAL_SIZE))
return true;
+ /*
+ * When FSGSBASE is enabled, paranoid_entry() fetches the per-CPU
+ * GSBASE value via __per_cpu_offset or pcpu_unit_offsets.
+ */
+#ifdef CONFIG_SMP
+ if (within_area(addr, end, (unsigned long)__per_cpu_offset,
+ sizeof(unsigned long) * nr_cpu_ids))
+ return true;
+#else
+ if (within_area(addr, end, (unsigned long)&pcpu_unit_offsets,
+ sizeof(pcpu_unit_offsets)))
+ return true;
+#endif
+
for_each_possible_cpu(cpu) {
/* The original rw GDT is being used after load_direct_gdt() */
if (within_area(addr, end, (unsigned long)get_cpu_gdt_rw(cpu),
^ permalink raw reply [flat|nested] 140+ messages in thread* [PATCH 5.10 109/120] x86/debug: Prevent data breakpoints on cpu_dr7
2021-02-08 14:59 [PATCH 5.10 000/120] 5.10.15-rc1 review Greg Kroah-Hartman
` (107 preceding siblings ...)
2021-02-08 15:01 ` [PATCH 5.10 108/120] x86/debug: Prevent data breakpoints on __per_cpu_offset Greg Kroah-Hartman
@ 2021-02-08 15:01 ` Greg Kroah-Hartman
2021-02-08 15:01 ` [PATCH 5.10 110/120] x86/apic: Add extra serialization for non-serializing MSRs Greg Kroah-Hartman
` (17 subsequent siblings)
126 siblings, 0 replies; 140+ messages in thread
From: Greg Kroah-Hartman @ 2021-02-08 15:01 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, Lai Jiangshan, Thomas Gleixner
From: Lai Jiangshan <laijs@linux.alibaba.com>
commit 3943abf2dbfae9ea4d2da05c1db569a0603f76da upstream.
local_db_save() is called at the start of exc_debug_kernel(), reads DR7 and
disables breakpoints to prevent recursion.
When running in a guest (X86_FEATURE_HYPERVISOR), local_db_save() reads the
per-cpu variable cpu_dr7 to check whether a breakpoint is active or not
before it accesses DR7.
A data breakpoint on cpu_dr7 therefore results in infinite #DB recursion.
Disallow data breakpoints on cpu_dr7 to prevent that.
Fixes: 84b6a3491567a("x86/entry: Optimize local_db_save() for virt")
Signed-off-by: Lai Jiangshan <laijs@linux.alibaba.com>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Cc: stable@vger.kernel.org
Link: https://lore.kernel.org/r/20210204152708.21308-2-jiangshanlai@gmail.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
arch/x86/kernel/hw_breakpoint.c | 8 ++++++++
1 file changed, 8 insertions(+)
--- a/arch/x86/kernel/hw_breakpoint.c
+++ b/arch/x86/kernel/hw_breakpoint.c
@@ -307,6 +307,14 @@ static inline bool within_cpu_entry(unsi
(unsigned long)&per_cpu(cpu_tlbstate, cpu),
sizeof(struct tlb_state)))
return true;
+
+ /*
+ * When in guest (X86_FEATURE_HYPERVISOR), local_db_save()
+ * will read per-cpu cpu_dr7 before clear dr7 register.
+ */
+ if (within_area(addr, end, (unsigned long)&per_cpu(cpu_dr7, cpu),
+ sizeof(cpu_dr7)))
+ return true;
}
return false;
^ permalink raw reply [flat|nested] 140+ messages in thread* [PATCH 5.10 110/120] x86/apic: Add extra serialization for non-serializing MSRs
2021-02-08 14:59 [PATCH 5.10 000/120] 5.10.15-rc1 review Greg Kroah-Hartman
` (108 preceding siblings ...)
2021-02-08 15:01 ` [PATCH 5.10 109/120] x86/debug: Prevent data breakpoints on cpu_dr7 Greg Kroah-Hartman
@ 2021-02-08 15:01 ` Greg Kroah-Hartman
2021-02-08 15:01 ` [PATCH 5.10 111/120] Input: goodix - add support for Goodix GT9286 chip Greg Kroah-Hartman
` (16 subsequent siblings)
126 siblings, 0 replies; 140+ messages in thread
From: Greg Kroah-Hartman @ 2021-02-08 15:01 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Jan Kiszka, Dave Hansen,
Borislav Petkov, Peter Zijlstra (Intel),
Thomas Gleixner
From: Dave Hansen <dave.hansen@linux.intel.com>
commit 25a068b8e9a4eb193d755d58efcb3c98928636e0 upstream.
Jan Kiszka reported that the x2apic_wrmsr_fence() function uses a plain
MFENCE while the Intel SDM (10.12.3 MSR Access in x2APIC Mode) calls for
MFENCE; LFENCE.
Short summary: we have special MSRs that have weaker ordering than all
the rest. Add fencing consistent with current SDM recommendations.
This is not known to cause any issues in practice, only in theory.
Longer story below:
The reason the kernel uses a different semantic is that the SDM changed
(roughly in late 2017). The SDM changed because folks at Intel were
auditing all of the recommended fences in the SDM and realized that the
x2apic fences were insufficient.
Why was the pain MFENCE judged insufficient?
WRMSR itself is normally a serializing instruction. No fences are needed
because the instruction itself serializes everything.
But, there are explicit exceptions for this serializing behavior written
into the WRMSR instruction documentation for two classes of MSRs:
IA32_TSC_DEADLINE and the X2APIC MSRs.
Back to x2apic: WRMSR is *not* serializing in this specific case.
But why is MFENCE insufficient? MFENCE makes writes visible, but
only affects load/store instructions. WRMSR is unfortunately not a
load/store instruction and is unaffected by MFENCE. This means that a
non-serializing WRMSR could be reordered by the CPU to execute before
the writes made visible by the MFENCE have even occurred in the first
place.
This means that an x2apic IPI could theoretically be triggered before
there is any (visible) data to process.
Does this affect anything in practice? I honestly don't know. It seems
quite possible that by the time an interrupt gets to consume the (not
yet) MFENCE'd data, it has become visible, mostly by accident.
To be safe, add the SDM-recommended fences for all x2apic WRMSRs.
This also leaves open the question of the _other_ weakly-ordered WRMSR:
MSR_IA32_TSC_DEADLINE. While it has the same ordering architecture as
the x2APIC MSRs, it seems substantially less likely to be a problem in
practice. While writes to the in-memory Local Vector Table (LVT) might
theoretically be reordered with respect to a weakly-ordered WRMSR like
TSC_DEADLINE, the SDM has this to say:
In x2APIC mode, the WRMSR instruction is used to write to the LVT
entry. The processor ensures the ordering of this write and any
subsequent WRMSR to the deadline; no fencing is required.
But, that might still leave xAPIC exposed. The safest thing to do for
now is to add the extra, recommended LFENCE.
[ bp: Massage commit message, fix typos, drop accidentally added
newline to tools/arch/x86/include/asm/barrier.h. ]
Reported-by: Jan Kiszka <jan.kiszka@siemens.com>
Signed-off-by: Dave Hansen <dave.hansen@linux.intel.com>
Signed-off-by: Borislav Petkov <bp@suse.de>
Acked-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Acked-by: Thomas Gleixner <tglx@linutronix.de>
Cc: <stable@vger.kernel.org>
Link: https://lkml.kernel.org/r/20200305174708.F77040DD@viggo.jf.intel.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
arch/x86/include/asm/apic.h | 10 ----------
arch/x86/include/asm/barrier.h | 18 ++++++++++++++++++
arch/x86/kernel/apic/apic.c | 4 ++++
arch/x86/kernel/apic/x2apic_cluster.c | 6 ++++--
arch/x86/kernel/apic/x2apic_phys.c | 9 ++++++---
5 files changed, 32 insertions(+), 15 deletions(-)
--- a/arch/x86/include/asm/apic.h
+++ b/arch/x86/include/asm/apic.h
@@ -197,16 +197,6 @@ static inline bool apic_needs_pit(void)
#endif /* !CONFIG_X86_LOCAL_APIC */
#ifdef CONFIG_X86_X2APIC
-/*
- * Make previous memory operations globally visible before
- * sending the IPI through x2apic wrmsr. We need a serializing instruction or
- * mfence for this.
- */
-static inline void x2apic_wrmsr_fence(void)
-{
- asm volatile("mfence" : : : "memory");
-}
-
static inline void native_apic_msr_write(u32 reg, u32 v)
{
if (reg == APIC_DFR || reg == APIC_ID || reg == APIC_LDR ||
--- a/arch/x86/include/asm/barrier.h
+++ b/arch/x86/include/asm/barrier.h
@@ -84,4 +84,22 @@ do { \
#include <asm-generic/barrier.h>
+/*
+ * Make previous memory operations globally visible before
+ * a WRMSR.
+ *
+ * MFENCE makes writes visible, but only affects load/store
+ * instructions. WRMSR is unfortunately not a load/store
+ * instruction and is unaffected by MFENCE. The LFENCE ensures
+ * that the WRMSR is not reordered.
+ *
+ * Most WRMSRs are full serializing instructions themselves and
+ * do not require this barrier. This is only required for the
+ * IA32_TSC_DEADLINE and X2APIC MSRs.
+ */
+static inline void weak_wrmsr_fence(void)
+{
+ asm volatile("mfence; lfence" : : : "memory");
+}
+
#endif /* _ASM_X86_BARRIER_H */
--- a/arch/x86/kernel/apic/apic.c
+++ b/arch/x86/kernel/apic/apic.c
@@ -41,6 +41,7 @@
#include <asm/perf_event.h>
#include <asm/x86_init.h>
#include <linux/atomic.h>
+#include <asm/barrier.h>
#include <asm/mpspec.h>
#include <asm/i8259.h>
#include <asm/proto.h>
@@ -472,6 +473,9 @@ static int lapic_next_deadline(unsigned
{
u64 tsc;
+ /* This MSR is special and need a special fence: */
+ weak_wrmsr_fence();
+
tsc = rdtsc();
wrmsrl(MSR_IA32_TSC_DEADLINE, tsc + (((u64) delta) * TSC_DIVISOR));
return 0;
--- a/arch/x86/kernel/apic/x2apic_cluster.c
+++ b/arch/x86/kernel/apic/x2apic_cluster.c
@@ -29,7 +29,8 @@ static void x2apic_send_IPI(int cpu, int
{
u32 dest = per_cpu(x86_cpu_to_logical_apicid, cpu);
- x2apic_wrmsr_fence();
+ /* x2apic MSRs are special and need a special fence: */
+ weak_wrmsr_fence();
__x2apic_send_IPI_dest(dest, vector, APIC_DEST_LOGICAL);
}
@@ -41,7 +42,8 @@ __x2apic_send_IPI_mask(const struct cpum
unsigned long flags;
u32 dest;
- x2apic_wrmsr_fence();
+ /* x2apic MSRs are special and need a special fence: */
+ weak_wrmsr_fence();
local_irq_save(flags);
tmpmsk = this_cpu_cpumask_var_ptr(ipi_mask);
--- a/arch/x86/kernel/apic/x2apic_phys.c
+++ b/arch/x86/kernel/apic/x2apic_phys.c
@@ -43,7 +43,8 @@ static void x2apic_send_IPI(int cpu, int
{
u32 dest = per_cpu(x86_cpu_to_apicid, cpu);
- x2apic_wrmsr_fence();
+ /* x2apic MSRs are special and need a special fence: */
+ weak_wrmsr_fence();
__x2apic_send_IPI_dest(dest, vector, APIC_DEST_PHYSICAL);
}
@@ -54,7 +55,8 @@ __x2apic_send_IPI_mask(const struct cpum
unsigned long this_cpu;
unsigned long flags;
- x2apic_wrmsr_fence();
+ /* x2apic MSRs are special and need a special fence: */
+ weak_wrmsr_fence();
local_irq_save(flags);
@@ -125,7 +127,8 @@ void __x2apic_send_IPI_shorthand(int vec
{
unsigned long cfg = __prepare_ICR(which, vector, 0);
- x2apic_wrmsr_fence();
+ /* x2apic MSRs are special and need a special fence: */
+ weak_wrmsr_fence();
native_x2apic_icr_write(cfg, 0);
}
^ permalink raw reply [flat|nested] 140+ messages in thread* [PATCH 5.10 111/120] Input: goodix - add support for Goodix GT9286 chip
2021-02-08 14:59 [PATCH 5.10 000/120] 5.10.15-rc1 review Greg Kroah-Hartman
` (109 preceding siblings ...)
2021-02-08 15:01 ` [PATCH 5.10 110/120] x86/apic: Add extra serialization for non-serializing MSRs Greg Kroah-Hartman
@ 2021-02-08 15:01 ` Greg Kroah-Hartman
2021-02-08 15:01 ` [PATCH 5.10 112/120] Input: xpad - sync supported devices with fork on GitHub Greg Kroah-Hartman
` (15 subsequent siblings)
126 siblings, 0 replies; 140+ messages in thread
From: Greg Kroah-Hartman @ 2021-02-08 15:01 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, AngeloGioacchino Del Regno,
Bastien Nocera, Dmitry Torokhov
From: AngeloGioacchino Del Regno <angelogioacchino.delregno@somainline.org>
commit 2dce6db70c77bbe639f5cd9cc796fb8f2694a7d0 upstream.
The Goodix GT9286 is a capacitive touch sensor IC based on GT1x.
This chip can be found on a number of smartphones, including the
F(x)tec Pro 1 and the Elephone U.
This has been tested on F(x)Tec Pro1 (MSM8998).
Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@somainline.org>
Link: https://lore.kernel.org/r/20210109135512.149032-2-angelogioacchino.delregno@somainline.org
Reviewed-by: Bastien Nocera <hadess@hadess.net>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/input/touchscreen/goodix.c | 2 ++
1 file changed, 2 insertions(+)
--- a/drivers/input/touchscreen/goodix.c
+++ b/drivers/input/touchscreen/goodix.c
@@ -157,6 +157,7 @@ static const struct goodix_chip_id goodi
{ .id = "5663", .data = >1x_chip_data },
{ .id = "5688", .data = >1x_chip_data },
{ .id = "917S", .data = >1x_chip_data },
+ { .id = "9286", .data = >1x_chip_data },
{ .id = "911", .data = >911_chip_data },
{ .id = "9271", .data = >911_chip_data },
@@ -1445,6 +1446,7 @@ static const struct of_device_id goodix_
{ .compatible = "goodix,gt927" },
{ .compatible = "goodix,gt9271" },
{ .compatible = "goodix,gt928" },
+ { .compatible = "goodix,gt9286" },
{ .compatible = "goodix,gt967" },
{ }
};
^ permalink raw reply [flat|nested] 140+ messages in thread* [PATCH 5.10 112/120] Input: xpad - sync supported devices with fork on GitHub
2021-02-08 14:59 [PATCH 5.10 000/120] 5.10.15-rc1 review Greg Kroah-Hartman
` (110 preceding siblings ...)
2021-02-08 15:01 ` [PATCH 5.10 111/120] Input: goodix - add support for Goodix GT9286 chip Greg Kroah-Hartman
@ 2021-02-08 15:01 ` Greg Kroah-Hartman
2021-02-08 15:01 ` [PATCH 5.10 113/120] Input: ili210x - implement pressure reporting for ILI251x Greg Kroah-Hartman
` (14 subsequent siblings)
126 siblings, 0 replies; 140+ messages in thread
From: Greg Kroah-Hartman @ 2021-02-08 15:01 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Benjamin Valentin, Dmitry Torokhov
From: Benjamin Valentin <benpicco@googlemail.com>
commit 9bbd77d5bbc9aff8cb74d805c31751f5f0691ba8 upstream.
There is a fork of this driver on GitHub [0] that has been updated
with new device IDs.
Merge those into the mainline driver, so the out-of-tree fork is not
needed for users of those devices anymore.
[0] https://github.com/paroj/xpad
Signed-off-by: Benjamin Valentin <benpicco@googlemail.com>
Link: https://lore.kernel.org/r/20210121142523.1b6b050f@rechenknecht2k11
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/input/joystick/xpad.c | 17 ++++++++++++++++-
1 file changed, 16 insertions(+), 1 deletion(-)
--- a/drivers/input/joystick/xpad.c
+++ b/drivers/input/joystick/xpad.c
@@ -215,9 +215,17 @@ static const struct xpad_device {
{ 0x0e6f, 0x0213, "Afterglow Gamepad for Xbox 360", 0, XTYPE_XBOX360 },
{ 0x0e6f, 0x021f, "Rock Candy Gamepad for Xbox 360", 0, XTYPE_XBOX360 },
{ 0x0e6f, 0x0246, "Rock Candy Gamepad for Xbox One 2015", 0, XTYPE_XBOXONE },
- { 0x0e6f, 0x02ab, "PDP Controller for Xbox One", 0, XTYPE_XBOXONE },
+ { 0x0e6f, 0x02a0, "PDP Xbox One Controller", 0, XTYPE_XBOXONE },
+ { 0x0e6f, 0x02a1, "PDP Xbox One Controller", 0, XTYPE_XBOXONE },
+ { 0x0e6f, 0x02a2, "PDP Wired Controller for Xbox One - Crimson Red", 0, XTYPE_XBOXONE },
{ 0x0e6f, 0x02a4, "PDP Wired Controller for Xbox One - Stealth Series", 0, XTYPE_XBOXONE },
{ 0x0e6f, 0x02a6, "PDP Wired Controller for Xbox One - Camo Series", 0, XTYPE_XBOXONE },
+ { 0x0e6f, 0x02a7, "PDP Xbox One Controller", 0, XTYPE_XBOXONE },
+ { 0x0e6f, 0x02a8, "PDP Xbox One Controller", 0, XTYPE_XBOXONE },
+ { 0x0e6f, 0x02ab, "PDP Controller for Xbox One", 0, XTYPE_XBOXONE },
+ { 0x0e6f, 0x02ad, "PDP Wired Controller for Xbox One - Stealth Series", 0, XTYPE_XBOXONE },
+ { 0x0e6f, 0x02b3, "Afterglow Prismatic Wired Controller", 0, XTYPE_XBOXONE },
+ { 0x0e6f, 0x02b8, "Afterglow Prismatic Wired Controller", 0, XTYPE_XBOXONE },
{ 0x0e6f, 0x0301, "Logic3 Controller", 0, XTYPE_XBOX360 },
{ 0x0e6f, 0x0346, "Rock Candy Gamepad for Xbox One 2016", 0, XTYPE_XBOXONE },
{ 0x0e6f, 0x0401, "Logic3 Controller", 0, XTYPE_XBOX360 },
@@ -296,6 +304,9 @@ static const struct xpad_device {
{ 0x1bad, 0xfa01, "MadCatz GamePad", 0, XTYPE_XBOX360 },
{ 0x1bad, 0xfd00, "Razer Onza TE", 0, XTYPE_XBOX360 },
{ 0x1bad, 0xfd01, "Razer Onza", 0, XTYPE_XBOX360 },
+ { 0x20d6, 0x2001, "BDA Xbox Series X Wired Controller", 0, XTYPE_XBOXONE },
+ { 0x20d6, 0x281f, "PowerA Wired Controller For Xbox 360", 0, XTYPE_XBOX360 },
+ { 0x2e24, 0x0652, "Hyperkin Duke X-Box One pad", 0, XTYPE_XBOXONE },
{ 0x24c6, 0x5000, "Razer Atrox Arcade Stick", MAP_TRIGGERS_TO_BUTTONS, XTYPE_XBOX360 },
{ 0x24c6, 0x5300, "PowerA MINI PROEX Controller", 0, XTYPE_XBOX360 },
{ 0x24c6, 0x5303, "Xbox Airflo wired controller", 0, XTYPE_XBOX360 },
@@ -429,8 +440,12 @@ static const struct usb_device_id xpad_t
XPAD_XBOX360_VENDOR(0x162e), /* Joytech X-Box 360 controllers */
XPAD_XBOX360_VENDOR(0x1689), /* Razer Onza */
XPAD_XBOX360_VENDOR(0x1bad), /* Harminix Rock Band Guitar and Drums */
+ XPAD_XBOX360_VENDOR(0x20d6), /* PowerA Controllers */
+ XPAD_XBOXONE_VENDOR(0x20d6), /* PowerA Controllers */
XPAD_XBOX360_VENDOR(0x24c6), /* PowerA Controllers */
XPAD_XBOXONE_VENDOR(0x24c6), /* PowerA Controllers */
+ XPAD_XBOXONE_VENDOR(0x2e24), /* Hyperkin Duke X-Box One pad */
+ XPAD_XBOX360_VENDOR(0x2f24), /* GameSir Controllers */
{ }
};
^ permalink raw reply [flat|nested] 140+ messages in thread* [PATCH 5.10 113/120] Input: ili210x - implement pressure reporting for ILI251x
2021-02-08 14:59 [PATCH 5.10 000/120] 5.10.15-rc1 review Greg Kroah-Hartman
` (111 preceding siblings ...)
2021-02-08 15:01 ` [PATCH 5.10 112/120] Input: xpad - sync supported devices with fork on GitHub Greg Kroah-Hartman
@ 2021-02-08 15:01 ` Greg Kroah-Hartman
2021-02-08 15:01 ` [PATCH 5.10 114/120] md: Set prev_flush_start and flush_bio in an atomic way Greg Kroah-Hartman
` (13 subsequent siblings)
126 siblings, 0 replies; 140+ messages in thread
From: Greg Kroah-Hartman @ 2021-02-08 15:01 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, Marek Vasut, Dmitry Torokhov
From: Marek Vasut <marex@denx.de>
commit 60159e9e7bc7e528c103b6b6d47dfd83af29669c upstream.
The ILI251x seems to report pressure information in the 5th byte of
each per-finger touch data element. On the available hardware, this
information has the values ranging from 0x0 to 0xa, which is also
matching the downstream example code. Report pressure information
on the ILI251x.
Signed-off-by: Marek Vasut <marex@denx.de>
Link: https://lore.kernel.org/r/20201224071238.160098-1-marex@denx.de
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/input/touchscreen/ili210x.c | 26 +++++++++++++++++++-------
1 file changed, 19 insertions(+), 7 deletions(-)
--- a/drivers/input/touchscreen/ili210x.c
+++ b/drivers/input/touchscreen/ili210x.c
@@ -29,11 +29,13 @@ struct ili2xxx_chip {
void *buf, size_t len);
int (*get_touch_data)(struct i2c_client *client, u8 *data);
bool (*parse_touch_data)(const u8 *data, unsigned int finger,
- unsigned int *x, unsigned int *y);
+ unsigned int *x, unsigned int *y,
+ unsigned int *z);
bool (*continue_polling)(const u8 *data, bool touch);
unsigned int max_touches;
unsigned int resolution;
bool has_calibrate_reg;
+ bool has_pressure_reg;
};
struct ili210x {
@@ -82,7 +84,8 @@ static int ili210x_read_touch_data(struc
static bool ili210x_touchdata_to_coords(const u8 *touchdata,
unsigned int finger,
- unsigned int *x, unsigned int *y)
+ unsigned int *x, unsigned int *y,
+ unsigned int *z)
{
if (touchdata[0] & BIT(finger))
return false;
@@ -137,7 +140,8 @@ static int ili211x_read_touch_data(struc
static bool ili211x_touchdata_to_coords(const u8 *touchdata,
unsigned int finger,
- unsigned int *x, unsigned int *y)
+ unsigned int *x, unsigned int *y,
+ unsigned int *z)
{
u32 data;
@@ -169,7 +173,8 @@ static const struct ili2xxx_chip ili211x
static bool ili212x_touchdata_to_coords(const u8 *touchdata,
unsigned int finger,
- unsigned int *x, unsigned int *y)
+ unsigned int *x, unsigned int *y,
+ unsigned int *z)
{
u16 val;
@@ -235,7 +240,8 @@ static int ili251x_read_touch_data(struc
static bool ili251x_touchdata_to_coords(const u8 *touchdata,
unsigned int finger,
- unsigned int *x, unsigned int *y)
+ unsigned int *x, unsigned int *y,
+ unsigned int *z)
{
u16 val;
@@ -245,6 +251,7 @@ static bool ili251x_touchdata_to_coords(
*x = val & 0x3fff;
*y = get_unaligned_be16(touchdata + 1 + (finger * 5) + 2);
+ *z = touchdata[1 + (finger * 5) + 4];
return true;
}
@@ -261,6 +268,7 @@ static const struct ili2xxx_chip ili251x
.continue_polling = ili251x_check_continue_polling,
.max_touches = 10,
.has_calibrate_reg = true,
+ .has_pressure_reg = true,
};
static bool ili210x_report_events(struct ili210x *priv, u8 *touchdata)
@@ -268,14 +276,16 @@ static bool ili210x_report_events(struct
struct input_dev *input = priv->input;
int i;
bool contact = false, touch;
- unsigned int x = 0, y = 0;
+ unsigned int x = 0, y = 0, z = 0;
for (i = 0; i < priv->chip->max_touches; i++) {
- touch = priv->chip->parse_touch_data(touchdata, i, &x, &y);
+ touch = priv->chip->parse_touch_data(touchdata, i, &x, &y, &z);
input_mt_slot(input, i);
if (input_mt_report_slot_state(input, MT_TOOL_FINGER, touch)) {
touchscreen_report_pos(input, &priv->prop, x, y, true);
+ if (priv->chip->has_pressure_reg)
+ input_report_abs(input, ABS_MT_PRESSURE, z);
contact = true;
}
}
@@ -437,6 +447,8 @@ static int ili210x_i2c_probe(struct i2c_
max_xy = (chip->resolution ?: SZ_64K) - 1;
input_set_abs_params(input, ABS_MT_POSITION_X, 0, max_xy, 0, 0);
input_set_abs_params(input, ABS_MT_POSITION_Y, 0, max_xy, 0, 0);
+ if (priv->chip->has_pressure_reg)
+ input_set_abs_params(input, ABS_MT_PRESSURE, 0, 0xa, 0, 0);
touchscreen_parse_properties(input, true, &priv->prop);
error = input_mt_init_slots(input, priv->chip->max_touches,
^ permalink raw reply [flat|nested] 140+ messages in thread* [PATCH 5.10 114/120] md: Set prev_flush_start and flush_bio in an atomic way
2021-02-08 14:59 [PATCH 5.10 000/120] 5.10.15-rc1 review Greg Kroah-Hartman
` (112 preceding siblings ...)
2021-02-08 15:01 ` [PATCH 5.10 113/120] Input: ili210x - implement pressure reporting for ILI251x Greg Kroah-Hartman
@ 2021-02-08 15:01 ` Greg Kroah-Hartman
2021-02-08 15:01 ` [PATCH 5.10 115/120] igc: Report speed and duplex as unknown when device is runtime suspended Greg Kroah-Hartman
` (12 subsequent siblings)
126 siblings, 0 replies; 140+ messages in thread
From: Greg Kroah-Hartman @ 2021-02-08 15:01 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, David Jeffery, Xiao Ni, Song Liu, Jack Wang
From: Xiao Ni <xni@redhat.com>
commit dc5d17a3c39b06aef866afca19245a9cfb533a79 upstream.
One customer reports a crash problem which causes by flush request. It
triggers a warning before crash.
/* new request after previous flush is completed */
if (ktime_after(req_start, mddev->prev_flush_start)) {
WARN_ON(mddev->flush_bio);
mddev->flush_bio = bio;
bio = NULL;
}
The WARN_ON is triggered. We use spin lock to protect prev_flush_start and
flush_bio in md_flush_request. But there is no lock protection in
md_submit_flush_data. It can set flush_bio to NULL first because of
compiler reordering write instructions.
For example, flush bio1 sets flush bio to NULL first in
md_submit_flush_data. An interrupt or vmware causing an extended stall
happen between updating flush_bio and prev_flush_start. Because flush_bio
is NULL, flush bio2 can get the lock and submit to underlayer disks. Then
flush bio1 updates prev_flush_start after the interrupt or extended stall.
Then flush bio3 enters in md_flush_request. The start time req_start is
behind prev_flush_start. The flush_bio is not NULL(flush bio2 hasn't
finished). So it can trigger the WARN_ON now. Then it calls INIT_WORK
again. INIT_WORK() will re-initialize the list pointers in the
work_struct, which then can result in a corrupted work list and the
work_struct queued a second time. With the work list corrupted, it can
lead in invalid work items being used and cause a crash in
process_one_work.
We need to make sure only one flush bio can be handled at one same time.
So add spin lock in md_submit_flush_data to protect prev_flush_start and
flush_bio in an atomic way.
Reviewed-by: David Jeffery <djeffery@redhat.com>
Signed-off-by: Xiao Ni <xni@redhat.com>
Signed-off-by: Song Liu <songliubraving@fb.com>
Signed-off-by: Jack Wang <jinpu.wang@cloud.ionos.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/md/md.c | 2 ++
1 file changed, 2 insertions(+)
--- a/drivers/md/md.c
+++ b/drivers/md/md.c
@@ -639,8 +639,10 @@ static void md_submit_flush_data(struct
* could wait for this and below md_handle_request could wait for those
* bios because of suspend check
*/
+ spin_lock_irq(&mddev->lock);
mddev->last_flush = mddev->start_flush;
mddev->flush_bio = NULL;
+ spin_unlock_irq(&mddev->lock);
wake_up(&mddev->sb_wait);
if (bio->bi_iter.bi_size == 0) {
^ permalink raw reply [flat|nested] 140+ messages in thread* [PATCH 5.10 115/120] igc: Report speed and duplex as unknown when device is runtime suspended
2021-02-08 14:59 [PATCH 5.10 000/120] 5.10.15-rc1 review Greg Kroah-Hartman
` (113 preceding siblings ...)
2021-02-08 15:01 ` [PATCH 5.10 114/120] md: Set prev_flush_start and flush_bio in an atomic way Greg Kroah-Hartman
@ 2021-02-08 15:01 ` Greg Kroah-Hartman
2021-02-08 15:01 ` [PATCH 5.10 116/120] neighbour: Prevent a dead entry from updating gc_list Greg Kroah-Hartman
` (11 subsequent siblings)
126 siblings, 0 replies; 140+ messages in thread
From: Greg Kroah-Hartman @ 2021-02-08 15:01 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Kai-Heng Feng, Sasha Neftin, Tony Nguyen
From: Kai-Heng Feng <kai.heng.feng@canonical.com>
commit 2e99dedc73f004f650b197c9b269c15c7e01ad15 upstream.
Similar to commit 165ae7a8feb5 ("igb: Report speed and duplex as unknown
when device is runtime suspended"), if we try to read speed and duplex
sysfs while the device is runtime suspended, igc will complain and
stops working:
[ 123.449883] igc 0000:03:00.0 enp3s0: PCIe link lost, device now detached
[ 123.450052] BUG: kernel NULL pointer dereference, address: 0000000000000008
[ 123.450056] #PF: supervisor read access in kernel mode
[ 123.450058] #PF: error_code(0x0000) - not-present page
[ 123.450059] PGD 0 P4D 0
[ 123.450064] Oops: 0000 [#1] SMP NOPTI
[ 123.450068] CPU: 0 PID: 2525 Comm: udevadm Tainted: G U W OE 5.10.0-1002-oem #2+rkl2-Ubuntu
[ 123.450078] RIP: 0010:igc_rd32+0x1c/0x90 [igc]
[ 123.450080] Code: c0 5d c3 b8 fd ff ff ff c3 0f 1f 44 00 00 0f 1f 44 00 00 55 89 f0 48 89 e5 41 56 41 55 41 54 49 89 c4 53 48 8b 57 08 48 01 d0 <44> 8b 28 41 83 fd ff 74 0c 5b 44 89 e8 41 5c 41 5d 4
[ 123.450083] RSP: 0018:ffffb0d100d6fcc0 EFLAGS: 00010202
[ 123.450085] RAX: 0000000000000008 RBX: ffffb0d100d6fd30 RCX: 0000000000000000
[ 123.450087] RDX: 0000000000000000 RSI: 0000000000000008 RDI: ffff945a12716c10
[ 123.450089] RBP: ffffb0d100d6fce0 R08: ffff945a12716550 R09: ffff945a09874000
[ 123.450090] R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000008
[ 123.450092] R13: ffff945a12716000 R14: ffff945a037da280 R15: ffff945a037da290
[ 123.450094] FS: 00007f3b34c868c0(0000) GS:ffff945b89200000(0000) knlGS:0000000000000000
[ 123.450096] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 123.450098] CR2: 0000000000000008 CR3: 00000001144de006 CR4: 0000000000770ef0
[ 123.450100] PKRU: 55555554
[ 123.450101] Call Trace:
[ 123.450111] igc_ethtool_get_link_ksettings+0xd6/0x1b0 [igc]
[ 123.450118] __ethtool_get_link_ksettings+0x71/0xb0
[ 123.450123] duplex_show+0x74/0xc0
[ 123.450129] dev_attr_show+0x1d/0x40
[ 123.450134] sysfs_kf_seq_show+0xa1/0x100
[ 123.450137] kernfs_seq_show+0x27/0x30
[ 123.450142] seq_read+0xb7/0x400
[ 123.450148] ? common_file_perm+0x72/0x170
[ 123.450151] kernfs_fop_read+0x35/0x1b0
[ 123.450155] vfs_read+0xb5/0x1b0
[ 123.450157] ksys_read+0x67/0xe0
[ 123.450160] __x64_sys_read+0x1a/0x20
[ 123.450164] do_syscall_64+0x38/0x90
[ 123.450168] entry_SYSCALL_64_after_hwframe+0x44/0xa9
[ 123.450170] RIP: 0033:0x7f3b351fe142
[ 123.450173] Code: c0 e9 c2 fe ff ff 50 48 8d 3d 3a ca 0a 00 e8 f5 19 02 00 0f 1f 44 00 00 f3 0f 1e fa 64 8b 04 25 18 00 00 00 85 c0 75 10 0f 05 <48> 3d 00 f0 ff ff 77 56 c3 0f 1f 44 00 00 48 83 ec 28 48 89 54 24
[ 123.450174] RSP: 002b:00007fffef2ec138 EFLAGS: 00000246 ORIG_RAX: 0000000000000000
[ 123.450177] RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007f3b351fe142
[ 123.450179] RDX: 0000000000001001 RSI: 00005644c047f070 RDI: 0000000000000003
[ 123.450180] RBP: 00007fffef2ec340 R08: 00005644c047f070 R09: 00007f3b352d9320
[ 123.450182] R10: 00005644c047c010 R11: 0000000000000246 R12: 00005644c047cbf0
[ 123.450184] R13: 00005644c047e6d0 R14: 0000000000000003 R15: 00007fffef2ec140
[ 123.450189] Modules linked in: rfcomm ccm cmac algif_hash algif_skcipher af_alg bnep toshiba_acpi industrialio toshiba_haps hp_accel lis3lv02d btusb btrtl btbcm btintel bluetooth ecdh_generic ecc joydev input_leds nls_iso8859_1 snd_sof_pci snd_sof_intel_byt snd_sof_intel_ipc snd_sof_intel_hda_common snd_soc_hdac_hda snd_hda_codec_hdmi snd_sof_xtensa_dsp snd_sof_intel_hda snd_sof snd_hda_ext_core snd_soc_acpi_intel_match snd_soc_acpi snd_hda_codec_realtek snd_hda_codec_generic ledtrig_audio snd_hda_intel snd_intel_dspcfg soundwire_intel soundwire_generic_allocation soundwire_cadence snd_hda_codec snd_hda_core ath10k_pci snd_hwdep intel_rapl_msr intel_rapl_common ath10k_core soundwire_bus snd_soc_core x86_pkg_temp_thermal ath intel_powerclamp snd_compress ac97_bus snd_pcm_dmaengine mac80211 snd_pcm coretemp snd_seq_midi snd_seq_midi_event snd_rawmidi kvm_intel cfg80211 snd_seq snd_seq_device snd_timer mei_hdcp kvm libarc4 snd crct10dif_pclmul ghash_clmulni_intel aesni_intel
mei_me dell_wmi
[ 123.450266] dell_smbios soundcore sparse_keymap dcdbas crypto_simd cryptd mei dell_uart_backlight glue_helper ee1004 wmi_bmof intel_wmi_thunderbolt dell_wmi_descriptor mac_hid efi_pstore acpi_pad acpi_tad intel_cstate sch_fq_codel parport_pc ppdev lp parport ip_tables x_tables autofs4 btrfs blake2b_generic raid10 raid456 async_raid6_recov async_memcpy async_pq async_xor async_tx xor raid6_pq libcrc32c raid1 raid0 multipath linear dm_mirror dm_region_hash dm_log hid_generic usbhid hid i915 i2c_algo_bit drm_kms_helper syscopyarea sysfillrect sysimgblt fb_sys_fops cec crc32_pclmul rc_core drm intel_lpss_pci i2c_i801 ahci igc intel_lpss i2c_smbus idma64 xhci_pci libahci virt_dma xhci_pci_renesas wmi video pinctrl_tigerlake
[ 123.450335] CR2: 0000000000000008
[ 123.450338] ---[ end trace 9f731e38b53c35cc ]---
The more generic approach will be wrap get_link_ksettings() with begin()
and complete() callbacks, and calls runtime resume and runtime suspend
routine respectively. However, igc is like igb, runtime resume routine
uses rtnl_lock() which upper ethtool layer also uses.
So to prevent a deadlock on rtnl, take a different approach, use
pm_runtime_suspended() to avoid reading register while device is runtime
suspended.
Fixes: 8c5ad0dae93c ("igc: Add ethtool support")
Signed-off-by: Kai-Heng Feng <kai.heng.feng@canonical.com>
Acked-by: Sasha Neftin <sasha.neftin@intel.com>
Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/net/ethernet/intel/igc/igc_ethtool.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
--- a/drivers/net/ethernet/intel/igc/igc_ethtool.c
+++ b/drivers/net/ethernet/intel/igc/igc_ethtool.c
@@ -1714,7 +1714,8 @@ static int igc_ethtool_get_link_ksetting
Asym_Pause);
}
- status = rd32(IGC_STATUS);
+ status = pm_runtime_suspended(&adapter->pdev->dev) ?
+ 0 : rd32(IGC_STATUS);
if (status & IGC_STATUS_LU) {
if (status & IGC_STATUS_SPEED_1000) {
^ permalink raw reply [flat|nested] 140+ messages in thread* [PATCH 5.10 116/120] neighbour: Prevent a dead entry from updating gc_list
2021-02-08 14:59 [PATCH 5.10 000/120] 5.10.15-rc1 review Greg Kroah-Hartman
` (114 preceding siblings ...)
2021-02-08 15:01 ` [PATCH 5.10 115/120] igc: Report speed and duplex as unknown when device is runtime suspended Greg Kroah-Hartman
@ 2021-02-08 15:01 ` Greg Kroah-Hartman
2021-02-08 15:01 ` [PATCH 5.10 117/120] net: ip_tunnel: fix mtu calculation Greg Kroah-Hartman
` (10 subsequent siblings)
126 siblings, 0 replies; 140+ messages in thread
From: Greg Kroah-Hartman @ 2021-02-08 15:01 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Chinmay Agarwal, Cong Wang,
David Ahern, Jakub Kicinski
From: Chinmay Agarwal <chinagar@codeaurora.org>
commit eb4e8fac00d1e01ada5e57c05d24739156086677 upstream.
Following race condition was detected:
<CPU A, t0> - neigh_flush_dev() is under execution and calls
neigh_mark_dead(n) marking the neighbour entry 'n' as dead.
<CPU B, t1> - Executing: __netif_receive_skb() ->
__netif_receive_skb_core() -> arp_rcv() -> arp_process().arp_process()
calls __neigh_lookup() which takes a reference on neighbour entry 'n'.
<CPU A, t2> - Moves further along neigh_flush_dev() and calls
neigh_cleanup_and_release(n), but since reference count increased in t2,
'n' couldn't be destroyed.
<CPU B, t3> - Moves further along, arp_process() and calls
neigh_update()-> __neigh_update() -> neigh_update_gc_list(), which adds
the neighbour entry back in gc_list(neigh_mark_dead(), removed it
earlier in t0 from gc_list)
<CPU B, t4> - arp_process() finally calls neigh_release(n), destroying
the neighbour entry.
This leads to 'n' still being part of gc_list, but the actual
neighbour structure has been freed.
The situation can be prevented from happening if we disallow a dead
entry to have any possibility of updating gc_list. This is what the
patch intends to achieve.
Fixes: 9c29a2f55ec0 ("neighbor: Fix locking order for gc_list changes")
Signed-off-by: Chinmay Agarwal <chinagar@codeaurora.org>
Reviewed-by: Cong Wang <xiyou.wangcong@gmail.com>
Reviewed-by: David Ahern <dsahern@kernel.org>
Link: https://lore.kernel.org/r/20210127165453.GA20514@chinagar-linux.qualcomm.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
net/core/neighbour.c | 7 ++++---
1 file changed, 4 insertions(+), 3 deletions(-)
--- a/net/core/neighbour.c
+++ b/net/core/neighbour.c
@@ -1245,13 +1245,14 @@ static int __neigh_update(struct neighbo
old = neigh->nud_state;
err = -EPERM;
- if (!(flags & NEIGH_UPDATE_F_ADMIN) &&
- (old & (NUD_NOARP | NUD_PERMANENT)))
- goto out;
if (neigh->dead) {
NL_SET_ERR_MSG(extack, "Neighbor entry is now dead");
+ new = old;
goto out;
}
+ if (!(flags & NEIGH_UPDATE_F_ADMIN) &&
+ (old & (NUD_NOARP | NUD_PERMANENT)))
+ goto out;
ext_learn_change = neigh_update_ext_learned(neigh, flags, ¬ify);
^ permalink raw reply [flat|nested] 140+ messages in thread* [PATCH 5.10 117/120] net: ip_tunnel: fix mtu calculation
2021-02-08 14:59 [PATCH 5.10 000/120] 5.10.15-rc1 review Greg Kroah-Hartman
` (115 preceding siblings ...)
2021-02-08 15:01 ` [PATCH 5.10 116/120] neighbour: Prevent a dead entry from updating gc_list Greg Kroah-Hartman
@ 2021-02-08 15:01 ` Greg Kroah-Hartman
2021-02-08 15:01 ` [PATCH 5.10 118/120] udp: ipv4: manipulate network header of NATed UDP GRO fraglist Greg Kroah-Hartman
` (9 subsequent siblings)
126 siblings, 0 replies; 140+ messages in thread
From: Greg Kroah-Hartman @ 2021-02-08 15:01 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Slava Bacherikov, Vadim Fedorenko,
Jakub Kicinski
From: Vadim Fedorenko <vfedorenko@novek.ru>
commit 28e104d00281ade30250b24e098bf50887671ea4 upstream.
dev->hard_header_len for tunnel interface is set only when header_ops
are set too and already contains full overhead of any tunnel encapsulation.
That's why there is not need to use this overhead twice in mtu calc.
Fixes: fdafed459998 ("ip_gre: set dev->hard_header_len and dev->needed_headroom properly")
Reported-by: Slava Bacherikov <mail@slava.cc>
Signed-off-by: Vadim Fedorenko <vfedorenko@novek.ru>
Link: https://lore.kernel.org/r/1611959267-20536-1-git-send-email-vfedorenko@novek.ru
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
net/ipv4/ip_tunnel.c | 16 +++++++---------
1 file changed, 7 insertions(+), 9 deletions(-)
--- a/net/ipv4/ip_tunnel.c
+++ b/net/ipv4/ip_tunnel.c
@@ -317,7 +317,7 @@ static int ip_tunnel_bind_dev(struct net
}
dev->needed_headroom = t_hlen + hlen;
- mtu -= (dev->hard_header_len + t_hlen);
+ mtu -= t_hlen;
if (mtu < IPV4_MIN_MTU)
mtu = IPV4_MIN_MTU;
@@ -347,7 +347,7 @@ static struct ip_tunnel *ip_tunnel_creat
nt = netdev_priv(dev);
t_hlen = nt->hlen + sizeof(struct iphdr);
dev->min_mtu = ETH_MIN_MTU;
- dev->max_mtu = IP_MAX_MTU - dev->hard_header_len - t_hlen;
+ dev->max_mtu = IP_MAX_MTU - t_hlen;
ip_tunnel_add(itn, nt);
return nt;
@@ -488,11 +488,10 @@ static int tnl_update_pmtu(struct net_de
int mtu;
tunnel_hlen = md ? tunnel_hlen : tunnel->hlen;
- pkt_size = skb->len - tunnel_hlen - dev->hard_header_len;
+ pkt_size = skb->len - tunnel_hlen;
if (df)
- mtu = dst_mtu(&rt->dst) - dev->hard_header_len
- - sizeof(struct iphdr) - tunnel_hlen;
+ mtu = dst_mtu(&rt->dst) - (sizeof(struct iphdr) + tunnel_hlen);
else
mtu = skb_valid_dst(skb) ? dst_mtu(skb_dst(skb)) : dev->mtu;
@@ -972,7 +971,7 @@ int __ip_tunnel_change_mtu(struct net_de
{
struct ip_tunnel *tunnel = netdev_priv(dev);
int t_hlen = tunnel->hlen + sizeof(struct iphdr);
- int max_mtu = IP_MAX_MTU - dev->hard_header_len - t_hlen;
+ int max_mtu = IP_MAX_MTU - t_hlen;
if (new_mtu < ETH_MIN_MTU)
return -EINVAL;
@@ -1149,10 +1148,9 @@ int ip_tunnel_newlink(struct net_device
mtu = ip_tunnel_bind_dev(dev);
if (tb[IFLA_MTU]) {
- unsigned int max = IP_MAX_MTU - dev->hard_header_len - nt->hlen;
+ unsigned int max = IP_MAX_MTU - (nt->hlen + sizeof(struct iphdr));
- mtu = clamp(dev->mtu, (unsigned int)ETH_MIN_MTU,
- (unsigned int)(max - sizeof(struct iphdr)));
+ mtu = clamp(dev->mtu, (unsigned int)ETH_MIN_MTU, max);
}
err = dev_set_mtu(dev, mtu);
^ permalink raw reply [flat|nested] 140+ messages in thread* [PATCH 5.10 118/120] udp: ipv4: manipulate network header of NATed UDP GRO fraglist
2021-02-08 14:59 [PATCH 5.10 000/120] 5.10.15-rc1 review Greg Kroah-Hartman
` (116 preceding siblings ...)
2021-02-08 15:01 ` [PATCH 5.10 117/120] net: ip_tunnel: fix mtu calculation Greg Kroah-Hartman
@ 2021-02-08 15:01 ` Greg Kroah-Hartman
2021-02-08 15:01 ` [PATCH 5.10 119/120] net: dsa: mv88e6xxx: override existent unicast portvec in port_fdb_add Greg Kroah-Hartman
` (8 subsequent siblings)
126 siblings, 0 replies; 140+ messages in thread
From: Greg Kroah-Hartman @ 2021-02-08 15:01 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Dongseok Yi, Steffen Klassert,
Jakub Kicinski
From: Dongseok Yi <dseok.yi@samsung.com>
commit c3df39ac9b0e3747bf8233ea9ce4ed5ceb3199d3 upstream.
UDP/IP header of UDP GROed frag_skbs are not updated even after NAT
forwarding. Only the header of head_skb from ip_finish_output_gso ->
skb_gso_segment is updated but following frag_skbs are not updated.
A call path skb_mac_gso_segment -> inet_gso_segment ->
udp4_ufo_fragment -> __udp_gso_segment -> __udp_gso_segment_list
does not try to update UDP/IP header of the segment list but copy
only the MAC header.
Update port, addr and check of each skb of the segment list in
__udp_gso_segment_list. It covers both SNAT and DNAT.
Fixes: 9fd1ff5d2ac7 (udp: Support UDP fraglist GRO/GSO.)
Signed-off-by: Dongseok Yi <dseok.yi@samsung.com>
Acked-by: Steffen Klassert <steffen.klassert@secunet.com>
Link: https://lore.kernel.org/r/1611962007-80092-1-git-send-email-dseok.yi@samsung.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
include/net/udp.h | 2 -
net/ipv4/udp_offload.c | 69 +++++++++++++++++++++++++++++++++++++++++++++----
net/ipv6/udp_offload.c | 2 -
3 files changed, 66 insertions(+), 7 deletions(-)
--- a/include/net/udp.h
+++ b/include/net/udp.h
@@ -178,7 +178,7 @@ struct sk_buff *udp_gro_receive(struct l
int udp_gro_complete(struct sk_buff *skb, int nhoff, udp_lookup_t lookup);
struct sk_buff *__udp_gso_segment(struct sk_buff *gso_skb,
- netdev_features_t features);
+ netdev_features_t features, bool is_ipv6);
static inline struct udphdr *udp_gro_udphdr(struct sk_buff *skb)
{
--- a/net/ipv4/udp_offload.c
+++ b/net/ipv4/udp_offload.c
@@ -184,8 +184,67 @@ out_unlock:
}
EXPORT_SYMBOL(skb_udp_tunnel_segment);
+static void __udpv4_gso_segment_csum(struct sk_buff *seg,
+ __be32 *oldip, __be32 *newip,
+ __be16 *oldport, __be16 *newport)
+{
+ struct udphdr *uh;
+ struct iphdr *iph;
+
+ if (*oldip == *newip && *oldport == *newport)
+ return;
+
+ uh = udp_hdr(seg);
+ iph = ip_hdr(seg);
+
+ if (uh->check) {
+ inet_proto_csum_replace4(&uh->check, seg, *oldip, *newip,
+ true);
+ inet_proto_csum_replace2(&uh->check, seg, *oldport, *newport,
+ false);
+ if (!uh->check)
+ uh->check = CSUM_MANGLED_0;
+ }
+ *oldport = *newport;
+
+ csum_replace4(&iph->check, *oldip, *newip);
+ *oldip = *newip;
+}
+
+static struct sk_buff *__udpv4_gso_segment_list_csum(struct sk_buff *segs)
+{
+ struct sk_buff *seg;
+ struct udphdr *uh, *uh2;
+ struct iphdr *iph, *iph2;
+
+ seg = segs;
+ uh = udp_hdr(seg);
+ iph = ip_hdr(seg);
+
+ if ((udp_hdr(seg)->dest == udp_hdr(seg->next)->dest) &&
+ (udp_hdr(seg)->source == udp_hdr(seg->next)->source) &&
+ (ip_hdr(seg)->daddr == ip_hdr(seg->next)->daddr) &&
+ (ip_hdr(seg)->saddr == ip_hdr(seg->next)->saddr))
+ return segs;
+
+ while ((seg = seg->next)) {
+ uh2 = udp_hdr(seg);
+ iph2 = ip_hdr(seg);
+
+ __udpv4_gso_segment_csum(seg,
+ &iph2->saddr, &iph->saddr,
+ &uh2->source, &uh->source);
+ __udpv4_gso_segment_csum(seg,
+ &iph2->daddr, &iph->daddr,
+ &uh2->dest, &uh->dest);
+ }
+
+ return segs;
+}
+
static struct sk_buff *__udp_gso_segment_list(struct sk_buff *skb,
- netdev_features_t features)
+ netdev_features_t features,
+ bool is_ipv6)
{
unsigned int mss = skb_shinfo(skb)->gso_size;
@@ -195,11 +254,11 @@ static struct sk_buff *__udp_gso_segment
udp_hdr(skb)->len = htons(sizeof(struct udphdr) + mss);
- return skb;
+ return is_ipv6 ? skb : __udpv4_gso_segment_list_csum(skb);
}
struct sk_buff *__udp_gso_segment(struct sk_buff *gso_skb,
- netdev_features_t features)
+ netdev_features_t features, bool is_ipv6)
{
struct sock *sk = gso_skb->sk;
unsigned int sum_truesize = 0;
@@ -211,7 +270,7 @@ struct sk_buff *__udp_gso_segment(struct
__be16 newlen;
if (skb_shinfo(gso_skb)->gso_type & SKB_GSO_FRAGLIST)
- return __udp_gso_segment_list(gso_skb, features);
+ return __udp_gso_segment_list(gso_skb, features, is_ipv6);
mss = skb_shinfo(gso_skb)->gso_size;
if (gso_skb->len <= sizeof(*uh) + mss)
@@ -325,7 +384,7 @@ static struct sk_buff *udp4_ufo_fragment
goto out;
if (skb_shinfo(skb)->gso_type & SKB_GSO_UDP_L4)
- return __udp_gso_segment(skb, features);
+ return __udp_gso_segment(skb, features, false);
mss = skb_shinfo(skb)->gso_size;
if (unlikely(skb->len <= mss))
--- a/net/ipv6/udp_offload.c
+++ b/net/ipv6/udp_offload.c
@@ -46,7 +46,7 @@ static struct sk_buff *udp6_ufo_fragment
goto out;
if (skb_shinfo(skb)->gso_type & SKB_GSO_UDP_L4)
- return __udp_gso_segment(skb, features);
+ return __udp_gso_segment(skb, features, true);
/* Do software UFO. Complete and fill in the UDP checksum as HW cannot
* do checksum of UDP packets sent as multiple IP fragments.
^ permalink raw reply [flat|nested] 140+ messages in thread* [PATCH 5.10 119/120] net: dsa: mv88e6xxx: override existent unicast portvec in port_fdb_add
2021-02-08 14:59 [PATCH 5.10 000/120] 5.10.15-rc1 review Greg Kroah-Hartman
` (117 preceding siblings ...)
2021-02-08 15:01 ` [PATCH 5.10 118/120] udp: ipv4: manipulate network header of NATed UDP GRO fraglist Greg Kroah-Hartman
@ 2021-02-08 15:01 ` Greg Kroah-Hartman
2021-02-08 15:01 ` [PATCH 5.10 120/120] net: sched: replaced invalid qdisc tree flush helper in qdisc_replace Greg Kroah-Hartman
` (7 subsequent siblings)
126 siblings, 0 replies; 140+ messages in thread
From: Greg Kroah-Hartman @ 2021-02-08 15:01 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, DENG Qingfang, Vladimir Oltean,
Jakub Kicinski
From: DENG Qingfang <dqfext@gmail.com>
commit f72f2fb8fb6be095b98af5d740ac50cffd0b0cae upstream.
Having multiple destination ports for a unicast address does not make
sense.
Make port_db_load_purge override existent unicast portvec instead of
adding a new port bit.
Fixes: 884729399260 ("net: dsa: mv88e6xxx: handle multiple ports in ATU")
Signed-off-by: DENG Qingfang <dqfext@gmail.com>
Reviewed-by: Vladimir Oltean <olteanv@gmail.com>
Link: https://lore.kernel.org/r/20210130134334.10243-1-dqfext@gmail.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/net/dsa/mv88e6xxx/chip.c | 6 +++++-
1 file changed, 5 insertions(+), 1 deletion(-)
--- a/drivers/net/dsa/mv88e6xxx/chip.c
+++ b/drivers/net/dsa/mv88e6xxx/chip.c
@@ -1669,7 +1669,11 @@ static int mv88e6xxx_port_db_load_purge(
if (!entry.portvec)
entry.state = 0;
} else {
- entry.portvec |= BIT(port);
+ if (state == MV88E6XXX_G1_ATU_DATA_STATE_UC_STATIC)
+ entry.portvec = BIT(port);
+ else
+ entry.portvec |= BIT(port);
+
entry.state = state;
}
^ permalink raw reply [flat|nested] 140+ messages in thread* [PATCH 5.10 120/120] net: sched: replaced invalid qdisc tree flush helper in qdisc_replace
2021-02-08 14:59 [PATCH 5.10 000/120] 5.10.15-rc1 review Greg Kroah-Hartman
` (118 preceding siblings ...)
2021-02-08 15:01 ` [PATCH 5.10 119/120] net: dsa: mv88e6xxx: override existent unicast portvec in port_fdb_add Greg Kroah-Hartman
@ 2021-02-08 15:01 ` Greg Kroah-Hartman
2021-02-08 18:33 ` [PATCH 5.10 000/120] 5.10.15-rc1 review Pavel Machek
` (6 subsequent siblings)
126 siblings, 0 replies; 140+ messages in thread
From: Greg Kroah-Hartman @ 2021-02-08 15:01 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Alexander Ovechkin,
Alexander Kuznetsov, Dmitry Monakhov, Dmitry Yakunin, Cong Wang,
Jakub Kicinski
From: Alexander Ovechkin <ovov@yandex-team.ru>
commit 938e0fcd3253efdef8924714158911286d08cfe1 upstream.
Commit e5f0e8f8e456 ("net: sched: introduce and use qdisc tree flush/purge helpers")
introduced qdisc tree flush/purge helpers, but erroneously used flush helper
instead of purge helper in qdisc_replace function.
This issue was found in our CI, that tests various qdisc setups by configuring
qdisc and sending data through it. Call of invalid helper sporadically leads
to corruption of vt_tree/cf_tree of hfsc_class that causes kernel oops:
Oops: 0000 [#1] SMP PTI
CPU: 1 PID: 0 Comm: swapper/1 Not tainted 5.11.0-8f6859df #1
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.10.2-0-g5f4c7b1-prebuilt.qemu-project.org 04/01/2014
RIP: 0010:rb_insert_color+0x18/0x190
Code: c3 31 c0 c3 0f 1f 40 00 66 2e 0f 1f 84 00 00 00 00 00 48 8b 07 48 85 c0 0f 84 05 01 00 00 48 8b 10 f6 c2 01 0f 85 34 01 00 00 <48> 8b 4a 08 49 89 d0 48 39 c1 74 7d 48 85 c9 74 32 f6 01 01 75 2d
RSP: 0018:ffffc900000b8bb0 EFLAGS: 00010246
RAX: ffff8881ef4c38b0 RBX: ffff8881d956e400 RCX: ffff8881ef4c38b0
RDX: 0000000000000000 RSI: ffff8881d956f0a8 RDI: ffff8881d956e4b0
RBP: 0000000000000000 R08: 000000d5c4e249da R09: 1600000000000000
R10: ffffc900000b8be0 R11: ffffc900000b8b28 R12: 0000000000000001
R13: 000000000000005a R14: ffff8881f0905000 R15: ffff8881f0387d00
FS: 0000000000000000(0000) GS:ffff8881f8b00000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000000000000008 CR3: 00000001f4796004 CR4: 0000000000060ee0
Call Trace:
<IRQ>
init_vf.isra.19+0xec/0x250 [sch_hfsc]
hfsc_enqueue+0x245/0x300 [sch_hfsc]
? fib_rules_lookup+0x12a/0x1d0
? __dev_queue_xmit+0x4b6/0x930
? hfsc_delete_class+0x250/0x250 [sch_hfsc]
__dev_queue_xmit+0x4b6/0x930
? ip6_finish_output2+0x24d/0x590
ip6_finish_output2+0x24d/0x590
? ip6_output+0x6c/0x130
ip6_output+0x6c/0x130
? __ip6_finish_output+0x110/0x110
mld_sendpack+0x224/0x230
mld_ifc_timer_expire+0x186/0x2c0
? igmp6_group_dropped+0x200/0x200
call_timer_fn+0x2d/0x150
run_timer_softirq+0x20c/0x480
? tick_sched_do_timer+0x60/0x60
? tick_sched_timer+0x37/0x70
__do_softirq+0xf7/0x2cb
irq_exit+0xa0/0xb0
smp_apic_timer_interrupt+0x74/0x150
apic_timer_interrupt+0xf/0x20
</IRQ>
Fixes: e5f0e8f8e456 ("net: sched: introduce and use qdisc tree flush/purge helpers")
Signed-off-by: Alexander Ovechkin <ovov@yandex-team.ru>
Reported-by: Alexander Kuznetsov <wwfq@yandex-team.ru>
Acked-by: Dmitry Monakhov <dmtrmonakhov@yandex-team.ru>
Acked-by: Dmitry Yakunin <zeil@yandex-team.ru>
Acked-by: Cong Wang <xiyou.wangcong@gmail.com>
Link: https://lore.kernel.org/r/20210201200049.299153-1-ovov@yandex-team.ru
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
include/net/sch_generic.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/include/net/sch_generic.h
+++ b/include/net/sch_generic.h
@@ -1155,7 +1155,7 @@ static inline struct Qdisc *qdisc_replac
old = *pold;
*pold = new;
if (old != NULL)
- qdisc_tree_flush_backlog(old);
+ qdisc_purge_queue(old);
sch_tree_unlock(sch);
return old;
^ permalink raw reply [flat|nested] 140+ messages in thread* Re: [PATCH 5.10 000/120] 5.10.15-rc1 review
2021-02-08 14:59 [PATCH 5.10 000/120] 5.10.15-rc1 review Greg Kroah-Hartman
` (119 preceding siblings ...)
2021-02-08 15:01 ` [PATCH 5.10 120/120] net: sched: replaced invalid qdisc tree flush helper in qdisc_replace Greg Kroah-Hartman
@ 2021-02-08 18:33 ` Pavel Machek
2021-02-10 8:31 ` Greg Kroah-Hartman
2021-02-08 20:01 ` Shuah Khan
` (5 subsequent siblings)
126 siblings, 1 reply; 140+ messages in thread
From: Pavel Machek @ 2021-02-08 18:33 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: linux-kernel, torvalds, akpm, linux, shuah, patches, lkft-triage,
pavel, jonathanh, stable
[-- Attachment #1: Type: text/plain, Size: 835 bytes --]
On Mon 2021-02-08 15:59:47, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 5.10.15 release.
> There are 120 patches in this series, all will be posted as a response
> to this one. If anyone has any issues with these being applied, please
> let me know.
>
> Responses should be made by Wed, 10 Feb 2021 14:57:55 +0000.
> Anything received after that time might be too late.
CIP testing did not find any problems here:
https://gitlab.com/cip-project/cip-testing/linux-stable-rc-ci/-/tree/linux-5.10.y
Tested-by: Pavel Machek (CIP) <pavel@denx.de>
Best regards,
Pavel
--
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 bytes --]
^ permalink raw reply [flat|nested] 140+ messages in thread* Re: [PATCH 5.10 000/120] 5.10.15-rc1 review
2021-02-08 18:33 ` [PATCH 5.10 000/120] 5.10.15-rc1 review Pavel Machek
@ 2021-02-10 8:31 ` Greg Kroah-Hartman
0 siblings, 0 replies; 140+ messages in thread
From: Greg Kroah-Hartman @ 2021-02-10 8:31 UTC (permalink / raw)
To: Pavel Machek
Cc: linux-kernel, torvalds, akpm, linux, shuah, patches, lkft-triage,
jonathanh, stable
On Mon, Feb 08, 2021 at 07:33:53PM +0100, Pavel Machek wrote:
> On Mon 2021-02-08 15:59:47, Greg Kroah-Hartman wrote:
> > This is the start of the stable review cycle for the 5.10.15 release.
> > There are 120 patches in this series, all will be posted as a response
> > to this one. If anyone has any issues with these being applied, please
> > let me know.
> >
> > Responses should be made by Wed, 10 Feb 2021 14:57:55 +0000.
> > Anything received after that time might be too late.
>
> CIP testing did not find any problems here:
>
> https://gitlab.com/cip-project/cip-testing/linux-stable-rc-ci/-/tree/linux-5.10.y
>
> Tested-by: Pavel Machek (CIP) <pavel@denx.de>
Thanks for testing some of them and letting me know.
greg k-h
^ permalink raw reply [flat|nested] 140+ messages in thread
* Re: [PATCH 5.10 000/120] 5.10.15-rc1 review
2021-02-08 14:59 [PATCH 5.10 000/120] 5.10.15-rc1 review Greg Kroah-Hartman
` (120 preceding siblings ...)
2021-02-08 18:33 ` [PATCH 5.10 000/120] 5.10.15-rc1 review Pavel Machek
@ 2021-02-08 20:01 ` Shuah Khan
2021-02-10 8:30 ` Greg Kroah-Hartman
2021-02-08 20:22 ` Davidson Francis
` (4 subsequent siblings)
126 siblings, 1 reply; 140+ messages in thread
From: Shuah Khan @ 2021-02-08 20:01 UTC (permalink / raw)
To: Greg Kroah-Hartman, linux-kernel
Cc: torvalds, akpm, linux, shuah, patches, lkft-triage, pavel,
jonathanh, stable, Shuah Khan
On 2/8/21 7:59 AM, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 5.10.15 release.
> There are 120 patches in this series, all will be posted as a response
> to this one. If anyone has any issues with these being applied, please
> let me know.
>
> Responses should be made by Wed, 10 Feb 2021 14:57:55 +0000.
> Anything received after that time might be too late.
>
> The whole patch series can be found in one patch at:
> https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.10.15-rc1.gz
> or in the git tree and branch at:
> git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-5.10.y
> and the diffstat can be found below.
>
> thanks,
>
> greg k-h
>
Compiled and booted on my test system. No dmesg regressions.
Tested-by: Shuah Khan <skhan@linuxfoundation.org>
thanks,
-- Shuah
^ permalink raw reply [flat|nested] 140+ messages in thread* Re: [PATCH 5.10 000/120] 5.10.15-rc1 review
2021-02-08 20:01 ` Shuah Khan
@ 2021-02-10 8:30 ` Greg Kroah-Hartman
0 siblings, 0 replies; 140+ messages in thread
From: Greg Kroah-Hartman @ 2021-02-10 8:30 UTC (permalink / raw)
To: Shuah Khan
Cc: linux-kernel, torvalds, akpm, linux, shuah, patches, lkft-triage,
pavel, jonathanh, stable
On Mon, Feb 08, 2021 at 01:01:09PM -0700, Shuah Khan wrote:
> On 2/8/21 7:59 AM, Greg Kroah-Hartman wrote:
> > This is the start of the stable review cycle for the 5.10.15 release.
> > There are 120 patches in this series, all will be posted as a response
> > to this one. If anyone has any issues with these being applied, please
> > let me know.
> >
> > Responses should be made by Wed, 10 Feb 2021 14:57:55 +0000.
> > Anything received after that time might be too late.
> >
> > The whole patch series can be found in one patch at:
> > https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.10.15-rc1.gz
> > or in the git tree and branch at:
> > git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-5.10.y
> > and the diffstat can be found below.
> >
> > thanks,
> >
> > greg k-h
> >
>
> Compiled and booted on my test system. No dmesg regressions.
>
> Tested-by: Shuah Khan <skhan@linuxfoundation.org>
Thanks for testing them all and letting me know.
greg k-h
^ permalink raw reply [flat|nested] 140+ messages in thread
* Re: [PATCH 5.10 000/120] 5.10.15-rc1 review
2021-02-08 14:59 [PATCH 5.10 000/120] 5.10.15-rc1 review Greg Kroah-Hartman
` (121 preceding siblings ...)
2021-02-08 20:01 ` Shuah Khan
@ 2021-02-08 20:22 ` Davidson Francis
2021-02-10 8:30 ` Greg Kroah-Hartman
2021-02-09 2:31 ` Naresh Kamboju
` (3 subsequent siblings)
126 siblings, 1 reply; 140+ messages in thread
From: Davidson Francis @ 2021-02-08 20:22 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: linux-kernel, torvalds, akpm, linux, shuah, patches, lkft-triage,
pavel, jonathanh, stable
On Mon, Feb 08, 2021 at 03:59:47PM +0100, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 5.10.15 release.
> There are 120 patches in this series, all will be posted as a response
> to this one. If anyone has any issues with these being applied, please
> let me know.
Compiled and boot tested for x86_64, no dmesg regressions found.
Tested-by: Davidson Francis <davidsondfgl@gmail.com>
Regards,
Davidson Francis
^ permalink raw reply [flat|nested] 140+ messages in thread* Re: [PATCH 5.10 000/120] 5.10.15-rc1 review
2021-02-08 20:22 ` Davidson Francis
@ 2021-02-10 8:30 ` Greg Kroah-Hartman
0 siblings, 0 replies; 140+ messages in thread
From: Greg Kroah-Hartman @ 2021-02-10 8:30 UTC (permalink / raw)
To: Davidson Francis
Cc: linux-kernel, torvalds, akpm, linux, shuah, patches, lkft-triage,
pavel, jonathanh, stable
On Mon, Feb 08, 2021 at 05:22:07PM -0300, Davidson Francis wrote:
> On Mon, Feb 08, 2021 at 03:59:47PM +0100, Greg Kroah-Hartman wrote:
> > This is the start of the stable review cycle for the 5.10.15 release.
> > There are 120 patches in this series, all will be posted as a response
> > to this one. If anyone has any issues with these being applied, please
> > let me know.
>
> Compiled and boot tested for x86_64, no dmesg regressions found.
>
> Tested-by: Davidson Francis <davidsondfgl@gmail.com>
Thanks for testing!
greg k-h
^ permalink raw reply [flat|nested] 140+ messages in thread
* Re: [PATCH 5.10 000/120] 5.10.15-rc1 review
2021-02-08 14:59 [PATCH 5.10 000/120] 5.10.15-rc1 review Greg Kroah-Hartman
` (122 preceding siblings ...)
2021-02-08 20:22 ` Davidson Francis
@ 2021-02-09 2:31 ` Naresh Kamboju
2021-02-09 6:52 ` Rolf Eike Beer
2021-02-09 14:12 ` Naresh Kamboju
` (2 subsequent siblings)
126 siblings, 1 reply; 140+ messages in thread
From: Naresh Kamboju @ 2021-02-09 2:31 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: open list, Shuah Khan, patches, lkft-triage, Jon Hunter,
linux-stable, pavel, Andrew Morton, Linus Torvalds,
Guenter Roeck, Rolf Eike Beer, Masahiro Yamada, Arnd Bergmann,
Daniel Díaz
On Mon, 8 Feb 2021 at 20:44, Greg Kroah-Hartman
<gregkh@linuxfoundation.org> wrote:
>
> This is the start of the stable review cycle for the 5.10.15 release.
> There are 120 patches in this series, all will be posted as a response
> to this one. If anyone has any issues with these being applied, please
> let me know.
>
> Responses should be made by Wed, 10 Feb 2021 14:57:55 +0000.
> Anything received after that time might be too late.
>
> The whole patch series can be found in one patch at:
> https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.10.15-rc1.gz
> or in the git tree and branch at:
> git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-5.10.y
> and the diffstat can be found below.
>
> thanks,
>
> greg k-h
Due to the patch below, the x86_64 build breaks with gcc 7.3.x
This issue is specific to openembedded kernel builder.
We have also noticed on mainline, Linux next and now on stable-rc 5.10.
collect2: error: ld returned 1 exit status
make[2]: *** [scripts/Makefile.host:95: scripts/extract-cert] Error 1
ref:
Build failure link,
https://ci.linaro.org/view/lkft/job/openembedded-lkft-linux-stable-rc-5.10/DISTRO=lkft,MACHINE=intel-corei7-64,label=docker-buster-lkft/64/consoleText
> Rolf Eike Beer <eb@emlix.com>
> scripts: use pkg-config to locate libcrypto
From 7658769759718950f5eda0079e84837738d8fda8 Mon Sep 17 00:00:00 2001
From: Rolf Eike Beer <eb@emlix.com>
Date: Thu, 22 Nov 2018 16:40:49 +0100
Subject: scripts: use pkg-config to locate libcrypto
commit 2cea4a7a1885bd0c765089afc14f7ff0eb77864e upstream.
Otherwise build fails if the headers are not in the default location. While at
it also ask pkg-config for the libs, with fallback to the existing value.
Signed-off-by: Rolf Eike Beer <eb@emlix.com>
Cc: stable@vger.kernel.org # 5.6.x
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
^ permalink raw reply [flat|nested] 140+ messages in thread* Re: [PATCH 5.10 000/120] 5.10.15-rc1 review
2021-02-09 2:31 ` Naresh Kamboju
@ 2021-02-09 6:52 ` Rolf Eike Beer
2021-02-09 7:11 ` Naresh Kamboju
0 siblings, 1 reply; 140+ messages in thread
From: Rolf Eike Beer @ 2021-02-09 6:52 UTC (permalink / raw)
To: Greg Kroah-Hartman, Naresh Kamboju
Cc: open list, Shuah Khan, patches, lkft-triage, Jon Hunter,
linux-stable, pavel, Andrew Morton, Linus Torvalds,
Guenter Roeck, Masahiro Yamada, Arnd Bergmann, Daniel Díaz
[-- Attachment #1: Type: text/plain, Size: 2229 bytes --]
Am Dienstag, 9. Februar 2021, 03:31:44 CET schrieb Naresh Kamboju:
> On Mon, 8 Feb 2021 at 20:44, Greg Kroah-Hartman
>
> <gregkh@linuxfoundation.org> wrote:
> > This is the start of the stable review cycle for the 5.10.15 release.
> > There are 120 patches in this series, all will be posted as a response
> > to this one. If anyone has any issues with these being applied, please
> > let me know.
> >
> > Responses should be made by Wed, 10 Feb 2021 14:57:55 +0000.
> > Anything received after that time might be too late.
> >
> > The whole patch series can be found in one patch at:
> > https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5
> > .10.15-rc1.gz>
> > or in the git tree and branch at:
> > git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-
> > rc.git linux-5.10.y>
> > and the diffstat can be found below.
> >
> > thanks,
> >
> > greg k-h
>
> Due to the patch below, the x86_64 build breaks with gcc 7.3.x
> This issue is specific to openembedded kernel builder.
>
> We have also noticed on mainline, Linux next and now on stable-rc 5.10.
>
> collect2: error: ld returned 1 exit status
> make[2]: *** [scripts/Makefile.host:95: scripts/extract-cert] Error 1
>
> ref:
> Build failure link,
> https://ci.linaro.org/view/lkft/job/openembedded-lkft-linux-stable-rc-5.10/D
> ISTRO=lkft,MACHINE=intel-corei7-64,label=docker-buster-lkft/64/consoleText
Is this part relevant or does that always happen with your builder.
| /srv/oe/build/tmp-lkft-glibc/hosttools/ld: cannot find /lib/libc.so.6 inside
/
| /srv/oe/build/tmp-lkft-glibc/hosttools/ld: cannot find /usr/lib/
libc_nonshared.a inside /
| /srv/oe/build/tmp-lkft-glibc/hosttools/ld: cannot find /lib/ld-linux-
x86-64.so.2 inside /
Can you provide a log with V=1 where we can see what actually is going on?
Eike
--
Rolf Eike Beer, emlix GmbH, http://www.emlix.com
Fon +49 551 30664-0, Fax +49 551 30664-11
Gothaer Platz 3, 37083 Göttingen, Germany
Sitz der Gesellschaft: Göttingen, Amtsgericht Göttingen HR B 3160
Geschäftsführung: Heike Jordan, Dr. Uwe Kracke – Ust-IdNr.: DE 205 198 055
emlix - smart embedded open source
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 313 bytes --]
^ permalink raw reply [flat|nested] 140+ messages in thread
* Re: [PATCH 5.10 000/120] 5.10.15-rc1 review
2021-02-09 6:52 ` Rolf Eike Beer
@ 2021-02-09 7:11 ` Naresh Kamboju
0 siblings, 0 replies; 140+ messages in thread
From: Naresh Kamboju @ 2021-02-09 7:11 UTC (permalink / raw)
To: Rolf Eike Beer, Greg Kroah-Hartman
Cc: open list, Shuah Khan, patches, lkft-triage, Jon Hunter,
linux-stable, pavel, Andrew Morton, Linus Torvalds,
Guenter Roeck, Masahiro Yamada, Arnd Bergmann, Daniel Díaz
On Tue, 9 Feb 2021 at 12:22, Rolf Eike Beer <eb@emlix.com> wrote:
>
> Am Dienstag, 9. Februar 2021, 03:31:44 CET schrieb Naresh Kamboju:
> > On Mon, 8 Feb 2021 at 20:44, Greg Kroah-Hartman
> >
> > <gregkh@linuxfoundation.org> wrote:
> > > This is the start of the stable review cycle for the 5.10.15 release.
> > > There are 120 patches in this series, all will be posted as a response
> > > to this one. If anyone has any issues with these being applied, please
> > > let me know.
> > >
> > > Responses should be made by Wed, 10 Feb 2021 14:57:55 +0000.
> > > Anything received after that time might be too late.
> > >
> > > The whole patch series can be found in one patch at:
> > > https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5
> > > .10.15-rc1.gz>
> > > or in the git tree and branch at:
> > > git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-
> > > rc.git linux-5.10.y>
> > > and the diffstat can be found below.
> > >
> > > thanks,
> > >
> > > greg k-h
> >
> > Due to the patch below, the x86_64 build breaks with gcc 7.3.x
> > This issue is specific to openembedded kernel builder.
> >
> > We have also noticed on mainline, Linux next and now on stable-rc 5.10.
> >
> > collect2: error: ld returned 1 exit status
> > make[2]: *** [scripts/Makefile.host:95: scripts/extract-cert] Error 1
> >
> > ref:
> > Build failure link,
> > https://ci.linaro.org/view/lkft/job/openembedded-lkft-linux-stable-rc-5.10/D
> > ISTRO=lkft,MACHINE=intel-corei7-64,label=docker-buster-lkft/64/consoleText
>
> Is this part relevant or does that always happen with your builder.
>
> | /srv/oe/build/tmp-lkft-glibc/hosttools/ld: cannot find /lib/libc.so.6 inside
> /
> | /srv/oe/build/tmp-lkft-glibc/hosttools/ld: cannot find /usr/lib/
> libc_nonshared.a inside /
> | /srv/oe/build/tmp-lkft-glibc/hosttools/ld: cannot find /lib/ld-linux-
> x86-64.so.2 inside /
>
> Can you provide a log with V=1 where we can see what actually is going on?
Daniel Díaz sent a fix patch on the stable mailing list.
[PATCH] scripts: Fix linking extract-cert against libcrypto
https://lore.kernel.org/stable/20210209050047.1958473-1-daniel.diaz@linaro.org/T/#u
- Naresh
^ permalink raw reply [flat|nested] 140+ messages in thread
* Re: [PATCH 5.10 000/120] 5.10.15-rc1 review
2021-02-08 14:59 [PATCH 5.10 000/120] 5.10.15-rc1 review Greg Kroah-Hartman
` (123 preceding siblings ...)
2021-02-09 2:31 ` Naresh Kamboju
@ 2021-02-09 14:12 ` Naresh Kamboju
2021-02-10 8:30 ` Greg Kroah-Hartman
2021-02-09 18:14 ` Guenter Roeck
2021-02-10 1:28 ` Ross Schmidt
126 siblings, 1 reply; 140+ messages in thread
From: Naresh Kamboju @ 2021-02-09 14:12 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: open list, Shuah Khan, patches, lkft-triage, Jon Hunter,
linux-stable, pavel, Andrew Morton, Linus Torvalds,
Guenter Roeck
On Mon, 8 Feb 2021 at 20:44, Greg Kroah-Hartman
<gregkh@linuxfoundation.org> wrote:
>
> This is the start of the stable review cycle for the 5.10.15 release.
> There are 120 patches in this series, all will be posted as a response
> to this one. If anyone has any issues with these being applied, please
> let me know.
>
> Responses should be made by Wed, 10 Feb 2021 14:57:55 +0000.
> Anything received after that time might be too late.
>
> The whole patch series can be found in one patch at:
> https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.10.15-rc1.gz
> or in the git tree and branch at:
> git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-5.10.y
> and the diffstat can be found below.
>
> thanks,
>
> greg k-h
Results from Linaro’s test farm.
No regressions on arm64, arm and i386.
Tested-by: Linux Kernel Functional Testing <lkft@linaro.org>
NOTE:
When compiling under OpenEmbedded, the following error is seen
as of recently:
/srv/oe/build/tmp/hosttools/ld: cannot find /lib/libc.so.6 inside /
/srv/oe/build/tmp/hosttools/ld: cannot find /usr/lib/libc_nonshared.a inside /
/srv/oe/build/tmp/hosttools/ld: cannot find /lib/ld-linux-x86-64.so.2 inside /
collect2: error: ld returned 1 exit status
make[2]: *** [scripts/Makefile.host:95: scripts/extract-cert] Error 1
This is because
2cea4a7a1885 ("scripts: use pkg-config to locate libcrypto"
This patch will fix the reported problem.
scripts: Fix linking extract-cert against libcrypto
https://lore.kernel.org/stable/20210209050047.1958473-1-daniel.diaz@linaro.org/T/#u
Summary
------------------------------------------------------------------------
kernel: 5.10.15-rc1
git repo: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git
git branch: linux-5.10.y
git commit: 21cc9754fccca82f1b3aae7baa6cddfdf4384802
git describe: v5.10.14-121-g21cc9754fccc
Test details: https://qa-reports.linaro.org/lkft/linux-stable-rc-linux-5.10.y/build/v5.10.14-121-g21cc9754fccc
No regressions (compared to build v5.10.14)
No fixes (compared to build v5.10.14)
Ran 55235 total tests in the following environments and test suites.
Environments
--------------
- arc
- arm
- arm64
- dragonboard-410c
- hi6220-hikey
- i386
- juno-r2
- juno-r2-compat
- juno-r2-kasan
- mips
- nxp-ls2088
- nxp-ls2088-64k_page_size
- parisc
- powerpc
- qemu-arm-clang
- qemu-arm64-clang
- qemu-arm64-kasan
- qemu-i386-clang
- qemu-x86_64-clang
- qemu-x86_64-kasan
- qemu-x86_64-kcsan
- qemu_arm
- qemu_arm64
- qemu_arm64-compat
- qemu_i386
- qemu_x86_64
- qemu_x86_64-compat
- riscv
- s390
- sh
- sparc
- x15
- x86
- x86-kasan
- x86_64
Test Suites
-----------
* build
* linux-log-parser
* install-android-platform-tools-r2600
* kvm-unit-tests
* libhugetlbfs
* ltp-commands-tests
* ltp-containers-tests
* ltp-fcntl-locktests-tests
* ltp-filecaps-tests
* ltp-fs_bind-tests
* ltp-fs_perms_simple-tests
* ltp-fsx-tests
* ltp-ipc-tests
* ltp-math-tests
* ltp-nptl-tests
* ltp-pty-tests
* ltp-sched-tests
* ltp-securebits-tests
* ltp-syscalls-tests
* ltp-tracing-tests
* fwts
* ltp-cap_bounds-tests
* ltp-cpuhotplug-tests
* ltp-crypto-tests
* ltp-cve-tests
* ltp-dio-tests
* ltp-fs-tests
* ltp-hugetlb-tests
* ltp-io-tests
* ltp-mm-tests
* ltp-controllers-tests
* ltp-open-posix-tests
* network-basic-tests
* perf
* v4l2-compliance
* kunit
* rcutorture
* kselftest-android
* kselftest-bpf
* kselftest-capabilities
* kselftest-cgroup
* kselftest-clone3
* kselftest-core
* kselftest-cpu-hotplug
* kselftest-cpufreq
* kselftest-efivarfs
* kselftest-filesystems
* kselftest-firmware
* kselftest-fpu
* kselftest-futex
* kselftest-gpio
* kselftest-ipc
* kselftest-ir
* kselftest-kcmp
* kselftest-lib
* kselftest-lkdtm
* kselftest-membarrier
* kselftest-memfd
* kselftest-memory-hotplug
* kselftest-mincore
* kselftest-mount
* kselftest-mqueue
* kselftest-net
* kselftest-netfilter
* kselftest-nsfs
* kselftest-openat2
* kselftest-pid_namespace
* kselftest-pidfd
* kselftest-proc
* kselftest-pstore
* kselftest-tc-testing
* kselftest-timens
* kselftest-timers
* kselftest-tmpfs
* kselftest-tpm2
* kselftest-user
* kselftest-zram
* kselftest-
* kselftest-intel_pstate
* kselftest-kexec
* kselftest-kvm
* kselftest-livepatch
* kselftest-ptrace
* kselftest-rseq
* kselftest-rtc
* kselftest-seccomp
* kselftest-sigaltstack
* kselftest-size
* kselftest-splice
* kselftest-static_keys
* kselftest-sync
* kselftest-sysctl
* kselftest-vm
* kselftest-x86
--
Linaro LKFT
https://lkft.linaro.org
^ permalink raw reply [flat|nested] 140+ messages in thread* Re: [PATCH 5.10 000/120] 5.10.15-rc1 review
2021-02-09 14:12 ` Naresh Kamboju
@ 2021-02-10 8:30 ` Greg Kroah-Hartman
0 siblings, 0 replies; 140+ messages in thread
From: Greg Kroah-Hartman @ 2021-02-10 8:30 UTC (permalink / raw)
To: Naresh Kamboju
Cc: open list, Shuah Khan, patches, lkft-triage, Jon Hunter,
linux-stable, pavel, Andrew Morton, Linus Torvalds,
Guenter Roeck
On Tue, Feb 09, 2021 at 07:42:34PM +0530, Naresh Kamboju wrote:
> On Mon, 8 Feb 2021 at 20:44, Greg Kroah-Hartman
> <gregkh@linuxfoundation.org> wrote:
> >
> > This is the start of the stable review cycle for the 5.10.15 release.
> > There are 120 patches in this series, all will be posted as a response
> > to this one. If anyone has any issues with these being applied, please
> > let me know.
> >
> > Responses should be made by Wed, 10 Feb 2021 14:57:55 +0000.
> > Anything received after that time might be too late.
> >
> > The whole patch series can be found in one patch at:
> > https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.10.15-rc1.gz
> > or in the git tree and branch at:
> > git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-5.10.y
> > and the diffstat can be found below.
> >
> > thanks,
> >
> > greg k-h
>
> Results from Linaro’s test farm.
> No regressions on arm64, arm and i386.
>
> Tested-by: Linux Kernel Functional Testing <lkft@linaro.org>
>
Thanks for testing them all and letting me know.
greg k-h
^ permalink raw reply [flat|nested] 140+ messages in thread
* Re: [PATCH 5.10 000/120] 5.10.15-rc1 review
2021-02-08 14:59 [PATCH 5.10 000/120] 5.10.15-rc1 review Greg Kroah-Hartman
` (124 preceding siblings ...)
2021-02-09 14:12 ` Naresh Kamboju
@ 2021-02-09 18:14 ` Guenter Roeck
2021-02-10 8:30 ` Greg Kroah-Hartman
2021-02-10 1:28 ` Ross Schmidt
126 siblings, 1 reply; 140+ messages in thread
From: Guenter Roeck @ 2021-02-09 18:14 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: linux-kernel, torvalds, akpm, shuah, patches, lkft-triage, pavel,
jonathanh, stable
On Mon, Feb 08, 2021 at 03:59:47PM +0100, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 5.10.15 release.
> There are 120 patches in this series, all will be posted as a response
> to this one. If anyone has any issues with these being applied, please
> let me know.
>
> Responses should be made by Wed, 10 Feb 2021 14:57:55 +0000.
> Anything received after that time might be too late.
>
Build results:
total: 154 pass: 154 fail: 0
Qemu test results:
total: 427 pass: 427 fail: 0
Tested-by: Guenter Roeck <linux@roeck-us.net>
Guenter
^ permalink raw reply [flat|nested] 140+ messages in thread* Re: [PATCH 5.10 000/120] 5.10.15-rc1 review
2021-02-09 18:14 ` Guenter Roeck
@ 2021-02-10 8:30 ` Greg Kroah-Hartman
0 siblings, 0 replies; 140+ messages in thread
From: Greg Kroah-Hartman @ 2021-02-10 8:30 UTC (permalink / raw)
To: Guenter Roeck
Cc: linux-kernel, torvalds, akpm, shuah, patches, lkft-triage, pavel,
jonathanh, stable
On Tue, Feb 09, 2021 at 10:14:44AM -0800, Guenter Roeck wrote:
> On Mon, Feb 08, 2021 at 03:59:47PM +0100, Greg Kroah-Hartman wrote:
> > This is the start of the stable review cycle for the 5.10.15 release.
> > There are 120 patches in this series, all will be posted as a response
> > to this one. If anyone has any issues with these being applied, please
> > let me know.
> >
> > Responses should be made by Wed, 10 Feb 2021 14:57:55 +0000.
> > Anything received after that time might be too late.
> >
>
> Build results:
> total: 154 pass: 154 fail: 0
> Qemu test results:
> total: 427 pass: 427 fail: 0
>
> Tested-by: Guenter Roeck <linux@roeck-us.net>
Great, thanks for testing.
greg k-h
^ permalink raw reply [flat|nested] 140+ messages in thread
* Re: [PATCH 5.10 000/120] 5.10.15-rc1 review
2021-02-08 14:59 [PATCH 5.10 000/120] 5.10.15-rc1 review Greg Kroah-Hartman
` (125 preceding siblings ...)
2021-02-09 18:14 ` Guenter Roeck
@ 2021-02-10 1:28 ` Ross Schmidt
2021-02-10 8:30 ` Greg Kroah-Hartman
126 siblings, 1 reply; 140+ messages in thread
From: Ross Schmidt @ 2021-02-10 1:28 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: linux-kernel, torvalds, akpm, linux, shuah, patches, lkft-triage,
pavel, jonathanh, stable
On Mon, Feb 08, 2021 at 03:59:47PM +0100, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 5.10.15 release.
> There are 120 patches in this series, all will be posted as a response
> to this one. If anyone has any issues with these being applied, please
> let me know.
>
Compiled and booted with no regressions on x86_64.
Tested-by: Ross Schmidt <ross.schm.dev@gmail.com>
thanks,
Ross
^ permalink raw reply [flat|nested] 140+ messages in thread* Re: [PATCH 5.10 000/120] 5.10.15-rc1 review
2021-02-10 1:28 ` Ross Schmidt
@ 2021-02-10 8:30 ` Greg Kroah-Hartman
0 siblings, 0 replies; 140+ messages in thread
From: Greg Kroah-Hartman @ 2021-02-10 8:30 UTC (permalink / raw)
To: Ross Schmidt
Cc: linux-kernel, torvalds, akpm, linux, shuah, patches, lkft-triage,
pavel, jonathanh, stable
On Tue, Feb 09, 2021 at 07:28:16PM -0600, Ross Schmidt wrote:
> On Mon, Feb 08, 2021 at 03:59:47PM +0100, Greg Kroah-Hartman wrote:
> > This is the start of the stable review cycle for the 5.10.15 release.
> > There are 120 patches in this series, all will be posted as a response
> > to this one. If anyone has any issues with these being applied, please
> > let me know.
> >
>
> Compiled and booted with no regressions on x86_64.
>
> Tested-by: Ross Schmidt <ross.schm.dev@gmail.com>
Thanks for testing and letting me know.
greg k-h
^ permalink raw reply [flat|nested] 140+ messages in thread