From 6ee762720c87c549a9e77b4673673958e55ef736 Mon Sep 17 00:00:00 2001 From: Greg Kroah-Hartman Date: Sat, 12 Jul 2025 15:53:08 +0200 Subject: [PATCH] 5.15-stable patches added patches: aoe-avoid-potential-deadlock-at-set_capacity.patch bpf-fix-precision-backtracking-instruction-iteration.patch bpf-sockmap-fix-skb-refcnt-race-after-locking-changes.patch jfs-fix-null-ptr-deref-in-dtinsertentry.patch rxrpc-fix-oops-due-to-non-existence-of-prealloc-backlog-struct.patch thermal-int340x_thermal-handle-data_vault-when-the-value-is-zero_size_ptr.patch xen-replace-xen_remap-with-memremap.patch --- ...d-potential-deadlock-at-set_capacity.patch | 73 +++++++++++ ...n-backtracking-instruction-iteration.patch | 88 +++++++++++++ ...kb-refcnt-race-after-locking-changes.patch | 120 ++++++++++++++++++ ...-fix-null-ptr-deref-in-dtinsertentry.patch | 47 +++++++ ...existence-of-prealloc-backlog-struct.patch | 44 +++++++ queue-5.15/series | 7 + ...ault-when-the-value-is-zero_size_ptr.patch | 70 ++++++++++ .../xen-replace-xen_remap-with-memremap.patch | 120 ++++++++++++++++++ 8 files changed, 569 insertions(+) create mode 100644 queue-5.15/aoe-avoid-potential-deadlock-at-set_capacity.patch create mode 100644 queue-5.15/bpf-fix-precision-backtracking-instruction-iteration.patch create mode 100644 queue-5.15/bpf-sockmap-fix-skb-refcnt-race-after-locking-changes.patch create mode 100644 queue-5.15/jfs-fix-null-ptr-deref-in-dtinsertentry.patch create mode 100644 queue-5.15/rxrpc-fix-oops-due-to-non-existence-of-prealloc-backlog-struct.patch create mode 100644 queue-5.15/thermal-int340x_thermal-handle-data_vault-when-the-value-is-zero_size_ptr.patch create mode 100644 queue-5.15/xen-replace-xen_remap-with-memremap.patch diff --git a/queue-5.15/aoe-avoid-potential-deadlock-at-set_capacity.patch b/queue-5.15/aoe-avoid-potential-deadlock-at-set_capacity.patch new file mode 100644 index 0000000000..ec85816abc --- /dev/null +++ b/queue-5.15/aoe-avoid-potential-deadlock-at-set_capacity.patch @@ -0,0 +1,73 @@ +From e169bd4fb2b36c4b2bee63c35c740c85daeb2e86 Mon Sep 17 00:00:00 2001 +From: Maksim Kiselev +Date: Wed, 24 Jan 2024 10:24:36 +0300 +Subject: aoe: avoid potential deadlock at set_capacity + +From: Maksim Kiselev + +commit e169bd4fb2b36c4b2bee63c35c740c85daeb2e86 upstream. + +Move set_capacity() outside of the section procected by (&d->lock). +To avoid possible interrupt unsafe locking scenario: + + CPU0 CPU1 + ---- ---- +[1] lock(&bdev->bd_size_lock); + local_irq_disable(); + [2] lock(&d->lock); + [3] lock(&bdev->bd_size_lock); + +[4] lock(&d->lock); + + *** DEADLOCK *** + +Where [1](&bdev->bd_size_lock) hold by zram_add()->set_capacity(). +[2]lock(&d->lock) hold by aoeblk_gdalloc(). And aoeblk_gdalloc() +is trying to acquire [3](&bdev->bd_size_lock) at set_capacity() call. +In this situation an attempt to acquire [4]lock(&d->lock) from +aoecmd_cfg_rsp() will lead to deadlock. + +So the simplest solution is breaking lock dependency +[2](&d->lock) -> [3](&bdev->bd_size_lock) by moving set_capacity() +outside. + +Signed-off-by: Maksim Kiselev +Reviewed-by: Christoph Hellwig +Link: https://lore.kernel.org/r/20240124072436.3745720-2-bigunclemax@gmail.com +Signed-off-by: Jens Axboe +[ Larry: backport to 5.15.y. Minor conflict resolved due to missing commit d9c2bd252a457 + aoe: add error handling support for add_disk() ] +Signed-off-by: Larry Bassel +Signed-off-by: Greg Kroah-Hartman +--- + drivers/block/aoe/aoeblk.c | 5 ++++- + 1 file changed, 4 insertions(+), 1 deletion(-) + +--- a/drivers/block/aoe/aoeblk.c ++++ b/drivers/block/aoe/aoeblk.c +@@ -346,6 +346,7 @@ aoeblk_gdalloc(void *vp) + struct gendisk *gd; + mempool_t *mp; + struct blk_mq_tag_set *set; ++ sector_t ssize; + ulong flags; + int late = 0; + int err; +@@ -408,7 +409,7 @@ aoeblk_gdalloc(void *vp) + gd->minors = AOE_PARTITIONS; + gd->fops = &aoe_bdops; + gd->private_data = d; +- set_capacity(gd, d->ssize); ++ ssize = d->ssize; + snprintf(gd->disk_name, sizeof gd->disk_name, "etherd/e%ld.%d", + d->aoemajor, d->aoeminor); + +@@ -417,6 +418,8 @@ aoeblk_gdalloc(void *vp) + + spin_unlock_irqrestore(&d->lock, flags); + ++ set_capacity(gd, ssize); ++ + device_add_disk(NULL, gd, aoe_attr_groups); + aoedisk_add_debugfs(d); + diff --git a/queue-5.15/bpf-fix-precision-backtracking-instruction-iteration.patch b/queue-5.15/bpf-fix-precision-backtracking-instruction-iteration.patch new file mode 100644 index 0000000000..d8e2a4af1c --- /dev/null +++ b/queue-5.15/bpf-fix-precision-backtracking-instruction-iteration.patch @@ -0,0 +1,88 @@ +From 973c7a0d8a38e675570c3336c664f5610bd4eb19 Mon Sep 17 00:00:00 2001 +From: Andrii Nakryiko +Date: Thu, 9 Nov 2023 16:26:37 -0800 +Subject: bpf: fix precision backtracking instruction iteration + +From: Andrii Nakryiko + +commit 4bb7ea946a370707315ab774432963ce47291946 upstream. + +Fix an edge case in __mark_chain_precision() which prematurely stops +backtracking instructions in a state if it happens that state's first +and last instruction indexes are the same. This situations doesn't +necessarily mean that there were no instructions simulated in a state, +but rather that we starting from the instruction, jumped around a bit, +and then ended up at the same instruction before checkpointing or +marking precision. + +To distinguish between these two possible situations, we need to consult +jump history. If it's empty or contain a single record "bridging" parent +state and first instruction of processed state, then we indeed +backtracked all instructions in this state. But if history is not empty, +we are definitely not done yet. + +Move this logic inside get_prev_insn_idx() to contain it more nicely. +Use -ENOENT return code to denote "we are out of instructions" +situation. + +This bug was exposed by verifier_loop1.c's bounded_recursion subtest, once +the next fix in this patch set is applied. + +Acked-by: Eduard Zingerman +Fixes: b5dc0163d8fd ("bpf: precise scalar_value tracking") +Signed-off-by: Andrii Nakryiko +Link: https://lore.kernel.org/r/20231110002638.4168352-3-andrii@kernel.org +Signed-off-by: Alexei Starovoitov +Signed-off-by: Aaron Lu +Reported-by: Wei Wei +Closes: https://lore.kernel.org/all/20250605070921.GA3795@bytedance/ +Signed-off-by: Greg Kroah-Hartman +Signed-off-by: Greg Kroah-Hartman +--- + kernel/bpf/verifier.c | 21 +++++++++++++++++++-- + 1 file changed, 19 insertions(+), 2 deletions(-) + +--- a/kernel/bpf/verifier.c ++++ b/kernel/bpf/verifier.c +@@ -2134,12 +2134,29 @@ static int push_jmp_history(struct bpf_v + + /* Backtrack one insn at a time. If idx is not at the top of recorded + * history then previous instruction came from straight line execution. ++ * Return -ENOENT if we exhausted all instructions within given state. ++ * ++ * It's legal to have a bit of a looping with the same starting and ending ++ * insn index within the same state, e.g.: 3->4->5->3, so just because current ++ * instruction index is the same as state's first_idx doesn't mean we are ++ * done. If there is still some jump history left, we should keep going. We ++ * need to take into account that we might have a jump history between given ++ * state's parent and itself, due to checkpointing. In this case, we'll have ++ * history entry recording a jump from last instruction of parent state and ++ * first instruction of given state. + */ + static int get_prev_insn_idx(struct bpf_verifier_state *st, int i, + u32 *history) + { + u32 cnt = *history; + ++ if (i == st->first_insn_idx) { ++ if (cnt == 0) ++ return -ENOENT; ++ if (cnt == 1 && st->jmp_history[0].idx == i) ++ return -ENOENT; ++ } ++ + if (cnt && st->jmp_history[cnt - 1].idx == i) { + i = st->jmp_history[cnt - 1].prev_idx; + (*history)--; +@@ -2630,9 +2647,9 @@ static int __mark_chain_precision(struct + * Nothing to be tracked further in the parent state. + */ + return 0; +- if (i == first_idx) +- break; + i = get_prev_insn_idx(st, i, &history); ++ if (i == -ENOENT) ++ break; + if (i >= env->prog->len) { + /* This can happen if backtracking reached insn 0 + * and there are still reg_mask or stack_mask diff --git a/queue-5.15/bpf-sockmap-fix-skb-refcnt-race-after-locking-changes.patch b/queue-5.15/bpf-sockmap-fix-skb-refcnt-race-after-locking-changes.patch new file mode 100644 index 0000000000..d2ab27e534 --- /dev/null +++ b/queue-5.15/bpf-sockmap-fix-skb-refcnt-race-after-locking-changes.patch @@ -0,0 +1,120 @@ +From a454d84ee20baf7bd7be90721b9821f73c7d23d9 Mon Sep 17 00:00:00 2001 +From: John Fastabend +Date: Fri, 1 Sep 2023 13:21:37 -0700 +Subject: bpf, sockmap: Fix skb refcnt race after locking changes + +From: John Fastabend + +commit a454d84ee20baf7bd7be90721b9821f73c7d23d9 upstream. + +There is a race where skb's from the sk_psock_backlog can be referenced +after userspace side has already skb_consumed() the sk_buff and its refcnt +dropped to zer0 causing use after free. + +The flow is the following: + + while ((skb = skb_peek(&psock->ingress_skb)) + sk_psock_handle_Skb(psock, skb, ..., ingress) + if (!ingress) ... + sk_psock_skb_ingress + sk_psock_skb_ingress_enqueue(skb) + msg->skb = skb + sk_psock_queue_msg(psock, msg) + skb_dequeue(&psock->ingress_skb) + +The sk_psock_queue_msg() puts the msg on the ingress_msg queue. This is +what the application reads when recvmsg() is called. An application can +read this anytime after the msg is placed on the queue. The recvmsg hook +will also read msg->skb and then after user space reads the msg will call +consume_skb(skb) on it effectively free'ing it. + +But, the race is in above where backlog queue still has a reference to +the skb and calls skb_dequeue(). If the skb_dequeue happens after the +user reads and free's the skb we have a use after free. + +The !ingress case does not suffer from this problem because it uses +sendmsg_*(sk, msg) which does not pass the sk_buff further down the +stack. + +The following splat was observed with 'test_progs -t sockmap_listen': + + [ 1022.710250][ T2556] general protection fault, ... + [...] + [ 1022.712830][ T2556] Workqueue: events sk_psock_backlog + [ 1022.713262][ T2556] RIP: 0010:skb_dequeue+0x4c/0x80 + [ 1022.713653][ T2556] Code: ... + [...] + [ 1022.720699][ T2556] Call Trace: + [ 1022.720984][ T2556] + [ 1022.721254][ T2556] ? die_addr+0x32/0x80^M + [ 1022.721589][ T2556] ? exc_general_protection+0x25a/0x4b0 + [ 1022.722026][ T2556] ? asm_exc_general_protection+0x22/0x30 + [ 1022.722489][ T2556] ? skb_dequeue+0x4c/0x80 + [ 1022.722854][ T2556] sk_psock_backlog+0x27a/0x300 + [ 1022.723243][ T2556] process_one_work+0x2a7/0x5b0 + [ 1022.723633][ T2556] worker_thread+0x4f/0x3a0 + [ 1022.723998][ T2556] ? __pfx_worker_thread+0x10/0x10 + [ 1022.724386][ T2556] kthread+0xfd/0x130 + [ 1022.724709][ T2556] ? __pfx_kthread+0x10/0x10 + [ 1022.725066][ T2556] ret_from_fork+0x2d/0x50 + [ 1022.725409][ T2556] ? __pfx_kthread+0x10/0x10 + [ 1022.725799][ T2556] ret_from_fork_asm+0x1b/0x30 + [ 1022.726201][ T2556] + +To fix we add an skb_get() before passing the skb to be enqueued in the +engress queue. This bumps the skb->users refcnt so that consume_skb() +and kfree_skb will not immediately free the sk_buff. With this we can +be sure the skb is still around when we do the dequeue. Then we just +need to decrement the refcnt or free the skb in the backlog case which +we do by calling kfree_skb() on the ingress case as well as the sendmsg +case. + +Before locking change from fixes tag we had the sock locked so we +couldn't race with user and there was no issue here. + +Fixes: 799aa7f98d53e ("skmsg: Avoid lock_sock() in sk_psock_backlog()") +Reported-by: Jiri Olsa +Signed-off-by: John Fastabend +Signed-off-by: Daniel Borkmann +Tested-by: Xu Kuohai +Tested-by: Jiri Olsa +Link: https://lore.kernel.org/bpf/20230901202137.214666-1-john.fastabend@gmail.com +Signed-off-by: Pranav Tyagi +Signed-off-by: Greg Kroah-Hartman +--- + net/core/skmsg.c | 12 ++++++++---- + 1 file changed, 8 insertions(+), 4 deletions(-) + +--- a/net/core/skmsg.c ++++ b/net/core/skmsg.c +@@ -608,12 +608,18 @@ static int sk_psock_skb_ingress_self(str + static int sk_psock_handle_skb(struct sk_psock *psock, struct sk_buff *skb, + u32 off, u32 len, bool ingress) + { ++ int err = 0; ++ + if (!ingress) { + if (!sock_writeable(psock->sk)) + return -EAGAIN; + return skb_send_sock(psock->sk, skb, off, len); + } +- return sk_psock_skb_ingress(psock, skb, off, len); ++ skb_get(skb); ++ err = sk_psock_skb_ingress(psock, skb, off, len); ++ if (err < 0) ++ kfree_skb(skb); ++ return err; + } + + static void sk_psock_skb_state(struct sk_psock *psock, +@@ -693,9 +699,7 @@ static void sk_psock_backlog(struct work + /* The entire skb sent, clear state */ + sk_psock_skb_state(psock, state, 0, 0); + skb = skb_dequeue(&psock->ingress_skb); +- if (!ingress) { +- kfree_skb(skb); +- } ++ kfree_skb(skb); + } + end: + mutex_unlock(&psock->work_mutex); diff --git a/queue-5.15/jfs-fix-null-ptr-deref-in-dtinsertentry.patch b/queue-5.15/jfs-fix-null-ptr-deref-in-dtinsertentry.patch new file mode 100644 index 0000000000..6639facdba --- /dev/null +++ b/queue-5.15/jfs-fix-null-ptr-deref-in-dtinsertentry.patch @@ -0,0 +1,47 @@ +From ce6dede912f064a855acf6f04a04cbb2c25b8c8c Mon Sep 17 00:00:00 2001 +From: Edward Adam Davis +Date: Thu, 11 Apr 2024 20:05:28 +0800 +Subject: jfs: fix null ptr deref in dtInsertEntry + +From: Edward Adam Davis + +commit ce6dede912f064a855acf6f04a04cbb2c25b8c8c upstream. + +[syzbot reported] +general protection fault, probably for non-canonical address 0xdffffc0000000001: 0000 [#1] PREEMPT SMP KASAN PTI +KASAN: null-ptr-deref in range [0x0000000000000008-0x000000000000000f] +CPU: 0 PID: 5061 Comm: syz-executor404 Not tainted 6.8.0-syzkaller-08951-gfe46a7dd189e #0 +Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 03/27/2024 +RIP: 0010:dtInsertEntry+0xd0c/0x1780 fs/jfs/jfs_dtree.c:3713 +... +[Analyze] +In dtInsertEntry(), when the pointer h has the same value as p, after writing +name in UniStrncpy_to_le(), p->header.flag will be cleared. This will cause the +previously true judgment "p->header.flag & BT-LEAF" to change to no after writing +the name operation, this leads to entering an incorrect branch and accessing the +uninitialized object ih when judging this condition for the second time. + +[Fix] +After got the page, check freelist first, if freelist == 0 then exit dtInsert() +and return -EINVAL. + +Reported-by: syzbot+bba84aef3a26fb93deb9@syzkaller.appspotmail.com +Signed-off-by: Edward Adam Davis +Signed-off-by: Dave Kleikamp +Signed-off-by: Aditya Dutt +Signed-off-by: Greg Kroah-Hartman +--- + fs/jfs/jfs_dtree.c | 2 ++ + 1 file changed, 2 insertions(+) + +--- a/fs/jfs/jfs_dtree.c ++++ b/fs/jfs/jfs_dtree.c +@@ -835,6 +835,8 @@ int dtInsert(tid_t tid, struct inode *ip + * the full page. + */ + DT_GETSEARCH(ip, btstack->top, bn, mp, p, index); ++ if (p->header.freelist == 0) ++ return -EINVAL; + + /* + * insert entry for new key diff --git a/queue-5.15/rxrpc-fix-oops-due-to-non-existence-of-prealloc-backlog-struct.patch b/queue-5.15/rxrpc-fix-oops-due-to-non-existence-of-prealloc-backlog-struct.patch new file mode 100644 index 0000000000..ba999294de --- /dev/null +++ b/queue-5.15/rxrpc-fix-oops-due-to-non-existence-of-prealloc-backlog-struct.patch @@ -0,0 +1,44 @@ +From 880a88f318cf1d2a0f4c0a7ff7b07e2062b434a4 Mon Sep 17 00:00:00 2001 +From: David Howells +Date: Tue, 8 Jul 2025 22:15:04 +0100 +Subject: rxrpc: Fix oops due to non-existence of prealloc backlog struct + +From: David Howells + +commit 880a88f318cf1d2a0f4c0a7ff7b07e2062b434a4 upstream. + +If an AF_RXRPC service socket is opened and bound, but calls are +preallocated, then rxrpc_alloc_incoming_call() will oops because the +rxrpc_backlog struct doesn't get allocated until the first preallocation is +made. + +Fix this by returning NULL from rxrpc_alloc_incoming_call() if there is no +backlog struct. This will cause the incoming call to be aborted. + +Reported-by: Junvyyang, Tencent Zhuque Lab +Suggested-by: Junvyyang, Tencent Zhuque Lab +Signed-off-by: David Howells +cc: LePremierHomme +cc: Marc Dionne +cc: Willy Tarreau +cc: Simon Horman +cc: linux-afs@lists.infradead.org +Link: https://patch.msgid.link/20250708211506.2699012-3-dhowells@redhat.com +Signed-off-by: Jakub Kicinski +Signed-off-by: Greg Kroah-Hartman +--- + net/rxrpc/call_accept.c | 3 +++ + 1 file changed, 3 insertions(+) + +--- a/net/rxrpc/call_accept.c ++++ b/net/rxrpc/call_accept.c +@@ -270,6 +270,9 @@ static struct rxrpc_call *rxrpc_alloc_in + unsigned short call_tail, conn_tail, peer_tail; + unsigned short call_count, conn_count; + ++ if (!b) ++ return NULL; ++ + /* #calls >= #conns >= #peers must hold true. */ + call_head = smp_load_acquire(&b->call_backlog_head); + call_tail = b->call_backlog_tail; diff --git a/queue-5.15/series b/queue-5.15/series index 68f7ac6e9d..6f35c1de7f 100644 --- a/queue-5.15/series +++ b/queue-5.15/series @@ -17,3 +17,10 @@ net-sched-abort-__tc_modify_qdisc-if-parent-class-do.patch x86-cpu-amd-properly-check-the-tsa-microcode.patch fs-proc-do_task_stat-use-__for_each_thread.patch ice-safer-stats-processing.patch +rxrpc-fix-oops-due-to-non-existence-of-prealloc-backlog-struct.patch +bpf-fix-precision-backtracking-instruction-iteration.patch +thermal-int340x_thermal-handle-data_vault-when-the-value-is-zero_size_ptr.patch +aoe-avoid-potential-deadlock-at-set_capacity.patch +bpf-sockmap-fix-skb-refcnt-race-after-locking-changes.patch +jfs-fix-null-ptr-deref-in-dtinsertentry.patch +xen-replace-xen_remap-with-memremap.patch diff --git a/queue-5.15/thermal-int340x_thermal-handle-data_vault-when-the-value-is-zero_size_ptr.patch b/queue-5.15/thermal-int340x_thermal-handle-data_vault-when-the-value-is-zero_size_ptr.patch new file mode 100644 index 0000000000..bc7a73b1bb --- /dev/null +++ b/queue-5.15/thermal-int340x_thermal-handle-data_vault-when-the-value-is-zero_size_ptr.patch @@ -0,0 +1,70 @@ +From 7931e28098a4c1a2a6802510b0cbe57546d2049d Mon Sep 17 00:00:00 2001 +From: "Lee, Chun-Yi" +Date: Mon, 8 Aug 2022 21:21:58 +0800 +Subject: thermal/int340x_thermal: handle data_vault when the value is ZERO_SIZE_PTR + +From: Lee, Chun-Yi + +commit 7931e28098a4c1a2a6802510b0cbe57546d2049d upstream. + +In some case, the GDDV returns a package with a buffer which has +zero length. It causes that kmemdup() returns ZERO_SIZE_PTR (0x10). + +Then the data_vault_read() got NULL point dereference problem when +accessing the 0x10 value in data_vault. + +[ 71.024560] BUG: kernel NULL pointer dereference, address: +0000000000000010 + +This patch uses ZERO_OR_NULL_PTR() for checking ZERO_SIZE_PTR or +NULL value in data_vault. + +Signed-off-by: "Lee, Chun-Yi" +Signed-off-by: Rafael J. Wysocki +[ Larry: backport to 5.15.y. Minor conflict resolved due to missing commit 9e5d3d6be664 + thermal: int340x: Consolidate freeing of acpi_buffer pointer ] +Signed-off-by: Larry Bassel +Signed-off-by: Greg Kroah-Hartman +--- + drivers/thermal/intel/int340x_thermal/int3400_thermal.c | 9 +++++---- + 1 file changed, 5 insertions(+), 4 deletions(-) + +--- a/drivers/thermal/intel/int340x_thermal/int3400_thermal.c ++++ b/drivers/thermal/intel/int340x_thermal/int3400_thermal.c +@@ -469,7 +469,7 @@ static void int3400_setup_gddv(struct in + priv->data_vault = kmemdup(obj->package.elements[0].buffer.pointer, + obj->package.elements[0].buffer.length, + GFP_KERNEL); +- if (!priv->data_vault) { ++ if (ZERO_OR_NULL_PTR(priv->data_vault)) { + kfree(buffer.pointer); + return; + } +@@ -540,7 +540,7 @@ static int int3400_thermal_probe(struct + goto free_imok; + } + +- if (priv->data_vault) { ++ if (!ZERO_OR_NULL_PTR(priv->data_vault)) { + result = sysfs_create_group(&pdev->dev.kobj, + &data_attribute_group); + if (result) +@@ -558,7 +558,8 @@ static int int3400_thermal_probe(struct + free_sysfs: + cleanup_odvp(priv); + if (priv->data_vault) { +- sysfs_remove_group(&pdev->dev.kobj, &data_attribute_group); ++ if (!ZERO_OR_NULL_PTR(priv->data_vault)) ++ sysfs_remove_group(&pdev->dev.kobj, &data_attribute_group); + kfree(priv->data_vault); + } + free_uuid: +@@ -590,7 +591,7 @@ static int int3400_thermal_remove(struct + if (!priv->rel_misc_dev_res) + acpi_thermal_rel_misc_device_remove(priv->adev->handle); + +- if (priv->data_vault) ++ if (!ZERO_OR_NULL_PTR(priv->data_vault)) + sysfs_remove_group(&pdev->dev.kobj, &data_attribute_group); + sysfs_remove_group(&pdev->dev.kobj, &uuid_attribute_group); + sysfs_remove_group(&pdev->dev.kobj, &imok_attribute_group); diff --git a/queue-5.15/xen-replace-xen_remap-with-memremap.patch b/queue-5.15/xen-replace-xen_remap-with-memremap.patch new file mode 100644 index 0000000000..5e173a754a --- /dev/null +++ b/queue-5.15/xen-replace-xen_remap-with-memremap.patch @@ -0,0 +1,120 @@ +From 41925b105e345ebc84cedb64f59d20cb14a62613 Mon Sep 17 00:00:00 2001 +From: Juergen Gross +Date: Mon, 30 May 2022 10:26:34 +0200 +Subject: xen: replace xen_remap() with memremap() + +From: Juergen Gross + +commit 41925b105e345ebc84cedb64f59d20cb14a62613 upstream. + +xen_remap() is used to establish mappings for frames not under direct +control of the kernel: for Xenstore and console ring pages, and for +grant pages of non-PV guests. + +Today xen_remap() is defined to use ioremap() on x86 (doing uncached +mappings), and ioremap_cache() on Arm (doing cached mappings). + +Uncached mappings for those use cases are bad for performance, so they +should be avoided if possible. As all use cases of xen_remap() don't +require uncached mappings (the mapped area is always physical RAM), +a mapping using the standard WB cache mode is fine. + +As sparse is flagging some of the xen_remap() use cases to be not +appropriate for iomem(), as the result is not annotated with the +__iomem modifier, eliminate xen_remap() completely and replace all +use cases with memremap() specifying the MEMREMAP_WB caching mode. + +xen_unmap() can be replaced with memunmap(). + +Reported-by: kernel test robot +Signed-off-by: Juergen Gross +Reviewed-by: Boris Ostrovsky +Acked-by: Stefano Stabellini +Link: https://lore.kernel.org/r/20220530082634.6339-1-jgross@suse.com +Signed-off-by: Juergen Gross +Signed-off-by: Teddy Astie [backport to 5.15.y] +Signed-off-by: Greg Kroah-Hartman +--- + arch/x86/include/asm/xen/page.h | 3 --- + drivers/tty/hvc/hvc_xen.c | 2 +- + drivers/xen/grant-table.c | 6 +++--- + drivers/xen/xenbus/xenbus_probe.c | 3 +-- + include/xen/arm/page.h | 3 --- + 5 files changed, 5 insertions(+), 12 deletions(-) + +--- a/arch/x86/include/asm/xen/page.h ++++ b/arch/x86/include/asm/xen/page.h +@@ -355,9 +355,6 @@ unsigned long arbitrary_virt_to_mfn(void + void make_lowmem_page_readonly(void *vaddr); + void make_lowmem_page_readwrite(void *vaddr); + +-#define xen_remap(cookie, size) ioremap((cookie), (size)) +-#define xen_unmap(cookie) iounmap((cookie)) +- + static inline bool xen_arch_need_swiotlb(struct device *dev, + phys_addr_t phys, + dma_addr_t dev_addr) +--- a/drivers/tty/hvc/hvc_xen.c ++++ b/drivers/tty/hvc/hvc_xen.c +@@ -270,7 +270,7 @@ static int xen_hvm_console_init(void) + if (r < 0 || v == 0) + goto err; + gfn = v; +- info->intf = xen_remap(gfn << XEN_PAGE_SHIFT, XEN_PAGE_SIZE); ++ info->intf = memremap(gfn << XEN_PAGE_SHIFT, XEN_PAGE_SIZE, MEMREMAP_WB); + if (info->intf == NULL) + goto err; + info->vtermno = HVC_COOKIE; +--- a/drivers/xen/grant-table.c ++++ b/drivers/xen/grant-table.c +@@ -743,7 +743,7 @@ int gnttab_setup_auto_xlat_frames(phys_a + if (xen_auto_xlat_grant_frames.count) + return -EINVAL; + +- vaddr = xen_remap(addr, XEN_PAGE_SIZE * max_nr_gframes); ++ vaddr = memremap(addr, XEN_PAGE_SIZE * max_nr_gframes, MEMREMAP_WB); + if (vaddr == NULL) { + pr_warn("Failed to ioremap gnttab share frames (addr=%pa)!\n", + &addr); +@@ -751,7 +751,7 @@ int gnttab_setup_auto_xlat_frames(phys_a + } + pfn = kcalloc(max_nr_gframes, sizeof(pfn[0]), GFP_KERNEL); + if (!pfn) { +- xen_unmap(vaddr); ++ memunmap(vaddr); + return -ENOMEM; + } + for (i = 0; i < max_nr_gframes; i++) +@@ -770,7 +770,7 @@ void gnttab_free_auto_xlat_frames(void) + if (!xen_auto_xlat_grant_frames.count) + return; + kfree(xen_auto_xlat_grant_frames.pfn); +- xen_unmap(xen_auto_xlat_grant_frames.vaddr); ++ memunmap(xen_auto_xlat_grant_frames.vaddr); + + xen_auto_xlat_grant_frames.pfn = NULL; + xen_auto_xlat_grant_frames.count = 0; +--- a/drivers/xen/xenbus/xenbus_probe.c ++++ b/drivers/xen/xenbus/xenbus_probe.c +@@ -982,8 +982,7 @@ static int __init xenbus_init(void) + #endif + xen_store_gfn = (unsigned long)v; + xen_store_interface = +- xen_remap(xen_store_gfn << XEN_PAGE_SHIFT, +- XEN_PAGE_SIZE); ++ memremap(xen_store_gfn << XEN_PAGE_SHIFT, XEN_PAGE_SIZE, MEMREMAP_WB); + break; + default: + pr_warn("Xenstore state unknown\n"); +--- a/include/xen/arm/page.h ++++ b/include/xen/arm/page.h +@@ -109,9 +109,6 @@ static inline bool set_phys_to_machine(u + return __set_phys_to_machine(pfn, mfn); + } + +-#define xen_remap(cookie, size) ioremap_cache((cookie), (size)) +-#define xen_unmap(cookie) iounmap((cookie)) +- + bool xen_arch_need_swiotlb(struct device *dev, + phys_addr_t phys, + dma_addr_t dev_addr); -- 2.47.2