--- /dev/null
+From 9231e98a50bf4633b8b4e1474735a9bd5acb753d Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Wed, 20 Jan 2021 20:41:35 +0900
+Subject: can: dev: can_restart: fix use after free bug
+
+From: Vincent Mailhol <mailhol.vincent@wanadoo.fr>
+
+[ Upstream commit 03f16c5075b22c8902d2af739969e878b0879c94 ]
+
+After calling netif_rx_ni(skb), dereferencing skb is unsafe.
+Especially, the can_frame cf which aliases skb memory is accessed
+after the netif_rx_ni() in:
+ stats->rx_bytes += cf->len;
+
+Reordering the lines solves the issue.
+
+Fixes: 39549eef3587 ("can: CAN Network device driver and Netlink interface")
+Link: https://lore.kernel.org/r/20210120114137.200019-2-mailhol.vincent@wanadoo.fr
+Signed-off-by: Vincent Mailhol <mailhol.vincent@wanadoo.fr>
+Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/net/can/dev.c | 4 ++--
+ 1 file changed, 2 insertions(+), 2 deletions(-)
+
+diff --git a/drivers/net/can/dev.c b/drivers/net/can/dev.c
+index 5b8791135de13..247aeacb3a440 100644
+--- a/drivers/net/can/dev.c
++++ b/drivers/net/can/dev.c
+@@ -567,11 +567,11 @@ static void can_restart(struct net_device *dev)
+ }
+ cf->can_id |= CAN_ERR_RESTARTED;
+
+- netif_rx_ni(skb);
+-
+ stats->rx_packets++;
+ stats->rx_bytes += cf->can_dlc;
+
++ netif_rx_ni(skb);
++
+ restart:
+ netdev_dbg(dev, "restarted\n");
+ priv->can_stats.restarts++;
+--
+2.27.0
+
--- /dev/null
+From 5477f142d72ae57f140f5b5d61a8d25dcf11ade9 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Wed, 20 Jan 2021 20:41:37 +0900
+Subject: can: peak_usb: fix use after free bugs
+
+From: Vincent Mailhol <mailhol.vincent@wanadoo.fr>
+
+[ Upstream commit 50aca891d7a554db0901b245167cd653d73aaa71 ]
+
+After calling peak_usb_netif_rx_ni(skb), dereferencing skb is unsafe.
+Especially, the can_frame cf which aliases skb memory is accessed
+after the peak_usb_netif_rx_ni().
+
+Reordering the lines solves the issue.
+
+Fixes: 0a25e1f4f185 ("can: peak_usb: add support for PEAK new CANFD USB adapters")
+Link: https://lore.kernel.org/r/20210120114137.200019-4-mailhol.vincent@wanadoo.fr
+Signed-off-by: Vincent Mailhol <mailhol.vincent@wanadoo.fr>
+Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/net/can/usb/peak_usb/pcan_usb_fd.c | 8 ++++----
+ 1 file changed, 4 insertions(+), 4 deletions(-)
+
+diff --git a/drivers/net/can/usb/peak_usb/pcan_usb_fd.c b/drivers/net/can/usb/peak_usb/pcan_usb_fd.c
+index dee3e689b54da..96bbdef672bc9 100644
+--- a/drivers/net/can/usb/peak_usb/pcan_usb_fd.c
++++ b/drivers/net/can/usb/peak_usb/pcan_usb_fd.c
+@@ -512,11 +512,11 @@ static int pcan_usb_fd_decode_canmsg(struct pcan_usb_fd_if *usb_if,
+ else
+ memcpy(cfd->data, rm->d, cfd->len);
+
+- peak_usb_netif_rx(skb, &usb_if->time_ref, le32_to_cpu(rm->ts_low));
+-
+ netdev->stats.rx_packets++;
+ netdev->stats.rx_bytes += cfd->len;
+
++ peak_usb_netif_rx(skb, &usb_if->time_ref, le32_to_cpu(rm->ts_low));
++
+ return 0;
+ }
+
+@@ -578,11 +578,11 @@ static int pcan_usb_fd_decode_status(struct pcan_usb_fd_if *usb_if,
+ if (!skb)
+ return -ENOMEM;
+
+- peak_usb_netif_rx(skb, &usb_if->time_ref, le32_to_cpu(sm->ts_low));
+-
+ netdev->stats.rx_packets++;
+ netdev->stats.rx_bytes += cf->can_dlc;
+
++ peak_usb_netif_rx(skb, &usb_if->time_ref, le32_to_cpu(sm->ts_low));
++
+ return 0;
+ }
+
+--
+2.27.0
+
--- /dev/null
+From a97ccb2c21fc8d759a2878f965a24558c05c85a4 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Wed, 20 Jan 2021 20:41:36 +0900
+Subject: can: vxcan: vxcan_xmit: fix use after free bug
+
+From: Vincent Mailhol <mailhol.vincent@wanadoo.fr>
+
+[ Upstream commit 75854cad5d80976f6ea0f0431f8cedd3bcc475cb ]
+
+After calling netif_rx_ni(skb), dereferencing skb is unsafe.
+Especially, the canfd_frame cfd which aliases skb memory is accessed
+after the netif_rx_ni().
+
+Fixes: a8f820a380a2 ("can: add Virtual CAN Tunnel driver (vxcan)")
+Link: https://lore.kernel.org/r/20210120114137.200019-3-mailhol.vincent@wanadoo.fr
+Signed-off-by: Vincent Mailhol <mailhol.vincent@wanadoo.fr>
+Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/net/can/vxcan.c | 6 ++++--
+ 1 file changed, 4 insertions(+), 2 deletions(-)
+
+diff --git a/drivers/net/can/vxcan.c b/drivers/net/can/vxcan.c
+index d6ba9426be4de..b1baa4ac1d537 100644
+--- a/drivers/net/can/vxcan.c
++++ b/drivers/net/can/vxcan.c
+@@ -39,6 +39,7 @@ static netdev_tx_t vxcan_xmit(struct sk_buff *skb, struct net_device *dev)
+ struct net_device *peer;
+ struct canfd_frame *cfd = (struct canfd_frame *)skb->data;
+ struct net_device_stats *peerstats, *srcstats = &dev->stats;
++ u8 len;
+
+ if (can_dropped_invalid_skb(dev, skb))
+ return NETDEV_TX_OK;
+@@ -61,12 +62,13 @@ static netdev_tx_t vxcan_xmit(struct sk_buff *skb, struct net_device *dev)
+ skb->dev = peer;
+ skb->ip_summed = CHECKSUM_UNNECESSARY;
+
++ len = cfd->len;
+ if (netif_rx_ni(skb) == NET_RX_SUCCESS) {
+ srcstats->tx_packets++;
+- srcstats->tx_bytes += cfd->len;
++ srcstats->tx_bytes += len;
+ peerstats = &peer->stats;
+ peerstats->rx_packets++;
+- peerstats->rx_bytes += cfd->len;
++ peerstats->rx_bytes += len;
+ }
+
+ out_unlock:
+--
+2.27.0
+
--- /dev/null
+From d8ec06bbb7295b79bb99cc6d74c1f436b636ab7a Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Sat, 9 Jan 2021 13:43:08 +0100
+Subject: i2c: octeon: check correct size of maximum RECV_LEN packet
+
+From: Wolfram Sang <wsa+renesas@sang-engineering.com>
+
+[ Upstream commit 1b2cfa2d1dbdcc3b6dba1ecb7026a537a1d7277f ]
+
+I2C_SMBUS_BLOCK_MAX defines already the maximum number as defined in the
+SMBus 2.0 specs. No reason to add one to it.
+
+Fixes: 886f6f8337dd ("i2c: octeon: Support I2C_M_RECV_LEN")
+Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
+Reviewed-by: Robert Richter <rric@kernel.org>
+Signed-off-by: Wolfram Sang <wsa@kernel.org>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/i2c/busses/i2c-octeon-core.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/drivers/i2c/busses/i2c-octeon-core.c b/drivers/i2c/busses/i2c-octeon-core.c
+index d9607905dc2f1..845eda70b8cab 100644
+--- a/drivers/i2c/busses/i2c-octeon-core.c
++++ b/drivers/i2c/busses/i2c-octeon-core.c
+@@ -347,7 +347,7 @@ static int octeon_i2c_read(struct octeon_i2c *i2c, int target,
+ if (result)
+ return result;
+ if (recv_len && i == 0) {
+- if (data[i] > I2C_SMBUS_BLOCK_MAX + 1)
++ if (data[i] > I2C_SMBUS_BLOCK_MAX)
+ return -EPROTO;
+ length += data[i];
+ }
+--
+2.27.0
+
--- /dev/null
+From e39cee8758f75de7fe563d9a7935bc619e639ee4 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Thu, 17 Dec 2020 10:49:12 +0800
+Subject: pinctrl: aspeed: g6: Fix PWMG0 pinctrl setting
+
+From: Billy Tsai <billy_tsai@aspeedtech.com>
+
+[ Upstream commit 92ff62a7bcc17d47c0ce8dddfb7a6e1a2e55ebf4 ]
+
+The SCU offset for signal PWM8 in group PWM8G0 is wrong, fix it from
+SCU414 to SCU4B4.
+
+Signed-off-by: Billy Tsai <billy_tsai@aspeedtech.com>
+Fixes: 2eda1cdec49f ("pinctrl: aspeed: Add AST2600 pinmux support")
+Reviewed-by: Joel Stanley <joel@jms.id.au>
+Reviewed-by: Andrew Jeffery <andrew@aj.id.au>
+Link: https://lore.kernel.org/r/20201217024912.3198-1-billy_tsai@aspeedtech.com
+Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/pinctrl/aspeed/pinctrl-aspeed-g6.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/drivers/pinctrl/aspeed/pinctrl-aspeed-g6.c b/drivers/pinctrl/aspeed/pinctrl-aspeed-g6.c
+index bb07024d22edc..0a745769e7127 100644
+--- a/drivers/pinctrl/aspeed/pinctrl-aspeed-g6.c
++++ b/drivers/pinctrl/aspeed/pinctrl-aspeed-g6.c
+@@ -334,7 +334,7 @@ FUNC_GROUP_DECL(RMII4, F24, E23, E24, E25, C25, C24, B26, B25, B24);
+
+ #define D22 40
+ SIG_EXPR_LIST_DECL_SESG(D22, SD1CLK, SD1, SIG_DESC_SET(SCU414, 8));
+-SIG_EXPR_LIST_DECL_SEMG(D22, PWM8, PWM8G0, PWM8, SIG_DESC_SET(SCU414, 8));
++SIG_EXPR_LIST_DECL_SEMG(D22, PWM8, PWM8G0, PWM8, SIG_DESC_SET(SCU4B4, 8));
+ PIN_DECL_2(D22, GPIOF0, SD1CLK, PWM8);
+ GROUP_DECL(PWM8G0, D22);
+
+--
+2.27.0
+
--- /dev/null
+From 10276409fcc533f6e567092ea2b5049429393054 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Thu, 14 Jan 2021 15:34:32 +0100
+Subject: platform/x86: intel-vbtn: Drop HP Stream x360 Convertible PC 11 from
+ allow-list
+
+From: Hans de Goede <hdegoede@redhat.com>
+
+[ Upstream commit 070222731be52d741e55d8967b1764482b81e54c ]
+
+THe HP Stream x360 Convertible PC 11 DSDT has the following VGBS function:
+
+ Method (VGBS, 0, Serialized)
+ {
+ If ((^^PCI0.LPCB.EC0.ROLS == Zero))
+ {
+ VBDS = Zero
+ }
+ Else
+ {
+ VBDS = Zero
+ }
+
+ Return (VBDS) /* \_SB_.VGBI.VBDS */
+ }
+
+Which is obviously wrong, because it always returns 0 independent of the
+2-in-1 being in laptop or tablet mode. This causes the intel-vbtn driver
+to initially report SW_TABLET_MODE = 1 to userspace, which is known to
+cause problems when the 2-in-1 is actually in laptop mode.
+
+During earlier testing this turned out to not be a problem because the
+2-in-1 would do a Notify(..., 0xCC) or Notify(..., 0xCD) soon after
+the intel-vbtn driver loaded, correcting the SW_TABLET_MODE state.
+
+Further testing however has shown that this Notify() soon after the
+intel-vbtn driver loads, does not always happen. When the Notify
+does not happen, then intel-vbtn reports SW_TABLET_MODE = 1 resulting in
+a non-working touchpad.
+
+IOW the tablet-mode reporting is not reliable on this device, so it
+should be dropped from the allow-list, fixing the touchpad sometimes
+not working.
+
+Fixes: 8169bd3e6e19 ("platform/x86: intel-vbtn: Switch to an allow-list for SW_TABLET_MODE reporting")
+Link: https://lore.kernel.org/r/20210114143432.31750-1-hdegoede@redhat.com
+Signed-off-by: Hans de Goede <hdegoede@redhat.com>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/platform/x86/intel-vbtn.c | 6 ------
+ 1 file changed, 6 deletions(-)
+
+diff --git a/drivers/platform/x86/intel-vbtn.c b/drivers/platform/x86/intel-vbtn.c
+index bc8b0098d4f32..37035dca469cf 100644
+--- a/drivers/platform/x86/intel-vbtn.c
++++ b/drivers/platform/x86/intel-vbtn.c
+@@ -191,12 +191,6 @@ static const struct dmi_system_id dmi_switches_allow_list[] = {
+ DMI_MATCH(DMI_PRODUCT_NAME, "Venue 11 Pro 7130"),
+ },
+ },
+- {
+- .matches = {
+- DMI_MATCH(DMI_SYS_VENDOR, "Hewlett-Packard"),
+- DMI_MATCH(DMI_PRODUCT_NAME, "HP Stream x360 Convertible PC 11"),
+- },
+- },
+ {
+ .matches = {
+ DMI_MATCH(DMI_SYS_VENDOR, "Hewlett-Packard"),
+--
+2.27.0
+
--- /dev/null
+From 1ad094150190a155398284c3a9ff8cfebceeed91 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Sat, 2 Jan 2021 22:11:56 +0200
+Subject: powerpc: Fix alignment bug within the init sections
+
+From: Ariel Marcovitch <arielmarcovitch@gmail.com>
+
+[ Upstream commit 2225a8dda263edc35a0e8b858fe2945cf6240fde ]
+
+This is a bug that causes early crashes in builds with an .exit.text
+section smaller than a page and an .init.text section that ends in the
+beginning of a physical page (this is kinda random, which might
+explain why this wasn't really encountered before).
+
+The init sections are ordered like this:
+ .init.text
+ .exit.text
+ .init.data
+
+Currently, these sections aren't page aligned.
+
+Because the init code might become read-only at runtime and because
+the .init.text section can potentially reside on the same physical
+page as .init.data, the beginning of .init.data might be mapped
+read-only along with .init.text.
+
+Then when the kernel tries to modify a variable in .init.data (like
+kthreadd_done, used in kernel_init()) the kernel panics.
+
+To avoid this, make _einittext page aligned and also align .exit.text
+to make sure .init.data is always seperated from the text segments.
+
+Fixes: 060ef9d89d18 ("powerpc32: PAGE_EXEC required for inittext")
+Signed-off-by: Ariel Marcovitch <ariel.marcovitch@gmail.com>
+Reviewed-by: Christophe Leroy <christophe.leroy@csgroup.eu>
+Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
+Link: https://lore.kernel.org/r/20210102201156.10805-1-ariel.marcovitch@gmail.com
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ arch/powerpc/kernel/vmlinux.lds.S | 8 ++++++++
+ 1 file changed, 8 insertions(+)
+
+diff --git a/arch/powerpc/kernel/vmlinux.lds.S b/arch/powerpc/kernel/vmlinux.lds.S
+index f9081724d6910..a4e576019d79c 100644
+--- a/arch/powerpc/kernel/vmlinux.lds.S
++++ b/arch/powerpc/kernel/vmlinux.lds.S
+@@ -210,6 +210,12 @@ SECTIONS
+ .init.text : AT(ADDR(.init.text) - LOAD_OFFSET) {
+ _sinittext = .;
+ INIT_TEXT
++
++ /*
++ *.init.text might be RO so we must ensure this section ends on
++ * a page boundary.
++ */
++ . = ALIGN(PAGE_SIZE);
+ _einittext = .;
+ #ifdef CONFIG_PPC64
+ *(.tramp.ftrace.init);
+@@ -223,6 +229,8 @@ SECTIONS
+ EXIT_TEXT
+ }
+
++ . = ALIGN(PAGE_SIZE);
++
+ INIT_DATA_SECTION(16)
+
+ . = ALIGN(8);
+--
+2.27.0
+
--- /dev/null
+From d35e69fef1648900516d4a334dd9872ad387ee90 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Wed, 4 Nov 2020 18:59:10 +0800
+Subject: powerpc: Use the common INIT_DATA_SECTION macro in vmlinux.lds.S
+
+From: Youling Tang <tangyouling@loongson.cn>
+
+[ Upstream commit fdcfeaba38e5b183045f5b079af94f97658eabe6 ]
+
+Use the common INIT_DATA_SECTION rule for the linker script in an effort
+to regularize the linker script.
+
+Signed-off-by: Youling Tang <tangyouling@loongson.cn>
+Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
+Link: https://lore.kernel.org/r/1604487550-20040-1-git-send-email-tangyouling@loongson.cn
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ arch/powerpc/kernel/vmlinux.lds.S | 19 +------------------
+ 1 file changed, 1 insertion(+), 18 deletions(-)
+
+diff --git a/arch/powerpc/kernel/vmlinux.lds.S b/arch/powerpc/kernel/vmlinux.lds.S
+index 4def51c12e1bf..f9081724d6910 100644
+--- a/arch/powerpc/kernel/vmlinux.lds.S
++++ b/arch/powerpc/kernel/vmlinux.lds.S
+@@ -223,21 +223,7 @@ SECTIONS
+ EXIT_TEXT
+ }
+
+- .init.data : AT(ADDR(.init.data) - LOAD_OFFSET) {
+- INIT_DATA
+- }
+-
+- .init.setup : AT(ADDR(.init.setup) - LOAD_OFFSET) {
+- INIT_SETUP(16)
+- }
+-
+- .initcall.init : AT(ADDR(.initcall.init) - LOAD_OFFSET) {
+- INIT_CALLS
+- }
+-
+- .con_initcall.init : AT(ADDR(.con_initcall.init) - LOAD_OFFSET) {
+- CON_INITCALL
+- }
++ INIT_DATA_SECTION(16)
+
+ . = ALIGN(8);
+ __ftr_fixup : AT(ADDR(__ftr_fixup) - LOAD_OFFSET) {
+@@ -265,9 +251,6 @@ SECTIONS
+ __stop___fw_ftr_fixup = .;
+ }
+ #endif
+- .init.ramfs : AT(ADDR(.init.ramfs) - LOAD_OFFSET) {
+- INIT_RAM_FS
+- }
+
+ PERCPU_SECTION(L1_CACHE_BYTES)
+
+--
+2.27.0
+
--- /dev/null
+From 5e61152de4e6d9e56d9d7065835eac687946bb9e Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Tue, 5 Jan 2021 00:41:04 +0100
+Subject: scsi: megaraid_sas: Fix MEGASAS_IOC_FIRMWARE regression
+
+From: Arnd Bergmann <arnd@arndb.de>
+
+[ Upstream commit b112036535eda34460677ea883eaecc3a45a435d ]
+
+Phil Oester reported that a fix for a possible buffer overrun that I sent
+caused a regression that manifests in this output:
+
+ Event Message: A PCI parity error was detected on a component at bus 0 device 5 function 0.
+ Severity: Critical
+ Message ID: PCI1308
+
+The original code tried to handle the sense data pointer differently when
+using 32-bit 64-bit DMA addressing, which would lead to a 32-bit dma_addr_t
+value of 0x11223344 to get stored
+
+32-bit kernel: 44 33 22 11 ?? ?? ?? ??
+64-bit LE kernel: 44 33 22 11 00 00 00 00
+64-bit BE kernel: 00 00 00 00 44 33 22 11
+
+or a 64-bit dma_addr_t value of 0x1122334455667788 to get stored as
+
+32-bit kernel: 88 77 66 55 ?? ?? ?? ??
+64-bit kernel: 88 77 66 55 44 33 22 11
+
+In my patch, I tried to ensure that the same value is used on both 32-bit
+and 64-bit kernels, and picked what seemed to be the most sensible
+combination, storing 32-bit addresses in the first four bytes (as 32-bit
+kernels already did), and 64-bit addresses in eight consecutive bytes (as
+64-bit kernels already did), but evidently this was incorrect.
+
+Always storing the dma_addr_t pointer as 64-bit little-endian,
+i.e. initializing the second four bytes to zero in case of 32-bit
+addressing, apparently solved the problem for Phil, and is consistent with
+what all 64-bit little-endian machines did before.
+
+I also checked in the history that in previous versions of the code, the
+pointer was always in the first four bytes without padding, and that
+previous attempts to fix 64-bit user space, big-endian architectures and
+64-bit DMA were clearly flawed and seem to have introduced made this worse.
+
+Link: https://lore.kernel.org/r/20210104234137.438275-1-arnd@kernel.org
+Fixes: 381d34e376e3 ("scsi: megaraid_sas: Check user-provided offsets")
+Fixes: 107a60dd71b5 ("scsi: megaraid_sas: Add support for 64bit consistent DMA")
+Fixes: 94cd65ddf4d7 ("[SCSI] megaraid_sas: addded support for big endian architecture")
+Fixes: 7b2519afa1ab ("[SCSI] megaraid_sas: fix 64 bit sense pointer truncation")
+Reported-by: Phil Oester <kernel@linuxace.com>
+Tested-by: Phil Oester <kernel@linuxace.com>
+Signed-off-by: Arnd Bergmann <arnd@arndb.de>
+Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/scsi/megaraid/megaraid_sas_base.c | 6 ++----
+ 1 file changed, 2 insertions(+), 4 deletions(-)
+
+diff --git a/drivers/scsi/megaraid/megaraid_sas_base.c b/drivers/scsi/megaraid/megaraid_sas_base.c
+index 4a23dd8b7f9aa..b9c1f722f1ded 100644
+--- a/drivers/scsi/megaraid/megaraid_sas_base.c
++++ b/drivers/scsi/megaraid/megaraid_sas_base.c
+@@ -8174,11 +8174,9 @@ megasas_mgmt_fw_ioctl(struct megasas_instance *instance,
+ goto out;
+ }
+
++ /* always store 64 bits regardless of addressing */
+ sense_ptr = (void *)cmd->frame + ioc->sense_off;
+- if (instance->consistent_mask_64bit)
+- put_unaligned_le64(sense_handle, sense_ptr);
+- else
+- put_unaligned_le32(sense_handle, sense_ptr);
++ put_unaligned_le64(sense_handle, sense_ptr);
+ }
+
+ /*
+--
+2.27.0
+
--- /dev/null
+From 3d0d7752888ceaff9d1d0415f9d0ec28ff881c37 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Tue, 19 Jan 2021 10:59:30 +0800
+Subject: selftests: net: fib_tests: remove duplicate log test
+
+From: Hangbin Liu <liuhangbin@gmail.com>
+
+[ Upstream commit fd23d2dc180fccfad4b27a8e52ba1bc415d18509 ]
+
+The previous test added an address with a specified metric and check if
+correspond route was created. I somehow added two logs for the same
+test. Remove the duplicated one.
+
+Reported-by: Antoine Tenart <atenart@redhat.com>
+Fixes: 0d29169a708b ("selftests/net/fib_tests: update addr_metric_test for peer route testing")
+Signed-off-by: Hangbin Liu <liuhangbin@gmail.com>
+Reviewed-by: David Ahern <dsahern@kernel.org>
+Link: https://lore.kernel.org/r/20210119025930.2810532-1-liuhangbin@gmail.com
+Signed-off-by: Jakub Kicinski <kuba@kernel.org>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ tools/testing/selftests/net/fib_tests.sh | 1 -
+ 1 file changed, 1 deletion(-)
+
+diff --git a/tools/testing/selftests/net/fib_tests.sh b/tools/testing/selftests/net/fib_tests.sh
+index 4811067d9b053..4e19a1c00ddd8 100755
+--- a/tools/testing/selftests/net/fib_tests.sh
++++ b/tools/testing/selftests/net/fib_tests.sh
+@@ -1055,7 +1055,6 @@ ipv6_addr_metric_test()
+
+ check_route6 "2001:db8:104::1 dev dummy2 proto kernel metric 260"
+ log_test $? 0 "Set metric with peer route on local side"
+- log_test $? 0 "User specified metric on local address"
+ check_route6 "2001:db8:104::2 dev dummy2 proto kernel metric 260"
+ log_test $? 0 "Set metric with peer route on peer side"
+
+--
+2.27.0
+
drm-nouveau-i2c-gm200-increase-width-of-aux-semaphor.patch
drm-nouveau-mmu-fix-vram-heap-sizing.patch
drm-nouveau-kms-nv50-fix-case-where-notifier-buffer-.patch
+powerpc-use-the-common-init_data_section-macro-in-vm.patch
+pinctrl-aspeed-g6-fix-pwmg0-pinctrl-setting.patch
+scsi-megaraid_sas-fix-megasas_ioc_firmware-regressio.patch
+powerpc-fix-alignment-bug-within-the-init-sections.patch
+i2c-octeon-check-correct-size-of-maximum-recv_len-pa.patch
+platform-x86-intel-vbtn-drop-hp-stream-x360-converti.patch
+selftests-net-fib_tests-remove-duplicate-log-test.patch
+can-dev-can_restart-fix-use-after-free-bug.patch
+can-vxcan-vxcan_xmit-fix-use-after-free-bug.patch
+can-peak_usb-fix-use-after-free-bugs.patch
projects / thirdparty / kernel / stable-queue.git / commitdiff
