August 2022 - Linux-stable-mirror

[PATCH] mips: pci: remove extraneous asterisk from top level comment of ar2315 PCI driver

by Bagas Sanjaya

kernel test robot reported kernel-doc warning: arch/mips/pci/pci-ar2315.c:6: warning: This comment starts with '/**', but isn't a kernel-doc comment. Refer Documentation/doc-guide/kernel-doc.rst * Both AR2315 and AR2316 chips have PCI interface unit, which supports DMA The warning above is caused by an extraneous asterisk on the top level (description) comment of pci-ar2315.c, for which the comment is confused as kernel-doc comment instead. Remove the asterisk. Link: https://lore.kernel.org/linux-doc/202208221854.8ASrzjKa-lkp@intel.com/ Fixes: 3ed7a2a702dc0f ("MIPS: ath25: add AR2315 PCI host controller driver") Fixes: 3e58e839150db0 ("scripts: kernel-doc: add warning for comment not following kernel-doc syntax") Reported-by: kernel test robot <lkp(a)intel.com> Cc: stable(a)vger.kernel.org # v5.15, v5.19 Signed-off-by: Bagas Sanjaya <bagasdotme(a)gmail.com> --- The second Fixes: commit exposes the kernel-doc warning, which the culprit is actually the first Fixes: commit, so it make sense to apply this patch to supported stable branches after the second commit one. arch/mips/pci/pci-ar2315.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/mips/pci/pci-ar2315.c b/arch/mips/pci/pci-ar2315.c index 30e0922f4ceaec..e17d862cfa4c6a 100644 --- a/arch/mips/pci/pci-ar2315.c +++ b/arch/mips/pci/pci-ar2315.c @@ -2,7 +2,7 @@ /* */ -/** +/* * Both AR2315 and AR2316 chips have PCI interface unit, which supports DMA * and interrupt. PCI interface supports MMIO access method, but does not * seem to support I/O ports. base-commit: 072e51356cd5a4a1c12c1020bc054c99b98333df -- An old man doll... just what I always wanted! - Clara

2 years, 5 months

3
3
0 0

patch "Revert "usb: typec: ucsi: add a common function" added to usb-linus

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled Revert "usb: typec: ucsi: add a common function to my usb git tree which can be found at git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git in the usb-linus branch. The patch will show up in the next release of the linux-next tree (usually sometime within the next 24 hours during the week.) The patch will hopefully also be merged in Linus's tree for the next -rc kernel release. If you have any questions about this process, please let me know. From 5f73aa2cf8bef4a39baa1591c3144ede4788826e Mon Sep 17 00:00:00 2001 From: Takashi Iwai <tiwai(a)suse.de> Date: Tue, 23 Aug 2022 08:54:55 +0200 Subject: Revert "usb: typec: ucsi: add a common function ucsi_unregister_connectors()" The recent commit 87d0e2f41b8c ("usb: typec: ucsi: add a common function ucsi_unregister_connectors()") introduced a regression that caused NULL dereference at reading the power supply sysfs. It's a stale sysfs entry that should have been removed but remains with NULL ops. The commit changed the error handling to skip the entries after a NULL con->wq, and this leaves the power device unreleased. For addressing the regression, the straight revert is applied here. Further code improvements can be done from the scratch again. Link: https://bugzilla.suse.com/show_bug.cgi?id=1202386 Link: https://lore.kernel.org/r/87r11cmbx0.wl-tiwai@suse.de Fixes: 87d0e2f41b8c ("usb: typec: ucsi: add a common function ucsi_unregister_connectors()") Cc: <stable(a)vger.kernel.org> Acked-by: Heikki Krogerus <heikki.krogerus(a)linux.intel.com> Signed-off-by: Takashi Iwai <tiwai(a)suse.de> Link: https://lore.kernel.org/r/20220823065455.32579-1-tiwai@suse.de Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/usb/typec/ucsi/ucsi.c | 53 ++++++++++++++++------------------- 1 file changed, 24 insertions(+), 29 deletions(-) diff --git a/drivers/usb/typec/ucsi/ucsi.c b/drivers/usb/typec/ucsi/ucsi.c index 1aea46493b85..7f2624f42724 100644 --- a/drivers/usb/typec/ucsi/ucsi.c +++ b/drivers/usb/typec/ucsi/ucsi.c @@ -1200,32 +1200,6 @@ static int ucsi_register_port(struct ucsi *ucsi, int index) return ret; } -static void ucsi_unregister_connectors(struct ucsi *ucsi) -{ - struct ucsi_connector *con; - int i; - - if (!ucsi->connector) - return; - - for (i = 0; i < ucsi->cap.num_connectors; i++) { - con = &ucsi->connector[i]; - - if (!con->wq) - break; - - cancel_work_sync(&con->work); - ucsi_unregister_partner(con); - ucsi_unregister_altmodes(con, UCSI_RECIPIENT_CON); - ucsi_unregister_port_psy(con); - destroy_workqueue(con->wq); - typec_unregister_port(con->port); - } - - kfree(ucsi->connector); - ucsi->connector = NULL; -} - /** * ucsi_init - Initialize UCSI interface * @ucsi: UCSI to be initialized @@ -1234,6 +1208,7 @@ static void ucsi_unregister_connectors(struct ucsi *ucsi) */ static int ucsi_init(struct ucsi *ucsi) { + struct ucsi_connector *con; u64 command; int ret; int i; @@ -1264,7 +1239,7 @@ static int ucsi_init(struct ucsi *ucsi) } /* Allocate the connectors. Released in ucsi_unregister() */ - ucsi->connector = kcalloc(ucsi->cap.num_connectors, + ucsi->connector = kcalloc(ucsi->cap.num_connectors + 1, sizeof(*ucsi->connector), GFP_KERNEL); if (!ucsi->connector) { ret = -ENOMEM; @@ -1288,7 +1263,15 @@ static int ucsi_init(struct ucsi *ucsi) return 0; err_unregister: - ucsi_unregister_connectors(ucsi); + for (con = ucsi->connector; con->port; con++) { + ucsi_unregister_partner(con); + ucsi_unregister_altmodes(con, UCSI_RECIPIENT_CON); + ucsi_unregister_port_psy(con); + if (con->wq) + destroy_workqueue(con->wq); + typec_unregister_port(con->port); + con->port = NULL; + } err_reset: memset(&ucsi->cap, 0, sizeof(ucsi->cap)); @@ -1402,6 +1385,7 @@ EXPORT_SYMBOL_GPL(ucsi_register); void ucsi_unregister(struct ucsi *ucsi) { u64 cmd = UCSI_SET_NOTIFICATION_ENABLE; + int i; /* Make sure that we are not in the middle of driver initialization */ cancel_delayed_work_sync(&ucsi->work); @@ -1409,7 +1393,18 @@ void ucsi_unregister(struct ucsi *ucsi) /* Disable notifications */ ucsi->ops->async_write(ucsi, UCSI_CONTROL, &cmd, sizeof(cmd)); - ucsi_unregister_connectors(ucsi); + for (i = 0; i < ucsi->cap.num_connectors; i++) { + cancel_work_sync(&ucsi->connector[i].work); + ucsi_unregister_partner(&ucsi->connector[i]); + ucsi_unregister_altmodes(&ucsi->connector[i], + UCSI_RECIPIENT_CON); + ucsi_unregister_port_psy(&ucsi->connector[i]); + if (ucsi->connector[i].wq) + destroy_workqueue(ucsi->connector[i].wq); + typec_unregister_port(ucsi->connector[i].port); + } + + kfree(ucsi->connector); } EXPORT_SYMBOL_GPL(ucsi_unregister); -- 2.37.2

2 years, 5 months

1
0
0 0

[PATCH 5.10] bpf: Fix KASAN use-after-free Read in compute_effective_progs

by Pu Lehui

From: Tadeusz Struk <tadeusz.struk(a)linaro.org> commit 4c46091ee985ae84c60c5e95055d779fcd291d87 upstream. Syzbot found a Use After Free bug in compute_effective_progs(). The reproducer creates a number of BPF links, and causes a fault injected alloc to fail, while calling bpf_link_detach on them. Link detach triggers the link to be freed by bpf_link_free(), which calls __cgroup_bpf_detach() and update_effective_progs(). If the memory allocation in this function fails, the function restores the pointer to the bpf_cgroup_link on the cgroup list, but the memory gets freed just after it returns. After this, every subsequent call to update_effective_progs() causes this already deallocated pointer to be dereferenced in prog_list_length(), and triggers KASAN UAF error. To fix this issue don't preserve the pointer to the prog or link in the list, but remove it and replace it with a dummy prog without shrinking the table. The subsequent call to __cgroup_bpf_detach() or __cgroup_bpf_detach() will correct it. Fixes: af6eea57437a ("bpf: Implement bpf_link-based cgroup BPF program attachment") Reported-by: <syzbot+f264bffdfbd5614f3bb2(a)syzkaller.appspotmail.com> Signed-off-by: Tadeusz Struk <tadeusz.struk(a)linaro.org> Signed-off-by: Andrii Nakryiko <andrii(a)kernel.org> Cc: <stable(a)vger.kernel.org> Link: https://syzkaller.appspot.com/bug?id=8ebf179a95c2a2670f7cf1ba62429ec044369d… Link: https://lore.kernel.org/bpf/20220517180420.87954-1-tadeusz.struk@linaro.org Signed-off-by: Pu Lehui <pulehui(a)huawei.com> --- kernel/bpf/cgroup.c | 70 ++++++++++++++++++++++++++++++++++++++------- 1 file changed, 60 insertions(+), 10 deletions(-) diff --git a/kernel/bpf/cgroup.c b/kernel/bpf/cgroup.c index 6aa9e10c6335..d154e52dd7ae 100644 --- a/kernel/bpf/cgroup.c +++ b/kernel/bpf/cgroup.c @@ -653,6 +653,60 @@ static struct bpf_prog_list *find_detach_entry(struct list_head *progs, return ERR_PTR(-ENOENT); } +/** + * purge_effective_progs() - After compute_effective_progs fails to alloc new + * cgrp->bpf.inactive table we can recover by + * recomputing the array in place. + * + * @cgrp: The cgroup which descendants to travers + * @prog: A program to detach or NULL + * @link: A link to detach or NULL + * @type: Type of detach operation + */ +static void purge_effective_progs(struct cgroup *cgrp, struct bpf_prog *prog, + struct bpf_cgroup_link *link, + enum bpf_attach_type type) +{ + struct cgroup_subsys_state *css; + struct bpf_prog_array *progs; + struct bpf_prog_list *pl; + struct list_head *head; + struct cgroup *cg; + int pos; + + /* recompute effective prog array in place */ + css_for_each_descendant_pre(css, &cgrp->self) { + struct cgroup *desc = container_of(css, struct cgroup, self); + + if (percpu_ref_is_zero(&desc->bpf.refcnt)) + continue; + + /* find position of link or prog in effective progs array */ + for (pos = 0, cg = desc; cg; cg = cgroup_parent(cg)) { + if (pos && !(cg->bpf.flags[type] & BPF_F_ALLOW_MULTI)) + continue; + + head = &cg->bpf.progs[type]; + list_for_each_entry(pl, head, node) { + if (!prog_list_prog(pl)) + continue; + if (pl->prog == prog && pl->link == link) + goto found; + pos++; + } + } +found: + BUG_ON(!cg); + progs = rcu_dereference_protected( + desc->bpf.effective[type], + lockdep_is_held(&cgroup_mutex)); + + /* Remove the program from the array */ + WARN_ONCE(bpf_prog_array_delete_safe_at(progs, pos), + "Failed to purge a prog from array at index %d", pos); + } +} + /** * __cgroup_bpf_detach() - Detach the program or link from a cgroup, and * propagate the change to descendants @@ -671,7 +725,6 @@ int __cgroup_bpf_detach(struct cgroup *cgrp, struct bpf_prog *prog, u32 flags = cgrp->bpf.flags[type]; struct bpf_prog_list *pl; struct bpf_prog *old_prog; - int err; if (prog && link) /* only one of prog or link can be specified */ @@ -686,9 +739,12 @@ int __cgroup_bpf_detach(struct cgroup *cgrp, struct bpf_prog *prog, pl->prog = NULL; pl->link = NULL; - err = update_effective_progs(cgrp, type); - if (err) - goto cleanup; + if (update_effective_progs(cgrp, type)) { + /* if update effective array failed replace the prog with a dummy prog*/ + pl->prog = old_prog; + pl->link = link; + purge_effective_progs(cgrp, old_prog, link, type); + } /* now can actually delete it from this cgroup list */ list_del(&pl->node); @@ -700,12 +756,6 @@ int __cgroup_bpf_detach(struct cgroup *cgrp, struct bpf_prog *prog, bpf_prog_put(old_prog); static_branch_dec(&cgroup_bpf_enabled_key); return 0; - -cleanup: - /* restore back prog or link */ - pl->prog = old_prog; - pl->link = link; - return err; } /* Must be called with cgroup_mutex held to avoid races. */ -- 2.25.1

2 years, 5 months

2
1
0 0

[PATCH STABLE 4.14 0/2] btrfs: raid56: backporst to reduce corruption

by Qu Wenruo

This is the backport for v4.19.x stable branch. The full explananation can be found here: https://lore.kernel.org/linux-btrfs/cover.1660891713.git.wqu@suse.com/ No code change between v4.14.x and v4.19.x, at least nothing git can not auto-resolve. Testing wise, this is beyond my testing environment. Although latest GCC compiles without problem, the result kernel can not be properly boot at all, not even any kernel early boot message. I'm not sure if this is something related to latest edk2 UEFI or something else, I can no longer do proper testing for any older branch, including this 4.19 one. Thus I can not do any guarantee on these backports, unfortunately the backports can only go to v5.x branches for now. Unless anyone has better ideas how to build and run older kernels with latest edk2 UEFI environment. Qu Wenruo (2): btrfs: only write the sectors in the vertical stripe which has data stripes btrfs: raid56: don't trust any cached sector in __raid56_parity_recover() fs/btrfs/raid56.c | 74 ++++++++++++++++++++++++++++++++++++----------- 1 file changed, 57 insertions(+), 17 deletions(-) -- 2.37.1

2 years, 5 months

2
3
0 0

[PATCH 5.10 0/1] qrtr: Convert qrtr_ports from IDR to XArray

by Stanislav Goriainov

Syzkaller reports using smp_processor_id() in preemptible code at radix_tree_node_alloc() in 5.10 stable releases. The problem has been fixed by the following patch which can be cleanly applied to the 5.10 branch. Found by Linux Verification Center (linuxtesting.org) with Syzkaller.

2 years, 5 months

2
2
0 0

[PATCH 5.15 0/9] xfs stable candidate patches for 5.15.y (part 4)

by Leah Rumancik

Hello, Here's another round of xfs backports for 5.15.y that have been through testing and ACK'd. Thanks, Leah Brian Foster (2): xfs: flush inodegc workqueue tasks before cancel xfs: fix soft lockup via spinning in filestream ag selection loop Darrick J. Wong (6): xfs: reserve quota for dir expansion when linking/unlinking files xfs: reserve quota for target dir expansion when renaming files xfs: remove infinite loop when reserving free block pool xfs: always succeed at setting the reserve pool size xfs: fix overfilling of reserve pool xfs: reject crazy array sizes being fed to XFS_IOC_GETBMAP* Eric Sandeen (1): xfs: revert "xfs: actually bump warning counts when we send warnings" fs/xfs/xfs_filestream.c | 7 ++-- fs/xfs/xfs_fsops.c | 50 ++++++++++------------- fs/xfs/xfs_icache.c | 22 ++-------- fs/xfs/xfs_inode.c | 79 ++++++++++++++++++++++-------------- fs/xfs/xfs_ioctl.c | 2 +- fs/xfs/xfs_trans.c | 86 ++++++++++++++++++++++++++++++++++++++++ fs/xfs/xfs_trans.h | 3 ++ fs/xfs/xfs_trans_dquot.c | 1 - 8 files changed, 167 insertions(+), 83 deletions(-) -- 2.37.1.595.g718a3a8f04-goog

2 years, 5 months

2
10
0 0

FAILED: patch "[PATCH] tracing/probes: Have kprobes and uprobes use $COMM too" failed to apply to 4.19-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 4.19-stable tree. If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to <stable(a)vger.kernel.org>. thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From ab8384442ee512fc0fc72deeb036110843d0e7ff Mon Sep 17 00:00:00 2001 From: "Steven Rostedt (Google)" <rostedt(a)goodmis.org> Date: Sat, 20 Aug 2022 09:43:21 -0400 Subject: [PATCH] tracing/probes: Have kprobes and uprobes use $COMM too Both $comm and $COMM can be used to get current->comm in eprobes and the filtering and histogram logic. Make kprobes and uprobes consistent in this regard and allow both $comm and $COMM as well. Currently kprobes and uprobes only handle $comm, which is inconsistent with the other utilities, and can be confusing to users. Link: https://lkml.kernel.org/r/20220820134401.317014913@goodmis.org Link: https://lore.kernel.org/all/20220820220442.776e1ddaf8836e82edb34d01@kernel.… Cc: stable(a)vger.kernel.org Cc: Ingo Molnar <mingo(a)kernel.org> Cc: Andrew Morton <akpm(a)linux-foundation.org> Cc: Tzvetomir Stoyanov <tz.stoyanov(a)gmail.com> Cc: Tom Zanussi <zanussi(a)kernel.org> Fixes: 533059281ee5 ("tracing: probeevent: Introduce new argument fetching code") Suggested-by: Masami Hiramatsu (Google) <mhiramat(a)kernel.org> Acked-by: Masami Hiramatsu (Google) <mhiramat(a)kernel.org> Signed-off-by: Steven Rostedt (Google) <rostedt(a)goodmis.org> diff --git a/kernel/trace/trace_probe.c b/kernel/trace/trace_probe.c index 4daabbb8b772..36dff277de46 100644 --- a/kernel/trace/trace_probe.c +++ b/kernel/trace/trace_probe.c @@ -314,7 +314,7 @@ static int parse_probe_vars(char *arg, const struct fetch_type *t, } } else goto inval_var; - } else if (strcmp(arg, "comm") == 0) { + } else if (strcmp(arg, "comm") == 0 || strcmp(arg, "COMM") == 0) { code->op = FETCH_OP_COMM; #ifdef CONFIG_HAVE_FUNCTION_ARG_ACCESS_API } else if (((flags & TPARG_FL_MASK) == @@ -625,7 +625,8 @@ static int traceprobe_parse_probe_arg_body(const char *argv, ssize_t *size, * we can find those by strcmp. But ignore for eprobes. */ if (!(flags & TPARG_FL_TPOINT) && - (strcmp(arg, "$comm") == 0 || strncmp(arg, "\\\"", 2) == 0)) { + (strcmp(arg, "$comm") == 0 || strcmp(arg, "$COMM") == 0 || + strncmp(arg, "\\\"", 2) == 0)) { /* The type of $comm must be "string", and not an array. */ if (parg->count || (t && strcmp(t, "string"))) goto out;

2 years, 5 months

3
2
0 0

FAILED: patch "[PATCH] tracing/eprobes: Fix reading of string fields" failed to apply to 5.15-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 5.15-stable tree. If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to <stable(a)vger.kernel.org>. thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From f04dec93466a0481763f3b56cdadf8076e28bfbf Mon Sep 17 00:00:00 2001 From: "Steven Rostedt (Google)" <rostedt(a)goodmis.org> Date: Sat, 20 Aug 2022 09:43:19 -0400 Subject: [PATCH] tracing/eprobes: Fix reading of string fields Currently when an event probe (eprobe) hooks to a string field, it does not display it as a string, but instead as a number. This makes the field rather useless. Handle the different kinds of strings, dynamic, static, relational/dynamic etc. Now when a string field is used, the ":string" type can be used to display it: echo "e:sw sched/sched_switch comm=$next_comm:string" > dynamic_events Link: https://lkml.kernel.org/r/20220820134400.959640191@goodmis.org Cc: stable(a)vger.kernel.org Cc: Ingo Molnar <mingo(a)kernel.org> Cc: Andrew Morton <akpm(a)linux-foundation.org> Cc: Tzvetomir Stoyanov <tz.stoyanov(a)gmail.com> Cc: Tom Zanussi <zanussi(a)kernel.org> Fixes: 7491e2c44278 ("tracing: Add a probe that attaches to trace events") Acked-by: Masami Hiramatsu (Google) <mhiramat(a)kernel.org> Signed-off-by: Steven Rostedt (Google) <rostedt(a)goodmis.org> diff --git a/kernel/trace/trace_eprobe.c b/kernel/trace/trace_eprobe.c index 550671985fd1..a1d3423ab74f 100644 --- a/kernel/trace/trace_eprobe.c +++ b/kernel/trace/trace_eprobe.c @@ -311,6 +311,27 @@ static unsigned long get_event_field(struct fetch_insn *code, void *rec) addr = rec + field->offset; + if (is_string_field(field)) { + switch (field->filter_type) { + case FILTER_DYN_STRING: + val = (unsigned long)(rec + (*(unsigned int *)addr & 0xffff)); + break; + case FILTER_RDYN_STRING: + val = (unsigned long)(addr + (*(unsigned int *)addr & 0xffff)); + break; + case FILTER_STATIC_STRING: + val = (unsigned long)addr; + break; + case FILTER_PTR_STRING: + val = (unsigned long)(*(char *)addr); + break; + default: + WARN_ON_ONCE(1); + return 0; + } + return val; + } + switch (field->size) { case 1: if (field->is_signed)

2 years, 5 months

3
2
0 0

[PATCH v3] mm/damon/dbgfs: avoid duplicate context directory creation

by SeongJae Park

From: Badari Pulavarty <badari.pulavarty(a)intel.com> From: Badari Pulavarty <badari.pulavarty(a)intel.com> When user tries to create a DAMON context via the DAMON debugfs interface with a name of an already existing context, the context directory creation fails but a new context is created and added in the internal data structure, due to absence of the directory creation success check. As a result, memory could leak and DAMON cannot be turned on. An example test case is as below: # cd /sys/kernel/debug/damon/ # echo "off" > monitor_on # echo paddr > target_ids # echo "abc" > mk_context # echo "abc" > mk_context # echo $$ > abc/target_ids # echo "on" > monitor_on <<< fails Return value of 'debugfs_create_dir()' is expected to be ignored in general, but this is an exceptional case as DAMON feature is depending on the debugfs functionality and it has the potential duplicate name issue. This commit therefore fixes the issue by checking the directory creation failure and immediately return the error in the case. Fixes: 75c1c2b53c78 ("mm/damon/dbgfs: support multiple contexts") Cc: <stable(a)vger.kernel.org> # 5.15.x Signed-off-by: Badari Pulavarty <badari.pulavarty(a)intel.com> Signed-off-by: SeongJae Park <sj(a)kernel.org> --- Changes from v2 (https://lore.kernel.org/damon/20220819171930.16166-1-sj@kernel.org/) - Simply check the debugfs_create_dir() return value (Andrew Morton) - Put a comment for justifying check of the return value (Greg KH) Changes from v1 (https://lore.kernel.org/damon/DM6PR11MB3978994F75A4104D714437379C679@DM6PR1…) - Manually check duplicate entry instead of checking 'debugfs_create_dir()' return value - Reword commit message and the test case Seems Badari have some email client issue, so I (SJ) am making this third version of the patch based on Badari's final proposal and reposting on behalf of Badari. mm/damon/dbgfs.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/mm/damon/dbgfs.c b/mm/damon/dbgfs.c index 51d67c8050dd..3b55a1b219b5 100644 --- a/mm/damon/dbgfs.c +++ b/mm/damon/dbgfs.c @@ -818,6 +818,9 @@ static int dbgfs_mk_context(char *name) return -ENOENT; new_dir = debugfs_create_dir(name, root); + /* Below check is required for a potential duplicated name case */ + if (IS_ERR(new_dir)) + return PTR_ERR(new_dir); dbgfs_dirs[dbgfs_nr_ctxs] = new_dir; new_ctx = dbgfs_new_ctx(); -- 2.25.1

2 years, 5 months

2
3
0 0

[PATCH 1/1] iommu/vt-d: Correctly calculate sagaw value of IOMMU

by Lu Baolu

The Intel IOMMU driver possibly selects between the first-level and the second-level translation tables for DMA address translation. However, the levels of page-table walks for the 4KB base page size are calculated from the SAGAW field of the capability register, which is only valid for the second-level page table. This causes the IOMMU driver to stop working if the hardware (or the emulated IOMMU) advertises only first-level translation capability and reports the SAGAW field as 0. This solves the above problem by considering both the first level and the second level when calculating the supported page table levels. Fixes: b802d070a52a1 ("iommu/vt-d: Use iova over first level") Cc: stable(a)vger.kernel.org Signed-off-by: Lu Baolu <baolu.lu(a)linux.intel.com> --- drivers/iommu/intel/iommu.c | 28 +++++++++++++++++++++++++--- 1 file changed, 25 insertions(+), 3 deletions(-) diff --git a/drivers/iommu/intel/iommu.c b/drivers/iommu/intel/iommu.c index 889ad2c9a7b9..2d0d2ef820d2 100644 --- a/drivers/iommu/intel/iommu.c +++ b/drivers/iommu/intel/iommu.c @@ -370,14 +370,36 @@ static inline int domain_pfn_supported(struct dmar_domain *domain, return !(addr_width < BITS_PER_LONG && pfn >> addr_width); } +/* + * Calculate the Supported Adjusted Guest Address Widths of an IOMMU. + * Refer to 11.4.2 of the VT-d spec for the encoding of each bit of + * the returned SAGAW. + */ +static unsigned long __iommu_calculate_sagaw(struct intel_iommu *iommu) +{ + unsigned long fl_sagaw, sl_sagaw; + + fl_sagaw = 0x6 | (cap_fl1gp_support(iommu->cap) ? BIT(3) : 0); + sl_sagaw = cap_sagaw(iommu->cap); + + /* Second level only. */ + if (!sm_supported(iommu) || !ecap_flts(iommu->ecap)) + return sl_sagaw; + + /* First level only. */ + if (!ecap_slts(iommu->ecap)) + return fl_sagaw; + + return fl_sagaw & sl_sagaw; +} + static int __iommu_calculate_agaw(struct intel_iommu *iommu, int max_gaw) { unsigned long sagaw; int agaw; - sagaw = cap_sagaw(iommu->cap); - for (agaw = width_to_agaw(max_gaw); - agaw >= 0; agaw--) { + sagaw = __iommu_calculate_sagaw(iommu); + for (agaw = width_to_agaw(max_gaw); agaw >= 0; agaw--) { if (test_bit(agaw, &sagaw)) break; } -- 2.25.1

2 years, 5 months

2
1
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror August 2022