* Re: linux-next: manual merge of the liveupdate tree with the mm-unstable tree
From: Mark Brown @ 2026-07-28 17:56 UTC (permalink / raw)
To: Mike Rapoport
Cc: Andrew Morton, Pasha Tatashin, Pratyush Yadav,
Linux Kernel Mailing List, Linux Next Mailing List, Muchun Song,
Muchun Song
In-Reply-To: <amjpLoJbHsqIAqJO@kernel.org>
[-- Attachment #1: Type: text/plain, Size: 383 bytes --]
On Tue, Jul 28, 2026 at 08:38:54PM +0300, Mike Rapoport wrote:
> On Tue, Jul 28, 2026 at 05:27:05PM +0100, Mark Brown wrote:
> > of liveupdate from next-20260727, I'll have another look tomorrow but
> > would really appreciate it if someone could help out here.
> I've got this for merging mm-unstable into liveupdate/next:
Thanks Mike, all being well I'll go with that tomorrow.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* linux-next: manual merge of the sysctl tree with the mm-nonmm-unstable tree
From: Mark Brown @ 2026-07-28 17:39 UTC (permalink / raw)
To: Luis Chamberlain, Kees Cook, Joel Granados
Cc: Andrew Morton, Linux Kernel Mailing List, Linux Next Mailing List,
Oleg Nesterov
[-- Attachment #1: Type: text/plain, Size: 2831 bytes --]
Hi all,
Today's linux-next merge of the sysctl tree got a conflict in:
kernel/time/jiffies.c
between commit:
842912dea6d51 ("sysctl: remove CONFIG_PROC_SYSCTL, it just mirrors CONFIG_SYSCTL")
from the mm-nonmm-unstable tree and commit:
a3c70a5a9f944 ("sysctl: Generate do_proc_doulongvec_minmax with do_proc_dotypevec macro")
from the sysctl tree.
I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging. You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.
diff --combined kernel/time/jiffies.c
index 84c6bd8e742e9,af529d558fa92..0000000000000
--- a/kernel/time/jiffies.c
+++ b/kernel/time/jiffies.c
@@@ -98,7 -98,7 +98,7 @@@ void __init register_refined_jiffies(lo
__clocksource_register(&refined_jiffies);
}
-#ifdef CONFIG_PROC_SYSCTL
+#ifdef CONFIG_SYSCTL
static ulong mult_hz(const ulong val)
{
return val * HZ;
@@@ -185,7 -185,25 +185,7 @@@ static int do_proc_int_conv_ms_jiffies_
sysctl_u2k_int_conv_ms, sysctl_k2u_int_conv_ms);
}
-static int sysctl_u2k_ulong_conv_ms(const ulong *u_ptr, ulong *k_ptr)
-{
- return proc_ulong_u2k_conv_uop(u_ptr, k_ptr, sysctl_msecs_to_jiffies);
-}
-
-static int sysctl_k2u_ulong_conv_ms(ulong *u_ptr, const ulong *k_ptr)
-{
- return proc_ulong_k2u_conv_kop(u_ptr, k_ptr, sysctl_jiffies_to_msecs);
-}
-
-static int do_proc_ulong_conv_ms_jiffies(bool *negp, ulong *u_ptr, ulong *k_ptr,
- int dir, const struct ctl_table *tbl)
-{
- return proc_ulong_conv(u_ptr, k_ptr, dir, tbl, false,
- sysctl_u2k_ulong_conv_ms, sysctl_k2u_ulong_conv_ms);
-}
-
-
-#else // CONFIG_PROC_SYSCTL
+#else // CONFIG_SYSCTL
static int do_proc_int_conv_jiffies(bool *negp, ulong *u_ptr, int *k_ptr,
int dir, const struct ctl_table *tbl)
{
@@@ -211,6 -229,12 +211,12 @@@ static int do_proc_int_conv_ms_jiffies_
{
return -ENOSYS;
}
+
+ static int do_proc_ulong_conv_ms_jiffies(bool *negp, ulong *u_ptr, ulong *k_ptr,
+ int dir, const struct ctl_table *tbl)
+ {
+ return -ENOSYS;
+ }
#endif
/**
@@@ -309,8 -333,8 +315,8 @@@ int proc_dointvec_ms_jiffies_minmax(con
int proc_doulongvec_ms_jiffies_minmax(const struct ctl_table *table, int dir,
void *buffer, size_t *lenp, loff_t *ppos)
{
- return proc_doulongvec_minmax_conv(table, dir, buffer, lenp, ppos,
- HZ, 1000l);
+ return proc_doulongvec_conv(table, dir, buffer, lenp, ppos,
+ do_proc_ulong_conv_ms_jiffies);
}
EXPORT_SYMBOL(proc_doulongvec_ms_jiffies_minmax);
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* linux-next: manual merge of the staging tree with the staging.current tree
From: Mark Brown @ 2026-07-28 17:39 UTC (permalink / raw)
To: Greg KH
Cc: Eugene Mavick, Greg Kroah-Hartman, Linux Kernel Mailing List,
Linux Next Mailing List, Muhammad Bilal
[-- Attachment #1: Type: text/plain, Size: 1557 bytes --]
Hi all,
Today's linux-next merge of the staging tree got a conflict in:
drivers/staging/rtl8723bs/core/rtw_wlan_util.c
between commit:
ae21407350151 ("staging: rtl8723bs: fix OOB read in WMM_param_handler()")
from the staging.current tree and commit:
6e68c64a71f70 ("staging: rtl8723bs: remove unnecessary parentheses")
from the staging tree.
I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging. You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.
diff --cc drivers/staging/rtl8723bs/core/rtw_wlan_util.c
index c614c0b4c792d,8b0502a1881b5..0000000000000
--- a/drivers/staging/rtl8723bs/core/rtw_wlan_util.c
+++ b/drivers/staging/rtl8723bs/core/rtw_wlan_util.c
@@@ -666,13 -665,10 +665,13 @@@ int WMM_param_handler(struct adapter *p
return false;
}
+ if (pIE->length != WLAN_WMM_LEN)
+ return false;
+
- if (!memcmp(&(pmlmeinfo->WMM_param), (pIE->data + 6), sizeof(struct WMM_para_element)))
+ if (!memcmp(&pmlmeinfo->WMM_param, (pIE->data + 6), sizeof(struct WMM_para_element)))
return false;
- memcpy(&(pmlmeinfo->WMM_param), (pIE->data + 6), sizeof(struct WMM_para_element));
+ memcpy(&pmlmeinfo->WMM_param, (pIE->data + 6), sizeof(struct WMM_para_element));
pmlmeinfo->WMM_enable = 1;
return true;
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* Re: linux-next: manual merge of the liveupdate tree with the mm-unstable tree
From: Mike Rapoport @ 2026-07-28 17:38 UTC (permalink / raw)
To: Mark Brown
Cc: Andrew Morton, Pasha Tatashin, Pratyush Yadav,
Linux Kernel Mailing List, Linux Next Mailing List, Muchun Song,
Muchun Song
In-Reply-To: <amjYWetl6_WVyumg@sirena.org.uk>
On Tue, Jul 28, 2026 at 05:27:05PM +0100, Mark Brown wrote:
> Hi all,
>
> Today's linux-next merge of the liveupdate tree got a conflict in:
>
> mm/hugetlb.c
> mm/mm_init.c
>
> between at least commit:
>
> 7b558c2570017 ("mm/hugetlb: refactor early boot gigantic hugepage allocation")
>
> from the mm-unstable tree and commit:
>
> 7c967e2d549dc ("memblock: make HugeTLB bootmem allocation work with KHO")
> f476132a8999e ("mm/mm_init: don't rely on memblock to get KHO scratch migratetype")
>
> from the liveupdate tree.
>
> I stared at the conflict for a bit but with my minimal familiarity with
> this code I have absolutely no confidence in my ability to do a working
> resolution for this in a timely fashion so instead I merged the version
> of liveupdate from next-20260727, I'll have another look tomorrow but
> would really appreciate it if someone could help out here.
I've got this for merging mm-unstable into liveupdate/next:
diff --cc mm/hugetlb.c
index ab4afc818e8cb,a77c3c1cb8943..0000000000000
--- a/mm/hugetlb.c
+++ b/mm/hugetlb.c
@@@ -3027,51 -3076,23 +3076,16 @@@ out_end_reservation
static __init void *alloc_bootmem(struct hstate *h, int nid, bool node_exact)
{
- struct huge_bootmem_page *m;
- int listnode = nid;
-
if (hugetlb_early_cma(h))
- m = hugetlb_cma_alloc_bootmem(h, &listnode, node_exact);
- else {
- m = memblock_alloc_hugetlb(huge_page_size(h), nid, node_exact);
- if (m) {
- m->flags = 0;
- m->cma = NULL;
+ return hugetlb_cma_alloc_bootmem(h, nid, node_exact);
- /*
- * For pre-HVO to work correctly, pages need to be on
- * the list for the node they were actually allocated
- * from. That node may be different in the case of
- * fallback by memblock_alloc_hugetlb_bootmem. So,
- * extract the actual node first.
- */
- if (!node_exact)
- listnode = early_pfn_to_nid(PHYS_PFN(__pa(m)));
- }
- }
-
- if (m) {
- /*
- * Use the beginning of the huge page to store the
- * huge_bootmem_page struct (until gather_bootmem
- * puts them into the mem_map).
- *
- * Put them into a private list first because mem_map
- * is not up yet.
- */
- INIT_LIST_HEAD(&m->list);
- list_add(&m->list, &huge_boot_pages[listnode]);
- m->hstate = h;
- }
- if (node_exact)
- return memblock_alloc_exact_nid_raw(huge_page_size(h),
- huge_page_size(h), 0,
- MEMBLOCK_ALLOC_ACCESSIBLE, nid);
--
- return m;
- return memblock_alloc_try_nid_raw(huge_page_size(h),
- huge_page_size(h), 0,
- MEMBLOCK_ALLOC_ACCESSIBLE, nid);
++ return memblock_alloc_hugetlb(huge_page_size(h), nid, node_exact);
}
- int alloc_bootmem_huge_page(struct hstate *h, int nid)
+ void *__init arch_alloc_bootmem_huge_page(struct hstate *h, int nid)
__attribute__ ((weak, alias("__alloc_bootmem_huge_page")));
- int __alloc_bootmem_huge_page(struct hstate *h, int nid)
+ void *__init __alloc_bootmem_huge_page(struct hstate *h, int nid)
{
- struct huge_bootmem_page *m = NULL; /* initialize for clang */
int nr_nodes, node = nid;
/* do node specific alloc */
diff --cc mm/mm_init.c
index dc20d6814e48b,711f821f7b3c7..0000000000000
--- a/mm/mm_init.c
+++ b/mm/mm_init.c
@@@ -2683,7 -2683,8 +2682,9 @@@ void __init __weak mem_init(void
void __init mm_core_init_early(void)
{
+ kho_memory_init_early();
+ free_area_init();
+
hugetlb_cma_reserve();
hugetlb_bootmem_alloc();
--
Sincerely yours,
Mike.
^ permalink raw reply
* linux-next: manual merge of the liveupdate tree with the mm-unstable tree
From: Mark Brown @ 2026-07-28 16:27 UTC (permalink / raw)
To: Mike Rapoport, Andrew Morton, Pasha Tatashin, Pratyush Yadav
Cc: Linux Kernel Mailing List, Linux Next Mailing List, Muchun Song,
Muchun Song
[-- Attachment #1: Type: text/plain, Size: 4296 bytes --]
Hi all,
Today's linux-next merge of the liveupdate tree got a conflict in:
mm/hugetlb.c
mm/mm_init.c
between at least commit:
7b558c2570017 ("mm/hugetlb: refactor early boot gigantic hugepage allocation")
from the mm-unstable tree and commit:
7c967e2d549dc ("memblock: make HugeTLB bootmem allocation work with KHO")
f476132a8999e ("mm/mm_init: don't rely on memblock to get KHO scratch migratetype")
from the liveupdate tree.
I stared at the conflict for a bit but with my minimal familiarity with
this code I have absolutely no confidence in my ability to do a working
resolution for this in a timely fashion so instead I merged the version
of liveupdate from next-20260727, I'll have another look tomorrow but
would really appreciate it if someone could help out here.
diff --cc mm/hugetlb.c
index a77c3c1cb8943,ab4afc818e8cb..0000000000000
--- a/mm/hugetlb.c
+++ b/mm/hugetlb.c
@@@ -3076,23 -3027,51 +3076,60 @@@ out_end_reservation
static __init void *alloc_bootmem(struct hstate *h, int nid, bool node_exact)
{
- struct huge_bootmem_page *m;
- int listnode = nid;
-
if (hugetlb_early_cma(h))
++<<<<<<< HEAD
+ return hugetlb_cma_alloc_bootmem(h, nid, node_exact);
+
+ if (node_exact)
+ return memblock_alloc_exact_nid_raw(huge_page_size(h),
+ huge_page_size(h), 0,
+ MEMBLOCK_ALLOC_ACCESSIBLE, nid);
+
+ return memblock_alloc_try_nid_raw(huge_page_size(h),
+ huge_page_size(h), 0,
+ MEMBLOCK_ALLOC_ACCESSIBLE, nid);
++=======
+ m = hugetlb_cma_alloc_bootmem(h, &listnode, node_exact);
+ else {
+ m = memblock_alloc_hugetlb(huge_page_size(h), nid, node_exact);
+ if (m) {
+ m->flags = 0;
+ m->cma = NULL;
+
+ /*
+ * For pre-HVO to work correctly, pages need to be on
+ * the list for the node they were actually allocated
+ * from. That node may be different in the case of
+ * fallback by memblock_alloc_hugetlb_bootmem. So,
+ * extract the actual node first.
+ */
+ if (!node_exact)
+ listnode = early_pfn_to_nid(PHYS_PFN(__pa(m)));
+ }
+ }
+
+ if (m) {
+ /*
+ * Use the beginning of the huge page to store the
+ * huge_bootmem_page struct (until gather_bootmem
+ * puts them into the mem_map).
+ *
+ * Put them into a private list first because mem_map
+ * is not up yet.
+ */
+ INIT_LIST_HEAD(&m->list);
+ list_add(&m->list, &huge_boot_pages[listnode]);
+ m->hstate = h;
+ }
+
+ return m;
++>>>>>>> liveupdate/next
}
-int alloc_bootmem_huge_page(struct hstate *h, int nid)
+void *__init arch_alloc_bootmem_huge_page(struct hstate *h, int nid)
__attribute__ ((weak, alias("__alloc_bootmem_huge_page")));
-int __alloc_bootmem_huge_page(struct hstate *h, int nid)
+void *__init __alloc_bootmem_huge_page(struct hstate *h, int nid)
{
- struct huge_bootmem_page *m = NULL; /* initialize for clang */
int nr_nodes, node = nid;
/* do node specific alloc */
diff --cc mm/mm_init.c
index 18befe5759310,dc20d6814e48b..0000000000000
--- a/mm/mm_init.c
+++ b/mm/mm_init.c
@@@ -685,7 -681,9 +685,13 @@@ static __meminit void pageblock_migrate
const unsigned long end = pfn + nr_pages;
for (pfn = pageblock_align(pfn); pfn < end; pfn += pageblock_nr_pages) {
++<<<<<<< HEAD
+ init_pageblock_migratetype(pfn_to_page(pfn), migratetype, false);
++=======
+ enum migratetype mt = kho_scratch_migratetype(pfn, migratetype);
+
+ init_pageblock_migratetype(pfn_to_page(pfn), mt, false);
++>>>>>>> liveupdate/next
if (!atomic && IS_ALIGNED(pfn, PAGES_PER_SECTION))
cond_resched();
}
@@@ -1978,7 -1982,7 +1983,11 @@@ static void __init deferred_free_pages(
if (!nr_pages)
return;
++<<<<<<< HEAD
+ pageblock_migratetype_init_range(pfn, nr_pages, mt, true);
++=======
+ pageblock_migratetype_init_range(pfn, nr_pages, MIGRATE_MOVABLE, true);
++>>>>>>> liveupdate/next
page = pfn_to_page(pfn);
@@@ -2682,8 -2683,7 +2689,12 @@@ void __init __weak mem_init(void
void __init mm_core_init_early(void)
{
++<<<<<<< HEAD
+ free_area_init();
+
++=======
+ kho_memory_init_early();
++>>>>>>> liveupdate/next
hugetlb_cma_reserve();
hugetlb_bootmem_alloc();
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* linux-next: manual merge of the bluetooth tree with the origin tree
From: Mark Brown @ 2026-07-28 16:26 UTC (permalink / raw)
To: Marcel Holtmann, Johan Hedberg
Cc: Linux Kernel Mailing List, Linux Next Mailing List,
Luiz Augusto von Dentz, Pauli Virtanen, Siwei Zhang
[-- Attachment #1: Type: text/plain, Size: 16223 bytes --]
Hi all,
Today's linux-next merge of the bluetooth tree got a conflict in:
net/bluetooth/hci_sync.c
between commit:
12917f591cea1 ("Bluetooth: hci_conn: Fix null ptr deref in hci_abort_conn()")
from the origin tree and commits:
76c2d047410ba ("Bluetooth: hci_conn: Fix null ptr deref in hci_abort_conn()")
73b6871b261f3 ("Bluetooth: hci_sync: remove unnecessary hci_conn_get in create_conn_sync")
423e5fc465eb1 ("Bluetooth: hci_sync: fix hci_conn_del() use in hci_le_create_conn_sync")
from the bluetooth tree.
I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging. You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.
diff --combined net/bluetooth/hci_sync.c
index c0b1fc293b496,7779d9d1663a4..0000000000000
--- a/net/bluetooth/hci_sync.c
+++ b/net/bluetooth/hci_sync.c
@@@ -860,32 -860,6 +860,6 @@@ void hci_cmd_sync_cancel_entry(struct h
}
EXPORT_SYMBOL(hci_cmd_sync_cancel_entry);
- /* Dequeue one HCI command entry:
- *
- * - Lookup and cancel first entry that matches.
- */
- bool hci_cmd_sync_dequeue_once(struct hci_dev *hdev,
- hci_cmd_sync_work_func_t func,
- void *data, hci_cmd_sync_work_destroy_t destroy)
- {
- struct hci_cmd_sync_work_entry *entry;
-
- mutex_lock(&hdev->cmd_sync_work_lock);
-
- entry = _hci_cmd_sync_lookup_entry(hdev, func, data, destroy);
- if (!entry) {
- mutex_unlock(&hdev->cmd_sync_work_lock);
- return false;
- }
-
- _hci_cmd_sync_cancel_entry(hdev, entry, -ECANCELED);
-
- mutex_unlock(&hdev->cmd_sync_work_lock);
-
- return true;
- }
- EXPORT_SYMBOL(hci_cmd_sync_dequeue_once);
-
/* Dequeue HCI command entry:
*
* - Lookup and cancel any entry that matches by function callback or data or
@@@ -1233,10 -1207,11 +1207,11 @@@ static int hci_set_adv_set_random_addr_
}
static int
- hci_set_ext_adv_params_sync(struct hci_dev *hdev, struct adv_info *adv,
+ hci_set_ext_adv_params_sync(struct hci_dev *hdev, u8 instance,
const struct hci_cp_le_set_ext_adv_params *cp,
struct hci_rp_le_set_ext_adv_params *rp)
{
+ struct adv_info *adv;
struct sk_buff *skb;
skb = __hci_cmd_sync(hdev, HCI_OP_LE_SET_EXT_ADV_PARAMS, sizeof(*cp),
@@@ -1264,11 -1239,15 +1239,15 @@@
if (!rp->status) {
hdev->adv_addr_type = cp->own_addr_type;
- if (!cp->handle) {
+ if (!instance) {
/* Store in hdev for instance 0 */
hdev->adv_tx_power = rp->tx_power;
- } else if (adv) {
- adv->tx_power = rp->tx_power;
+ } else {
+ hci_dev_lock(hdev);
+ adv = hci_find_adv_instance(hdev, instance);
+ if (adv)
+ adv->tx_power = rp->tx_power;
+ hci_dev_unlock(hdev);
}
}
@@@ -1284,9 -1263,13 +1263,13 @@@ static int hci_set_ext_adv_data_sync(st
int err;
if (instance) {
+ hci_dev_lock(hdev);
+
adv = hci_find_adv_instance(hdev, instance);
- if (!adv || !adv->adv_data_changed)
+ if (!adv || !adv->adv_data_changed) {
+ hci_dev_unlock(hdev);
return 0;
+ }
}
len = eir_create_adv_data(hdev, instance, pdu->data,
@@@ -1297,16 -1280,27 +1280,27 @@@
pdu->operation = LE_SET_ADV_DATA_OP_COMPLETE;
pdu->frag_pref = LE_SET_ADV_DATA_NO_FRAG;
+ if (adv) {
+ adv->adv_data_changed = false;
+ hci_dev_unlock(hdev);
+ }
+
err = __hci_cmd_sync_status(hdev, HCI_OP_LE_SET_EXT_ADV_DATA,
struct_size(pdu, data, len), pdu,
HCI_CMD_TIMEOUT);
- if (err)
- return err;
+ if (err) {
+ if (instance) {
+ hci_dev_lock(hdev);
+ adv = hci_find_adv_instance(hdev, instance);
+ if (adv)
+ adv->adv_data_changed = true;
+ hci_dev_unlock(hdev);
+ }
- /* Update data if the command succeed */
- if (adv) {
- adv->adv_data_changed = false;
- } else {
+ return err;
+ }
+
+ if (!instance) {
memcpy(hdev->adv_data, pdu->data, len);
hdev->adv_data_len = len;
}
@@@ -1360,22 -1354,22 +1354,22 @@@ int hci_setup_ext_adv_instance_sync(str
struct adv_info *adv;
bool secondary_adv;
- if (instance > 0) {
- adv = hci_find_adv_instance(hdev, instance);
- if (!adv)
- return -EINVAL;
- } else {
- adv = NULL;
- }
-
/* Updating parameters of an active instance will return a
- * Command Disallowed error, so we must first disable the
- * instance if it is active.
+ * Command Disallowed error, so disable it before taking a snapshot.
*/
- if (adv) {
+ if (instance > 0) {
err = hci_disable_ext_adv_instance_sync(hdev, instance);
if (err)
return err;
+
+ hci_dev_lock(hdev);
+ adv = hci_find_adv_instance(hdev, instance);
+ if (!adv) {
+ hci_dev_unlock(hdev);
+ return -EINVAL;
+ }
+ } else {
+ adv = NULL;
}
flags = hci_adv_instance_flags(hdev, instance);
@@@ -1386,8 -1380,11 +1380,11 @@@
connectable = (flags & MGMT_ADV_FLAG_CONNECTABLE) ||
mgmt_get_connectable(hdev);
- if (!is_advertising_allowed(hdev, connectable))
+ if (!is_advertising_allowed(hdev, connectable)) {
+ if (instance)
+ hci_dev_unlock(hdev);
return -EPERM;
+ }
/* Set require_privacy to true only when non-connectable
* advertising is used and it is not periodic.
@@@ -1398,8 -1395,11 +1395,11 @@@
err = hci_get_random_address(hdev, require_privacy,
adv_use_rpa(hdev, flags), adv,
&own_addr_type, &random_addr);
- if (err < 0)
+ if (err < 0) {
+ if (instance)
+ hci_dev_unlock(hdev);
return err;
+ }
memset(&cp, 0, sizeof(cp));
@@@ -1450,6 -1450,9 +1450,9 @@@
cp.channel_map = hdev->le_adv_channel_map;
cp.handle = adv ? adv->handle : instance;
+ if (instance)
+ hci_dev_unlock(hdev);
+
if (flags & MGMT_ADV_FLAG_SEC_2M) {
cp.primary_phy = HCI_ADV_PHY_1M;
cp.secondary_phy = HCI_ADV_PHY_2M;
@@@ -1462,12 -1465,12 +1465,12 @@@
cp.secondary_phy = HCI_ADV_PHY_1M;
}
- err = hci_set_ext_adv_params_sync(hdev, adv, &cp, &rp);
+ err = hci_set_ext_adv_params_sync(hdev, instance, &cp, &rp);
if (err)
return err;
/* Update adv data as tx power is known now */
- err = hci_set_ext_adv_data_sync(hdev, cp.handle);
+ err = hci_set_ext_adv_data_sync(hdev, instance);
if (err)
return err;
@@@ -1475,9 -1478,14 +1478,14 @@@
own_addr_type == ADDR_LE_DEV_RANDOM_RESOLVED) &&
bacmp(&random_addr, BDADDR_ANY)) {
/* Check if random address need to be updated */
- if (adv) {
- if (!bacmp(&random_addr, &adv->random_addr))
+ if (instance) {
+ hci_dev_lock(hdev);
+ adv = hci_find_adv_instance(hdev, instance);
+ if (!adv || !bacmp(&random_addr, &adv->random_addr)) {
+ hci_dev_unlock(hdev);
return 0;
+ }
+ hci_dev_unlock(hdev);
} else {
if (!bacmp(&random_addr, &hdev->random_addr))
return 0;
@@@ -1499,9 -1507,13 +1507,13 @@@ static int hci_set_ext_scan_rsp_data_sy
int err;
if (instance) {
+ hci_dev_lock(hdev);
+
adv = hci_find_adv_instance(hdev, instance);
- if (!adv || !adv->scan_rsp_changed)
+ if (!adv || !adv->scan_rsp_changed) {
+ hci_dev_unlock(hdev);
return 0;
+ }
}
len = eir_create_scan_rsp(hdev, instance, pdu->data);
@@@ -1511,15 -1523,27 +1523,27 @@@
pdu->operation = LE_SET_ADV_DATA_OP_COMPLETE;
pdu->frag_pref = LE_SET_ADV_DATA_NO_FRAG;
+ if (adv) {
+ adv->scan_rsp_changed = false;
+ hci_dev_unlock(hdev);
+ }
+
err = __hci_cmd_sync_status(hdev, HCI_OP_LE_SET_EXT_SCAN_RSP_DATA,
struct_size(pdu, data, len), pdu,
HCI_CMD_TIMEOUT);
- if (err)
- return err;
+ if (err) {
+ if (instance) {
+ hci_dev_lock(hdev);
+ adv = hci_find_adv_instance(hdev, instance);
+ if (adv)
+ adv->scan_rsp_changed = true;
+ hci_dev_unlock(hdev);
+ }
- if (adv) {
- adv->scan_rsp_changed = false;
- } else {
+ return err;
+ }
+
+ if (!instance) {
memcpy(hdev->scan_rsp_data, pdu->data, len);
hdev->scan_rsp_data_len = len;
}
@@@ -1534,8 -1558,14 +1558,14 @@@ static int __hci_set_scan_rsp_data_sync
memset(&cp, 0, sizeof(cp));
+ if (instance)
+ hci_dev_lock(hdev);
+
len = eir_create_scan_rsp(hdev, instance, cp.data);
+ if (instance)
+ hci_dev_unlock(hdev);
+
if (hdev->scan_rsp_data_len == len &&
!memcmp(cp.data, hdev->scan_rsp_data, len))
return 0;
@@@ -1670,9 -1700,13 +1700,13 @@@ static int hci_set_per_adv_data_sync(st
struct adv_info *adv = NULL;
if (instance) {
+ hci_dev_lock(hdev);
+
adv = hci_find_adv_instance(hdev, instance);
- if (!adv || !adv->periodic)
+ if (!adv || !adv->periodic) {
+ hci_dev_unlock(hdev);
return 0;
+ }
}
len = eir_create_per_adv_data(hdev, instance, pdu->data);
@@@ -1681,6 -1715,9 +1715,9 @@@
pdu->handle = adv ? adv->handle : instance;
pdu->operation = LE_SET_ADV_DATA_OP_COMPLETE;
+ if (adv)
+ hci_dev_unlock(hdev);
+
return __hci_cmd_sync_status(hdev, HCI_OP_LE_SET_PER_ADV_DATA,
struct_size(pdu, data, len), pdu,
HCI_CMD_TIMEOUT);
@@@ -3717,18 -3754,20 +3754,20 @@@ static const struct hci_init_stage hci_
int hci_reset_sync(struct hci_dev *hdev)
{
- int err;
-
set_bit(HCI_RESET, &hdev->flags);
- err = __hci_cmd_sync_status(hdev, HCI_OP_RESET, 0, NULL,
- HCI_CMD_TIMEOUT);
- if (err)
- return err;
-
- return 0;
+ return __hci_cmd_sync_status(hdev, HCI_OP_RESET, 0, NULL,
+ HCI_CMD_TIMEOUT);
}
+ /* Send a raw HCI reset for use by vendor drivers */
+ int __hci_reset_sync(struct hci_dev *hdev)
+ {
+ return __hci_cmd_sync_status(hdev, HCI_OP_RESET, 0, NULL,
+ HCI_INIT_TIMEOUT);
+ }
+ EXPORT_SYMBOL(__hci_reset_sync);
+
static int hci_init0_sync(struct hci_dev *hdev)
{
int err;
@@@ -6523,7 -6562,7 +6562,7 @@@ static int hci_le_ext_directed_advertis
if (err)
return err;
- err = hci_set_ext_adv_params_sync(hdev, NULL, &cp, &rp);
+ err = hci_set_ext_adv_params_sync(hdev, 0, &cp, &rp);
if (err)
return err;
@@@ -6678,11 -6717,6 +6717,11 @@@ static int hci_le_create_conn_sync(stru
bt_dev_dbg(hdev, "conn %p", conn);
+ /* Hold a reference so conn stays valid for the HCI_CONN_CREATE
+ * clear_bit() at done.
+ */
+ hci_conn_get(conn);
+
clear_bit(HCI_CONN_SCANNING, &conn->flags);
conn->state = BT_CONNECT;
@@@ -6694,8 -6728,9 +6733,9 @@@
if (hci_dev_test_flag(hdev, HCI_LE_SCAN) &&
hdev->le_scan_type == LE_SCAN_ACTIVE &&
!hci_dev_test_flag(hdev, HCI_LE_SIMULTANEOUS_ROLES)) {
- hci_conn_del(conn);
- hci_conn_put(conn);
+ conn->state = BT_OPEN;
+ hci_abort_conn_sync(hdev, conn,
+ HCI_ERROR_REJ_LIMITED_RESOURCES);
return -EBUSY;
}
@@@ -6793,7 -6828,6 +6833,7 @@@ done
/* Re-enable advertising after the connection attempt is finished. */
hci_resume_advertising_sync(hdev);
+ hci_conn_put(conn);
return err;
}
@@@ -7068,11 -7102,6 +7108,6 @@@ static int hci_acl_create_conn_sync(str
else
cp.role_switch = 0x00;
- /* Hold a reference so conn stays valid for the HCI_CONN_CREATE
- * clear_bit() below.
- */
- hci_conn_get(conn);
-
/* Mark create connection in flight so hci_cancel_connect_sync() can
* cancel it while blocking on the connection complete event.
*/
@@@ -7084,17 -7113,27 +7119,27 @@@
conn->conn_timeout, NULL);
clear_bit(HCI_CONN_CREATE, &conn->flags);
- hci_conn_put(conn);
return err;
}
+ static void hci_acl_create_conn_sync_complete(struct hci_dev *hdev, void *data,
+ int err)
+ {
+ struct hci_conn *conn = data;
+
+ hci_conn_put(conn);
+ }
+
int hci_connect_acl_sync(struct hci_dev *hdev, struct hci_conn *conn)
{
int err;
- err = hci_cmd_sync_queue_once(hdev, hci_acl_create_conn_sync, conn,
- NULL);
+ err = hci_cmd_sync_queue_once(hdev, hci_acl_create_conn_sync,
+ hci_conn_get(conn),
+ hci_acl_create_conn_sync_complete);
+ if (err)
+ hci_conn_put(conn);
return (err == -EEXIST) ? 0 : err;
}
@@@ -7105,36 -7144,41 +7150,41 @@@ static void create_le_conn_complete(str
bt_dev_dbg(hdev, "err %d", err);
if (err == -ECANCELED)
- return;
+ goto done;
hci_dev_lock(hdev);
if (!hci_conn_valid(hdev, conn))
- goto done;
+ goto unlock;
if (!err) {
hci_connect_le_scan_cleanup(conn, 0x00);
- goto done;
+ goto unlock;
}
/* Check if connection is still pending */
if (conn != hci_lookup_le_connect(hdev))
- goto done;
+ goto unlock;
/* Flush to make sure we send create conn cancel command if needed */
flush_delayed_work(&conn->le_conn_timeout);
hci_conn_failed(conn, bt_status(err));
- done:
+ unlock:
hci_dev_unlock(hdev);
+ done:
+ hci_conn_put(conn);
}
int hci_connect_le_sync(struct hci_dev *hdev, struct hci_conn *conn)
{
int err;
- err = hci_cmd_sync_queue_once(hdev, hci_le_create_conn_sync, conn,
+ err = hci_cmd_sync_queue_once(hdev, hci_le_create_conn_sync,
+ hci_conn_get(conn),
create_le_conn_complete);
+ if (err)
+ hci_conn_put(conn);
return (err == -EEXIST) ? 0 : err;
}
@@@ -7257,7 -7301,7 +7307,7 @@@ static void create_pa_complete(struct h
bt_dev_dbg(hdev, "err %d", err);
if (err == -ECANCELED)
- return;
+ goto done;
hci_dev_lock(hdev);
@@@ -7281,6 -7325,8 +7331,8 @@@
unlock:
hci_dev_unlock(hdev);
+ done:
+ hci_conn_put(conn);
}
static int hci_le_past_params_sync(struct hci_dev *hdev, struct hci_conn *conn,
@@@ -7431,8 -7477,11 +7483,11 @@@ int hci_connect_pa_sync(struct hci_dev
{
int err;
- err = hci_cmd_sync_queue_once(hdev, hci_le_pa_create_sync, conn,
+ err = hci_cmd_sync_queue_once(hdev, hci_le_pa_create_sync,
+ hci_conn_get(conn),
create_pa_complete);
+ if (err)
+ hci_conn_put(conn);
return (err == -EEXIST) ? 0 : err;
}
@@@ -7443,10 -7492,12 +7498,12 @@@ static void create_big_complete(struct
bt_dev_dbg(hdev, "err %d", err);
if (err == -ECANCELED)
- return;
+ goto done;
- if (hci_conn_valid(hdev, conn))
- clear_bit(HCI_CONN_CREATE_BIG_SYNC, &conn->flags);
+ clear_bit(HCI_CONN_CREATE_BIG_SYNC, &conn->flags);
+
+ done:
+ hci_conn_put(conn);
}
static int hci_le_big_create_sync(struct hci_dev *hdev, void *data)
@@@ -7498,8 -7549,14 +7555,14 @@@ int hci_connect_big_sync(struct hci_de
{
int err;
- err = hci_cmd_sync_queue_once(hdev, hci_le_big_create_sync, conn,
+ if (!conn)
+ return 0;
+
+ err = hci_cmd_sync_queue_once(hdev, hci_le_big_create_sync,
+ hci_conn_get(conn),
create_big_complete);
+ if (err)
+ hci_conn_put(conn);
return (err == -EEXIST) ? 0 : err;
}
@@@ -7514,6 -7571,8 +7577,8 @@@ static void past_complete(struct hci_de
bt_dev_dbg(hdev, "err %d", err);
+ hci_conn_put(past->conn);
+ hci_conn_put(past->le);
kfree(past);
}
@@@ -7578,8 -7637,8 +7643,8 @@@ int hci_past_sync(struct hci_conn *conn
if (!data)
return -ENOMEM;
- data->conn = conn;
- data->le = le;
+ data->conn = hci_conn_get(conn);
+ data->le = hci_conn_get(le);
if (conn->role == HCI_ROLE_MASTER)
err = hci_cmd_sync_queue_once(conn->hdev,
@@@ -7589,8 -7648,11 +7654,11 @@@
err = hci_cmd_sync_queue_once(conn->hdev, hci_le_past_sync,
data, past_complete);
- if (err)
+ if (err) {
+ hci_conn_put(data->conn);
+ hci_conn_put(data->le);
kfree(data);
+ }
return (err == -EEXIST) ? 0 : err;
}
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* Re: Policy regarding linux-next only changes
From: Mark Brown @ 2026-07-28 15:16 UTC (permalink / raw)
To: Tetsuo Handa
Cc: Leandro Ribeiro, Pekka Paalanen, Daniel Stone, Miguel Ojeda,
Theodore Tso, Alexander Potapenko, Christoph Hellwig,
Aleksandr Nogikh, Boqun Feng, Gary Guo, linux-next, linux-kernel,
Miguel Ojeda, Linus Torvalds, peterz, will, longman, mingo,
gregkh
In-Reply-To: <cba31f88-09f2-443f-ab0f-b2b263750947@I-love.SAKURA.ne.jp>
[-- Attachment #1: Type: text/plain, Size: 1589 bytes --]
On Tue, Jul 28, 2026 at 11:46:04PM +0900, Tetsuo Handa wrote:
> On 2026/07/28 2:39, Mark Brown wrote:
> > This really just looks like another case where you (or someone) need to
> > commuicate if something is urgent - I would have a hard time telling
> > from that thread that there's a particularly big problem, the only reply
> That commit says "Drivers triggering this warning must be fixed.". That is,
> they know that it is expected that WARN*() fires. But they don't know that
> syzbot stops upon encountering "BUG:" or "WARNING:" within printk() output.
Right, I think some of this is the difference between "needs to fix
this" and "needs to fix this right now" - WARN_ON()s obviously need to
be fixed, but it's not so obvious that it's a major disruption.
> They also don't know that syzbot builds-in almost all modules into vmlinux.
> That is, initialization functions of most modules are executed upon boot.
> If one of modules emits "BUG:" or "WARNING:" line, the boot fails.
Oh, that *is* surprising - more people tend towards heavily modular
kernels than fully built in ones, I suspect a lot of driver people won't
realise that they're impacting anyone who doesn't have the hardware
since it's not the norm.
> All new bugs which are introduced while syzbot is unable to update linux-next kernels
> are reported only after syzbot succeeded to update linux-next kernels. The "being unable
> to build or boot" caused by addition of WARN*() can break whole testing by syzbot.
Indeed. I'd suggest following up on the fix with this information to
try to chase things along.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* Re: Policy regarding linux-next only changes
From: Tetsuo Handa @ 2026-07-28 14:46 UTC (permalink / raw)
To: Mark Brown, Leandro Ribeiro, Pekka Paalanen, Daniel Stone
Cc: Miguel Ojeda, Theodore Tso, Alexander Potapenko,
Christoph Hellwig, Aleksandr Nogikh, Boqun Feng, Gary Guo,
linux-next, linux-kernel, Miguel Ojeda, Linus Torvalds, peterz,
will, longman, mingo, gregkh
In-Reply-To: <c7b9cce5-5d69-43db-91c6-10f6bcd07b68@sirena.org.uk>
On 2026/07/28 2:39, Mark Brown wrote:
>> For the latter example, syzbot is still using next-20260714 because a maintainer
>> who should accept/reject https://lkml.kernel.org/r/al1pElMQZsDfpAYI@michalis-linux
>> is not responding. As a result, syzbot is unable to test changes made between
>> next-20260714 and next-20260726.
>
> This really just looks like another case where you (or someone) need to
> commuicate if something is urgent - I would have a hard time telling
> from that thread that there's a particularly big problem, the only reply
> indicating any kind of problem with the posted patch (from Joshua) was
> then followed up saying to disrgard it and there's nothing at all at any
> point in the thread or original report about the scope of the issue or
> any practical impact it's having. Frankly I'm not clear that Michail
> (who posted the patch) is aware that there's any urgency here and isn't
> just acting reasonably and promptly on what was in the report mail.
This problem is caused by commit 860e748bddcc ("drm: ensure blend mode supported
if pixel format with alpha exposed") at
https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit?id=860e748bddcc9291cbdd23e801640aeeba30cc44 .
That commit says "Drivers triggering this warning must be fixed.". That is,
they know that it is expected that WARN*() fires. But they don't know that
syzbot stops upon encountering "BUG:" or "WARNING:" within printk() output.
They also don't know that syzbot builds-in almost all modules into vmlinux.
That is, initialization functions of most modules are executed upon boot.
If one of modules emits "BUG:" or "WARNING:" line, the boot fails.
Maintainers sometimes apply commits that cause some in-tree modules to emit
"BUG:" or "WARNING:" line, without having grace period for confirming that
all in-tree modules are updated/fixed. Such decision is annoying for syzbot.
>
> Even if someone were to click through the syzbot link the report is
> flagged as low priority in the dashboard and the config is just a link
> to a raw config so there's no indication if this is defconfig,
> randconfig or whatever. There's absolutely nothing in the sysbot
> dashboard or list report that indicates to me that this has any kind of
> impact beyond "a warning is displayed during boot".
That priority is determined based on how critical the bug is (e.g. use-after-free write).
Therefore, being unable to build or boot is considered low priority because it can't cause
e.g. use-after-free write. However, the real impact of "being unable to build or boot" is
indicated at https://syzkaller.appspot.com/upstream/manager/ci-upstream-linux-next-kasan-gce-root .
Currently syzbot is failing to update linux-next kernels for two weeks due to
commit 860e748bddcc being in the linux-next tree.
All new bugs which are introduced while syzbot is unable to update linux-next kernels
are reported only after syzbot succeeded to update linux-next kernels. The "being unable
to build or boot" caused by addition of WARN*() can break whole testing by syzbot.
^ permalink raw reply
* linux-next: build failure after merge of the vfs-brauner tree
From: Mark Brown @ 2026-07-28 13:45 UTC (permalink / raw)
To: Christian Brauner, Jan Kara
Cc: Linux Kernel Mailing List, Linux Next Mailing List
[-- Attachment #1: Type: text/plain, Size: 322 bytes --]
Hi all,
After merging the vfs-brauner tree, today's linux-next build (x86_64
allmodconfig) failed like this:
ERROR: modpost: "__inode_attach_wb" [fs/ext4/ext4.ko] undefined!
Caused by commit
c26339e1df335 (ext4: Fix data integrity writeout issues in nojournal mode)
I have used the tree from next-20260723 instead.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* Re: Unexpected files in the drm-rust tree
From: Danilo Krummrich @ 2026-07-28 13:06 UTC (permalink / raw)
To: Mark Brown; +Cc: Alice Ryhl, linux-kernel, linux-next
In-Reply-To: <amiode9ojm4agngI@sirena.org.uk>
Hi Mark,
On Tue Jul 28, 2026 at 3:02 PM CEST, Mark Brown wrote:
> Commit
>
> ac3baea883dab ("drm/panel: find_panel_by_fwnode() return a counted reference")
>
> added this unexpected file:
>
> drivers/gpu/drm/drm_panel.c.orig
this (and the other reported issues) originate from a backmerge of the DRM tree
into the DRM Rust tree. I've seen this issue has already been reported for the
trees it originates from and is being addressed there.
Thanks,
Danilo
^ permalink raw reply
* Unexpected files in the drm-rust tree
From: Mark Brown @ 2026-07-28 13:02 UTC (permalink / raw)
To: Alice Ryhl, Danilo Krummrich; +Cc: linux-kernel, linux-next
[-- Attachment #1: Type: text/plain, Size: 154 bytes --]
Commit
ac3baea883dab ("drm/panel: find_panel_by_fwnode() return a counted reference")
added this unexpected file:
drivers/gpu/drm/drm_panel.c.orig
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* Fixes tags need work in the drm-rust tree
From: Mark Brown @ 2026-07-28 13:02 UTC (permalink / raw)
To: Alice Ryhl, Danilo Krummrich; +Cc: linux-kernel, linux-next
[-- Attachment #1: Type: text/plain, Size: 312 bytes --]
In commit
0aeed866cb938 ("drm/amd/display: Fix dangling pointer in CRTC reset function")
Fixes tag
Fixes: e7b07ceef2a6 ("drm/amd/display: Merge amdgpu_dm_crtc and dm_crtc_state")
has these problem(s):
- Subject does not match target commit subject
Just use
git log -1 --format='Fixes: %h ("%s")'
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* Fixes tags need work in the drm-rust tree
From: Mark Brown @ 2026-07-28 13:02 UTC (permalink / raw)
To: Alice Ryhl, Danilo Krummrich; +Cc: linux-kernel, linux-next
[-- Attachment #1: Type: text/plain, Size: 317 bytes --]
In commit
3b1f4d5e47b36 ("drm/amd/display: Fix dangling pointer in connector reset function")
Fixes tag
Fixes: e7b07ceef2a6 ("drm/amd/display: Merge amdgpu_dm_crtc and dm_crtc_state")
has these problem(s):
- Subject does not match target commit subject
Just use
git log -1 --format='Fixes: %h ("%s")'
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* Re: linux-next: build failure after merge of the thunderbolt tree
From: Pan Chuang @ 2026-07-28 8:03 UTC (permalink / raw)
To: mika.westerberg; +Cc: broonie, linux-kernel, linux-next, panchuang
In-Reply-To: <20260728043537.GO2365036@black.igk.intel.com>
On 2026/7/28 12:35, Mika Westerberg wrote:
> On Mon, Jul 27, 2026 at 04:04:17PM +0100, Mark Brown wrote:
>> Hi all,
>>
>> After merging the thunderbolt tree, today's linux-next build (x86_64
>> allmodconfig) failed like this:
>>
>> /tmp/next/build/drivers/thunderbolt/pci.c:115:17: error: unused variable 'dev' [-Werror,-Wunused-variable]
>> 115 | struct device *dev = &pdev->dev;
>> | ^~~
>> 1 error generated. make[5]: ***
>>
>> Caused by commit
>>
>> eef9f6d8c36f7 (thunderbolt: Remove redundant dev_err_probe())
>>
>> I have used the tree from next-20260726 instead.
>
> Thanks for the report Mark. I've dropped that commit from my tree now.
>
> @Pan Chuang, please send an updated version where this variable is removed
> as well.
Sorry for the noise. The fix is ready and I'll send v2 in a moment.
Best Regards,
PanChuang
^ permalink raw reply
* [STATUS] next/master - 0d33d21e47d9dc66f91e44da3fc9220c74d93df7
From: KernelCI bot @ 2026-07-28 2:30 UTC (permalink / raw)
To: kernelci-results; +Cc: linux-next
Hello,
Status summary for next/master
Dashboard:
https://d.kernelci.org/c/next/master/0d33d21e47d9dc66f91e44da3fc9220c74d93df7/
giturl: https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git
branch: master
commit hash: 0d33d21e47d9dc66f91e44da3fc9220c74d93df7
origin: maestro
test start time: 2026-07-27 16:09:04.096000+00:00
Builds: 72 ✅ 2 ❌ 0 ⚠️
Boots: 160 ✅ 3 ❌ 0 ⚠️
Tests: 28872 ✅ 2453 ❌ 6648 ⚠️
### POSSIBLE REGRESSIONS
Hardware: bcm2837-rpi-3-b-plus
> Config: defconfig+lab-setup+kselftest
- Architecture/compiler: arm64/gcc-14
- kselftest.proc
last run: https://d.kernelci.org/test/maestro:6a679a3b798ea6c1ef7855cd
history: > ✅ > ❌ > ❌ > ❌
- kselftest.proc.proc_proc-self-map-files-001
last run: https://d.kernelci.org/test/maestro:6a67a86d798ea6c1ef78c67c
history: > ✅ > ❌ > ❌ > ❌
- kselftest.proc.proc_proc-self-map-files-002
last run: https://d.kernelci.org/test/maestro:6a67a86d798ea6c1ef78c67b
history: > ✅ > ❌ > ❌ > ❌
Hardware: imx8mp-evk
> Config: defconfig+lab-setup+kselftest
- Architecture/compiler: arm64/gcc-14
- kselftest.dt.dt_test_unprobed_devices_sh_sound-wm8960
last run: https://d.kernelci.org/test/maestro:6a679f58798ea6c1ef78ad4d
history: > ✅ > ✅ > ✅ > ✅ > ❌
Hardware: imx8mp-verdin-nonwifi-dahlia
> Config: defconfig+lab-setup+kselftest
- Architecture/compiler: arm64/gcc-14
- kselftest.dt.dt_test_unprobed_devices_sh_soc_0_bus_30800000_i2c_30a50000_eeprom_50
last run: https://d.kernelci.org/test/maestro:6a67a089798ea6c1ef78b426
history: > ✅ > ✅ > ❌
Hardware: k3-am625-verdin-wifi-mallow
> Config: defconfig+lab-setup+kselftest
- Architecture/compiler: arm64/gcc-14
- kselftest.dt
last run: https://d.kernelci.org/test/maestro:6a679a2c798ea6c1ef78554c
history: > ✅ > ❌ > ❌ > ❌ > ❌
Hardware: kaanapali-mtp
> Config: defconfig+lab-setup+kselftest
- Architecture/compiler: arm64/gcc-14
- kselftest.arm64
last run: https://d.kernelci.org/test/maestro:6a6799c1798ea6c1ef785261
history: > ✅ > ✅ > ✅ > ✅ > ❌
- kselftest.arm64.arm64_fp-stress
last run: https://d.kernelci.org/test/maestro:6a679ae4798ea6c1ef786484
history: > ✅ > ✅ > ✅ > ✅ > ❌
- kselftest.breakpoints
last run: https://d.kernelci.org/test/maestro:6a6799d1798ea6c1ef7852e0
history: > ✅ > ❌ > ❌
- kselftest.proc
last run: https://d.kernelci.org/test/maestro:6a679a38798ea6c1ef7855bb
history: > ✅ > ✅ > ❌ > ❌ > ❌
- kselftest.proc.proc_proc-self-map-files-001
last run: https://d.kernelci.org/test/maestro:6a67a02b798ea6c1ef78b047
history: > ✅ > ✅ > ❌ > ❌ > ❌
- kselftest.proc.proc_proc-self-map-files-002
last run: https://d.kernelci.org/test/maestro:6a67a02b798ea6c1ef78b046
history: > ✅ > ✅ > ❌ > ❌ > ❌
Hardware: lemans-evk
> Config: defconfig+lab-setup+kselftest
- Architecture/compiler: arm64/gcc-14
- kselftest.proc
last run: https://d.kernelci.org/test/maestro:6a679a39798ea6c1ef7855c1
history: > ✅ > ✅ > ❌ > ❌ > ❌
- kselftest.proc.proc_proc-self-map-files-001
last run: https://d.kernelci.org/test/maestro:6a67a2db798ea6c1ef78bcc2
history: > ✅ > ✅ > ❌ > ❌ > ❌
- kselftest.proc.proc_proc-self-map-files-002
last run: https://d.kernelci.org/test/maestro:6a67a2db798ea6c1ef78bcc1
history: > ✅ > ✅ > ❌ > ❌ > ❌
Hardware: qcs615-ride
> Config: defconfig+lab-setup+kselftest
- Architecture/compiler: arm64/gcc-14
- kselftest.proc
last run: https://d.kernelci.org/test/maestro:6a679a32798ea6c1ef785579
history: > ✅ > ✅ > ❌ > ❌ > ❌
- kselftest.proc.proc_proc-self-map-files-001
last run: https://d.kernelci.org/test/maestro:6a67a489798ea6c1ef78c134
history: > ✅ > ✅ > ❌ > ❌ > ❌
- kselftest.proc.proc_proc-self-map-files-002
last run: https://d.kernelci.org/test/maestro:6a67a489798ea6c1ef78c133
history: > ✅ > ✅ > ❌ > ❌ > ❌
Hardware: qcs6490-rb3gen2
> Config: defconfig+lab-setup+kselftest
- Architecture/compiler: arm64/gcc-14
- kselftest.device-error-logs
last run: https://d.kernelci.org/test/maestro:6a679a0c798ea6c1ef785453
history: > ✅ > ✅ > ❌ > ❌ > ❌
- kselftest.proc
last run: https://d.kernelci.org/test/maestro:6a679a33798ea6c1ef78557e
history: > ✅ > ✅ > ❌ > ❌ > ❌
- kselftest.proc.proc_proc-self-map-files-001
last run: https://d.kernelci.org/test/maestro:6a67a1f7798ea6c1ef78b9df
history: > ✅ > ✅ > ❌ > ❌ > ❌
- kselftest.proc.proc_proc-self-map-files-002
last run: https://d.kernelci.org/test/maestro:6a67a1f7798ea6c1ef78b9de
history: > ✅ > ✅ > ❌ > ❌ > ❌
Hardware: qcs8300-ride
> Config: defconfig+lab-setup+kselftest
- Architecture/compiler: arm64/gcc-14
- kselftest.device-error-logs
last run: https://d.kernelci.org/test/maestro:6a679a0e798ea6c1ef78545b
history: > ✅ > ❌ > ❌ > ❌ > ❌
- kselftest.proc
last run: https://d.kernelci.org/test/maestro:6a679a35798ea6c1ef785589
history: > ✅ > ✅ > ❌ > ❌ > ❌
- kselftest.proc.proc_proc-self-map-files-001
last run: https://d.kernelci.org/test/maestro:6a67a1ba798ea6c1ef78b9b5
history: > ✅ > ✅ > ❌ > ❌
- kselftest.proc.proc_proc-self-map-files-002
last run: https://d.kernelci.org/test/maestro:6a67a1ba798ea6c1ef78b9b4
history: > ✅ > ✅ > ❌ > ❌
Hardware: qcs9100-ride
> Config: defconfig+lab-setup+kselftest
- Architecture/compiler: arm64/gcc-14
- kselftest.dt.dt_test_unprobed_devices_sh_reboot-mode
last run: https://d.kernelci.org/test/maestro:6a67a279798ea6c1ef78bc6d
history: > ✅ > ✅ > ✅ > ✅ > ❌
- kselftest.dt.dt_test_unprobed_devices_sh_soc_0_clock-controller_abf0000
last run: https://d.kernelci.org/test/maestro:6a67a279798ea6c1ef78bc61
history: > ✅ > ✅ > ✅ > ✅ > ❌
- kselftest.dt.dt_test_unprobed_devices_sh_soc_0_clock-controller_ade0000
last run: https://d.kernelci.org/test/maestro:6a67a279798ea6c1ef78bc7d
history: > ✅ > ✅ > ✅ > ✅ > ❌
- kselftest.dt.dt_test_unprobed_devices_sh_soc_0_clock-controller_af00000
last run: https://d.kernelci.org/test/maestro:6a67a279798ea6c1ef78bc60
history: > ✅ > ✅ > ✅ > ✅ > ❌
- kselftest.dt.dt_test_unprobed_devices_sh_soc_0_display-subsystem_22000000
last run: https://d.kernelci.org/test/maestro:6a67a279798ea6c1ef78bc5a
history: > ✅ > ✅ > ✅ > ✅ > ❌
- kselftest.dt.dt_test_unprobed_devices_sh_soc_0_display-subsystem_22000000_display-controller_22001000
last run: https://d.kernelci.org/test/maestro:6a67a279798ea6c1ef78bc59
history: > ✅ > ✅ > ✅ > ✅ > ❌
- kselftest.dt.dt_test_unprobed_devices_sh_soc_0_display-subsystem_ae00000
last run: https://d.kernelci.org/test/maestro:6a67a279798ea6c1ef78bc54
history: > ✅ > ✅ > ✅ > ✅ > ❌
- kselftest.dt.dt_test_unprobed_devices_sh_soc_0_display-subsystem_ae00000_display-controller_ae01000
last run: https://d.kernelci.org/test/maestro:6a67a279798ea6c1ef78bc53
history: > ✅ > ✅ > ✅ > ✅ > ❌
- kselftest.dt.dt_test_unprobed_devices_sh_soc_0_display-subsystem_ae00000_dsi_ae94000
last run: https://d.kernelci.org/test/maestro:6a67a279798ea6c1ef78bc4e
history: > ✅ > ✅ > ✅ > ✅ > ❌
- kselftest.dt.dt_test_unprobed_devices_sh_soc_0_display-subsystem_ae00000_dsi_ae96000
last run: https://d.kernelci.org/test/maestro:6a67a279798ea6c1ef78bc4c
history: > ✅ > ✅ > ✅ > ✅ > ❌
- kselftest.dt.dt_test_unprobed_devices_sh_soc_0_display-subsystem_ae00000_phy_ae94400
last run: https://d.kernelci.org/test/maestro:6a67a279798ea6c1ef78bc4b
history: > ✅ > ✅ > ✅ > ✅ > ❌
- kselftest.dt.dt_test_unprobed_devices_sh_soc_0_display-subsystem_ae00000_phy_ae96400
last run: https://d.kernelci.org/test/maestro:6a67a279798ea6c1ef78bc4a
history: > ✅ > ✅ > ✅ > ✅ > ❌
- kselftest.dt.dt_test_unprobed_devices_sh_soc_0_ethernet_23000000
last run: https://d.kernelci.org/test/maestro:6a67a279798ea6c1ef78bc45
history: > ✅ > ✅ > ✅ > ✅ > ❌
- kselftest.dt.dt_test_unprobed_devices_sh_soc_0_ethernet_23040000
last run: https://d.kernelci.org/test/maestro:6a67a279798ea6c1ef78bc44
history: > ✅ > ✅ > ✅ > ✅ > ❌
- kselftest.dt.dt_test_unprobed_devices_sh_soc_0_geniqup_8c0000_i2c_890000
last run: https://d.kernelci.org/test/maestro:6a67a279798ea6c1ef78bc2f
history: > ✅ > ✅ > ✅ > ✅ > ❌
- kselftest.dt.dt_test_unprobed_devices_sh_soc_0_geniqup_8c0000_i2c_890000_gpio_74
last run: https://d.kernelci.org/test/maestro:6a67a279798ea6c1ef78bc2e
history: > ✅ > ✅ > ✅ > ✅ > ❌
- kselftest.dt.dt_test_unprobed_devices_sh_soc_0_geniqup_8c0000_i2c_890000_i2c-mux_70
last run: https://d.kernelci.org/test/maestro:6a67a279798ea6c1ef78bc2d
history: > ✅ > ✅ > ✅ > ✅ > ❌
- kselftest.dt.dt_test_unprobed_devices_sh_soc_0_geniqup_8c0000_i2c_890000_i2c-mux_70_i2c_0_bridge_58
last run: https://d.kernelci.org/test/maestro:6a67a279798ea6c1ef78bc2c
history: > ✅ > ✅ > ✅ > ✅ > ❌
- kselftest.dt.dt_test_unprobed_devices_sh_soc_0_geniqup_8c0000_i2c_890000_i2c-mux_70_i2c_1_bridge_58
last run: https://d.kernelci.org/test/maestro:6a67a279798ea6c1ef78bc2b
history: > ✅ > ✅ > ✅ > ✅ > ❌
- kselftest.dt.dt_test_unprobed_devices_sh_soc_0_geniqup_8c0000_serial_88c000_bluetooth
last run: https://d.kernelci.org/test/maestro:6a67a279798ea6c1ef78bc29
history: > ✅ > ✅ > ✅ > ✅ > ❌
- kselftest.dt.dt_test_unprobed_devices_sh_soc_0_geniqup_ac0000_i2c_a90000
last run: https://d.kernelci.org/test/maestro:6a67a279798ea6c1ef78bc26
history: > ✅ > ✅ > ✅ > ✅ > ❌
- kselftest.dt.dt_test_unprobed_devices_sh_soc_0_gpu_3d00000
last run: https://d.kernelci.org/test/maestro:6a67a279798ea6c1ef78bc21
history: > ✅ > ✅ > ✅ > ✅ > ❌
- kselftest.dt.dt_test_unprobed_devices_sh_soc_0_pcie_1c00000
last run: https://d.kernelci.org/test/maestro:6a67a279798ea6c1ef78bc0a
history: > ✅ > ✅ > ✅ > ✅ > ❌
- kselftest.dt.dt_test_unprobed_devices_sh_soc_0_pcie_1c00000_pcie_0
last run: https://d.kernelci.org/test/maestro:6a67a279798ea6c1ef78bc09
history: > ✅ > ✅ > ✅ > ✅ > ❌
- kselftest.dt.dt_test_unprobed_devices_sh_soc_0_pcie_1c00000_pcie_0_wifi_0
last run: https://d.kernelci.org/test/maestro:6a67a279798ea6c1ef78bc08
history: > ✅ > ✅ > ✅ > ✅ > ❌
- kselftest.dt.dt_test_unprobed_devices_sh_soc_0_remoteproc_20c00000
last run: https://d.kernelci.org/test/maestro:6a67a279798ea6c1ef78bbf5
history: > ✅ > ✅ > ✅ > ✅ > ❌
- kselftest.dt.dt_test_unprobed_devices_sh_soc_0_remoteproc_21c00000
last run: https://d.kernelci.org/test/maestro:6a67a279798ea6c1ef78bbf0
history: > ✅ > ✅ > ✅ > ✅ > ❌
- kselftest.dt.dt_test_unprobed_devices_sh_soc_0_remoteproc_26300000
last run: https://d.kernelci.org/test/maestro:6a67a279798ea6c1ef78bbeb
history: > ✅ > ✅ > ✅ > ✅ > ❌
- kselftest.dt.dt_test_unprobed_devices_sh_soc_0_remoteproc_2a300000
last run: https://d.kernelci.org/test/maestro:6a67a279798ea6c1ef78bbdf
history: > ✅ > ✅ > ✅ > ✅ > ❌
- kselftest.dt.dt_test_unprobed_devices_sh_soc_0_remoteproc_30000000
last run: https://d.kernelci.org/test/maestro:6a67a279798ea6c1ef78bbd0
history: > ✅ > ✅ > ✅ > ✅ > ❌
- kselftest.dt.dt_test_unprobed_devices_sh_soc_0_spmi_c440000_pmic_0_nvram_7100
last run: https://d.kernelci.org/test/maestro:6a67a279798ea6c1ef78bbb6
history: > ✅ > ✅ > ✅ > ✅ > ❌
- kselftest.dt.dt_test_unprobed_devices_sh_soc_0_spmi_c440000_pmic_0_pon_1200
last run: https://d.kernelci.org/test/maestro:6a67a279798ea6c1ef78bbb5
history: > ✅ > ✅ > ✅ > ✅ > ❌
- kselftest.dt.dt_test_unprobed_devices_sh_soc_0_spmi_c440000_pmic_0_pon_1200_pwrkey
last run: https://d.kernelci.org/test/maestro:6a67a279798ea6c1ef78bbb4
history: > ✅ > ✅ > ✅ > ✅ > ❌
- kselftest.dt.dt_test_unprobed_devices_sh_soc_0_spmi_c440000_pmic_0_pon_1200_resin
last run: https://d.kernelci.org/test/maestro:6a67a279798ea6c1ef78bbb3
history: > ✅ > ✅ > ✅ > ✅ > ❌
- kselftest.dt.dt_test_unprobed_devices_sh_soc_0_spmi_c440000_pmic_0_rtc_6100
last run: https://d.kernelci.org/test/maestro:6a67a279798ea6c1ef78bbb2
history: > ✅ > ✅ > ✅ > ✅ > ❌
- kselftest.dt.dt_test_unprobed_devices_sh_soc_0_spmi_c440000_pmic_0_temp-alarm_a00
last run: https://d.kernelci.org/test/maestro:6a67a279798ea6c1ef78bbb1
history: > ✅ > ✅ > ✅ > ✅ > ❌
- kselftest.dt.dt_test_unprobed_devices_sh_soc_0_spmi_c440000_pmic_2_temp-alarm_a00
last run: https://d.kernelci.org/test/maestro:6a67a279798ea6c1ef78bbae
history: > ✅ > ✅ > ✅ > ✅ > ❌
- kselftest.dt.dt_test_unprobed_devices_sh_soc_0_spmi_c440000_pmic_4_temp-alarm_a00
last run: https://d.kernelci.org/test/maestro:6a67a279798ea6c1ef78bbab
history: > ✅ > ✅ > ✅ > ✅ > ❌
- kselftest.dt.dt_test_unprobed_devices_sh_soc_0_spmi_c440000_pmic_6_temp-alarm_a00
last run: https://d.kernelci.org/test/maestro:6a67a279798ea6c1ef78bba8
history: > ✅ > ✅ > ✅ > ✅ > ❌
- kselftest.dt.dt_test_unprobed_devices_sh_soc_0_sram_c3f0000
last run: https://d.kernelci.org/test/maestro:6a67a279798ea6c1ef78bba5
history: > ✅ > ✅ > ✅ > ✅ > ❌
- kselftest.dt.dt_test_unprobed_devices_sh_soc_0_system-cache-controller_9200000
last run: https://d.kernelci.org/test/maestro:6a67a279798ea6c1ef78bba2
history: > ✅ > ✅ > ✅ > ❌
- kselftest.dt.dt_test_unprobed_devices_sh_soc_0_video-codec_aa00000
last run: https://d.kernelci.org/test/maestro:6a67a279798ea6c1ef78bb86
history: > ✅ > ✅ > ✅ > ✅ > ❌
- kselftest.dt.dt_test_unprobed_devices_sh_wcn6855-pmu
last run: https://d.kernelci.org/test/maestro:6a67a279798ea6c1ef78bb7a
history: > ✅ > ✅ > ✅ > ✅ > ❌
- kselftest.proc
last run: https://d.kernelci.org/test/maestro:6a679a36798ea6c1ef78558f
history: > ✅ > ✅ > ❌ > ❌ > ❌
- kselftest.proc.proc_proc-self-map-files-001
last run: https://d.kernelci.org/test/maestro:6a67a504798ea6c1ef78c28a
history: > ✅ > ✅ > ❌ > ❌ > ❌
- kselftest.proc.proc_proc-self-map-files-002
last run: https://d.kernelci.org/test/maestro:6a67a504798ea6c1ef78c289
history: > ✅ > ✅ > ❌ > ❌ > ❌
Hardware: sm8750-mtp
> Config: defconfig+lab-setup+kselftest
- Architecture/compiler: arm64/gcc-14
- kselftest.proc
last run: https://d.kernelci.org/test/maestro:6a679a37798ea6c1ef7855b5
history: > ✅ > ✅ > ❌ > ❌ > ❌
- kselftest.proc.proc_proc-self-map-files-001
last run: https://d.kernelci.org/test/maestro:6a679f31798ea6c1ef78acbb
history: > ✅ > ✅ > ❌ > ❌ > ❌
- kselftest.proc.proc_proc-self-map-files-002
last run: https://d.kernelci.org/test/maestro:6a679f31798ea6c1ef78acba
history: > ✅ > ✅ > ❌ > ❌ > ❌
### FIXED REGRESSIONS
Hardware: lemans-evk
> Config: defconfig+lab-setup+kselftest
- Architecture/compiler: arm64/gcc-14
- kselftest.dt.dt_test_unprobed_devices_sh_soc_0_geniqup_8c0000_spi_888000
last run: https://d.kernelci.org/test/maestro:6a67a1a6798ea6c1ef78b8e9
history: > ❌ > ❌ > ❌ > ✅
Hardware: qcs615-ride
> Config: defconfig+lab-setup+kselftest
- Architecture/compiler: arm64/gcc-14
- kselftest.futex
last run: https://d.kernelci.org/test/maestro:6a679a24798ea6c1ef785525
history: > ❌ > ✅ > ✅ > ✅
> Config: defconfig+arm64-chromebook+kselftest
- Architecture/compiler: arm64/gcc-14
- kselftest.efivars
last run: https://d.kernelci.org/test/maestro:6a679ca8798ea6c1ef789cf7
history: > ❌ > ❌ > ❌ > ❌ > ✅
- kselftest.ring-buffer
last run: https://d.kernelci.org/test/maestro:6a679d11798ea6c1ef78a4d8
history: > ❌ > ❌ > ❌ > ✅
Hardware: qcs8300-ride
> Config: defconfig+lab-setup+kselftest
- Architecture/compiler: arm64/gcc-14
- kselftest.dt.dt_test_unprobed_devices_sh_soc_0_display-subsystem_ae00000
last run: https://d.kernelci.org/test/maestro:6a67a0a4798ea6c1ef78b604
history: > ❌ > ✅ > ✅ > ✅
- kselftest.dt.dt_test_unprobed_devices_sh_soc_0_display-subsystem_ae00000_phy_ae94400
last run: https://d.kernelci.org/test/maestro:6a67a0a4798ea6c1ef78b5fd
history: > ❌ > ✅ > ✅ > ✅
- kselftest.dt.dt_test_unprobed_devices_sh_soc_0_display-subsystem_ae00000_phy_aec2a00
last run: https://d.kernelci.org/test/maestro:6a67a0a4798ea6c1ef78b5fc
history: > ❌ > ✅ > ✅ > ✅
- kselftest.dt.dt_test_unprobed_devices_sh_soc_0_geniqup_9c0000_serial_988000_bluetooth
last run: https://d.kernelci.org/test/maestro:6a67a0a4798ea6c1ef78b5dc
history: > ❌ > ✅ > ✅ > ✅
- kselftest.dt.dt_test_unprobed_devices_sh_soc_0_gpu_3d00000
last run: https://d.kernelci.org/test/maestro:6a67a0a4798ea6c1ef78b5d3
history: > ❌ > ✅ > ✅ > ✅
- kselftest.dt.dt_test_unprobed_devices_sh_soc_0_remoteproc_20c00000
last run: https://d.kernelci.org/test/maestro:6a67a0a4798ea6c1ef78b5a8
history: > ❌ > ✅ > ✅ > ✅
- kselftest.dt.dt_test_unprobed_devices_sh_soc_0_video-codec_aa00000
last run: https://d.kernelci.org/test/maestro:6a67a0a4798ea6c1ef78b549
history: > ❌ > ✅ > ✅ > ✅
Hardware: qcs9100-ride
> Config: defconfig+lab-setup+kselftest
- Architecture/compiler: arm64/gcc-14
- kselftest.devices-probe
last run: https://d.kernelci.org/test/maestro:6a679a84798ea6c1ef785705
history: > ❌ > ❌ > ❌ > ❌ > ✅
- kselftest.exec
last run: https://d.kernelci.org/test/maestro:6a679aa3798ea6c1ef78581e
history: > ❌ > ❌ > ❌ > ❌ > ✅
### UNSTABLE TESTS
Hardware: imx8mp-evk
> Config: defconfig+lab-setup+kselftest
- Architecture/compiler: arm64/gcc-14
- kselftest.alsa.alsa_mixer-test_event_spurious_wm8960audio_59
last run: https://d.kernelci.org/test/maestro:6a679be2798ea6c1ef788ae8
history: > ✅ > ❌ > ✅ > ✅
- kselftest.alsa.alsa_mixer-test_event_spurious_wm8960audio_62
last run: https://d.kernelci.org/test/maestro:6a679be2798ea6c1ef788afd
history: > ✅ > ❌ > ✅ > ✅
- kselftest.alsa.alsa_mixer-test_name_wm8960audio_61
last run: https://d.kernelci.org/test/maestro:6a679be2798ea6c1ef788afb
history: > ❌ > ✅ > ❌ > ❌
- kselftest.alsa.alsa_mixer-test_name_wm8960audio_62
last run: https://d.kernelci.org/test/maestro:6a679be2798ea6c1ef788b02
history: > ❌ > ✅ > ❌ > ❌
- kselftest.alsa.alsa_mixer-test_name_wm8960audio_63
last run: https://d.kernelci.org/test/maestro:6a679be2798ea6c1ef788b09
history: > ❌ > ✅ > ❌ > ❌
- kselftest.alsa.alsa_mixer-test_name_wm8960audio_64
last run: https://d.kernelci.org/test/maestro:6a679be2798ea6c1ef788b10
history: > ❌ > ✅ > ❌ > ❌
- kselftest.alsa.alsa_mixer-test_write_default_wm8960audio_70
last run: https://d.kernelci.org/test/maestro:6a679be2798ea6c1ef788b39
history: > ❌ > ✅ > ❌ > ❌
- kselftest.alsa.alsa_mixer-test_write_default_wm8960audio_72
last run: https://d.kernelci.org/test/maestro:6a679be2798ea6c1ef788b47
history: > ❌ > ✅ > ❌ > ❌
- kselftest.alsa.alsa_mixer-test_write_invalid_wm8960audio_69
last run: https://d.kernelci.org/test/maestro:6a679be2798ea6c1ef788b30
history: > ⚠️ > ✅ > ⚠️ > ⚠️
- kselftest.alsa.alsa_mixer-test_write_invalid_wm8960audio_70
last run: https://d.kernelci.org/test/maestro:6a679be2798ea6c1ef788b37
history: > ⚠️ > ✅ > ⚠️ > ⚠️
- kselftest.alsa.alsa_mixer-test_write_invalid_wm8960audio_71
last run: https://d.kernelci.org/test/maestro:6a679be2798ea6c1ef788b3e
history: > ⚠️ > ✅ > ⚠️ > ⚠️
- kselftest.alsa.alsa_mixer-test_write_invalid_wm8960audio_72
last run: https://d.kernelci.org/test/maestro:6a679be2798ea6c1ef788b45
history: > ⚠️ > ✅ > ⚠️ > ⚠️
- kselftest.alsa.alsa_mixer-test_write_valid_wm8960audio_69
last run: https://d.kernelci.org/test/maestro:6a679be2798ea6c1ef788b31
history: > ⚠️ > ✅ > ⚠️ > ⚠️
- kselftest.alsa.alsa_mixer-test_write_valid_wm8960audio_70
last run: https://d.kernelci.org/test/maestro:6a679be2798ea6c1ef788b38
history: > ⚠️ > ✅ > ⚠️ > ⚠️
- kselftest.alsa.alsa_mixer-test_write_valid_wm8960audio_71
last run: https://d.kernelci.org/test/maestro:6a679be2798ea6c1ef788b3f
history: > ⚠️ > ✅ > ⚠️ > ⚠️
- kselftest.alsa.alsa_mixer-test_write_valid_wm8960audio_72
last run: https://d.kernelci.org/test/maestro:6a679be2798ea6c1ef788b46
history: > ⚠️ > ✅ > ⚠️ > ⚠️
Hardware: lemans-evk
> Config: defconfig+lab-setup+kselftest
- Architecture/compiler: arm64/gcc-14
- kselftest.arm64
last run: https://d.kernelci.org/test/maestro:6a6799c3798ea6c1ef785267
history: > ✅ > ✅ > ❌ > ✅ > ❌
- kselftest.arm64.arm64_fp-stress
last run: https://d.kernelci.org/test/maestro:6a679c08798ea6c1ef789616
history: > ✅ > ✅ > ❌ > ✅ > ❌
- kselftest.devices-exist
last run: https://d.kernelci.org/test/maestro:6a679a6e798ea6c1ef7856bf
history: > ❌ > ❌ > ❌ > ✅ > ❌
- kselftest.devices-probe
last run: https://d.kernelci.org/test/maestro:6a679a7d798ea6c1ef7856f3
history: > ✅ > ❌ > ❌ > ❌ > ✅
- kselftest.dt.dt_test_unprobed_devices_sh_soc_0_display-subsystem_ae00000_displayport-controller_af54000
last run: https://d.kernelci.org/test/maestro:6a67a1a6798ea6c1ef78b913
history: > ✅ > ✅ > ❌ > ✅
- kselftest.dt.dt_test_unprobed_devices_sh_soc_0_display-subsystem_ae00000_displayport-controller_af5c000
last run: https://d.kernelci.org/test/maestro:6a67a1a6798ea6c1ef78b911
history: > ✅ > ✅ > ❌ > ✅
- kselftest.dt.dt_test_unprobed_devices_sh_soc_0_display-subsystem_ae00000_phy_aec2a00
last run: https://d.kernelci.org/test/maestro:6a67a1a6798ea6c1ef78b910
history: > ✅ > ✅ > ❌ > ✅
- kselftest.dt.dt_test_unprobed_devices_sh_soc_0_display-subsystem_ae00000_phy_aec5a00
last run: https://d.kernelci.org/test/maestro:6a67a1a6798ea6c1ef78b90f
history: > ✅ > ✅ > ❌ > ✅
- kselftest.dt.dt_test_unprobed_devices_sh_soc_0_ethernet_23040000
last run: https://d.kernelci.org/test/maestro:6a67a1a6798ea6c1ef78b909
history: > ✅ > ✅ > ❌ > ✅
- kselftest.dt.dt_test_unprobed_devices_sh_soc_0_ethernet_23040000_mdio_ethernet-phy_1c
last run: https://d.kernelci.org/test/maestro:6a67a1a6798ea6c1ef78b907
history: > ✅ > ✅ > ⚠️ > ✅
- kselftest.dt.dt_test_unprobed_devices_sh_soc_0_geniqup_8c0000_i2c_890000_eeprom_50
last run: https://d.kernelci.org/test/maestro:6a67a1a6798ea6c1ef78b8f3
history: > ✅ > ✅ > ❌ > ✅
- kselftest.dt.dt_test_unprobed_devices_sh_soc_0_geniqup_8c0000_i2c_890000_eeprom_50_nvmem-layout
last run: https://d.kernelci.org/test/maestro:6a67a1a6798ea6c1ef78b8f2
history: > ✅ > ✅ > ❌ > ✅
- kselftest.dt.dt_test_unprobed_devices_sh_soc_0_geniqup_8c0000_serial_88c000_bluetooth
last run: https://d.kernelci.org/test/maestro:6a67a1a6798ea6c1ef78b8ea
history: > ✅ > ✅ > ❌ > ✅
- kselftest.dt.dt_test_unprobed_devices_sh_soc_0_usb_a800000_hub_2
last run: https://d.kernelci.org/test/maestro:6a67a1a6798ea6c1ef78b844
history: > ✅ > ✅ > ✅ > ⚠️
- kselftest.dt.dt_test_unprobed_devices_sh_soc_0_video-codec_aa00000
last run: https://d.kernelci.org/test/maestro:6a67a1a6798ea6c1ef78b843
history: > ✅ > ✅ > ❌ > ✅
- kselftest.timers.timers_inconsistency-check_CLOCK_BOOTTIME_ALARM
last run: https://d.kernelci.org/test/maestro:6a67a4ec798ea6c1ef78c22e
history: > ✅ > ✅ > ✅ > ⚠️ > ✅
- kselftest.timers.timers_inconsistency-check_CLOCK_REALTIME_ALARM
last run: https://d.kernelci.org/test/maestro:6a67a4ec798ea6c1ef78c22f
history: > ✅ > ✅ > ✅ > ⚠️ > ✅
- kselftest.timers.timers_nanosleep_CLOCK_BOOTTIME_ALARM
last run: https://d.kernelci.org/test/maestro:6a67a4ec798ea6c1ef78c247
history: > ✅ > ✅ > ✅ > ⚠️ > ✅
- kselftest.timers.timers_nanosleep_CLOCK_REALTIME_ALARM
last run: https://d.kernelci.org/test/maestro:6a67a4ec798ea6c1ef78c248
history: > ✅ > ✅ > ✅ > ⚠️ > ✅
- kselftest.timers.timers_nsleep-lat_CLOCK_BOOTTIME_ALARM
last run: https://d.kernelci.org/test/maestro:6a67a4ec798ea6c1ef78c23c
history: > ✅ > ✅ > ✅ > ⚠️ > ✅
- kselftest.timers.timers_nsleep-lat_CLOCK_REALTIME_ALARM
last run: https://d.kernelci.org/test/maestro:6a67a4ec798ea6c1ef78c23d
history: > ✅ > ✅ > ✅ > ⚠️ > ✅
Hardware: meson-g12b-a311d-khadas-vim3
> Config: defconfig+preempt_rt
- Architecture/compiler: arm64/gcc-14
- rt-tests.rt-migrate-test
last run: https://d.kernelci.org/test/maestro:6a67aa6d798ea6c1ef78cb13
history: > ❌ > ✅ > ✅ > ❌ > ❌
- rt-tests.rt-migrate-test.rt-migrate-test
last run: https://d.kernelci.org/test/maestro:6a67ab14798ea6c1ef78cd86
history: > ❌ > ✅ > ✅ > ❌ > ❌
Hardware: qcs615-ride
> Config: defconfig+lab-setup+kselftest
- Architecture/compiler: arm64/gcc-14
- kselftest.arm64
last run: https://d.kernelci.org/test/maestro:6a6799bc798ea6c1ef785243
history: > ✅ > ❌ > ✅ > ✅ > ✅
- kselftest.arm64.arm64_fp-stress
last run: https://d.kernelci.org/test/maestro:6a679bf4798ea6c1ef789123
history: > ✅ > ❌ > ✅ > ✅ > ✅
- kselftest.breakpoints
last run: https://d.kernelci.org/test/maestro:6a6799cb798ea6c1ef7852b1
history: > ❌ > ❌ > ✅ > ❌ > ❌
- kselftest.breakpoints.breakpoints_step_after_suspend_test
last run: https://d.kernelci.org/test/maestro:6a679d31798ea6c1ef78a6eb
history: > ❌ > ❌ > ✅ > ❌ > ❌
- kselftest.futex.futex_run_sh_global_requeue_multiple
last run: https://d.kernelci.org/test/maestro:6a67a389798ea6c1ef78bd4a
history: > ✅ > ❌ > ✅ > ✅
Hardware: qcs6490-rb3gen2
> Config: defconfig+lab-setup+kselftest
- Architecture/compiler: arm64/gcc-14
- kselftest.coredump
last run: https://d.kernelci.org/test/maestro:6a6799f9798ea6c1ef7853cb
history: > ❌ > ✅ > ❌ > ❌ > ❌
- kselftest.dt.dt_test_unprobed_devices_sh_reboot-mode
last run: https://d.kernelci.org/test/maestro:6a67a01d798ea6c1ef78b003
history: > ✅ > ❌ > ✅ > ✅ > ✅
- kselftest.dt.dt_test_unprobed_devices_sh_soc_0_display-subsystem_ae00000_edp_aea0000
last run: https://d.kernelci.org/test/maestro:6a67a01d798ea6c1ef78afdc
history: > ✅ > ❌ > ✅ > ✅
- kselftest.dt.dt_test_unprobed_devices_sh_soc_0_display-subsystem_ae00000_phy_aec2a00
last run: https://d.kernelci.org/test/maestro:6a67a01d798ea6c1ef78afd9
history: > ✅ > ❌ > ✅ > ✅ > ✅
- kselftest.dt.dt_test_unprobed_devices_sh_soc_0_geniqup_9c0000_serial_99c000_bluetooth
last run: https://d.kernelci.org/test/maestro:6a67a01c798ea6c1ef78afbb
history: > ✅ > ❌ > ✅ > ✅ > ✅
- kselftest.dt.dt_test_unprobed_devices_sh_soc_0_phy_88e8000
last run: https://d.kernelci.org/test/maestro:6a67a01c798ea6c1ef78af97
history: > ✅ > ❌ > ✅ > ✅ > ✅
- kselftest.dt.dt_test_unprobed_devices_sh_soc_0_spmi_c440000_pmic_0_adc_3100
last run: https://d.kernelci.org/test/maestro:6a67a01c798ea6c1ef78af62
history: > ✅ > ❌ > ✅ > ✅ > ✅
- kselftest.dt.dt_test_unprobed_devices_sh_soc_0_spmi_c440000_pmic_0_adc-tm_3400
last run: https://d.kernelci.org/test/maestro:6a67a01c798ea6c1ef78af63
history: > ✅ > ❌ > ✅ > ✅ > ✅
- kselftest.dt.dt_test_unprobed_devices_sh_soc_0_spmi_c440000_pmic_0_nvram_7000
last run: https://d.kernelci.org/test/maestro:6a67a01c798ea6c1ef78af60
history: > ✅ > ❌ > ✅ > ✅ > ✅
- kselftest.dt.dt_test_unprobed_devices_sh_soc_0_spmi_c440000_pmic_0_nvram_7100
last run: https://d.kernelci.org/test/maestro:6a67a01c798ea6c1ef78af5f
history: > ✅ > ❌ > ✅ > ✅ > ✅
- kselftest.dt.dt_test_unprobed_devices_sh_soc_0_spmi_c440000_pmic_0_nvram_7400
last run: https://d.kernelci.org/test/maestro:6a67a01c798ea6c1ef78af5e
history: > ✅ > ❌ > ✅ > ✅ > ✅
- kselftest.dt.dt_test_unprobed_devices_sh_soc_0_spmi_c440000_pmic_0_nvram_7c00
last run: https://d.kernelci.org/test/maestro:6a67a01c798ea6c1ef78af5d
history: > ✅ > ❌ > ✅ > ✅ > ✅
- kselftest.dt.dt_test_unprobed_devices_sh_soc_0_spmi_c440000_pmic_0_nvram_7d00
last run: https://d.kernelci.org/test/maestro:6a67a01c798ea6c1ef78af5c
history: > ✅ > ❌ > ✅ > ✅ > ✅
- kselftest.dt.dt_test_unprobed_devices_sh_soc_0_spmi_c440000_pmic_0_nvram_8400
last run: https://d.kernelci.org/test/maestro:6a67a01c798ea6c1ef78af5b
history: > ✅ > ❌ > ✅ > ✅ > ✅
- kselftest.dt.dt_test_unprobed_devices_sh_soc_0_spmi_c440000_pmic_0_nvram_8500
last run: https://d.kernelci.org/test/maestro:6a67a01c798ea6c1ef78af5a
history: > ✅ > ❌ > ✅ > ✅ > ✅
- kselftest.dt.dt_test_unprobed_devices_sh_soc_0_spmi_c440000_pmic_0_nvram_8600
last run: https://d.kernelci.org/test/maestro:6a67a01c798ea6c1ef78af59
history: > ✅ > ❌ > ✅ > ✅ > ✅
- kselftest.dt.dt_test_unprobed_devices_sh_soc_0_spmi_c440000_pmic_0_nvram_9800
last run: https://d.kernelci.org/test/maestro:6a67a01c798ea6c1ef78af58
history: > ✅ > ❌ > ✅ > ✅ > ✅
- kselftest.dt.dt_test_unprobed_devices_sh_soc_0_spmi_c440000_pmic_0_nvram_9d00
last run: https://d.kernelci.org/test/maestro:6a67a01c798ea6c1ef78af57
history: > ✅ > ❌ > ✅ > ✅ > ✅
- kselftest.dt.dt_test_unprobed_devices_sh_soc_0_spmi_c440000_pmic_0_pon_1300
last run: https://d.kernelci.org/test/maestro:6a67a01c798ea6c1ef78af56
history: > ✅ > ❌ > ✅ > ✅ > ✅
- kselftest.dt.dt_test_unprobed_devices_sh_soc_0_spmi_c440000_pmic_0_pon_1300_pwrkey
last run: https://d.kernelci.org/test/maestro:6a67a01c798ea6c1ef78af55
history: > ✅ > ❌ > ✅ > ✅ > ✅
- kselftest.dt.dt_test_unprobed_devices_sh_soc_0_spmi_c440000_pmic_0_pon_1300_resin
last run: https://d.kernelci.org/test/maestro:6a67a01c798ea6c1ef78af54
history: > ✅ > ❌ > ✅ > ✅ > ✅
- kselftest.dt.dt_test_unprobed_devices_sh_soc_0_spmi_c440000_pmic_0_rtc_6100
last run: https://d.kernelci.org/test/maestro:6a67a01c798ea6c1ef78af53
history: > ✅ > ❌ > ✅ > ✅ > ✅
- kselftest.dt.dt_test_unprobed_devices_sh_soc_0_spmi_c440000_pmic_1_temp-alarm_a00
last run: https://d.kernelci.org/test/maestro:6a67a01c798ea6c1ef78af50
history: > ✅ > ❌ > ✅ > ✅ > ✅
- kselftest.dt.dt_test_unprobed_devices_sh_soc_0_spmi_c440000_pmic_2_pwm
last run: https://d.kernelci.org/test/maestro:6a67a01c798ea6c1ef78af4d
history: > ✅ > ❌ > ✅ > ✅ > ✅
- kselftest.dt.dt_test_unprobed_devices_sh_soc_0_spmi_c440000_pmic_2_temp-alarm_a00
last run: https://d.kernelci.org/test/maestro:6a67a01c798ea6c1ef78af4c
history: > ✅ > ❌ > ✅ > ✅ > ✅
- kselftest.dt.dt_test_unprobed_devices_sh_soc_0_spmi_c440000_pmic_8_adc_3100
last run: https://d.kernelci.org/test/maestro:6a67a01c798ea6c1ef78af4a
history: > ✅ > ❌ > ✅ > ✅ > ✅
- kselftest.dt.dt_test_unprobed_devices_sh_soc_0_spmi_c440000_pmic_8_temp-alarm_2400
last run: https://d.kernelci.org/test/maestro:6a67a01c798ea6c1ef78af48
history: > ✅ > ❌ > ✅ > ✅ > ✅
- kselftest.dt.dt_test_unprobed_devices_sh_soc_0_usb_a600000
last run: https://d.kernelci.org/test/maestro:6a67a01c798ea6c1ef78af27
history: > ✅ > ❌ > ✅ > ✅ > ✅
- kselftest.dt.dt_test_unprobed_devices_sh_soc_0_video-codec_aa00000
last run: https://d.kernelci.org/test/maestro:6a67a01c798ea6c1ef78af26
history: > ✅ > ❌ > ✅ > ✅ > ✅
- kselftest.dt.dt_test_unprobed_devices_sh_wcn6750-pmu
last run: https://d.kernelci.org/test/maestro:6a67a01c798ea6c1ef78af21
history: > ✅ > ❌ > ✅ > ✅ > ✅
> Config: defconfig+arm64-chromebook+kselftest
- Architecture/compiler: arm64/gcc-14
- kselftest.gpio
last run: https://d.kernelci.org/test/maestro:6a679ce6798ea6c1ef789f4a
history: > ✅ > ❌ > ❌ > ❌ > ✅
Hardware: qcs8300-ride
> Config: defconfig+lab-setup+kselftest
- Architecture/compiler: arm64/gcc-14
- kselftest.clone3
last run: https://d.kernelci.org/test/maestro:6a6799eb798ea6c1ef78538e
history: > ✅ > ✅ > ❌ > ✅ > ✅
- kselftest.coredump
last run: https://d.kernelci.org/test/maestro:6a6799fa798ea6c1ef7853d7
history: > ❌ > ❌ > ✅ > ✅ > ❌
- kselftest.devices-exist
last run: https://d.kernelci.org/test/maestro:6a679a74798ea6c1ef7856d7
history: > ❌ > ✅ > ✅ > ❌ > ❌
- kselftest.dt.dt_test_unprobed_devices_sh_soc_0_display-subsystem_ae00000_display-controller_ae01000
last run: https://d.kernelci.org/test/maestro:6a67a0a4798ea6c1ef78b603
history: > ❌ > ✅ > ❌ > ✅
- kselftest.dt.dt_test_unprobed_devices_sh_soc_0_display-subsystem_ae00000_displayport-controller_af54000
last run: https://d.kernelci.org/test/maestro:6a67a0a4798ea6c1ef78b601
history: > ❌ > ✅ > ❌ > ✅
- kselftest.dt.dt_test_unprobed_devices_sh_soc_0_display-subsystem_ae00000_dsi_ae94000
last run: https://d.kernelci.org/test/maestro:6a67a0a4798ea6c1ef78b5ff
history: > ❌ > ✅ > ❌ > ✅
- kselftest.dt.dt_test_unprobed_devices_sh_soc_0_ethernet_23040000_mdio_phy_8
last run: https://d.kernelci.org/test/maestro:6a67a0a4798ea6c1ef78b5f7
history: > ⚠️ > ✅ > ⚠️ > ⚠️
- kselftest.dt.dt_test_unprobed_devices_sh_soc_0_geniqup_ac0000_i2c_a80000_i2c-mux_70_i2c_0_bridge_58
last run: https://d.kernelci.org/test/maestro:6a67a0a4798ea6c1ef78b5d6
history: > ❌ > ✅ > ❌ > ✅
- kselftest.dt.dt_test_unprobed_devices_sh_soc_0_pci_1c00000
last run: https://d.kernelci.org/test/maestro:6a67a0a4798ea6c1ef78b5bd
history: > ✅ > ✅ > ❌ > ✅
- kselftest.dt.dt_test_unprobed_devices_sh_soc_0_usb_a600000
last run: https://d.kernelci.org/test/maestro:6a67a0a4798ea6c1ef78b54a
history: > ✅ > ✅ > ❌ > ✅
- kselftest.futex
last run: https://d.kernelci.org/test/maestro:6a679a26798ea6c1ef785531
history: > ❌ > ✅ > ✅ > ✅ > ❌
> Config: defconfig+arm64-chromebook+kselftest
- Architecture/compiler: arm64/gcc-14
- kselftest.ring-buffer
last run: https://d.kernelci.org/test/maestro:6a679d1a798ea6c1ef78a507
history: > ❌ > ❌ > ✅ > ❌ > ❌
Hardware: qcs9100-ride
> Config: defconfig+lab-setup+kselftest
- Architecture/compiler: arm64/gcc-14
- kselftest.arm64
last run: https://d.kernelci.org/test/maestro:6a6799bf798ea6c1ef785256
history: > ✅ > ❌ > ✅ > ✅ > ✅
- kselftest.arm64.arm64_fp-stress
last run: https://d.kernelci.org/test/maestro:6a679bff798ea6c1ef7893b4
history: > ✅ > ❌ > ✅ > ✅ > ✅
- kselftest.dt.dt_test_unprobed_devices_sh_soc_0_cti_4b13000
last run: https://d.kernelci.org/test/maestro:6a67a279798ea6c1ef78bc5b
history: > ✅ > ✅ > ✅ > ✅ > ⚠️
- kselftest.dt.dt_test_unprobed_devices_sh_soc_0_display-subsystem_22000000_displayport-controller_22154000
last run: https://d.kernelci.org/test/maestro:6a67a279798ea6c1ef78bc58
history: > ✅ > ✅ > ❌ > ✅ > ❌
- kselftest.dt.dt_test_unprobed_devices_sh_soc_0_display-subsystem_22000000_displayport-controller_2215c000
last run: https://d.kernelci.org/test/maestro:6a67a279798ea6c1ef78bc57
history: > ✅ > ✅ > ❌ > ✅ > ❌
- kselftest.dt.dt_test_unprobed_devices_sh_soc_0_display-subsystem_22000000_phy_220c2a00
last run: https://d.kernelci.org/test/maestro:6a67a279798ea6c1ef78bc56
history: > ✅ > ✅ > ❌ > ✅ > ❌
- kselftest.dt.dt_test_unprobed_devices_sh_soc_0_display-subsystem_22000000_phy_220c5a00
last run: https://d.kernelci.org/test/maestro:6a67a279798ea6c1ef78bc55
history: > ✅ > ✅ > ❌ > ✅ > ❌
- kselftest.dt.dt_test_unprobed_devices_sh_soc_0_display-subsystem_ae00000_displayport-controller_af54000
last run: https://d.kernelci.org/test/maestro:6a67a279798ea6c1ef78bc51
history: > ✅ > ✅ > ❌ > ✅ > ❌
- kselftest.dt.dt_test_unprobed_devices_sh_soc_0_display-subsystem_ae00000_displayport-controller_af5c000
last run: https://d.kernelci.org/test/maestro:6a67a279798ea6c1ef78bc4f
history: > ✅ > ✅ > ❌ > ✅ > ❌
- kselftest.dt.dt_test_unprobed_devices_sh_soc_0_display-subsystem_ae00000_phy_aec2a00
last run: https://d.kernelci.org/test/maestro:6a67a279798ea6c1ef78bc49
history: > ✅ > ✅ > ❌ > ✅ > ❌
- kselftest.dt.dt_test_unprobed_devices_sh_soc_0_display-subsystem_ae00000_phy_aec5a00
last run: https://d.kernelci.org/test/maestro:6a67a279798ea6c1ef78bc48
history: > ✅ > ✅ > ❌ > ✅ > ❌
- kselftest.dt.dt_test_unprobed_devices_sh_soc_0_ethernet_23040000_mdio_phy_8
last run: https://d.kernelci.org/test/maestro:6a67a279798ea6c1ef78bc42
history: > ✅ > ✅ > ✅ > ✅ > ⚠️
- kselftest.dt.dt_test_unprobed_devices_sh_soc_0_ethernet_23040000_mdio_phy_a
last run: https://d.kernelci.org/test/maestro:6a67a279798ea6c1ef78bc41
history: > ✅ > ✅ > ✅ > ✅ > ⚠️
- kselftest.dt.dt_test_unprobed_devices_sh_soc_0_funnel_4041000
last run: https://d.kernelci.org/test/maestro:6a67a279798ea6c1ef78bc38
history: > ✅ > ✅ > ✅ > ✅ > ⚠️
- kselftest.dt.dt_test_unprobed_devices_sh_soc_0_funnel_4042000
last run: https://d.kernelci.org/test/maestro:6a67a279798ea6c1ef78bc37
history: > ✅ > ✅ > ✅ > ✅ > ⚠️
- kselftest.dt.dt_test_unprobed_devices_sh_soc_0_funnel_4045000
last run: https://d.kernelci.org/test/maestro:6a67a279798ea6c1ef78bc36
history: > ✅ > ✅ > ✅ > ✅ > ⚠️
- kselftest.dt.dt_test_unprobed_devices_sh_soc_0_funnel_4ad4000
last run: https://d.kernelci.org/test/maestro:6a67a279798ea6c1ef78bc35
history: > ✅ > ✅ > ✅ > ✅ > ⚠️
- kselftest.dt.dt_test_unprobed_devices_sh_soc_0_funnel_4b04000
last run: https://d.kernelci.org/test/maestro:6a67a279798ea6c1ef78bc34
history: > ✅ > ✅ > ✅ > ✅ > ⚠️
- kselftest.dt.dt_test_unprobed_devices_sh_soc_0_funnel_4b83000
last run: https://d.kernelci.org/test/maestro:6a67a279798ea6c1ef78bc33
history: > ✅ > ✅ > ✅ > ✅ > ⚠️
- kselftest.dt.dt_test_unprobed_devices_sh_soc_0_funnel_6800000
last run: https://d.kernelci.org/test/maestro:6a67a279798ea6c1ef78bc32
history: > ✅ > ✅ > ✅ > ✅ > ⚠️
- kselftest.dt.dt_test_unprobed_devices_sh_soc_0_funnel_6810000
last run: https://d.kernelci.org/test/maestro:6a67a279798ea6c1ef78bc31
history: > ✅ > ✅ > ✅ > ✅ > ⚠️
- kselftest.dt.dt_test_unprobed_devices_sh_soc_0_replicator_4046000
last run: https://d.kernelci.org/test/maestro:6a67a279798ea6c1ef78bbc5
history: > ✅ > ✅ > ✅ > ✅ > ⚠️
- kselftest.dt.dt_test_unprobed_devices_sh_soc_0_replicator_404e000
last run: https://d.kernelci.org/test/maestro:6a67a279798ea6c1ef78bbc4
history: > ✅ > ✅ > ✅ > ✅ > ⚠️
- kselftest.dt.dt_test_unprobed_devices_sh_soc_0_replicator_4b06000
last run: https://d.kernelci.org/test/maestro:6a67a279798ea6c1ef78bbc3
history: > ✅ > ✅ > ✅ > ✅ > ⚠️
- kselftest.dt.dt_test_unprobed_devices_sh_soc_0_stm_4002000
last run: https://d.kernelci.org/test/maestro:6a67a279798ea6c1ef78bba4
history: > ✅ > ✅ > ✅ > ✅ > ⚠️
- kselftest.dt.dt_test_unprobed_devices_sh_soc_0_tmc_4048000
last run: https://d.kernelci.org/test/maestro:6a67a279798ea6c1ef78bb9c
history: > ✅ > ✅ > ✅ > ✅ > ⚠️
- kselftest.dt.dt_test_unprobed_devices_sh_soc_0_tmc_404f000
last run: https://d.kernelci.org/test/maestro:6a67a279798ea6c1ef78bb9b
history: > ✅ > ✅ > ✅ > ✅ > ⚠️
- kselftest.dt.dt_test_unprobed_devices_sh_soc_0_tmc_4b05000
last run: https://d.kernelci.org/test/maestro:6a67a279798ea6c1ef78bb9a
history: > ✅ > ✅ > ✅ > ✅ > ⚠️
> Config: defconfig+arm64-chromebook+kselftest
- Architecture/compiler: arm64/gcc-14
- kselftest.efivars
last run: https://d.kernelci.org/test/maestro:6a679cad798ea6c1ef789d0f
history: > ❌ > ❌ > ✅ > ❌ > ❌
- kselftest.ring-buffer
last run: https://d.kernelci.org/test/maestro:6a679d1d798ea6c1ef78a50a
history: > ❌ > ❌ > ✅ > ❌ > ❌
This branch has 1 pre-existing build issues. See details in the dashboard.
Sent every day if there were changes in the past 24 hours.
Legend: ✅ PASS ❌ FAIL ⚠️ INCONCLUSIVE
--
This is an experimental report format. Please send feedback in!
Talk to us at kernelci@lists.linux.dev
Made with love by the KernelCI team - https://kernelci.org
^ permalink raw reply
* Re: [PATCH] drm/amd/display: fix usage of DC_FPU_{BEGIN,END} with PREEMPT_RT
From: mikhail.v.gavrilov @ 2026-07-28 0:51 UTC (permalink / raw)
To: Bert Karwatzki, linux-kernel
Cc: linux-next, linux-rt-devel, amd-gfx, # = v7 . 1, Alex Deucher,
Rafal Ostrowski, Mario Limonciello, Sebastian Andrzej Siewior,
Thomas Gleixner
In-Reply-To: <20260727105059.75716-1-spasswolf@web.de>
On Mon, 2026-07-27 at 12:50 +0200, Bert Karwatzki wrote:
> On PREEMPT_RT kernels kvzalloc_obj() can sleep because spin_lock is
> converted to rt_mutex. dc_create_plane_state() can be called while
> inside an FPU-guarded region, resuling in "scheduling while atomic"
> errors on PREEMPT_RT kernels.
> Fix this by calling kvzalloc_obj() with
> DC_RUN_WITH_PREEMPTION_ENABLED().
> Also fix the error path in dc_create_stream_for_sink().
>
> Fixes: 3539437f354b ("drm/amd/display: Move FPU Guards From DML To DC
> - Part 1")
> Link:
> https://lore.kernel.org/lkml/20260723123449.6494-1-spasswolf@web.de/
>
> Signed-off-by: Bert Karwatzki <spasswolf@web.de>
> ---
> drivers/gpu/drm/amd/display/dc/core/dc_stream.c | 5 +++--
> drivers/gpu/drm/amd/display/dc/core/dc_surface.c | 4 ++--
> 2 files changed, 5 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/display/dc/core/dc_stream.c
> b/drivers/gpu/drm/amd/display/dc/core/dc_stream.c
> index dbc12640b01c..4ac835777b58 100644
> --- a/drivers/gpu/drm/amd/display/dc/core/dc_stream.c
> +++ b/drivers/gpu/drm/amd/display/dc/core/dc_stream.c
> @@ -233,8 +233,9 @@ struct dc_stream_state
> *dc_create_stream_for_sink(
>
> fail:
> if (stream) {
> - kfree(stream->update_scratch);
> - kfree(stream);
> + if (stream->update_scratch)
> + DC_RUN_WITH_PREEMPTION_ENABLED(kfree(stream-
> >update_scratch));
> + DC_RUN_WITH_PREEMPTION_ENABLED(kfree(stream));
> }
>
> return NULL;
> diff --git a/drivers/gpu/drm/amd/display/dc/core/dc_surface.c
> b/drivers/gpu/drm/amd/display/dc/core/dc_surface.c
> index 88e825a6582c..d5c6427796b6 100644
> --- a/drivers/gpu/drm/amd/display/dc/core/dc_surface.c
> +++ b/drivers/gpu/drm/amd/display/dc/core/dc_surface.c
> @@ -85,8 +85,8 @@ uint8_t dc_plane_get_pipe_mask(struct dc_state
> *dc_state, const struct dc_plane
>
> *********************************************************************
> *********/
> struct dc_plane_state *dc_create_plane_state(const struct dc *dc)
> {
> - struct dc_plane_state *plane_state =
> kvzalloc_obj(*plane_state,
> -
> GFP_ATOMIC);
> + struct dc_plane_state *plane_state;
> + DC_RUN_WITH_PREEMPTION_ENABLED(plane_state =
> kvzalloc_obj(*plane_state, GFP_ATOMIC));
>
> if (NULL == plane_state)
> return NULL;
Hi Bert,
You may not be aware that the same allocation is already wrapped once,
at the dcn32 call site:
183182235f6d ("drm/amd/display: Wrap DCN32 phantom-plane allocation
in DC_RUN_WITH_PREEMPTION_ENABLED")
That one only covers the dcn32 DML1 path, while your trace goes through
dcn401_validate_bandwidth() and dml21 - so wrapping the call site could
never have caught your case. Which is a good argument for guarding the
allocation in the callee, as you do: dc_create_plane_state() is reached
from every DCN and both DML generations.
On dcn32 the two wraps now nest. That is harmless, because
DC_RUN_WITH_PREEMPTION_ENABLED() is conditional on dc_is_fp_enabled():
once the outer instance has left the FPU region, the inner one expands
to a plain call. But it does make the dcn32 wrap redundant, and I
think it should be dropped in a follow-up now that the allocation is
guarded in the callee.
One thing that may be worth adjusting in the commit message: this is
not only a PREEMPT_RT problem. 183182235f6d was needed on a plain non-
RT x86 kernel. There DC_FP_START() takes fpregs_lock(), which disables
local softirqs, and dc_plane_state is around 335 KiB, so kvzalloc_obj()
falls through to the vmalloc path and hits BUG_ON(in_interrupt()). So
on RT any allocation inside the FPU region is illegal, while on non-RT
it is specifically the large ones - two failure modes, one root cause.
About the FPU register question raised by the review bot: as far as I
can see it applies to every existing user of
DC_RUN_WITH_PREEMPTION_ENABLED(), 183182235f6d included, so it looks
like a property of the macro rather than something your patch
introduces. An answer from AMD on that would be useful either way.
I have dcn32 hardware here (RX 7900 XTX) and can test the patch on
non-RT if that helps.
--
Thanks,
Mikhail
^ permalink raw reply
* Re: hang during shutdown in next-20260722+ with MT7925
From: mikhail.v.gavrilov @ 2026-07-28 0:32 UTC (permalink / raw)
To: Bert Karwatzki, Nicolas Cavallari
Cc: linux-kernel, linux-next, linux-wireless, Felix Fietkau,
ryder.lee, lorenzo, legale.legale, sean.wang, shayne.chen
In-Reply-To: <20260724151419.26014-1-spasswolf@web.de>
On Fri, 2026-07-24 at 17:14 +0200, Bert Karwatzki wrote:
> Since next-20260722 my debian sid system hangs when shutting down or
> rebooting (No error message when monitoring the shutdown process via
> netconsole). I bisected the error to commit
> 13b7e6a96a00 ("wifi: mt76: Disable napi when removing device")
> and reverting this commit in next-20260723 makes shutting down or
> rebooting work normally again.
>
> Wifi device:
> 09:00.0 Network controller [0280]: MEDIATEK Corp. MT7925 802.11be
> 160MHz 2x2 PCIe Wireless Network Adapter [Filogic 360] [14c3:7925]
>
> Cpu:
> $ cat /proc/cpuinfo
> processor : 0
> vendor_id : AuthenticAMD
> cpu family : 26
> model : 68
> model name : AMD Ryzen 9 9950X 16-Core Processor
> stepping : 0
> microcode : 0xb404035
> cpu MHz : 624.194
> cache size : 1024 KB
> physical id : 0
> siblings : 32
> core id : 0
> cpu cores : 16
> apicid : 0
> initial apicid : 0
> fpu : yes
> fpu_exception : yes
> cpuid level : 16
> wp : yes
> flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr
> pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext
> fxsr_opt pdpe1gb rdtscp lm constant_tsc rep_good amd_lbr_v2 nopl
> xtopology nonstop_tsc cpuid extd_apicid aperfmperf rapl pni pclmulqdq
> monitor ssse3 fma cx16 sse4_1 sse4_2 movbe popcnt aes xsave avx f16c
> rdrand lahf_lm cmp_legacy svm extapic cr8_legacy abm sse4a
> misalignsse 3dnowprefetch osvw ibs skinit wdt tce topoext
> perfctr_core perfctr_nb bpext perfctr_llc mwaitx cpuid_fault cpb
> cat_l3 cdp_l3 hw_pstate ssbd mba perfmon_v2 ibrs ibpb stibp
> ibrs_enhanced vmmcall fsgsbase tsc_adjust bmi1 avx2 smep bmi2 erms
> invpcid cqm rdt_a avx512f avx512dq rdseed adx smap avx512ifma
> clflushopt clwb avx512cd sha_ni avx512bw avx512vl xsaveopt xsavec
> xgetbv1 xsaves cqm_llc cqm_occup_llc cqm_mbm_total cqm_mbm_local
> user_shstk avx_vnni avx512_bf16 clzero irperf xsaveerptr rdpru
> wbnoinvd cppc arat npt lbrv svm_lock nrip_save tsc_scale vmcb_clean
> flushbyasid decodeassists pausefilter pfthreshold avic
> v_vmsave_vmload vgif x2avic v_spec_ctrl vnmi avx512vbmi umip pku
> ospke avx512_vbmi2 gfni vaes vpclmulqdq avx512_vnni avx512_bitalg
> avx512_vpopcntdq rdpid bus_lock_detect movdiri movdir64b
> overflow_recov succor smca fsrm avx512_vp2intersect flush_l1d
> amd_lbr_pmc_freeze
> bugs : sysret_ss_attrs spectre_v1 spectre_v2
> spec_store_bypass srso spectre_v2_user vmscape
> bogomips : 8599.52
> TLB size : 192 4K pages
> clflush size : 64
> cache_alignment : 64
> address sizes : 48 bits physical, 48 bits virtual
> power management: ts ttp tm hwpstate cpb eff_freq_ro [13] [14]
>
> Other pci hardware:
> $ lspci
> 00:00.0 Host bridge: Advanced Micro Devices, Inc. [AMD]
> Raphael/Granite Ridge Root Complex
> 00:00.2 IOMMU: Advanced Micro Devices, Inc. [AMD] Raphael/Granite
> Ridge IOMMU
> 00:01.0 Host bridge: Advanced Micro Devices, Inc. [AMD]
> Raphael/Granite Ridge Dummy Host Bridge
> 00:01.1 PCI bridge: Advanced Micro Devices, Inc. [AMD]
> Raphael/Granite Ridge GPP Bridge
> 00:01.2 PCI bridge: Advanced Micro Devices, Inc. [AMD]
> Raphael/Granite Ridge GPP Bridge
> 00:02.0 Host bridge: Advanced Micro Devices, Inc. [AMD]
> Raphael/Granite Ridge Dummy Host Bridge
> 00:02.1 PCI bridge: Advanced Micro Devices, Inc. [AMD]
> Raphael/Granite Ridge GPP Bridge
> 00:03.0 Host bridge: Advanced Micro Devices, Inc. [AMD]
> Raphael/Granite Ridge Dummy Host Bridge
> 00:04.0 Host bridge: Advanced Micro Devices, Inc. [AMD]
> Raphael/Granite Ridge Dummy Host Bridge
> 00:08.0 Host bridge: Advanced Micro Devices, Inc. [AMD]
> Raphael/Granite Ridge Dummy Host Bridge
> 00:08.1 PCI bridge: Advanced Micro Devices, Inc. [AMD]
> Raphael/Granite Ridge Internal GPP Bridge to Bus [C:A]
> 00:08.3 PCI bridge: Advanced Micro Devices, Inc. [AMD]
> Raphael/Granite Ridge Internal GPP Bridge to Bus [C:A]
> 00:14.0 SMBus: Advanced Micro Devices, Inc. [AMD] FCH SMBus
> Controller (rev 71)
> 00:14.3 ISA bridge: Advanced Micro Devices, Inc. [AMD] FCH LPC Bridge
> (rev 51)
> 00:18.0 Host bridge: Advanced Micro Devices, Inc. [AMD]
> Raphael/Granite Ridge Data Fabric; Function 0
> 00:18.1 Host bridge: Advanced Micro Devices, Inc. [AMD]
> Raphael/Granite Ridge Data Fabric; Function 1
> 00:18.2 Host bridge: Advanced Micro Devices, Inc. [AMD]
> Raphael/Granite Ridge Data Fabric; Function 2
> 00:18.3 Host bridge: Advanced Micro Devices, Inc. [AMD]
> Raphael/Granite Ridge Data Fabric; Function 3
> 00:18.4 Host bridge: Advanced Micro Devices, Inc. [AMD]
> Raphael/Granite Ridge Data Fabric; Function 4
> 00:18.5 Host bridge: Advanced Micro Devices, Inc. [AMD]
> Raphael/Granite Ridge Data Fabric; Function 5
> 00:18.6 Host bridge: Advanced Micro Devices, Inc. [AMD]
> Raphael/Granite Ridge Data Fabric; Function 6
> 00:18.7 Host bridge: Advanced Micro Devices, Inc. [AMD]
> Raphael/Granite Ridge Data Fabric; Function 7
> 01:00.0 PCI bridge: Advanced Micro Devices, Inc. [AMD/ATI] Navi 10 XL
> Upstream Port of PCI Express Switch (rev 25)
> 02:00.0 PCI bridge: Advanced Micro Devices, Inc. [AMD/ATI] Navi 10 XL
> Downstream Port of PCI Express Switch (rev 25)
> 03:00.0 VGA compatible controller: Advanced Micro Devices, Inc.
> [AMD/ATI] Navi 44 [Radeon RX 9060 XT] (rev c0)
> 03:00.1 Audio device: Advanced Micro Devices, Inc. [AMD/ATI] Navi 48
> HDMI/DP Audio Controller
> 04:00.0 Non-Volatile memory controller: Samsung Electronics Co Ltd
> NVMe SSD 9100 PRO [PM9E1]
> 05:00.0 PCI bridge: Advanced Micro Devices, Inc. [AMD] 600 Series
> Chipset PCIe Switch Upstream Port (rev 01)
> 06:00.0 PCI bridge: Advanced Micro Devices, Inc. [AMD] 600 Series
> Chipset PCIe Switch Downstream Port (rev 01)
> 06:06.0 PCI bridge: Advanced Micro Devices, Inc. [AMD] 600 Series
> Chipset PCIe Switch Downstream Port (rev 01)
> 06:07.0 PCI bridge: Advanced Micro Devices, Inc. [AMD] 600 Series
> Chipset PCIe Switch Downstream Port (rev 01)
> 06:08.0 PCI bridge: Advanced Micro Devices, Inc. [AMD] 600 Series
> Chipset PCIe Switch Downstream Port (rev 01)
> 06:0c.0 PCI bridge: Advanced Micro Devices, Inc. [AMD] 600 Series
> Chipset PCIe Switch Downstream Port (rev 01)
> 06:0d.0 PCI bridge: Advanced Micro Devices, Inc. [AMD] 600 Series
> Chipset PCIe Switch Downstream Port (rev 01)
> 08:00.0 Ethernet controller: Intel Corporation Ethernet Controller
> I226-V (rev 06)
> 09:00.0 Network controller: MEDIATEK Corp. MT7925 802.11be 160MHz 2x2
> PCIe Wireless Network Adapter [Filogic 360]
> 0b:00.0 USB controller: Advanced Micro Devices, Inc. [AMD] 800 Series
> Chipset USB 3.x XHCI Controller (rev 01)
> 0c:00.0 SATA controller: Advanced Micro Devices, Inc. [AMD] 600
> Series Chipset SATA Controller (rev 01)
> 0d:00.0 Non-Essential Instrumentation [1300]: Advanced Micro Devices,
> Inc. [AMD] Raphael/Granite Ridge PCIe Dummy Function (rev c1)
> 0d:00.2 Encryption controller: Advanced Micro Devices, Inc. [AMD]
> Family 19h PSP/CCP
> 0d:00.3 USB controller: Advanced Micro Devices, Inc. [AMD]
> Raphael/Granite Ridge USB 3.1 xHCI
> 0d:00.4 USB controller: Advanced Micro Devices, Inc. [AMD]
> Raphael/Granite Ridge USB 3.1 xHCI
> 0e:00.0 USB controller: Advanced Micro Devices, Inc. [AMD]
> Raphael/Granite Ridge USB 2.0 xHCI
>
>
> Bert Karwatzki
Hi Bert,
I hit the same hang on an MT7922 (mt7921e) and bisected it to the same
commit, so it is not MT7925 specific.
The cause is a double napi_disable(). mt7921e_unregister_device() and
mt7925e_unregister_device() already disable all RX NAPI instances, and
since 13b7e6a96a00 mt76_dma_cleanup() disables them a second time.
napi_disable() is not idempotent - it leaves NAPIF_STATE_SCHED set on
return, so the second call spins in usleep_range() forever. Since
mt7921_pci_shutdown() and mt7925_pci_shutdown() reuse the remove path,
this is hit on every reboot and poweroff. It is silent because the
stuck task keeps sleeping and rescheduling, so neither the hung task
detector nor the lockup detectors fire; sysrq-w during the hang shows
the task parked in napi_disable() under mt76_dma_cleanup().
I have posted a fix, which is Nicolas' suggestion extended to mt7921e
and with the then unused 'int i' removed:
https://lore.kernel.org/all/20260728002048.19351-1-mikhail.v.gavrilov@gmail.com/
I sent it as a separate thread so that patchwork registers it as a
patch instead of a comment on the already applied commit.
Here on MT7922 it is tested with KASAN and lockdep enabled: module
unload and reload, reboot and poweroff all work again. If you can
confirm it on your MT7925, a Tested-by would be welcome.
--
Thanks,
Mikhail
^ permalink raw reply
* Re: linux-next: manual merge of the tip tree with the mm-hotfixes-unstable tree
From: Lorenzo Stoakes (ARM) @ 2026-07-27 18:15 UTC (permalink / raw)
To: Mike Rapoport
Cc: Mark Brown, Thomas Gleixner, Ingo Molnar, H. Peter Anvin,
Peter Zijlstra, Andrew Morton, Dave Hansen,
Linux Kernel Mailing List, Linux Next Mailing List
In-Reply-To: <amdXKvl8NMM9S6bB@kernel.org>
On Mon, Jul 27, 2026 at 04:03:38PM +0300, Mike Rapoport wrote:
> On Mon, Jul 27, 2026 at 12:33:30PM +0100, Lorenzo Stoakes (ARM) wrote:
> > On Mon, Jul 27, 2026 at 08:48:31AM +0300, Mike Rapoport wrote:
> > > Hi Mark,
> > >
> > > On Sun, Jul 26, 2026 at 10:33:53PM +0100, Mark Brown wrote:
> > > > Hi all,
> > > >
> > > > Today's linux-next merge of the tip tree got a conflict in:
> > > >
> > > > arch/x86/mm/pat/set_memory.c
> > > >
> > > > between commits:
> > > >
> > > > 7a7c16a2d2b4d ("x86/mm/pat: acquire init_mm read lock on attribute change to avoid UAF")
> > > > 25a54f65ccbaf ("x86/mm/pat: allocate split page tables as kernel page tables")
> > > >
> > > > from the mm-hotfixes-unstable tree and commit:
> > > >
> > > > 5fce67641a3ed ("x86/mm/pat: Don't gate cpa_lock on debug_pagealloc_enabled()")
> > > >
> > > > from the tip tree.
> > > >
> > > > I fixed it up (see below) and can carry the fix as necessary. This
> > > > is now fixed as far as linux-next is concerned, but any non trivial
> > > > conflicts should be mentioned to your upstream maintainer when your tree
> > > > is submitted for merging. You may also want to consider cooperating
> > > > with the maintainer of the conflicting tree to minimise any particularly
> > > > complex conflicts.
> > > >
> > > > diff --cc arch/x86/mm/pat/set_memory.c
> > > > index 422ce7fba00c6,1f2a2ba9ce57d..0000000000000
> > > > --- a/arch/x86/mm/pat/set_memory.c
> > > > +++ b/arch/x86/mm/pat/set_memory.c
> > > > @@@ -440,30 -441,12 +443,32 @@@ static void __cpa_collapse_large_pages(
> > > >
> > > > list_for_each_entry_safe(ptdesc, tmp, &pgtables, pt_list) {
> > > > list_del(&ptdesc->pt_list);
> > > > - pagetable_free(ptdesc);
> > > > + /*
> > > > + * Only early alloc'd direct map should not be flagged PG_table
> > > > + * here and those shouldn't be collapsed. However be abundantly
> > > > + * cautious and handle the !PG_table case too.
> > > > + */
> > > > + if (PageTable((ptdesc_page(ptdesc))))
> > > > + pagetable_dtor_free(ptdesc);
> > > > + else
> > > > + pagetable_free(ptdesc);
> > > > }
> > > > +
> > > > + spin_unlock(&cpa_lock);
> > > > }
> > > >
> > > > +static void cpa_collapse_large_pages(struct cpa_data *cpa)
> > > > +{
> > > > + /*
> > > > + * Take the mmap write lock on init_mm to:
> > > > + * - Avoid a use-after-free if raced by ptdump (which takes its own
> > > > + * write lock on init_mm).
> > > > + * - Serialise concurrent CPA walkers.
> > > > + */
> > > > + scoped_guard(mmap_write_lock, &init_mm)
> > > > + __cpa_collapse_large_pages(cpa);
> > > > +}
> > > > +
> > > > static void cpa_flush(struct cpa_data *cpa, int cache)
> > > > {
> > > > unsigned int i;
> > > > @@@ -1254,22 -1237,16 +1258,20 @@@ __split_large_page(struct cpa_data *cpa
> > > > static int split_large_page(struct cpa_data *cpa, pte_t *kpte,
> > > > unsigned long address)
> > > > {
> > > > - struct ptdesc *ptdesc;
> > > > + pte_t *pte;
> > > >
> > > > - if (!debug_pagealloc_enabled())
> > > > - spin_unlock(&cpa_lock);
> > > > + spin_unlock(&cpa_lock);
> > >
> > > This should be
> > >
> > > if (!debug_pagealloc_enabled())
> > > spin_unlock(&cpa_lock);
> > >
> > > > - ptdesc = pagetable_alloc(GFP_KERNEL, 0);
> > > > + if (cpa->init_mm_read_locked)
> > > > + mmap_read_unlock(&init_mm);
> > > > + pte = pte_alloc_one_kernel(&init_mm);
> > > > + if (cpa->init_mm_read_locked)
> > > > + mmap_read_lock(&init_mm);
> > > > - if (!debug_pagealloc_enabled())
> > > > - spin_lock(&cpa_lock);
> > > > + spin_lock(&cpa_lock);
> > >
> > > And this
> > >
> > > if (!debug_pagealloc_enabled())
> > > spin_lock(&cpa_lock);
> > >
> > > > - if (!ptdesc)
> > > > + if (!pte)
> > > > return -ENOMEM;
> > > >
> > > > - if (__split_large_page(cpa, kpte, address, ptdesc))
> > > > - pagetable_free(ptdesc);
> > > > + if (__split_large_page(cpa, kpte, address, pte))
> > > > + pte_free_kernel(&init_mm, pte);
> > > >
> > > > return 0;
> > > > }
> > >
> > >
> > >
> > > --
> > > Sincerely yours,
> > > Mike.
> >
> > Hmm, what's the status of the x86/mm trees on this though? AFAICT Denis's
> > patch is still as-is and the spin_lock() vs. spin_[un]lock_irq*() issue
> > raised in [0] is unaddressed?
>
> Maybe it's best to take x86 cpa fixes via x86 tree in the end.
>
> I collected them on top of the current tip/x86/mm:
>
> https://git.kernel.org/pub/scm/linux/kernel/git/rppt/linux.git/log/?h=cpa-fixes
>
> Can you please take a look and check I didn't miss anything? I'd like to
> test it a bit more before sending out.
Will take a look later to make sure :)
>
> If we route your x86 fixes via x86 tree rather than mm tree there will be a
> trivial conflict in definition of the new guards for mmap_lock, but other
> than that they should merge nicely with generic and arm64 part of your UAF
> set.
In terms of having the x86 fixes there it's fine, as long as the mm fixes land
and the x86 fixes land, we're all good.
>
> > Thanks, Lorenzo
> >
> > [0]:https://lore.kernel.org/all/al-MrKyIafA8QR_8@lucifer/
>
> --
> Sincerely yours,
> Mike.
Cheers, Lorenzo
^ permalink raw reply
* Re: Policy regarding linux-next only changes
From: Mark Brown @ 2026-07-27 17:39 UTC (permalink / raw)
To: Tetsuo Handa
Cc: Miguel Ojeda, Theodore Tso, Alexander Potapenko,
Christoph Hellwig, Aleksandr Nogikh, Boqun Feng, Gary Guo,
linux-next, linux-kernel, Miguel Ojeda, Linus Torvalds, peterz,
will, longman, mingo, gregkh
In-Reply-To: <43a46fbd-acea-43f6-99f4-c8b866a5f9f4@I-love.SAKURA.ne.jp>
[-- Attachment #1: Type: text/plain, Size: 3213 bytes --]
On Mon, Jul 27, 2026 at 10:19:26PM +0900, Tetsuo Handa wrote:
> On 2026/07/27 2:49, Mark Brown wrote:
> > On Sat, Jul 25, 2026 at 12:44:17PM +0900, Tetsuo Handa wrote:
> >> Excuse me, but what does "successfully unit tested" mean? Broken patches
> >> that do not build, or trigger oops by just "/bin/cat" _are_ arriving at
> >> linux-next tree, which in turn preventing continuous testing by syzbot.
> > You're supposed to make some reasonable effort to ensure that things
> > work, if you break things badly enough and pay little enough attention
> > your tree will get kicked. To even get merged in -next on a given day a
> You and I are talking about different topics.
> You are saying that I should not submit patches that break linux-next.
> I am saying that maintainers are submitting patches that break linux-next
> (and then stop responding after a breakage was found in linux-next).
No, what I'm describing applies to everyone. It's a bit more important
that if you're adding things not for your own tree that you don't mess
up, but I do actually occasionally find myself removing trees because of
disruption they are causing.
> Some maintainers respond quickly (e.g. remove problematic commits from the tree)
> when syzbot sends a report that there was a build failure or boot failure with
> linux-next kernel, but other maintainers respond very slowly.
> For the latter example, syzbot is still using next-20260714 because a maintainer
> who should accept/reject https://lkml.kernel.org/r/al1pElMQZsDfpAYI@michalis-linux
> is not responding. As a result, syzbot is unable to test changes made between
> next-20260714 and next-20260726.
This really just looks like another case where you (or someone) need to
commuicate if something is urgent - I would have a hard time telling
from that thread that there's a particularly big problem, the only reply
indicating any kind of problem with the posted patch (from Joshua) was
then followed up saying to disrgard it and there's nothing at all at any
point in the thread or original report about the scope of the issue or
any practical impact it's having. Frankly I'm not clear that Michail
(who posted the patch) is aware that there's any urgency here and isn't
just acting reasonably and promptly on what was in the report mail.
Even if someone were to click through the syzbot link the report is
flagged as low priority in the dashboard and the config is just a link
to a raw config so there's no indication if this is defconfig,
randconfig or whatever. There's absolutely nothing in the sysbot
dashboard or list report that indicates to me that this has any kind of
impact beyond "a warning is displayed during boot".
If this were something super urgent I would expect to see people
following up saying clearly why that's the case, doing so repeatedly if
things take a while. That simply isn't happening here, from what's
visible I really don't know how anyone is expected to infer that this
isn't just a fairly standard bugfix for a routine issue that was only
reported a week ago. Perhaps this is all clear if you are familiar with
how exactly syzbot works but most people aren't.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* -next status as at v7.2-rc5
From: Mark Brown @ 2026-07-27 17:01 UTC (permalink / raw)
To: Linus Torvalds; +Cc: linux-next, linux-kernel
[-- Attachment #1: Type: text/plain, Size: 827 bytes --]
Hi Linus,
Everything is fairly standard at the minute, still seeing a lot of
collisions due to the point in the cycle we're at. The number of build
breaks is a little high but not really enough to write home about.
Trees being held at old versions:
fastrpc next-20260723
thunderbolt next-20260726
vfs-brauner next-20260723
Trees with signoff problems:
arm-soc (missing author) (A merge got turned into a
patch somehow, fun.)
arm-soc (missing committer)
driver-core (missing committer)
Non-merge commits relative to Linus' tree: 8523
7932 files changed, 390407 insertions(+), 122539 deletions(-)
Top trees adding commits to -next:
1353 drm
587 mm-unstable
340 qcom
301 net-next
279 sound-asoc
262 tip
173 iio
172 v4l-dvb
156 vfs-brauner
154 bpf-next
Thanks,
Mark
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* linux-next: Tree for Jul 27
From: Mark Brown @ 2026-07-27 16:06 UTC (permalink / raw)
To: Linux Next Mailing List; +Cc: Linux Kernel Mailing List
[-- Attachment #1: Type: text/plain, Size: 1743 bytes --]
Hi all,
Changes since 20260726:
The qcom tree acquired a conflict with the origin tree.
The thunderbolt tree acquired a build failure, I used the version from
next-20260726 instead.
Non-merge commits (relative to Linus' tree): 8523
7932 files changed, 390407 insertions(+), 122539 deletions(-)
----------------------------------------------------------------------------
I have created today's linux-next tree at
https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git
(patches at https://www.kernel.org/pub/linux/kernel/next/ ). If you
are tracking the linux-next tree using git, you should not use "git pull"
to do so as that will try to merge the new linux-next release with the
old one. You should use "git fetch" and checkout or reset to the new
master.
You can see which trees have been included by looking in the Next/Trees
file in the source. There is also the merge.log file in the Next
directory. Between each merge, the tree was built with a defconfig
for arm64, an allmodconfig for x86_64, a multi_v7_defconfig for arm,
an arm64 build of various kselftests, a KUnit build and run on arm64,
and a native build of tools/perf. After the final fixups (if any), I do
an x86_64 modules_install followed by builds for x86_64 allnoconfig,
arm64 allyesconfig, powerpc allnoconfig (32 and 64 bit),
ppc44x_defconfig and pseries_le_defconfig and i386, s390, sparc and
sparc64 defconfig and htmldocs.
Below is a summary of the state of the merge.
I am currently merging 429 trees (counting Linus' and 133 trees of bug
fix patches pending for the current release).
Stats about the size of the tree over time can be seen at
http://neuling.org/linux-next-size.html .
Thanks to Paul Gortmaker for triage and bug fixes.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* linux-next: build failure after merge of the thunderbolt tree
From: Mark Brown @ 2026-07-27 15:04 UTC (permalink / raw)
To: Mika Westerberg, Pan Chuang
Cc: Linux Kernel Mailing List, Linux Next Mailing List
[-- Attachment #1: Type: text/plain, Size: 469 bytes --]
Hi all,
After merging the thunderbolt tree, today's linux-next build (x86_64
allmodconfig) failed like this:
/tmp/next/build/drivers/thunderbolt/pci.c:115:17: error: unused variable 'dev' [-Werror,-Wunused-variable]
115 | struct device *dev = &pdev->dev;
| ^~~
1 error generated. make[5]: ***
Caused by commit
eef9f6d8c36f7 (thunderbolt: Remove redundant dev_err_probe())
I have used the tree from next-20260726 instead.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* Re: Policy regarding linux-next only changes
From: Tetsuo Handa @ 2026-07-27 13:19 UTC (permalink / raw)
To: Mark Brown
Cc: Miguel Ojeda, Theodore Tso, Alexander Potapenko,
Christoph Hellwig, Aleksandr Nogikh, Boqun Feng, Gary Guo,
linux-next, linux-kernel, Miguel Ojeda, Linus Torvalds, peterz,
will, longman, mingo, gregkh
In-Reply-To: <0e5ea495-07a2-4f83-8fd7-c90563bc12c4@sirena.org.uk>
On 2026/07/27 2:49, Mark Brown wrote:
> On Sat, Jul 25, 2026 at 12:44:17PM +0900, Tetsuo Handa wrote:
>
>> Excuse me, but what does "successfully unit tested" mean? Broken patches
>> that do not build, or trigger oops by just "/bin/cat" _are_ arriving at
>> linux-next tree, which in turn preventing continuous testing by syzbot.
>
> You're supposed to make some reasonable effort to ensure that things
> work, if you break things badly enough and pay little enough attention
> your tree will get kicked. To even get merged in -next on a given day a
> tree has to build in some of the more common configurations, and not
> break KUnit. It's not expected that everything will be perfect, people
> can't be reasonably expected to to test all possible configurations - a
> big part of the point of -next is to pool coverage - but it's expected
> that people will be making a reasonable effort.
You and I are talking about different topics.
You are saying that I should not submit patches that break linux-next.
I am saying that maintainers are submitting patches that break linux-next
(and then stop responding after a breakage was found in linux-next).
Some maintainers respond quickly (e.g. remove problematic commits from the tree)
when syzbot sends a report that there was a build failure or boot failure with
linux-next kernel, but other maintainers respond very slowly.
For the latter example, syzbot is still using next-20260714 because a maintainer
who should accept/reject https://lkml.kernel.org/r/al1pElMQZsDfpAYI@michalis-linux
is not responding. As a result, syzbot is unable to test changes made between
next-20260714 and next-20260726.
Since one of purposes for linux-next.git is "find bugs before bugs reach linux.git",
being unable to follow daily next-YYYYMMDD is annoying. For example,
https://lkml.kernel.org/r/1a9f53d4-6f48-4df8-a3d8-2b0e442a163a@I-love.SAKURA.ne.jp (which
caused a rust-next breakage while trying to find possible fix for this problem) was not
discovered immediately because syzbot was unable to test next-202604{03,06,07,08,09,10}
due to a different bug. This problem was introduced at the worst timing (i.e. unable to
test around the merge window), and maintainers are not responding.
To minimize period of being unable to follow daily next-YYYYMMDD, I was sometimes sending
linux-next only patches that disable specific module under CONFIG_DEBUG_AID_FOR_SYZBOT=y, for
we can't predict when a maintainer responds to a build failure or boot failure in linux-next.
But now that you want me to stop sending linux-next only patches that disable specific module
under CONFIG_DEBUG_AID_FOR_SYZBOT=y, my question is what we can do to mitigate this "being
unable to follow daily next-YYYYMMDD" problem.
^ permalink raw reply
* Re: linux-next: manual merge of the tip tree with the mm-hotfixes-unstable tree
From: Mike Rapoport @ 2026-07-27 13:09 UTC (permalink / raw)
To: Mark Brown
Cc: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra,
Andrew Morton, Dave Hansen, Linux Kernel Mailing List,
Linux Next Mailing List, Lorenzo Stoakes
In-Reply-To: <76ef8225-1d4a-49e4-a3b9-5e341ec6a057@sirena.org.uk>
On Mon, Jul 27, 2026 at 12:38:58PM +0100, Mark Brown wrote:
> On Mon, Jul 27, 2026 at 08:48:31AM +0300, Mike Rapoport wrote:
> > On Sun, Jul 26, 2026 at 10:33:53PM +0100, Mark Brown wrote:
>
> > > from the mm-hotfixes-unstable tree and commit:
>
> > > 5fce67641a3ed ("x86/mm/pat: Don't gate cpa_lock on debug_pagealloc_enabled()")
>
> > > from the tip tree.
>
> > > - if (!debug_pagealloc_enabled())
> > > - spin_unlock(&cpa_lock);
> > > + spin_unlock(&cpa_lock);
> >
> > This should be
>
> > if (!debug_pagealloc_enabled())
> > spin_unlock(&cpa_lock);
>
> So essentially dropping the changes from the above commit from the tip
> tree?
It's a bit more messy, but essentially yes :)
> Should that commit be there?
There is another commit Lorenzo mentioned that depends on that.
And the patches I have mentioned in reply to Lorenzo should take care of
it.
--
Sincerely yours,
Mike.
^ permalink raw reply
* linux-next: manual merge of the qcom tree with the origin tree
From: Mark Brown @ 2026-07-27 13:04 UTC (permalink / raw)
To: Konrad Dybcio, Bjorn Andersson, Andy Gross
Cc: Konrad Dybcio, Linux Kernel Mailing List, Linux Next Mailing List,
Qiang Yu, Uwe Kleine-König
[-- Attachment #1: Type: text/plain, Size: 1215 bytes --]
Hi all,
Today's linux-next merge of the qcom tree got a conflict in:
drivers/clk/qcom/tcsrcc-glymur.c
between commit:
995832b2cebe6 ("Replace <linux/mod_devicetable.h> by more specific <linux/device-id/*.h> (c files)")
from the origin tree and commit:
0753091abc4b4 ("clk: qcom: tcsrcc-glymur: Add regulator supplies and migrate to clk_ref helper")
from the qcom tree.
I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging. You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.
diff --cc drivers/clk/qcom/tcsrcc-glymur.c
index b44fccb795c6b,3388c1c3a2aaa..0000000000000
--- a/drivers/clk/qcom/tcsrcc-glymur.c
+++ b/drivers/clk/qcom/tcsrcc-glymur.c
@@@ -4,7 -4,10 +4,9 @@@
*/
#include <linux/clk-provider.h>
+ #include <linux/clk/qcom.h>
-#include <linux/mod_devicetable.h>
#include <linux/module.h>
+ #include <linux/of.h>
#include <linux/platform_device.h>
#include <linux/regmap.h>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox