[linus:master] [mm] d99e3140a4: BUG:KCSAN:data-race_in_folio_remove_rmap_ptes/print_report
c:3268) [ 66.574364][ T404] __mmput (kernel/fork.c:1347) [ 66.574717][ T404] mmput (kernel/fork.c:1369) [ 66.575033][ T404] exec_mmap (fs/exec.c:1053) [ 66.575401][ T404] begin_new_exec (fs/exec.c:1310) [ 66.575811][ T404] load_elf_binary (fs/binfmt_elf.c:1006 (discriminator 1)) [ 66.576234][ T404] search_binary_handler (fs/exec.c:1780) [ 66.576683][ T404] exec_binprm (fs/exec.c:1821) [ 66.577064][ T404] bprm_execve (fs/exec.c:1872) [ 66.577455][ T404] do_execveat_common+0x286/0x2af [ 66.577939][ T404] compat_do_execve (fs/exec.c:2081) [ 66.578316][ T404] __ia32_compat_sys_execve (fs/exec.c:2144) [ 66.582840][ T404] ia32_sys_call (kbuild/obj/consumer/x86_64-randconfig-016-20230920/./arch/x86/include/generated/asm/syscalls_32.h:12) [ 66.583256][ T404] __do_fast_syscall_32 (arch/x86/entry/common.c:165 arch/x86/entry/common.c:321) [ 66.583687][ T404] do_fast_syscall_32 (arch/x86/entry/common.c:346 (discriminator 1)) [ 66.584104][ T404] do_SYSENTER_32 (arch/x86/entry/common.c:385) [ 66.584491][ T404] entry_SYSENTER_compat_after_hwframe (arch/x86/entry/entry_64_compat.S:122) [ 66.585022][ T404] [ 66.585226][ T404] value changed: 0x0016 -> 0x0015 [ 66.585694][ T404] [ 66.585891][ T404] Reported by Kernel Concurrency Sanitizer on: [ 66.586387][ T404] CPU: 1 PID: 404 Comm: run Not tainted 6.9.0-rc4-00021-gd99e3140a4d3 #1 [ 66.587057][ T404] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.2-debian-1.16.2-1 04/01/2014 [ 66.587876][ T404] == The kernel config and materials to reproduce are available at: https://download.01.org/0day-ci/archive/20240528/202405281431.c46a3be9-...@intel.com -- 0-DAY CI Kernel Test Service https://github.com/intel/lkp-tests/wiki
Re: [PATCH v2 1/5] dt-bindings: remoteproc: qcom,sa8775p-pas: Document the SA8775p ADSP, CDSP and GPDSP
On Mon, May 27, 2024 at 10:56 AM Krzysztof Kozlowski wrote: > > On 27/05/2024 10:43, Bartosz Golaszewski wrote: > > From: Bartosz Golaszewski > > > > Document the components used to boot the ADSP, CDSP0, CDSP1, GPDSP0 and > > GPDSP1 on the SA8775p SoC. > > > > Co-developed-by: Tengfei Fan > > Missing SoB. > Does it though? The patch never passed through Tengfei's hands, I just wanted to give him credit for the work modifying the sm8550-pas bindings. Bart
Re: [linus:master] [mm] d99e3140a4: BUG:KCSAN:data-race_in_folio_remove_rmap_ptes/print_report
Am 28.05.24 um 09:11 schrieb kernel test robot:
Hello,
kernel test robot noticed
"BUG:KCSAN:data-race_in_folio_remove_rmap_ptes/print_report" on:
commit: d99e3140a4d33e26066183ff727d8f02f56bec64 ("mm: turn folio_test_hugetlb into
a PageType")
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git master
[test failed on linus/master c760b3725e52403dc1b28644fb09c47a83cacea6]
[test failed on linux-next/master 3689b0ef08b70e4e03b82ebd37730a03a672853a]
in testcase: trinity
version: trinity-i386-abe9de86-1_20230429
with following parameters:
runtime: 300s
group: group-04
nr_groups: 5
compiler: gcc-13
test machine: qemu-system-x86_64 -enable-kvm -cpu SandyBridge -smp 2 -m 16G
(please refer to attached dmesg/kmsg for entire log/backtrace)
we noticed this issue does not always happen. we also noticed there are
different random KCSAN issues for both this commit and its parent. but below
4 only happen on this commit with not small rate and keep clean on parent.
Likely that's just a page_type check racing against concurrent
mapcount changes.
In __folio_rmap_sanity_checks() we check
VM_WARN_ON_FOLIO(folio_test_hugetlb(folio), folio);
To make sure we don't get hugetlb folios in the wrong rmap code path. That
can easily race with concurrent mapcount changes, just like any other
page_type checks that end up in folio_test_type/page_has_type e.g., from
PFN walkers.
Load tearing in these functions shouldn't really result in false positives
(what we care about), but READ_ONCE shouldn't hurt or make a difference.
From b03dc9bf27571442d886d8da624a4e4f737433f2 Mon Sep 17 00:00:00 2001
From: David Hildenbrand
Date: Tue, 28 May 2024 09:37:20 +0200
Subject: [PATCH] mm: read page_type using READ_ONCE
KCSAN complains about possible data races: while we check for a
page_type -- for example for sanity checks -- we might concurrently
modify the mapcount that overlays page_type.
Let's use READ_ONCE to avoid laod tearing (shouldn't make a difference)
and to make KCSAN happy.
Note: nothing should really be broken besides wrong KCSAN complaints.
Reported-by: kernel test robot
Closes: https://lore.kernel.org/oe-lkp/202405281431.c46a3be9-...@intel.com
Signed-off-by: David Hildenbrand
---
include/linux/page-flags.h | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/include/linux/page-flags.h b/include/linux/page-flags.h
index 104078afe0b1..e46ccbb9aa58 100644
--- a/include/linux/page-flags.h
+++ b/include/linux/page-flags.h
@@ -955,9 +955,9 @@ PAGEFLAG_FALSE(HasHWPoisoned, has_hwpoisoned)
#define PG_slab0x1000
#define PageType(page, flag) \
- ((page->page_type & (PAGE_TYPE_BASE | flag)) == PAGE_TYPE_BASE)
+ ((READ_ONCE(page->page_type) & (PAGE_TYPE_BASE | flag)) ==
PAGE_TYPE_BASE)
#define folio_test_type(folio, flag) \
- ((folio->page.page_type & (PAGE_TYPE_BASE | flag)) == PAGE_TYPE_BASE)
+ ((READ_ONCE(folio->page.page_type) & (PAGE_TYPE_BASE | flag)) ==
PAGE_TYPE_BASE)
static inline int page_type_has_type(unsigned int page_type)
{
@@ -966,7 +966,7 @@ static inline int page_type_has_type(unsigned int page_type)
static inline int page_has_type(const struct page *page)
{
- return page_type_has_type(page->page_type);
+ return page_type_has_type(READ_ONCE(page->page_type));
}
#define FOLIO_TYPE_OPS(lname, fname) \
--
2.45.1
--
Thanks,
David / dhildenb
Re: [linus:master] [mm] d99e3140a4: BUG:KCSAN:data-race_in_folio_remove_rmap_ptes/print_report
On Tue, May 28, 2024 at 09:43:39AM +0200, David Hildenbrand wrote: > Likely that's just a page_type check racing against concurrent > mapcount changes. > > In __folio_rmap_sanity_checks() we check > VM_WARN_ON_FOLIO(folio_test_hugetlb(folio), folio); Yeah, and that "collides" with last = atomic_add_negative(-1, &page->_mapcount) from __folio_remove_rmap. > To make sure we don't get hugetlb folios in the wrong rmap code path. That > can easily race with concurrent mapcount changes, just like any other > page_type checks that end up in folio_test_type/page_has_type e.g., from > PFN walkers. > > Load tearing in these functions shouldn't really result in false positives > (what we care about), but READ_ONCE shouldn't hurt or make a difference. > > > From b03dc9bf27571442d886d8da624a4e4f737433f2 Mon Sep 17 00:00:00 2001 > From: David Hildenbrand > Date: Tue, 28 May 2024 09:37:20 +0200 > Subject: [PATCH] mm: read page_type using READ_ONCE > > KCSAN complains about possible data races: while we check for a > page_type -- for example for sanity checks -- we might concurrently > modify the mapcount that overlays page_type. > > Let's use READ_ONCE to avoid laod tearing (shouldn't make a difference) > and to make KCSAN happy. > > Note: nothing should really be broken besides wrong KCSAN complaints. > > Reported-by: kernel test robot > Closes: https://lore.kernel.org/oe-lkp/202405281431.c46a3be9-...@intel.com > Signed-off-by: David Hildenbrand Reviewed-by: Oscar Salvador Thanks! -- Oscar Salvador SUSE Labs
Re: [PATCH v2 1/5] dt-bindings: remoteproc: qcom,sa8775p-pas: Document the SA8775p ADSP, CDSP and GPDSP
On 28/05/2024 09:26, Bartosz Golaszewski wrote: > On Mon, May 27, 2024 at 10:56 AM Krzysztof Kozlowski wrote: >> >> On 27/05/2024 10:43, Bartosz Golaszewski wrote: >>> From: Bartosz Golaszewski >>> >>> Document the components used to boot the ADSP, CDSP0, CDSP1, GPDSP0 and >>> GPDSP1 on the SA8775p SoC. >>> >>> Co-developed-by: Tengfei Fan >> >> Missing SoB. >> > > Does it though? The patch never passed through Tengfei's hands, I just > wanted to give him credit for the work modifying the sm8550-pas > bindings. Then what was co-developed by Tengfei? If nothing, then indeed no SoB but also no Co-developed-by. Docs are clear here: every Co-developed-by *must* be followed by SoB. Best regards, Krzysztof
Re: [linus:master] [mm] d99e3140a4: BUG:KCSAN:data-race_in_folio_remove_rmap_ptes/print_report
On 2024/5/28 15:43, David Hildenbrand wrote:
> Am 28.05.24 um 09:11 schrieb kernel test robot:
>>
>>
>> Hello,
>>
>> kernel test robot noticed
>> "BUG:KCSAN:data-race_in_folio_remove_rmap_ptes/print_report" on:
>>
>> commit: d99e3140a4d33e26066183ff727d8f02f56bec64 ("mm: turn
>> folio_test_hugetlb into a PageType")
>> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git master
>>
>> [test failed on linus/master c760b3725e52403dc1b28644fb09c47a83cacea6]
>> [test failed on linux-next/master 3689b0ef08b70e4e03b82ebd37730a03a672853a]
>>
>> in testcase: trinity
>> version: trinity-i386-abe9de86-1_20230429
>> with following parameters:
>>
>> runtime: 300s
>> group: group-04
>> nr_groups: 5
>>
>>
>>
>> compiler: gcc-13
>> test machine: qemu-system-x86_64 -enable-kvm -cpu SandyBridge -smp 2 -m 16G
>>
>> (please refer to attached dmesg/kmsg for entire log/backtrace)
>>
>>
>> we noticed this issue does not always happen. we also noticed there are
>> different random KCSAN issues for both this commit and its parent. but below
>> 4 only happen on this commit with not small rate and keep clean on parent.
>>
>
> Likely that's just a page_type check racing against concurrent
> mapcount changes.
>
> In __folio_rmap_sanity_checks() we check
> VM_WARN_ON_FOLIO(folio_test_hugetlb(folio), folio);
>
> To make sure we don't get hugetlb folios in the wrong rmap code path. That
> can easily race with concurrent mapcount changes, just like any other
> page_type checks that end up in folio_test_type/page_has_type e.g., from
> PFN walkers.
>
> Load tearing in these functions shouldn't really result in false positives
> (what we care about), but READ_ONCE shouldn't hurt or make a difference.
>
>
> From b03dc9bf27571442d886d8da624a4e4f737433f2 Mon Sep 17 00:00:00 2001
> From: David Hildenbrand
> Date: Tue, 28 May 2024 09:37:20 +0200
> Subject: [PATCH] mm: read page_type using READ_ONCE
>
> KCSAN complains about possible data races: while we check for a
> page_type -- for example for sanity checks -- we might concurrently
> modify the mapcount that overlays page_type.
>
> Let's use READ_ONCE to avoid laod tearing (shouldn't make a difference)
> and to make KCSAN happy.
>
> Note: nothing should really be broken besides wrong KCSAN complaints.
>
> Reported-by: kernel test robot
> Closes: https://lore.kernel.org/oe-lkp/202405281431.c46a3be9-...@intel.com
> Signed-off-by: David Hildenbrand
LGTM. Thanks for fixing.
Reviewed-by: Miaohe Lin
Thanks.
.
[PATCH net-next v5 06/13] mm: page_frag: add '_va' suffix to page_frag API
Currently the page_frag API is returning 'virtual address'
or 'va' when allocing and expecting 'virtual address' or
'va' as input when freeing.
As we are about to support new use cases that the caller
need to deal with 'struct page' or need to deal with both
'va' and 'struct page'. In order to differentiate the API
handling between 'va' and 'struct page', add '_va' suffix
to the corresponding API mirroring the page_pool_alloc_va()
API of the page_pool. So that callers expecting to deal with
va, page or both va and page may call page_frag_alloc_va*,
page_frag_alloc_pg*, or page_frag_alloc* API accordingly.
CC: Alexander Duyck
Signed-off-by: Yunsheng Lin
---
drivers/net/ethernet/google/gve/gve_rx.c | 4 ++--
drivers/net/ethernet/intel/ice/ice_txrx.c | 2 +-
drivers/net/ethernet/intel/ice/ice_txrx.h | 2 +-
drivers/net/ethernet/intel/ice/ice_txrx_lib.c | 2 +-
.../net/ethernet/intel/ixgbevf/ixgbevf_main.c | 4 ++--
.../marvell/octeontx2/nic/otx2_common.c | 2 +-
drivers/net/ethernet/mediatek/mtk_wed_wo.c| 4 ++--
drivers/nvme/host/tcp.c | 8 +++
drivers/nvme/target/tcp.c | 22 +--
drivers/vhost/net.c | 6 ++---
include/linux/page_frag_cache.h | 21 +-
include/linux/skbuff.h| 2 +-
kernel/bpf/cpumap.c | 2 +-
mm/page_frag_cache.c | 12 +-
mm/page_frag_test.c | 11 +-
net/core/skbuff.c | 18 +++
net/core/xdp.c| 2 +-
net/rxrpc/txbuf.c | 15 +++--
net/sunrpc/svcsock.c | 6 ++---
19 files changed, 74 insertions(+), 71 deletions(-)
diff --git a/drivers/net/ethernet/google/gve/gve_rx.c
b/drivers/net/ethernet/google/gve/gve_rx.c
index acb73d4d0de6..b6c10100e462 100644
--- a/drivers/net/ethernet/google/gve/gve_rx.c
+++ b/drivers/net/ethernet/google/gve/gve_rx.c
@@ -729,7 +729,7 @@ static int gve_xdp_redirect(struct net_device *dev, struct
gve_rx_ring *rx,
total_len = headroom + SKB_DATA_ALIGN(len) +
SKB_DATA_ALIGN(sizeof(struct skb_shared_info));
- frame = page_frag_alloc(&rx->page_cache, total_len, GFP_ATOMIC);
+ frame = page_frag_alloc_va(&rx->page_cache, total_len, GFP_ATOMIC);
if (!frame) {
u64_stats_update_begin(&rx->statss);
rx->xdp_alloc_fails++;
@@ -742,7 +742,7 @@ static int gve_xdp_redirect(struct net_device *dev, struct
gve_rx_ring *rx,
err = xdp_do_redirect(dev, &new, xdp_prog);
if (err)
- page_frag_free(frame);
+ page_frag_free_va(frame);
return err;
}
diff --git a/drivers/net/ethernet/intel/ice/ice_txrx.c
b/drivers/net/ethernet/intel/ice/ice_txrx.c
index 8bb743f78fcb..399b317c509d 100644
--- a/drivers/net/ethernet/intel/ice/ice_txrx.c
+++ b/drivers/net/ethernet/intel/ice/ice_txrx.c
@@ -126,7 +126,7 @@ ice_unmap_and_free_tx_buf(struct ice_tx_ring *ring, struct
ice_tx_buf *tx_buf)
dev_kfree_skb_any(tx_buf->skb);
break;
case ICE_TX_BUF_XDP_TX:
- page_frag_free(tx_buf->raw_buf);
+ page_frag_free_va(tx_buf->raw_buf);
break;
case ICE_TX_BUF_XDP_XMIT:
xdp_return_frame(tx_buf->xdpf);
diff --git a/drivers/net/ethernet/intel/ice/ice_txrx.h
b/drivers/net/ethernet/intel/ice/ice_txrx.h
index feba314a3fe4..6379f57d8228 100644
--- a/drivers/net/ethernet/intel/ice/ice_txrx.h
+++ b/drivers/net/ethernet/intel/ice/ice_txrx.h
@@ -148,7 +148,7 @@ static inline int ice_skb_pad(void)
* @ICE_TX_BUF_DUMMY: dummy Flow Director packet, unmap and kfree()
* @ICE_TX_BUF_FRAG: mapped skb OR &xdp_buff frag, only unmap DMA
* @ICE_TX_BUF_SKB: &sk_buff, unmap and consume_skb(), update stats
- * @ICE_TX_BUF_XDP_TX: &xdp_buff, unmap and page_frag_free(), stats
+ * @ICE_TX_BUF_XDP_TX: &xdp_buff, unmap and page_frag_free_va(), stats
* @ICE_TX_BUF_XDP_XMIT: &xdp_frame, unmap and xdp_return_frame(), stats
* @ICE_TX_BUF_XSK_TX: &xdp_buff on XSk queue, xsk_buff_free(), stats
*/
diff --git a/drivers/net/ethernet/intel/ice/ice_txrx_lib.c
b/drivers/net/ethernet/intel/ice/ice_txrx_lib.c
index 2719f0e20933..a1a41a14df0d 100644
--- a/drivers/net/ethernet/intel/ice/ice_txrx_lib.c
+++ b/drivers/net/ethernet/intel/ice/ice_txrx_lib.c
@@ -250,7 +250,7 @@ ice_clean_xdp_tx_buf(struct device *dev, struct ice_tx_buf
*tx_buf,
switch (tx_buf->type) {
case ICE_TX_BUF_XDP_TX:
- page_frag_free(tx_buf->raw_buf);
+ page_frag_free_va(tx_buf->raw_buf);
break;
case ICE_TX_BUF_XDP_XMIT:
xdp_return_frame_bulk(tx_buf->xdpf, bq);
diff --git a/drivers/net/ethernet/intel/ixgbevf/ixgbevf_main.c
b/drivers/net/ethernet/intel/ixgbevf/
[PATCH net-next v5 07/13] mm: page_frag: avoid caller accessing 'page_frag_cache' directly
Use appropriate frag_page API instead of caller accessing
'page_frag_cache' directly.
CC: Alexander Duyck
Signed-off-by: Yunsheng Lin
---
drivers/vhost/net.c | 2 +-
include/linux/page_frag_cache.h | 10 ++
mm/page_frag_test.c | 2 +-
net/core/skbuff.c | 6 +++---
net/rxrpc/conn_object.c | 4 +---
net/rxrpc/local_object.c| 4 +---
net/sunrpc/svcsock.c| 6 ++
7 files changed, 19 insertions(+), 15 deletions(-)
diff --git a/drivers/vhost/net.c b/drivers/vhost/net.c
index 6691fac01e0d..b2737dc0dc50 100644
--- a/drivers/vhost/net.c
+++ b/drivers/vhost/net.c
@@ -1325,7 +1325,7 @@ static int vhost_net_open(struct inode *inode, struct
file *f)
vqs[VHOST_NET_VQ_RX]);
f->private_data = n;
- n->pf_cache.va = NULL;
+ page_frag_cache_init(&n->pf_cache);
return 0;
}
diff --git a/include/linux/page_frag_cache.h b/include/linux/page_frag_cache.h
index c6fde197a6eb..6ac3a25089d1 100644
--- a/include/linux/page_frag_cache.h
+++ b/include/linux/page_frag_cache.h
@@ -23,6 +23,16 @@ struct page_frag_cache {
bool pfmemalloc;
};
+static inline void page_frag_cache_init(struct page_frag_cache *nc)
+{
+ nc->va = NULL;
+}
+
+static inline bool page_frag_cache_is_pfmemalloc(struct page_frag_cache *nc)
+{
+ return !!nc->pfmemalloc;
+}
+
void page_frag_cache_drain(struct page_frag_cache *nc);
void __page_frag_cache_drain(struct page *page, unsigned int count);
void *__page_frag_alloc_va_align(struct page_frag_cache *nc,
diff --git a/mm/page_frag_test.c b/mm/page_frag_test.c
index bb9f5aa84631..641255136105 100644
--- a/mm/page_frag_test.c
+++ b/mm/page_frag_test.c
@@ -337,7 +337,7 @@ static int __init page_frag_test_init(void)
u64 duration;
int ret;
- test_frag.va = NULL;
+ page_frag_cache_init(&test_frag);
atomic_set(&nthreads, 2);
init_completion(&wait);
diff --git a/net/core/skbuff.c b/net/core/skbuff.c
index dca4e7445348..caee22db1cc7 100644
--- a/net/core/skbuff.c
+++ b/net/core/skbuff.c
@@ -741,12 +741,12 @@ struct sk_buff *__netdev_alloc_skb(struct net_device
*dev, unsigned int len,
if (in_hardirq() || irqs_disabled()) {
nc = this_cpu_ptr(&netdev_alloc_cache);
data = page_frag_alloc_va(nc, len, gfp_mask);
- pfmemalloc = nc->pfmemalloc;
+ pfmemalloc = page_frag_cache_is_pfmemalloc(nc);
} else {
local_bh_disable();
nc = this_cpu_ptr(&napi_alloc_cache.page);
data = page_frag_alloc_va(nc, len, gfp_mask);
- pfmemalloc = nc->pfmemalloc;
+ pfmemalloc = page_frag_cache_is_pfmemalloc(nc);
local_bh_enable();
}
@@ -834,7 +834,7 @@ struct sk_buff *napi_alloc_skb(struct napi_struct *napi,
unsigned int len)
len = SKB_HEAD_ALIGN(len);
data = page_frag_alloc_va(&nc->page, len, gfp_mask);
- pfmemalloc = nc->page.pfmemalloc;
+ pfmemalloc = page_frag_cache_is_pfmemalloc(&nc->page);
}
if (unlikely(!data))
diff --git a/net/rxrpc/conn_object.c b/net/rxrpc/conn_object.c
index 1539d315afe7..694c4df7a1a3 100644
--- a/net/rxrpc/conn_object.c
+++ b/net/rxrpc/conn_object.c
@@ -337,9 +337,7 @@ static void rxrpc_clean_up_connection(struct work_struct
*work)
*/
rxrpc_purge_queue(&conn->rx_queue);
- if (conn->tx_data_alloc.va)
- __page_frag_cache_drain(virt_to_page(conn->tx_data_alloc.va),
- conn->tx_data_alloc.pagecnt_bias);
+ page_frag_cache_drain(&conn->tx_data_alloc);
call_rcu(&conn->rcu, rxrpc_rcu_free_connection);
}
diff --git a/net/rxrpc/local_object.c b/net/rxrpc/local_object.c
index 504453c688d7..a8cffe47cf01 100644
--- a/net/rxrpc/local_object.c
+++ b/net/rxrpc/local_object.c
@@ -452,9 +452,7 @@ void rxrpc_destroy_local(struct rxrpc_local *local)
#endif
rxrpc_purge_queue(&local->rx_queue);
rxrpc_purge_client_connections(local);
- if (local->tx_alloc.va)
- __page_frag_cache_drain(virt_to_page(local->tx_alloc.va),
- local->tx_alloc.pagecnt_bias);
+ page_frag_cache_drain(&local->tx_alloc);
}
/*
diff --git a/net/sunrpc/svcsock.c b/net/sunrpc/svcsock.c
index 42d20412c1c3..4b1e87187614 100644
--- a/net/sunrpc/svcsock.c
+++ b/net/sunrpc/svcsock.c
@@ -1609,7 +1609,6 @@ static void svc_tcp_sock_detach(struct svc_xprt *xprt)
static void svc_sock_free(struct svc_xprt *xprt)
{
struct svc_sock *svsk = container_of(xprt, struct svc_sock, sk_xprt);
- struct page_frag_cache *pfc = &svsk->sk_frag_cache;
struct socket *sock = svsk->sk_sock;
trace_svcsock_free(svsk, sock);
@@ -1619,8 +1618,7 @@ static void svc_sock_free(struct svc_xprt *xprt)
sockfd_put(sock);
el
Re: [PATCH] [v5] kallsyms: rework symbol lookup return codes
Hi Arnd,
On Thu, Apr 4, 2024 at 4:52 PM Arnd Bergmann wrote:
> From: Arnd Bergmann
>
> Building with W=1 in some configurations produces a false positive
> warning for kallsyms:
>
> kernel/kallsyms.c: In function '__sprint_symbol.isra':
> kernel/kallsyms.c:503:17: error: 'strcpy' source argument is the same as
> destination [-Werror=restrict]
> 503 | strcpy(buffer, name);
> | ^~~~
>
> This originally showed up while building with -O3, but later started
> happening in other configurations as well, depending on inlining
> decisions. The underlying issue is that the local 'name' variable is
> always initialized to the be the same as 'buffer' in the called functions
> that fill the buffer, which gcc notices while inlining, though it could
> see that the address check always skips the copy.
>
> The calling conventions here are rather unusual, as all of the internal
> lookup functions (bpf_address_lookup, ftrace_mod_address_lookup,
> ftrace_func_address_lookup, module_address_lookup and
> kallsyms_lookup_buildid) already use the provided buffer and either return
> the address of that buffer to indicate success, or NULL for failure,
> but the callers are written to also expect an arbitrary other buffer
> to be returned.
>
> Rework the calling conventions to return the length of the filled buffer
> instead of its address, which is simpler and easier to follow as well
> as avoiding the warning. Leave only the kallsyms_lookup() calling conventions
> unchanged, since that is called from 16 different functions and
> adapting this would be a much bigger change.
>
> Link: https://lore.kernel.org/all/20200107214042.855757-1-a...@arndb.de/
> Link: https://lore.kernel.org/lkml/20240326130647.7bfb1...@gandalf.local.home/
> Reviewed-by: Luis Chamberlain
> Acked-by: Steven Rostedt (Google)
> Signed-off-by: Arnd Bergmann
> ---
> v5: fix ftrace_mod_address_lookup return value,
> rebased on top of 2e114248e086 ("bpf: Replace deprecated strncpy with
> strscpy")
> v4: fix string length
> v3: use strscpy() instead of strlcpy()
> v2: complete rewrite after the first patch was rejected (in 2020). This
> is now one of only two warnings that are in the way of enabling
> -Wextra/-Wrestrict by default.
Aha, commit 06bb7fc0feee32d9 ("kbuild: turn on -Wrestrict by default")
still made v6.10-rc1, without this one...
> Signed-off-by: Arnd Bergmann
Thanks, this fixes
kernel/kallsyms.c: In function ‘__sprint_symbol.constprop’:
kernel/kallsyms.c:492:17: warning: ‘strcpy’ source argument is the
same as destination [-Werror=restrict]
492 | strcpy(buffer, name);
| ^~~~
I am seeing with shmobile_defconfig and gcc version 11.4.0 (Ubuntu
11.4.0-1ubuntu1~22.04).
Tested-by: Geert Uytterhoeven
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
Re: [PATCH] rv: Update rv_en(dis)able_monitor doc to match kernel-doc
On 5/20/24 07:42, Yang Li wrote: > The patch updates the function documentation comment for > rv_en(dis)able_monitor to adhere to the kernel-doc specification. > > Signed-off-by: Yang Li Acked-by: Daniel Bristot de Oliveira Thanks -- Daniel
Re: (subset) [PATCH v2 0/3] arm64: dts: qcom: msm8996: enable fastrpc and glink-edge
On Thu, 18 Apr 2024 09:44:19 +0300, Dmitry Baryshkov wrote: > Enable the FastRPC and glink-edge nodes on MSM8996 platform. Tested on > APQ8096 Dragonboard820c. > > Applied, thanks! [2/3] arm64: dts: qcom: msm8996: add glink-edge nodes commit: 56ae780a4387d71dd709895acd95112d01f37fb4 [3/3] arm64: dts: msm8996: add fastrpc nodes commit: 1b80b83f893dd69efe3c3bf84cd9f661218ccfc0 Best regards, -- Bjorn Andersson
[PATCH] mctp i2c: Add rx trace
mctp-i2c rx implementation doesn't call
__i2c_transfer which calls the i2c reply trace function.
Add an mctp_reply trace function that will be used instead.
Signed-off-by: Tal Yacobi
---
drivers/net/mctp/mctp-i2c.c | 3 +++
include/trace/events/mctp.h | 16
2 files changed, 19 insertions(+)
diff --git a/drivers/net/mctp/mctp-i2c.c b/drivers/net/mctp/mctp-i2c.c
index b37a9e4bade4..22754f4e4a8d 100644
--- a/drivers/net/mctp/mctp-i2c.c
+++ b/drivers/net/mctp/mctp-i2c.c
@@ -24,6 +24,7 @@
#include
#include
#include
+#include
/* byte_count is limited to u8 */
#define MCTP_I2C_MAXBLOCK 255
@@ -312,6 +313,8 @@ static int mctp_i2c_recv(struct mctp_i2c_dev *midev)
return -ENOMEM;
}
+ trace_mctp_reply(midev->rx_buffer, recvlen);
+
skb->protocol = htons(ETH_P_MCTP);
skb_put_data(skb, midev->rx_buffer, recvlen);
skb_reset_mac_header(skb);
diff --git a/include/trace/events/mctp.h b/include/trace/events/mctp.h
index 165cf25f77a7..d115c353dff9 100644
--- a/include/trace/events/mctp.h
+++ b/include/trace/events/mctp.h
@@ -73,6 +73,22 @@ TRACE_EVENT(mctp_key_release,
)
);
+TRACE_EVENT(mctp_reply,
+ TP_PROTO(const u8 *rx_buffer, const size_t recvlen),
+ TP_ARGS(rx_buffer, recvlen),
+ TP_STRUCT__entry(
+ __field(__u16, len)
+ __dynamic_array(__u8, buf, recvlen)),
+ TP_fast_assign(
+ __entry->len = (__u16) recvlen;
+ memcpy(__get_dynamic_array(buf), rx_buffer, recvlen);
+ ),
+ TP_printk("l=%u [%*phD]",
+ __entry->len,
+ __entry->len, __get_dynamic_array(buf)
+ )
+);
+
#endif
#include
--
2.43.0
Re: [PATCH v3 0/2] x86/sgx: Fix two data races in EAUG/EREMOVE flows
On 5/17/24 04:06, Dmitrii Kuvaiskii wrote: > We wrote a trivial stress test to reproduce the hangs observed in > real-world applications. The test stresses #PF-based page allocation and > SGX_IOC_ENCLAVE_REMOVE_PAGES flows in the SGX driver: This seems like something we'd want in the kernel SGX selftests.
Re: [PATCH v3 2/2] x86/sgx: Resolve EREMOVE page vs EAUG page data race
On 5/17/24 04:06, Dmitrii Kuvaiskii wrote:
...
First, why is SGX so special here? How is the SGX problem different
than what the core mm code does?
> --- a/arch/x86/kernel/cpu/sgx/encl.h
> +++ b/arch/x86/kernel/cpu/sgx/encl.h
> @@ -25,6 +25,9 @@
> /* 'desc' bit marking that the page is being reclaimed. */
> #define SGX_ENCL_PAGE_BEING_RECLAIMEDBIT(3)
>
> +/* 'desc' bit marking that the page is being removed. */
> +#define SGX_ENCL_PAGE_BEING_REMOVED BIT(2)
Second, convince me that this _needs_ a new bit. Why can't we just have
a bit that effectively means "return EBUSY if you see this bit when
handling a fault".
> struct sgx_encl_page {
> unsigned long desc;
> unsigned long vm_max_prot_bits:8;
> diff --git a/arch/x86/kernel/cpu/sgx/ioctl.c b/arch/x86/kernel/cpu/sgx/ioctl.c
> index 5d390df21440..de59219ae794 100644
> --- a/arch/x86/kernel/cpu/sgx/ioctl.c
> +++ b/arch/x86/kernel/cpu/sgx/ioctl.c
> @@ -1142,6 +1142,7 @@ static long sgx_encl_remove_pages(struct sgx_encl *encl,
>* Do not keep encl->lock because of dependency on
>* mmap_lock acquired in sgx_zap_enclave_ptes().
>*/
> + entry->desc |= SGX_ENCL_PAGE_BEING_REMOVED;
This also needs a comment, no matter what.
Re: [PATCH 0/3] tracing: Fix some selftest issues
On Mon, 27 May 2024 19:29:07 -0400 Steven Rostedt wrote: > On Sun, 26 May 2024 19:10:57 +0900 > "Masami Hiramatsu (Google)" wrote: > > > Hi, > > > > Here is a series of some fixes/improvements for the test modules and boot > > time selftest of kprobe events. I found a WARNING message with some boot > > time selftest configuration, which came from the combination of embedded > > kprobe generate API tests module and ftrace boot-time selftest. So the main > > problem is that the test module should not be built-in. But I also think > > this WARNING message is useless (because there are warning messages already) > > and the cleanup code is redundant. This series fixes those issues. > > Note, when I enable trace tests as builtin instead of modules, I just > disable the bootup self tests when it detects this. This helps with > doing tests via config options than having to add user space code that > loads modules. > > Could you do something similar? OK, in that case, I would like to move the test cleanup code in module_exit function into the end of module_init function. It looks there is no reason to split those into 2 parts. Thank you, > > -- Steve > > > > > > Thank you, > > > > --- > > > > Masami Hiramatsu (Google) (3): > > tracing: Build event generation tests only as modules > > tracing/kprobe: Remove unneeded WARN_ON_ONCE() in selftests > > tracing/kprobe: Remove cleanup code unrelated to selftest > > -- Masami Hiramatsu (Google)
Re: (subset) [PATCH 0/2] Fix msm8974 apcs syscon compatible
On Mon, 08 Apr 2024 21:32:02 +0200, Luca Weiss wrote: > Finally fix a warning about the apcs-global syscon used on msm8974 that > has been around forever. > > Applied, thanks! [2/2] ARM: dts: qcom: msm8974: Use proper compatible for APCS syscon commit: c133cfc12cd717b72ce534477415446e1c33de47 Best regards, -- Bjorn Andersson
Re: (subset) [PATCH v2 0/2] Allow gpio-hog nodes in qcom,pmic-gpio bindings (& dt fixup)
On Tue, 09 Apr 2024 20:36:35 +0200, Luca Weiss wrote: > Resolve the dt validation failure on Nexus 5. > > Applied, thanks! [2/2] ARM: dts: qcom: msm8974-hammerhead: Update gpio hog node name commit: 92b9ce5b11d7ba281f5bf0029185d5c891b29344 Best regards, -- Bjorn Andersson
Re: Bug in Kernel 6.8.x, 6.9.x Causing Trace/Panic During Shutdown/Reboot
On Tue, 28 May 2024 07:51:30 +0300
Ilkka Naulapää wrote:
> yeah, the cache_from_obj tracing bug (without panic) has been
> displayed quite some time now - maybe even since 6.7.x or so. I could
> try checking a few versions back for this and try bisecting it if I
> can find when this started.
>
OK, so I don't think the commit your last bisect hit is the cause of
the bug. It added a delay (via RCU) and is causing the real bug to blow
up more.
Can you add this patch to v6.9.2 and hopefully it crashes in a better
location that we can find where the mixup happened.
You may need to add the other commit (too if this doesn't trigger.
Thanks,
-- Steve
diff --git a/fs/tracefs/inode.c b/fs/tracefs/inode.c
index 417c840e6403..7af3f696696d 100644
--- a/fs/tracefs/inode.c
+++ b/fs/tracefs/inode.c
@@ -50,6 +50,7 @@ static struct inode *tracefs_alloc_inode(struct super_block
*sb)
list_add_rcu(&ti->list, &tracefs_inodes);
spin_unlock_irqrestore(&tracefs_inode_lock, flags);
+ ti->magic = 20240823;
return &ti->vfs_inode;
}
@@ -66,6 +67,7 @@ static void tracefs_free_inode(struct inode *inode)
struct tracefs_inode *ti = get_tracefs(inode);
unsigned long flags;
+ BUG_ON(ti->magic != 20240823);
spin_lock_irqsave(&tracefs_inode_lock, flags);
list_del_rcu(&ti->list);
spin_unlock_irqrestore(&tracefs_inode_lock, flags);
@@ -271,16 +273,6 @@ static const struct inode_operations
tracefs_file_inode_operations = {
.setattr= tracefs_setattr,
};
-struct inode *tracefs_get_inode(struct super_block *sb)
-{
- struct inode *inode = new_inode(sb);
- if (inode) {
- inode->i_ino = get_next_ino();
- simple_inode_init_ts(inode);
- }
- return inode;
-}
-
struct tracefs_mount_opts {
kuid_t uid;
kgid_t gid;
@@ -448,6 +440,17 @@ static const struct super_operations
tracefs_super_operations = {
.show_options = tracefs_show_options,
};
+struct inode *tracefs_get_inode(struct super_block *sb)
+{
+ struct inode *inode = new_inode(sb);
+ BUG_ON(sb->s_op != &tracefs_super_operations);
+ if (inode) {
+ inode->i_ino = get_next_ino();
+ simple_inode_init_ts(inode);
+ }
+ return inode;
+}
+
/*
* It would be cleaner if eventfs had its own dentry ops.
*
diff --git a/fs/tracefs/internal.h b/fs/tracefs/internal.h
index f704d8348357..dda7d2708e30 100644
--- a/fs/tracefs/internal.h
+++ b/fs/tracefs/internal.h
@@ -16,6 +16,7 @@ struct tracefs_inode {
};
/* The below gets initialized with memset_after(ti, 0, vfs_inode) */
struct list_headlist;
+ unsigned long magic;
unsigned long flags;
void*private;
};
Re: [PATCH] remoteproc: stm32_rproc: Fix mailbox interrupts queuing
On Tue, May 21, 2024 at 06:23:16PM +0200, Gwenael Treuveur wrote:
> Manage interrupt coming from coprocessor also when state is
> ATTACHED.
>
> Fixes: 35bdafda40cc ("remoteproc: stm32_rproc: Add mutex protection for
> workqueue")
> Signed-off-by: Gwenael Treuveur
> Acked-by: Arnaud Pouliquen
I will pickup this patch but this time only - next time all reviews and tagging
need to happend on the mailing list.
Mathieu
> ---
> drivers/remoteproc/stm32_rproc.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/remoteproc/stm32_rproc.c
> b/drivers/remoteproc/stm32_rproc.c
> index 88623df7d0c3..8c7f7950b80e 100644
> --- a/drivers/remoteproc/stm32_rproc.c
> +++ b/drivers/remoteproc/stm32_rproc.c
> @@ -294,7 +294,7 @@ static void stm32_rproc_mb_vq_work(struct work_struct
> *work)
>
> mutex_lock(&rproc->lock);
>
> - if (rproc->state != RPROC_RUNNING)
> + if (rproc->state != RPROC_RUNNING && rproc->state != RPROC_ATTACHED)
> goto unlock_mutex;
>
> if (rproc_vq_interrupt(rproc, mb->vq_id) == IRQ_NONE)
>
> base-commit: 4d5ba6ead1dc9fa298d727e92db40cd98564d1ac
> --
> 2.25.1
>
Re: [PATCH v5 2/7] dt-bindings: remoteproc: Add compatibility for TEE support
On Tue, May 21, 2024 at 10:09:56AM +0200, Arnaud Pouliquen wrote:
> The "st,stm32mp1-m4-tee" compatible is utilized in a system configuration
> where the Cortex-M4 firmware is loaded by the Trusted execution Environment
> (TEE).
> For instance, this compatible is used in both the Linux and OP-TEE
> device-tree:
> - In OP-TEE, a node is defined in the device tree with the
> st,stm32mp1-m4-tee to support signed remoteproc firmware.
> Based on DT properties, OP-TEE authenticates, loads, starts, and stops
> the firmware.
I don't see how firmware can be started and stopped. Please rework.
> - On Linux, when the compatibility is set, the Cortex-M resets should not
> be declared in the device tree.
This is a description of "what" is happening and not "why".
More comments to come shortly.
Thanks,
Mathieu
>
> Signed-off-by: Arnaud Pouliquen
> Reviewed-by: Rob Herring
> ---
> .../bindings/remoteproc/st,stm32-rproc.yaml | 51 ---
> 1 file changed, 43 insertions(+), 8 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/remoteproc/st,stm32-rproc.yaml
> b/Documentation/devicetree/bindings/remoteproc/st,stm32-rproc.yaml
> index 370af61d8f28..36ea54016b76 100644
> --- a/Documentation/devicetree/bindings/remoteproc/st,stm32-rproc.yaml
> +++ b/Documentation/devicetree/bindings/remoteproc/st,stm32-rproc.yaml
> @@ -16,7 +16,12 @@ maintainers:
>
> properties:
>compatible:
> -const: st,stm32mp1-m4
> +enum:
> + - st,stm32mp1-m4
> + - st,stm32mp1-m4-tee
> +description:
> + Use "st,stm32mp1-m4" for the Cortex-M4 coprocessor management by
> non-secure context
> + Use "st,stm32mp1-m4-tee" for the Cortex-M4 coprocessor management by
> secure context
>
>reg:
> description:
> @@ -142,21 +147,41 @@ properties:
> required:
>- compatible
>- reg
> - - resets
>
> allOf:
>- if:
>properties:
> -reset-names:
> - not:
> -contains:
> - const: hold_boot
> +compatible:
> + contains:
> +const: st,stm32mp1-m4
> then:
> + if:
> +properties:
> + reset-names:
> +not:
> + contains:
> +const: hold_boot
> + then:
> +required:
> + - st,syscfg-holdboot
> + else:
> +properties:
> + st,syscfg-holdboot: false
> +required:
> + - reset-names
>required:
> -- st,syscfg-holdboot
> -else:
> +- resets
> +
> + - if:
> + properties:
> +compatible:
> + contains:
> +const: st,stm32mp1-m4-tee
> +then:
>properties:
> st,syscfg-holdboot: false
> +reset-names: false
> +resets: false
>
> additionalProperties: false
>
> @@ -188,5 +213,15 @@ examples:
>st,syscfg-rsc-tbl = <&tamp 0x144 0x>;
>st,syscfg-m4-state = <&tamp 0x148 0x>;
> };
> + - |
> +#include
> +m4@1000 {
> + compatible = "st,stm32mp1-m4-tee";
> + reg = <0x1000 0x4>,
> +<0x3000 0x4>,
> +<0x3800 0x1>;
> + st,syscfg-rsc-tbl = <&tamp 0x144 0x>;
> + st,syscfg-m4-state = <&tamp 0x148 0x>;
> +};
>
> ...
> --
> 2.25.1
>
Re: [PATCH v5 4/7] remoteproc: core introduce rproc_set_rsc_table_on_start function
On Tue, May 21, 2024 at 10:09:58AM +0200, Arnaud Pouliquen wrote:
> Split rproc_start()to prepare the update of the management of
I don't see any "splitting" for rproc_start() in this patch. Please consider
rewording or removing.
> the cache table on start, for the support of the firmware loading
> by the TEE interface.
> - create rproc_set_rsc_table_on_start() to address the management of
> the cache table in a specific function, as done in
> rproc_reset_rsc_table_on_stop().
> - rename rproc_set_rsc_table in rproc_set_rsc_table_on_attach()
> - move rproc_reset_rsc_table_on_stop() to be close to the
> rproc_set_rsc_table_on_start() function
This patch is really hard to read due to all 3 operations happening at the same
time. Please split in 3 smaller patches.
>
> Suggested-by: Mathieu Poirier
> Signed-off-by: Arnaud Pouliquen
> ---
> drivers/remoteproc/remoteproc_core.c | 116 ++-
> 1 file changed, 62 insertions(+), 54 deletions(-)
>
> diff --git a/drivers/remoteproc/remoteproc_core.c
> b/drivers/remoteproc/remoteproc_core.c
> index f276956f2c5c..42bca01f3bde 100644
> --- a/drivers/remoteproc/remoteproc_core.c
> +++ b/drivers/remoteproc/remoteproc_core.c
> @@ -1264,18 +1264,9 @@ void rproc_resource_cleanup(struct rproc *rproc)
> }
> EXPORT_SYMBOL(rproc_resource_cleanup);
>
> -static int rproc_start(struct rproc *rproc, const struct firmware *fw)
> +static int rproc_set_rsc_table_on_start(struct rproc *rproc, const struct
> firmware *fw)
> {
> struct resource_table *loaded_table;
> - struct device *dev = &rproc->dev;
> - int ret;
> -
> - /* load the ELF segments to memory */
> - ret = rproc_load_segments(rproc, fw);
> - if (ret) {
> - dev_err(dev, "Failed to load program segments: %d\n", ret);
> - return ret;
> - }
>
> /*
>* The starting device has been given the rproc->cached_table as the
> @@ -1291,6 +1282,64 @@ static int rproc_start(struct rproc *rproc, const
> struct firmware *fw)
> rproc->table_ptr = loaded_table;
> }
>
> + return 0;
> +}
> +
> +static int rproc_reset_rsc_table_on_stop(struct rproc *rproc)
> +{
> + /* A resource table was never retrieved, nothing to do here */
> + if (!rproc->table_ptr)
> + return 0;
> +
> + /*
> + * If a cache table exists the remote processor was started by
> + * the remoteproc core. That cache table should be used for
> + * the rest of the shutdown process.
> + */
> + if (rproc->cached_table)
> + goto out;
> +
> + /*
> + * If we made it here the remote processor was started by another
> + * entity and a cache table doesn't exist. As such make a copy of
> + * the resource table currently used by the remote processor and
> + * use that for the rest of the shutdown process. The memory
> + * allocated here is free'd in rproc_shutdown().
> + */
> + rproc->cached_table = kmemdup(rproc->table_ptr,
> + rproc->table_sz, GFP_KERNEL);
> + if (!rproc->cached_table)
> + return -ENOMEM;
> +
> + /*
> + * Since the remote processor is being switched off the clean table
> + * won't be needed. Allocated in rproc_set_rsc_table_on_start().
> + */
> + kfree(rproc->clean_table);
> +
> +out:
> + /*
> + * Use a copy of the resource table for the remainder of the
> + * shutdown process.
> + */
> + rproc->table_ptr = rproc->cached_table;
> + return 0;
> +}
> +
> +static int rproc_start(struct rproc *rproc, const struct firmware *fw)
> +{
> + struct device *dev = &rproc->dev;
> + int ret;
> +
> + /* load the ELF segments to memory */
> + ret = rproc_load_segments(rproc, fw);
> + if (ret) {
> + dev_err(dev, "Failed to load program segments: %d\n", ret);
> + return ret;
> + }
> +
> + rproc_set_rsc_table_on_start(rproc, fw);
> +
> ret = rproc_prepare_subdevices(rproc);
> if (ret) {
> dev_err(dev, "failed to prepare subdevices for %s: %d\n",
> @@ -1450,7 +1499,7 @@ static int rproc_fw_boot(struct rproc *rproc, const
> struct firmware *fw)
> return ret;
> }
>
> -static int rproc_set_rsc_table(struct rproc *rproc)
> +static int rproc_set_rsc_table_on_attach(struct rproc *rproc)
> {
> struct resource_table *table_ptr;
> struct device *dev = &rproc->dev;
> @@ -1540,54 +1589,13 @@ static int rproc_reset_rsc_table_on_detach(struct
> rproc *rproc)
>
> /*
>* The clean resource table is no longer needed. Allocated in
> - * rproc_set_rsc_table().
> + * rproc_set_rsc_table_on_attach().
>*/
> kfree(rproc->clean_table);
>
> return 0;
> }
>
> -static int rproc_reset_rsc_table_on_stop(struct rproc *rproc)
> -{
> - /* A resource table was never retrieved, nothing to do here */
> - if (!rproc->table_ptr)
> -
Re: [PATCH v10] remoteproc: qcom: Move minidump related layout and API to soc/qcom directory
On Fri, May 03, 2024 at 01:48:07PM GMT, Mukesh Ojha wrote:
> Currently, Qualcomm Minidump is being used to collect mini version of
> remoteproc coredump with the help of boot firmware however, Minidump
> as a feature is not limited to be used only for remote processor and
> can also be used for Application processors. So, in preparation of
> using it move the Minidump related data structure and its function
> to its own file under drivers/soc/qcom with qcom_rproc_minidump.c
> which clearly says it is only for remoteproc minidump.
>
> Extra changes made apart from the movement is,
> 1. Adds new config, kernel headers and module macros to get this
>module compiled.
> 2. Guards the qcom_minidump() with CONFIG_QCOM_RPROC_MINIDUMP.
> 3. Selects this QCOM_RPROC_MINIDUMP config when QCOM_RPROC_COMMON
>enabled.
> 4. Added new header qcom_minidump.h .
>
> Signed-off-by: Mukesh Ojha
I wouldn't be able to merge this without anything depending on it...
[..]
> diff --git a/drivers/soc/qcom/qcom_rproc_minidump.c
> b/drivers/soc/qcom/qcom_rproc_minidump.c
[..]
> +void qcom_minidump(struct rproc *rproc, unsigned int minidump_id,
> + void (*rproc_dumpfn_t)(struct rproc *rproc,
> + struct rproc_dump_segment *segment, void *dest, size_t offset,
> + size_t size))
> +{
> + int ret;
> + struct minidump_subsystem *subsystem;
> + struct minidump_global_toc *toc;
> +
> + /* Get Global minidump ToC*/
> + toc = qcom_smem_get(QCOM_SMEM_HOST_ANY, SBL_MINIDUMP_SMEM_ID, NULL);
> +
> + /* check if global table pointer exists and init is set */
> + if (IS_ERR(toc) || !toc->status) {
> + dev_err(&rproc->dev, "Minidump TOC not found in SMEM\n");
> + return;
> + }
> +
> + /* Get subsystem table of contents using the minidump id */
> + subsystem = &toc->subsystems[minidump_id];
> +
> + /**
> + * Collect minidump if SS ToC is valid and segment table
> + * is initialized in memory and encryption status is set.
> + */
> + if (subsystem->regions_baseptr == 0 ||
> + le32_to_cpu(subsystem->status) != 1 ||
> + le32_to_cpu(subsystem->enabled) != MINIDUMP_SS_ENABLED) {
> + return rproc_coredump(rproc);
> + }
> +
> + if (le32_to_cpu(subsystem->encryption_status) != MINIDUMP_SS_ENCR_DONE)
> {
> + dev_err(&rproc->dev, "Minidump not ready, skipping\n");
> + return;
> + }
> +
> + /**
> + * Clear out the dump segments populated by parse_fw before
> + * re-populating them with minidump segments.
> + */
> + rproc_coredump_cleanup(rproc);
I don't think this should be invoked outside drivers/remoteproc, and the
comment talks about a remoteproc-internal concern...
> +
> + ret = qcom_add_minidump_segments(rproc, subsystem, rproc_dumpfn_t);
This function changes the internal state of the remoteproc and relies on
other operations to clean things up.
I think we could come up with a better design of this, and I don't think
we should spread this outside of the remoteproc framework.
Regards,
Bjorn
> + if (ret) {
> + dev_err(&rproc->dev, "Failed with error: %d while adding
> minidump entries\n", ret);
> + goto clean_minidump;
> + }
> + rproc_coredump_using_sections(rproc);
> +clean_minidump:
> + qcom_minidump_cleanup(rproc);
> +}
> +EXPORT_SYMBOL_GPL(qcom_minidump);
> +
> +MODULE_DESCRIPTION("Qualcomm Remoteproc Minidump helper module");
> +MODULE_LICENSE("GPL");
> diff --git a/include/soc/qcom/qcom_minidump.h
> b/include/soc/qcom/qcom_minidump.h
> new file mode 100644
> index ..0fe156066bc0
> --- /dev/null
> +++ b/include/soc/qcom/qcom_minidump.h
> @@ -0,0 +1,23 @@
> +/* SPDX-License-Identifier: GPL-2.0-only */
> +/*
> + * Copyright (c) 2023 Qualcomm Innovation Center, Inc. All rights reserved.
> + */
> +
> +#ifndef _QCOM_MINIDUMP_H_
> +#define _QCOM_MINIDUMP_H_
> +
> +struct rproc;
> +struct rproc_dump_segment;
> +
> +#if IS_ENABLED(CONFIG_QCOM_RPROC_MINIDUMP)
> +void qcom_minidump(struct rproc *rproc, unsigned int minidump_id,
> +void (*rproc_dumpfn_t)(struct rproc *rproc,
> +struct rproc_dump_segment *segment, void *dest, size_t
> offset,
> +size_t size));
> +#else
> +static inline void qcom_minidump(struct rproc *rproc, unsigned int
> minidump_id,
> +void (*rproc_dumpfn_t)(struct rproc *rproc,
> +struct rproc_dump_segment *segment, void *dest, size_t
> offset,
> +size_t size)) { }
> +#endif /* CONFIG_QCOM_RPROC_MINIDUMP */
> +#endif /* _QCOM_MINIDUMP_H_ */
> --
> 2.7.4
>
Re: [PATCH v5 5/7] remoteproc: core: support of the tee interface
On Tue, May 21, 2024 at 10:09:59AM +0200, Arnaud Pouliquen wrote:
> 1) on start:
> - Using the TEE loader, the resource table is loaded by an external entity.
> In such case the resource table address is not find from the firmware but
> provided by the TEE remoteproc framework.
> Use the rproc_get_loaded_rsc_table instead of rproc_find_loaded_rsc_table
> - test that rproc->cached_table is not null before performing the memcpy
>
> 2)on stop
> The use of the cached_table seems mandatory:
> - during recovery sequence to have a snapshot of the resource table
> resources used,
> - on stop to allow for the deinitialization of resources after the
> the remote processor has been shutdown.
> However if the TEE interface is being used, we first need to unmap the
> table_ptr before setting it to rproc->cached_table.
> The update of rproc->table_ptr to rproc->cached_table is performed in
> tee_remoteproc.
>
> Signed-off-by: Arnaud Pouliquen
> ---
> drivers/remoteproc/remoteproc_core.c | 31 +---
> 1 file changed, 23 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/remoteproc/remoteproc_core.c
> b/drivers/remoteproc/remoteproc_core.c
> index 42bca01f3bde..3a642151c983 100644
> --- a/drivers/remoteproc/remoteproc_core.c
> +++ b/drivers/remoteproc/remoteproc_core.c
> @@ -1267,6 +1267,7 @@ EXPORT_SYMBOL(rproc_resource_cleanup);
> static int rproc_set_rsc_table_on_start(struct rproc *rproc, const struct
> firmware *fw)
> {
> struct resource_table *loaded_table;
> + struct device *dev = &rproc->dev;
>
> /*
>* The starting device has been given the rproc->cached_table as the
> @@ -1276,12 +1277,21 @@ static int rproc_set_rsc_table_on_start(struct rproc
> *rproc, const struct firmwa
>* this information to device memory. We also update the table_ptr so
>* that any subsequent changes will be applied to the loaded version.
>*/
> - loaded_table = rproc_find_loaded_rsc_table(rproc, fw);
> - if (loaded_table) {
> - memcpy(loaded_table, rproc->cached_table, rproc->table_sz);
> - rproc->table_ptr = loaded_table;
> + if (rproc->tee_interface) {
> + loaded_table = rproc_get_loaded_rsc_table(rproc,
> &rproc->table_sz);
> + if (IS_ERR(loaded_table)) {
> + dev_err(dev, "can't get resource table\n");
> + return PTR_ERR(loaded_table);
> + }
> + } else {
> + loaded_table = rproc_find_loaded_rsc_table(rproc, fw);
> }
>
> + if (loaded_table && rproc->cached_table)
> + memcpy(loaded_table, rproc->cached_table, rproc->table_sz);
> +
Why is this not part of the else {} above as it was the case before this patch?
And why was an extra check for ->cached_table added?
This should be a simple change, i.e introduce an if {} else {} block to take
care of the two scenarios. Plus the comment is misplaced now.
More comments tomorrow.
Thanks,
Mathieu
> + rproc->table_ptr = loaded_table;
> +
> return 0;
> }
>
> @@ -1318,11 +1328,16 @@ static int rproc_reset_rsc_table_on_stop(struct rproc
> *rproc)
> kfree(rproc->clean_table);
>
> out:
> - /*
> - * Use a copy of the resource table for the remainder of the
> - * shutdown process.
> + /* If the remoteproc_tee interface is used, then we have first to unmap
> the resource table
> + * before updating the proc->table_ptr reference.
>*/
> - rproc->table_ptr = rproc->cached_table;
> + if (!rproc->tee_interface) {
> + /*
> + * Use a copy of the resource table for the remainder of the
> + * shutdown process.
> + */
> + rproc->table_ptr = rproc->cached_table;
> + }
> return 0;
> }
>
> --
> 2.25.1
>
Re: [PATCH DNM 2/2] arm64: dts: qcom: qcm6490-fairphone-fp5: Add DisplayPort sound support
On Fri, May 10, 2024 at 02:27:09PM GMT, Luca Weiss wrote:
> Add the required nodes for sound playback via a connected external
> display (DisplayPort over USB-C).
>
> Signed-off-by: Luca Weiss
> ---
> Depends on a bunch of patches upstream doing bringup of Display (DSI),
> DisplayPort, GPU, and then finally audio could land. But we're blocked
> on DPU 1:1:1 topology for all of that unfortunately.
>
> And also machine driver for sound just exists a bit hackily.
Thanks for sharing this, Luca. Can you please resubmit this once it's
ready to be merged, so that I don't need to keep track of it?
Regards,
Bjorn
> ---
> arch/arm64/boot/dts/qcom/qcm6490-fairphone-fp5.dts | 36
> ++
> 1 file changed, 36 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/qcom/qcm6490-fairphone-fp5.dts
> b/arch/arm64/boot/dts/qcom/qcm6490-fairphone-fp5.dts
> index 05bbf1da5cb8..2bbbcaeff95e 100644
> --- a/arch/arm64/boot/dts/qcom/qcm6490-fairphone-fp5.dts
> +++ b/arch/arm64/boot/dts/qcom/qcm6490-fairphone-fp5.dts
> @@ -14,6 +14,8 @@
> #include
> #include
> #include
> +#include
> +#include
> #include "sc7280.dtsi"
> #include "pm7250b.dtsi"
> #include "pm7325.dtsi"
> @@ -774,6 +776,12 @@ &pon_resin {
> status = "okay";
> };
>
> +&q6afedai {
> + dai@104 {
> + reg = ;
> + };
> +};
> +
> &qup_spi13_cs {
> drive-strength = <6>;
> bias-disable;
> @@ -847,6 +855,34 @@ &sdhc_2 {
> status = "okay";
> };
>
> +&sound {
> + compatible = "fairphone,fp5-sndcard";
> + model = "Fairphone 5";
> +
> + mm1-dai-link {
> + link-name = "MultiMedia1";
> + cpu {
> + sound-dai = <&q6asmdai MSM_FRONTEND_DAI_MULTIMEDIA1>;
> + };
> + };
> +
> + displayport-rx-dai-link {
> + link-name = "DisplayPort Playback";
> +
> + cpu {
> + sound-dai = <&q6afedai DISPLAY_PORT_RX>;
> + };
> +
> + platform {
> + sound-dai = <&q6routing>;
> + };
> +
> + codec {
> + sound-dai = <&mdss_dp>;
> + };
> + };
> +};
> +
> &spi13 {
> status = "okay";
>
>
> --
> 2.45.0
>
Re: [PATCH 0/3] tracing: Fix some selftest issues
On Wed, 29 May 2024 01:46:40 +0900 Masami Hiramatsu (Google) wrote: > On Mon, 27 May 2024 19:29:07 -0400 > Steven Rostedt wrote: > > > On Sun, 26 May 2024 19:10:57 +0900 > > "Masami Hiramatsu (Google)" wrote: > > > > > Hi, > > > > > > Here is a series of some fixes/improvements for the test modules and boot > > > time selftest of kprobe events. I found a WARNING message with some boot > > > time selftest configuration, which came from the combination of embedded > > > kprobe generate API tests module and ftrace boot-time selftest. So the > > > main > > > problem is that the test module should not be built-in. But I also think > > > this WARNING message is useless (because there are warning messages > > > already) > > > and the cleanup code is redundant. This series fixes those issues. > > > > Note, when I enable trace tests as builtin instead of modules, I just > > disable the bootup self tests when it detects this. This helps with > > doing tests via config options than having to add user space code that > > loads modules. > > > > Could you do something similar? > > OK, in that case, I would like to move the test cleanup code in > module_exit function into the end of module_init function. > It looks there is no reason to split those into 2 parts. Wait, I would like to hear Tom's opinion. I found following usage comments in the code. * Following that are a few examples using the created events to test * various ways of tracing a synthetic event. * * To test, select CONFIG_SYNTH_EVENT_GEN_TEST and build the module. * Then: * * # insmod kernel/trace/synth_event_gen_test.ko * # cat /sys/kernel/tracing/trace * * You should see several events in the trace buffer - * "create_synth_test", "empty_synth_test", and several instances of * "gen_synth_test". * * To remove the events, remove the module: * * # rmmod synth_event_gen_test Tom, is that intended behavior ? and are you expected to reuse these events outside of the module? e.g. load the test module and run some test script in user space which uses those events? As far as I can see, those tests are not intended to be embedded in the kernel because those are expected to be removed. Thank you, > > Thank you, > > > > > -- Steve > > > > > > > > > > Thank you, > > > > > > --- > > > > > > Masami Hiramatsu (Google) (3): > > > tracing: Build event generation tests only as modules > > > tracing/kprobe: Remove unneeded WARN_ON_ONCE() in selftests > > > tracing/kprobe: Remove cleanup code unrelated to selftest > > > > > > -- > Masami Hiramatsu (Google) -- Masami Hiramatsu (Google)
Re: [PATCH] mctp i2c: Add rx trace
Hi Tal, Thanks for the contribution! Some comments: > mctp-i2c rx implementation doesn't call > __i2c_transfer which calls the i2c reply trace function. No, but we can trace the i2c rx path through the trace_i2c_slave tracepoint. It is a little messier than tracing trace_i2c_write, but has been sufficient with the debugging I've needed in the past. > Add an mctp_reply trace function that will be used instead. Can you elaborate a little on what you were/are looking to inspect here? (mainly: which packet fields are you interested in?) That will help to determine the best approach here. Cheers, Jeremy
Re: [PATCH 0/2] Enable vibrator on PMI632 + Fairphone 3
On Thu, 18 Apr 2024 08:36:53 +0200, Luca Weiss wrote: > With the patches to add vibration support for PMI632 finally applied, > let's enable this for the PMI632 PMIC and Fairphone 3 smartphone. > > https://lore.kernel.org/linux-arm-msm/20240416-pm8xxx-vibrator-new-design-v11-0-7b1c951e1...@quicinc.com/ > > Patches have landed in the input tree: > https://git.kernel.org/pub/scm/linux/kernel/git/dtor/input.git/ > > [...] Applied, thanks! [1/2] arm64: dts: qcom: pmi632: Add vibrator commit: bbb1dd6402f9c67ea00bc6bf0e2a01d71db4c7fd [2/2] arm64: dts: qcom: sdm632-fairphone-fp3: Enable vibrator commit: ffaa4b5d5d07aed600d82929d8862263ce341a71 Best regards, -- Bjorn Andersson
Re: [PATCH] clk: qcom: gcc-sm6350: Fix gpll6* & gpll7 parents
On Wed, 08 May 2024 10:12:53 +0200, Luca Weiss wrote: > Both gpll6 and gpll7 are parented to CXO at 19.2 MHz and not to GPLL0 > which runs at 600 MHz. Also gpll6_out_even should have the parent gpll6 > and not gpll0. > > Adjust the parents of these clocks to make Linux report the correct rate > and not absurd numbers like gpll7 at ~25 GHz or gpll6 at 24 GHz. > > [...] Applied, thanks! [1/1] clk: qcom: gcc-sm6350: Fix gpll6* & gpll7 parents commit: 3414f41a13eb41db15c558fbc695466203dca4fa Best regards, -- Bjorn Andersson
Re: (subset) [PATCH 0/2] Mark qcom,ipc as deprecated in two schemas
On Thu, 25 Apr 2024 21:14:29 +0200, Luca Weiss wrote: > The mboxes property has been supported in those bindings since a while > and was always meant to the replace qcom,ipc properties, so let's mark > qcom,ipc as deprecated - and update the examples to use mboxes. > > Related: > https://lore.kernel.org/linux-arm-msm/20240424-apcs-mboxes-v1-0-6556c47cb...@z3ntu.xyz/ > > [...] Applied, thanks! [2/2] dt-bindings: soc: qcom,smp2p: Mark qcom,ipc as deprecated commit: 7ce966eb6f1288eb92bc2eb5df8933acee1ae6ed Best regards, -- Bjorn Andersson
Re: (subset) [PATCH v2 0/3] Convert qcom,hfpll documentation to yaml + related changes
On Sun, 18 Feb 2024 21:57:24 +0100, Luca Weiss wrote: > Finally touch the hfpll doc and convert it to yaml, and do some related > changes along the way. > > Applied, thanks! [3/3] arm64: dts: qcom: qcs404: Use qcs404-hfpll compatible for hfpll commit: 839936d9676bdc2e4dde63631131feb8870fa4d2 Best regards, -- Bjorn Andersson
Re: [PATCH 01/12] soc: qcom: add firmware name helper
On Mon, May 27, 2024 at 02:42:44PM GMT, Dmitry Baryshkov wrote: > On Thu, 23 May 2024 at 01:48, Bjorn Andersson > wrote: > > > > On Tue, May 21, 2024 at 03:08:31PM +0200, Dmitry Baryshkov wrote: > > > On Tue, 21 May 2024 at 13:20, Kalle Valo wrote: > > > > > > > > Dmitry Baryshkov writes: > > > > > > > > > On Tue, 21 May 2024 at 12:52, wrote: > > > > >> > > > > >> On 21/05/2024 11:45, Dmitry Baryshkov wrote: > > > > >> > Qualcomm platforms have different sets of the firmware files, which > > > > >> > differ from platform to platform (and from board to board, due to > > > > >> > the > > > > >> > embedded signatures). Rather than listing all the firmware files, > > > > >> > including full paths, in the DT, provide a way to determine > > > > >> > firmware > > > > >> > path based on the root DT node compatible. > > > > >> > > > > >> Ok this looks quite over-engineered but necessary to handle the > > > > >> legacy, > > > > >> but I really think we should add a way to look for a board-specific > > > > >> path > > > > >> first and fallback to those SoC specific paths. > > > > > > > > > > Again, CONFIG_FW_LOADER_USER_HELPER => delays. > > > > > > > > To me this also looks like very over-engineered, can you elaborate more > > > > why this is needed? Concrete examples would help to understand better. > > > > > > Sure. During the meeting last week Arnd suggested evaluating if we can > > > drop firmware-name from the board DT files. Several reasons for that: > > > - DT should describe the hardware, not the Linux-firmware locations > > > - having firmware name in DT complicates updating the tree to use > > > different firmware API (think of mbn vs mdt vs any other format) > > > - If the DT gets supplied by the vendor (e.g. for > > > SystemReady-certified devices), there should be a sync between the > > > vendor's DT, linux kernel and the rootfs. Dropping firmware names from > > > DT solves that by removing one piece of the equation > > > > > > Now for the complexity of the solution. Each SoC family has their own > > > firmware set. This includes firmware for the DSPs, for modem, WiFi > > > bits, GPU shader, etc. > > > For the development boards these devices are signed by the testing key > > > and the actual signature is not validated against the root of trust > > > certificate. > > > For the end-user devices the signature is actually validated against > > > the bits fused to the SoC during manufacturing process. CA certificate > > > (and thus the fuses) differ from vendor to vendor (and from the device > > > to device) > > > > > > Not all of the firmware files are a part of the public linux-firmware > > > tree. However we need to support the rootfs bundled with the firmware > > > for different platforms (both public and vendor). The non-signed files > > > come from the Adreno GPU and can be shared between platforms. All > > > other files are SoC-specific and in some cases device-specific. > > > > > > So for example the SDM845 db845c (open device) loads following firmware > > > files: > > > Not signed: > > > - qcom/a630_sqe.fw > > > - qcom/a630_gmu.bin > > > > > > Signed, will work for any non-secured sdm845 device: > > > - qcom/sdm845/a630_zap.mbn > > > - qcom/sdm845/adsp.mbn > > > - qcom/sdm845/cdsp.mbn > > > - qcom/sdm485/mba.mbn > > > - qcom/sdm845/modem.mbn > > > - qcom/sdm845/wlanmdsp.mbn (loaded via TQFTP) > > > - qcom/venus-5.2/venus.mbn > > > > > > Signed, works only for DB845c. > > > - qcom/sdm845/Thundercomm/db845c/slpi.mbn > > > > > > In comparison, the SDM845 Pixel-3 phone (aka blueline) should load the > > > following firmware files: > > > - qcom/a630_sqe.fw (the same, non-signed file) > > > - qcom/a630_gmu.bin (the same, non-signed file) > > > - qcom/sdm845/Google/blueline/a630_zap.mbn > > > > How do you get from "a630_zap.mbn" to this? By extending the lookup > > table for every target, or what am I missing? > > More or less so. Matching the root OF node gives us the firmware > location, then it gets prepended to all firmware targets. Not an ideal > solution, as there is no fallback support, but at least it gives us > some points to discuss (and to decide whether to move to some > particular direction or to abandon the idea completely, making Arnd > unhappy again). > I understand the desire to not put linux-firmware-specific paths in the DeviceTree, but I think I'm less keen on having a big lookup table in the kernel... Regards, Bjorn
[linus:master] [net] e9669a00bb: aim9.udp_test.ops_per_sec 2.7% improvement
Hello,
kernel test robot noticed a 2.7% improvement of aim9.udp_test.ops_per_sec on:
commit: e9669a00bba79442dd4862c57761333d6a020c24 ("net: udp: add IP/port data
to the tracepoint udp/udp_fail_queue_rcv_skb")
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git master
testcase: aim9
test machine: 48 threads 2 sockets Intel(R) Xeon(R) CPU E5-2697 v2 @ 2.70GHz
(Ivy Bridge-EP) with 64G memory
parameters:
testtime: 300s
test: udp_test
cpufreq_governor: performance
Details are as below:
-->
The kernel config and materials to reproduce are available at:
https://download.01.org/0day-ci/archive/20240529/202405291024.412dc03e-oliver.s...@intel.com
=
compiler/cpufreq_governor/kconfig/rootfs/tbox_group/test/testcase/testtime:
gcc-13/performance/x86_64-rhel-8.3/debian-12-x86_64-20240206.cgz/lkp-ivb-2ep2/udp_test/aim9/300s
commit:
a0ad11fc26 ("net: port TP_STORE_ADDR_PORTS_SKB macro to be tcp/udp
independent")
e9669a00bb ("net: udp: add IP/port data to the tracepoint
udp/udp_fail_queue_rcv_skb")
a0ad11fc2632903e e9669a00bba79442dd4862c5776
---
%stddev %change %stddev
\ |\
294621+2.7% 302449aim9.udp_test.ops_per_sec
20613+1.7% 20955proc-vmstat.nr_slab_reclaimable
5.444e+08+2.1% 5.558e+08perf-stat.i.branch-instructions
8460968 ± 2% +4.8%8867626perf-stat.i.cache-references
1.58-2.3% 1.54perf-stat.i.cpi
66.45+4.0% 69.07perf-stat.i.cpu-migrations
4858 ± 5% -7.6% 4487 ± 3%
perf-stat.i.cycles-between-cache-misses
2.846e+09+2.1% 2.906e+09perf-stat.i.instructions
0.65+2.2% 0.67perf-stat.i.ipc
1.48-1.9% 1.45perf-stat.overall.cpi
3684 ± 3% -5.1% 3495 ± 3%
perf-stat.overall.cycles-between-cache-misses
0.68+1.9% 0.69perf-stat.overall.ipc
5.428e+08+2.1% 5.541e+08perf-stat.ps.branch-instructions
8432000 ± 2% +4.8%8837232perf-stat.ps.cache-references
66.22+4.0% 68.84perf-stat.ps.cpu-migrations
2.837e+09+2.1% 2.897e+09perf-stat.ps.instructions
8.552e+11+2.0% 8.726e+11perf-stat.total.instructions
21.69-0.7 21.03
perf-profile.calltrace.cycles-pp.ksys_write.do_syscall_64.entry_SYSCALL_64_after_hwframe.write
22.32-0.7 21.66
perf-profile.calltrace.cycles-pp.entry_SYSCALL_64_after_hwframe.write
22.29-0.7 21.63
perf-profile.calltrace.cycles-pp.do_syscall_64.entry_SYSCALL_64_after_hwframe.write
21.21-0.6 20.60
perf-profile.calltrace.cycles-pp.vfs_write.ksys_write.do_syscall_64.entry_SYSCALL_64_after_hwframe.write
19.97-0.5 19.47
perf-profile.calltrace.cycles-pp.sock_write_iter.vfs_write.ksys_write.do_syscall_64.entry_SYSCALL_64_after_hwframe
26.87-0.5 26.38
perf-profile.calltrace.cycles-pp.write
18.78-0.4 18.32
perf-profile.calltrace.cycles-pp.udp_sendmsg.sock_write_iter.vfs_write.ksys_write.do_syscall_64
1.54 ± 4% -0.31.24 ± 4%
perf-profile.calltrace.cycles-pp.loopback_xmit.dev_hard_start_xmit.__dev_queue_xmit.ip_finish_output2.ip_send_skb
1.67 ± 4% -0.31.40 ± 3%
perf-profile.calltrace.cycles-pp.dev_hard_start_xmit.__dev_queue_xmit.ip_finish_output2.ip_send_skb.udp_send_skb
0.92 ± 6% -0.10.83 ± 5%
perf-profile.calltrace.cycles-pp.__ip_make_skb.ip_make_skb.udp_sendmsg.sock_write_iter.vfs_write
3.21+0.13.32 ± 2%
perf-profile.calltrace.cycles-pp.ip_protocol_deliver_rcu.ip_local_deliver_finish.__netif_receive_skb_one_core.process_backlog.__napi_poll
0.76 ± 6% +0.10.88 ± 5%
perf-profile.calltrace.cycles-pp.ip_rcv.__netif_receive_skb_one_core.process_backlog.__napi_poll.net_rx_action
0.92 ± 5% +0.11.05 ± 4%
perf-profile.calltrace.cycles-pp.__skb_recv_udp.udp_recvmsg.inet_recvmsg.sock_recvmsg.sock_read_iter
2.76+0.12.89 ± 2%
perf-profile.calltrace.cycles-pp.__udp4_lib_rcv.ip_protocol_deliver_rcu.ip_local_deliver_finish.__netif_receive_skb_one_core.process_backlog
0.43 ± 50% +0.20.58 ± 6%
perf-profile.calltrace.cycles-pp.irqtime_account_irq.__do_softirq.do_softirq.__local_bh_enable_ip.__dev_queue_xmit
5.96+0.26.21
perf-profile.calltr
Re: [PATCH net-next 0/5] net: constify ctl_table arguments of utility functions
Hello: This series was applied to netdev/net-next.git (main) by Jakub Kicinski : On Mon, 27 May 2024 19:04:18 +0200 you wrote: > The sysctl core is preparing to only expose instances of > struct ctl_table as "const". > This will also affect the ctl_table argument of sysctl handlers. > > As the function prototype of all sysctl handlers throughout the tree > needs to stay consistent that change will be done in one commit. > > [...] Here is the summary with links: - [net-next,1/5] net/neighbour: constify ctl_table arguments of utility function https://git.kernel.org/netdev/net-next/c/874aa96d78c7 - [net-next,2/5] net/ipv4/sysctl: constify ctl_table arguments of utility functions https://git.kernel.org/netdev/net-next/c/551814313f11 - [net-next,3/5] net/ipv6/addrconf: constify ctl_table arguments of utility functions https://git.kernel.org/netdev/net-next/c/c55eb03765f4 - [net-next,4/5] net/ipv6/ndisc: constify ctl_table arguments of utility function https://git.kernel.org/netdev/net-next/c/7a20cd1e71d8 - [net-next,5/5] ipvs: constify ctl_table arguments of utility functions https://git.kernel.org/netdev/net-next/c/0a9f788fdde4 You are awesome, thank you! -- Deet-doot-dot, I am a bot. https://korg.docs.kernel.org/patchwork/pwbot.html
Re: [PATCH DNM 2/2] arm64: dts: qcom: qcm6490-fairphone-fp5: Add DisplayPort sound support
On Tue May 28, 2024 at 11:35 PM CEST, Bjorn Andersson wrote:
> On Fri, May 10, 2024 at 02:27:09PM GMT, Luca Weiss wrote:
> > Add the required nodes for sound playback via a connected external
> > display (DisplayPort over USB-C).
> >
> > Signed-off-by: Luca Weiss
> > ---
> > Depends on a bunch of patches upstream doing bringup of Display (DSI),
> > DisplayPort, GPU, and then finally audio could land. But we're blocked
> > on DPU 1:1:1 topology for all of that unfortunately.
> >
> > And also machine driver for sound just exists a bit hackily.
>
> Thanks for sharing this, Luca. Can you please resubmit this once it's
> ready to be merged, so that I don't need to keep track of it?
Definitely, though I don't expect it to be soon unfortunately, maybe you
can ask your colleagues though to fix that DPU 1:1:1 topology ;)
>
> Regards,
> Bjorn
>
> > ---
> > arch/arm64/boot/dts/qcom/qcm6490-fairphone-fp5.dts | 36
> > ++
> > 1 file changed, 36 insertions(+)
> >
> > diff --git a/arch/arm64/boot/dts/qcom/qcm6490-fairphone-fp5.dts
> > b/arch/arm64/boot/dts/qcom/qcm6490-fairphone-fp5.dts
> > index 05bbf1da5cb8..2bbbcaeff95e 100644
> > --- a/arch/arm64/boot/dts/qcom/qcm6490-fairphone-fp5.dts
> > +++ b/arch/arm64/boot/dts/qcom/qcm6490-fairphone-fp5.dts
> > @@ -14,6 +14,8 @@
> > #include
> > #include
> > #include
> > +#include
> > +#include
> > #include "sc7280.dtsi"
> > #include "pm7250b.dtsi"
> > #include "pm7325.dtsi"
> > @@ -774,6 +776,12 @@ &pon_resin {
> > status = "okay";
> > };
> >
> > +&q6afedai {
> > + dai@104 {
> > + reg = ;
> > + };
> > +};
> > +
> > &qup_spi13_cs {
> > drive-strength = <6>;
> > bias-disable;
> > @@ -847,6 +855,34 @@ &sdhc_2 {
> > status = "okay";
> > };
> >
> > +&sound {
> > + compatible = "fairphone,fp5-sndcard";
> > + model = "Fairphone 5";
> > +
> > + mm1-dai-link {
> > + link-name = "MultiMedia1";
> > + cpu {
> > + sound-dai = <&q6asmdai MSM_FRONTEND_DAI_MULTIMEDIA1>;
> > + };
> > + };
> > +
> > + displayport-rx-dai-link {
> > + link-name = "DisplayPort Playback";
> > +
> > + cpu {
> > + sound-dai = <&q6afedai DISPLAY_PORT_RX>;
> > + };
> > +
> > + platform {
> > + sound-dai = <&q6routing>;
> > + };
> > +
> > + codec {
> > + sound-dai = <&mdss_dp>;
> > + };
> > + };
> > +};
> > +
> > &spi13 {
> > status = "okay";
> >
> >
> > --
> > 2.45.0
> >
