Skip to contentSkip to conversation

5.12.1-rc1 review

PATCH In review Greg Kroah-Hartman 8 participants 13 messages Apr 30, 2021 – May 1, 2021 Stable branch

lore
Share & tools
lore

Greg Kroah-Hartman

author maintainer
#0 lore raw

cover 5.12.1-rc1 review

This is the start of the stable review cycle for the 5.12.1 release. There are 5 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 Sun, 02 May 2021 14:19:04 +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.12.1-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.12.y
and the diffstat can be found below.

thanks,

greg k-h

-------------
Pseudo-Shortlog of commits:

Greg Kroah-Hartman <[email protected]>

    Linux 5.12.1-rc1

Tomas Winkler <[email protected]>
mei: me: add Alder Lake P device id.

Johannes Berg <[email protected]>
cfg80211: fix locking in netlink owner interface destruction

Jiri Kosina <[email protected]>
iwlwifi: Fix softirq/hardirq disabling in iwl_pcie_gen2_enqueue_hcmd()

Oliver Neukum <[email protected]>
USB: CDC-ACM: fix poison/unpoison imbalance

Johan Hovold <[email protected]>
net: hso: fix NULL-deref on disconnect regression

-------------

Diffstat:

 Makefile                                          |  4 ++--
 drivers/misc/mei/hw-me-regs.h                     |  1 +
 drivers/misc/mei/pci-me.c                         |  1 +
 drivers/net/usb/hso.c                             |  2 +-
 drivers/net/wireless/intel/iwlwifi/pcie/tx-gen2.c |  7 ++++---
 drivers/usb/class/cdc-acm.c                       |  3 ++-
 net/wireless/core.c                               | 21 ++++++++++++++++----
 net/wireless/nl80211.c                            | 24 ++++++++++++++++++-----
 8 files changed, 47 insertions(+), 16 deletions(-)
author maintainer
#1 lore raw

PATCH 1/5 net: hso: fix NULL-deref on disconnect regression

From: Johan Hovold <[email protected]>

commit 2ad5692db72874f02b9ad551d26345437ea4f7f3 upstream.

Commit 8a12f8836145 ("net: hso: fix null-ptr-deref during tty device unregistration") fixed the racy minor allocation reported by syzbot, but introduced an unconditional NULL-pointer dereference on every disconnect instead.

Specifically, the serial device table must no longer be accessed after the minor has been released by hso_serial_tty_unregister().

Fixes 8a12f8836145 ("net: hso: fix null-ptr-deref during tty device unregistration")
Cc Anirudh Rayabharam <[email protected]>
---
 drivers/net/usb/hso.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/net/usb/hso.c +1 -1
@@ -3104,7 +3104,7 @@ static void hso_free_interface(struct us
 			cancel_work_sync(&serial_table[i]->async_put_intf);
 			cancel_work_sync(&serial_table[i]->async_get_intf);
 			hso_serial_tty_unregister(serial);
-			kref_put(&serial_table[i]->ref, hso_serial_ref_free);
+			kref_put(&serial->parent->ref, hso_serial_ref_free);
 		}
 	}
 
author maintainer
#2 lore raw

PATCH 2/5 USB: CDC-ACM: fix poison/unpoison imbalance

In reply to Greg Kroah-Hartman

From: Oliver Neukum <[email protected]>

commit a8b3b519618f30a87a304c4e120267ce6f8dc68a upstream.

suspend() does its poisoning conditionally, resume() does it unconditionally. On a device with combined interfaces this will balance, on a device with two interfaces the counter will go negative and resubmission will fail.

Both actions need to be done conditionally.

Fixes 6069e3e927c8f ("USB: cdc-acm: untangle a circular dependency between callback and softint")
Cc stable <[email protected]>
---
 drivers/usb/class/cdc-acm.c |    3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)
drivers/usb/class/cdc-acm.c +2 -1
@@ -1634,12 +1634,13 @@ static int acm_resume(struct usb_interfa
 	struct urb *urb;
 	int rv = 0;
 
-	acm_unpoison_urbs(acm);
 	spin_lock_irq(&acm->write_lock);
 
 	if (--acm->susp_count)
 		goto out;
 
+	acm_unpoison_urbs(acm);
+
 	if (tty_port_initialized(&acm->port)) {
 		rv = usb_submit_urb(acm->ctrlurb, GFP_ATOMIC);
 
author maintainer
#3 lore raw

PATCH 3/5 iwlwifi: Fix softirq/hardirq disabling in iwl_pcie_gen2_enqueue_hcmd()

In reply to Greg Kroah-Hartman

From: Jiri Kosina <[email protected]>

commit e7020bb068d8be50a92f48e36b236a1a1ef9282e upstream.

Analogically to what we did in 2800aadc18a6 ("iwlwifi: Fix softirq/hardirq disabling in iwl_pcie_enqueue_hcmd()"), we must apply the same fix to iwl_pcie_gen2_enqueue_hcmd(), as it's being called from exactly the same contexts.

---
 drivers/net/wireless/intel/iwlwifi/pcie/tx-gen2.c |    7 ++++---
 1 file changed, 4 insertions(+), 3 deletions(-)
drivers/net/wireless/intel/iwlwifi/pcie/tx-gen2.c +4 -3
@@ -40,6 +40,7 @@ int iwl_pcie_gen2_enqueue_hcmd(struct iw
 	const u8 *cmddata[IWL_MAX_CMD_TBS_PER_TFD];
 	u16 cmdlen[IWL_MAX_CMD_TBS_PER_TFD];
 	struct iwl_tfh_tfd *tfd;
+	unsigned long flags;
 
 	copy_size = sizeof(struct iwl_cmd_header_wide);
 	cmd_size = sizeof(struct iwl_cmd_header_wide);
@@ -108,14 +109,14 @@ int iwl_pcie_gen2_enqueue_hcmd(struct iw
 		goto free_dup_buf;
 	}
 
-	spin_lock_bh(&txq->lock);
+	spin_lock_irqsave(&txq->lock, flags);
 
 	idx = iwl_txq_get_cmd_index(txq, txq->write_ptr);
 	tfd = iwl_txq_get_tfd(trans, txq, txq->write_ptr);
 	memset(tfd, 0, sizeof(*tfd));
 
 	if (iwl_txq_space(trans, txq) < ((cmd->flags & CMD_ASYNC) ? 2 : 1)) {
-		spin_unlock_bh(&txq->lock);
+		spin_unlock_irqrestore(&txq->lock, flags);
 
 		IWL_ERR(trans, "No space in command queue\n");
 		iwl_op_mode_cmd_queue_full(trans->op_mode);
@@ -250,7 +251,7 @@ int iwl_pcie_gen2_enqueue_hcmd(struct iw
 	spin_unlock(&trans_pcie->reg_lock);
 
 out:
-	spin_unlock_bh(&txq->lock);
+	spin_unlock_irqrestore(&txq->lock, flags);
 free_dup_buf:
 	if (idx < 0)
 		kfree(dup_buf);
author maintainer
#4 lore raw

PATCH 4/5 cfg80211: fix locking in netlink owner interface destruction

In reply to Greg Kroah-Hartman

From: Johannes Berg <[email protected]>

commit ea6b2098dd02789f68770fd3d5a373732207be2f upstream.

Harald Arnesen reported [1] a deadlock at reboot time, and after he captured a stack trace a picture developed of what's going on:

The distribution he's using is using iwd (not wpa_supplicant) to manage wireless. iwd will usually use the "socket owner" option when it creates new interfaces, so that they're automatically destroyed when it quits (unexpectedly or otherwise). This is also done by wpa_supplicant, but it doesn't do it for the normal one, only for additional ones, which is different with iwd.

Anyway, during shutdown, iwd quits while the netdev is still UP, i.e. IFF_UP is set. This causes the stack trace that Linus so nicely transcribed from the pictures:

cfg80211_destroy_iface_wk() takes wiphy_lock
-> cfg80211_destroy_ifaces()
->ieee80211_del_iface

    ->ieeee80211_if_remove
      ->cfg80211_unregister_wdev
        ->unregister_netdevice_queue
          ->dev_close_many
            ->__dev_close_many
              ->raw_notifier_call_chain
                ->cfg80211_netdev_notifier_call

and that last call tries to take wiphy_lock again.

In commit a05829a7222e ("cfg80211: avoid holding the RTNL when calling the driver") I had taken into account the possibility of recursing from cfg80211 into cfg80211_netdev_notifier_call() via the network stack, but only for NETDEV_UNREGISTER, not for what happens here, NETDEV_GOING_DOWN and NETDEV_DOWN notifications.

Additionally, while this worked still back in commit 78f22b6a3a92 ("cfg80211: allow userspace to take ownership of interfaces"), it missed another corner case: unregistering a netdev will cause dev_close() to be called, and thus stop wireless operations (e.g. disconnecting), but there are some types of virtual interfaces in wifi that don't have a netdev - for that we need an additional call to cfg80211_leave().

So, to fix this mess, change cfg80211_destroy_ifaces() to not require the wiphy_lock(), but instead make it acquire it, but only after it has actually closed all the netdevs on the list, and then call cfg80211_leave() as well before removing them from the driver, to fix the second issue. The locking change in this requires modifying the nl80211 call to not get the wiphy lock passed in, but acquire it by itself after flushing any potentially pending destruction requests.

[1] https://lore.kernel.org/r/[email protected]

Fixes 776a39b8196d ("cfg80211: call cfg80211_destroy_ifaces() with wiphy lock held")
Fixes 78f22b6a3a92 ("cfg80211: allow userspace to take ownership of interfaces")
---
 net/wireless/core.c    |   21 +++++++++++++++++----
 net/wireless/nl80211.c |   24 +++++++++++++++++++-----
 2 files changed, 36 insertions(+), 9 deletions(-)
net/wireless/core.c +17 -4
@@ -332,14 +332,29 @@ static void cfg80211_event_work(struct w
 void cfg80211_destroy_ifaces(struct cfg80211_registered_device *rdev)
 {
 	struct wireless_dev *wdev, *tmp;
+	bool found = false;
 
 	ASSERT_RTNL();
-	lockdep_assert_wiphy(&rdev->wiphy);
 
+	list_for_each_entry(wdev, &rdev->wiphy.wdev_list, list) {
+		if (wdev->nl_owner_dead) {
+			if (wdev->netdev)
+				dev_close(wdev->netdev);
+			found = true;
+		}
+	}
+
+	if (!found)
+		return;
+
+	wiphy_lock(&rdev->wiphy);
 	list_for_each_entry_safe(wdev, tmp, &rdev->wiphy.wdev_list, list) {
-		if (wdev->nl_owner_dead)
+		if (wdev->nl_owner_dead) {
+			cfg80211_leave(rdev, wdev);
 			rdev_del_virtual_intf(rdev, wdev);
+		}
 	}
+	wiphy_unlock(&rdev->wiphy);
 }
 
 static void cfg80211_destroy_iface_wk(struct work_struct *work)
@@ -350,9 +365,7 @@ static void cfg80211_destroy_iface_wk(st
 			    destroy_work);
 
 	rtnl_lock();
-	wiphy_lock(&rdev->wiphy);
 	cfg80211_destroy_ifaces(rdev);
-	wiphy_unlock(&rdev->wiphy);
 	rtnl_unlock();
 }
 
net/wireless/nl80211.c +19 -5
@@ -3929,7 +3929,7 @@ static int nl80211_set_interface(struct
 	return err;
 }
 
-static int nl80211_new_interface(struct sk_buff *skb, struct genl_info *info)
+static int _nl80211_new_interface(struct sk_buff *skb, struct genl_info *info)
 {
 	struct cfg80211_registered_device *rdev = info->user_ptr[0];
 	struct vif_params params;
@@ -3938,9 +3938,6 @@ static int nl80211_new_interface(struct
 	int err;
 	enum nl80211_iftype type = NL80211_IFTYPE_UNSPECIFIED;
 
-	/* to avoid failing a new interface creation due to pending removal */
-	cfg80211_destroy_ifaces(rdev);
-
 	memset(&params, 0, sizeof(params));
 
 	if (!info->attrs[NL80211_ATTR_IFNAME])
@@ -4028,6 +4025,21 @@ static int nl80211_new_interface(struct
 	return genlmsg_reply(msg, info);
 }
 
+static int nl80211_new_interface(struct sk_buff *skb, struct genl_info *info)
+{
+	struct cfg80211_registered_device *rdev = info->user_ptr[0];
+	int ret;
+
+	/* to avoid failing a new interface creation due to pending removal */
+	cfg80211_destroy_ifaces(rdev);
+
+	wiphy_lock(&rdev->wiphy);
+	ret = _nl80211_new_interface(skb, info);
+	wiphy_unlock(&rdev->wiphy);
+
+	return ret;
+}
+
 static int nl80211_del_interface(struct sk_buff *skb, struct genl_info *info)
 {
 	struct cfg80211_registered_device *rdev = info->user_ptr[0];
@@ -15040,7 +15052,9 @@ static const struct genl_small_ops nl802
 		.doit = nl80211_new_interface,
 		.flags = GENL_UNS_ADMIN_PERM,
 		.internal_flags = NL80211_FLAG_NEED_WIPHY |
-				  NL80211_FLAG_NEED_RTNL,
+				  NL80211_FLAG_NEED_RTNL |
+				  /* we take the wiphy mutex later ourselves */
+				  NL80211_FLAG_NO_WIPHY_MTX,
 	},
 	{
 		.cmd = NL80211_CMD_DEL_INTERFACE,
#5 lore raw

Re: [PATCH 5.12 4/5] cfg80211: fix locking in netlink owner interface destruction

Greg Kroah-Hartman [30.04.2021 16:20]:

Quoted 7 lines

From: Johannes Berg <[email protected]>

commit ea6b2098dd02789f68770fd3d5a373732207be2f upstream.

Harald Arnesen reported [1] a deadlock at reboot time, and after he captured a stack trace a picture developed of what's going on:

Quoted 6 lines

The distribution he's using is using iwd (not wpa_supplicant) to manage wireless. iwd will usually use the "socket owner" option when it creates new interfaces, so that they're automatically destroyed when it quits (unexpectedly or otherwise). This is also done by wpa_supplicant, but it doesn't do it for the normal one, only for additional ones, which is different with iwd.

I just want to point out that the distribution (Void Linux) can use either wpa_supplicant or iwd. I just happened to use iwd on this machine.

Signature · 1 line
Hilsen Harald
author maintainer
#6 lore raw

PATCH 5/5 mei: me: add Alder Lake P device id.

In reply to Greg Kroah-Hartman

From: Tomas Winkler <[email protected]>

commit 0df74278faedf20f9696bf2755cf0ce34afa4c3a upstream.

Add Alder Lake P device ID.

---
 drivers/misc/mei/hw-me-regs.h |    1 +
 drivers/misc/mei/pci-me.c     |    1 +
 2 files changed, 2 insertions(+)
drivers/misc/mei/hw-me-regs.h +1 -0
@@ -105,6 +105,7 @@
 
 #define MEI_DEV_ID_ADP_S      0x7AE8  /* Alder Lake Point S */
 #define MEI_DEV_ID_ADP_LP     0x7A60  /* Alder Lake Point LP */
+#define MEI_DEV_ID_ADP_P      0x51E0  /* Alder Lake Point P */
 
 /*
  * MEI HW Section
drivers/misc/mei/pci-me.c +1 -0
@@ -111,6 +111,7 @@ static const struct pci_device_id mei_me
 
 	{MEI_PCI_DEVICE(MEI_DEV_ID_ADP_S, MEI_ME_PCH15_CFG)},
 	{MEI_PCI_DEVICE(MEI_DEV_ID_ADP_LP, MEI_ME_PCH15_CFG)},
+	{MEI_PCI_DEVICE(MEI_DEV_ID_ADP_P, MEI_ME_PCH15_CFG)},
 
 	/* required last entry */
 	{0, }
Tested-by on the v1 series
#7 lore raw
In reply to Greg Kroah-Hartman
Quoted 9 lines · Greg Kroah-Hartman

This is the start of the stable review cycle for the 5.12.1 release. There are 5 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 Sun, 02 May 2021 14:19:04 +0000. Anything received after that time might be too late.

The whole patch series can be found in one patch at:

Quoted 9 lines
	https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.12.1-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.12.y
and the diffstat can be found below.

thanks,

greg k-h

5.12.1-rc1 Successfully Compiled and booted on my Raspberry PI 4b (8g) (bcm2711)

#8 lore raw
In reply to Greg Kroah-Hartman
Quoted 1 line · On Fri, 30 Apr 2021 16:20:55 +0200 Greg Kroah-Hartman…

This is the start of the stable review cycle for the 5.12.1 release.

I noticed no problems on until I upgraded to new GCC 11.1. This is sparc64.

if [ arch/sparc/kernel/sstate.o != "scripts/mod/empty.o" ]; then ./scripts/recordmcount "arch/sparc/kernel/sstate.o"; fi;
sparc64-linux-gcc -Wp,-MMD,arch/sparc/kernel/.mdesc.o.d -nostdinc -isystem /home/jason/toolchain-11.1.0/bin/../lib/gcc/sparc64-linux/11.1.0/include -I./arch/sparc/include -I./arch/sparc/include/generated -I./include -I./arch/sparc/include/uapi -I./arch/sparc/include/generated/uapi -I./include/uapi -I./include/generated/uapi -include ./include/linux/compiler-version.h -include ./include/linux/kconfig.h -include ./include/linux/compiler_types.h -D__KERNEL__ -fmacro-prefix-map=./= -Wall -Wundef -Werror=strict-prototypes -Wno-trigraphs -fno-strict-aliasing -fno-common -fshort-wchar -fno-PIE -Werror=implicit-function-declaration -Werror=implicit-int -Werror=return-type -Wno-format-security -std=gnu89 -m64 -pipe -mno-fpu -mcpu=ultrasparc -mcmodel=medlow -ffixed-g4 -ffixed-g5 -fcall-used-g7 -Wno-sign-compare -Wa,--undeclared-regs -mtune=ultrasparc3 -pg -fno-delete-null-pointer-checks -Wno-frame-address -Wno-format-truncation -Wno-format-overflow -Wno-address-of-packed-member -O2 -fno-allow-store-data-races -Wframe-larger-than=2048 -fno-stack-protector -Wno-unused-but-set-variable -Wimplicit-fallthrough -Wno-unused-const-variable -fno-omit-frame-pointer -fno-optimize-sibling-calls -pg -Wdeclaration-after-statement -Wvla -Wno-pointer-sign -Wno-stringop-truncation -Wno-zero-length-bounds -Wno-array-bounds -Wno-stringop-overflow -Wno-restrict -Wno-maybe-uninitialized -fno-strict-overflow -fno-stack-check -fconserve-stack -Werror=date-time -Werror=incompatible-pointer-types -Werror=designated-init -Wno-packed-not-aligned -Werror -DKBUILD_MODFILE='"arch/sparc/kernel/mdesc"' -DKBUILD_BASENAME='"mdesc"' -DKBUILD_MODNAME='"mdesc"' -D__KBUILD_MODNAME=kmod_mdesc -c -o arch/sparc/kernel/mdesc.o arch/sparc/kernel/mdesc.c
arch/sparc/kernel/mdesc.c: In function 'mdesc_node_by_name':
arch/sparc/kernel/mdesc.c:647:22: error: 'strcmp' reading 1 or more bytes from a region of size 0 [-Werror=stringop-overread]
647 | if (!strcmp(names + ep[ret].name_offset, name))

      |                      ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
arch/sparc/kernel/mdesc.c:77:33: note: at offset 16 into source object 'mdesc' of size 16
   77 |         struct mdesc_hdr        mdesc;
      |                                 ^~~~~
arch/sparc/kernel/mdesc.c: In function 'mdesc_get_property':
arch/sparc/kernel/mdesc.c:692:22: error: 'strcmp' reading 1 or more bytes from a region of size 0 [-Werror=stringop-overread]
  692 |                 if (!strcmp(names + ep->name_offset, name)) {
      |                      ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
arch/sparc/kernel/mdesc.c:77:33: note: at offset 16 into source object 'mdesc' of size 16
   77 |         struct mdesc_hdr        mdesc;
      |                                 ^~~~~
arch/sparc/kernel/mdesc.c: In function 'mdesc_next_arc':
arch/sparc/kernel/mdesc.c:719:21: error: 'strcmp' reading 1 or more bytes from a region of size 0 [-Werror=stringop-overread]
  719 |                 if (strcmp(names + ep->name_offset, arc_type))
      |                     ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
arch/sparc/kernel/mdesc.c:77:33: note: at offset 16 into source object 'mdesc' of size 16
   77 |         struct mdesc_hdr        mdesc;
      |                                 ^~~~~

cc1: all warnings being treated as errors scripts/Makefile.build:271: recipe for target 'arch/sparc/kernel/mdesc.o' failed make[2]: *** [arch/sparc/kernel/mdesc.o] Error 1 scripts/Makefile.build:514: recipe for target 'arch/sparc/kernel' failed make[1]: *** [arch/sparc/kernel] Error 2
Makefile:1851: recipe for target 'arch/sparc' failed
make: *** [arch/sparc] Error 2

#9 lore raw
Quoted 7 lines · Jason Self
Quoted 1 line · On Fri, 30 Apr 2021 16:20:55 +0200 Greg Kroah-Hartman…

This is the start of the stable review cycle for the 5.12.1 release.

I noticed no problems on until I upgraded to new GCC 11.1. This is sparc64.

I don't think gcc 11.1 builds Linus's tree either yet, so this isn't an issue.

As the fixes for this new compiler come in, letting me know what to backport is appreciated.

thanks,

greg k-h

Tested-by Linux Kernel Functional Testing on the v1 series
#10 lore raw
In reply to Greg Kroah-Hartman
Quoted 10 lines · Greg Kroah-Hartman

This is the start of the stable review cycle for the 5.12.1 release. There are 5 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 Sun, 02 May 2021 14:19:04 +0000. Anything received after that time might be too late.

The whole patch series can be found in one patch at:

Quoted 8 lines
        https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.12.1-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.12.y
and the diffstat can be found below.

thanks,

greg k-h

Results from Linaro’s test farm.
No regressions on arm64, arm, x86_64, and i386.

## Build
* kernel: 5.12.1-rc1
* git: https://gitlab.com/Linaro/lkft/mirrors/stable/linux-stable-rc
* git branch: linux-5.12.y
* git commit: 94990849b4da1a85c0e8aaed7cb3285a6ecff018
* git describe: v5.12-6-g94990849b4da
* test details:
https://qa-reports.linaro.org/lkft/linux-stable-rc-linux-5.12.y/build/v5.12-6-g94990849b4da

## No regressions (compared to v5.12)

## No fixes (compared to v5.12)

## Test result summary
total: 72055, pass: 60456, fail: 1438, skip: 10161, xfail: 0,

## Build Summary
* arc: 10 total, 10 passed, 0 failed
* arm: 193 total, 193 passed, 0 failed
* arm64: 27 total, 27 passed, 0 failed
* i386: 25 total, 25 passed, 0 failed
* mips: 45 total, 45 passed, 0 failed
* parisc: 9 total, 9 passed, 0 failed
* powerpc: 27 total, 27 passed, 0 failed
* riscv: 21 total, 21 passed, 0 failed
* s390: 18 total, 18 passed, 0 failed
* sh: 18 total, 18 passed, 0 failed
* sparc: 9 total, 9 passed, 0 failed
* x86_64: 26 total, 26 passed, 0 failed

## Test suites summary
* fwts
* igt-gpu-tools
* kselftest-android
* kselftest-breakpoints
* kselftest-capabilities
* kselftest-cgroup
* kselftest-clone3
* kselftest-core
* kselftest-cpu-hotplug
* kselftest-cpufreq
* kselftest-drivers
* kselftest-efivarfs
* kselftest-filesystems
* kselftest-firmware
* kselftest-fpu
* kselftest-futex
* kselftest-gpio
* kselftest-ipc
* kselftest-ir
* kselftest-kcmp
* kselftest-kvm
* 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-rseq
* kselftest-rtc
* kselftest-seccomp
* kselftest-sigaltstack
* kselftest-size
* kselftest-splice
* kselftest-static_keys
* kselftest-sync
* kselftest-sysctl
* kselftest-timens
* kselftest-timers
* kselftest-tmpfs
* kselftest-tpm2
* kselftest-user
* kselftest-vm
* kselftest-zram
* kunit
* kvm-unit-tests
* libhugetlbfs
* linux-log-parser
* ltp-cap_bounds-tests
* ltp-commands-tests
* ltp-containers-tests
* ltp-controllers-tests
* ltp-cpuhotplug-tests
* ltp-crypto-tests
* ltp-cve-tests
* ltp-dio-tests
* ltp-fcntl-locktests-tests
* ltp-filecaps-tests
* ltp-fs-tests
* ltp-fs_bind-tests
* ltp-fs_perms_simple-tests
* ltp-fsx-tests
* ltp-hugetlb-tests
* ltp-io-tests
* ltp-ipc-tests
* ltp-math-tests
* ltp-mm-tests
* ltp-nptl-tests
* ltp-open-posix-tests
* ltp-pty-tests
* ltp-sched-tests
* ltp-securebits-tests
* ltp-syscalls-tests
* ltp-tracing-tests
* network-basic-tests
* packetdrill
* perf
* rcutorture
* v4l2-compliance

--
Linaro LKFT
https://lkft.linaro.org

Tested-by on the v1 series
#11 lore raw
In reply to Greg Kroah-Hartman

Hi Greg,

Quoted 9 lines · Greg Kroah-Hartman

This is the start of the stable review cycle for the 5.12.1 release. There are 5 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 Sun, 02 May 2021 14:19:04 +0000. Anything received after that time might be too late.

The whole patch series can be found in one patch at:

Quoted 8 lines
	https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.12.1-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.12.y
and the diffstat can be found below.

thanks,

greg k-h

There is one failure for Tegra, but this is not a regression for v5.12.1 and is a known issue for v5.12 ...

Test results for stable-v5.12:

    12 builds:	12 pass, 0 fail
    28 boots:	28 pass, 0 fail
    104 tests:	103 pass, 1 fail

Linux version: 5.12.1-rc1-g94990849b4da
Boards tested: tegra124-jetson-tk1, tegra186-p2771-0000,

                tegra194-p2972-0000, tegra194-p3509-0000+p3668-0000,
                tegra20-ventana, tegra210-p2371-2180,
                tegra210-p3450-0000, tegra30-cardhu-a04

Test failures: tegra210-p2371-2180: devices

Once the fixes are in the mainline I will let you know the commits to pull into linux-5.12.y. Otherwise ...

Cheers
Jon

Signature · 1 line
nvpublic
Tested-by on the v1 series
#12 lore raw
In reply to Greg Kroah-Hartman
Quoted 8 lines · Greg Kroah-Hartman

This is the start of the stable review cycle for the 5.12.1 release. There are 5 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 Sun, 02 May 2021 14:19:04 +0000. Anything received after that time might be too late.

Build results:

	total: 151 pass: 151 fail: 0
Qemu test results:
	total: 461 pass: 461 fail: 0

Guenter