6.6.145-rc1 review
Subsystems (7)
Greg Kroah-Hartman
maintainerPATCH 1255/1266 Bluetooth: hci_sync: Fix attempting to send HCI_Disconnect to BIS handle
In reply to Greg Kroah-Hartman6.6-stable review patch. If anyone has any objections, please let me know.
------------------
From: Luiz Augusto von Dentz <[email protected]>
commit 314d30b1508682e27c8a324096262c66f23455d9 upstream.
BIS/PA connections do have their own cleanup proceedure which are performed by hci_conn_cleanup/bis_cleanup.
--- net/bluetooth/hci_sync.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
net/bluetooth/hci_sync.c +1 -1
@@ -5529,7 +5529,7 @@ static int hci_disconnect_sync(struct hc {struct hci_cp_disconnect cp; -if (test_bit (HCI_CONN_BIG_CREATED , &conn->flags)) { +if (conn->type ==BIS_LINK ) {/* This is a BIS connection, hci_conn_del will * do the necessary cleanup. */
Greg Kroah-Hartman
maintainerPATCH 1256/1266 Bluetooth: 6lowpan: Fix using chan->conn as indication to no remote netdev
In reply to Greg Kroah-Hartman6.6-stable review patch. If anyone has any objections, please let me know.
------------------
From: Luiz Augusto von Dentz <[email protected]>
commit d38eaf611839b85ade3dd3db309dbc8aaaaf0095 upstream.
b66774b48dd9 ("Bluetooth: L2CAP: Fix UAF in channel timeout by holding conn ref") don't reset the chan->conn to NULL anymore making the bt# netdev not be remove once the last l2cap_chan_del is removed.
Instead of restoring the original behavior this remove the logic of keeping the interface after the last channel is removed because it never worked as intended and the l2cap_chan_del always detach its l2cap_conn which results in always removing the channel anyway.
--- net/bluetooth/6lowpan.c | 18 +++--------------- 1 file changed, 3 insertions(+), 15 deletions(-)
net/bluetooth/6lowpan.c +3 -15
@@ -781,20 +781,10 @@ static void chan_close_cb(struct l2cap_cstruct lowpan_btle_dev *dev =NULL ;struct lowpan_peer *peer;int err = -ENOENT ; -bool last = false, remove = true; +bool last = false;BT_DBG ("chan %p conn %p" , chan, chan->conn); -if (chan->conn && chan->conn->hcon) { -if (!is_bt_6lowpan (chan->conn->hcon)) -return ; - -/* If conn is set, then the netdev is also there and we should -* not remove it. -*/ - remove = false; - } -spin_lock (&devices_lock);list_for_each_entry_rcu (entry, &bt_6lowpan_devices, list) {
@@ -821,10 +811,8 @@ static void chan_close_cb(struct l2cap_cifdown (dev->netdev); -if (remove) { -INIT_WORK (&entry->delete_netdev, delete_netdev); -schedule_work (&entry->delete_netdev); - } +INIT_WORK (&entry->delete_netdev, delete_netdev); +schedule_work (&entry->delete_netdev); }else {spin_unlock (&devices_lock); }
Greg Kroah-Hartman
maintainerPATCH 1257/1266 selftests/hid: ensure CKI can compile our new tests on old kernels
In reply to Greg Kroah-Hartman6.6-stable review patch. If anyone has any objections, please let me know.
------------------
From: Benjamin Tissoires <[email protected]>
commit fcdf830ea634cf0ee6543b6cd6a4932f92464fc7 upstream.
In the same way than commit ae7487d112cf ("selftests/hid: ensure we can compile the tests on kernels pre-6.3") we should expose struct hid_bpf_ops when it's not available in vmlinux.h.
So unexpose an eventual struct hid_bpf_ops, include vmlinux.h, and re-export struct hid_bpf_ops.
--- tools/testing/selftests/hid/progs/hid_bpf_helpers.h | 16 ++++++++++++++++ 1 file changed, 16 insertions(+)
tools/testing/selftests/hid/progs/hid_bpf_helpers.h +16 -0
@@ -7,6 +7,7 @@/* "undefine" structs and enums in vmlinux.h, because we "override" them below */ #define hid_bpf_ctx hid_bpf_ctx___not_used +#define hid_bpf_ops hid_bpf_ops___not_used#define hid_report_type hid_report_type___not_used#define hid_class_request hid_class_request___not_used#define hid_bpf_attach_flags hid_bpf_attach_flags___not_used
@@ -24,6 +25,7 @@#include "vmlinux.h" #undef hid_bpf_ctx +#undef hid_bpf_ops#undef hid_report_type#undef hid_class_request#undef hid_bpf_attach_flags
@@ -68,6 +70,20 @@ enum hid_class_request { HID_REQ_SET_PROTOCOL = 0x0B, }; +struct hid_bpf_ops { +int hid_id; +u32 flags; +struct list_head list; +int (*hid_device_event)(struct hid_bpf_ctx *ctx,enum hid_report_type report_type, +u64 source); +int (*hid_rdesc_fixup)(struct hid_bpf_ctx *ctx); +int (*hid_hw_request)(struct hid_bpf_ctx *ctx,unsigned char reportnum, +enum hid_report_type rtype,enum hid_class_request reqtype, +u64 source); +int (*hid_hw_output_report)(struct hid_bpf_ctx *ctx,u64 source); +struct hid_device *hdev; +}; +#ifndef BPF_F_BEFORE #define BPF_F_BEFORE (1U << 3)#endif
Greg Kroah-Hartman
maintainerPATCH 1258/1266 Bluetooth: btmtk: Fix btmtk.c undefined reference build error harder
In reply to Greg Kroah-Hartman6.6-stable review patch. If anyone has any objections, please let me know.
------------------
From: Arnd Bergmann <[email protected]>
commit 61f7a8f975456d7be21100ee0936389142b95a81 upstream.
The previous fix was incomplete as the link failure still persists with CONFIG_USB=m when the sdio or serial wrappers for btmtk.c are build-in:
btmtk.c:(.text+0x468): undefined reference to usb_alloc_urb' btmtk.c:(.text+0x488): undefined reference to usb_free_urb' btmtk.c:(.text+0x500): undefined reference to usb_anchor_urb' btmtk.c:(.text+0x50a): undefined reference to usb_submit_urb' btmtk.c:(.text+0x92c): undefined reference to usb_control_msg' btmtk.c:(.text+0xa92): undefined reference to usb_unanchor_urb' btmtk.c:(.text+0x11e4): undefined reference to usb_set_interface' btmtk.c:(.text+0x120a): undefined reference to usb_kill_anchored_urbs'
Disallow this configuration.
--- drivers/bluetooth/Kconfig | 2 ++ 1 file changed, 2 insertions(+)
drivers/bluetooth/Kconfig +2 -0
@@ -412,6 +412,7 @@ config BT_ATH3K config BT_MTKSDIO tristate "MediaTek HCI SDIO driver" depends on MMC + depends on USB || !BT_HCIBTUSB_MTK select BT_MTK help MediaTek Bluetooth HCI SDIO driver.
@@ -424,6 +425,7 @@ config BT_MTKSDIO config BT_MTKUART tristate "MediaTek HCI UART driver" depends on SERIAL_DEV_BUS + depends on USB || !BT_HCIBTUSB_MTK select BT_MTK help MediaTek Bluetooth HCI UART driver.
Greg Kroah-Hartman
maintainerPATCH 1259/1266 Bluetooth: btmtk: remove #ifdef around declarations
In reply to Greg Kroah-Hartman6.6-stable review patch. If anyone has any objections, please let me know.
------------------
From: Arnd Bergmann <[email protected]>
commit 7a8c6fb21a7c913ddb99785b14914dab2f934fbd upstream.
The caller of these functions in btusb.c is guarded with an if(IS_ENABLED()) style check, so dead code is left out, but the declarations are still needed at compile time:
drivers/bluetooth/btusb.c: In function 'btusb_mtk_reset':drivers/bluetooth/btusb.c:2705:15: error: implicit declaration of function 'btmtk_usb_subsys_reset' [-Wimplicit-function-declaration]
2705 | err = btmtk_usb_subsys_reset(hdev, btmtk_data->dev_id);
| ^~~~~~~~~~~~~~~~~~~~~~
drivers/bluetooth/btusb.c: In function 'btusb_send_frame_mtk':
drivers/bluetooth/btusb.c:2720:23: error: implicit declaration of function 'alloc_mtk_intr_urb' [-Wimplicit-function-declaration]
2720 | urb = alloc_mtk_intr_urb(hdev, skb, btusb_tx_complete);
| ^~~~~~~~~~~~~~~~~~drivers/bluetooth/btusb.c:2720:21: error: assignment to 'struct urb *' from 'int' makes pointer from integer without a cast [-Wint-conversion]
2720 | urb = alloc_mtk_intr_urb(hdev, skb, btusb_tx_complete);
| ^
--- drivers/bluetooth/btmtk.h | 2 -- 1 file changed, 2 deletions(-)
drivers/bluetooth/btmtk.h +0 -2
@@ -189,13 +189,11 @@ int btmtk_process_coredump(struct hci_devoid btmtk_fw_get_filename (char *buf,size_t size,u32 dev_id,u32 fw_ver,u32 fw_flavor); -#if IS_ENABLED (CONFIG_BT_HCIBTUSB_MTK )int btmtk_usb_subsys_reset (struct hci_dev *hdev,u32 dev_id);int btmtk_usb_setup (struct hci_dev *hdev);int btmtk_usb_shutdown (struct hci_dev *hdev); -#endif #else static inline int btmtk_set_bdaddr(struct hci_dev *hdev,
Greg Kroah-Hartman
maintainerPATCH 1260/1266 xfs: fix stupid compiler warning
In reply to Greg Kroah-Hartman6.6-stable review patch. If anyone has any objections, please let me know.
------------------
From: Darrick J. Wong <[email protected]>
commit f06725052098d7b1133ac3846d693c383dc427a2 upstream.
gcc 14.2 warns about:
xfs_attr_item.c: In function ‘xfs_attr_recover_work’:
xfs_attr_item.c:785:9: warning: ‘ip’ may be used uninitialized [-Wmaybe-uninitialized]
785 | xfs_trans_ijoin(tp, ip, 0);
| ^~~~~~~~~~~~~~~~~~~~~~~~~~xfs_attr_item.c:740:42: note: ‘ip’ was declared here
740 | struct xfs_inode *ip;
| ^~
I think this is bogus since xfs_attri_recover_work either returns a real pointer having initialized ip or an ERR_PTR having not touched it, but the tools are smarter than me so let's just null-init the variable anyway.
--- fs/xfs/xfs_attr_item.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
fs/xfs/xfs_attr_item.c +1 -1
@@ -622,7 +622,7 @@ xfs_attr_recover_work(struct xfs_attri_log_item *attrip =ATTRI_ITEM (lip);struct xfs_attr_intent *attr;struct xfs_mount *mp = lip->li_log->l_mp; -struct xfs_inode *ip; +struct xfs_inode *ip =NULL ;struct xfs_da_args *args;struct xfs_trans *tp;struct xfs_trans_res resv;
Greg Kroah-Hartman
maintainerPATCH 1261/1266 writeback: Fix use after free in inode_switch_wbs_work_fn()
In reply to Greg Kroah-Hartman6.6-stable review patch. If anyone has any objections, please let me know.
------------------
From: Jan Kara <[email protected]>
commit 6689f01d6740cf358932b3e97ee968c6099800d9 upstream.
inode_switch_wbs_work_fn() has a loop like:
wb_get(new_wb);
while (1) {
list = llist_del_all(&new_wb->switch_wbs_ctxs);
/* Nothing to do? */
if (!list)
break;
... process the items ...
}Now adding of items to the list looks like:
wb_queue_isw()
if (llist_add(&isw->list, &wb->switch_wbs_ctxs))
queue_work(isw_wq, &wb->switch_work);
Because inode_switch_wbs_work_fn() loops when processing isw items, it can happen that wb->switch_work is pending while wb->switch_wbs_ctxs is empty. This is a problem because in that case wb can get freed (no isw items -> no wb reference) while the work is still pending causing use-after-free issues.
We cannot just fix this by cancelling work when freeing wb because that could still trigger problematic 0 -> 1 transitions on wb refcount due to wb_get() in inode_switch_wbs_work_fn(). It could be all handled with more careful code but that seems unnecessarily complex so let's avoid that until it is proven that the looping actually brings practical benefit. Just remove the loop from inode_switch_wbs_work_fn() instead. That way when wb_queue_isw() queues work, we are guaranteed we have added the first item to wb->switch_wbs_ctxs and nobody is going to remove it (and drop the wb reference it holds) until the queued work runs.
--- fs/fs-writeback.c | 36 +++++++++++++++++++----------------- 1 file changed, 19 insertions(+), 17 deletions(-)
fs/fs-writeback.c +19 -17
@@ -535,28 +535,30 @@ void inode_switch_wbs_work_fn(struct worstruct inode_switch_wbs_context *isw, *next_isw;struct llist_node *list; + list =llist_del_all (&new_wb->switch_wbs_ctxs);/* -* Grab out reference to wb so that it cannot get freed under us +* Nothing to do? That would be a problem as references held by isw +* items protect wb from freeing... +*/ +if (WARN_ON_ONCE (!list)) +return ; + +/* +* Grab our reference to wb so that it cannot get freed under us * after we process all the isw items. */ wb_get (new_wb); -while (1 ) { - list =llist_del_all (&new_wb->switch_wbs_ctxs); -/* Nothing to do? */ -if (!list) -break ; -/* -* In addition to synchronizing among switchers, I_WB_SWITCH -* tells the RCU protected stat update paths to grab the i_page -* lock so that stat transfer can synchronize against them. -* Let's continue after I_WB_SWITCH is guaranteed to be -* visible. -*/ -synchronize_rcu (); +/* +* In addition to synchronizing among switchers, I_WB_SWITCH +* tells the RCU protected stat update paths to grab the i_page +* lock so that stat transfer can synchronize against them. +* Let's continue after I_WB_SWITCH is guaranteed to be +* visible. +*/ +synchronize_rcu (); -llist_for_each_entry_safe (isw, next_isw, list, list) -process_inode_switch_wbs (new_wb, isw); - } +llist_for_each_entry_safe (isw, next_isw, list, list) +process_inode_switch_wbs (new_wb, isw);wb_put (new_wb); }
Greg Kroah-Hartman
maintainerPATCH 1262/1266 writeback: drop now-unnecessary rcu_barrier() in cgroup_writeback_umount()
In reply to Greg Kroah-Hartman6.6-stable review patch. If anyone has any objections, please let me know.
------------------
From: Baokun Li <[email protected]>
commit e90a6d668e26e00a72df2d09c173b563468f09c9 upstream.
Commit e1b849cfa6b6 ("writeback: Avoid contention on wb->list_lock when switching inodes") replaced the queue_rcu_work() based scheduling of inode wb switches with a plain queue_work(). Since then no switcher goes through call_rcu(), so rcu_barrier() in cgroup_writeback_umount() has no callbacks of its own to wait for. It still drains unrelated call_rcu() callbacks from other subsystems on busy systems, which incidentally slows umount down; drop it.
--- fs/fs-writeback.c | 5 ----- 1 file changed, 5 deletions(-)
fs/fs-writeback.c +0 -5
@@ -1191,11 +1191,6 @@ void cgroup_writeback_umount(void)* will then drain it. */ synchronize_rcu (); -/* -* Use rcu_barrier() to wait for all pending callbacks to -* ensure that all in-flight wb switches are in the workqueue. -*/ -rcu_barrier ();flush_workqueue (isw_wq); } }
Greg Kroah-Hartman
maintainerPATCH 1263/1266 jiffies: Define secs_to_jiffies()
In reply to Greg Kroah-Hartman6.6-stable review patch. If anyone has any objections, please let me know.
------------------
From: Easwar Hariharan <[email protected]>
commit b35108a51cf7bab58d7eace1267d7965978bcdb8 upstream.
secs_to_jiffies() is defined in hci_event.c and cannot be reused by other call sites. Hoist it into the core code to allow conversion of the ~1150 usages of msecs_to_jiffies() that either:
- use a multiplier value of 1000 or equivalently MSEC_PER_SEC, or
- have timeouts that are denominated in seconds (i.e. end in 000)
It's implemented as a macro to allow usage in static initializers.
This will also allow conversion of yet more sites that use (sec * HZ) directly, and improve their readability.
--- include/linux/jiffies.h | 13 +++++++++++++ net/bluetooth/hci_event.c | 2 -- 2 files changed, 13 insertions(+), 2 deletions(-)
include/linux/jiffies.h +13 -0
@@ -523,6 +523,19 @@ static __always_inline unsigned long mse } } +/** +* secs_to_jiffies: - convert seconds to jiffies +* @_secs: time in seconds +* +* Conversion is done by simple multiplication with HZ +* +* secs_to_jiffies() is defined as a macro rather than a static inline +* function so it can be used in static initializers. +* +* Return: jiffies value +*/ +#define secs_to_jiffies (_secs) ((_secs) * HZ) +extern unsigned long __usecs_to_jiffies (const unsigned int u);#if !(USEC_PER_SEC %HZ )static inline unsigned long _usecs_to_jiffies (const unsigned int u)
net/bluetooth/hci_event.c +0 -2
@@ -43,8 +43,6 @@#define ZERO_KEY "\x00\x00\x00\x00\x00\x00\x00\x00" \ "\x00\x00\x00\x00\x00\x00\x00\x00" -#define secs_to_jiffies (_secs) msecs_to_jiffies((_secs) * 1000) -/* Handle HCI Event packets */ static void *hci_ev_skb_pull(struct hci_dev *hdev, struct sk_buff *skb,
Greg Kroah-Hartman
maintainerPATCH 1264/1266 jiffies: Cast to unsigned long in secs_to_jiffies() conversion
In reply to Greg Kroah-Hartman6.6-stable review patch. If anyone has any objections, please let me know.
------------------
From: Easwar Hariharan <[email protected]>
commit bb2784d9ab49587ba4fbff37a319fff2924db289 upstream.
While converting users of msecs_to_jiffies(), lkp reported that some range checks would always be true because of the mismatch between the implied int value of secs_to_jiffies() vs the unsigned long return value of the msecs_to_jiffies() calls it was replacing.
Fix this by casting the secs_to_jiffies() input value to unsigned long.
--- include/linux/jiffies.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
include/linux/jiffies.h +1 -1
@@ -534,7 +534,7 @@ static __always_inline unsigned long mse* * Return: jiffies value */ -#define secs_to_jiffies (_secs) ((_secs) * HZ) +#define secs_to_jiffies (_secs) (unsigned long)((_secs) * HZ)extern unsigned long __usecs_to_jiffies (const unsigned int u);#if !(USEC_PER_SEC %HZ )
Greg Kroah-Hartman
maintainerPATCH 1265/1266 driver core: Fix missing jiffies conversion in deferred_probe_extend_timeout()
In reply to Greg Kroah-Hartman6.6-stable review patch. If anyone has any objections, please let me know.
------------------
From: Danilo Krummrich <[email protected]>
commit f9e6da99fe49277979798a1c3b9790ae10aaa18a upstream.
mod_delayed_work() takes jiffies, not seconds. Thus, restore the dropped conversion.
While at it, fix incorrect indentation.
--- drivers/base/dd.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/base/dd.c +1 -1
@@ -327,7 +327,7 @@ void deferred_probe_extend_timeout(void)* start a new one. */ if (mod_delayed_work (system_wq, &deferred_probe_timeout_work, - driver_deferred_probe_timeout)) +secs_to_jiffies (driver_deferred_probe_timeout)))pr_debug ("Extended deferred probe timeout by %d secs\n" , driver_deferred_probe_timeout); }
Greg Kroah-Hartman
maintainerPATCH 1266/1266 driver core: Guard deferred probe timeout extension with delayed_work_pending()
In reply to Greg Kroah-Hartman6.6-stable review patch. If anyone has any objections, please let me know.
------------------
From: Danilo Krummrich <[email protected]>
commit 557495bc879013c3d5e21d667e987e7ce3a514de upstream.
mod_delayed_work() unconditionally queues the work even when it wasn't previously pending, which can fire the timeout prematurely or restart it after it already fired. Add a delayed_work_pending() guard to restore the originally intended semantics.
Premature firing calls fw_devlink_drivers_done() before all built-in drivers have registered, causing fw_devlink to prematurely relax device links for suppliers whose drivers haven't loaded yet.
--- drivers/base/dd.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)
drivers/base/dd.c +2 -1
@@ -326,7 +326,8 @@ void deferred_probe_extend_timeout(void)* If the work hasn't been queued yet or if the work expired, don't * start a new one. */ -if (mod_delayed_work (system_wq, &deferred_probe_timeout_work, +if (delayed_work_pending (&deferred_probe_timeout_work) && +mod_delayed_work (system_wq, &deferred_probe_timeout_work,secs_to_jiffies (driver_deferred_probe_timeout)))pr_debug ("Extended deferred probe timeout by %d secs\n" , driver_deferred_probe_timeout);
# Librecast Test Results
020/020 [ OK ] liblcrq
010/010 [ OK ] libmld
120/120 [ OK ] liblibrecast
CPU/kernel: Linux auntie 6.6.145-rc1-g5b1c90a58c89 #1 SMP PREEMPT_DYNAMIC Tue Jul 21 20:42:54 -00 2026 x86_64 AMD Ryzen 9 9950X 16-Core Processor AuthenticAMD GNU/Linux
Am 21.07.2026 um 17:07 schrieb Greg Kroah-Hartman:
Quoted 4 lines
This is the start of the stable review cycle for the 6.6.145 release. There are 1266 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.
Builds, boots and works on my 2-socket Ivy Bridge Xeon E5-2697 v2 server. No dmesg oddities or regressions found.
Beste Grüße,
Peter Schneider
Signature · 8 lines
Climb the mountain not to plant your flag, but to embrace the challenge, enjoy the air and behold the view. Climb it so you can see the world, not so the world can see you. -- David McCullough Jr. OpenPGP: 0xA3828BD796CCE11A8CADE8866E3A92C92C3FF244 Download: https://www.peters-netzplatz.de/download/pschneider1968_pub.asc https://keys.mailvelope.com/pks/lookup?op=get&[email protected] https://keys.mailvelope.com/pks/lookup?op=get&[email protected]
Quoted 4 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 6.6.145 release. There are 1266 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.
Hi,
Build tested in our x86,arm64,loongarch,riscv config successfully without error.
BRs
Wentao Guan
Log:
Linux version 6.6.145-rc1-arm64-desktop-hwe-g5b1c90a58c89 (guanwentao@uos-PC) (aarch64-linux-gnu-gcc-12 (Deepin 12.3.0-17deepin8) 12.3.0, GNU ld (GNU Binutils for Deepin) 2.41) # SMP PREEMPT Linux version 6.6.145-rc1-arm64-desktop-hwe-g5b1c90a58c89 (guanwentao@uos-PC) (aarch64-linux-gnu-gcc-12 (Deepin 12.3.0-17deepin8) 12.3.0, GNU ld (GNU Binutils for Deepin) 2.41) #2 SMP PREEMPT Wed Jul 22 14:02:44 CST 2026 Linux version 6.6.145-rc1-loong64-desktop-hwe-g5b1c90a58c89 (guanwentao@uos-PC) (loongarch64-linux-gnu-gcc-12 (Deepin 12.3.0-17deepin8) 12.3.0, GNU ld (GNU Binutils for Deepin) 2.41) # SMP PREEMPT Linux version 6.6.145-rc1-loong64-desktop-hwe-g5b1c90a58c89 (guanwentao@uos-PC) (loongarch64-linux-gnu-gcc-12 (Deepin 12.3.0-17deepin8) 12.3.0, GNU ld (GNU Binutils for Deepin) 2.41) #3 SMP PREEMPT Wed Jul 22 14:19:39 CST 2026 Linux version 6.6.145-rc1-riscv64-desktop-hwe+ (guanwentao@uos-PC) (riscv64-linux-gnu-gcc-12 (Deepin 12.3.0-17deepin8) 12.3.0, GNU ld (GNU Binutils for Deepin) 2.41) # SMP
Linux version 6.6.145-rc1-riscv64-desktop-hwe+ (guanwentao@uos-PC) (riscv64-linux-gnu-gcc-12 (Deepin 12.3.0-17deepin8) 12.3.0, GNU ld (GNU Binutils for Deepin) 2.41) #4 SMP Wed Jul 22 14:35:36 CST 2026 Linux version 6.6.145-rc1-amd64-desktop-hwe-g5b1c90a58c89 (guanwentao@uos-PC) (gcc (Deepin 12.3.0-17deepin15) 12.3.0, GNU ld (GNU Binutils for Deepin) 2.41) # SMP PREEMPT_DYNAMIC
Linux version 6.6.145-rc1-amd64-desktop-hwe-g5b1c90a58c89 (guanwentao@uos-PC) (gcc (Deepin 12.3.0-17deepin15) 12.3.0, GNU ld (GNU Binutils for Deepin) 2.41) #1 SMP PREEMPT_DYNAMIC Wed Jul 22 13:43:48 CST 2026
Quoted 9 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 6.6.145 release. There are 1266 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 Thu, 23 Jul 2026 15:23:00 +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/v6.x/stable-review/patch-6.6.145-rc1.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-6.6.y
and the diffstat can be found below.thanks,
greg k-h
Built and booted successfully on RISC-V RV64 (HiFive Unmatched).
Quoted 14 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 6.6.145 release. There are 1266 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 Thu, 23 Jul 2026 15:23:00 +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.6.145-rc1.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-6.6.y
and the diffstat can be found below.
Quoted 5 lines
thanks,
greg k-h
Compiled and booted on my test system. No dmesg regressions.
thanks,
-- Shuah
Hi!
Quoted 4 lines
This is the start of the stable review cycle for the 6.6.145 release. There are 1266 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.
CIP testing did not find any problems here:
https://gitlab.com/cip-project/cip-testing/linux-stable-rc-ci/-/tree/linux-6.6.y
Best regards,
Pavel