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

[PATCH v2] mm/memory-failure: teach kill_accessing_process to accept hugetlb tail page pfn

by Jane Chu

When a hugetlb folio is being poisoned again, try_memory_failure_hugetlb() passed head pfn to kill_accessing_process(), that is not right. The precise pfn of the poisoned page should be used in order to determine the precise vaddr as the SIGBUS payload. This issue has already been taken care of in the normal path, that is, hwpoison_user_mappings(), see [1][2]. Further more, for [3] to work correctly in the hugetlb repoisoning case, it's essential to inform VM the precise poisoned page, not the head page. [1] https://lkml.kernel.org/r/20231218135837.3310403-1-willy@infradead.org [2] https://lkml.kernel.org/r/20250224211445.2663312-1-jane.chu@oracle.com [3] https://lore.kernel.org/lkml/20251116013223.1557158-1-jiaqiyan@google.com/ Cc: <stable(a)vger.kernel.org> Signed-off-by: Jane Chu <jane.chu(a)oracle.com> Reviewed-by: Liam R. Howlett <Liam.Howlett(a)oracle.com> --- v1 -> v2: pickup R-B, add stable to cc list. --- mm/memory-failure.c | 22 ++++++++++++---------- 1 file changed, 12 insertions(+), 10 deletions(-) diff --git a/mm/memory-failure.c b/mm/memory-failure.c index 3edebb0cda30..c9d87811b1ea 100644 --- a/mm/memory-failure.c +++ b/mm/memory-failure.c @@ -681,9 +681,11 @@ static void set_to_kill(struct to_kill *tk, unsigned long addr, short shift) } static int check_hwpoisoned_entry(pte_t pte, unsigned long addr, short shift, - unsigned long poisoned_pfn, struct to_kill *tk) + unsigned long poisoned_pfn, struct to_kill *tk, + int pte_nr) { unsigned long pfn = 0; + unsigned long hwpoison_vaddr; if (pte_present(pte)) { pfn = pte_pfn(pte); @@ -694,10 +696,11 @@ static int check_hwpoisoned_entry(pte_t pte, unsigned long addr, short shift, pfn = swp_offset_pfn(swp); } - if (!pfn || pfn != poisoned_pfn) + if (!pfn || (pfn > poisoned_pfn || (pfn + pte_nr - 1) < poisoned_pfn)) return 0; - set_to_kill(tk, addr, shift); + hwpoison_vaddr = addr + ((poisoned_pfn - pfn) << PAGE_SHIFT); + set_to_kill(tk, hwpoison_vaddr, shift); return 1; } @@ -749,7 +752,7 @@ static int hwpoison_pte_range(pmd_t *pmdp, unsigned long addr, for (; addr != end; ptep++, addr += PAGE_SIZE) { ret = check_hwpoisoned_entry(ptep_get(ptep), addr, PAGE_SHIFT, - hwp->pfn, &hwp->tk); + hwp->pfn, &hwp->tk, 1); if (ret == 1) break; } @@ -772,8 +775,8 @@ static int hwpoison_hugetlb_range(pte_t *ptep, unsigned long hmask, ptl = huge_pte_lock(h, walk->mm, ptep); pte = huge_ptep_get(walk->mm, addr, ptep); - ret = check_hwpoisoned_entry(pte, addr, huge_page_shift(h), - hwp->pfn, &hwp->tk); + ret = check_hwpoisoned_entry(pte, addr, huge_page_shift(h), hwp->pfn, + &hwp->tk, pages_per_huge_page(h)); spin_unlock(ptl); return ret; } @@ -2023,10 +2026,8 @@ static int try_memory_failure_hugetlb(unsigned long pfn, int flags, int *hugetlb *hugetlb = 0; return 0; } else if (res == -EHWPOISON) { - if (flags & MF_ACTION_REQUIRED) { - folio = page_folio(p); - res = kill_accessing_process(current, folio_pfn(folio), flags); - } + if (flags & MF_ACTION_REQUIRED) + res = kill_accessing_process(current, pfn, flags); action_result(pfn, MF_MSG_ALREADY_POISONED, MF_FAILED); return res; } else if (res == -EBUSY) { @@ -2037,6 +2038,7 @@ static int try_memory_failure_hugetlb(unsigned long pfn, int flags, int *hugetlb return action_result(pfn, MF_MSG_GET_HWPOISON, MF_IGNORED); } + folio = page_folio(p); folio_lock(folio); -- 2.43.5

31 minutes

1
0
0 0

[PATCH 02/23] PCI: Rewrite bridge window head alignment function

by Ilpo Järvinen

The calculation of bridge window head alignment is done by calculate_mem_align() [*]. With the default bridge window alignment, it is used for both head and tail alignment. The selected head alignment does not always result in tight-fitting resources (gap at d4f00000-d4ffffff): d4800000-dbffffff : PCI Bus 0000:06 d4800000-d48fffff : PCI Bus 0000:07 d4800000-d4803fff : 0000:07:00.0 d4800000-d4803fff : nvme d4900000-d49fffff : PCI Bus 0000:0a d4900000-d490ffff : 0000:0a:00.0 d4900000-d490ffff : r8169 d4910000-d4913fff : 0000:0a:00.0 d4a00000-d4cfffff : PCI Bus 0000:0b d4a00000-d4bfffff : 0000:0b:00.0 d4a00000-d4bfffff : 0000:0b:00.0 d4c00000-d4c07fff : 0000:0b:00.0 d4d00000-d4dfffff : PCI Bus 0000:15 d4d00000-d4d07fff : 0000:15:00.0 d4d00000-d4d07fff : xhci-hcd d4e00000-d4efffff : PCI Bus 0000:16 d4e00000-d4e7ffff : 0000:16:00.0 d4e80000-d4e803ff : 0000:16:00.0 d4e80000-d4e803ff : ahci d5000000-dbffffff : PCI Bus 0000:0c This has not been caused problems (for years) with the default bridge window tail alignment that grossly over-estimates the required tail alignment leaving more tail room than necessary. With the introduction of relaxed tail alignment that leaves no extra tail room whatsoever, any gaps will immediately turn into assignment failures. Introduce head alignment calculation that ensures no gaps are left and apply the new approach when using relaxed alignment. We may want to consider using it for the normal alignment eventually, but as the first step, solve only the problem with the relaxed tail alignment. ([*] I don't understand the algorithm in calculate_mem_align().) Fixes: 5d0a8965aea9 ("[PATCH] 2.5.14: New PCI allocation code (alpha, arm, parisc) [2/2]") Closes: https://bugzilla.kernel.org/show_bug.cgi?id=220775 Reported-by: Malte Schröder <malte+lkml(a)tnxip.de> Tested-by: Malte Schröder <malte+lkml(a)tnxip.de> Signed-off-by: Ilpo Järvinen <ilpo.jarvinen(a)linux.intel.com> Cc: stable(a)vger.kernel.org --- Little annoyingly, there's difference in what aligns array contains between the legacy alignment approach (which I dare not to touch as I really don't understand what the algorithm tries to do) and this new head aligment algorithm, both consuming stack space. After making the new approach the only available approach in the follow-up patch, only one array remains (however, that follow-up change is also somewhat riskier when it comes to regressions). That being said, the new head alignment could work with the same aligns array as the legacy approach, it just won't necessarily produce an optimal (the smallest possible) head alignment when if (r_size <= align) condition is used. Just let me know if that approach is preferred (to save some stack space). --- drivers/pci/setup-bus.c | 53 ++++++++++++++++++++++++++++++++++------- 1 file changed, 44 insertions(+), 9 deletions(-) diff --git a/drivers/pci/setup-bus.c b/drivers/pci/setup-bus.c index 4b918ff4d2d8..80e5a8fc62e7 100644 --- a/drivers/pci/setup-bus.c +++ b/drivers/pci/setup-bus.c @@ -1228,6 +1228,45 @@ static inline resource_size_t calculate_mem_align(resource_size_t *aligns, return min_align; } +/* + * Calculate bridge window head alignment that leaves no gaps in between + * resources. + */ +static resource_size_t calculate_head_align(resource_size_t *aligns, + int max_order) +{ + resource_size_t head_align = 1; + resource_size_t remainder = 0; + int order; + + /* Take the largest alignment as the starting point. */ + head_align <<= max_order + __ffs(SZ_1M); + + for (order = max_order - 1; order >= 0; order--) { + resource_size_t align1 = 1; + + align1 <<= order + __ffs(SZ_1M); + + /* + * Account smaller resources with alignment < max_order that + * could be used to fill head room if alignment less than + * max_order is used. + */ + remainder += aligns[order]; + + /* + * Test if head fill is enough to satisfy the alignment of + * the larger resources after reducing the alignment. + */ + while ((head_align > align1) && (remainder >= head_align / 2)) { + head_align /= 2; + remainder -= head_align; + } + } + + return head_align; +} + /** * pbus_upstream_space_available - Check no upstream resource limits allocation * @bus: The bus @@ -1315,13 +1354,13 @@ static void pbus_size_mem(struct pci_bus *bus, unsigned long type, { struct pci_dev *dev; resource_size_t min_align, win_align, align, size, size0, size1 = 0; - resource_size_t aligns[28]; /* Alignments from 1MB to 128TB */ + resource_size_t aligns[28] = {}; /* Alignments from 1MB to 128TB */ + resource_size_t aligns2[28] = {};/* Alignments from 1MB to 128TB */ int order, max_order; struct resource *b_res = pbus_select_window_for_type(bus, type); resource_size_t children_add_size = 0; resource_size_t children_add_align = 0; resource_size_t add_align = 0; - resource_size_t relaxed_align; resource_size_t old_size; if (!b_res) @@ -1331,7 +1370,6 @@ static void pbus_size_mem(struct pci_bus *bus, unsigned long type, if (b_res->parent) return; - memset(aligns, 0, sizeof(aligns)); max_order = 0; size = 0; @@ -1382,6 +1420,7 @@ static void pbus_size_mem(struct pci_bus *bus, unsigned long type, */ if (r_size <= align) aligns[order] += align; + aligns2[order] += align; if (order > max_order) max_order = order; @@ -1406,9 +1445,7 @@ static void pbus_size_mem(struct pci_bus *bus, unsigned long type, if (bus->self && size0 && !pbus_upstream_space_available(bus, b_res, size0, min_align)) { - relaxed_align = 1ULL << (max_order + __ffs(SZ_1M)); - relaxed_align = max(relaxed_align, win_align); - min_align = min(min_align, relaxed_align); + min_align = calculate_head_align(aligns2, max_order); size0 = calculate_memsize(size, min_size, 0, 0, old_size, win_align); resource_set_range(b_res, min_align, size0); pci_info(bus->self, "bridge window %pR to %pR requires relaxed alignment rules\n", @@ -1422,9 +1459,7 @@ static void pbus_size_mem(struct pci_bus *bus, unsigned long type, if (bus->self && size1 && !pbus_upstream_space_available(bus, b_res, size1, add_align)) { - relaxed_align = 1ULL << (max_order + __ffs(SZ_1M)); - relaxed_align = max(relaxed_align, win_align); - min_align = min(min_align, relaxed_align); + min_align = calculate_head_align(aligns2, max_order); size1 = calculate_memsize(size, min_size, add_size, children_add_size, old_size, win_align); pci_info(bus->self, -- 2.39.5

46 minutes

1
0
0 0

[PATCH 01/23] PCI: Fix bridge window alignment with optional resources

by Ilpo Järvinen

pbus_size_mem() has two alignments, one for required resources in min_align and another in add_align that takes account optional resources. The add_align is applied to the bridge window through the realloc_head list. It can happen, however, that add_align is larger than min_align but calculated size1 and size0 are equal due to extra tailroom (e.g., hotplug reservation, tail alignment), and therefore no entry is created to the realloc_head list. Without the bridge appearing in the realloc head, add_align is lost when pbus_size_mem() returns. The problem is visible in this log for 0000:05:00.0 which lacks add_size ... add_align ... line that would indicate it was added into the realloc_head list: pci 0000:05:00.0: PCI bridge to [bus 06-16] ... pci 0000:06:00.0: bridge window [mem 0x00100000-0x001fffff] to [bus 07] requires relaxed alignment rules pci 0000:06:06.0: bridge window [mem 0x00100000-0x001fffff] to [bus 0a] requires relaxed alignment rules pci 0000:06:07.0: bridge window [mem 0x00100000-0x003fffff] to [bus 0b] requires relaxed alignment rules pci 0000:06:08.0: bridge window [mem 0x00800000-0x00ffffff 64bit pref] to [bus 0c-14] requires relaxed alignment rules pci 0000:06:08.0: bridge window [mem 0x01000000-0x057fffff] to [bus 0c-14] requires relaxed alignment rules pci 0000:06:08.0: bridge window [mem 0x01000000-0x057fffff] to [bus 0c-14] requires relaxed alignment rules pci 0000:06:08.0: bridge window [mem 0x01000000-0x057fffff] to [bus 0c-14] add_size 100000 add_align 1000000 pci 0000:06:0c.0: bridge window [mem 0x00100000-0x001fffff] to [bus 15] requires relaxed alignment rules pci 0000:06:0d.0: bridge window [mem 0x00100000-0x001fffff] to [bus 16] requires relaxed alignment rules pci 0000:06:0d.0: bridge window [mem 0x00100000-0x001fffff] to [bus 16] requires relaxed alignment rules pci 0000:05:00.0: bridge window [mem 0xd4800000-0xd97fffff]: assigned pci 0000:05:00.0: bridge window [mem 0x1060000000-0x10607fffff 64bit pref]: assigned pci 0000:06:08.0: bridge window [mem size 0x04900000]: can't assign; no space pci 0000:06:08.0: bridge window [mem size 0x04900000]: failed to assign While this bug itself seems old, it has likely become more visible after the relaxed tail alignment that does not grossly overestimate the size needed for the bridge window. Make sure add_align > min_align too results in adding an entry into the realloc head list. In addition, add handling to the cases where add_size is zero while only alignment differs. Fixes: d74b9027a4da ("PCI: Consider additional PF's IOV BAR alignment in sizing and assigning") Reported-by: Malte Schröder <malte+lkml(a)tnxip.de> Tested-by: Malte Schröder <malte+lkml(a)tnxip.de> Signed-off-by: Ilpo Järvinen <ilpo.jarvinen(a)linux.intel.com> Cc: stable(a)vger.kernel.org --- drivers/pci/setup-bus.c | 10 ++++++---- 1 file changed, 6 insertions(+), 4 deletions(-) diff --git a/drivers/pci/setup-bus.c b/drivers/pci/setup-bus.c index 6e90f46f52af..4b918ff4d2d8 100644 --- a/drivers/pci/setup-bus.c +++ b/drivers/pci/setup-bus.c @@ -14,6 +14,7 @@ * tighter packing. Prefetchable range support. */ +#include <linux/align.h> #include <linux/bitops.h> #include <linux/bug.h> #include <linux/init.h> @@ -456,7 +457,7 @@ static void reassign_resources_sorted(struct list_head *realloc_head, "%s %pR: ignoring failure in optional allocation\n", res_name, res); } - } else if (add_size > 0) { + } else if (add_size > 0 || !IS_ALIGNED(res->start, align)) { res->flags |= add_res->flags & (IORESOURCE_STARTALIGN|IORESOURCE_SIZEALIGN); if (pci_reassign_resource(dev, idx, add_size, align)) @@ -1442,12 +1443,13 @@ static void pbus_size_mem(struct pci_bus *bus, unsigned long type, resource_set_range(b_res, min_align, size0); b_res->flags |= IORESOURCE_STARTALIGN; - if (bus->self && size1 > size0 && realloc_head) { + if (bus->self && realloc_head && (size1 > size0 || add_align > min_align)) { b_res->flags &= ~IORESOURCE_DISABLED; - add_to_list(realloc_head, bus->self, b_res, size1-size0, add_align); + add_size = size1 > size0 ? size1 - size0 : 0; + add_to_list(realloc_head, bus->self, b_res, add_size, add_align); pci_info(bus->self, "bridge window %pR to %pR add_size %llx add_align %llx\n", b_res, &bus->busn_res, - (unsigned long long) (size1 - size0), + (unsigned long long) add_size, (unsigned long long) add_align); } } -- 2.39.5

46 minutes

1
0
0 0

[PATCH] x86/CPU/AMD: avoid printing reset reasons on Xen domU

by Ariadne Conill

Xen domU cannot access the given MMIO address for security reasons, resulting in a failed hypercall in ioremap() due to permissions. Fixes: ab8131028710 ("x86/CPU/AMD: Print the reason for the last reset") Signed-off-by: Ariadne Conill <ariadne(a)ariadne.space> Cc: xen-devel(a)lists.xenproject.org Cc: stable(a)vger.kernel.org --- arch/x86/kernel/cpu/amd.c | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/arch/x86/kernel/cpu/amd.c b/arch/x86/kernel/cpu/amd.c index a6f88ca1a6b4..99308fba4d7d 100644 --- a/arch/x86/kernel/cpu/amd.c +++ b/arch/x86/kernel/cpu/amd.c @@ -29,6 +29,8 @@ # include <asm/mmconfig.h> #endif +#include <xen/xen.h> + #include "cpu.h" u16 invlpgb_count_max __ro_after_init = 1; @@ -1333,6 +1335,10 @@ static __init int print_s5_reset_status_mmio(void) if (!cpu_feature_enabled(X86_FEATURE_ZEN)) return 0; + /* Xen PV domU cannot access hardware directly, so bail for domU case */ + if (cpu_feature_enabled(X86_FEATURE_XENPV) && !xen_initial_domain()) + return 0; + addr = ioremap(FCH_PM_BASE + FCH_PM_S5_RESET_STATUS, sizeof(value)); if (!addr) return 0; -- 2.51.0

47 minutes

4
4
0 0

Re: [PATCH] x86/CPU/AMD: avoid printing reset reasons on Xen domU

by Andrew Cooper

On 19/12/2025 4:09 pm, Sean Christopherson wrote: > On Fri, Dec 19, 2025, Borislav Petkov wrote: >> On December 19, 2025 1:01:31 AM UTC, Ariadne Conill <ariadne(a)ariadne.space> wrote: >>> Xen domU cannot access the given MMIO address for security reasons, >>> resulting in a failed hypercall in ioremap() due to permissions. > Why does that matter though? Ah, because set_pte() assumes success, and so > presumably the failed hypercall goes unnoticed and trying to access the MMIO > #PFs due to !PRESENT mapping. > >>> Fixes: ab8131028710 ("x86/CPU/AMD: Print the reason for the last reset") >>> Signed-off-by: Ariadne Conill <ariadne(a)ariadne.space> >>> Cc: xen-devel(a)lists.xenproject.org >>> Cc: stable(a)vger.kernel.org >>> --- >>> arch/x86/kernel/cpu/amd.c | 6 ++++++ >>> 1 file changed, 6 insertions(+) >>> >>> diff --git a/arch/x86/kernel/cpu/amd.c b/arch/x86/kernel/cpu/amd.c >>> index a6f88ca1a6b4..99308fba4d7d 100644 >>> --- a/arch/x86/kernel/cpu/amd.c >>> +++ b/arch/x86/kernel/cpu/amd.c >>> @@ -29,6 +29,8 @@ >>> # include <asm/mmconfig.h> >>> #endif >>> >>> +#include <xen/xen.h> >>> + >>> #include "cpu.h" >>> >>> u16 invlpgb_count_max __ro_after_init = 1; >>> @@ -1333,6 +1335,10 @@ static __init int print_s5_reset_status_mmio(void) >>> if (!cpu_feature_enabled(X86_FEATURE_ZEN)) >>> return 0; >>> >>> + /* Xen PV domU cannot access hardware directly, so bail for domU case */ > Heh, Xen on Zen crime. > >>> + if (cpu_feature_enabled(X86_FEATURE_XENPV) && !xen_initial_domain()) >>> + return 0; >>> + >>> addr = ioremap(FCH_PM_BASE + FCH_PM_S5_RESET_STATUS, sizeof(value)); >>> if (!addr) >>> return 0; >> Sean, looka here. The other hypervisor wants other checks. >> >> Time to whip out the X86_FEATURE_HYPERVISOR check. > LOL, Ariadne, be honest, how much did Boris pay you? :-D > > Jokes aside, I suppose I'm fine adding a HYPERVISOR check, but at the same time, > how is this not a Xen bug? Refusing to create a mapping because the VM doesn't > have a device defined at a given GPA is pretty hostile behavior for a hypervisor. > This is a Xen PV guest. No SVM/VT-x. A PV Guest (by it's contract with Xen) cannot create mappings to host physical addresses it doesn't own. Xen rejects the attempt, and Linux is ignoring the failure in this case. This has been ABI for 25 years. From a more practical point of view, because guests can read their own pagetables, Xen can't swap the requested PTE for safe alternative to trap the MMIO access, because that violates Linux's model of what's mapped in this position. ~Andrew

49 minutes

2
1
0 0

[regression 5.10.y] Libvirt can no longer delete macvtap devices after backport of a6cec0bcd342 ("net: rtnetlink: add bulk delete support flag") to 5.10.y series (Debian 11)

by Salvatore Bonaccorso

Hi all, Roland Schwarzkopf reported to the Debian mailing list a problem which he encountered once updating in Debian from 5.10.244 to 5.10.247. The report is quoted below and found in https://lists.debian.org/debian-kernel/2025/12/msg00223.html Roland did bisect the changes between 5.10.244 to 5.10.247 and found that the issue is introduced with 1550f3673972 ("net: rtnetlink: add bulk delete support flag") which is the backport to the 5.10.y series. On Thu, Dec 18, 2025 at 02:59:55PM +0100, Roland Schwarzkopf wrote: > Hi Salvatore, > > On 12/17/25 20:28, Salvatore Bonaccorso wrote: > > Hi Roland, > > > > I'm CC'ing Ben Hutchings directly as well as he takes care of the > > Debian LTS kernel updates. Idellly we make this as well a proper bug > > for easier tracking. > > > > On Wed, Dec 17, 2025 at 01:35:54PM +0100, Roland Schwarzkopf wrote: > > > Hi there, > > > > > > after upgrading to the latest kernel on Debian 11 > > > (linux-image-5.10.0-37-amd64) I have an issue using libvirt with qemu/kvm > > > virtual machines and macvtap networking. When a machine is shut down, > > > libvirt can not delete the corresponding macvtap device. Thus, starting the > > > machine again is not possible. After manually removing the macvtap device > > > using `ip link delete` the vm can be started again. > > > > > > In the journal the following message is shown: > > > > > > Dec 17 13:19:27 iblis libvirtd[535]: error destroying network device macvtap0: Operation not supported > > > > > > After downgrading the kernel to linux-image-5.10.0-36-amd64, the problem > > > disappears. I tested this on a fresh minimal install of Debian 11 - to > > > exclude that anything else on my production machines is causing this issue. > > > > > > Since the older kernel does not have this issue, I assume this is related to > > > the kernel and not to libvirt? > > > > > > I tried to check for bug reports of the kernel package, but the bug tracker > > > finds no reports and even states that the package does not exist (I used the > > > "Bug reports" link on > > > https://packages.debian.org/bullseye/linux-image-5.10.0-37-amd64). This left > > > me a bit puzzled. Since I don't have experience with the debian bug > > > reporting process, I had no other idea than writing to this list. > > You would need to search for inhttps://bugs.debian.org/src:linux , > > but that said I'm not aware of any bug reports in that direction. > > > > Would you be in the position of bisecting the problem as you can say > > that 5.10.244 is good and 5.10.247 is bad and regressed? If you can do > > that that would involve compiling a couple of kernels to narrow down > > where the problem is introduced: > > > > git clone --single-branch -b linux-5.10.yhttps://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-st… > > cd linux-stable > > git checkout v5.10.244 > > cp /boot/config-$(uname -r) .config > > yes '' | make localmodconfig > > make savedefconfig > > mv defconfig arch/x86/configs/my_defconfig > > > > # test 5.10.244 to ensure this is "good" > > make my_defconfig > > make -j $(nproc) bindeb-pkg > > ... install the resulting .deb package and confirm it successfully boots / problem does not exist > > > > # test 5.10.247 to ensure this is "bad" > > git checkout v5.10.247 > > make my_defconfig > > make -j $(nproc) bindeb-pkg > > ... install the resulting .deb package and confirm it fails to boot / problem exists > > > > With that confirmed, the bisection can start: > > > > git bisect start > > git bisect good v5.10.244 > > git bisect bad v5.10.247 > > > > In each bisection step git checks out a state between the oldest > > known-bad and the newest known-good commit. In each step test using: > > > > make my_defconfig > > make -j $(nproc) bindeb-pkg > > ... install, try to boot / verify if problem exists > > > > and if the problem is hit run: > > > > git bisect bad > > > > and if the problem doesn't trigger run: > > > > git bisect good > > > > . Please pay attention to always select the just built kernel for > > booting, it won't always be the default kernel picked up by grub. > > > > Iterate until git announces to have identified the first bad commit. > > > > Then provide the output of > > > > git bisect log > > > > In the course of the bisection you might have to uninstall previous > > kernels again to not exhaust the disk space in /boot. Also in the end > > uninstall all self-built kernels again. > > I just did my first bisection \o/ (sorry) > > Here are the results: > > git bisect start > # bad: [f964b940099f9982d723d4c77988d4b0dda9c165] Linux 5.10.247 > git bisect bad f964b940099f9982d723d4c77988d4b0dda9c165 > # good: [863b76df7d1e327979946a2d3893479c3275bfa4] Linux 5.10.244 > git bisect good f52ee6ea810273e527a5d319e5f400be8c8424c1 > # good: [dc9fdb7586b90e33c766eac52b6f3d1c9ec365a1] net: usb: lan78xx: Add error handling to lan78xx_init_mac_address > git bisect good dc9fdb7586b90e33c766eac52b6f3d1c9ec365a1 > # bad: [2272d5757ce5d3fb416d9f2497b015678eb85c0d] phy: cadence: cdns-dphy: Enable lower resolutions in dphy > git bisect bad 2272d5757ce5d3fb416d9f2497b015678eb85c0d > # bad: [547539f08b9e3629ce68479889813e58c8087e70] ALSA: usb-audio: fix control pipe direction > git bisect bad 547539f08b9e3629ce68479889813e58c8087e70 > # bad: [3509c748e79435d09e730673c8c100b7f0ebc87c] most: usb: hdm_probe: Fix calling put_device() before device initialization > git bisect bad 3509c748e79435d09e730673c8c100b7f0ebc87c > # bad: [a6ebcafc2f5ff7f0d1ce0c6dc38ac09a16a56ec0] net: add ndo_fdb_del_bulk > git bisect bad a6ebcafc2f5ff7f0d1ce0c6dc38ac09a16a56ec0 > # good: [b8a72692aa42b7dcd179a96b90bc2763ac74576a] hfsplus: fix KMSAN uninit-value issue in __hfsplus_ext_cache_extent() > git bisect good b8a72692aa42b7dcd179a96b90bc2763ac74576a > # good: [2b42a595863556b394bd702d46f4a9d0d2985aaa] m68k: bitops: Fix find_*_bit() signatures > git bisect good 2b42a595863556b394bd702d46f4a9d0d2985aaa > # good: [9d9f7d71d46cff3491a443a3cf452cecf87d51ef] net: rtnetlink: use BIT for flag values > git bisect good 9d9f7d71d46cff3491a443a3cf452cecf87d51ef > # bad: [1550f3673972c5cfba714135f8bf26784e6f2b0f] net: rtnetlink: add bulk delete support flag > git bisect bad 1550f3673972c5cfba714135f8bf26784e6f2b0f > # good: [c8879afa24169e504f78c9ca43a4d0d7397049eb] net: netlink: add NLM_F_BULK delete request modifier > git bisect good c8879afa24169e504f78c9ca43a4d0d7397049eb > # first bad commit: [1550f3673972c5cfba714135f8bf26784e6f2b0f] net: rtnetlink: add bulk delete support flag > > Is there anything else I can do to help? Is there soemthing missing? Roland I think it would be helpful if you can test as well more recent stable series versions to confirm if the issue is present there as well or not, which might indicate a 5.10.y specific backporting problem. #regzbot introduced: 1550f3673972c5cfba714135f8bf26784e6f2b0f Regards, Salvatore

1 hour, 11 minutes

3
2
0 0

[PATCH] ALSA: ac97: fix a double free in snd_ac97_controller_register()

by Haoxiang Li

If ac97_add_adapter() fails, put_device() is the correct way to drop the device reference. kfree() is not required. Add kfree() if idr_alloc() fails and in ac97_adapter_release() to do the cleanup. Found by code review. Fixes: 74426fbff66e ("ALSA: ac97: add an ac97 bus") Cc: stable(a)vger.kernel.org Signed-off-by: Haoxiang Li <lihaoxiang(a)isrc.iscas.ac.cn> --- sound/ac97/bus.c | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/sound/ac97/bus.c b/sound/ac97/bus.c index f4254703d29f..bb9b795e0226 100644 --- a/sound/ac97/bus.c +++ b/sound/ac97/bus.c @@ -298,6 +298,7 @@ static void ac97_adapter_release(struct device *dev) idr_remove(&ac97_adapter_idr, ac97_ctrl->nr); dev_dbg(&ac97_ctrl->adap, "adapter unregistered by %s\n", dev_name(ac97_ctrl->parent)); + kfree(ac97_ctrl); } static const struct device_type ac97_adapter_type = { @@ -319,7 +320,9 @@ static int ac97_add_adapter(struct ac97_controller *ac97_ctrl) ret = device_register(&ac97_ctrl->adap); if (ret) put_device(&ac97_ctrl->adap); - } + } else + kfree(ac97_ctrl); + if (!ret) { list_add(&ac97_ctrl->controllers, &ac97_controllers); dev_dbg(&ac97_ctrl->adap, "adapter registered by %s\n", @@ -361,14 +364,11 @@ struct ac97_controller *snd_ac97_controller_register( ret = ac97_add_adapter(ac97_ctrl); if (ret) - goto err; + return ERR_PTR(ret); ac97_bus_reset(ac97_ctrl); ac97_bus_scan(ac97_ctrl); return ac97_ctrl; -err: - kfree(ac97_ctrl); - return ERR_PTR(ret); } EXPORT_SYMBOL_GPL(snd_ac97_controller_register); -- 2.25.1

1 hour, 57 minutes

1
0
0 0

[PATCH] cpufreq: amd_freq_sensitivity: Fix sensitivity clamping in amd_powersave_bias_target

by Thorsten Blum

The local variable 'sensitivity' was never clamped to 0 or POWERSAVE_BIAS_MAX because the return value of clamp() was not used. Fix this by assigning the clamped value back to 'sensitivity'. Cc: stable(a)vger.kernel.org Fixes: 9c5320c8ea8b ("cpufreq: AMD "frequency sensitivity feedback" powersave bias for ondemand governor") Signed-off-by: Thorsten Blum <thorsten.blum(a)linux.dev> --- drivers/cpufreq/amd_freq_sensitivity.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/cpufreq/amd_freq_sensitivity.c b/drivers/cpufreq/amd_freq_sensitivity.c index 13fed4b9e02b..713ccf24c97d 100644 --- a/drivers/cpufreq/amd_freq_sensitivity.c +++ b/drivers/cpufreq/amd_freq_sensitivity.c @@ -76,7 +76,7 @@ static unsigned int amd_powersave_bias_target(struct cpufreq_policy *policy, sensitivity = POWERSAVE_BIAS_MAX - (POWERSAVE_BIAS_MAX * (d_reference - d_actual) / d_reference); - clamp(sensitivity, 0, POWERSAVE_BIAS_MAX); + sensitivity = clamp(sensitivity, 0, POWERSAVE_BIAS_MAX); /* this workload is not CPU bound, so choose a lower freq */ if (sensitivity < od_tuners->powersave_bias) { -- Thorsten Blum <thorsten.blum(a)linux.dev> GPG: 1D60 735E 8AEF 3BE4 73B6 9D84 7336 78FD 8DFE EAD4

2 hours, 31 minutes

2
2
0 0

[PATCH] usb: ulpi: fix a double free in ulpi_register_interface()

by Haoxiang Li

If ulpi_register() fails, put_device() is called in ulpi_register(), kfree() in ulpi_register_interface() will result in a double free. Also, refactor the device registration sequence to use a unified put_device() cleanup path, addressing multiple error returns in ulpi_register(). Found by code review and compiled on ubuntu 20.04. Fixes: 0a907ee9d95e ("usb: ulpi: Call of_node_put correctly") Cc: stable(a)vger.kernel.org Signed-off-by: Haoxiang Li <lihaoxiang(a)isrc.iscas.ac.cn> --- drivers/usb/common/ulpi.c | 25 ++++++++++++------------- 1 file changed, 12 insertions(+), 13 deletions(-) diff --git a/drivers/usb/common/ulpi.c b/drivers/usb/common/ulpi.c index 4a2ee447b213..c81a0cb24067 100644 --- a/drivers/usb/common/ulpi.c +++ b/drivers/usb/common/ulpi.c @@ -278,6 +278,7 @@ static int ulpi_register(struct device *dev, struct ulpi *ulpi) int ret; struct dentry *root; + device_initialize(&ulpi->dev); ulpi->dev.parent = dev; /* needed early for ops */ ulpi->dev.bus = &ulpi_bus; ulpi->dev.type = &ulpi_dev_type; @@ -287,19 +288,15 @@ static int ulpi_register(struct device *dev, struct ulpi *ulpi) ret = ulpi_of_register(ulpi); if (ret) - return ret; + goto err_register; ret = ulpi_read_id(ulpi); - if (ret) { - of_node_put(ulpi->dev.of_node); - return ret; - } + if (ret) + goto err_register; - ret = device_register(&ulpi->dev); - if (ret) { - put_device(&ulpi->dev); - return ret; - } + ret = device_add(&ulpi->dev); + if (ret) + goto err_register; root = debugfs_create_dir(dev_name(&ulpi->dev), ulpi_root); debugfs_create_file("regs", 0444, root, ulpi, &ulpi_regs_fops); @@ -308,6 +305,10 @@ static int ulpi_register(struct device *dev, struct ulpi *ulpi) ulpi->id.vendor, ulpi->id.product); return 0; + +err_register: + put_device(&ulpi->dev); + return ret; } /** @@ -331,10 +332,8 @@ struct ulpi *ulpi_register_interface(struct device *dev, ulpi->ops = ops; ret = ulpi_register(dev, ulpi); - if (ret) { - kfree(ulpi); + if (ret) return ERR_PTR(ret); - } return ulpi; } -- 2.25.1

2 hours, 37 minutes

1
0
0 0

[PATCH] drm/fsl-dcu: fix clock reference leak in fsl_tcon_init error path

by Miaoqian Lin

In fsl_tcon_init(), when of_clk_get_by_name() succeeds but clk_prepare_enable() fails, the function jumps to err_node_put label without releasing the clock reference obtained. This causes a clock reference leak. Fix by calling clk_put() that properly releases the clock reference. Found via static analysis and code review. Fixes: fb127b7943c9 ("drm/fsl-dcu: add TCON driver") Cc: stable(a)vger.kernel.org Signed-off-by: Miaoqian Lin <linmq006(a)gmail.com> --- drivers/gpu/drm/fsl-dcu/fsl_tcon.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/fsl-dcu/fsl_tcon.c b/drivers/gpu/drm/fsl-dcu/fsl_tcon.c index 49bbd00c77ae..b7ba90814b0e 100644 --- a/drivers/gpu/drm/fsl-dcu/fsl_tcon.c +++ b/drivers/gpu/drm/fsl-dcu/fsl_tcon.c @@ -86,7 +86,7 @@ struct fsl_tcon *fsl_tcon_init(struct device *dev) ret = clk_prepare_enable(tcon->ipg_clk); if (ret) { dev_err(dev, "Couldn't enable the TCON clock\n"); - goto err_node_put; + goto err_clk_put; } of_node_put(np); @@ -94,6 +94,8 @@ struct fsl_tcon *fsl_tcon_init(struct device *dev) return tcon; +err_clk_put: + clk_put(tcon->ipg_clk); err_node_put: of_node_put(np); return NULL; -- 2.25.1

3 hours, 5 minutes

1
0
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror