[PATCH 6.3 00/11] 6.3.1-rc1 review

[PATCH 6.3 00/11] 6.3.1-rc1 review

[Greg Kroah-Hartman]

This is the start of the stable review cycle for the 6.3.1 release.
There are 11 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, 30 Apr 2023 11:20:30 +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/v6.x/stable-review/patch-6.3.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-6.3.y
and the diffstat can be found below.

thanks,

greg k-h

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

Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Linux 6.3.1-rc1

Stephen Boyd <swboyd@chromium.org>
    driver core: Don't require dynamic_debug for initcall_debug probe timing

Arınç ÜNAL <arinc.unal@arinc9.com>
    USB: serial: option: add UNISOC vendor and TOZED LT70C product

Vlastimil Babka <vbabka@suse.cz>
    mm/mremap: fix vm_pgoff in vma_merge() case 3

Genjian Zhang <zhanggenjian@kylinos.cn>
    btrfs: fix uninitialized variable warnings

Marek Vasut <marex@denx.de>
    wifi: brcmfmac: add Cypress 43439 SDIO ids

Ruihan Li <lrh2000@pku.edu.cn>
    bluetooth: Perform careful capability checks in hci_sock_ioctl()

Werner Sembach <wse@tuxedocomputers.com>
    gpiolib: acpi: Add a ignore wakeup quirk for Clevo NL5xNU

Eric Biggers <ebiggers@google.com>
    fsverity: explicitly check for buffer overflow in build_merkle_tree()

Daniel Vetter <daniel.vetter@ffwll.ch>
    drm/fb-helper: set x/yres_virtual in drm_fb_helper_check_var

Eric Biggers <ebiggers@google.com>
    fsverity: reject FS_IOC_ENABLE_VERITY on mode 3 fds

Jisoo Jang <jisoo.jang@yonsei.ac.kr>
    wifi: brcmfmac: slab-out-of-bounds read in brcmf_get_assoc_ies()


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

Diffstat:

 Makefile                                                |  4 ++--
 drivers/base/dd.c                                       |  7 ++++++-
 drivers/gpio/gpiolib-acpi.c                             | 13 +++++++++++++
 drivers/gpu/drm/drm_fb_helper.c                         |  3 +++
 .../net/wireless/broadcom/brcm80211/brcmfmac/bcmsdh.c   |  9 ++++++++-
 .../net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c |  5 +++++
 drivers/usb/serial/option.c                             |  6 ++++++
 fs/btrfs/send.c                                         |  2 +-
 fs/btrfs/volumes.c                                      |  2 +-
 fs/verity/enable.c                                      | 17 +++++++++++++++++
 include/linux/mmc/sdio_ids.h                            |  5 ++++-
 mm/mmap.c                                               |  2 +-
 net/bluetooth/hci_sock.c                                |  9 ++++++++-
 13 files changed, 75 insertions(+), 9 deletions(-)

[PATCH 6.3 01/11] wifi: brcmfmac: slab-out-of-bounds read in brcmf_get_assoc_ies()

[Greg Kroah-Hartman]

From: Jisoo Jang <jisoo.jang@yonsei.ac.kr>

commit 0da40e018fd034d87c9460123fa7f897b69fdee7 upstream.

Fix a slab-out-of-bounds read that occurs in kmemdup() called from
brcmf_get_assoc_ies().
The bug could occur when assoc_info->req_len, data from a URB provided
by a USB device, is bigger than the size of buffer which is defined as
WL_EXTRA_BUF_MAX.

Add the size check for req_len/resp_len of assoc_info.

Found by a modified version of syzkaller.

[   46.592467][    T7] ==================================================================
[   46.594687][    T7] BUG: KASAN: slab-out-of-bounds in kmemdup+0x3e/0x50
[   46.596572][    T7] Read of size 3014656 at addr ffff888019442000 by task kworker/0:1/7
[   46.598575][    T7]
[   46.599157][    T7] CPU: 0 PID: 7 Comm: kworker/0:1 Tainted: G           O      5.14.0+ #145
[   46.601333][    T7] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.12.1-0-ga5cab58e9a3f-prebuilt.qemu.org 04/01/2014
[   46.604360][    T7] Workqueue: events brcmf_fweh_event_worker
[   46.605943][    T7] Call Trace:
[   46.606584][    T7]  dump_stack_lvl+0x8e/0xd1
[   46.607446][    T7]  print_address_description.constprop.0.cold+0x93/0x334
[   46.608610][    T7]  ? kmemdup+0x3e/0x50
[   46.609341][    T7]  kasan_report.cold+0x79/0xd5
[   46.610151][    T7]  ? kmemdup+0x3e/0x50
[   46.610796][    T7]  kasan_check_range+0x14e/0x1b0
[   46.611691][    T7]  memcpy+0x20/0x60
[   46.612323][    T7]  kmemdup+0x3e/0x50
[   46.612987][    T7]  brcmf_get_assoc_ies+0x967/0xf60
[   46.613904][    T7]  ? brcmf_notify_vif_event+0x3d0/0x3d0
[   46.614831][    T7]  ? lock_chain_count+0x20/0x20
[   46.615683][    T7]  ? mark_lock.part.0+0xfc/0x2770
[   46.616552][    T7]  ? lock_chain_count+0x20/0x20
[   46.617409][    T7]  ? mark_lock.part.0+0xfc/0x2770
[   46.618244][    T7]  ? lock_chain_count+0x20/0x20
[   46.619024][    T7]  brcmf_bss_connect_done.constprop.0+0x241/0x2e0
[   46.620019][    T7]  ? brcmf_parse_configure_security.isra.0+0x2a0/0x2a0
[   46.620818][    T7]  ? __lock_acquire+0x181f/0x5790
[   46.621462][    T7]  brcmf_notify_connect_status+0x448/0x1950
[   46.622134][    T7]  ? rcu_read_lock_bh_held+0xb0/0xb0
[   46.622736][    T7]  ? brcmf_cfg80211_join_ibss+0x7b0/0x7b0
[   46.623390][    T7]  ? find_held_lock+0x2d/0x110
[   46.623962][    T7]  ? brcmf_fweh_event_worker+0x19f/0xc60
[   46.624603][    T7]  ? mark_held_locks+0x9f/0xe0
[   46.625145][    T7]  ? lockdep_hardirqs_on_prepare+0x3e0/0x3e0
[   46.625871][    T7]  ? brcmf_cfg80211_join_ibss+0x7b0/0x7b0
[   46.626545][    T7]  brcmf_fweh_call_event_handler.isra.0+0x90/0x100
[   46.627338][    T7]  brcmf_fweh_event_worker+0x557/0xc60
[   46.627962][    T7]  ? brcmf_fweh_call_event_handler.isra.0+0x100/0x100
[   46.628736][    T7]  ? rcu_read_lock_sched_held+0xa1/0xd0
[   46.629396][    T7]  ? rcu_read_lock_bh_held+0xb0/0xb0
[   46.629970][    T7]  ? lockdep_hardirqs_on_prepare+0x273/0x3e0
[   46.630649][    T7]  process_one_work+0x92b/0x1460
[   46.631205][    T7]  ? pwq_dec_nr_in_flight+0x330/0x330
[   46.631821][    T7]  ? rwlock_bug.part.0+0x90/0x90
[   46.632347][    T7]  worker_thread+0x95/0xe00
[   46.632832][    T7]  ? __kthread_parkme+0x115/0x1e0
[   46.633393][    T7]  ? process_one_work+0x1460/0x1460
[   46.633957][    T7]  kthread+0x3a1/0x480
[   46.634369][    T7]  ? set_kthread_struct+0x120/0x120
[   46.634933][    T7]  ret_from_fork+0x1f/0x30
[   46.635431][    T7]
[   46.635687][    T7] Allocated by task 7:
[   46.636151][    T7]  kasan_save_stack+0x1b/0x40
[   46.636628][    T7]  __kasan_kmalloc+0x7c/0x90
[   46.637108][    T7]  kmem_cache_alloc_trace+0x19e/0x330
[   46.637696][    T7]  brcmf_cfg80211_attach+0x4a0/0x4040
[   46.638275][    T7]  brcmf_attach+0x389/0xd40
[   46.638739][    T7]  brcmf_usb_probe+0x12de/0x1690
[   46.639279][    T7]  usb_probe_interface+0x2aa/0x760
[   46.639820][    T7]  really_probe+0x205/0xb70
[   46.640342][    T7]  __driver_probe_device+0x311/0x4b0
[   46.640876][    T7]  driver_probe_device+0x4e/0x150
[   46.641445][    T7]  __device_attach_driver+0x1cc/0x2a0
[   46.642000][    T7]  bus_for_each_drv+0x156/0x1d0
[   46.642543][    T7]  __device_attach+0x23f/0x3a0
[   46.643065][    T7]  bus_probe_device+0x1da/0x290
[   46.643644][    T7]  device_add+0xb7b/0x1eb0
[   46.644130][    T7]  usb_set_configuration+0xf59/0x16f0
[   46.644720][    T7]  usb_generic_driver_probe+0x82/0xa0
[   46.645295][    T7]  usb_probe_device+0xbb/0x250
[   46.645786][    T7]  really_probe+0x205/0xb70
[   46.646258][    T7]  __driver_probe_device+0x311/0x4b0
[   46.646804][    T7]  driver_probe_device+0x4e/0x150
[   46.647387][    T7]  __device_attach_driver+0x1cc/0x2a0
[   46.647926][    T7]  bus_for_each_drv+0x156/0x1d0
[   46.648454][    T7]  __device_attach+0x23f/0x3a0
[   46.648939][    T7]  bus_probe_device+0x1da/0x290
[   46.649478][    T7]  device_add+0xb7b/0x1eb0
[   46.649936][    T7]  usb_new_device.cold+0x49c/0x1029
[   46.650526][    T7]  hub_event+0x1c98/0x3950
[   46.650975][    T7]  process_one_work+0x92b/0x1460
[   46.651535][    T7]  worker_thread+0x95/0xe00
[   46.651991][    T7]  kthread+0x3a1/0x480
[   46.652413][    T7]  ret_from_fork+0x1f/0x30
[   46.652885][    T7]
[   46.653131][    T7] The buggy address belongs to the object at ffff888019442000
[   46.653131][    T7]  which belongs to the cache kmalloc-2k of size 2048
[   46.654669][    T7] The buggy address is located 0 bytes inside of
[   46.654669][    T7]  2048-byte region [ffff888019442000, ffff888019442800)
[   46.656137][    T7] The buggy address belongs to the page:
[   46.656720][    T7] page:ffffea0000651000 refcount:1 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x19440
[   46.657792][    T7] head:ffffea0000651000 order:3 compound_mapcount:0 compound_pincount:0
[   46.658673][    T7] flags: 0x100000000010200(slab|head|node=0|zone=1)
[   46.659422][    T7] raw: 0100000000010200 0000000000000000 dead000000000122 ffff888100042000
[   46.660363][    T7] raw: 0000000000000000 0000000000080008 00000001ffffffff 0000000000000000
[   46.661236][    T7] page dumped because: kasan: bad access detected
[   46.661956][    T7] page_owner tracks the page as allocated
[   46.662588][    T7] page last allocated via order 3, migratetype Unmovable, gfp_mask 0x52a20(GFP_ATOMIC|__GFP_NOWARN|__GFP_NORETRY|__GFP_COMP), pid 7, ts 31136961085, free_ts 0
[   46.664271][    T7]  prep_new_page+0x1aa/0x240
[   46.664763][    T7]  get_page_from_freelist+0x159a/0x27c0
[   46.665340][    T7]  __alloc_pages+0x2da/0x6a0
[   46.665847][    T7]  alloc_pages+0xec/0x1e0
[   46.666308][    T7]  allocate_slab+0x380/0x4e0
[   46.666770][    T7]  ___slab_alloc+0x5bc/0x940
[   46.667264][    T7]  __slab_alloc+0x6d/0x80
[   46.667712][    T7]  kmem_cache_alloc_trace+0x30a/0x330
[   46.668299][    T7]  brcmf_usbdev_qinit.constprop.0+0x50/0x470
[   46.668885][    T7]  brcmf_usb_probe+0xc97/0x1690
[   46.669438][    T7]  usb_probe_interface+0x2aa/0x760
[   46.669988][    T7]  really_probe+0x205/0xb70
[   46.670487][    T7]  __driver_probe_device+0x311/0x4b0
[   46.671031][    T7]  driver_probe_device+0x4e/0x150
[   46.671604][    T7]  __device_attach_driver+0x1cc/0x2a0
[   46.672192][    T7]  bus_for_each_drv+0x156/0x1d0
[   46.672739][    T7] page_owner free stack trace missing
[   46.673335][    T7]
[   46.673620][    T7] Memory state around the buggy address:
[   46.674213][    T7]  ffff888019442700: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
[   46.675083][    T7]  ffff888019442780: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
[   46.675994][    T7] >ffff888019442800: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
[   46.676875][    T7]                    ^
[   46.677323][    T7]  ffff888019442880: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
[   46.678190][    T7]  ffff888019442900: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
[   46.679052][    T7] ==================================================================
[   46.679945][    T7] Disabling lock debugging due to kernel taint
[   46.680725][    T7] Kernel panic - not syncing:

Reviewed-by: Arend van Spriel <arend.vanspriel@broadcom.com>
Signed-off-by: Jisoo Jang <jisoo.jang@yonsei.ac.kr>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/20230309104457.22628-1-jisoo.jang@yonsei.ac.kr
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
 drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c |    5 +++++
 1 file changed, 5 insertions(+)

--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c
@@ -6164,6 +6164,11 @@ static s32 brcmf_get_assoc_ies(struct br
 		(struct brcmf_cfg80211_assoc_ielen_le *)cfg->extra_buf;
 	req_len = le32_to_cpu(assoc_info->req_len);
 	resp_len = le32_to_cpu(assoc_info->resp_len);
+	if (req_len > WL_EXTRA_BUF_MAX || resp_len > WL_EXTRA_BUF_MAX) {
+		bphy_err(drvr, "invalid lengths in assoc info: req %u resp %u\n",
+			 req_len, resp_len);
+		return -EINVAL;
+	}
 	if (req_len) {
 		err = brcmf_fil_iovar_data_get(ifp, "assoc_req_ies",
 					       cfg->extra_buf,

[PATCH 6.3 02/11] fsverity: reject FS_IOC_ENABLE_VERITY on mode 3 fds

[Greg Kroah-Hartman]

From: Eric Biggers <ebiggers@google.com>

commit 04839139213cf60d4c5fc792214a08830e294ff8 upstream.

Commit 56124d6c87fd ("fsverity: support enabling with tree block size <
PAGE_SIZE") changed FS_IOC_ENABLE_VERITY to use __kernel_read() to read
the file's data, instead of direct pagecache accesses.

An unintended consequence of this is that the
'WARN_ON_ONCE(!(file->f_mode & FMODE_READ))' in __kernel_read() became
reachable by fuzz tests.  This happens if FS_IOC_ENABLE_VERITY is called
on a fd opened with access mode 3, which means "ioctl access only".

Arguably, FS_IOC_ENABLE_VERITY should work on ioctl-only fds.  But
ioctl-only fds are a weird Linux extension that is rarely used and that
few people even know about.  (The documentation for FS_IOC_ENABLE_VERITY
even specifically says it requires O_RDONLY.)  It's probably not
worthwhile to make the ioctl internally open a new fd just to handle
this case.  Thus, just reject the ioctl on such fds for now.

Fixes: 56124d6c87fd ("fsverity: support enabling with tree block size < PAGE_SIZE")
Reported-by: syzbot+51177e4144d764827c45@syzkaller.appspotmail.com
Link: https://syzkaller.appspot.com/bug?id=2281afcbbfa8fdb92f9887479cc0e4180f1c6b28
Cc: stable@vger.kernel.org
Link: https://lore.kernel.org/r/20230406215106.235829-1-ebiggers@kernel.org
Reviewed-by: Christoph Hellwig <hch@lst.de>
Reviewed-by: Christian Brauner <brauner@kernel.org>
Signed-off-by: Eric Biggers <ebiggers@google.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
 fs/verity/enable.c |    7 +++++++
 1 file changed, 7 insertions(+)

--- a/fs/verity/enable.c
+++ b/fs/verity/enable.c
@@ -347,6 +347,13 @@ int fsverity_ioctl_enable(struct file *f
 	err = file_permission(filp, MAY_WRITE);
 	if (err)
 		return err;
+	/*
+	 * __kernel_read() is used while building the Merkle tree.  So, we can't
+	 * allow file descriptors that were opened for ioctl access only, using
+	 * the special nonstandard access mode 3.  O_RDONLY only, please!
+	 */
+	if (!(filp->f_mode & FMODE_READ))
+		return -EBADF;
 
 	if (IS_APPEND(inode))
 		return -EPERM;

[PATCH 6.3 03/11] drm/fb-helper: set x/yres_virtual in drm_fb_helper_check_var

[Greg Kroah-Hartman]

From: Daniel Vetter <daniel.vetter@ffwll.ch>

commit 1935f0deb6116dd785ea64d8035eab0ff441255b upstream.

Drivers are supposed to fix this up if needed if they don't outright
reject it. Uncovered by 6c11df58fd1a ("fbmem: Check virtual screen
sizes in fb_set_var()").

Reported-by: syzbot+20dcf81733d43ddff661@syzkaller.appspotmail.com
Link: https://syzkaller.appspot.com/bug?id=c5faf983bfa4a607de530cd3bb008888bf06cefc
Cc: stable@vger.kernel.org # v5.4+
Cc: Daniel Vetter <daniel@ffwll.ch>
Cc: Javier Martinez Canillas <javierm@redhat.com>
Cc: Thomas Zimmermann <tzimmermann@suse.de>
Reviewed-by: Javier Martinez Canillas <javierm@redhat.com>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230404194038.472803-1-daniel.vetter@ffwll.ch
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
 drivers/gpu/drm/drm_fb_helper.c |    3 +++
 1 file changed, 3 insertions(+)

--- a/drivers/gpu/drm/drm_fb_helper.c
+++ b/drivers/gpu/drm/drm_fb_helper.c
@@ -1569,6 +1569,9 @@ int drm_fb_helper_check_var(struct fb_va
 		return -EINVAL;
 	}
 
+	var->xres_virtual = fb->width;
+	var->yres_virtual = fb->height;
+
 	/*
 	 * Workaround for SDL 1.2, which is known to be setting all pixel format
 	 * fields values to zero in some cases. We treat this situation as a

[PATCH 6.3 04/11] fsverity: explicitly check for buffer overflow in build_merkle_tree()

[Greg Kroah-Hartman]

From: Eric Biggers <ebiggers@google.com>

commit 39049b69ec9fc125fa1f314165dcc86f72cb72ec upstream.

The new Merkle tree construction algorithm is a bit fragile in that it
may overflow the 'root_hash' array if the tree actually generated does
not match the calculated tree parameters.

This should never happen unless there is a filesystem bug that allows
the file size to change despite deny_write_access(), or a bug in the
Merkle tree logic itself.  Regardless, it's fairly easy to check for
buffer overflow here, so let's do so.

This is a robustness improvement only; this case is not currently known
to be reachable.  I've added a Fixes tag anyway, since I recommend that
this be included in kernels that have the mentioned commit.

Fixes: 56124d6c87fd ("fsverity: support enabling with tree block size < PAGE_SIZE")
Cc: stable@vger.kernel.org
Link: https://lore.kernel.org/r/20230328041505.110162-1-ebiggers@kernel.org
Signed-off-by: Eric Biggers <ebiggers@google.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
 fs/verity/enable.c |   10 ++++++++++
 1 file changed, 10 insertions(+)

--- a/fs/verity/enable.c
+++ b/fs/verity/enable.c
@@ -13,6 +13,7 @@
 
 struct block_buffer {
 	u32 filled;
+	bool is_root_hash;
 	u8 *data;
 };
 
@@ -24,6 +25,14 @@ static int hash_one_block(struct inode *
 	struct block_buffer *next = cur + 1;
 	int err;
 
+	/*
+	 * Safety check to prevent a buffer overflow in case of a filesystem bug
+	 * that allows the file size to change despite deny_write_access(), or a
+	 * bug in the Merkle tree logic itself
+	 */
+	if (WARN_ON_ONCE(next->is_root_hash && next->filled != 0))
+		return -EINVAL;
+
 	/* Zero-pad the block if it's shorter than the block size. */
 	memset(&cur->data[cur->filled], 0, params->block_size - cur->filled);
 
@@ -97,6 +106,7 @@ static int build_merkle_tree(struct file
 		}
 	}
 	buffers[num_levels].data = root_hash;
+	buffers[num_levels].is_root_hash = true;
 
 	BUILD_BUG_ON(sizeof(level_offset) != sizeof(params->level_start));
 	memcpy(level_offset, params->level_start, sizeof(level_offset));

[PATCH 6.3 05/11] gpiolib: acpi: Add a ignore wakeup quirk for Clevo NL5xNU

[Greg Kroah-Hartman]

From: Werner Sembach <wse@tuxedocomputers.com>

commit 782eea0c89f7d071d6b56ecfa1b8b0c81164b9be upstream.

commit 1796f808e4bb ("HID: i2c-hid: acpi: Stop setting wakeup_capable")
changed the policy such that I2C touchpads may be able to wake up the
system by default if the system is configured as such.

However on Clevo NL5xNU there is a mistake in the ACPI tables that the
TP_ATTN# signal connected to GPIO 9 is configured as ActiveLow and level
triggered but connected to a pull up. As soon as the system suspends the
touchpad loses power and then the system wakes up.

To avoid this problem, introduce a quirk for this model that will prevent
the wakeup capability for being set for GPIO 9.

This patch is analoge to a very similar patch for NL5xRU, just the DMI
string changed.

Signed-off-by: Werner Sembach <wse@tuxedocomputers.com>
Cc: stable@vger.kernel.org
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
 drivers/gpio/gpiolib-acpi.c |   13 +++++++++++++
 1 file changed, 13 insertions(+)

--- a/drivers/gpio/gpiolib-acpi.c
+++ b/drivers/gpio/gpiolib-acpi.c
@@ -1624,6 +1624,19 @@ static const struct dmi_system_id gpioli
 		 * https://gitlab.freedesktop.org/drm/amd/-/issues/1722#note_1720627
 		 */
 		.matches = {
+			DMI_MATCH(DMI_BOARD_NAME, "NL5xNU"),
+		},
+		.driver_data = &(struct acpi_gpiolib_dmi_quirk) {
+			.ignore_wake = "ELAN0415:00@9",
+		},
+	},
+	{
+		/*
+		 * Spurious wakeups from TP_ATTN# pin
+		 * Found in BIOS 1.7.8
+		 * https://gitlab.freedesktop.org/drm/amd/-/issues/1722#note_1720627
+		 */
+		.matches = {
 			DMI_MATCH(DMI_BOARD_NAME, "NL5xRU"),
 		},
 		.driver_data = &(struct acpi_gpiolib_dmi_quirk) {

[PATCH 6.3 06/11] bluetooth: Perform careful capability checks in hci_sock_ioctl()

[Greg Kroah-Hartman]

From: Ruihan Li <lrh2000@pku.edu.cn>

commit 25c150ac103a4ebeed0319994c742a90634ddf18 upstream.

Previously, capability was checked using capable(), which verified that the
caller of the ioctl system call had the required capability. In addition,
the result of the check would be stored in the HCI_SOCK_TRUSTED flag,
making it persistent for the socket.

However, malicious programs can abuse this approach by deliberately sharing
an HCI socket with a privileged task. The HCI socket will be marked as
trusted when the privileged task occasionally makes an ioctl call.

This problem can be solved by using sk_capable() to check capability, which
ensures that not only the current task but also the socket opener has the
specified capability, thus reducing the risk of privilege escalation
through the previously identified vulnerability.

Cc: stable@vger.kernel.org
Fixes: f81f5b2db869 ("Bluetooth: Send control open and close messages for HCI raw sockets")
Signed-off-by: Ruihan Li <lrh2000@pku.edu.cn>
Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
 net/bluetooth/hci_sock.c |    9 ++++++++-
 1 file changed, 8 insertions(+), 1 deletion(-)

--- a/net/bluetooth/hci_sock.c
+++ b/net/bluetooth/hci_sock.c
@@ -1003,7 +1003,14 @@ static int hci_sock_ioctl(struct socket
 	if (hci_sock_gen_cookie(sk)) {
 		struct sk_buff *skb;
 
-		if (capable(CAP_NET_ADMIN))
+		/* Perform careful checks before setting the HCI_SOCK_TRUSTED
+		 * flag. Make sure that not only the current task but also
+		 * the socket opener has the required capability, since
+		 * privileged programs can be tricked into making ioctl calls
+		 * on HCI sockets, and the socket should not be marked as
+		 * trusted simply because the ioctl caller is privileged.
+		 */
+		if (sk_capable(sk, CAP_NET_ADMIN))
 			hci_sock_set_flag(sk, HCI_SOCK_TRUSTED);
 
 		/* Send event to monitor */

[PATCH 6.3 07/11] wifi: brcmfmac: add Cypress 43439 SDIO ids

[Greg Kroah-Hartman]

From: Marek Vasut <marex@denx.de>

commit cc4cffc3c142d57df48c07851862444e1d33bdaa upstream.

Add SDIO ids for use with the muRata 1YN (Cypress CYW43439).
The odd thing about this is that the previous 1YN populated
on M.2 card for evaluation purposes had BRCM SDIO vendor ID,
while the chip populated on real hardware has a Cypress one.
The device ID also differs between the two devices. But they
are both 43439 otherwise, so add the IDs for both.

On-device 1YN (43439), the new one, chip label reads "1YN":
```
/sys/.../mmc_host/mmc2/mmc2:0001 # cat vendor device
0x04b4
0xbd3d
```

EA M.2 evaluation board 1YN (43439), the old one, chip label reads "1YN ES1.4":
```
/sys/.../mmc_host/mmc0/mmc0:0001/# cat vendor device
0x02d0
0xa9a6
```

Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Cc: stable@vger.kernel.org
Signed-off-by: Marek Vasut <marex@denx.de>
Reviewed-by: Simon Horman <simon.horman@corigine.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/20230407203752.128539-1-marex@denx.de
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
 drivers/net/wireless/broadcom/brcm80211/brcmfmac/bcmsdh.c |    9 ++++++++-
 include/linux/mmc/sdio_ids.h                              |    5 ++++-
 2 files changed, 12 insertions(+), 2 deletions(-)

--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/bcmsdh.c
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/bcmsdh.c
@@ -965,6 +965,12 @@ out:
 		.driver_data = BRCMF_FWVENDOR_ ## fw_vend \
 	}
 
+#define CYW_SDIO_DEVICE(dev_id, fw_vend) \
+	{ \
+		SDIO_DEVICE(SDIO_VENDOR_ID_CYPRESS, dev_id), \
+		.driver_data = BRCMF_FWVENDOR_ ## fw_vend \
+	}
+
 /* devices we support, null terminated */
 static const struct sdio_device_id brcmf_sdmmc_ids[] = {
 	BRCMF_SDIO_DEVICE(SDIO_DEVICE_ID_BROADCOM_43143, WCC),
@@ -979,6 +985,7 @@ static const struct sdio_device_id brcmf
 	BRCMF_SDIO_DEVICE(SDIO_DEVICE_ID_BROADCOM_4335_4339, WCC),
 	BRCMF_SDIO_DEVICE(SDIO_DEVICE_ID_BROADCOM_4339, WCC),
 	BRCMF_SDIO_DEVICE(SDIO_DEVICE_ID_BROADCOM_43430, WCC),
+	BRCMF_SDIO_DEVICE(SDIO_DEVICE_ID_BROADCOM_43439, WCC),
 	BRCMF_SDIO_DEVICE(SDIO_DEVICE_ID_BROADCOM_4345, WCC),
 	BRCMF_SDIO_DEVICE(SDIO_DEVICE_ID_BROADCOM_43455, WCC),
 	BRCMF_SDIO_DEVICE(SDIO_DEVICE_ID_BROADCOM_4354, WCC),
@@ -986,9 +993,9 @@ static const struct sdio_device_id brcmf
 	BRCMF_SDIO_DEVICE(SDIO_DEVICE_ID_BROADCOM_4359, WCC),
 	BRCMF_SDIO_DEVICE(SDIO_DEVICE_ID_BROADCOM_CYPRESS_4373, CYW),
 	BRCMF_SDIO_DEVICE(SDIO_DEVICE_ID_BROADCOM_CYPRESS_43012, CYW),
-	BRCMF_SDIO_DEVICE(SDIO_DEVICE_ID_BROADCOM_CYPRESS_43439, CYW),
 	BRCMF_SDIO_DEVICE(SDIO_DEVICE_ID_BROADCOM_CYPRESS_43752, CYW),
 	BRCMF_SDIO_DEVICE(SDIO_DEVICE_ID_BROADCOM_CYPRESS_89359, CYW),
+	CYW_SDIO_DEVICE(SDIO_DEVICE_ID_BROADCOM_CYPRESS_43439, CYW),
 	{ /* end: all zeroes */ }
 };
 MODULE_DEVICE_TABLE(sdio, brcmf_sdmmc_ids);
--- a/include/linux/mmc/sdio_ids.h
+++ b/include/linux/mmc/sdio_ids.h
@@ -74,10 +74,13 @@
 #define SDIO_DEVICE_ID_BROADCOM_43362		0xa962
 #define SDIO_DEVICE_ID_BROADCOM_43364		0xa9a4
 #define SDIO_DEVICE_ID_BROADCOM_43430		0xa9a6
-#define SDIO_DEVICE_ID_BROADCOM_CYPRESS_43439	0xa9af
+#define SDIO_DEVICE_ID_BROADCOM_43439		0xa9af
 #define SDIO_DEVICE_ID_BROADCOM_43455		0xa9bf
 #define SDIO_DEVICE_ID_BROADCOM_CYPRESS_43752	0xaae8
 
+#define SDIO_VENDOR_ID_CYPRESS			0x04b4
+#define SDIO_DEVICE_ID_BROADCOM_CYPRESS_43439	0xbd3d
+
 #define SDIO_VENDOR_ID_MARVELL			0x02df
 #define SDIO_DEVICE_ID_MARVELL_LIBERTAS		0x9103
 #define SDIO_DEVICE_ID_MARVELL_8688_WLAN	0x9104

[PATCH 6.3 08/11] btrfs: fix uninitialized variable warnings

[Greg Kroah-Hartman]

From: Genjian Zhang <zhanggenjian@kylinos.cn>

commit 8ba7d5f5ba931be68a94b8c91bcced1622934e7a upstream.

There are some warnings on older compilers (gcc 10, 7) or non-x86_64
architectures (aarch64).  As btrfs wants to enable -Wmaybe-uninitialized
by default, fix the warnings even though it's not necessary on recent
compilers (gcc 12+).

../fs/btrfs/volumes.c: In function ‘btrfs_init_new_device’:
../fs/btrfs/volumes.c:2703:3: error: ‘seed_devices’ may be used uninitialized in this function [-Werror=maybe-uninitialized]
 2703 |   btrfs_setup_sprout(fs_info, seed_devices);
      |   ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

../fs/btrfs/send.c: In function ‘get_cur_inode_state’:
../include/linux/compiler.h:70:32: error: ‘right_gen’ may be used uninitialized in this function [-Werror=maybe-uninitialized]
   70 |   (__if_trace.miss_hit[1]++,1) :  \
      |                                ^
../fs/btrfs/send.c:1878:6: note: ‘right_gen’ was declared here
 1878 |  u64 right_gen;
      |      ^~~~~~~~~

Reported-by: k2ci <kernel-bot@kylinos.cn>
Signed-off-by: Genjian Zhang <zhanggenjian@kylinos.cn>
Reviewed-by: David Sterba <dsterba@suse.com>
[ update changelog ]
Signed-off-by: David Sterba <dsterba@suse.com>
Cc: Ammar Faizi <ammarfaizi2@gnuweeb.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
 fs/btrfs/send.c    |    2 +-
 fs/btrfs/volumes.c |    2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

--- a/fs/btrfs/send.c
+++ b/fs/btrfs/send.c
@@ -1875,7 +1875,7 @@ static int get_cur_inode_state(struct se
 	int left_ret;
 	int right_ret;
 	u64 left_gen;
-	u64 right_gen;
+	u64 right_gen = 0;
 	struct btrfs_inode_info info;
 
 	ret = get_inode_info(sctx->send_root, ino, &info);
--- a/fs/btrfs/volumes.c
+++ b/fs/btrfs/volumes.c
@@ -2618,7 +2618,7 @@ int btrfs_init_new_device(struct btrfs_f
 	struct block_device *bdev;
 	struct super_block *sb = fs_info->sb;
 	struct btrfs_fs_devices *fs_devices = fs_info->fs_devices;
-	struct btrfs_fs_devices *seed_devices;
+	struct btrfs_fs_devices *seed_devices = NULL;
 	u64 orig_super_total_bytes;
 	u64 orig_super_num_devices;
 	int ret = 0;

[PATCH 6.3 09/11] mm/mremap: fix vm_pgoff in vma_merge() case 3

[Greg Kroah-Hartman]

From: Vlastimil Babka <vbabka@suse.cz>

commit 7e7757876f258d99266e7b3c559639289a2a45fe upstream.

After upgrading build guests to v6.3, rpm started segfaulting for
specific packages, which was bisected to commit 0503ea8f5ba7 ("mm/mmap:
remove __vma_adjust()"). rpm is doing many mremap() operations with file
mappings of its db. The problem is that in vma_merge() case 3 (we merge
with the next vma, expanding it downwards) vm_pgoff is not adjusted as
it should when vm_start changes. As a result the rpm process most likely
sees data from the wrong offset of the file. Fix the vm_pgoff
calculation.

For case 8 this is a non-functional change as the resulting vm_pgoff is
the same.

Reported-and-bisected-by: Jiri Slaby <jirislaby@kernel.org>
Reported-and-tested-by: Fabian Vogt <fvogt@suse.com>
Link: https://bugzilla.suse.com/show_bug.cgi?id=1210903
Fixes: 0503ea8f5ba7 ("mm/mmap: remove __vma_adjust()")
Signed-off-by: Vlastimil Babka <vbabka@suse.cz>
Cc: <stable@vger.kernel.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
 mm/mmap.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- a/mm/mmap.c
+++ b/mm/mmap.c
@@ -978,7 +978,7 @@ struct vm_area_struct *vma_merge(struct
 			vma = next;			/* case 3 */
 			vma_start = addr;
 			vma_end = next->vm_end;
-			vma_pgoff = mid->vm_pgoff;
+			vma_pgoff = next->vm_pgoff - pglen;
 			err = 0;
 			if (mid != next) {		/* case 8 */
 				remove = mid;

[PATCH 6.3 10/11] USB: serial: option: add UNISOC vendor and TOZED LT70C product

[Greg Kroah-Hartman]

From: Arınç ÜNAL <arinc.unal@arinc9.com>

commit a095edfc15f0832e046ae23964e249ef5c95af87 upstream.

Add UNISOC vendor ID and TOZED LT70-C modem which is based from UNISOC
SL8563. The modem supports the NCM mode. Interface 0 is used for running
the AT commands. Interface 12 is the ADB interface.

T:  Bus=01 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#=  6 Spd=480  MxCh= 0
D:  Ver= 2.00 Cls=00(>ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs=  1
P:  Vendor=1782 ProdID=4055 Rev=04.04
S:  Manufacturer=Unisoc Phone
S:  Product=Unisoc Phone
S:  SerialNumber=<redacted>
C:  #Ifs=14 Cfg#= 1 Atr=c0 MxPwr=500mA
I:  If#= 0 Alt= 0 #EPs= 1 Cls=02(commc) Sub=0d Prot=00 Driver=cdc_ncm
E:  Ad=82(I) Atr=03(Int.) MxPS=  16 Ivl=32ms
I:  If#= 1 Alt= 1 #EPs= 2 Cls=0a(data ) Sub=00 Prot=01 Driver=cdc_ncm
E:  Ad=01(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
E:  Ad=81(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
I:  If#=10 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=00 Prot=00 Driver=option
E:  Ad=07(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
E:  Ad=8b(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
I:  If#=11 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=00 Prot=00 Driver=option
E:  Ad=08(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
E:  Ad=8c(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
I:  If#=12 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=42 Prot=01 Driver=(none)
E:  Ad=09(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
E:  Ad=8d(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
I:  If#=13 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=00 Prot=00 Driver=option
E:  Ad=0a(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
E:  Ad=8e(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
I:  If#= 2 Alt= 0 #EPs= 1 Cls=02(commc) Sub=0d Prot=00 Driver=cdc_ncm
E:  Ad=84(I) Atr=03(Int.) MxPS=  16 Ivl=32ms
I:  If#= 3 Alt= 1 #EPs= 2 Cls=0a(data ) Sub=00 Prot=01 Driver=cdc_ncm
E:  Ad=02(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
E:  Ad=83(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
I:  If#= 4 Alt= 0 #EPs= 1 Cls=02(commc) Sub=0d Prot=00 Driver=cdc_ncm
E:  Ad=86(I) Atr=03(Int.) MxPS=  16 Ivl=32ms
I:  If#= 5 Alt= 1 #EPs= 2 Cls=0a(data ) Sub=00 Prot=01 Driver=cdc_ncm
E:  Ad=03(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
E:  Ad=85(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
I:  If#= 6 Alt= 0 #EPs= 1 Cls=02(commc) Sub=0d Prot=00 Driver=cdc_ncm
E:  Ad=88(I) Atr=03(Int.) MxPS=  16 Ivl=32ms
I:  If#= 7 Alt= 1 #EPs= 2 Cls=0a(data ) Sub=00 Prot=01 Driver=cdc_ncm
E:  Ad=04(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
E:  Ad=87(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
I:  If#= 8 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=00 Prot=00 Driver=option
E:  Ad=05(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
E:  Ad=89(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
I:  If#= 9 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=00 Prot=00 Driver=option
E:  Ad=06(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
E:  Ad=8a(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms

Signed-off-by: Arınç ÜNAL <arinc.unal@arinc9.com>
Link: https://lore.kernel.org/r/20230417152003.243248-1-arinc.unal@arinc9.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
@@ -595,6 +595,11 @@ static void option_instat_callback(struc
 #define SIERRA_VENDOR_ID			0x1199
 #define SIERRA_PRODUCT_EM9191			0x90d3
 
+/* UNISOC (Spreadtrum) products */
+#define UNISOC_VENDOR_ID			0x1782
+/* TOZED LT70-C based on UNISOC SL8563 uses UNISOC's vendor ID */
+#define TOZED_PRODUCT_LT70C			0x4055
+
 /* Device flags */
 
 /* Highest interface number which can be used with NCTRL() and RSVD() */
@@ -2225,6 +2230,7 @@ static const struct usb_device_id option
 	{ USB_DEVICE_AND_INTERFACE_INFO(OPPO_VENDOR_ID, OPPO_PRODUCT_R11, 0xff, 0xff, 0x30) },
 	{ USB_DEVICE_AND_INTERFACE_INFO(SIERRA_VENDOR_ID, SIERRA_PRODUCT_EM9191, 0xff, 0xff, 0x30) },
 	{ USB_DEVICE_AND_INTERFACE_INFO(SIERRA_VENDOR_ID, SIERRA_PRODUCT_EM9191, 0xff, 0, 0) },
+	{ USB_DEVICE_AND_INTERFACE_INFO(UNISOC_VENDOR_ID, TOZED_PRODUCT_LT70C, 0xff, 0, 0) },
 	{ } /* Terminating entry */
 };
 MODULE_DEVICE_TABLE(usb, option_ids);

[PATCH 6.3 11/11] driver core: Dont require dynamic_debug for initcall_debug probe timing

[Greg Kroah-Hartman]

From: Stephen Boyd <swboyd@chromium.org>

commit e2f06aa885081e1391916367f53bad984714b4db upstream.

Don't require the use of dynamic debug (or modification of the kernel to
add a #define DEBUG to the top of this file) to get the printk message
about driver probe timing. This printk is only emitted when
initcall_debug is enabled on the kernel commandline, and it isn't
immediately obvious that you have to do something else to debug boot
timing issues related to driver probe. Add a comment too so it doesn't
get converted back to pr_debug().

Fixes: eb7fbc9fb118 ("driver core: Add missing '\n' in log messages")
Cc: stable <stable@kernel.org>
Cc: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
Cc: Brian Norris <briannorris@chromium.org>
Reviewed-by: Brian Norris <briannorris@chromium.org>
Acked-by: Randy Dunlap <rdunlap@infradead.org>
Signed-off-by: Stephen Boyd <swboyd@chromium.org>
Link: https://lore.kernel.org/r/20230412225842.3196599-1-swboyd@chromium.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
 drivers/base/dd.c |    7 ++++++-
 1 file changed, 6 insertions(+), 1 deletion(-)

--- a/drivers/base/dd.c
+++ b/drivers/base/dd.c
@@ -708,7 +708,12 @@ static int really_probe_debug(struct dev
 	calltime = ktime_get();
 	ret = really_probe(dev, drv);
 	rettime = ktime_get();
-	pr_debug("probe of %s returned %d after %lld usecs\n",
+	/*
+	 * Don't change this to pr_debug() because that requires
+	 * CONFIG_DYNAMIC_DEBUG and we want a simple 'initcall_debug' on the
+	 * kernel commandline to print this all the time at the debug level.
+	 */
+	printk(KERN_DEBUG "probe of %s returned %d after %lld usecs\n",
 		 dev_name(dev), ret, ktime_us_delta(rettime, calltime));
 	return ret;
 }

Re: [PATCH 6.3 00/11] 6.3.1-rc1 review

[Markus Reichelt]

* Greg Kroah-Hartman <gregkh@linuxfoundation.org> wrote:

> This is the start of the stable review cycle for the 6.3.1 release.
> There are 11 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, 30 Apr 2023 11:20:30 +0000.
> Anything received after that time might be too late.

Hi Greg

6.3.1-rc1

compiles, boots and runs here on x86_64
(AMD Ryzen 5 PRO 4650G, Slackware64-15.0)

Tested-by: Markus Reichelt <lkt+2023@mareichelt.com>

Re: [PATCH 6.3 00/11] 6.3.1-rc1 review

[Shuah Khan]

On 4/28/23 05:27, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 6.3.1 release.
> There are 11 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, 30 Apr 2023 11:20:30 +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/v6.x/stable-review/patch-6.3.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-6.3.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

Re: [PATCH 6.3 00/11] 6.3.1-rc1 review

[Naresh Kamboju]

On Fri, 28 Apr 2023 at 12:27, Greg Kroah-Hartman
<gregkh@linuxfoundation.org> wrote:
>
> This is the start of the stable review cycle for the 6.3.1 release.
> There are 11 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, 30 Apr 2023 11:20:30 +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/v6.x/stable-review/patch-6.3.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-6.3.y
> and the diffstat can be found below.
>
> thanks,
>
> greg k-h

Results from Linaro’s test farm.
Regressions while running LTP controllers testing with 6.3 kernel on i386
and ftrace testing from x86.

Reported-by: Linux Kernel Functional Testing <lkft@linaro.org>

This is not always reproducible.

x86 crash log:
--------------
# selftests: ftrace: ftracetest
# === Ftrace unit tests ===
# [1] Basic trace file check [PASS]
# [2] Basic test for tracers [PASS]
# [3] Basic trace clock test [PASS]
# [4] Basic event tracing check [PASS]
# [5] Change the ringbuffer size<47>[  106.586512]
systemd-journald[95]: Sent WATCHDOG=1 notification.
[PASS]
# [6] Snapshot and tracing setting [PASS]
# [7] trace_pipe and trace_marker [PASS]
# [8] Test ftrace direct functions against tracers<4>[  113.917567]
...
<47>[  190.132853] systemd-journald[95]: Sent WATCHDOG=1 notification.
<4>[  213.968606] int3: 0000 [#1] PREEMPT SMP PTI
<4>[  213.969006] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 6.3.1-rc1 #1
<4>[  213.969088] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009),
BIOS 1.14.0-2 04/01/2014
<4>[  213.969282] RIP: 0010:update_rq_clock+0x5/0x20
<4>[  213.969783] Code: 0d 48 83 c4 40 c3 cc cc cc cc 0f 0b eb e3 e8
52 94 e0 00 66 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 66
0f 1f 00 0f <1f> 44 00 00 f6 87 88 09 00 00 02 74 05 c3 cc cc cc cc e9
d4 c3 ff
<4>[  213.969877] RSP: 0018:ffffb529c0003ea0 EFLAGS: 00000082
<4>[  213.970040] RAX: 00000000fffeaed4 RBX: 0000000000000001 RCX:
ffffa2383bc2b340
<4>[  213.970075] RDX: 0000000000000001 RSI: 0000000000000000 RDI:
ffffa2383bc2b340
<4>[  213.970104] RBP: 00000000ffff9934 R08: 0000000000000003 R09:
0000000000000000
<4>[  213.970134] R10: ffffffff8d4060c0 R11: ffffb529c0003ff8 R12:
0000000000000000
<4>[  213.970188] R13: ffffa2383bc2b340 R14: ffffa2383bc2b340 R15:
0000000000000000
<4>[  213.970263] FS:  0000000000000000(0000)
GS:ffffa2383bc00000(0000) knlGS:0000000000000000
<4>[  213.970302] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
<4>[  213.970333] CR2: 00007f16b5507ae4 CR3: 0000000100252000 CR4:
00000000000006f0
<4>[  213.970465] Call Trace:
<4>[  213.970716]  <IRQ>
<4>[  213.970841]  update_blocked_averages+0x58/0x5e0
<4>[  213.971160]  _nohz_idle_balance.isra.0+0x2db/0x330
<4>[  213.971341]  __do_softirq+0x10a/0x38c
<4>[  213.971457]  __irq_exit_rcu+0x86/0xb0
<4>[  213.971503]  irq_exit_rcu+0xe/0x20
<4>[  213.971543]  sysvec_call_function_single+0x6a/0x80
<4>[  213.971622]  </IRQ>
<4>[  213.971654]  <TASK>
<4>[  213.971688]  asm_sysvec_call_function_single+0x1a/0x20
<4>[  213.971796] RIP: 0010:default_idle+0xf/0x20
<4>[  213.971843] Code: 4c 01 c7 4c 29 c2 e9 72 ff ff ff 90 90 90 90
90 90 90 90 90 90 90 90 90 90 90 90 f3 0f 1e fa eb 07 0f 00 2d 53 f8
32 00 fb f4 <fa> c3 cc cc cc cc 66 66 2e 0f 1f 84 00 00 00 00 00 90 90
90 90 90
<4>[  213.971866] RSP: 0018:ffffffff8d403ea0 EFLAGS: 00000202
<4>[  213.971907] RAX: ffffa2383bc280c0 RBX: ffffffff8d40c900 RCX:
4000000000000000
<4>[  213.971926] RDX: 0000000000000001 RSI: ffffffff8d0cc130 RDI:
0000000000099fe4
<4>[  213.971993] RBP: 0000000000000000 R08: 0000000000099fe4 R09:
00000031d27ffa40
<4>[  213.972016] R10: 0000000000000000 R11: 0000000000000002 R12:
0000000000000000
<4>[  213.972034] R13: 0000000000000000 R14: ffffffff8d40c030 R15:
0000000000000000
<4>[  213.972326]  default_idle_call+0x36/0xf0
<4>[  213.972373]  do_idle+0x1d8/0x220
<4>[  213.972466]  cpu_startup_entry+0x1d/0x20
<4>[  213.972519]  rest_init+0xc3/0xd0
<4>[  213.972564]  arch_call_rest_init+0xe/0x30
<4>[  213.972654]  start_kernel+0x46d/0x770
<4>[  213.972751]  secondary_startup_64_no_verify+0xe0/0xeb
<4>[  213.972939]  </TASK>
<4>[  213.973072] Modules linked in: fuse configfs [last unloaded:
ftrace_direct]
<4>[  214.012764] ---[ end trace 0000000000000000 ]---
<4>[  214.012773] int3: 0000 [#2] PREEMPT SMP PTI
<4>[  214.012858] RIP: 0010:update_rq_clock+0x5/0x20
<4>[  214.012887] CPU: 1 PID: 571 Comm: ftracetest Tainted: G      D
         6.3.1-rc1 #1
<4>[  214.012919] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009),
BIOS 1.14.0-2 04/01/2014
<4>[  214.012926] Code: 0d 48 83 c4 40 c3 cc cc cc cc 0f 0b eb e3 e8
52 94 e0 00 66 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 66
0f 1f 00 0f <1f> 44 00 00 f6 87 88 09 00 00 02 74 05 c3 cc cc cc cc e9
d4 c3 ff
<4>[  214.012951] RSP: 0018:ffffb529c0003ea0 EFLAGS: 00000082
<4>[  214.012940] RIP: 0010:update_rq_clock+0x5/0x20
<4>[  214.012985] Code: 0d 48 83 c4 40 c3 cc cc cc cc 0f 0b eb e3 e8
52 94 e0 00 66 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 66
0f 1f 00 0f <1f> 44 00 00 f6 87 88 09 00 00 02 74 05 c3 cc cc cc cc e9
d4 c3 ff
<4>[  214.013005] RSP: 0018:ffffb529c00c0ef0 EFLAGS: 00000002
<4>[  214.013047] RAX: 00000000fffeaee7 RBX: ffffa2383bd2b340 RCX:
ffffa2383bd2b340
<4>[  214.013008]
<4>[  214.013065] RDX: 0000000000000001 RSI: 0000000000000000 RDI:
ffffa2383bd2b340
<4>[  214.013076] RAX: 00000000fffeaed4 RBX: 0000000000000001 RCX:
ffffa2383bc2b340
<4>[  214.013084] RBP: 0000000000000000 R08: ffffa2383bd1f2c0 R09:
7fffffffffffffff
<4>[  214.013094] RDX: 0000000000000001 RSI: 0000000000000000 RDI:
ffffa2383bc2b340
<4>[  214.013104] R10: ffffffff8d4060c0 R11: 00000000000280ab R12:
0000000000000101
<4>[  214.013112] RBP: 00000000ffff9934 R08: 0000000000000003 R09:
0000000000000000
<4>[  214.013123] R13: ffffa2383bd2b340 R14: ffffffff8d4060f8 R15:
0000000000000007
<4>[  214.013130] R10: ffffffff8d4060c0 R11: ffffb529c0003ff8 R12:
0000000000000000
<4>[  214.013142] FS:  00007f589909c740(0000)
GS:ffffa2383bd00000(0000) knlGS:0000000000000000
<4>[  214.013149] R13: ffffa2383bc2b340 R14: ffffa2383bc2b340 R15:
0000000000000000
<4>[  214.013165] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
<4>[  214.013169] FS:  0000000000000000(0000)
GS:ffffa2383bc00000(0000) knlGS:0000000000000000
<4>[  214.013186] CR2: 00007f16b54e181c CR3: 00000001069e2000 CR4:
00000000000006e0
<4>[  214.013191] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
<4>[  214.013207] Call Trace:
<4>[  214.013210] CR2: 00007f16b5507ae4 CR3: 0000000100252000 CR4:
00000000000006f0
<4>[  214.013252]  <IRQ>
<4>[  214.013272]  update_blocked_averages+0x58/0x5e0
<0>[  214.013359] Kernel panic - not syncing: Fatal exception in interrupt
<4>[  214.013353]  ? update_blocked_averages+0x5/0x5e0
<4>[  214.013483]  run_rebalance_domains+0x49/0x70
<4>[  214.013620]  __do_softirq+0x10a/0x38c
<4>[  214.013747]  __irq_exit_rcu+0x86/0xb0
<4>[  214.013788]  irq_exit_rcu+0xe/0x20
<4>[  214.013824]  sysvec_apic_timer_interrupt+0x6a/0x80
<4>[  214.013874]  </IRQ>
<4>[  214.013892]  <TASK>
<4>[  214.013921]  asm_sysvec_apic_timer_interrupt+0x1a/0x20
<4>[  214.013965] RIP: 0010:__text_poke+0x2aa/0x450
<4>[  214.014004] Code: 00 00 48 01 f2 e8 66 16 04 00 49 81 fd 70 78
a3 8b 0f 84 08 01 00 00 48 83 7c 24 18 00 74 06 e8 cc 48 18 00 fb 48
8b 7c 24 30 <e8> 91 ac ea 00 48 8b 44 24 38 65 48 2b 04 25 28 00 00 00
0f 85 6a
<4>[  214.014027] RSP: 0018:ffffb529c04bbc20 EFLAGS: 00000246
<4>[  214.014064] RAX: 0000000000027bb4 RBX: ffffffff8bae2b10 RCX:
0000000000000000
<4>[  214.014084] RDX: ffffa2383bd00000 RSI: 0000000000000000 RDI:
fffff631440015a8
<4>[  214.014103] RBP: 0000000000000001 R08: 00000000000000cc R09:
0000000000000001
<4>[  214.014123] R10: ffffb529c04bbcac R11: ffffffff8df2095a R12:
ffffa237c00561e0
<4>[  214.014143] R13: ffffffff8ba37870 R14: 0000000000000b10 R15:
0000000000000b11
<4>[  214.014179]  ? __pfx_text_poke_memcpy+0x10/0x10
<4>[  214.014227]  ? __pfx_task_non_contending+0x10/0x10
<4>[  214.014466]  text_poke_bp_batch+0x8a/0x300
<4>[  214.014538]  ? __wake_up_locked_key+0x4/0x20
<4>[  214.014608]  text_poke_queue+0x6c/0xa0
<4>[  214.014676]  ftrace_replace_code+0x19a/0x220
<4>[  214.014773]  ftrace_modify_all_code+0x14a/0x180
<4>[  214.014826]  ftrace_shutdown.part.0+0x10e/0x1e0
<4>[  214.014882]  unregister_ftrace_graph+0x55/0x90
<4>[  214.014920]  tracing_set_tracer+0x119/0x270
<4>[  214.014986]  tracing_set_trace_write+0x90/0xd0
<4>[  214.015153]  vfs_write+0xcb/0x410
<4>[  214.015245]  ? trace_hardirqs_on+0x21/0x90
<4>[  214.015282]  ? trace_graph_return+0xb4/0x100
<4>[  214.015426]  ? ftrace_regs_caller_end+0x61/0x61
<4>[  214.015469]  ksys_write+0x6f/0xf0
<4>[  214.015547]  ? ftrace_regs_caller_end+0x61/0x61
<4>[  214.015580]  do_syscall_64+0x3e/0x90
<4>[  214.015631]  entry_SYSCALL_64_after_hwframe+0x72/0xdc
<4>[  214.015669] RIP: 0033:0x7f5899197190
<4>[  214.015897] Code: 40 00 48 8b 15 71 9c 0d 00 f7 d8 64 89 02 48
c7 c0 ff ff ff ff eb b7 0f 1f 00 80 3d 51 24 0e 00 00 74 17 b8 01 00
00 00 0f 05 <48> 3d 00 f0 ff ff 77 58 c3 0f 1f 80 00 00 00 00 48 83 ec
28 48 89
<4>[  214.015920] RSP: 002b:00007ffc73238a88 EFLAGS: 00000202
ORIG_RAX: 0000000000000001
<4>[  214.015967] RAX: ffffffffffffffda RBX: 0000000000000004 RCX:
00007f5899197190
<4>[  214.015999] RDX: 0000000000000004 RSI: 000055a4a8f346a0 RDI:
0000000000000001
<4>[  214.016018] RBP: 000055a4a8f346a0 R08: 0000000000000002 R09:
000055a4a8f4b98b
<4>[  214.016037] R10: 0000000000000000 R11: 0000000000000202 R12:
0000000000000001
<4>[  214.016056] R13: 0000000000000004 R14: 0000000000000002 R15:
0000000000000000
<4>[  214.016232]  </TASK>
<4>[  214.016251] Modules linked in: fuse configfs [last unloaded:
ftrace_direct]
<4>[  214.017050] ---[ end trace 0000000000000000 ]---
<4>[  214.017081] RIP: 0010:update_rq_clock+0x5/0x20
<4>[  214.017128] Code: 0d 48 83 c4 40 c3 cc cc cc cc 0f 0b eb e3 e8
52 94 e0 00 66 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 66
0f 1f 00 0f <1f> 44 00 00 f6 87 88 09 00 00 02 74 05 c3 cc cc cc cc e9
d4 c3 ff
<4>[  214.017152] RSP: 0018:ffffb529c0003ea0 EFLAGS: 00000082
<4>[  214.017188] RAX: 00000000fffeaed4 RBX: 0000000000000001 RCX:
ffffa2383bc2b340
<4>[  214.017422] RDX: 0000000000000001 RSI: 0000000000000000 RDI:
ffffa2383bc2b340
<4>[  214.017444] RBP: 00000000ffff9934 R08: 0000000000000003 R09:
0000000000000000
<4>[  214.017464] R10: ffffffff8d4060c0 R11: ffffb529c0003ff8 R12:
0000000000000000
<4>[  214.017484] R13: ffffa2383bc2b340 R14: ffffa2383bc2b340 R15:
0000000000000000
<4>[  214.017505] FS:  00007f589909c740(0000)
GS:ffffa2383bd00000(0000) knlGS:0000000000000000
<4>[  214.017530] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
<4>[  214.017552] CR2: 00007f16b54e181c CR3: 00000001069e2000 CR4:
00000000000006e0
<0>[  217.337191] Shutting down cpus with NMI
<0>[  217.338269] Kernel Offset: 0xaa00000 from 0xffffffff81000000
(relocation range: 0xffffffff80000000-0xffffffffbfff


i386 kernel crash:
---------------

[    0.000000] Linux version 6.3.1-rc1 (tuxmake@tuxmake) (Debian clang
version 17.0.0 (++20230417071830+ae77aceba5ad-1~exp1~20230417071935.630),
Debian LLD 17.0.0) #1 SMP PREEMPT_DYNAMIC @1682689312
...
cgroup_fj_stress 1 TPASS: All done!
cgroup_fj_stress 2 TINFO: Removing all ltp subgroups...
<4>[   92.135813] int3: 0000 [#1] PREEMPT SMP
<4>[   92.136105] CPU: 0 PID: 3107 Comm: cgroup_fj_stres Not tainted
6.3.1-rc1 #1
<4>[   92.136265] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009),
BIOS 1.14.0-2 04/01/2014
<4>[   92.136441] EIP: get_page_from_freelist+0xf1/0xc70
<4>[   92.136848] Code: 89 45 8c 8d 04 5b 89 45 94 c7 45 a4 00 00 00
00 c7 45 a8 00 00 00 00 89 5d e0 90 90 90 90 90 90 90 90 90 90 90 90
90 90 90 3e <8d> 74 26 00 8b 45 0c 80 78 14 00 89 7d e4 74 28 89 f8 89
f7 8b 70
<4>[   92.136925] EAX: 00000000 EBX: 00000000 ECX: 00000054 EDX: 00000801
<4>[   92.136952] ESI: ca2aa4c8 EDI: ca2a9d40 EBP: c3cf1d28 ESP: c3cf1c90
<4>[   92.136986] DS: 007b ES: 007b FS: 00d8 GS: 0033 SS: 0068 EFLAGS: 00000297
<4>[   92.137023] CR0: 80050033 CR2: b7d10ec8 CR3: 02cb7000 CR4: 000006d0
<4>[   92.137143] Call Trace:
<4>[   92.137451]  ? sysvec_call_function_single+0x2c/0x30
<4>[   92.137539]  ? sysvec_call_function+0x30/0x30
<4>[   92.137557]  ? irqentry_exit+0x30/0x40
<4>[   92.137574]  ? sysvec_call_function_single+0x2c/0x30
<4>[   92.137602]  ? __alloc_pages+0x8d/0x270
<4>[   92.137625]  __alloc_pages+0xf5/0x270
<4>[   92.137678]  pte_alloc_one+0x25/0xa0
<4>[   92.137702]  __pte_alloc+0x22/0xe0
<4>[   92.137721]  ? __get_user_pages+0x1cd/0x3a0
<4>[   92.137743]  handle_mm_fault+0xb94/0xdf0
<4>[   92.137762]  ? mt_find+0x90/0x180
<4>[   92.137790]  ? __irq_exit_rcu+0x3c/0xd0
<4>[   92.137812]  __get_user_pages+0x1cd/0x3a0
<4>[   92.137836]  ? __down_read_common+0x317/0x460
<4>[   92.137860]  get_user_pages_remote+0xb9/0x340
<4>[   92.137893]  get_arg_page+0x5c/0x120
<4>[   92.137915]  ? up_write+0x45/0xc0
<4>[   92.137936]  copy_string_kernel+0x93/0x120
<4>[   92.137955]  ? alloc_bprm+0x1c8/0x230
<4>[   92.137978]  do_execveat_common+0x1eb/0x2a0
<4>[   92.138001]  __ia32_sys_execve+0x29/0x30
<4>[   92.138024]  __do_fast_syscall_32+0x86/0xcc
<4>[   92.138039]  ? irqentry_exit_to_user_mode+0xf/0x1c
<4>[   92.138056]  ? irqentry_exit+0x12/0x40
<4>[   92.138073]  ? trace_hardirqs_on_prepare+0x26/0x70
<4>[   92.138093]  ? irqentry_exit_to_user_mode+0xf/0x1c
<4>[   92.138113]  do_fast_syscall_32+0x29/0x5c
<4>[   92.138131]  do_SYSENTER_32+0x12/0x14
<4>[   92.138146]  entry_SYSENTER_32+0x98/0xf1
<4>[   92.138256] EIP: 0xb7f4c539
<4>[   92.138573] Code: 03 74 b4 01 10 07 03 74 b0 01 10 08 03 74 d8
01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 51 52 55 89 e5
0f 34 cd 80 <5d> 5a 59 c3 90 90 90 90 90 90 90 58 b8 77 00 00 00 cd 80
90 90 90
<4>[   92.138586] EAX: ffffffda EBX: 0869e180 ECX: 086f3f50 EDX: 087069f0
<4>[   92.138595] ESI: 0869e180 EDI: 00000020 EBP: 08705540 ESP: bfe8e708
<4>[   92.138605] DS: 007b ES: 007b FS: 0000 GS: 0033 SS: 007b EFLAGS: 00000292
<4>[   92.138718] Modules linked in:
<4>[   92.164397] ---[ end trace 0000000000000000 ]---
<4>[   92.164662] EIP: get_page_from_freelist+0xf1/0xc70
<4>[   92.164706] Code: 89 45 8c 8d 04 5b 89 45 94 c7 45 a4 00 00 00
00 c7 45 a8 00 00 00 00 89 5d e0 90 90 90 90 90 90 90 90 90 90 90 90
90 90 90 3e <8d> 74 26 00 8b 45 0c 80 78 14 00 89 7d e4 74 28 89 f8 89
f7 8b 70
<4>[   92.164721] EAX: 00000000 EBX: 00000000 ECX: 00000054 EDX: 00000801
<4>[   92.164731] ESI: ca2aa4c8 EDI: ca2a9d40 EBP: c3cf1d28 ESP: c3cf1c90
<4>[   92.164741] DS: 007b ES: 007b FS: 00d8 GS: 0033 SS: 0068 EFLAGS: 00000297
<4>[   92.164753] CR0: 80050033 CR2: b7d10ec8 CR3: 02cb7000 CR4: 000006d0
<0>[   92.164918] Kernel panic - not syncing: Fatal exception in interrupt
<0>[   92.165882] Kernel Offset: disabled

log links,
- https://qa-reports.linaro.org/lkft/linux-stable-rc-linux-6.3.y/build/v6.3-rc4-935-gf45bb34ed520/testrun/16605304/suite/log-parser-test/test/check-kernel-panic/log
- https://qa-reports.linaro.org/lkft/linux-stable-rc-linux-6.3.y/build/v6.3-rc4-935-gf45bb34ed520/testrun/16605678/suite/log-parser-test/test/check-kernel-panic/log
- https://qa-reports.linaro.org/lkft/linux-stable-rc-linux-6.3.y/build/v6.3-rc4-935-gf45bb34ed520/testrun/16605670/suite/log-parser-test/tests/


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

Re: [PATCH 6.3 00/11] 6.3.1-rc1 review

[Rudi Heitbaum]

On Fri, Apr 28, 2023 at 01:27:35PM +0200, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 6.3.1 release.
> There are 11 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, 30 Apr 2023 11:20:30 +0000.
> Anything received after that time might be too late.

Hi Greg,

6.3.1-rc1 tested.

Run tested on:
- Intel Alder Lake x86_64 (nuc12 i7-1260P)

In addition - build tested for:
- Allwinner A64
- Allwinner H3
- Allwinner H5
- NXP iMX6
- NXP iMX8
- Qualcomm Dragonboard
- Rockchip RK3288
- Rockchip RK3328
- Rockchip RK3399pro
- Samsung Exynos

Tested-by: Rudi Heitbaum <rudi@heitbaum.com>
--
Rudi

Re: [PATCH 6.3 00/11] 6.3.1-rc1 review

[Ron Economos]

On 4/28/23 4:27 AM, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 6.3.1 release.
> There are 11 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, 30 Apr 2023 11:20:30 +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/v6.x/stable-review/patch-6.3.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-6.3.y
> and the diffstat can be found below.
>
> thanks,
>
> greg k-h

Built and booted successfully on RISC-V RV64 (HiFive Unmatched).

Tested-by: Ron Economos <re@w6rz.net>

Re: [PATCH 6.3 00/11] 6.3.1-rc1 review

[Guenter Roeck]

On Fri, Apr 28, 2023 at 01:27:35PM +0200, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 6.3.1 release.
> There are 11 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, 30 Apr 2023 11:20:30 +0000.
> Anything received after that time might be too late.
> 

Build results:
	total: 153 pass: 153 fail: 0
Qemu test results:
	total: 520 pass: 520 fail: 0

Tested-by: Guenter Roeck <linux@roeck-us.net>

Guenter

Re: [PATCH 6.3 00/11] 6.3.1-rc1 review

[Bagas Sanjaya]

On Fri, Apr 28, 2023 at 01:27:35PM +0200, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 6.3.1 release.
> There are 11 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.
> 

Successfully built and installed bindeb-pkgs for my computer (Acer E15,
Intel Core i3 Haswell).

Tested-by: Bagas Sanjaya <bagasdotme@gmail.com>

-- 
An old man doll... just what I always wanted! - Clara

Re: [PATCH 6.3 00/11] 6.3.1-rc1 review

[Florian Fainelli]

On 4/28/2023 4:27 AM, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 6.3.1 release.
> There are 11 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, 30 Apr 2023 11:20:30 +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/v6.x/stable-review/patch-6.3.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-6.3.y
> and the diffstat can be found below.
> 
> thanks,
> 
> greg k-h

On ARCH_BRCMSTB using 32-bit and 64-bit ARM kernels, build tested on 
BMIPS_GENERIC:

Tested-by: Florian Fainelli <f.fainelli@gmail.com>
-- 
Florian

RE: [PATCH 6.3 00/11] 6.3.1-rc1 review

[Chris Paterson]

Hello Greg,

> From: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> Sent: Friday, April 28, 2023 12:28 PM
> 
> This is the start of the stable review cycle for the 6.3.1 release.
> There are 11 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, 30 Apr 2023 11:20:30 +0000.
> Anything received after that time might be too late.

Sorry it's late. Weekend & national holidays in the UK etc...

CIP configurations built and booted with Linux 6.3.1-rc1 (f45bb34ed520):
https://gitlab.com/cip-project/cip-kernel/linux-cip/-/pipelines/854248852/

Tested-by: Chris Paterson (CIP) <chris.paterson2@renesas.com>

Kind regards, Chris