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

[PATCH] media: imagination: Fix value clamping in calculate_qp_tables

by Thorsten Blum

The local variable 'val' was never clamped to 1 or 255 because the return value of clamp() was not used. Fix this by assigning the clamped value back to 'val'. Cc: stable(a)vger.kernel.org Fixes: a1e294045885 ("media: imagination: Add E5010 JPEG Encoder driver") Signed-off-by: Thorsten Blum <thorsten.blum(a)linux.dev> --- drivers/media/platform/imagination/e5010-jpeg-enc.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/media/platform/imagination/e5010-jpeg-enc.c b/drivers/media/platform/imagination/e5010-jpeg-enc.c index c4e0097cb8b7..a36a2acc896c 100644 --- a/drivers/media/platform/imagination/e5010-jpeg-enc.c +++ b/drivers/media/platform/imagination/e5010-jpeg-enc.c @@ -175,12 +175,12 @@ static void calculate_qp_tables(struct e5010_context *ctx) long long delta = v4l2_jpeg_ref_table_chroma_qt[i] * contrast + luminosity; int val = (int)(v4l2_jpeg_ref_table_chroma_qt[i] + delta); - clamp(val, 1, 255); + val = clamp(val, 1, 255); ctx->chroma_qp[i] = quality == -50 ? 1 : val; delta = v4l2_jpeg_ref_table_luma_qt[i] * contrast + luminosity; val = (int)(v4l2_jpeg_ref_table_luma_qt[i] + delta); - clamp(val, 1, 255); + val = clamp(val, 1, 255); ctx->luma_qp[i] = quality == -50 ? 1 : val; } -- Thorsten Blum <thorsten.blum(a)linux.dev> GPG: 1D60 735E 8AEF 3BE4 73B6 9D84 7336 78FD 8DFE EAD4

5 days, 16 hours

1
1
0 0

[PATCH v2] mm/memory-failure: fix missing ->mf_stats count in hugetlb poison

by Jane Chu

When a newly poisoned subpage ends up in an already poisoned hugetlb folio, 'num_poisoned_pages' is incremented, but the per node ->mf_stats is not. Fix the inconsistency by designating action_result() to update them both. While at it, define __get_huge_page_for_hwpoison() return values in terms of symbol names for better readibility. Also rename folio_set_hugetlb_hwpoison() to hugetlb_update_hwpoison() since the function does more than the conventional bit setting and the fact three possible return values are expected. Fixes: 18f41fa616ee4 ("mm: memory-failure: bump memory failure stats to pglist_data") Cc: <stable(a)vger.kernel.org> Signed-off-by: Jane Chu <jane.chu(a)oracle.com> --- v1 -> v2: adapted David and Liam's comment, define __get_huge_page_for_hwpoison() return values in terms of symbol names instead of naked integers for better readibility. #define instead of enum is used since the function has footprint outside MF, just try to limit the MF specifics local. also renamed folio_set_hugetlb_hwpoison() to hugetlb_update_hwpoison() since the function does more than the conventional bit setting and the fact three possible return values are expected. --- mm/memory-failure.c | 56 ++++++++++++++++++++++++++------------------- 1 file changed, 33 insertions(+), 23 deletions(-) diff --git a/mm/memory-failure.c b/mm/memory-failure.c index 3edebb0cda30..3eb9d23a4ad0 100644 --- a/mm/memory-failure.c +++ b/mm/memory-failure.c @@ -1873,12 +1873,18 @@ static unsigned long __folio_free_raw_hwp(struct folio *folio, bool move_flag) return count; } -static int folio_set_hugetlb_hwpoison(struct folio *folio, struct page *page) +#define MF_HUGETLB_ALREADY_POISONED 3 /* already poisoned */ +#define MF_HUGETLB_ACC_EXISTING_POISON 4 /* accessed existing poisoned page */ +/* + * Set hugetlb folio as hwpoisoned, update folio private raw hwpoison list + * to keep track of the poisoned pages. + */ +static int hugetlb_update_hwpoison(struct folio *folio, struct page *page) { struct llist_head *head; struct raw_hwp_page *raw_hwp; struct raw_hwp_page *p; - int ret = folio_test_set_hwpoison(folio) ? -EHWPOISON : 0; + int ret = folio_test_set_hwpoison(folio) ? MF_HUGETLB_ALREADY_POISONED : 0; /* * Once the hwpoison hugepage has lost reliable raw error info, @@ -1886,20 +1892,18 @@ static int folio_set_hugetlb_hwpoison(struct folio *folio, struct page *page) * so skip to add additional raw error info. */ if (folio_test_hugetlb_raw_hwp_unreliable(folio)) - return -EHWPOISON; + return MF_HUGETLB_ALREADY_POISONED; + head = raw_hwp_list_head(folio); llist_for_each_entry(p, head->first, node) { if (p->page == page) - return -EHWPOISON; + return MF_HUGETLB_ACC_EXISTING_POISON; } raw_hwp = kmalloc(sizeof(struct raw_hwp_page), GFP_ATOMIC); if (raw_hwp) { raw_hwp->page = page; llist_add(&raw_hwp->node, head); - /* the first error event will be counted in action_result(). */ - if (ret) - num_poisoned_pages_inc(page_to_pfn(page)); } else { /* * Failed to save raw error info. We no longer trace all @@ -1945,32 +1949,30 @@ void folio_clear_hugetlb_hwpoison(struct folio *folio) folio_free_raw_hwp(folio, true); } +#define MF_HUGETLB_FREED 0 /* freed hugepage */ +#define MF_HUGETLB_IN_USED 1 /* in-use hugepage */ +#define MF_NOT_HUGETLB 2 /* not a hugepage */ + /* * Called from hugetlb code with hugetlb_lock held. - * - * Return values: - * 0 - free hugepage - * 1 - in-use hugepage - * 2 - not a hugepage - * -EBUSY - the hugepage is busy (try to retry) - * -EHWPOISON - the hugepage is already hwpoisoned */ int __get_huge_page_for_hwpoison(unsigned long pfn, int flags, bool *migratable_cleared) { struct page *page = pfn_to_page(pfn); struct folio *folio = page_folio(page); - int ret = 2; /* fallback to normal page handling */ + int ret = MF_NOT_HUGETLB; bool count_increased = false; + int rc; if (!folio_test_hugetlb(folio)) goto out; if (flags & MF_COUNT_INCREASED) { - ret = 1; + ret = MF_HUGETLB_IN_USED; count_increased = true; } else if (folio_test_hugetlb_freed(folio)) { - ret = 0; + ret = MF_HUGETLB_FREED; } else if (folio_test_hugetlb_migratable(folio)) { ret = folio_try_get(folio); if (ret) @@ -1981,8 +1983,9 @@ int __get_huge_page_for_hwpoison(unsigned long pfn, int flags, goto out; } - if (folio_set_hugetlb_hwpoison(folio, page)) { - ret = -EHWPOISON; + rc = hugetlb_update_hwpoison(folio, page); + if (rc >= MF_HUGETLB_ALREADY_POISONED) { + ret = rc; goto out; } @@ -2019,22 +2022,29 @@ static int try_memory_failure_hugetlb(unsigned long pfn, int flags, int *hugetlb *hugetlb = 1; retry: res = get_huge_page_for_hwpoison(pfn, flags, &migratable_cleared); - if (res == 2) { /* fallback to normal page handling */ + switch (res) { + case MF_NOT_HUGETLB: /* fallback to normal page handling */ *hugetlb = 0; return 0; - } else if (res == -EHWPOISON) { + case MF_HUGETLB_ALREADY_POISONED: + case MF_HUGETLB_ACC_EXISTING_POISON: if (flags & MF_ACTION_REQUIRED) { folio = page_folio(p); res = kill_accessing_process(current, folio_pfn(folio), flags); } - action_result(pfn, MF_MSG_ALREADY_POISONED, MF_FAILED); + if (res == MF_HUGETLB_ALREADY_POISONED) + action_result(pfn, MF_MSG_ALREADY_POISONED, MF_FAILED); + else + action_result(pfn, MF_MSG_HUGE, MF_FAILED); return res; - } else if (res == -EBUSY) { + case -EBUSY: if (!(flags & MF_NO_RETRY)) { flags |= MF_NO_RETRY; goto retry; } return action_result(pfn, MF_MSG_GET_HWPOISON, MF_IGNORED); + default: + break; } folio = page_folio(p); -- 2.43.5

5 days, 19 hours

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

5 days, 20 hours

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

5 days, 20 hours

1
0
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

5 days, 21 hours

3
2
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

5 days, 23 hours

1
0
0 0

[PATCH] enclosure: fix a api misuse in enclosure_register()

by Haoxiang Li

If device_register() fails, put_device() is the correct way to drop the device reference. Found by code review. Fixes: ee959b00c335 ("SCSI: convert struct class_device to struct device") Cc: stable(a)vger.kernel.org Signed-off-by: Haoxiang Li <lihaoxiang(a)isrc.iscas.ac.cn> --- drivers/misc/enclosure.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/misc/enclosure.c b/drivers/misc/enclosure.c index ca4c420e4a2f..f7f72856d697 100644 --- a/drivers/misc/enclosure.c +++ b/drivers/misc/enclosure.c @@ -149,7 +149,7 @@ enclosure_register(struct device *dev, const char *name, int components, err: put_device(edev->edev.parent); - kfree(edev); + put_device(&edev->edev); return ERR_PTR(err); } EXPORT_SYMBOL_GPL(enclosure_register); -- 2.25.1

5 days, 23 hours

1
0
0 0

[PATCH v3 0/8] ASoC: SOF: ipoc4: Support for generic bytes controls

by Peter Ujfalusi

Hi, Changes since v2: - correct the fixes tag for the second path Changes since v1: - correct SHAs for fixes tags - add Cc stable tag We support bytes control type for set and get, but these are module specific controls and there is no way to handle notifications from them in a generic way. Each control have module specific param_id and this param_id is only valid in the module's scope, other modules might use the same id for different functions for example. This series will add a new generic control type, similar to the existing ones for ENUM and SWITCH, which can be used to create bytes controls which can send notifications from firmware on change. The new param_id is 202 and the sof_ipc4_control_msg_payload is updated to describe bytes payload also. On set, the payload must include the sof_ipc4_control_msg_payload struct with the control's ID and data size, followed by the data. On get, the kernel needs to send the sof_ipc4_control_msg_payload struct along with the LARGE_CONFIG_GET message as payload with the ID of the control that needs to be retrieved. The raw data is received back without additional header. A notification might contain data, in this case the num_elems reflects the size in bytes, or without data. If no data is received then the control is marked as dirty and on read the kernel will refresh the data from firmware. The series includes mandatory fixes for existing code and adds support for sending payload with LARGE_CONFIG_GET when the param_id is either generic ENUM, SWITCH or BYTES control. Regards, Peter --- Peter Ujfalusi (8): ASoC: SOF: ipc4-control: If there is no data do not send bytes update ASoC: SOF: ipc4-topology: Correct the allocation size for bytes controls ASoC: SOF: ipc4-control: Use the correct size for scontrol->ipc_control_data ASoC: SOF: ipc4-control: Keep the payload size up to date ASoC: SOF: ipc4-topology: Set initial param_id for bytes control type ASoC: SOF: ipc4: Support for sending payload along with LARGE_CONFIG_GET ASoC: SOF: ipc4: Add definition for generic bytes control ASoC: SOF: ipc4-control: Add support for generic bytes control sound/soc/sof/ipc4-control.c | 197 ++++++++++++++++++++++++++++++---- sound/soc/sof/ipc4-topology.c | 36 +++++-- sound/soc/sof/ipc4-topology.h | 9 +- sound/soc/sof/ipc4.c | 45 +++++++- 4 files changed, 252 insertions(+), 35 deletions(-) -- 2.52.0

6 days

2
9
0 0

[PATCH v2 0/8] ASoC: SOF: ipoc4: Support for generic bytes controls

by Peter Ujfalusi

Hi, Changes since v1: - correct SHAs for fixes tags - add Cc stable tag We support bytes control type for set and get, but these are module specific controls and there is no way to handle notifications from them in a generic way. Each control have module specific param_id and this param_id is only valid in the module's scope, other modules might use the same id for different functions for example. This series will add a new generic control type, similar to the existing ones for ENUM and SWITCH, which can be used to create bytes controls which can send notifications from firmware on change. The new param_id is 202 and the sof_ipc4_control_msg_payload is updated to describe bytes payload also. On set, the payload must include the sof_ipc4_control_msg_payload struct with the control's ID and data size, followed by the data. On get, the kernel needs to send the sof_ipc4_control_msg_payload struct along with the LARGE_CONFIG_GET message as payload with the ID of the control that needs to be retrieved. The raw data is received back without additional header. A notification might contain data, in this case the num_elems reflects the size in bytes, or without data. If no data is received then the control is marked as dirty and on read the kernel will refresh the data from firmware. The series includes mandatory fixes for existing code and adds support for sending payload with LARGE_CONFIG_GET when the param_id is either generic ENUM, SWITCH or BYTES control. Regards, Peter --- Peter Ujfalusi (8): ASoC: SOF: ipc4-control: If there is no data do not send bytes update ASoC: SOF: ipc4-topology: Correct the allocation size for bytes controls ASoC: SOF: ipc4-control: Use the correct size for scontrol->ipc_control_data ASoC: SOF: ipc4-control: Keep the payload size up to date ASoC: SOF: ipc4-topology: Set initial param_id for bytes control type ASoC: SOF: ipc4: Support for sending payload along with LARGE_CONFIG_GET ASoC: SOF: ipc4: Add definition for generic bytes control ASoC: SOF: ipc4-control: Add support for generic bytes control sound/soc/sof/ipc4-control.c | 197 ++++++++++++++++++++++++++++++---- sound/soc/sof/ipc4-topology.c | 36 +++++-- sound/soc/sof/ipc4-topology.h | 9 +- sound/soc/sof/ipc4.c | 45 +++++++- 4 files changed, 252 insertions(+), 35 deletions(-) -- 2.52.0

6 days

3
12
0 0

[PATCH] drm/amdgpu: don't attach the tlb fence for SI

by Hans de Goede

From: Alex Deucher <alexander.deucher(a)amd.com> commit eb296c09805ee37dd4ea520a7fb3ec157c31090f upstream. SI hardware doesn't support pasids, user mode queues, or KIQ/MES so there is no need for this. Doing so results in a segfault as these callbacks are non-existent for SI. Closes: https://gitlab.freedesktop.org/drm/amd/-/issues/4744 Fixes: f3854e04b708 ("drm/amdgpu: attach tlb fence to the PTs update") Reviewed-by: Timur Kristóf <timur.kristof(a)gmail.com> Signed-off-by: Alex Deucher <alexander.deucher(a)amd.com> Signed-off-by: Hans de Goede <johannes.goede(a)oss.qualcomm.com> --- drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c index 676e24fb8864..cdcafde3c71a 100644 --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c @@ -1066,7 +1066,9 @@ amdgpu_vm_tlb_flush(struct amdgpu_vm_update_params *params, } /* Prepare a TLB flush fence to be attached to PTs */ - if (!params->unlocked) { + if (!params->unlocked && + /* SI doesn't support pasid or KIQ/MES */ + params->adev->family > AMDGPU_FAMILY_SI) { amdgpu_vm_tlb_fence_create(params->adev, vm, fence); /* Makes sure no PD/PT is freed before the flush */ -- 2.52.0

6 days

3
5
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror