inconsistent lock state in __mmap_lock_do_trace_released
Hello.
We are Ubisectech Sirius Team, the vulnerability lab of China ValiantSec.
Recently, our team has discovered a issue in Linux kernel 6.7. Attached to the
email were a PoC file of the issue.
Stack dump:
WARNING: inconsistent lock state
6.7.0 #2 Not tainted
inconsistent {HARDIRQ-ON-W} -> {IN-HARDIRQ-W} usage.
modprobe/17218 [HC1[1]:SC0[0]:HE0:SE1] takes:
88802c6376a0 (lock#13){?.+.}-{2:2}, at: local_lock_acquire
include/linux/local_lock_internal.h:29 [inline]
88802c6376a0 (lock#13){?.+.}-{2:2}, at:
__mmap_lock_do_trace_released+0x7b/0x740 mm/mmap_lock.c:243
{HARDIRQ-ON-W} state was registered at:
lock_acquire kernel/locking/lockdep.c:5754 [inline]
lock_acquire+0x1b1/0x530 kernel/locking/lockdep.c:5719
local_lock_acquire include/linux/local_lock_internal.h:29 [inline]
__mmap_lock_do_trace_acquire_returned+0x96/0x740 mm/mmap_lock.c:237
__mmap_lock_trace_acquire_returned include/linux/mmap_lock.h:36 [inline]
mmap_read_trylock include/linux/mmap_lock.h:166 [inline]
get_mmap_lock_carefully mm/memory.c:5372 [inline]
lock_mm_and_find_vma+0xf1/0x5a0 mm/memory.c:5432
do_user_addr_fault+0x390/0x1010 arch/x86/mm/fault.c:1387
handle_page_fault arch/x86/mm/fault.c:1507 [inline]
exc_page_fault+0x99/0x180 arch/x86/mm/fault.c:1563
asm_exc_page_fault+0x26/0x30 arch/x86/include/asm/idtentry.h:570
__put_user_8+0x11/0x20 arch/x86/lib/putuser.S:105
clear_rseq_cs kernel/rseq.c:257 [inline]
rseq_ip_fixup kernel/rseq.c:291 [inline]
__rseq_handle_notify_resume+0xd50/0x1000 kernel/rseq.c:329
rseq_handle_notify_resume include/linux/sched.h:2361 [inline]
resume_user_mode_work include/linux/resume_user_mode.h:61 [inline]
exit_to_user_mode_loop kernel/entry/common.c:171 [inline]
exit_to_user_mode_prepare+0x170/0x240 kernel/entry/common.c:204
__syscall_exit_to_user_mode_work kernel/entry/common.c:285 [inline]
syscall_exit_to_user_mode+0x1e/0x60 kernel/entry/common.c:296
do_syscall_64+0x53/0x120 arch/x86/entry/common.c:89
entry_SYSCALL_64_after_hwframe+0x6f/0x77
irq event stamp: 696
hardirqs last enabled at (695): []
flush_tlb_mm_range+0x26b/0x340 arch/x86/mm/tlb.c:1035
hardirqs last disabled at (696): [] sysvec_irq_work+0x18/0xf0
arch/x86/kernel/irq_work.c:17
softirqs last enabled at (244): [] local_bh_enable
include/linux/bottom_half.h:33 [inline]
softirqs last enabled at (244): [] fpregs_unlock
arch/x86/include/asm/fpu/api.h:80 [inline]
softirqs last enabled at (244): [] fpu_reset_fpregs
arch/x86/kernel/fpu/core.c:733 [inline]
softirqs last enabled at (244): []
fpu_flush_thread+0x309/0x400 arch/x86/kernel/fpu/core.c:777
softirqs last disabled at (242): [] local_bh_disable
include/linux/bottom_half.h:20 [inline]
softirqs last disabled at (242): [] fpregs_lock
arch/x86/include/asm/fpu/api.h:72 [inline]
softirqs last disabled at (242): [] fpu_reset_fpregs
arch/x86/kernel/fpu/core.c:716 [inline]
softirqs last disabled at (242): []
fpu_flush_thread+0x23a/0x400 arch/x86/kernel/fpu/core.c:777
other info that might help us debug this:
Possible unsafe locking scenario:
CPU0
lock(lock#13);
lock(lock#13);
*** DEADLOCK ***
3 locks held by modprobe/17218:
#0: 8880200de658 (&vma->vm_lock->lock){}-{3:3}, at: vma_start_read
include/linux/mm.h:663 [inline]
#0: 8880200de658 (&vma->vm_lock->lock){}-{3:3}, at:
lock_vma_under_rcu+0x1e1/0x960 mm/memory.c:5501
#1: 8d3a9f60 (rcu_read_lock){}-{1:2}, at: rcu_lock_acquire
include/linux/rcupdate.h:301 [inline]
#1: 8d3a9f60 (rcu_read_lock){}-{1:2}, at: rcu_read_lock
include/linux/rcupdate.h:747 [inline]
#1: 8d3a9f60 (rcu_read_lock){}-{1:2}, at:
__pte_offset_map+0x42/0x570 mm/pgtable-generic.c:285
#2: 8880491b0258 (ptlock_ptr(ptdesc)#2){+.+.}-{2:2}, at: spin_lock
include/linux/spinlock.h:351 [inline]
#2: 8880491b0258 (ptlock_ptr(ptdesc)#2){+.+.}-{2:2}, at:
__pte_offset_map_lock+0x10d/0x2f0 mm/pgtable-generic.c:373
stack backtrace:
CPU: 0 PID: 17218 Comm: modprobe Not tainted 6.7.0 #2
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014
Call Trace:
__dump_stack lib/dump_stack.c:88 [inline]
dump_stack_lvl+0xd9/0x150 lib/dump_stack.c:106
print_usage_bug kernel/locking/lockdep.c:3971 [inline]
valid_state kernel/locking/lockdep.c:4013 [inline]
mark_lock_irq kernel/locking/lockdep.c:4216 [inline]
mark_lock+0x99b/0xd60 kernel/locking/lockdep.c:4678
mark_usage kernel/locking/lockdep.c:4564 [inline]
__lock_acquire+0x1339/0x3bb0 kernel/locking/lockdep.c:5091
lock_acquire kernel/locking/lockdep.c:5754 [inline]
lock_acquire+0x1b1/0x530 kernel/locking/lockdep.c:5719
local_lock_acquire include/linux/local_lock_internal.h:29 [inline]
__mmap_lock_do_trace_released+0x93/0x740 mm/mmap_lock.c:243
__mmap_lock_trace_released include/linux/mmap_lock.h:42 [inline]
mmap_read_unlock_non_owner include/linux/mmap_lock.h:178 [inline]
do_mmap_read_
[PATCH] clk: qcom: gcc-sm6350: Fix gpll6* & gpll7 parents
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.
Corrected rates are the following:
gpll7 80702 Hz
gpll6 76800 Hz
gpll6_out_even 38400 Hz
gpll0 6 Hz
gpll0_out_odd 2 Hz
gpll0_out_even 3 Hz
And because gpll6 is the parent of gcc_sdcc2_apps_clk_src (at 202 MHz)
that clock also reports the correct rate now and avoids this warning:
[5.984062] mmc0: Card appears overclocked; req 20200 Hz, actual
6312499237 Hz
Fixes: 131abae905df ("clk: qcom: Add SM6350 GCC driver")
Signed-off-by: Luca Weiss
---
drivers/clk/qcom/gcc-sm6350.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/clk/qcom/gcc-sm6350.c b/drivers/clk/qcom/gcc-sm6350.c
index cf4a7b6e0b23..0559a33faf00 100644
--- a/drivers/clk/qcom/gcc-sm6350.c
+++ b/drivers/clk/qcom/gcc-sm6350.c
@@ -100,8 +100,8 @@ static struct clk_alpha_pll gpll6 = {
.enable_mask = BIT(6),
.hw.init = &(struct clk_init_data){
.name = "gpll6",
- .parent_hws = (const struct clk_hw*[]){
- &gpll0.clkr.hw,
+ .parent_data = &(const struct clk_parent_data){
+ .fw_name = "bi_tcxo",
},
.num_parents = 1,
.ops = &clk_alpha_pll_fixed_fabia_ops,
@@ -124,7 +124,7 @@ static struct clk_alpha_pll_postdiv gpll6_out_even = {
.clkr.hw.init = &(struct clk_init_data){
.name = "gpll6_out_even",
.parent_hws = (const struct clk_hw*[]){
- &gpll0.clkr.hw,
+ &gpll6.clkr.hw,
},
.num_parents = 1,
.ops = &clk_alpha_pll_postdiv_fabia_ops,
@@ -139,8 +139,8 @@ static struct clk_alpha_pll gpll7 = {
.enable_mask = BIT(7),
.hw.init = &(struct clk_init_data){
.name = "gpll7",
- .parent_hws = (const struct clk_hw*[]){
- &gpll0.clkr.hw,
+ .parent_data = &(const struct clk_parent_data){
+ .fw_name = "bi_tcxo",
},
.num_parents = 1,
.ops = &clk_alpha_pll_fixed_fabia_ops,
---
base-commit: dd5a440a31fae6e459c0d627162825505361
change-id: 20240508-sm6350-gpll-fix-a308bb393434
Best regards,
--
Luca Weiss
Re: [PATCH v4 1/2] ipvs: add READ_ONCE barrier for ipvs->sysctl_amemthresh
Hello: This series was applied to netdev/net-next.git (main) by David S. Miller : On Mon, 6 May 2024 16:14:43 +0200 you wrote: > Cc: Julian Anastasov > Cc: Simon Horman > Cc: Pablo Neira Ayuso > Cc: Jozsef Kadlecsik > Cc: Florian Westphal > Suggested-by: Julian Anastasov > Signed-off-by: Alexander Mikhalitsyn > > [...] Here is the summary with links: - [v4,1/2] ipvs: add READ_ONCE barrier for ipvs->sysctl_amemthresh https://git.kernel.org/netdev/net-next/c/643bb5dbaef7 - [v4,2/2] ipvs: allow some sysctls in non-init user namespaces https://git.kernel.org/netdev/net-next/c/2b696a2a101d You are awesome, thank you! -- Deet-doot-dot, I am a bot. https://korg.docs.kernel.org/patchwork/pwbot.html
[PATCH net-next v3 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 v3 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 a5747cf7a3a1..024ff73a7ea4 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 92eb288aab75..8a974d0588bf 100644
--- a/mm/page_frag_test.c
+++ b/mm/page_frag_test.c
@@ -329,7 +329,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 v9 2/5] remoteproc: k3-m4: Add a remoteproc driver for M4F subsystem
On 5/6/24 3:46 PM, Mathieu Poirier wrote:
Good day,
I have started reviewing this patchset. Comments will be scattered over
multiple days and as such, I will explicitly inform you when am done with the
review.
On Fri, Apr 26, 2024 at 02:18:08PM -0500, Andrew Davis wrote:
From: Martyn Welch
The AM62x and AM64x SoCs of the TI K3 family has a Cortex M4F core in
the MCU domain. This core is typically used for safety applications in a
stand alone mode. However, some application (non safety related) may
want to use the M4F core as a generic remote processor with IPC to the
host processor. The M4F core has internal IRAM and DRAM memories and are
exposed to the system bus for code and data loading.
A remote processor driver is added to support this subsystem, including
being able to load and boot the M4F core. Loading includes to M4F
internal memories and predefined external code/data memories. The
carve outs for external contiguous memory is defined in the M4F device
node and should match with the external memory declarations in the M4F
image binary. The M4F subsystem has two resets. One reset is for the
entire subsystem i.e including the internal memories and the other, a
local reset is only for the M4F processing core. When loading the image,
the driver first releases the subsystem reset, loads the firmware image
and then releases the local reset to let the M4F processing core run.
Signed-off-by: Martyn Welch
Signed-off-by: Hari Nagalla
Signed-off-by: Andrew Davis
---
drivers/remoteproc/Kconfig | 13 +
drivers/remoteproc/Makefile | 1 +
drivers/remoteproc/ti_k3_m4_remoteproc.c | 785 +++
3 files changed, 799 insertions(+)
create mode 100644 drivers/remoteproc/ti_k3_m4_remoteproc.c
diff --git a/drivers/remoteproc/Kconfig b/drivers/remoteproc/Kconfig
index 48845dc8fa852..1a7c0330c91a9 100644
--- a/drivers/remoteproc/Kconfig
+++ b/drivers/remoteproc/Kconfig
@@ -339,6 +339,19 @@ config TI_K3_DSP_REMOTEPROC
It's safe to say N here if you're not interested in utilizing
the DSP slave processors.
+config TI_K3_M4_REMOTEPROC
+ tristate "TI K3 M4 remoteproc support"
+ depends on ARCH_K3 || COMPILE_TEST
+ select MAILBOX
+ select OMAP2PLUS_MBOX
+ help
+ Say m here to support TI's M4 remote processor subsystems
+ on various TI K3 family of SoCs through the remote processor
+ framework.
+
+ It's safe to say N here if you're not interested in utilizing
+ a remote processor.
+
config TI_K3_R5_REMOTEPROC
tristate "TI K3 R5 remoteproc support"
depends on ARCH_K3
diff --git a/drivers/remoteproc/Makefile b/drivers/remoteproc/Makefile
index 91314a9b43cef..5ff4e2fee4abd 100644
--- a/drivers/remoteproc/Makefile
+++ b/drivers/remoteproc/Makefile
@@ -37,5 +37,6 @@ obj-$(CONFIG_ST_REMOTEPROC) += st_remoteproc.o
obj-$(CONFIG_ST_SLIM_REMOTEPROC) += st_slim_rproc.o
obj-$(CONFIG_STM32_RPROC) += stm32_rproc.o
obj-$(CONFIG_TI_K3_DSP_REMOTEPROC)+= ti_k3_dsp_remoteproc.o
+obj-$(CONFIG_TI_K3_M4_REMOTEPROC) += ti_k3_m4_remoteproc.o
obj-$(CONFIG_TI_K3_R5_REMOTEPROC) += ti_k3_r5_remoteproc.o
obj-$(CONFIG_XLNX_R5_REMOTEPROC) += xlnx_r5_remoteproc.o
diff --git a/drivers/remoteproc/ti_k3_m4_remoteproc.c
b/drivers/remoteproc/ti_k3_m4_remoteproc.c
new file mode 100644
index 0..0030e509f6b5d
--- /dev/null
+++ b/drivers/remoteproc/ti_k3_m4_remoteproc.c
@@ -0,0 +1,785 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * TI K3 Cortex-M4 Remote Processor(s) driver
+ *
+ * Copyright (C) 2021-2024 Texas Instruments Incorporated - https://www.ti.com/
+ * Hari Nagalla
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include "omap_remoteproc.h"
+#include "remoteproc_internal.h"
+#include "ti_sci_proc.h"
+
+/**
+ * struct k3_m4_rproc_mem - internal memory structure
+ * @cpu_addr: MPU virtual address of the memory region
+ * @bus_addr: Bus address used to access the memory region
+ * @dev_addr: Device address of the memory region from remote processor view
+ * @size: Size of the memory region
+ */
+struct k3_m4_rproc_mem {
+ void __iomem *cpu_addr;
+ phys_addr_t bus_addr;
+ u32 dev_addr;
+ size_t size;
+};
+
+/**
+ * struct k3_m4_rproc_mem_data - memory definitions for a remote processor
+ * @name: name for this memory entry
+ * @dev_addr: device address for the memory entry
+ */
+struct k3_m4_rproc_mem_data {
+ const char *name;
+ const u32 dev_addr;
+};
+
+/**
+ * struct k3_m4_rproc_dev_data - device data structure for a remote processor
+ * @mems: pointer to memory definitions for a remote processor
+ * @num_mems: number of memory regions in @mems
+ * @uses_lreset: flag to denote the need for local reset management
+ */
+struct k3_m4_rproc_dev_data {
+ const struct k3_m4_rproc_mem_data *mems;
+ u32 num_
[PATCH v4 0/4] MSM8976 MDSS/GPU/WCNSS support
This patch series provide support for display subsystem, gpu and also adds wireless connectivity subsystem support. Changes since v3 1. Minor styling fixes 2. Converted qcom,ipc into mailbox on wcnss patch Changes since v2 1. Disabled mdss_dsi nodes by default 2. Changed reg size of mdss_dsi0 to be equal on both 3. Added operating points to second mdss_dsi 4. Brought back required opp-supported-hw on adreno 5. Moved status under operating points on adreno Changes since v1 1. Addressed feedback 2. Dropped already applied dt-bindings patches 3. Dropped sdc patch as it was submitted as part of other series 4. Dropped dt-bindings patch for Adreno, also separate now Adam Skladowski (4): arm64: dts: qcom: msm8976: Add IOMMU nodes arm64: dts: qcom: msm8976: Add MDSS nodes arm64: dts: qcom: msm8976: Add Adreno GPU arm64: dts: qcom: msm8976: Add WCNSS node arch/arm64/boot/dts/qcom/msm8976.dtsi | 537 +- 1 file changed, 533 insertions(+), 4 deletions(-) -- 2.44.0
[PATCH v4 1/4] arm64: dts: qcom: msm8976: Add IOMMU nodes
Add the nodes describing the apps and gpu iommu and its context banks
that are found on msm8976 SoCs.
Signed-off-by: Adam Skladowski
---
arch/arm64/boot/dts/qcom/msm8976.dtsi | 81 +++
1 file changed, 81 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/msm8976.dtsi
b/arch/arm64/boot/dts/qcom/msm8976.dtsi
index d2bb1ada361a..8bdcc1438177 100644
--- a/arch/arm64/boot/dts/qcom/msm8976.dtsi
+++ b/arch/arm64/boot/dts/qcom/msm8976.dtsi
@@ -808,6 +808,87 @@ tcsr: syscon@1937000 {
reg = <0x01937000 0x3>;
};
+ apps_iommu: iommu@1ee {
+ compatible = "qcom,msm8976-iommu", "qcom,msm-iommu-v2";
+ reg = <0x01ee 0x3000>;
+ ranges = <0 0x01e2 0x2>;
+
+ clocks = <&gcc GCC_SMMU_CFG_CLK>,
+<&gcc GCC_APSS_TCU_CLK>;
+ clock-names = "iface", "bus";
+
+ qcom,iommu-secure-id = <17>;
+
+ #address-cells = <1>;
+ #size-cells = <1>;
+ #iommu-cells = <1>;
+
+ /* VFE */
+ iommu-ctx@15000 {
+ compatible = "qcom,msm-iommu-v2-ns";
+ reg = <0x15000 0x1000>;
+ qcom,ctx-asid = <20>;
+ interrupts = ;
+ };
+
+ /* VENUS NS */
+ iommu-ctx@16000 {
+ compatible = "qcom,msm-iommu-v2-ns";
+ reg = <0x16000 0x1000>;
+ qcom,ctx-asid = <21>;
+ interrupts = ;
+ };
+
+ /* MDP0 */
+ iommu-ctx@17000 {
+ compatible = "qcom,msm-iommu-v2-ns";
+ reg = <0x17000 0x1000>;
+ qcom,ctx-asid = <22>;
+ interrupts = ;
+ };
+ };
+
+ gpu_iommu: iommu@1f08000 {
+ compatible = "qcom,msm8976-iommu", "qcom,msm-iommu-v2";
+ ranges = <0 0x01f08000 0x8000>;
+
+ clocks = <&gcc GCC_SMMU_CFG_CLK>,
+<&gcc GCC_GFX3D_TCU_CLK>;
+ clock-names = "iface", "bus";
+
+ power-domains = <&gcc OXILI_CX_GDSC>;
+
+ qcom,iommu-secure-id = <18>;
+
+ #address-cells = <1>;
+ #size-cells = <1>;
+ #iommu-cells = <1>;
+
+ /* gfx3d user */
+ iommu-ctx@0 {
+ compatible = "qcom,msm-iommu-v2-ns";
+ reg = <0x0 0x1000>;
+ qcom,ctx-asid = <0>;
+ interrupts = ;
+ };
+
+ /* gfx3d secure */
+ iommu-ctx@1000 {
+ compatible = "qcom,msm-iommu-v2-sec";
+ reg = <0x1000 0x1000>;
+ qcom,ctx-asid = <2>;
+ interrupts = ;
+ };
+
+ /* gfx3d priv */
+ iommu-ctx@2000 {
+ compatible = "qcom,msm-iommu-v2-sec";
+ reg = <0x2000 0x1000>;
+ qcom,ctx-asid = <1>;
+ interrupts = ;
+ };
+ };
+
spmi_bus: spmi@200f000 {
compatible = "qcom,spmi-pmic-arb";
reg = <0x0200f000 0x1000>,
--
2.44.0
[PATCH v4 2/4] arm64: dts: qcom: msm8976: Add MDSS nodes
Add MDSS nodes to support displays on MSM8976 SoC.
Signed-off-by: Adam Skladowski
---
arch/arm64/boot/dts/qcom/msm8976.dtsi | 280 +-
1 file changed, 276 insertions(+), 4 deletions(-)
diff --git a/arch/arm64/boot/dts/qcom/msm8976.dtsi
b/arch/arm64/boot/dts/qcom/msm8976.dtsi
index 8bdcc1438177..b26c35796928 100644
--- a/arch/arm64/boot/dts/qcom/msm8976.dtsi
+++ b/arch/arm64/boot/dts/qcom/msm8976.dtsi
@@ -785,10 +785,10 @@ gcc: clock-controller@180 {
clocks = <&rpmcc RPM_SMD_XO_CLK_SRC>,
<&rpmcc RPM_SMD_XO_A_CLK_SRC>,
-<0>,
-<0>,
-<0>,
-<0>;
+<&mdss_dsi0_phy 1>,
+<&mdss_dsi0_phy 0>,
+<&mdss_dsi1_phy 1>,
+<&mdss_dsi1_phy 0>;
clock-names = "xo",
"xo_a",
"dsi0pll",
@@ -808,6 +808,278 @@ tcsr: syscon@1937000 {
reg = <0x01937000 0x3>;
};
+ mdss: display-subsystem@1a0 {
+ compatible = "qcom,mdss";
+
+ reg = <0x01a0 0x1000>,
+ <0x01ab 0x3000>;
+ reg-names = "mdss_phys", "vbif_phys";
+
+ power-domains = <&gcc MDSS_GDSC>;
+ interrupts = ;
+
+ interrupt-controller;
+ #interrupt-cells = <1>;
+
+ clocks = <&gcc GCC_MDSS_AHB_CLK>,
+<&gcc GCC_MDSS_AXI_CLK>,
+<&gcc GCC_MDSS_VSYNC_CLK>,
+<&gcc GCC_MDSS_MDP_CLK>;
+ clock-names = "iface",
+ "bus",
+ "vsync",
+ "core";
+
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges;
+
+ status = "disabled";
+
+ mdss_mdp: display-controller@1a01000 {
+ compatible = "qcom,msm8976-mdp5", "qcom,mdp5";
+ reg = <0x01a01000 0x89000>;
+ reg-names = "mdp_phys";
+
+ interrupt-parent = <&mdss>;
+ interrupts = <0>;
+
+ clocks = <&gcc GCC_MDSS_AHB_CLK>,
+<&gcc GCC_MDSS_AXI_CLK>,
+<&gcc GCC_MDSS_MDP_CLK>,
+<&gcc GCC_MDSS_VSYNC_CLK>,
+<&gcc GCC_MDP_TBU_CLK>,
+<&gcc GCC_MDP_RT_TBU_CLK>;
+ clock-names = "iface",
+ "bus",
+ "core",
+ "vsync",
+ "tbu",
+ "tbu_rt";
+
+ operating-points-v2 = <&mdp_opp_table>;
+ power-domains = <&gcc MDSS_GDSC>;
+
+ iommus = <&apps_iommu 22>;
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+
+ mdss_mdp5_intf1_out: endpoint {
+ remote-endpoint =
<&mdss_dsi0_in>;
+ };
+ };
+
+ port@1 {
+ reg = <1>;
+
+ mdss_mdp5_intf2_out: endpoint {
+ remote-endpoint =
<&mdss_dsi1_in>;
+ };
+ };
+ };
+
+ mdp_opp_table: opp-table {
+ compatible = "operating-points-v2";
+
+ opp-17778 {
+ opp-hz = /bits/ 64 <17778>;
+ required-opps =
<&rpmpd_opp_svs>;
+ };
+
+ opp-27000 {
[PATCH v4 3/4] arm64: dts: qcom: msm8976: Add Adreno GPU
Add Adreno GPU node.
Signed-off-by: Adam Skladowski
---
arch/arm64/boot/dts/qcom/msm8976.dtsi | 71 +++
1 file changed, 71 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/msm8976.dtsi
b/arch/arm64/boot/dts/qcom/msm8976.dtsi
index b26c35796928..22a6a09a904d 100644
--- a/arch/arm64/boot/dts/qcom/msm8976.dtsi
+++ b/arch/arm64/boot/dts/qcom/msm8976.dtsi
@@ -1080,6 +1080,77 @@ mdss_dsi1_phy: phy@1a96a00 {
};
};
+ adreno_gpu: gpu@1c0 {
+ compatible = "qcom,adreno-510.0", "qcom,adreno";
+
+ reg = <0x01c0 0x4>;
+ reg-names = "kgsl_3d0_reg_memory";
+
+ interrupts = ;
+ interrupt-names = "kgsl_3d0_irq";
+
+ clocks = <&gcc GCC_GFX3D_OXILI_CLK>,
+<&gcc GCC_GFX3D_OXILI_AHB_CLK>,
+<&gcc GCC_GFX3D_OXILI_GMEM_CLK>,
+<&gcc GCC_GFX3D_BIMC_CLK>,
+<&gcc GCC_GFX3D_OXILI_TIMER_CLK>,
+<&gcc GCC_GFX3D_OXILI_AON_CLK>;
+ clock-names = "core",
+ "iface",
+ "mem",
+ "mem_iface",
+ "rbbmtimer",
+ "alwayson";
+
+ power-domains = <&gcc OXILI_GX_GDSC>;
+
+ iommus = <&gpu_iommu 0>;
+
+ operating-points-v2 = <&gpu_opp_table>;
+
+ status = "disabled";
+
+ gpu_opp_table: opp-table {
+ compatible = "operating-points-v2";
+
+ opp-2 {
+ opp-hz = /bits/ 64 <2>;
+ required-opps = <&rpmpd_opp_low_svs>;
+ opp-supported-hw = <0xff>;
+ };
+
+ opp-3 {
+ opp-hz = /bits/ 64 <3>;
+ required-opps = <&rpmpd_opp_svs>;
+ opp-supported-hw = <0xff>;
+ };
+
+ opp-4 {
+ opp-hz = /bits/ 64 <4>;
+ required-opps = <&rpmpd_opp_nom>;
+ opp-supported-hw = <0xff>;
+ };
+
+ opp-48000 {
+ opp-hz = /bits/ 64 <48000>;
+ required-opps = <&rpmpd_opp_nom_plus>;
+ opp-supported-hw = <0xff>;
+ };
+
+ opp-54000 {
+ opp-hz = /bits/ 64 <54000>;
+ required-opps = <&rpmpd_opp_turbo>;
+ opp-supported-hw = <0xff>;
+ };
+
+ opp-6 {
+ opp-hz = /bits/ 64 <6>;
+ required-opps = <&rpmpd_opp_turbo>;
+ opp-supported-hw = <0xff>;
+ };
+ };
+ };
+
apps_iommu: iommu@1ee {
compatible = "qcom,msm8976-iommu", "qcom,msm-iommu-v2";
reg = <0x01ee 0x3000>;
--
2.44.0
[PATCH v4 4/4] arm64: dts: qcom: msm8976: Add WCNSS node
Add node describing wireless connectivity subsystem.
Signed-off-by: Adam Skladowski
---
arch/arm64/boot/dts/qcom/msm8976.dtsi | 105 ++
1 file changed, 105 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/msm8976.dtsi
b/arch/arm64/boot/dts/qcom/msm8976.dtsi
index 22a6a09a904d..a7f772485bf5 100644
--- a/arch/arm64/boot/dts/qcom/msm8976.dtsi
+++ b/arch/arm64/boot/dts/qcom/msm8976.dtsi
@@ -771,6 +771,36 @@ blsp2_i2c4_sleep: blsp2-i2c4-sleep-state {
drive-strength = <2>;
bias-disable;
};
+
+ wcss_wlan_default: wcss-wlan-default-state {
+ wcss-wlan2-pins {
+ pins = "gpio40";
+ function = "wcss_wlan2";
+ drive-strength = <6>;
+ bias-pull-up;
+ };
+
+ wcss-wlan1-pins {
+ pins = "gpio41";
+ function = "wcss_wlan1";
+ drive-strength = <6>;
+ bias-pull-up;
+ };
+
+ wcss-wlan0-pins {
+ pins = "gpio42";
+ function = "wcss_wlan0";
+ drive-strength = <6>;
+ bias-pull-up;
+ };
+
+ wcss-wlan-pins {
+ pins = "gpio43", "gpio44";
+ function = "wcss_wlan";
+ drive-strength = <6>;
+ bias-pull-up;
+ };
+ };
};
gcc: clock-controller@180 {
@@ -1458,6 +1488,81 @@ blsp2_i2c4: i2c@7af8000 {
status = "disabled";
};
+ wcnss: remoteproc@a204000 {
+ compatible = "qcom,pronto-v3-pil", "qcom,pronto";
+ reg = <0x0a204000 0x2000>,
+ <0x0a202000 0x1000>,
+ <0x0a21b000 0x3000>;
+ reg-names = "ccu",
+ "dxe",
+ "pmu";
+
+ memory-region = <&wcnss_fw_mem>;
+
+ interrupts-extended = <&intc GIC_SPI 149
IRQ_TYPE_EDGE_RISING>,
+ <&wcnss_smp2p_in 0
IRQ_TYPE_EDGE_RISING>,
+ <&wcnss_smp2p_in 1
IRQ_TYPE_EDGE_RISING>,
+ <&wcnss_smp2p_in 2
IRQ_TYPE_EDGE_RISING>,
+ <&wcnss_smp2p_in 3
IRQ_TYPE_EDGE_RISING>;
+ interrupt-names = "wdog",
+ "fatal",
+ "ready",
+ "handover",
+ "stop-ack";
+
+ power-domains = <&rpmpd MSM8976_VDDCX>,
+ <&rpmpd MSM8976_VDDMX>;
+ power-domain-names = "cx", "mx";
+
+ qcom,smem-states = <&wcnss_smp2p_out 0>;
+ qcom,smem-state-names = "stop";
+
+ pinctrl-0 = <&wcss_wlan_default>;
+ pinctrl-names = "default";
+
+ status = "disabled";
+
+ wcnss_iris: iris {
+ /* Separate chip, compatible is board-specific
*/
+ clocks = <&rpmcc RPM_SMD_RF_CLK2>;
+ clock-names = "xo";
+ };
+
+ smd-edge {
+ interrupts = ;
+
+ mboxes = <&apcs 17>;
+ qcom,smd-edge = <6>;
+ qcom,remote-pid = <4>;
+
+ label = "pronto";
+
+ wcnss_ctrl: wcnss {
+ compatible = "qcom,wcnss";
+ qcom,smd-channels = "WCNSS_CTRL";
+
+ qcom,mmio = <&wcnss>;
+
+ wcnss_bt: bluetooth {
+ compatible = "qcom,wcnss-bt";
+ };
+
+ wcnss_wifi: wifi {
+ compatible = "qcom,wcnss-wlan";
+
+
Re: [PATCH v9 2/5] remoteproc: k3-m4: Add a remoteproc driver for M4F subsystem
On 5/7/24 3:36 PM, Mathieu Poirier wrote:
On Fri, Apr 26, 2024 at 02:18:08PM -0500, Andrew Davis wrote:
From: Martyn Welch
The AM62x and AM64x SoCs of the TI K3 family has a Cortex M4F core in
the MCU domain. This core is typically used for safety applications in a
stand alone mode. However, some application (non safety related) may
want to use the M4F core as a generic remote processor with IPC to the
host processor. The M4F core has internal IRAM and DRAM memories and are
exposed to the system bus for code and data loading.
A remote processor driver is added to support this subsystem, including
being able to load and boot the M4F core. Loading includes to M4F
internal memories and predefined external code/data memories. The
carve outs for external contiguous memory is defined in the M4F device
node and should match with the external memory declarations in the M4F
image binary. The M4F subsystem has two resets. One reset is for the
entire subsystem i.e including the internal memories and the other, a
local reset is only for the M4F processing core. When loading the image,
the driver first releases the subsystem reset, loads the firmware image
and then releases the local reset to let the M4F processing core run.
Signed-off-by: Martyn Welch
Signed-off-by: Hari Nagalla
Signed-off-by: Andrew Davis
---
drivers/remoteproc/Kconfig | 13 +
drivers/remoteproc/Makefile | 1 +
drivers/remoteproc/ti_k3_m4_remoteproc.c | 785 +++
3 files changed, 799 insertions(+)
create mode 100644 drivers/remoteproc/ti_k3_m4_remoteproc.c
diff --git a/drivers/remoteproc/Kconfig b/drivers/remoteproc/Kconfig
index 48845dc8fa852..1a7c0330c91a9 100644
--- a/drivers/remoteproc/Kconfig
+++ b/drivers/remoteproc/Kconfig
@@ -339,6 +339,19 @@ config TI_K3_DSP_REMOTEPROC
It's safe to say N here if you're not interested in utilizing
the DSP slave processors.
+config TI_K3_M4_REMOTEPROC
+ tristate "TI K3 M4 remoteproc support"
+ depends on ARCH_K3 || COMPILE_TEST
+ select MAILBOX
+ select OMAP2PLUS_MBOX
+ help
+ Say m here to support TI's M4 remote processor subsystems
+ on various TI K3 family of SoCs through the remote processor
+ framework.
+
+ It's safe to say N here if you're not interested in utilizing
+ a remote processor.
+
config TI_K3_R5_REMOTEPROC
tristate "TI K3 R5 remoteproc support"
depends on ARCH_K3
diff --git a/drivers/remoteproc/Makefile b/drivers/remoteproc/Makefile
index 91314a9b43cef..5ff4e2fee4abd 100644
--- a/drivers/remoteproc/Makefile
+++ b/drivers/remoteproc/Makefile
@@ -37,5 +37,6 @@ obj-$(CONFIG_ST_REMOTEPROC) += st_remoteproc.o
obj-$(CONFIG_ST_SLIM_REMOTEPROC) += st_slim_rproc.o
obj-$(CONFIG_STM32_RPROC) += stm32_rproc.o
obj-$(CONFIG_TI_K3_DSP_REMOTEPROC)+= ti_k3_dsp_remoteproc.o
+obj-$(CONFIG_TI_K3_M4_REMOTEPROC) += ti_k3_m4_remoteproc.o
obj-$(CONFIG_TI_K3_R5_REMOTEPROC) += ti_k3_r5_remoteproc.o
obj-$(CONFIG_XLNX_R5_REMOTEPROC) += xlnx_r5_remoteproc.o
diff --git a/drivers/remoteproc/ti_k3_m4_remoteproc.c
b/drivers/remoteproc/ti_k3_m4_remoteproc.c
new file mode 100644
index 0..0030e509f6b5d
--- /dev/null
+++ b/drivers/remoteproc/ti_k3_m4_remoteproc.c
@@ -0,0 +1,785 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * TI K3 Cortex-M4 Remote Processor(s) driver
+ *
+ * Copyright (C) 2021-2024 Texas Instruments Incorporated - https://www.ti.com/
+ * Hari Nagalla
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include "omap_remoteproc.h"
+#include "remoteproc_internal.h"
+#include "ti_sci_proc.h"
+
+/**
+ * struct k3_m4_rproc_mem - internal memory structure
+ * @cpu_addr: MPU virtual address of the memory region
+ * @bus_addr: Bus address used to access the memory region
+ * @dev_addr: Device address of the memory region from remote processor view
+ * @size: Size of the memory region
+ */
+struct k3_m4_rproc_mem {
+ void __iomem *cpu_addr;
+ phys_addr_t bus_addr;
+ u32 dev_addr;
+ size_t size;
+};
+
+/**
+ * struct k3_m4_rproc_mem_data - memory definitions for a remote processor
+ * @name: name for this memory entry
+ * @dev_addr: device address for the memory entry
+ */
+struct k3_m4_rproc_mem_data {
+ const char *name;
+ const u32 dev_addr;
+};
+
+/**
+ * struct k3_m4_rproc_dev_data - device data structure for a remote processor
+ * @mems: pointer to memory definitions for a remote processor
+ * @num_mems: number of memory regions in @mems
+ * @uses_lreset: flag to denote the need for local reset management
+ */
+struct k3_m4_rproc_dev_data {
+ const struct k3_m4_rproc_mem_data *mems;
+ u32 num_mems;
+ bool uses_lreset;
+};
+
+/**
+ * struct k3_m4_rproc - k3 remote processor driver structure
+ * @dev: cached device pointer
+ * @rproc: remoteproc device handl
Re: [PATCH v3] ftrace: Fix possible use-after-free issue in ftrace_location()
On 2024/5/3 05:07, Steven Rostedt wrote:
On Wed, 17 Apr 2024 11:28:30 +0800
Zheng Yejian wrote:
diff --git a/kernel/trace/ftrace.c b/kernel/trace/ftrace.c
index da1710499698..e05d3e3dc06a 100644
--- a/kernel/trace/ftrace.c
+++ b/kernel/trace/ftrace.c
@@ -1581,7 +1581,7 @@ static struct dyn_ftrace *lookup_rec(unsigned long start,
unsigned long end)
}
/**
- * ftrace_location_range - return the first address of a traced location
+ * ftrace_location_range_rcu - return the first address of a traced location
kerneldoc comments are for external functions. You need to move this down
to ftrace_location_range() as here you are commenting a local static function.
I'll do it in v4.
But I have to ask, why did you create this static function anyway? There's
only one user of it (the ftrace_location_range()). Why didn't you just
simply add the rcu locking there?
Yes, the only-one-user function looks ugly.
At first thought that ftrace_location_range() needs to a lock, I just do like
that,
no specital reason.
unsigned long ftrace_location_range(unsigned long start, unsigned long end)
{
struct dyn_ftrace *rec;
unsigned long ip = 0;
rcu_read_lock();
rec = lookup_rec(start, end);
if (rec)
ip = rec->ip;
rcu_read_unlock();
return ip;
}
-- Steve
*if it touches the given ip range
* @start: start of range to search.
* @end: end of range to search (inclusive). @end points to the last byte
@@ -1592,7 +1592,7 @@ static struct dyn_ftrace *lookup_rec(unsigned long start,
unsigned long end)
* that is either a NOP or call to the function tracer. It checks the ftrace
* internal tables to determine if the address belongs or not.
*/
-unsigned long ftrace_location_range(unsigned long start, unsigned long end)
+static unsigned long ftrace_location_range_rcu(unsigned long start, unsigned
long end)
{
struct dyn_ftrace *rec;
@@ -1603,6 +1603,16 @@ unsigned long ftrace_location_range(unsigned long start, unsigned long end)
return 0;
}
+unsigned long ftrace_location_range(unsigned long start, unsigned long end)
+{
+ unsigned long loc;
+
+ rcu_read_lock();
+ loc = ftrace_location_range_rcu(start, end);
+ rcu_read_unlock();
+ return loc;
+}
Re: [REGRESSION][v6.8-rc1] virtio-pci: Introduce admin virtqueue
On 2024-05-08 a.m.7:18, Catherine Redfield wrote:
*External email: Use caution opening links or attachments*
On a VM with the GCP kernel (where we first identified the problem), I see:
1. The full kernel log from `journalctl --system > kernlog` attached.
The specific suspend section is here:
May 08 11:08:42 kernel-test-202405080702.c.ubuntu-catred.internal
systemd[1]: Reached target sleep.target - Sleep.
May 08 11:08:42 kernel-test-202405080702.c.ubuntu-catred.internal
systemd[1]: Starting systemd-suspend.service - System Suspend...
May 08 11:08:42 kernel-test-202405080702.c.ubuntu-catred.internal
systemd-sleep[1413]: Performing sleep operation 'suspend'...
May 08 11:08:42 kernel-test-202405080702.c.ubuntu-catred.internal
kernel: PM: suspend entry (deep)
May 08 11:08:42 kernel-test-202405080702.c.ubuntu-catred.internal
kernel: Filesystems sync: 0.008 seconds
May 08 11:08:42 kernel-test-202405080702.c.ubuntu-catred.internal
kernel: Freezing user space processes
May 08 11:08:42 kernel-test-202405080702.c.ubuntu-catred.internal
kernel: Freezing user space processes completed (elapsed 0.001 seconds)
May 08 11:08:42 kernel-test-202405080702.c.ubuntu-catred.internal
kernel: OOM killer disabled.
May 08 11:08:42 kernel-test-202405080702.c.ubuntu-catred.internal
kernel: Freezing remaining freezable tasks
May 08 11:08:42 kernel-test-202405080702.c.ubuntu-catred.internal
kernel: Freezing remaining freezable tasks completed (elapsed 0.000 seconds)
May 08 11:08:42 kernel-test-202405080702.c.ubuntu-catred.internal
kernel: printk: Suspending console(s) (use no_console_suspend to debug)
May 08 11:08:42 kernel-test-202405080702.c.ubuntu-catred.internal
kernel: port 00:03:0.0: PM: dpm_run_callback():
pm_runtime_force_suspend+0x0/0x130 returns -16
May 08 11:08:42 kernel-test-202405080702.c.ubuntu-catred.internal
kernel: port 00:03:0.0: PM: failed to suspend: error -16
Thanks Joesph and Catherine's help.
Hi,
I have alreay synced up with Cananical guys offline about this issue.
I can run "suspend/resume" sucessfully on my local server and VM.
And "PM: failed to suspend: error -16" looks like not cause by my
previous virtio patch ( fd27ef6b44be ("virtio-pci: Introduce admin
virtqueue")) which only modified "virtio_device_freeze" about "suspend"
action.
So I have provide the my steps and debug patch to Joesph and Catherine.
I will also sync up the information here, as follow:
I have read the qemu code and find a way to trigger "suspend/resume" on
my setup, and add some debug message in the latest kerenel
My setps are:
1. QEMU cmdline add following
-global PIIX4_PM.disable_s3=0 \
-global PIIX4_PM.disable_s4=1 \
-netdev type=tap,ifname=tap0,id=hostnet0,script=no,downscript=no \
-device
virtio-net-pci,netdev=hostnet0,id=net0,mac=$SSH_MAC,bus=pci.0,addr=0x3 \
..
2. In the VM, run "systemctl suspend" to PM suspend the VM into memory
3. In qemu hmp shell, run "system_wakeup" to resume the VM again
My VM configuration:
NIC: 1 virtio nic emulated by QEMU
OS: Ubuntu 22.04.4 LTS
kernel: latest kernel, 6.9-rc7: ee5b455b0ada (kernel2/net-next-virito,
kernel2/master, master) Merge tag 'slab-for-6.9-rc7-fixes' of
git://git.kernel.org/pub/scm/linux/kernel/git/vbabka/slab)
I add some debug message on the latest kernel, and do above steps to
trigger "suspen/resume". Everything of VM is OK, VM could suspend/resume
successfully.
Follwing is the kernel log:
May 6 15:59:52 feliu-vm kernel: [ 43.446737] PM: suspend entry (deep)
May 6 16:00:04 feliu-vm kernel: [ 43.467640] Filesystems sync: 0.020
seconds
May 6 16:00:04 feliu-vm kernel: [ 43.467923] Freezing user space
processes
May 6 16:00:04 feliu-vm kernel: [ 43.470294] Freezing user space
processes completed (elapsed 0.002 seconds)
May 6 16:00:04 feliu-vm kernel: [ 43.470299] OOM killer disabled.
May 6 16:00:04 feliu-vm kernel: [ 43.470301] Freezing remaining
freezable tasks
May 6 16:00:04 feliu-vm kernel: [ 43.471482] Freezing remaining
freezable tasks completed (elapsed 0.001 seconds)
May 6 16:00:04 feliu-vm kernel: [ 43.471495] printk: Suspending
console(s) (use no_console_suspend to debug)
May 6 16:00:04 feliu-vm kernel: [ 43.474034] virtio_net virtio0:
godeng virtio device freeze
May 6 16:00:04 feliu-vm kernel: [ 43.475714] virtio_net virtio0 ens3:
godfeng virtnet_freeze done
May 6 16:00:04 feliu-vm kernel: [ 43.475717] virtio_net virtio0:
godfeng VIRTIO_F_ADMIN_VQ not enabled
May 6 16:00:04 feliu-vm kernel: [ 43.475719] virtio_net virtio0:
godeng virtio device freeze done
May 6 16:00:04 feliu-vm kernel: [ 43.535382] smpboot: CPU 1 is now
offline
May 6 16:00:04 feliu-vm kernel: [ 43.537283] IRQ fixup: irq 1 move in
progress, old vector 32
May 6 16:00:04 feliu-vm kernel: [ 43.538504] smpboot: CPU 2 is now
offline
May 6 16:00:04 feliu-vm kernel: [ 43.541392] smpboo
WARNING in fscrypt_fname_siphash
Hello. We are Ubisectech Sirius Team, the vulnerability lab of China ValiantSec. Recently, our team has discovered a issue in Linux kernel 6.7. Attached to the email were a PoC file of the issue. Stack dump: [ cut here ] WARNING: CPU: 0 PID: 10070 at fs/crypto/fname.c:573 fscrypt_fname_siphash+0xdf/0x120 fs/crypto/fname.c:573 Modules linked in: CPU: 0 PID: 10070 Comm: syz-executor.2 Not tainted 6.7.0 #2 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014 RIP: 0010:fscrypt_fname_siphash+0xdf/0x120 fs/crypto/fname.c:573 Code: 00 00 00 fc ff df 48 89 f9 48 c1 e9 03 80 3c 01 00 75 3f 48 8b 7b 08 48 83 c4 10 5b 5d 41 5c e9 d7 79 6e 08 e8 f2 a2 80 ff 90 <0f> 0b 90 eb 93 48 89 14 24 e8 b3 5b d7 ff 48 8b 14 24 eb b7 e8 48 RSP: 0018:c90002887238 EFLAGS: 00010246 RAX: 0004 RBX: c900028872d0 RCX: c900030cb000 RDX: 0004 RSI: 8209535e RDI: 0001 RBP: 888063065180 R08: 0001 R09: R10: R11: 8d4c4d91 R12: R13: 0001 R14: dc00 R15: 888056aba0c4 FS: 7ff63b86f640() GS:88802c60() knlGS: CS: 0010 DS: ES: CR0: 80050033 CR2: 7ff5442398e0 CR3: 57fd8000 CR4: 00750ef0 DR0: DR1: DR2: DR3: DR6: fffe0ff0 DR7: 0400 PKRU: 5554 Call Trace: __ext4fs_dirhash+0x36a/0xb60 fs/ext4/hash.c:268 ext4fs_dirhash+0x246/0x2d0 fs/ext4/hash.c:322 htree_dirblock_to_tree+0x821/0xc90 fs/ext4/namei.c:1124 ext4_htree_fill_tree+0x32d/0xc40 fs/ext4/namei.c:1219 ext4_dx_readdir fs/ext4/dir.c:597 [inline] ext4_readdir+0x1d2d/0x36a0 fs/ext4/dir.c:142 iterate_dir+0x1f4/0x5c0 fs/readdir.c:106 ovl_dir_read fs/overlayfs/readdir.c:315 [inline] ovl_indexdir_cleanup+0x2e2/0x940 fs/overlayfs/readdir.c:1183 ovl_get_indexdir fs/overlayfs/super.c:887 [inline] ovl_fill_super+0x414d/0x6560 fs/overlayfs/super.c:1404 vfs_get_super fs/super.c:1338 [inline] get_tree_nodev+0xda/0x190 fs/super.c:1357 vfs_get_tree+0x93/0x380 fs/super.c:1771 do_new_mount fs/namespace.c:3337 [inline] path_mount+0x679/0x1e40 fs/namespace.c:3664 do_mount fs/namespace.c:3677 [inline] __do_sys_mount fs/namespace.c:3886 [inline] __se_sys_mount fs/namespace.c:3863 [inline] __x64_sys_mount+0x287/0x310 fs/namespace.c:3863 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0x43/0x120 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x6f/0x77 RIP: 0033:0x7ff63aa8fd6d Code: c3 e8 97 2b 00 00 0f 1f 80 00 00 00 00 f3 0f 1e fa 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b0 ff ff ff f7 d8 64 89 01 48 RSP: 002b:7ff63b86f028 EFLAGS: 0246 ORIG_RAX: 00a5 RAX: ffda RBX: 7ff63abcc120 RCX: 7ff63aa8fd6d RDX: 2000 RSI: 2040 RDI: RBP: 7ff63aaf14cd R08: 2140 R09: R10: R11: 0246 R12: R13: 006e R14: 7ff63abcc120 R15: 7ff63b84f000 Thank you for taking the time to read this email and we look forward to working with you further. poc.c Description: Binary data
general protection fault in crypto_skcipher_encrypt
Hello. We are Ubisectech Sirius Team, the vulnerability lab of China ValiantSec. Recently, our team has discovered a issue in Linux kernel 6.7. Attached to the email were a PoC file of the issue. Stack dump: bcachefs (loop0): error validating btree node on loop0 at btree extents level 0/0 u64s 11 type btree_ptr_v2 SPOS_MAX len 0 ver 0: seq 83426fcb67886cbe written 16 min_key POS_MIN durability: 1 ptr: 0:27:0 gen 0 node offset 0 bset u64s 0: unknown checksum type 4, fixing general protection fault, probably for non-canonical address 0xdc04: [#1] PREEMPT SMP KASAN NOPTI KASAN: null-ptr-deref in range [0x0020-0x0027] CPU: 0 PID: 25892 Comm: syz-executor.0 Not tainted 6.7.0 #2 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014 RIP: 0010:crypto_skcipher_alg include/crypto/skcipher.h:387 [inline] RIP: 0010:crypto_skcipher_encrypt+0x48/0x170 crypto/skcipher.c:656 Code: 48 89 fa 48 c1 ea 03 80 3c 02 00 0f 85 17 01 00 00 48 b8 00 00 00 00 00 fc ff df 48 8b 5d 40 48 8d 7b 18 48 89 fa 48 c1 ea 03 <80> 3c 02 00 0f 85 08 01 00 00 48 8d 7b 04 4c 8b 63 18 48 b8 00 00 RSP: 0018:c90002d46388 EFLAGS: 00010202 RAX: dc00 RBX: 0008 RCX: c9000e04a000 RDX: 0004 RSI: 84162b50 RDI: 0020 RBP: c90002d463f8 R08: 0020 R09: 0001 R10: 0001 R11: R12: 0008 R13: 0020 R14: 88801133d600 R15: c90002d467d8 FS: 7fdd0174b640() GS:88802c60() knlGS: CS: 0010 DS: ES: CR0: 80050033 CR2: 001b2df21000 CR3: 57314000 CR4: 00750ef0 DR0: DR1: DR2: DR3: DR6: fffe0ff0 DR7: 0400 PKRU: 5554 Call Trace: do_encrypt_sg+0xbc/0x150 fs/bcachefs/checksum.c:107 do_encrypt+0x27d/0x430 fs/bcachefs/checksum.c:149 gen_poly_key.isra.0+0x144/0x310 fs/bcachefs/checksum.c:190 bch2_checksum+0x1bc/0x2b0 fs/bcachefs/checksum.c:226 bch2_btree_node_read_done+0x75b/0x45a0 fs/bcachefs/btree_io.c:1003 btree_node_read_work+0x77f/0x10e0 fs/bcachefs/btree_io.c:1262 bch2_btree_node_read+0xef3/0x1460 fs/bcachefs/btree_io.c:1641 __bch2_btree_root_read fs/bcachefs/btree_io.c:1680 [inline] bch2_btree_root_read+0x2bc/0x670 fs/bcachefs/btree_io.c:1704 read_btree_roots fs/bcachefs/recovery.c:384 [inline] bch2_fs_recovery+0x28b0/0x52d0 fs/bcachefs/recovery.c:914 bch2_fs_start+0x365/0x5e0 fs/bcachefs/super.c:978 bch2_fs_open+0x1ac9/0x3890 fs/bcachefs/super.c:1968 bch2_mount+0x538/0x13c0 fs/bcachefs/fs.c:1863 legacy_get_tree+0x109/0x220 fs/fs_context.c:662 vfs_get_tree+0x93/0x380 fs/super.c:1771 do_new_mount fs/namespace.c:3337 [inline] path_mount+0x679/0x1e40 fs/namespace.c:3664 do_mount fs/namespace.c:3677 [inline] __do_sys_mount fs/namespace.c:3886 [inline] __se_sys_mount fs/namespace.c:3863 [inline] __x64_sys_mount+0x287/0x310 fs/namespace.c:3863 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0x43/0x120 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x6f/0x77 RIP: 0033:0x7fdd00a91b3e Code: 48 c7 c0 ff ff ff ff eb aa e8 be 0d 00 00 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 f3 0f 1e fa 49 89 ca b8 a5 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b0 ff ff ff f7 d8 64 89 01 48 RSP: 002b:7fdd0174ae38 EFLAGS: 0202 ORIG_RAX: 00a5 RAX: ffda RBX: 000119fc RCX: 7fdd00a91b3e RDX: 20011a00 RSI: 2040 RDI: 7fdd0174ae90 RBP: 7fdd0174aed0 R08: 7fdd0174aed0 R09: 0001 R10: 0001 R11: 0202 R12: 20011a00 R13: 2040 R14: 7fdd0174ae90 R15: 2100 Modules linked in: ---[ end trace ]--- RIP: 0010:crypto_skcipher_alg include/crypto/skcipher.h:387 [inline] RIP: 0010:crypto_skcipher_encrypt+0x48/0x170 crypto/skcipher.c:656 Code: 48 89 fa 48 c1 ea 03 80 3c 02 00 0f 85 17 01 00 00 48 b8 00 00 00 00 00 fc ff df 48 8b 5d 40 48 8d 7b 18 48 89 fa 48 c1 ea 03 <80> 3c 02 00 0f 85 08 01 00 00 48 8d 7b 04 4c 8b 63 18 48 b8 00 00 RSP: 0018:c90002d46388 EFLAGS: 00010202 RAX: dc00 RBX: 0008 RCX: c9000e04a000 RDX: 0004 RSI: 84162b50 RDI: 0020 RBP: c90002d463f8 R08: 0020 R09: 0001 R10: 0001 R11: R12: 0008 R13: 0020 R14: 88801133d600 R15: c90002d467d8 FS: 7fdd0174b640() GS:88802c60() knlGS: CS: 0010 DS: ES: CR0: 80050033 CR2: 55e4cd278120 CR3: 57314000 CR4: 00750ef0 DR0: DR1: DR2: DR3: DR6: fffe0ff0 DR7: 0400 PKRU: 5554 Code disassembly (best guess): 0: 48 89 fa
