- Linux-stable-mirror - lists.linaro.org

FAILED: patch "[PATCH] cacheinfo: Check cache properties are present in DT" failed to apply to 6.1-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 6.1-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>. To reproduce the conflict and resubmit, you may use the following commands: git fetch https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/ linux-6.1.y git checkout FETCH_HEAD git cherry-pick -x cde0fbff07eff7e4e0e85fa053fe19a24c86b1e0 # <resolve conflicts, build, test, etc.> git commit -s git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '2025101328-ferry-wrought-6a64@gregkh' --subject-prefix 'PATCH 6.1.y' HEAD^.. Possible dependencies: thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From cde0fbff07eff7e4e0e85fa053fe19a24c86b1e0 Mon Sep 17 00:00:00 2001 From: Pierre Gondois <pierre.gondois(a)arm.com> Date: Fri, 14 Apr 2023 10:14:50 +0200 Subject: [PATCH] cacheinfo: Check cache properties are present in DT If a Device Tree (DT) is used, the presence of cache properties is assumed. Not finding any is not considered. For arm64 platforms, cache information can be fetched from the clidr_el1 register. Checking whether cache information is available in the DT allows to switch to using clidr_el1. init_of_cache_level() \-of_count_cache_leaves() will assume there a 2 cache leaves (L1 data/instruction caches), which can be different from clidr_el1 information. cache_setup_of_node() tries to read cache properties in the DT. If there are none, this is considered a success. Knowing no information was available would allow to switch to using clidr_el1. Fixes: de0df442ee49 ("cacheinfo: Check 'cache-unified' property to count cache leaves") Reported-by: Alexandre Ghiti <alexghiti(a)rivosinc.com> Link: https://lore.kernel.org/all/20230404-hatred-swimmer-6fecdf33b57a@spud/ Signed-off-by: Pierre Gondois <pierre.gondois(a)arm.com> Reviewed-by: Conor Dooley <conor.dooley(a)microchip.com> Link: https://lore.kernel.org/r/20230414081453.244787-3-pierre.gondois@arm.com Signed-off-by: Sudeep Holla <sudeep.holla(a)arm.com> diff --git a/drivers/base/cacheinfo.c b/drivers/base/cacheinfo.c index ba14c7872e4a..f16e5a82f0f3 100644 --- a/drivers/base/cacheinfo.c +++ b/drivers/base/cacheinfo.c @@ -78,6 +78,9 @@ bool last_level_cache_is_shared(unsigned int cpu_x, unsigned int cpu_y) } #ifdef CONFIG_OF + +static bool of_check_cache_nodes(struct device_node *np); + /* OF properties to query for a given cache type */ struct cache_type_info { const char *size_prop; @@ -205,6 +208,11 @@ static int cache_setup_of_node(unsigned int cpu) return -ENOENT; } + if (!of_check_cache_nodes(np)) { + of_node_put(np); + return -ENOENT; + } + prev = np; while (index < cache_leaves(cpu)) { @@ -229,6 +237,25 @@ static int cache_setup_of_node(unsigned int cpu) return 0; } +static bool of_check_cache_nodes(struct device_node *np) +{ + struct device_node *next; + + if (of_property_present(np, "cache-size") || + of_property_present(np, "i-cache-size") || + of_property_present(np, "d-cache-size") || + of_property_present(np, "cache-unified")) + return true; + + next = of_find_next_cache_node(np); + if (next) { + of_node_put(next); + return true; + } + + return false; +} + static int of_count_cache_leaves(struct device_node *np) { unsigned int leaves = 0; @@ -260,6 +287,11 @@ int init_of_cache_level(unsigned int cpu) struct device_node *prev = NULL; unsigned int levels = 0, leaves, level; + if (!of_check_cache_nodes(np)) { + of_node_put(np); + return -ENOENT; + } + leaves = of_count_cache_leaves(np); if (leaves > 0) levels = 1;

2 months, 1 week

1
0
0 0

Re: Patch "hugetlbfs: skip VMAs without shareable locks in hugetlb_vmdelete_list" has been added to the 6.17-stable tree

by Deepanshu Kartikey

Hi Sasha, Please do NOT backport commit dd83609b8898 alone to stable. This patch causes a regression in fallocate(PUNCH_HOLE) operations where pages are not freed immediately, as reported by Mark Brown. The fix for this regression is already in linux-next as commit 91a830422707 ("hugetlbfs: check for shareable lock before calling huge_pmd_unshare()"). Please backport both commits together to avoid introducing the regression in stable kernels: - dd83609b88986f4add37c0871c3434310652ebd5 ("hugetlbfs: skip VMAs without shareable locks in hugetlb_vmdelete_list") - 91a830422707a62629fc4fbf8cdc3c8acf56ca64 ("hugetlbfs: check for shareable lock before calling huge_pmd_unshare()") Thanks, Deepanshu Kartikey

2 months, 1 week

2
1
0 0

Re: Patch "gpio: TODO: remove the task for converting to the new line setters" has been added to the 6.17-stable tree

by Bartosz Golaszewski

On Sun, Oct 12, 2025 at 3:57 PM Sasha Levin <sashal(a)kernel.org> wrote: > > This is a note to let you know that I've just added the patch titled > > gpio: TODO: remove the task for converting to the new line setters > > to the 6.17-stable tree which can be found at: > http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… > > The filename of the patch is: > gpio-todo-remove-the-task-for-converting-to-the-new-.patch > and it can be found in the queue-6.17 subdirectory. > > If you, or anyone else, feels it should not be added to the stable tree, > please let <stable(a)vger.kernel.org> know about it. > As per commit message: this is neither a fix nor even a new feature, this is just a change in the TODO file. Please drop it, this has no place in stable branches. Bart

2 months, 1 week

2
1
0 0

Re: Patch "PCI: Preserve bridge window resource type flags" has been added to the 6.17-stable tree

by Ilpo Järvinen

On Sun, 12 Oct 2025, Sasha Levin wrote: > This is a note to let you know that I've just added the patch titled > > PCI: Preserve bridge window resource type flags > > to the 6.17-stable tree which can be found at: > http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… > > The filename of the patch is: > pci-preserve-bridge-window-resource-type-flags.patch > and it can be found in the queue-6.17 subdirectory. > > If you, or anyone else, feels it should not be added to the stable tree, > please let <stable(a)vger.kernel.org> know about it. Hi Sasha and other stable maintainers, While I agree the assessment that this is stable material, could we postpone queueing to stable a bit more? This change has relatively high regression potential and high impact for individual system that regresses, and is complicated change no matter what already given the diffstat alone. So try e.g. after 6.18 is released would seem more prudent for me as it would give more time to iron out problems in the rc-phase before any stable sees this change. I'm also very worried this change is queued without the commit 1cdffa51ecc4 ("PCI: Enable bridge even if bridge window fails to assign"), that's pretty much straight into territory I've personally charted to contain ways to break things which is why I added 1cdffa51ecc4. There are also the supporting arch cleanups to the same functionality as 1cdffa51ecc4 (done through weak magic) that are related to 1cdffa51ecc4. -- i. > commit b871817e3ba3e462dbc10491a2786cd3fb9dc064 > Author: Ilpo Järvinen <ilpo.jarvinen(a)linux.intel.com> > Date: Fri Aug 29 16:10:59 2025 +0300 > > PCI: Preserve bridge window resource type flags > > [ Upstream commit 8278c6914306f35f32d73bdf2a918950919a0051 ] > > When a bridge window is found unused or fails to assign, the flags of the > associated resource are cleared. Clearing flags is problematic as it also > removes the type information of the resource which is needed later. > > Thus, always preserve the bridge window type flags and use IORESOURCE_UNSET > and IORESOURCE_DISABLED to indicate the status of the bridge window. Also, > when initializing resources, make sure all valid bridge windows do get > their type flags set. > > Change various places that relied on resource flags being cleared to check > for IORESOURCE_UNSET and IORESOURCE_DISABLED to allow bridge window > resource to retain their type flags. Add pdev_resource_assignable() and > pdev_resource_should_fit() helpers to filter out disabled bridge windows > during resource fitting; the latter combines more common checks into the > helper. > > When reading the bridge windows from the registers, instead of leaving the > resource flags cleared for bridge windows that are not enabled, always > set up the flags and set IORESOURCE_UNSET | IORESOURCE_DISABLED as needed. > > When resource fitting or assignment fails for a bridge window resource, or > the bridge window is not needed, mark the resource with IORESOURCE_UNSET or > IORESOURCE_DISABLED, respectively. > > Use dummy zero resource in resource_show() for backwards compatibility as > lspci will otherwise misrepresent disabled bridge windows. > > This change fixes an issue which highlights the importance of keeping the > resource type flags intact: > > At the end of __assign_resources_sorted(), reset_resource() is called, > previously clearing the flags. Later, pci_prepare_next_assign_round() > attempted to release bridge resources using > pci_bus_release_bridge_resources() that calls into > pci_bridge_release_resources() that assumes type flags are still present. > As type flags were cleared, IORESOURCE_MEM_64 was not set leading to > resources under an incorrect bridge window to be released (idx = 1 > instead of idx = 2). While the assignments performed later covered this > problem so that the wrongly released resources got assigned in the end, > it was still causing extra release+assign pairs. > > There are other reasons why the resource flags should be retained in > upcoming changes too. > > Removing the flag reset for non-bridge window resource is left as future > work, in part because it has a much higher regression potential due to > pci_enable_resources() that will start to work also for those resources > then and due to what endpoint drivers might assume about resources. > > Despite the Fixes tag, backporting this (at least any time soon) is highly > discouraged. The issue fixed is borderline cosmetic as the later > assignments normally cover the problem entirely. Also there might be > non-obvious dependencies. > > Fixes: 5b28541552ef ("PCI: Restrict 64-bit prefetchable bridge windows to 64-bit resources") > Signed-off-by: Ilpo Järvinen <ilpo.jarvinen(a)linux.intel.com> > Signed-off-by: Bjorn Helgaas <bhelgaas(a)google.com> > Link: https://patch.msgid.link/20250829131113.36754-11-ilpo.jarvinen@linux.intel.… > Signed-off-by: Sasha Levin <sashal(a)kernel.org> > > diff --git a/drivers/pci/bus.c b/drivers/pci/bus.c > index b77fd30bbfd9d..58b5388423ee3 100644 > --- a/drivers/pci/bus.c > +++ b/drivers/pci/bus.c > @@ -204,6 +204,9 @@ static int pci_bus_alloc_from_region(struct pci_bus *bus, struct resource *res, > if (!r) > continue; > > + if (r->flags & (IORESOURCE_UNSET|IORESOURCE_DISABLED)) > + continue; > + > /* type_mask must match */ > if ((res->flags ^ r->flags) & type_mask) > continue; > diff --git a/drivers/pci/pci-sysfs.c b/drivers/pci/pci-sysfs.c > index 5eea14c1f7f5f..162a5241c7f70 100644 > --- a/drivers/pci/pci-sysfs.c > +++ b/drivers/pci/pci-sysfs.c > @@ -177,6 +177,13 @@ static ssize_t resource_show(struct device *dev, struct device_attribute *attr, > > for (i = 0; i < max; i++) { > struct resource *res = &pci_dev->resource[i]; > + struct resource zerores = {}; > + > + /* For backwards compatibility */ > + if (i >= PCI_BRIDGE_RESOURCES && i <= PCI_BRIDGE_RESOURCE_END && > + res->flags & (IORESOURCE_UNSET | IORESOURCE_DISABLED)) > + res = &zerores; > + > pci_resource_to_user(pci_dev, i, res, &start, &end); > len += sysfs_emit_at(buf, len, "0x%016llx 0x%016llx 0x%016llx\n", > (unsigned long long)start, > diff --git a/drivers/pci/probe.c b/drivers/pci/probe.c > index f41128f91ca76..f31d27c7708a6 100644 > --- a/drivers/pci/probe.c > +++ b/drivers/pci/probe.c > @@ -419,13 +419,17 @@ static void pci_read_bridge_io(struct pci_dev *dev, struct resource *res, > limit |= ((unsigned long) io_limit_hi << 16); > } > > + res->flags = (io_base_lo & PCI_IO_RANGE_TYPE_MASK) | IORESOURCE_IO; > + > if (base <= limit) { > - res->flags = (io_base_lo & PCI_IO_RANGE_TYPE_MASK) | IORESOURCE_IO; > region.start = base; > region.end = limit + io_granularity - 1; > pcibios_bus_to_resource(dev->bus, res, &region); > if (log) > pci_info(dev, " bridge window %pR\n", res); > + } else { > + resource_set_range(res, 0, 0); > + res->flags |= IORESOURCE_UNSET | IORESOURCE_DISABLED; > } > } > > @@ -440,13 +444,18 @@ static void pci_read_bridge_mmio(struct pci_dev *dev, struct resource *res, > pci_read_config_word(dev, PCI_MEMORY_LIMIT, &mem_limit_lo); > base = ((unsigned long) mem_base_lo & PCI_MEMORY_RANGE_MASK) << 16; > limit = ((unsigned long) mem_limit_lo & PCI_MEMORY_RANGE_MASK) << 16; > + > + res->flags = (mem_base_lo & PCI_MEMORY_RANGE_TYPE_MASK) | IORESOURCE_MEM; > + > if (base <= limit) { > - res->flags = (mem_base_lo & PCI_MEMORY_RANGE_TYPE_MASK) | IORESOURCE_MEM; > region.start = base; > region.end = limit + 0xfffff; > pcibios_bus_to_resource(dev->bus, res, &region); > if (log) > pci_info(dev, " bridge window %pR\n", res); > + } else { > + resource_set_range(res, 0, 0); > + res->flags |= IORESOURCE_UNSET | IORESOURCE_DISABLED; > } > } > > @@ -489,16 +498,20 @@ static void pci_read_bridge_mmio_pref(struct pci_dev *dev, struct resource *res, > return; > } > > + res->flags = (mem_base_lo & PCI_PREF_RANGE_TYPE_MASK) | IORESOURCE_MEM | > + IORESOURCE_PREFETCH; > + if (res->flags & PCI_PREF_RANGE_TYPE_64) > + res->flags |= IORESOURCE_MEM_64; > + > if (base <= limit) { > - res->flags = (mem_base_lo & PCI_PREF_RANGE_TYPE_MASK) | > - IORESOURCE_MEM | IORESOURCE_PREFETCH; > - if (res->flags & PCI_PREF_RANGE_TYPE_64) > - res->flags |= IORESOURCE_MEM_64; > region.start = base; > region.end = limit + 0xfffff; > pcibios_bus_to_resource(dev->bus, res, &region); > if (log) > pci_info(dev, " bridge window %pR\n", res); > + } else { > + resource_set_range(res, 0, 0); > + res->flags |= IORESOURCE_UNSET | IORESOURCE_DISABLED; > } > } > > diff --git a/drivers/pci/setup-bus.c b/drivers/pci/setup-bus.c > index 203c8ebef7029..8078ee30e675f 100644 > --- a/drivers/pci/setup-bus.c > +++ b/drivers/pci/setup-bus.c > @@ -154,6 +154,31 @@ static bool pdev_resources_assignable(struct pci_dev *dev) > return true; > } > > +static bool pdev_resource_assignable(struct pci_dev *dev, struct resource *res) > +{ > + int idx = pci_resource_num(dev, res); > + > + if (!res->flags) > + return false; > + > + if (idx >= PCI_BRIDGE_RESOURCES && idx <= PCI_BRIDGE_RESOURCE_END && > + res->flags & IORESOURCE_DISABLED) > + return false; > + > + return true; > +} > + > +static bool pdev_resource_should_fit(struct pci_dev *dev, struct resource *res) > +{ > + if (res->parent) > + return false; > + > + if (res->flags & IORESOURCE_PCI_FIXED) > + return false; > + > + return pdev_resource_assignable(dev, res); > +} > + > /* Sort resources by alignment */ > static void pdev_sort_resources(struct pci_dev *dev, struct list_head *head) > { > @@ -169,10 +194,7 @@ static void pdev_sort_resources(struct pci_dev *dev, struct list_head *head) > resource_size_t r_align; > struct list_head *n; > > - if (r->flags & IORESOURCE_PCI_FIXED) > - continue; > - > - if (!(r->flags) || r->parent) > + if (!pdev_resource_should_fit(dev, r)) > continue; > > r_align = pci_resource_alignment(dev, r); > @@ -221,8 +243,15 @@ bool pci_resource_is_optional(const struct pci_dev *dev, int resno) > return false; > } > > -static inline void reset_resource(struct resource *res) > +static inline void reset_resource(struct pci_dev *dev, struct resource *res) > { > + int idx = pci_resource_num(dev, res); > + > + if (idx >= PCI_BRIDGE_RESOURCES && idx <= PCI_BRIDGE_RESOURCE_END) { > + res->flags |= IORESOURCE_UNSET; > + return; > + } > + > res->start = 0; > res->end = 0; > res->flags = 0; > @@ -568,7 +597,7 @@ static void __assign_resources_sorted(struct list_head *head, > 0 /* don't care */); > } > > - reset_resource(res); > + reset_resource(dev, res); > } > > free_list(head); > @@ -997,8 +1026,11 @@ static void pbus_size_io(struct pci_bus *bus, resource_size_t min_size, > > if (r->parent || !(r->flags & IORESOURCE_IO)) > continue; > - r_size = resource_size(r); > > + if (!pdev_resource_assignable(dev, r)) > + continue; > + > + r_size = resource_size(r); > if (r_size < SZ_1K) > /* Might be re-aligned for ISA */ > size += r_size; > @@ -1017,6 +1049,9 @@ static void pbus_size_io(struct pci_bus *bus, resource_size_t min_size, > size0 = calculate_iosize(size, min_size, size1, 0, 0, > resource_size(b_res), min_align); > > + if (size0) > + b_res->flags &= ~IORESOURCE_DISABLED; > + > size1 = size0; > if (realloc_head && (add_size > 0 || children_add_size > 0)) { > size1 = calculate_iosize(size, min_size, size1, add_size, > @@ -1028,13 +1063,14 @@ static void pbus_size_io(struct pci_bus *bus, resource_size_t min_size, > if (bus->self && (b_res->start || b_res->end)) > pci_info(bus->self, "disabling bridge window %pR to %pR (unused)\n", > b_res, &bus->busn_res); > - b_res->flags = 0; > + b_res->flags |= IORESOURCE_DISABLED; > return; > } > > resource_set_range(b_res, min_align, size0); > b_res->flags |= IORESOURCE_STARTALIGN; > if (bus->self && size1 > size0 && realloc_head) { > + b_res->flags &= ~IORESOURCE_DISABLED; > add_to_list(realloc_head, bus->self, b_res, size1-size0, > min_align); > pci_info(bus->self, "bridge window %pR to %pR add_size %llx\n", > @@ -1180,11 +1216,13 @@ static int pbus_size_mem(struct pci_bus *bus, unsigned long mask, > const char *r_name = pci_resource_name(dev, i); > resource_size_t r_size; > > - if (r->parent || (r->flags & IORESOURCE_PCI_FIXED) || > - !pdev_resources_assignable(dev) || > - ((r->flags & mask) != type && > - (r->flags & mask) != type2 && > - (r->flags & mask) != type3)) > + if (!pdev_resources_assignable(dev) || > + !pdev_resource_should_fit(dev, r)) > + continue; > + > + if ((r->flags & mask) != type && > + (r->flags & mask) != type2 && > + (r->flags & mask) != type3) > continue; > r_size = resource_size(r); > > @@ -1235,6 +1273,9 @@ static int pbus_size_mem(struct pci_bus *bus, unsigned long mask, > min_align = max(min_align, win_align); > size0 = calculate_memsize(size, min_size, 0, 0, resource_size(b_res), min_align); > > + if (size0) > + b_res->flags &= ~IORESOURCE_DISABLED; > + > if (bus->self && size0 && > !pbus_upstream_space_available(bus, mask | IORESOURCE_PREFETCH, type, > size0, min_align)) { > @@ -1267,13 +1308,14 @@ static int pbus_size_mem(struct pci_bus *bus, unsigned long mask, > if (bus->self && (b_res->start || b_res->end)) > pci_info(bus->self, "disabling bridge window %pR to %pR (unused)\n", > b_res, &bus->busn_res); > - b_res->flags = 0; > + b_res->flags |= IORESOURCE_DISABLED; > return 0; > } > > resource_set_range(b_res, min_align, size0); > b_res->flags |= IORESOURCE_STARTALIGN; > if (bus->self && size1 > size0 && realloc_head) { > + b_res->flags &= ~IORESOURCE_DISABLED; > add_to_list(realloc_head, bus->self, b_res, size1-size0, add_align); > pci_info(bus->self, "bridge window %pR to %pR add_size %llx add_align %llx\n", > b_res, &bus->busn_res, > @@ -1705,7 +1747,6 @@ static void pci_bridge_release_resources(struct pci_bus *bus, > { > struct pci_dev *dev = bus->self; > struct resource *r; > - unsigned int old_flags; > struct resource *b_res; > int idx, ret; > > @@ -1742,17 +1783,15 @@ static void pci_bridge_release_resources(struct pci_bus *bus, > /* If there are children, release them all */ > release_child_resources(r); > > - type = old_flags = r->flags & PCI_RES_TYPE_MASK; > ret = pci_release_resource(dev, PCI_BRIDGE_RESOURCES + idx); > if (ret) > return; > > + type = r->flags & PCI_RES_TYPE_MASK; > /* Avoiding touch the one without PREF */ > if (type & IORESOURCE_PREFETCH) > type = IORESOURCE_PREFETCH; > __pci_setup_bridge(bus, type); > - /* For next child res under same bridge */ > - r->flags = old_flags; > } > > enum release_type { > @@ -2230,21 +2269,9 @@ static void pci_prepare_next_assign_round(struct list_head *fail_head, > } > > /* Restore size and flags */ > - list_for_each_entry(fail_res, fail_head, list) { > - struct resource *res = fail_res->res; > - struct pci_dev *dev = fail_res->dev; > - int idx = pci_resource_num(dev, res); > - > + list_for_each_entry(fail_res, fail_head, list) > restore_dev_resource(fail_res); > > - if (!pci_is_bridge(dev)) > - continue; > - > - if (idx >= PCI_BRIDGE_RESOURCES && > - idx <= PCI_BRIDGE_RESOURCE_END) > - res->flags = 0; > - } > - > free_list(fail_head); > } > > diff --git a/drivers/pci/setup-res.c b/drivers/pci/setup-res.c > index 0468c058b5987..c5ef8ef54d3ce 100644 > --- a/drivers/pci/setup-res.c > +++ b/drivers/pci/setup-res.c > @@ -359,6 +359,9 @@ int pci_assign_resource(struct pci_dev *dev, int resno) > > res->flags &= ~IORESOURCE_UNSET; > res->flags &= ~IORESOURCE_STARTALIGN; > + if (resno >= PCI_BRIDGE_RESOURCES && resno <= PCI_BRIDGE_RESOURCE_END) > + res->flags &= ~IORESOURCE_DISABLED; > + > pci_info(dev, "%s %pR: assigned\n", res_name, res); > if (resno < PCI_BRIDGE_RESOURCES) > pci_update_resource(dev, resno); >

2 months, 1 week

2
1
0 0

[PATCH] usb: gadget: udc: fix race condition in usb_del_gadget

by Jimmy Hu

A race condition during gadget teardown can lead to a use-after-free in usb_gadget_state_work(), as reported by KASAN: BUG: KASAN: invalid-access in sysfs_notify+0_x_2c/0_x_d0 Workqueue: events usb_gadget_state_work The fundamental race occurs because a concurrent event (e.g., an interrupt) can call usb_gadget_set_state() and schedule gadget->work at any time during the cleanup process in usb_del_gadget(). Commit 399a45e5237c ("usb: gadget: core: flush gadget workqueue after device removal") attempted to fix this by moving flush_work() to after device_del(). However, this does not fully solve the race, as a new work item can still be scheduled *after* flush_work() completes but before the gadget's memory is freed, leading to the same use-after-free. This patch fixes the race condition robustly by introducing a 'teardown' flag and a 'state_lock' spinlock to the usb_gadget struct. The flag is set during cleanup in usb_del_gadget() *before* calling flush_work() to prevent any new work from being scheduled once cleanup has commenced. The scheduling site, usb_gadget_set_state(), now checks this flag under the lock before queueing the work, thus safely closing the race window. Fixes: 5702f75375aa9 ("usb: gadget: udc-core: move sysfs_notify() to a workqueue") Signed-off-by: Jimmy Hu <hhhuuu(a)google.com> Cc: stable(a)vger.kernel.org --- drivers/usb/gadget/udc/core.c | 18 +++++++++++++++++- include/linux/usb/gadget.h | 6 ++++++ 2 files changed, 23 insertions(+), 1 deletion(-) diff --git a/drivers/usb/gadget/udc/core.c b/drivers/usb/gadget/udc/core.c index d709e24c1fd4..c4268b76d747 100644 --- a/drivers/usb/gadget/udc/core.c +++ b/drivers/usb/gadget/udc/core.c @@ -1123,8 +1123,13 @@ static void usb_gadget_state_work(struct work_struct *work) void usb_gadget_set_state(struct usb_gadget *gadget, enum usb_device_state state) { + unsigned long flags; + + spin_lock_irqsave(&gadget->state_lock, flags); gadget->state = state; - schedule_work(&gadget->work); + if (!gadget->teardown) + schedule_work(&gadget->work); + spin_unlock_irqrestore(&gadget->state_lock, flags); } EXPORT_SYMBOL_GPL(usb_gadget_set_state); @@ -1357,6 +1362,9 @@ static void usb_udc_nop_release(struct device *dev) void usb_initialize_gadget(struct device *parent, struct usb_gadget *gadget, void (*release)(struct device *dev)) { + /* For race-free teardown */ + spin_lock_init(&gadget->state_lock); + gadget->teardown = false; INIT_WORK(&gadget->work, usb_gadget_state_work); gadget->dev.parent = parent; @@ -1531,6 +1539,7 @@ EXPORT_SYMBOL_GPL(usb_add_gadget_udc); void usb_del_gadget(struct usb_gadget *gadget) { struct usb_udc *udc = gadget->udc; + unsigned long flags; if (!udc) return; @@ -1544,6 +1553,13 @@ void usb_del_gadget(struct usb_gadget *gadget) kobject_uevent(&udc->dev.kobj, KOBJ_REMOVE); sysfs_remove_link(&udc->dev.kobj, "gadget"); device_del(&gadget->dev); + /* + * Set the teardown flag before flushing the work to prevent new work + * from being scheduled while we are cleaning up. + */ + spin_lock_irqsave(&gadget->state_lock, flags); + gadget->teardown = true; + spin_unlock_irqrestore(&gadget->state_lock, flags); flush_work(&gadget->work); ida_free(&gadget_id_numbers, gadget->id_number); cancel_work_sync(&udc->vbus_work); diff --git a/include/linux/usb/gadget.h b/include/linux/usb/gadget.h index 0f28c5512fcb..8302aeaea82e 100644 --- a/include/linux/usb/gadget.h +++ b/include/linux/usb/gadget.h @@ -351,6 +351,9 @@ struct usb_gadget_ops { * can handle. The UDC must support this and all slower speeds and lower * number of lanes. * @state: the state we are now (attached, suspended, configured, etc) + * @state_lock: Spinlock protecting the `state` and `teardown` members. + * @teardown: True if the device is undergoing teardown, used to prevent + * new work from being scheduled during cleanup. * @name: Identifies the controller hardware type. Used in diagnostics * and sometimes configuration. * @dev: Driver model state for this abstract device. @@ -426,6 +429,9 @@ struct usb_gadget { enum usb_ssp_rate max_ssp_rate; enum usb_device_state state; + /* For race-free teardown and state management */ + spinlock_t state_lock; + bool teardown; const char *name; struct device dev; unsigned isoch_delay; -- 2.51.0.618.g983fd99d29-goog

2 months, 1 week

2
1
0 0

FAILED: patch "[PATCH] PCI: endpoint: pci-epf-test: Add NULL check for DMA channels" failed to apply to 5.10-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 5.10-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>. To reproduce the conflict and resubmit, you may use the following commands: git fetch https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/ linux-5.10.y git checkout FETCH_HEAD git cherry-pick -x 85afa9ea122dd9d4a2ead104a951d318975dcd25 # <resolve conflicts, build, test, etc.> git commit -s git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '2025101342-copartner-greedless-b2d8@gregkh' --subject-prefix 'PATCH 5.10.y' HEAD^.. Possible dependencies: thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From 85afa9ea122dd9d4a2ead104a951d318975dcd25 Mon Sep 17 00:00:00 2001 From: Shin'ichiro Kawasaki <shinichiro.kawasaki(a)wdc.com> Date: Tue, 16 Sep 2025 11:57:56 +0900 Subject: [PATCH] PCI: endpoint: pci-epf-test: Add NULL check for DMA channels before release MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit The fields dma_chan_tx and dma_chan_rx of the struct pci_epf_test can be NULL even after EPF initialization. Then it is prudent to check that they have non-NULL values before releasing the channels. Add the checks in pci_epf_test_clean_dma_chan(). Without the checks, NULL pointer dereferences happen and they can lead to a kernel panic in some cases: Unable to handle kernel NULL pointer dereference at virtual address 0000000000000050 Call trace: dma_release_channel+0x2c/0x120 (P) pci_epf_test_epc_deinit+0x94/0xc0 [pci_epf_test] pci_epc_deinit_notify+0x74/0xc0 tegra_pcie_ep_pex_rst_irq+0x250/0x5d8 irq_thread_fn+0x34/0xb8 irq_thread+0x18c/0x2e8 kthread+0x14c/0x210 ret_from_fork+0x10/0x20 Fixes: 8353813c88ef ("PCI: endpoint: Enable DMA tests for endpoints with DMA capabilities") Fixes: 5ebf3fc59bd2 ("PCI: endpoint: functions/pci-epf-test: Add DMA support to transfer data") Signed-off-by: Shin'ichiro Kawasaki <shinichiro.kawasaki(a)wdc.com> [mani: trimmed the stack trace] Signed-off-by: Manivannan Sadhasivam <mani(a)kernel.org> Reviewed-by: Damien Le Moal <dlemoal(a)kernel.org> Reviewed-by: Krzysztof Wilczyński <kwilczynski(a)kernel.org> Cc: stable(a)vger.kernel.org Link: https://patch.msgid.link/20250916025756.34807-1-shinichiro.kawasaki@wdc.com diff --git a/drivers/pci/endpoint/functions/pci-epf-test.c b/drivers/pci/endpoint/functions/pci-epf-test.c index 09e1b8b46b55..31617772ad51 100644 --- a/drivers/pci/endpoint/functions/pci-epf-test.c +++ b/drivers/pci/endpoint/functions/pci-epf-test.c @@ -301,15 +301,20 @@ static void pci_epf_test_clean_dma_chan(struct pci_epf_test *epf_test) if (!epf_test->dma_supported) return; - dma_release_channel(epf_test->dma_chan_tx); - if (epf_test->dma_chan_tx == epf_test->dma_chan_rx) { + if (epf_test->dma_chan_tx) { + dma_release_channel(epf_test->dma_chan_tx); + if (epf_test->dma_chan_tx == epf_test->dma_chan_rx) { + epf_test->dma_chan_tx = NULL; + epf_test->dma_chan_rx = NULL; + return; + } epf_test->dma_chan_tx = NULL; - epf_test->dma_chan_rx = NULL; - return; } - dma_release_channel(epf_test->dma_chan_rx); - epf_test->dma_chan_rx = NULL; + if (epf_test->dma_chan_rx) { + dma_release_channel(epf_test->dma_chan_rx); + epf_test->dma_chan_rx = NULL; + } } static void pci_epf_test_print_rate(struct pci_epf_test *epf_test,

2 months, 1 week

1
0
0 0

FAILED: patch "[PATCH] PCI: endpoint: pci-epf-test: Add NULL check for DMA channels" 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>. To reproduce the conflict and resubmit, you may use the following commands: git fetch https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/ linux-5.15.y git checkout FETCH_HEAD git cherry-pick -x 85afa9ea122dd9d4a2ead104a951d318975dcd25 # <resolve conflicts, build, test, etc.> git commit -s git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '2025101341-hurler-salute-f4f9@gregkh' --subject-prefix 'PATCH 5.15.y' HEAD^.. Possible dependencies: thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From 85afa9ea122dd9d4a2ead104a951d318975dcd25 Mon Sep 17 00:00:00 2001 From: Shin'ichiro Kawasaki <shinichiro.kawasaki(a)wdc.com> Date: Tue, 16 Sep 2025 11:57:56 +0900 Subject: [PATCH] PCI: endpoint: pci-epf-test: Add NULL check for DMA channels before release MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit The fields dma_chan_tx and dma_chan_rx of the struct pci_epf_test can be NULL even after EPF initialization. Then it is prudent to check that they have non-NULL values before releasing the channels. Add the checks in pci_epf_test_clean_dma_chan(). Without the checks, NULL pointer dereferences happen and they can lead to a kernel panic in some cases: Unable to handle kernel NULL pointer dereference at virtual address 0000000000000050 Call trace: dma_release_channel+0x2c/0x120 (P) pci_epf_test_epc_deinit+0x94/0xc0 [pci_epf_test] pci_epc_deinit_notify+0x74/0xc0 tegra_pcie_ep_pex_rst_irq+0x250/0x5d8 irq_thread_fn+0x34/0xb8 irq_thread+0x18c/0x2e8 kthread+0x14c/0x210 ret_from_fork+0x10/0x20 Fixes: 8353813c88ef ("PCI: endpoint: Enable DMA tests for endpoints with DMA capabilities") Fixes: 5ebf3fc59bd2 ("PCI: endpoint: functions/pci-epf-test: Add DMA support to transfer data") Signed-off-by: Shin'ichiro Kawasaki <shinichiro.kawasaki(a)wdc.com> [mani: trimmed the stack trace] Signed-off-by: Manivannan Sadhasivam <mani(a)kernel.org> Reviewed-by: Damien Le Moal <dlemoal(a)kernel.org> Reviewed-by: Krzysztof Wilczyński <kwilczynski(a)kernel.org> Cc: stable(a)vger.kernel.org Link: https://patch.msgid.link/20250916025756.34807-1-shinichiro.kawasaki@wdc.com diff --git a/drivers/pci/endpoint/functions/pci-epf-test.c b/drivers/pci/endpoint/functions/pci-epf-test.c index 09e1b8b46b55..31617772ad51 100644 --- a/drivers/pci/endpoint/functions/pci-epf-test.c +++ b/drivers/pci/endpoint/functions/pci-epf-test.c @@ -301,15 +301,20 @@ static void pci_epf_test_clean_dma_chan(struct pci_epf_test *epf_test) if (!epf_test->dma_supported) return; - dma_release_channel(epf_test->dma_chan_tx); - if (epf_test->dma_chan_tx == epf_test->dma_chan_rx) { + if (epf_test->dma_chan_tx) { + dma_release_channel(epf_test->dma_chan_tx); + if (epf_test->dma_chan_tx == epf_test->dma_chan_rx) { + epf_test->dma_chan_tx = NULL; + epf_test->dma_chan_rx = NULL; + return; + } epf_test->dma_chan_tx = NULL; - epf_test->dma_chan_rx = NULL; - return; } - dma_release_channel(epf_test->dma_chan_rx); - epf_test->dma_chan_rx = NULL; + if (epf_test->dma_chan_rx) { + dma_release_channel(epf_test->dma_chan_rx); + epf_test->dma_chan_rx = NULL; + } } static void pci_epf_test_print_rate(struct pci_epf_test *epf_test,

2 months, 1 week

1
0
0 0

FAILED: patch "[PATCH] misc: fastrpc: fix possible map leak in fastrpc_put_args" failed to apply to 5.4-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 5.4-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>. To reproduce the conflict and resubmit, you may use the following commands: git fetch https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/ linux-5.4.y git checkout FETCH_HEAD git cherry-pick -x da1ba64176e0138f2bfa96f9e43e8c3640d01e1e # <resolve conflicts, build, test, etc.> git commit -s git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '2025101312-express-attractor-1757@gregkh' --subject-prefix 'PATCH 5.4.y' HEAD^.. Possible dependencies: thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From da1ba64176e0138f2bfa96f9e43e8c3640d01e1e Mon Sep 17 00:00:00 2001 From: Ling Xu <quic_lxu5(a)quicinc.com> Date: Fri, 12 Sep 2025 14:12:35 +0100 Subject: [PATCH] misc: fastrpc: fix possible map leak in fastrpc_put_args copy_to_user() failure would cause an early return without cleaning up the fdlist, which has been updated by the DSP. This could lead to map leak. Fix this by redirecting to a cleanup path on failure, ensuring that all mapped buffers are properly released before returning. Fixes: c68cfb718c8f ("misc: fastrpc: Add support for context Invoke method") Cc: stable(a)kernel.org Co-developed-by: Ekansh Gupta <ekansh.gupta(a)oss.qualcomm.com> Signed-off-by: Ekansh Gupta <ekansh.gupta(a)oss.qualcomm.com> Signed-off-by: Ling Xu <quic_lxu5(a)quicinc.com> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov(a)oss.qualcomm.com> Signed-off-by: Srinivas Kandagatla <srini(a)kernel.org> Link: https://lore.kernel.org/r/20250912131236.303102-4-srini@kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> diff --git a/drivers/misc/fastrpc.c b/drivers/misc/fastrpc.c index 1815b1e0c607..d950a179bff8 100644 --- a/drivers/misc/fastrpc.c +++ b/drivers/misc/fastrpc.c @@ -1085,6 +1085,7 @@ static int fastrpc_put_args(struct fastrpc_invoke_ctx *ctx, struct fastrpc_phy_page *pages; u64 *fdlist; int i, inbufs, outbufs, handles; + int ret = 0; inbufs = REMOTE_SCALARS_INBUFS(ctx->sc); outbufs = REMOTE_SCALARS_OUTBUFS(ctx->sc); @@ -1100,14 +1101,17 @@ static int fastrpc_put_args(struct fastrpc_invoke_ctx *ctx, u64 len = rpra[i].buf.len; if (!kernel) { - if (copy_to_user((void __user *)dst, src, len)) - return -EFAULT; + if (copy_to_user((void __user *)dst, src, len)) { + ret = -EFAULT; + goto cleanup_fdlist; + } } else { memcpy(dst, src, len); } } } +cleanup_fdlist: /* Clean up fdlist which is updated by DSP */ for (i = 0; i < FASTRPC_MAX_FDLIST; i++) { if (!fdlist[i]) @@ -1116,7 +1120,7 @@ static int fastrpc_put_args(struct fastrpc_invoke_ctx *ctx, fastrpc_map_put(mmap); } - return 0; + return ret; } static int fastrpc_invoke_send(struct fastrpc_session_ctx *sctx,

2 months, 1 week

1
0
0 0

FAILED: patch "[PATCH] misc: fastrpc: fix possible map leak in fastrpc_put_args" failed to apply to 5.10-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 5.10-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>. To reproduce the conflict and resubmit, you may use the following commands: git fetch https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/ linux-5.10.y git checkout FETCH_HEAD git cherry-pick -x da1ba64176e0138f2bfa96f9e43e8c3640d01e1e # <resolve conflicts, build, test, etc.> git commit -s git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '2025101311-unrented-email-bbb3@gregkh' --subject-prefix 'PATCH 5.10.y' HEAD^.. Possible dependencies: thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From da1ba64176e0138f2bfa96f9e43e8c3640d01e1e Mon Sep 17 00:00:00 2001 From: Ling Xu <quic_lxu5(a)quicinc.com> Date: Fri, 12 Sep 2025 14:12:35 +0100 Subject: [PATCH] misc: fastrpc: fix possible map leak in fastrpc_put_args copy_to_user() failure would cause an early return without cleaning up the fdlist, which has been updated by the DSP. This could lead to map leak. Fix this by redirecting to a cleanup path on failure, ensuring that all mapped buffers are properly released before returning. Fixes: c68cfb718c8f ("misc: fastrpc: Add support for context Invoke method") Cc: stable(a)kernel.org Co-developed-by: Ekansh Gupta <ekansh.gupta(a)oss.qualcomm.com> Signed-off-by: Ekansh Gupta <ekansh.gupta(a)oss.qualcomm.com> Signed-off-by: Ling Xu <quic_lxu5(a)quicinc.com> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov(a)oss.qualcomm.com> Signed-off-by: Srinivas Kandagatla <srini(a)kernel.org> Link: https://lore.kernel.org/r/20250912131236.303102-4-srini@kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> diff --git a/drivers/misc/fastrpc.c b/drivers/misc/fastrpc.c index 1815b1e0c607..d950a179bff8 100644 --- a/drivers/misc/fastrpc.c +++ b/drivers/misc/fastrpc.c @@ -1085,6 +1085,7 @@ static int fastrpc_put_args(struct fastrpc_invoke_ctx *ctx, struct fastrpc_phy_page *pages; u64 *fdlist; int i, inbufs, outbufs, handles; + int ret = 0; inbufs = REMOTE_SCALARS_INBUFS(ctx->sc); outbufs = REMOTE_SCALARS_OUTBUFS(ctx->sc); @@ -1100,14 +1101,17 @@ static int fastrpc_put_args(struct fastrpc_invoke_ctx *ctx, u64 len = rpra[i].buf.len; if (!kernel) { - if (copy_to_user((void __user *)dst, src, len)) - return -EFAULT; + if (copy_to_user((void __user *)dst, src, len)) { + ret = -EFAULT; + goto cleanup_fdlist; + } } else { memcpy(dst, src, len); } } } +cleanup_fdlist: /* Clean up fdlist which is updated by DSP */ for (i = 0; i < FASTRPC_MAX_FDLIST; i++) { if (!fdlist[i]) @@ -1116,7 +1120,7 @@ static int fastrpc_put_args(struct fastrpc_invoke_ctx *ctx, fastrpc_map_put(mmap); } - return 0; + return ret; } static int fastrpc_invoke_send(struct fastrpc_session_ctx *sctx,

2 months, 1 week

1
0
0 0

FAILED: patch "[PATCH] misc: fastrpc: fix possible map leak in fastrpc_put_args" 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>. To reproduce the conflict and resubmit, you may use the following commands: git fetch https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/ linux-5.15.y git checkout FETCH_HEAD git cherry-pick -x da1ba64176e0138f2bfa96f9e43e8c3640d01e1e # <resolve conflicts, build, test, etc.> git commit -s git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '2025101311-user-gratified-0681@gregkh' --subject-prefix 'PATCH 5.15.y' HEAD^.. Possible dependencies: thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From da1ba64176e0138f2bfa96f9e43e8c3640d01e1e Mon Sep 17 00:00:00 2001 From: Ling Xu <quic_lxu5(a)quicinc.com> Date: Fri, 12 Sep 2025 14:12:35 +0100 Subject: [PATCH] misc: fastrpc: fix possible map leak in fastrpc_put_args copy_to_user() failure would cause an early return without cleaning up the fdlist, which has been updated by the DSP. This could lead to map leak. Fix this by redirecting to a cleanup path on failure, ensuring that all mapped buffers are properly released before returning. Fixes: c68cfb718c8f ("misc: fastrpc: Add support for context Invoke method") Cc: stable(a)kernel.org Co-developed-by: Ekansh Gupta <ekansh.gupta(a)oss.qualcomm.com> Signed-off-by: Ekansh Gupta <ekansh.gupta(a)oss.qualcomm.com> Signed-off-by: Ling Xu <quic_lxu5(a)quicinc.com> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov(a)oss.qualcomm.com> Signed-off-by: Srinivas Kandagatla <srini(a)kernel.org> Link: https://lore.kernel.org/r/20250912131236.303102-4-srini@kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> diff --git a/drivers/misc/fastrpc.c b/drivers/misc/fastrpc.c index 1815b1e0c607..d950a179bff8 100644 --- a/drivers/misc/fastrpc.c +++ b/drivers/misc/fastrpc.c @@ -1085,6 +1085,7 @@ static int fastrpc_put_args(struct fastrpc_invoke_ctx *ctx, struct fastrpc_phy_page *pages; u64 *fdlist; int i, inbufs, outbufs, handles; + int ret = 0; inbufs = REMOTE_SCALARS_INBUFS(ctx->sc); outbufs = REMOTE_SCALARS_OUTBUFS(ctx->sc); @@ -1100,14 +1101,17 @@ static int fastrpc_put_args(struct fastrpc_invoke_ctx *ctx, u64 len = rpra[i].buf.len; if (!kernel) { - if (copy_to_user((void __user *)dst, src, len)) - return -EFAULT; + if (copy_to_user((void __user *)dst, src, len)) { + ret = -EFAULT; + goto cleanup_fdlist; + } } else { memcpy(dst, src, len); } } } +cleanup_fdlist: /* Clean up fdlist which is updated by DSP */ for (i = 0; i < FASTRPC_MAX_FDLIST; i++) { if (!fdlist[i]) @@ -1116,7 +1120,7 @@ static int fastrpc_put_args(struct fastrpc_invoke_ctx *ctx, fastrpc_map_put(mmap); } - return 0; + return ret; } static int fastrpc_invoke_send(struct fastrpc_session_ctx *sctx,

2 months, 1 week

1
0
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror