March 2024 - Linux-stable-mirror

FAILED: patch "[PATCH] crash: use macro to add crashk_res into iomem early for" failed to apply to 6.7-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 6.7-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.7.y git checkout FETCH_HEAD git cherry-pick -x 32fbe5246582af4f611ccccee33fd6e559087252 # <resolve conflicts, build, test, etc.> git commit -s git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '2024033006-laptop-tassel-b290@gregkh' --subject-prefix 'PATCH 6.7.y' HEAD^.. Possible dependencies: 32fbe5246582 ("crash: use macro to add crashk_res into iomem early for specific arch") 85fcde402db1 ("kexec: split crashkernel reservation code out from crash_core.c") 4a693ce65b18 ("kdump: defer the insertion of crashkernel resources") 29166371ef67 ("kdump: remove redundant DEFAULT_CRASH_KERNEL_LOW_SIZE") thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From 32fbe5246582af4f611ccccee33fd6e559087252 Mon Sep 17 00:00:00 2001 From: Baoquan He <bhe(a)redhat.com> Date: Mon, 25 Mar 2024 09:50:50 +0800 Subject: [PATCH] crash: use macro to add crashk_res into iomem early for specific arch There are regression reports[1][2] that crashkernel region on x86_64 can't be added into iomem tree sometime. This causes the later failure of kdump loading. This happened after commit 4a693ce65b18 ("kdump: defer the insertion of crashkernel resources") was merged. Even though, these reported issues are proved to be related to other component, they are just exposed after above commmit applied, I still would like to keep crashk_res and crashk_low_res being added into iomem early as before because the early adding has been always there on x86_64 and working very well. For safety of kdump, Let's change it back. Here, add a macro HAVE_ARCH_ADD_CRASH_RES_TO_IOMEM_EARLY to limit that only ARCH defining the macro can have the early adding crashk_res/_low_res into iomem. Then define HAVE_ARCH_ADD_CRASH_RES_TO_IOMEM_EARLY on x86 to enable it. Note: In reserve_crashkernel_low(), there's a remnant of crashk_low_res handling which was mistakenly added back in commit 85fcde402db1 ("kexec: split crashkernel reservation code out from crash_core.c"). [1] [PATCH V2] x86/kexec: do not update E820 kexec table for setup_data https://lore.kernel.org/all/Zfv8iCL6CT2JqLIC@darkstar.users.ipa.redhat.com/… [2] Question about Address Range Validation in Crash Kernel Allocation https://lore.kernel.org/all/4eeac1f733584855965a2ea62fa4da58@huawei.com/T/#u Link: https://lkml.kernel.org/r/ZgDYemRQ2jxjLkq+@MiWiFi-R3L-srv Fixes: 4a693ce65b18 ("kdump: defer the insertion of crashkernel resources") Signed-off-by: Baoquan He <bhe(a)redhat.com> Cc: Dave Young <dyoung(a)redhat.com> Cc: Huacai Chen <chenhuacai(a)loongson.cn> Cc: Ingo Molnar <mingo(a)kernel.org> Cc: Jiri Bohac <jbohac(a)suse.cz> Cc: Li Huafei <lihuafei1(a)huawei.com> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> diff --git a/arch/x86/include/asm/crash_reserve.h b/arch/x86/include/asm/crash_reserve.h index 152239f95541..7835b2cdff04 100644 --- a/arch/x86/include/asm/crash_reserve.h +++ b/arch/x86/include/asm/crash_reserve.h @@ -39,4 +39,6 @@ static inline unsigned long crash_low_size_default(void) #endif } +#define HAVE_ARCH_ADD_CRASH_RES_TO_IOMEM_EARLY + #endif /* _X86_CRASH_RESERVE_H */ diff --git a/kernel/crash_reserve.c b/kernel/crash_reserve.c index bbb6c3cb00e4..066668799f75 100644 --- a/kernel/crash_reserve.c +++ b/kernel/crash_reserve.c @@ -366,7 +366,9 @@ static int __init reserve_crashkernel_low(unsigned long long low_size) crashk_low_res.start = low_base; crashk_low_res.end = low_base + low_size - 1; +#ifdef HAVE_ARCH_ADD_CRASH_RES_TO_IOMEM_EARLY insert_resource(&iomem_resource, &crashk_low_res); +#endif #endif return 0; } @@ -448,8 +450,12 @@ void __init reserve_crashkernel_generic(char *cmdline, crashk_res.start = crash_base; crashk_res.end = crash_base + crash_size - 1; +#ifdef HAVE_ARCH_ADD_CRASH_RES_TO_IOMEM_EARLY + insert_resource(&iomem_resource, &crashk_res); +#endif } +#ifndef HAVE_ARCH_ADD_CRASH_RES_TO_IOMEM_EARLY static __init int insert_crashkernel_resources(void) { if (crashk_res.start < crashk_res.end) @@ -462,3 +468,4 @@ static __init int insert_crashkernel_resources(void) } early_initcall(insert_crashkernel_resources); #endif +#endif

1 year

1
0
0 0

[PATCH STABLE v4.19.y] mm/migrate: set swap entry values of THP tail pages properly.

by Zi Yan

From: Zi Yan <ziy(a)nvidia.com> The tail pages in a THP can have swap entry information stored in their private field. When migrating to a new page, all tail pages of the new page need to update ->private to avoid future data corruption. This fix is stable-only, since after commit 07e09c483cbe ("mm/huge_memory: work on folio->swap instead of page->private when splitting folio"), subpages of a swapcached THP no longer requires the maintenance. Adding THPs to the swapcache was introduced in commit 38d8b4e6bdc87 ("mm, THP, swap: delay splitting THP during swap out"), where each subpage of a THP added to the swapcache had its own swapcache entry and required the ->private field to point to the correct swapcache entry. Later, when THP migration functionality was implemented in commit 616b8371539a6 ("mm: thp: enable thp migration in generic path"), it initially did not handle the subpages of swapcached THPs, failing to update their ->private fields or replace the subpage pointers in the swapcache. Subsequently, commit e71769ae5260 ("mm: enable thp migration for shmem thp") addressed the swapcache update aspect. This patch fixes the update of subpage ->private fields. Closes: https://lore.kernel.org/linux-mm/1707814102-22682-1-git-send-email-quic_cha… Fixes: 616b8371539a ("mm: thp: enable thp migration in generic path") Signed-off-by: Zi Yan <ziy(a)nvidia.com> Acked-by: David Hildenbrand <david(a)redhat.com> --- mm/migrate.c | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/mm/migrate.c b/mm/migrate.c index 171573613c39..893ea04498f7 100644 --- a/mm/migrate.c +++ b/mm/migrate.c @@ -514,8 +514,12 @@ int migrate_page_move_mapping(struct address_space *mapping, if (PageSwapBacked(page)) { __SetPageSwapBacked(newpage); if (PageSwapCache(page)) { + int i; + SetPageSwapCache(newpage); - set_page_private(newpage, page_private(page)); + for (i = 0; i < (1 << compound_order(page)); i++) + set_page_private(newpage + i, + page_private(page + i)); } } else { VM_BUG_ON_PAGE(PageSwapCache(page), page); -- 2.43.0

1 year

2
1
0 0

[PATCH v3] mtd: limit OTP NVMEM Cell parse to non Nand devices

by Christian Marangi

MTD OTP logic is very fragile and can be problematic with some specific kind of devices. NVMEM across the years had various iteration on how Cells could be declared in DT and MTD OTP probably was left behind and add_legacy_fixed_of_cells was enabled without thinking of the consequences. That option enables NVMEM to scan the provided of_node and treat each child as a NVMEM Cell, this was to support legacy NVMEM implementation and don't cause regression. This is problematic if we have devices like Nand where the OTP is triggered by setting a special mode in the flash. In this context real partitions declared in the Nand node are registered as OTP Cells and this cause probe fail with -EINVAL error. This was never notice due to the fact that till now, no Nand supported the OTP feature. With commit e87161321a40 ("mtd: rawnand: macronix: OTP access for MX30LFxG18AC") this changed and coincidentally this Nand is used on an FritzBox 7530 supported on OpenWrt. Alternative and more robust way to declare OTP Cells are already prossible by using the fixed-layout node or by declaring a child node with the compatible set to "otp-user" or "otp-factory". To fix this and limit any regression with other MTD that makes use of declaring OTP as direct child of the dev node, disable add_legacy_fixed_of_cells if we detect the MTD type is Nand. With the following logic, the OTP NVMEM entry is correctly created with no Cells and the MTD Nand is correctly probed and partitions are correctly exposed. Fixes: 2cc3b37f5b6d ("nvmem: add explicit config option to read old syntax fixed OF cells") Cc: <stable(a)vger.kernel.org> Signed-off-by: Christian Marangi <ansuelsmth(a)gmail.com> --- drivers/mtd/mtdcore.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/mtd/mtdcore.c b/drivers/mtd/mtdcore.c index 5887feb347a4..0de87bc63840 100644 --- a/drivers/mtd/mtdcore.c +++ b/drivers/mtd/mtdcore.c @@ -900,7 +900,7 @@ static struct nvmem_device *mtd_otp_nvmem_register(struct mtd_info *mtd, config.name = compatible; config.id = NVMEM_DEVID_AUTO; config.owner = THIS_MODULE; - config.add_legacy_fixed_of_cells = true; + config.add_legacy_fixed_of_cells = !mtd_type_is_nand(mtd); config.type = NVMEM_TYPE_OTP; config.root_only = true; config.ignore_wp = true; -- 2.43.0

1 year

3
10
0 0

[PATCH stable-5.10] mm/memory-failure: fix an incorrect use of tail pages

by Liu Shixin

When backport commit c79c5a0a00a9 to 5.10-stable, there is a mistake change. The head page instead of tail page should be passed to try_to_unmap(), otherwise unmap will failed as follows. Memory failure: 0x121c10: failed to unmap page (mapcount=1) Memory failure: 0x121c10: recovery action for unmapping failed page: Ignored Fixes: 70168fdc743b ("mm/memory-failure: check the mapcount of the precise page") Signed-off-by: Liu Shixin <liushixin2(a)huawei.com> --- mm/memory-failure.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/mm/memory-failure.c b/mm/memory-failure.c index f320ff02cc19..dba2936292cf 100644 --- a/mm/memory-failure.c +++ b/mm/memory-failure.c @@ -1075,7 +1075,7 @@ static bool hwpoison_user_mappings(struct page *p, unsigned long pfn, unmap_success = false; } } else { - unmap_success = try_to_unmap(p, ttu); + unmap_success = try_to_unmap(hpage, ttu); } } if (!unmap_success) -- 2.25.1

1 year

3
4
0 0

[PATCH stable 5.10 5.15 v2] serial: sc16is7xx: convert from _raw_ to _noinc_ regmap functions for FIFO

by GONG, Ruiqi

From: Hugo Villeneuve <hvilleneuve(a)dimonoff.com> commit dbf4ab821804df071c8b566d9813083125e6d97b upstream. The SC16IS7XX IC supports a burst mode to access the FIFOs where the initial register address is sent ($00), followed by all the FIFO data without having to resend the register address each time. In this mode, the IC doesn't increment the register address for each R/W byte. The regmap_raw_read() and regmap_raw_write() are functions which can perform IO over multiple registers. They are currently used to read/write from/to the FIFO, and although they operate correctly in this burst mode on the SPI bus, they would corrupt the regmap cache if it was not disabled manually. The reason is that when the R/W size is more than 1 byte, these functions assume that the register address is incremented and handle the cache accordingly. Convert FIFO R/W functions to use the regmap _noinc_ versions in order to remove the manual cache control which was a workaround when using the _raw_ versions. FIFO registers are properly declared as volatile so cache will not be used/updated for FIFO accesses. Fixes: dfeae619d781 ("serial: sc16is7xx") Cc: <stable(a)vger.kernel.org> # 5.10 5.15 Signed-off-by: Hugo Villeneuve <hvilleneuve(a)dimonoff.com> Link: https://lore.kernel.org/r/20231211171353.2901416-6-hugo@hugovil.com Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Cc: Hugo Villeneuve <hvilleneuve(a)dimonoff.com> Signed-off-by: GONG, Ruiqi <gongruiqi1(a)huawei.com> --- v2: Backport to both 5.15 and 5.10 The mainline commit dbf4ab821804 ("serial: sc16is7xx: convert from _raw_ to _noinc_ regmap functions for FIFO") by Hugo has been assigned to be CVE-2023-52488, but for stable branches lower than 6.1 there's no official backport. I made up this backport patch for 5.10, and its correctness has been confirmed in previous communication with Hugo. Let's publicize it and merge it into upstream. drivers/tty/serial/sc16is7xx.c | 15 +++++++++------ 1 file changed, 9 insertions(+), 6 deletions(-) diff --git a/drivers/tty/serial/sc16is7xx.c b/drivers/tty/serial/sc16is7xx.c index 8c09c97f9814..0066a0e23516 100644 --- a/drivers/tty/serial/sc16is7xx.c +++ b/drivers/tty/serial/sc16is7xx.c @@ -376,9 +376,7 @@ static void sc16is7xx_fifo_read(struct uart_port *port, unsigned int rxlen) const u8 line = sc16is7xx_line(port); u8 addr = (SC16IS7XX_RHR_REG << SC16IS7XX_REG_SHIFT) | line; - regcache_cache_bypass(s->regmap, true); - regmap_raw_read(s->regmap, addr, s->buf, rxlen); - regcache_cache_bypass(s->regmap, false); + regmap_noinc_read(s->regmap, addr, s->buf, rxlen); } static void sc16is7xx_fifo_write(struct uart_port *port, u8 to_send) @@ -394,9 +392,7 @@ static void sc16is7xx_fifo_write(struct uart_port *port, u8 to_send) if (unlikely(!to_send)) return; - regcache_cache_bypass(s->regmap, true); - regmap_raw_write(s->regmap, addr, s->buf, to_send); - regcache_cache_bypass(s->regmap, false); + regmap_noinc_write(s->regmap, addr, s->buf, to_send); } static void sc16is7xx_port_update(struct uart_port *port, u8 reg, @@ -489,6 +485,11 @@ static bool sc16is7xx_regmap_precious(struct device *dev, unsigned int reg) return false; } +static bool sc16is7xx_regmap_noinc(struct device *dev, unsigned int reg) +{ + return reg == SC16IS7XX_RHR_REG; +} + static int sc16is7xx_set_baud(struct uart_port *port, int baud) { struct sc16is7xx_port *s = dev_get_drvdata(port->dev); @@ -1439,6 +1440,8 @@ static struct regmap_config regcfg = { .cache_type = REGCACHE_RBTREE, .volatile_reg = sc16is7xx_regmap_volatile, .precious_reg = sc16is7xx_regmap_precious, + .writeable_noinc_reg = sc16is7xx_regmap_noinc, + .readable_noinc_reg = sc16is7xx_regmap_noinc, }; #ifdef CONFIG_SERIAL_SC16IS7XX_SPI -- 2.25.1

1 year

2
1
0 0

[PATCH -stable-6.1 resend 1/4] x86/coco: Export cc_vendor

by Ard Biesheuvel

From: "Borislav Petkov (AMD)" <bp(a)alien8.de> [ Commit 3d91c537296794d5d0773f61abbe7b63f2f132d8 upstream ] It will be used in different checks in future changes. Export it directly and provide accessor functions and stubs so this can be used in general code when CONFIG_ARCH_HAS_CC_PLATFORM is not set. No functional changes. [ tglx: Add accessor functions ] Signed-off-by: Borislav Petkov (AMD) <bp(a)alien8.de> Signed-off-by: Thomas Gleixner <tglx(a)linutronix.de> Link: https://lore.kernel.org/r/20230318115634.9392-2-bp@alien8.de Signed-off-by: Ard Biesheuvel <ardb(a)kernel.org> --- arch/x86/coco/core.c | 13 ++++------- arch/x86/include/asm/coco.h | 23 +++++++++++++++++--- 2 files changed, 24 insertions(+), 12 deletions(-) diff --git a/arch/x86/coco/core.c b/arch/x86/coco/core.c index 49b44f881484..684f0a910475 100644 --- a/arch/x86/coco/core.c +++ b/arch/x86/coco/core.c @@ -13,7 +13,7 @@ #include <asm/coco.h> #include <asm/processor.h> -static enum cc_vendor vendor __ro_after_init; +enum cc_vendor cc_vendor __ro_after_init; static u64 cc_mask __ro_after_init; static bool intel_cc_platform_has(enum cc_attr attr) @@ -83,7 +83,7 @@ static bool hyperv_cc_platform_has(enum cc_attr attr) bool cc_platform_has(enum cc_attr attr) { - switch (vendor) { + switch (cc_vendor) { case CC_VENDOR_AMD: return amd_cc_platform_has(attr); case CC_VENDOR_INTEL: @@ -105,7 +105,7 @@ u64 cc_mkenc(u64 val) * - for AMD, bit *set* means the page is encrypted * - for Intel *clear* means encrypted. */ - switch (vendor) { + switch (cc_vendor) { case CC_VENDOR_AMD: return val | cc_mask; case CC_VENDOR_INTEL: @@ -118,7 +118,7 @@ u64 cc_mkenc(u64 val) u64 cc_mkdec(u64 val) { /* See comment in cc_mkenc() */ - switch (vendor) { + switch (cc_vendor) { case CC_VENDOR_AMD: return val & ~cc_mask; case CC_VENDOR_INTEL: @@ -129,11 +129,6 @@ u64 cc_mkdec(u64 val) } EXPORT_SYMBOL_GPL(cc_mkdec); -__init void cc_set_vendor(enum cc_vendor v) -{ - vendor = v; -} - __init void cc_set_mask(u64 mask) { cc_mask = mask; diff --git a/arch/x86/include/asm/coco.h b/arch/x86/include/asm/coco.h index 3d98c3a60d34..91b9448ffe76 100644 --- a/arch/x86/include/asm/coco.h +++ b/arch/x86/include/asm/coco.h @@ -11,13 +11,30 @@ enum cc_vendor { CC_VENDOR_INTEL, }; -void cc_set_vendor(enum cc_vendor v); -void cc_set_mask(u64 mask); - #ifdef CONFIG_ARCH_HAS_CC_PLATFORM +extern enum cc_vendor cc_vendor; + +static inline enum cc_vendor cc_get_vendor(void) +{ + return cc_vendor; +} + +static inline void cc_set_vendor(enum cc_vendor vendor) +{ + cc_vendor = vendor; +} + +void cc_set_mask(u64 mask); u64 cc_mkenc(u64 val); u64 cc_mkdec(u64 val); #else +static inline enum cc_vendor cc_get_vendor(void) +{ + return CC_VENDOR_NONE; +} + +static inline void cc_set_vendor(enum cc_vendor vendor) { } + static inline u64 cc_mkenc(u64 val) { return val; -- 2.44.0.478.gd926399ef9-goog

1 year

3
7
0 0

[PATCH 6.1.y 0/7] vfio: Interrupt eventfd hardening for 6.6.y

by Alex Williamson

This corrects the backport of commit fe9a7082684e ("vfio/pci: Disable auto-enable of exclusive INTx IRQ"), choosing to adapt the fix to the current tree which uses an array of eventfd contexts rather than include a base patch for the conversion to xarray, which is found to be faulty in isolation. I include the reverts here for completeness, but if the associated commits are otherwise already dropped due to previous report[1], the remainder of this series is still valid. Largely this just adapts the mainline commits to the eventfd context array from the current internal API where they're stored in an xarray. Thanks, Alex [1]https://lore.kernel.org/all/20240329110433.156ff56c.alex.williamson@redha… Alex Williamson (7): Revert "vfio/pci: Disable auto-enable of exclusive INTx IRQ" Revert "vfio/pci: Prepare for dynamic interrupt context storage" vfio/pci: Disable auto-enable of exclusive INTx IRQ vfio: Introduce interface to flush virqfd inject workqueue vfio/pci: Create persistent INTx handler vfio/platform: Create persistent IRQ handlers vfio/fsl-mc: Block calling interrupt handler without trigger drivers/vfio/fsl-mc/vfio_fsl_mc_intr.c | 7 +- drivers/vfio/pci/vfio_pci_intrs.c | 318 +++++++++------------- drivers/vfio/platform/vfio_platform_irq.c | 101 ++++--- drivers/vfio/virqfd.c | 21 ++ include/linux/vfio.h | 2 + 5 files changed, 220 insertions(+), 229 deletions(-) -- 2.44.0

1 year

2
10
0 0

Re: Patch "vfio/pci: Prepare for dynamic interrupt context storage" has been added to the 6.1-stable tree

by Alex Williamson

On Wed, 27 Mar 2024 07:41:33 -0400 Sasha Levin <sashal(a)kernel.org> wrote: > This is a note to let you know that I've just added the patch titled > > vfio/pci: Prepare for dynamic interrupt context storage > > to the 6.1-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: > vfio-pci-prepare-for-dynamic-interrupt-context-stora.patch > and it can be found in the queue-6.1 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. > > > > commit bca808da62c6a87ef168554caa318c2801d19b70 > Author: Reinette Chatre <reinette.chatre(a)intel.com> > Date: Thu May 11 08:44:30 2023 -0700 > > vfio/pci: Prepare for dynamic interrupt context storage > > [ Upstream commit d977e0f7663961368f6442589e52d27484c2f5c2 ] > > Interrupt context storage is statically allocated at the time > interrupts are allocated. Following allocation, the interrupt > context is managed by directly accessing the elements of the > array using the vector as index. > > It is possible to allocate additional MSI-X vectors after > MSI-X has been enabled. Dynamic storage of interrupt context > is needed to support adding new MSI-X vectors after initial > allocation. > > Replace direct access of array elements with pointers to the > array elements. Doing so reduces impact of moving to a new data > structure. Move interactions with the array to helpers to > mostly contain changes needed to transition to a dynamic > data structure. > > No functional change intended. > > Signed-off-by: Reinette Chatre <reinette.chatre(a)intel.com> > Reviewed-by: Kevin Tian <kevin.tian(a)intel.com> > Acked-by: Thomas Gleixner <tglx(a)linutronix.de> > Reviewed-by: Jason Gunthorpe <jgg(a)nvidia.com> > Link: https://lore.kernel.org/r/eab289693c8325ede9aba99380f8b8d5143980a4.16837406… > Signed-off-by: Alex Williamson <alex.williamson(a)redhat.com> > Stable-dep-of: fe9a7082684e ("vfio/pci: Disable auto-enable of exclusive INTx IRQ") > Signed-off-by: Sasha Levin <sashal(a)kernel.org> ... > @@ -171,15 +225,24 @@ static irqreturn_t vfio_intx_handler(int irq, void *dev_id) > > static int vfio_intx_enable(struct vfio_pci_core_device *vdev) > { > + struct vfio_pci_irq_ctx *ctx; > + int ret; > + > if (!is_irq_none(vdev)) > return -EINVAL; > > if (!vdev->pdev->irq) > return -ENODEV; > > - vdev->ctx = kzalloc(sizeof(struct vfio_pci_irq_ctx), GFP_KERNEL_ACCOUNT); > - if (!vdev->ctx) > - return -ENOMEM; > + ret = vfio_irq_ctx_alloc_num(vdev, 1); > + if (ret) > + return ret; > + > + ctx = vfio_irq_ctx_get(vdev, 0); > + if (!ctx) { > + vfio_irq_ctx_free_all(vdev); > + return -EINVAL; > + } > > vdev->num_ctx = 1; This is broken on it's own, vfio_irq_ctx_get() depends on a valid num_ctx, therefore this function always returns -EINVAL. This was resolved upstream by b156e48fffa9 ("vfio/pci: Use xarray for interrupt context storage") which was from the same series, so this issue was never apparent upstream. Suggest dropping this and fe9a7082684e ("vfio/pci: Disable auto-enable of exclusive INTx IRQ") for now and we'll try to rework the latter to remove the dependency. Thanks, Alex

1 year

2
1
0 0

FAILED: patch "[PATCH] selftests: mptcp: diag: return KSFT_FAIL not test_cnt" 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 45bcc0346561daa3f59e19a753cc7f3e08e8dff1 # <resolve conflicts, build, test, etc.> git commit -s git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '2024032713-identity-slightly-586d@gregkh' --subject-prefix 'PATCH 5.15.y' HEAD^.. Possible dependencies: 45bcc0346561 ("selftests: mptcp: diag: return KSFT_FAIL not test_cnt") ce9902573652 ("selftests: mptcp: diag: format subtests results in TAP") dc97251bf0b7 ("selftests: mptcp: diag: skip listen tests if not supported") e04a30f78809 ("selftest: mptcp: add test for mptcp socket in use") 42fb6cddec3b ("selftests: mptcp: more stable diag tests") f2ae0fa68e28 ("selftests/mptcp: add diag listen tests") 0cd33c5ffec1 ("selftests: mptcp: fix diag instability") thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From 45bcc0346561daa3f59e19a753cc7f3e08e8dff1 Mon Sep 17 00:00:00 2001 From: Geliang Tang <tanggeliang(a)kylinos.cn> Date: Fri, 1 Mar 2024 18:11:22 +0100 Subject: [PATCH] selftests: mptcp: diag: return KSFT_FAIL not test_cnt The test counter 'test_cnt' should not be returned in diag.sh, e.g. what if only the 4th test fail? Will do 'exit 4' which is 'exit ${KSFT_SKIP}', the whole test will be marked as skipped instead of 'failed'! So we should do ret=${KSFT_FAIL} instead. Fixes: df62f2ec3df6 ("selftests/mptcp: add diag interface tests") Cc: stable(a)vger.kernel.org Fixes: 42fb6cddec3b ("selftests: mptcp: more stable diag tests") Signed-off-by: Geliang Tang <tanggeliang(a)kylinos.cn> Reviewed-by: Matthieu Baerts (NGI0) <matttbe(a)kernel.org> Signed-off-by: Matthieu Baerts (NGI0) <matttbe(a)kernel.org> Signed-off-by: David S. Miller <davem(a)davemloft.net> diff --git a/tools/testing/selftests/net/mptcp/diag.sh b/tools/testing/selftests/net/mptcp/diag.sh index f300f4e1eb59..18d37d4695c1 100755 --- a/tools/testing/selftests/net/mptcp/diag.sh +++ b/tools/testing/selftests/net/mptcp/diag.sh @@ -69,7 +69,7 @@ __chk_nr() else echo "[ fail ] expected $expected found $nr" mptcp_lib_result_fail "${msg}" - ret=$test_cnt + ret=${KSFT_FAIL} fi else echo "[ ok ]" @@ -124,11 +124,11 @@ wait_msk_nr() if [ $i -ge $timeout ]; then echo "[ fail ] timeout while expecting $expected max $max last $nr" mptcp_lib_result_fail "${msg} # timeout" - ret=$test_cnt + ret=${KSFT_FAIL} elif [ $nr != $expected ]; then echo "[ fail ] expected $expected found $nr" mptcp_lib_result_fail "${msg} # unexpected result" - ret=$test_cnt + ret=${KSFT_FAIL} else echo "[ ok ]" mptcp_lib_result_pass "${msg}"

1 year

3
2
0 0

[PATCH 5.10] nvme: use nvme_cid to generate command_id in trace event

by Li Lingfeng

From: Li Lingfeng <lilingfeng3(a)huawei.com> A null-ptr-deref problem may occur since commit 706960d328f5 ("nvme: use command_id instead of req->tag in trace_nvme_complete_rq()") tries to get command_id by nvme_req(req)->cmd while nvme_req(req)->cmd is NULL. The problem has been sloved since the patch has been reverted by commit 929ba86476b3. However, cmd->common.command_id is set to req->tag again which should be ((genctl & 0xf)< 12 | req->tag). Generating command_id by nvme_cid() in trace event instead of nvme_req(req)->cmd->common.command_id to set it to ((genctl & 0xf)< 12 | req->tag) without trigging the null-ptr-deref problem. Fixes: commit 706960d328f5 ("nvme: use command_id instead of req->tag in trace_nvme_complete_rq()") Reported-by: John Sperbeck <jsperbeck(a)google.com> Link: https://lore.kernel.org/r/20240109181722.228783-1-jsperbeck@google.com Signed-off-by: Li Lingfeng <lilingfeng3(a)huawei.com> --- drivers/nvme/host/trace.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/nvme/host/trace.h b/drivers/nvme/host/trace.h index 700fdce2ecf1..0de057a298dd 100644 --- a/drivers/nvme/host/trace.h +++ b/drivers/nvme/host/trace.h @@ -98,7 +98,7 @@ TRACE_EVENT(nvme_complete_rq, TP_fast_assign( __entry->ctrl_id = nvme_req(req)->ctrl->instance; __entry->qid = nvme_req_qid(req); - __entry->cid = req->tag; + __entry->cid = nvme_cid(req); __entry->result = le64_to_cpu(nvme_req(req)->result.u64); __entry->retries = nvme_req(req)->retries; __entry->flags = nvme_req(req)->flags; -- 2.31.1

1 year

3
3
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror March 2024