December 2023 - Linux-stable-mirror

[PATCH v4 0/4] x86/cacheinfo: Set the number of leaves per CPU

by Ricardo Neri

Hi, The interface /sys/devices/system/cpu/cpuX/cache is broken (not populated) if CPUs have different numbers of subleaves in CPUID 4. This is the case of Intel Meteor Lake. This is v4 of a patchset to fix the cache sysfs interface by setting the number of cache leaves independently for each CPU. v1, v2, and v3 can be found here[1], here[2], and here[3]. All the tests described in [4] passed. Changes since v3: * Fixed another NULL-pointer dereference when checking the validity of the last-level cache info. * Added the Reviewed-by tags from Radu and Sudeep. Thanks! * Rebased on v6.7-rc5. Changes since v2: * This version uncovered a NULL-pointer dereference in recent changes to cacheinfo[5]. This dereference is observed when the system does not configure cacheinfo early during boot nor makes corrections later during CPU hotplug; as is the case in x86. Patch 1 fixes this issue. Changes since v1: * Dave Hansen suggested to use the existing per-CPU ci_cpu_cacheinfo variable. Now the global variable num_cache_leaves became useless. * While here, I noticed that init_cache_level() also became useless: x86 does not need ci_cpu_cacheinfo::num_levels. Thanks and BR, Ricardo [1]. https://lore.kernel.org/lkml/20230314231658.30169-1-ricardo.neri-calderon@l… [2]. https://lore.kernel.org/all/20230424001956.21434-1-ricardo.neri-calderon@li… [3]. https://lore.kernel.org/lkml/20230805012421.7002-1-ricardo.neri-calderon@li… [4]. https://lore.kernel.org/lkml/20230912032350.GA17008@ranerica-svr.sc.intel.c… [5]. https://lore.kernel.org/all/20230412185759.755408-1-rrendec@redhat.com/ Ricardo Neri (4): cacheinfo: Check for null last-level cache info cacheinfo: Allocate memory for memory if not done from the primary CPU x86/cacheinfo: Delete global num_cache_leaves x86/cacheinfo: Clean out init_cache_level() arch/x86/kernel/cpu/cacheinfo.c | 49 +++++++++++++++++---------------- drivers/base/cacheinfo.c | 9 +++++- 2 files changed, 34 insertions(+), 24 deletions(-) -- 2.25.1

3 months, 2 weeks

2
8
0 0

[PATCH v2 1/2] EDAC/device_sysfs: Fix calling kobject_put() with ->state_initialized unset

by Harshit Mogalapalli

In edac_device_register_sysfs_main_kobj(), when dev_root is NULL, kobject_init_and_add() is not called. if (err) { // err = -ENODEV edac_dbg(1, "Failed to register '.../edac/%s'\n", edac_dev->name); goto err_kobj_reg; // This calls kobj_put() } This will cause a runtime warning in kobject_put() if the above happens. Warning: "kobject: '%s' (%p): is not initialized, yet kobject_put() is being called." Fix the error handling to avoid the above possible situation. Cc: <stable(a)vger.kernel.org> Fixes: cb4a0bec0bb9 ("EDAC/sysfs: move to use bus_get_dev_root()") Signed-off-by: Harshit Mogalapalli <harshit.m.mogalapalli(a)oracle.com> --- This is based on static analysis and only compile tested. v1->v2: Resend as a patchset as they are two similar bugs. --- drivers/edac/edac_device_sysfs.c | 14 ++++++++------ 1 file changed, 8 insertions(+), 6 deletions(-) diff --git a/drivers/edac/edac_device_sysfs.c b/drivers/edac/edac_device_sysfs.c index 010c26be5846..4cac14cbdb60 100644 --- a/drivers/edac/edac_device_sysfs.c +++ b/drivers/edac/edac_device_sysfs.c @@ -253,11 +253,13 @@ int edac_device_register_sysfs_main_kobj(struct edac_device_ctl_info *edac_dev) /* register */ dev_root = bus_get_dev_root(edac_subsys); - if (dev_root) { - err = kobject_init_and_add(&edac_dev->kobj, &ktype_device_ctrl, - &dev_root->kobj, "%s", edac_dev->name); - put_device(dev_root); - } + if (!dev_root) + goto module_put; + + err = kobject_init_and_add(&edac_dev->kobj, &ktype_device_ctrl, + &dev_root->kobj, "%s", edac_dev->name); + put_device(dev_root); + if (err) { edac_dbg(1, "Failed to register '.../edac/%s'\n", edac_dev->name); @@ -276,8 +278,8 @@ int edac_device_register_sysfs_main_kobj(struct edac_device_ctl_info *edac_dev) /* Error exit stack */ err_kobj_reg: kobject_put(&edac_dev->kobj); +module_put: module_put(edac_dev->owner); - err_out: return err; } -- 2.42.0

3 months, 2 weeks

2
4
0 0

[PATCH] firmware: arm_scmi: Check Mailbox/SMT channel for consistency

by Cristian Marussi

On reception of a completion interrupt the SMT memory area is accessed to retrieve the message header at first and then, if the message sequence number identifies a transaction which is still pending, the related payload is fetched too. When an SCMI command times out the channel ownership remains with the platform until eventually a late reply is received and, as a consequence, any further transmission attempt remains pending, waiting for the channel to be relinquished by the platform. Once that late reply is received the channel ownership is given back to the agent and any pending request is then allowed to proceed and overwrite the SMT area of the just delivered late reply; then the wait for the reply to the new request starts. It has been observed that the spurious IRQ related to the late reply can be wrongly associated with the freshly enqueued request: when that happens the SCMI stack in-flight lookup procedure is fooled by the fact that the message header now present in the SMT area is related to the new pending transaction, even though the real reply has still to arrive. This race-condition on the A2P channel can be detected by looking at the channel status bits: a genuine reply from the platform will have set the channel free bit before triggering the completion IRQ. Add a consistency check to validate such condition in the A2P ISR. Reported-by: Xinglong Yang <xinglong.yang(a)cixtech.com> Closes: https://lore.kernel.org/all/PUZPR06MB54981E6FA00D82BFDBB864FBF08DA@PUZPR06M… Fixes: 5c8a47a5a91d ("firmware: arm_scmi: Make scmi core independent of the transport type") CC: stable(a)vger.kernel.org # 5.15+ Signed-off-by: Cristian Marussi <cristian.marussi(a)arm.com> --- drivers/firmware/arm_scmi/common.h | 1 + drivers/firmware/arm_scmi/mailbox.c | 14 ++++++++++++++ drivers/firmware/arm_scmi/shmem.c | 6 ++++++ 3 files changed, 21 insertions(+) diff --git a/drivers/firmware/arm_scmi/common.h b/drivers/firmware/arm_scmi/common.h index 3b7c68a11fd0..0956c2443840 100644 --- a/drivers/firmware/arm_scmi/common.h +++ b/drivers/firmware/arm_scmi/common.h @@ -329,6 +329,7 @@ void shmem_fetch_notification(struct scmi_shared_mem __iomem *shmem, void shmem_clear_channel(struct scmi_shared_mem __iomem *shmem); bool shmem_poll_done(struct scmi_shared_mem __iomem *shmem, struct scmi_xfer *xfer); +bool shmem_channel_free(struct scmi_shared_mem __iomem *shmem); /* declarations for message passing transports */ struct scmi_msg_payld; diff --git a/drivers/firmware/arm_scmi/mailbox.c b/drivers/firmware/arm_scmi/mailbox.c index 19246ed1f01f..b8d470417e8f 100644 --- a/drivers/firmware/arm_scmi/mailbox.c +++ b/drivers/firmware/arm_scmi/mailbox.c @@ -45,6 +45,20 @@ static void rx_callback(struct mbox_client *cl, void *m) { struct scmi_mailbox *smbox = client_to_scmi_mailbox(cl); + /* + * An A2P IRQ is NOT valid when received while the platform still has + * the ownership of the channel, because the platform at first releases + * the SMT channel and then sends the completion interrupt. + * + * This addresses a possible race condition in which a spurious IRQ from + * a previous timed-out reply which arrived late could be wrongly + * associated with the next pending transaction. + */ + if (cl->knows_txdone && !shmem_channel_free(smbox->shmem)) { + dev_warn(smbox->cinfo->dev, "Ignoring spurious A2P IRQ !\n"); + return; + } + scmi_rx_callback(smbox->cinfo, shmem_read_header(smbox->shmem), NULL); } diff --git a/drivers/firmware/arm_scmi/shmem.c b/drivers/firmware/arm_scmi/shmem.c index 87b4f4d35f06..517d52fb3bcb 100644 --- a/drivers/firmware/arm_scmi/shmem.c +++ b/drivers/firmware/arm_scmi/shmem.c @@ -122,3 +122,9 @@ bool shmem_poll_done(struct scmi_shared_mem __iomem *shmem, (SCMI_SHMEM_CHAN_STAT_CHANNEL_ERROR | SCMI_SHMEM_CHAN_STAT_CHANNEL_FREE); } + +bool shmem_channel_free(struct scmi_shared_mem __iomem *shmem) +{ + return (ioread32(&shmem->channel_status) & + SCMI_SHMEM_CHAN_STAT_CHANNEL_FREE); +} -- 2.34.1

3 months, 2 weeks

3
5
0 0

[PATCH AUTOSEL 4.14 1/6] clk: rockchip: rk3128: Fix HCLK_OTG gate register

by Sasha Levin

From: Weihao Li <cn.liweihao(a)gmail.com> [ Upstream commit c6c5a5580dcb6631aa6369dabe12ef3ce784d1d2 ] The HCLK_OTG gate control is in CRU_CLKGATE5_CON, not CRU_CLKGATE3_CON. Signed-off-by: Weihao Li <cn.liweihao(a)gmail.com> Link: https://lore.kernel.org/r/20231031111816.8777-1-cn.liweihao@gmail.com Signed-off-by: Heiko Stuebner <heiko(a)sntech.de> Signed-off-by: Sasha Levin <sashal(a)kernel.org> --- drivers/clk/rockchip/clk-rk3128.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/clk/rockchip/clk-rk3128.c b/drivers/clk/rockchip/clk-rk3128.c index 5970a50671b9a..83c7eb18321f4 100644 --- a/drivers/clk/rockchip/clk-rk3128.c +++ b/drivers/clk/rockchip/clk-rk3128.c @@ -497,7 +497,7 @@ static struct rockchip_clk_branch common_clk_branches[] __initdata = { GATE(HCLK_I2S_2CH, "hclk_i2s_2ch", "hclk_peri", 0, RK2928_CLKGATE_CON(7), 2, GFLAGS), GATE(0, "hclk_usb_peri", "hclk_peri", CLK_IGNORE_UNUSED, RK2928_CLKGATE_CON(9), 13, GFLAGS), GATE(HCLK_HOST2, "hclk_host2", "hclk_peri", 0, RK2928_CLKGATE_CON(7), 3, GFLAGS), - GATE(HCLK_OTG, "hclk_otg", "hclk_peri", 0, RK2928_CLKGATE_CON(3), 13, GFLAGS), + GATE(HCLK_OTG, "hclk_otg", "hclk_peri", 0, RK2928_CLKGATE_CON(5), 13, GFLAGS), GATE(0, "hclk_peri_ahb", "hclk_peri", CLK_IGNORE_UNUSED, RK2928_CLKGATE_CON(9), 14, GFLAGS), GATE(HCLK_SPDIF, "hclk_spdif", "hclk_peri", 0, RK2928_CLKGATE_CON(10), 9, GFLAGS), GATE(HCLK_TSP, "hclk_tsp", "hclk_peri", 0, RK2928_CLKGATE_CON(10), 12, GFLAGS), -- 2.43.0

3 months, 3 weeks

3
8
0 0

[PATCH v2 1/2] usb: dwc3: host: Set XHCI_SG_TRB_CACHE_SIZE_QUIRK

by Prashanth K

Upstream commit bac1ec551434 ("usb: xhci: Set quirk for XHCI_SG_TRB_CACHE_SIZE_QUIRK") introduced a new quirk in XHCI which fixes XHC timeout, which was seen on synopsys XHCs while using SG buffers. But the support for this quirk isn't present in the DWC3 layer. We will encounter this XHCI timeout/hung issue if we run iperf loopback tests using RTL8156 ethernet adaptor on DWC3 targets with scatter-gather enabled. This gets resolved after enabling the XHCI_SG_TRB_CACHE_SIZE_QUIRK. This patch enables it using the xhci device property since its needed for DWC3 controller. In Synopsys DWC3 databook, Table 9-3: xHCI Debug Capability Limitations Chained TRBs greater than TRB cache size: The debug capability driver must not create a multi-TRB TD that describes smaller than a 1K packet that spreads across 8 or more TRBs on either the IN TR or the OUT TR. Cc: <stable(a)vger.kernel.org> Signed-off-by: Prashanth K <quic_prashk(a)quicinc.com> --- drivers/usb/dwc3/host.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/usb/dwc3/host.c b/drivers/usb/dwc3/host.c index 61f57fe5bb78..31a496233d87 100644 --- a/drivers/usb/dwc3/host.c +++ b/drivers/usb/dwc3/host.c @@ -89,6 +89,8 @@ int dwc3_host_init(struct dwc3 *dwc) memset(props, 0, sizeof(struct property_entry) * ARRAY_SIZE(props)); + props[prop_idx++] = PROPERTY_ENTRY_BOOL("xhci-sg-trb-cache-size-quirk"); + if (dwc->usb3_lpm_capable) props[prop_idx++] = PROPERTY_ENTRY_BOOL("usb3-lpm-capable"); -- 2.25.1

3 months, 3 weeks

4
8
0 0

[PATCH AUTOSEL 4.14 1/6] reset: hisilicon: hi6220: fix Wvoid-pointer-to-enum-cast warning

by Sasha Levin

From: Krzysztof Kozlowski <krzysztof.kozlowski(a)linaro.org> [ Upstream commit b5ec294472794ed9ecba0cb4b8208372842e7e0d ] 'type' is an enum, thus cast of pointer on 64-bit compile test with W=1 causes: hi6220_reset.c:166:9: error: cast to smaller integer type 'enum hi6220_reset_ctrl_type' from 'const void *' [-Werror,-Wvoid-pointer-to-enum-cast] Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski(a)linaro.org> Link: https://lore.kernel.org/r/20230810091300.70197-1-krzysztof.kozlowski@linaro… Signed-off-by: Philipp Zabel <p.zabel(a)pengutronix.de> Signed-off-by: Sasha Levin <sashal(a)kernel.org> --- drivers/reset/hisilicon/hi6220_reset.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/reset/hisilicon/hi6220_reset.c b/drivers/reset/hisilicon/hi6220_reset.c index d5e5229308f22..d77a7ad7e57a7 100644 --- a/drivers/reset/hisilicon/hi6220_reset.c +++ b/drivers/reset/hisilicon/hi6220_reset.c @@ -107,7 +107,7 @@ static int hi6220_reset_probe(struct platform_device *pdev) if (!data) return -ENOMEM; - type = (enum hi6220_reset_ctrl_type)of_device_get_match_data(dev); + type = (uintptr_t)of_device_get_match_data(dev); regmap = syscon_node_to_regmap(np); if (IS_ERR(regmap)) { -- 2.43.0

3 months, 3 weeks

2
7
0 0

[PATCH AUTOSEL 4.19 1/7] reset: hisilicon: hi6220: fix Wvoid-pointer-to-enum-cast warning

by Sasha Levin

From: Krzysztof Kozlowski <krzysztof.kozlowski(a)linaro.org> [ Upstream commit b5ec294472794ed9ecba0cb4b8208372842e7e0d ] 'type' is an enum, thus cast of pointer on 64-bit compile test with W=1 causes: hi6220_reset.c:166:9: error: cast to smaller integer type 'enum hi6220_reset_ctrl_type' from 'const void *' [-Werror,-Wvoid-pointer-to-enum-cast] Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski(a)linaro.org> Link: https://lore.kernel.org/r/20230810091300.70197-1-krzysztof.kozlowski@linaro… Signed-off-by: Philipp Zabel <p.zabel(a)pengutronix.de> Signed-off-by: Sasha Levin <sashal(a)kernel.org> --- drivers/reset/hisilicon/hi6220_reset.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/reset/hisilicon/hi6220_reset.c b/drivers/reset/hisilicon/hi6220_reset.c index d5e5229308f22..d77a7ad7e57a7 100644 --- a/drivers/reset/hisilicon/hi6220_reset.c +++ b/drivers/reset/hisilicon/hi6220_reset.c @@ -107,7 +107,7 @@ static int hi6220_reset_probe(struct platform_device *pdev) if (!data) return -ENOMEM; - type = (enum hi6220_reset_ctrl_type)of_device_get_match_data(dev); + type = (uintptr_t)of_device_get_match_data(dev); regmap = syscon_node_to_regmap(np); if (IS_ERR(regmap)) { -- 2.43.0

3 months, 3 weeks

3
9
0 0

[PATCH mm-unstable v1 1/4] mm/mglru: fix underprotected page cache

by Yu Zhao

Unmapped folios accessed through file descriptors can be underprotected. Those folios are added to the oldest generation based on: 1. The fact that they are less costly to reclaim (no need to walk the rmap and flush the TLB) and have less impact on performance (don't cause major PFs and can be non-blocking if needed again). 2. The observation that they are likely to be single-use. E.g., for client use cases like Android, its apps parse configuration files and store the data in heap (anon); for server use cases like MySQL, it reads from InnoDB files and holds the cached data for tables in buffer pools (anon). However, the oldest generation can be very short lived, and if so, it doesn't provide the PID controller with enough time to respond to a surge of refaults. (Note that the PID controller uses weighted refaults and those from evicted generations only take a half of the whole weight.) In other words, for a short lived generation, the moving average smooths out the spike quickly. To fix the problem: 1. For folios that are already on LRU, if they can be beyond the tracking range of tiers, i.e., five accesses through file descriptors, move them to the second oldest generation to give them more time to age. (Note that tiers are used by the PID controller to statistically determine whether folios accessed multiple times through file descriptors are worth protecting.) 2. When adding unmapped folios to LRU, adjust the placement of them so that they are not too close to the tail. The effect of this is similar to the above. On Android, launching 55 apps sequentially: Before After Change workingset_refault_anon 25641024 25598972 0% workingset_refault_file 115016834 106178438 -8% Fixes: ac35a4902374 ("mm: multi-gen LRU: minimal implementation") Signed-off-by: Yu Zhao <yuzhao(a)google.com> Reported-by: Charan Teja Kalla <quic_charante(a)quicinc.com> Tested-by: Kalesh Singh <kaleshsingh(a)google.com> Cc: stable(a)vger.kernel.org --- include/linux/mm_inline.h | 23 ++++++++++++++--------- mm/vmscan.c | 2 +- mm/workingset.c | 6 +++--- 3 files changed, 18 insertions(+), 13 deletions(-) diff --git a/include/linux/mm_inline.h b/include/linux/mm_inline.h index 9ae7def16cb2..f4fe593c1400 100644 --- a/include/linux/mm_inline.h +++ b/include/linux/mm_inline.h @@ -232,22 +232,27 @@ static inline bool lru_gen_add_folio(struct lruvec *lruvec, struct folio *folio, if (folio_test_unevictable(folio) || !lrugen->enabled) return false; /* - * There are three common cases for this page: - * 1. If it's hot, e.g., freshly faulted in or previously hot and - * migrated, add it to the youngest generation. - * 2. If it's cold but can't be evicted immediately, i.e., an anon page - * not in swapcache or a dirty page pending writeback, add it to the - * second oldest generation. - * 3. Everything else (clean, cold) is added to the oldest generation. + * There are four common cases for this page: + * 1. If it's hot, i.e., freshly faulted in, add it to the youngest + * generation, and it's protected over the rest below. + * 2. If it can't be evicted immediately, i.e., a dirty page pending + * writeback, add it to the second youngest generation. + * 3. If it should be evicted first, e.g., cold and clean from + * folio_rotate_reclaimable(), add it to the oldest generation. + * 4. Everything else falls between 2 & 3 above and is added to the + * second oldest generation if it's considered inactive, or the + * oldest generation otherwise. See lru_gen_is_active(). */ if (folio_test_active(folio)) seq = lrugen->max_seq; else if ((type == LRU_GEN_ANON && !folio_test_swapcache(folio)) || (folio_test_reclaim(folio) && (folio_test_dirty(folio) || folio_test_writeback(folio)))) - seq = lrugen->min_seq[type] + 1; - else + seq = lrugen->max_seq - 1; + else if (reclaiming || lrugen->min_seq[type] + MIN_NR_GENS >= lrugen->max_seq) seq = lrugen->min_seq[type]; + else + seq = lrugen->min_seq[type] + 1; gen = lru_gen_from_seq(seq); flags = (gen + 1UL) << LRU_GEN_PGOFF; diff --git a/mm/vmscan.c b/mm/vmscan.c index 4e3b835c6b4a..e67631c60ac0 100644 --- a/mm/vmscan.c +++ b/mm/vmscan.c @@ -4260,7 +4260,7 @@ static bool sort_folio(struct lruvec *lruvec, struct folio *folio, struct scan_c } /* protected */ - if (tier > tier_idx) { + if (tier > tier_idx || refs == BIT(LRU_REFS_WIDTH)) { int hist = lru_hist_from_seq(lrugen->min_seq[type]); gen = folio_inc_gen(lruvec, folio, false); diff --git a/mm/workingset.c b/mm/workingset.c index 7d3dacab8451..2a2a34234df9 100644 --- a/mm/workingset.c +++ b/mm/workingset.c @@ -313,10 +313,10 @@ static void lru_gen_refault(struct folio *folio, void *shadow) * 1. For pages accessed through page tables, hotter pages pushed out * hot pages which refaulted immediately. * 2. For pages accessed multiple times through file descriptors, - * numbers of accesses might have been out of the range. + * they would have been protected by sort_folio(). */ - if (lru_gen_in_fault() || refs == BIT(LRU_REFS_WIDTH)) { - folio_set_workingset(folio); + if (lru_gen_in_fault() || refs >= BIT(LRU_REFS_WIDTH) - 1) { + set_mask_bits(&folio->flags, 0, LRU_REFS_MASK | BIT(PG_workingset)); mod_lruvec_state(lruvec, WORKINGSET_RESTORE_BASE + type, delta); } unlock: -- 2.43.0.472.g3155946c3a-goog

3 months, 4 weeks

3
30
0 0

[PATCH v2 6/6] s390/vfio-ap: do not reset queue removed from host config

by Tony Krowiak

When a queue is unbound from the vfio_ap device driver, it is reset to ensure its crypto data is not leaked when it is bound to another device driver. If the queue is unbound due to the fact that the adapter or domain was removed from the host's AP configuration, then attempting to reset it will fail with response code 01 (APID not valid) getting returned from the reset command. Let's ensure that the queue is assigned to the host's configuration before resetting it. Signed-off-by: Tony Krowiak <akrowiak(a)linux.ibm.com> Fixes: eeb386aeb5b7 ("s390/vfio-ap: handle config changed and scan complete notification") Cc: <stable(a)vger.kernel.org> --- drivers/s390/crypto/vfio_ap_ops.c | 14 ++++++++++++-- 1 file changed, 12 insertions(+), 2 deletions(-) diff --git a/drivers/s390/crypto/vfio_ap_ops.c b/drivers/s390/crypto/vfio_ap_ops.c index e014108067dc..84decb0d5c97 100644 --- a/drivers/s390/crypto/vfio_ap_ops.c +++ b/drivers/s390/crypto/vfio_ap_ops.c @@ -2197,6 +2197,8 @@ void vfio_ap_mdev_remove_queue(struct ap_device *apdev) q = dev_get_drvdata(&apdev->device); get_update_locks_for_queue(q); matrix_mdev = q->matrix_mdev; + apid = AP_QID_CARD(q->apqn); + apqi = AP_QID_QUEUE(q->apqn); if (matrix_mdev) { /* If the queue is assigned to the guest's AP configuration */ @@ -2214,8 +2216,16 @@ void vfio_ap_mdev_remove_queue(struct ap_device *apdev) } } - vfio_ap_mdev_reset_queue(q); - flush_work(&q->reset_work); + /* + * If the queue is not in the host's AP configuration, then resetting + * it will fail with response code 01, (APQN not valid); so, let's make + * sure it is in the host's config. + */ + if (test_bit_inv(apid, (unsigned long *)matrix_dev->info.apm) && + test_bit_inv(apqi, (unsigned long *)matrix_dev->info.aqm)) { + vfio_ap_mdev_reset_queue(q); + flush_work(&q->reset_work); + } done: if (matrix_mdev) -- 2.43.0

3 months, 4 weeks

3
2
0 0

FAILED: patch "[PATCH] fuse: nlookup missing decrement in fuse_direntplus_link" failed to apply to 4.19-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 4.19-stable tree. If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to <stable(a)vger.kernel.org>. 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-4.19.y git checkout FETCH_HEAD git cherry-pick -x b8bd342d50cbf606666488488f9fea374aceb2d5 # <resolve conflicts, build, test, etc.> git commit -s git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '2023091601-spotted-untie-0ba4@gregkh' --subject-prefix 'PATCH 4.19.y' HEAD^.. Possible dependencies: b8bd342d50cb ("fuse: nlookup missing decrement in fuse_direntplus_link") d123d8e1833c ("fuse: split out readdir.c") thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From b8bd342d50cbf606666488488f9fea374aceb2d5 Mon Sep 17 00:00:00 2001 From: ruanmeisi <ruan.meisi(a)zte.com.cn> Date: Tue, 25 Apr 2023 19:13:54 +0800 Subject: [PATCH] fuse: nlookup missing decrement in fuse_direntplus_link During our debugging of glusterfs, we found an Assertion failed error: inode_lookup >= nlookup, which was caused by the nlookup value in the kernel being greater than that in the FUSE file system. The issue was introduced by fuse_direntplus_link, where in the function, fuse_iget increments nlookup, and if d_splice_alias returns failure, fuse_direntplus_link returns failure without decrementing nlookup https://github.com/gluster/glusterfs/pull/4081 Signed-off-by: ruanmeisi <ruan.meisi(a)zte.com.cn> Fixes: 0b05b18381ee ("fuse: implement NFS-like readdirplus support") Cc: <stable(a)vger.kernel.org> # v3.9 Signed-off-by: Miklos Szeredi <mszeredi(a)redhat.com> diff --git a/fs/fuse/readdir.c b/fs/fuse/readdir.c index dc603479b30e..b3d498163f97 100644 --- a/fs/fuse/readdir.c +++ b/fs/fuse/readdir.c @@ -243,8 +243,16 @@ static int fuse_direntplus_link(struct file *file, dput(dentry); dentry = alias; } - if (IS_ERR(dentry)) + if (IS_ERR(dentry)) { + if (!IS_ERR(inode)) { + struct fuse_inode *fi = get_fuse_inode(inode); + + spin_lock(&fi->lock); + fi->nlookup--; + spin_unlock(&fi->lock); + } return PTR_ERR(dentry); + } } if (fc->readdirplus_auto) set_bit(FUSE_I_INIT_RDPLUS, &get_fuse_inode(inode)->state);

3 months, 4 weeks

3
2
0 0

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror December 2023