August 2024 - Linux-stable-mirror

[PATCH 6.1.y 2/2 V2] KVM: x86: Fix lapic timer interrupt lost after loading a snapshot.

by David Hunter

From: Haitao Shan <hshan(a)google.com> When running android emulator (which is based on QEMU 2.12) on certain Intel hosts with kernel version 6.3-rc1 or above, guest will freeze after loading a snapshot. This is almost 100% reproducible. By default, the android emulator will use snapshot to speed up the next launching of the same android guest. So this breaks the android emulator badly. I tested QEMU 8.0.4 from Debian 12 with an Ubuntu 22.04 guest by running command "loadvm" after "savevm". The same issue is observed. At the same time, none of our AMD platforms is impacted. More experiments show that loading the KVM module with "enable_apicv=false" can workaround it. The issue started to show up after commit 8e6ed96cdd50 ("KVM: x86: fire timer when it is migrated and expired, and in oneshot mode"). However, as is pointed out by Sean Christopherson, it is introduced by commit 967235d32032 ("KVM: vmx: clear pending interrupts on KVM_SET_LAPIC"). commit 8e6ed96cdd50 ("KVM: x86: fire timer when it is migrated and expired, and in oneshot mode") just makes it easier to hit the issue. Having both commits, the oneshot lapic timer gets fired immediately inside the KVM_SET_LAPIC call when loading the snapshot. On Intel platforms with APIC virtualization and posted interrupt processing, this eventually leads to setting the corresponding PIR bit. However, the whole PIR bits get cleared later in the same KVM_SET_LAPIC call by apicv_post_state_restore. This leads to timer interrupt lost. The fix is to move vmx_apicv_post_state_restore to the beginning of the KVM_SET_LAPIC call and rename to vmx_apicv_pre_state_restore. What vmx_apicv_post_state_restore does is actually clearing any former apicv state and this behavior is more suitable to carry out in the beginning. Fixes: 967235d32032 ("KVM: vmx: clear pending interrupts on KVM_SET_LAPIC") Cc: stable(a)vger.kernel.org Suggested-by: Sean Christopherson <seanjc(a)google.com> Signed-off-by: Haitao Shan <hshan(a)google.com> Link: https://lore.kernel.org/r/20230913000215.478387-1-hshan@google.com Signed-off-by: Sean Christopherson <seanjc(a)google.com> Signed-off-by: David Hunter <david.hunter.linux(a)gmail.com> --- arch/x86/kvm/vmx/vmx.c | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/x86/kvm/vmx/vmx.c b/arch/x86/kvm/vmx/vmx.c index 87abf4eebf8a..4040075bbd5a 100644 --- a/arch/x86/kvm/vmx/vmx.c +++ b/arch/x86/kvm/vmx/vmx.c @@ -8203,6 +8203,7 @@ static struct kvm_x86_ops vmx_x86_ops __initdata = { .load_eoi_exitmap = vmx_load_eoi_exitmap, .apicv_pre_state_restore = vmx_apicv_pre_state_restore, .check_apicv_inhibit_reasons = vmx_check_apicv_inhibit_reasons, + .required_apicv_inhibits = VMX_REQUIRED_APICV_INHIBITS, .hwapic_irr_update = vmx_hwapic_irr_update, .hwapic_isr_update = vmx_hwapic_isr_update, .guest_apic_has_interrupt = vmx_guest_apic_has_interrupt, -- 2.43.0

8 months, 1 week

1
1
0 0

[PATCH v2 2/7] media: sun4i_csi: Implement link validate for sun4i_csi subdev

by Laurent Pinchart

The sun4i_csi driver doesn't implement link validation for the subdev it registers, leaving the link between the subdev and its source unvalidated. Fix it, using the v4l2_subdev_link_validate() helper. Fixes: 577bbf23b758 ("media: sunxi: Add A10 CSI driver") Cc: stable(a)vger.kernel.org Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas(a)ideasonboard.com> Acked-by: Chen-Yu Tsai <wens(a)csie.org> --- drivers/media/platform/sunxi/sun4i-csi/sun4i_csi.c | 5 +++++ 1 file changed, 5 insertions(+) diff --git a/drivers/media/platform/sunxi/sun4i-csi/sun4i_csi.c b/drivers/media/platform/sunxi/sun4i-csi/sun4i_csi.c index 097a3a08ef7d..dbb26c7b2f8d 100644 --- a/drivers/media/platform/sunxi/sun4i-csi/sun4i_csi.c +++ b/drivers/media/platform/sunxi/sun4i-csi/sun4i_csi.c @@ -39,6 +39,10 @@ static const struct media_entity_operations sun4i_csi_video_entity_ops = { .link_validate = v4l2_subdev_link_validate, }; +static const struct media_entity_operations sun4i_csi_subdev_entity_ops = { + .link_validate = v4l2_subdev_link_validate, +}; + static int sun4i_csi_notify_bound(struct v4l2_async_notifier *notifier, struct v4l2_subdev *subdev, struct v4l2_async_connection *asd) @@ -214,6 +218,7 @@ static int sun4i_csi_probe(struct platform_device *pdev) subdev->internal_ops = &sun4i_csi_subdev_internal_ops; subdev->flags = V4L2_SUBDEV_FL_HAS_DEVNODE | V4L2_SUBDEV_FL_HAS_EVENTS; subdev->entity.function = MEDIA_ENT_F_VID_IF_BRIDGE; + subdev->entity.ops = &sun4i_csi_subdev_entity_ops; subdev->owner = THIS_MODULE; snprintf(subdev->name, sizeof(subdev->name), "sun4i-csi-0"); v4l2_set_subdevdata(subdev, csi); -- Regards, Laurent Pinchart

8 months, 1 week

1
0
0 0

[PATCH V3] video/aperture: optionally match the device in sysfb_disable()

by Alex Deucher

In aperture_remove_conflicting_pci_devices(), we currently only call sysfb_disable() on vga class devices. This leads to the following problem when the pimary device is not VGA compatible: 1. A PCI device with a non-VGA class is the boot display 2. That device is probed first and it is not a VGA device so sysfb_disable() is not called, but the device resources are freed by aperture_detach_platform_device() 3. Non-primary GPU has a VGA class and it ends up calling sysfb_disable() 4. NULL pointer dereference via sysfb_disable() since the resources have already been freed by aperture_detach_platform_device() when it was called by the other device. Fix this by passing a device pointer to sysfb_disable() and checking the device to determine if we should execute it or not. v2: Fix build when CONFIG_SCREEN_INFO is not set v3: Move device check into the mutex Drop primary variable in aperture_remove_conflicting_pci_devices() Drop __init on pci sysfb_pci_dev_is_enabled() Fixes: 5ae3716cfdcd ("video/aperture: Only remove sysfb on the default vga pci device") Cc: Javier Martinez Canillas <javierm(a)redhat.com> Cc: Thomas Zimmermann <tzimmermann(a)suse.de> Cc: Helge Deller <deller(a)gmx.de> Cc: Sam Ravnborg <sam(a)ravnborg.org> Cc: Daniel Vetter <daniel.vetter(a)ffwll.ch> Signed-off-by: Alex Deucher <alexander.deucher(a)amd.com> Cc: stable(a)vger.kernel.org --- drivers/firmware/sysfb.c | 19 +++++++++++++------ drivers/of/platform.c | 2 +- drivers/video/aperture.c | 11 +++-------- include/linux/sysfb.h | 4 ++-- 4 files changed, 19 insertions(+), 17 deletions(-) diff --git a/drivers/firmware/sysfb.c b/drivers/firmware/sysfb.c index 880ffcb50088..ac4680dc463f 100644 --- a/drivers/firmware/sysfb.c +++ b/drivers/firmware/sysfb.c @@ -39,6 +39,8 @@ static struct platform_device *pd; static DEFINE_MUTEX(disable_lock); static bool disabled; +static struct device *sysfb_parent_dev(const struct screen_info *si); + static bool sysfb_unregister(void) { if (IS_ERR_OR_NULL(pd)) @@ -52,6 +54,7 @@ static bool sysfb_unregister(void) /** * sysfb_disable() - disable the Generic System Framebuffers support + * @dev: the device to check if non-NULL * * This disables the registration of system framebuffer devices that match the * generic drivers that make use of the system framebuffer set up by firmware. @@ -61,17 +64,21 @@ static bool sysfb_unregister(void) * Context: The function can sleep. A @disable_lock mutex is acquired to serialize * against sysfb_init(), that registers a system framebuffer device. */ -void sysfb_disable(void) +void sysfb_disable(struct device *dev) { + struct screen_info *si = &screen_info; + mutex_lock(&disable_lock); - sysfb_unregister(); - disabled = true; + if (!dev || dev == sysfb_parent_dev(si)) { + sysfb_unregister(); + disabled = true; + } mutex_unlock(&disable_lock); } EXPORT_SYMBOL_GPL(sysfb_disable); #if defined(CONFIG_PCI) -static __init bool sysfb_pci_dev_is_enabled(struct pci_dev *pdev) +static bool sysfb_pci_dev_is_enabled(struct pci_dev *pdev) { /* * TODO: Try to integrate this code into the PCI subsystem @@ -87,13 +94,13 @@ static __init bool sysfb_pci_dev_is_enabled(struct pci_dev *pdev) return true; } #else -static __init bool sysfb_pci_dev_is_enabled(struct pci_dev *pdev) +static bool sysfb_pci_dev_is_enabled(struct pci_dev *pdev) { return false; } #endif -static __init struct device *sysfb_parent_dev(const struct screen_info *si) +static struct device *sysfb_parent_dev(const struct screen_info *si) { struct pci_dev *pdev; diff --git a/drivers/of/platform.c b/drivers/of/platform.c index 389d4ea6bfc1..ef622d41eb5b 100644 --- a/drivers/of/platform.c +++ b/drivers/of/platform.c @@ -592,7 +592,7 @@ static int __init of_platform_default_populate_init(void) * This can happen for example on DT systems that do EFI * booting and may provide a GOP handle to the EFI stub. */ - sysfb_disable(); + sysfb_disable(NULL); of_platform_device_create(node, NULL, NULL); of_node_put(node); } diff --git a/drivers/video/aperture.c b/drivers/video/aperture.c index 561be8feca96..2b5a1e666e9b 100644 --- a/drivers/video/aperture.c +++ b/drivers/video/aperture.c @@ -293,7 +293,7 @@ int aperture_remove_conflicting_devices(resource_size_t base, resource_size_t si * ask for this, so let's assume that a real driver for the display * was already probed and prevent sysfb to register devices later. */ - sysfb_disable(); + sysfb_disable(NULL); aperture_detach_devices(base, size); @@ -346,15 +346,10 @@ EXPORT_SYMBOL(__aperture_remove_legacy_vga_devices); */ int aperture_remove_conflicting_pci_devices(struct pci_dev *pdev, const char *name) { - bool primary = false; resource_size_t base, size; int bar, ret = 0; - if (pdev == vga_default_device()) - primary = true; - - if (primary) - sysfb_disable(); + sysfb_disable(&pdev->dev); for (bar = 0; bar < PCI_STD_NUM_BARS; ++bar) { if (!(pci_resource_flags(pdev, bar) & IORESOURCE_MEM)) @@ -370,7 +365,7 @@ int aperture_remove_conflicting_pci_devices(struct pci_dev *pdev, const char *na * that consumes the VGA framebuffer I/O range. Remove this * device as well. */ - if (primary) + if (pdev == vga_default_device()) ret = __aperture_remove_legacy_vga_devices(pdev); return ret; diff --git a/include/linux/sysfb.h b/include/linux/sysfb.h index c9cb657dad08..bef5f06a91de 100644 --- a/include/linux/sysfb.h +++ b/include/linux/sysfb.h @@ -58,11 +58,11 @@ struct efifb_dmi_info { #ifdef CONFIG_SYSFB -void sysfb_disable(void); +void sysfb_disable(struct device *dev); #else /* CONFIG_SYSFB */ -static inline void sysfb_disable(void) +static inline void sysfb_disable(struct device *dev) { } -- 2.46.0

8 months, 1 week

3
3
0 0

[PATCH] usb: cdnsp: fix for Link TRB with TC

by Pawel Laszczak

Stop Endpoint command on LINK TRB with TC bit set to 1 causes that internal cycle bit can have incorrect state after command complete. In consequence empty transfer ring can be incorrectly detected when EP is resumed. NOP TRB before LINK TRB avoid such scenario. Stop Endpoint command is then on NOP TRB and internal cycle bit is not changed and have correct value. Fixes: 3d82904559f4 ("usb: cdnsp: cdns3 Add main part of Cadence USBSSP DRD Driver") cc: <stable(a)vger.kernel.org> Signed-off-by: Pawel Laszczak <pawell(a)cadence.com> --- drivers/usb/cdns3/cdnsp-gadget.h | 3 +++ drivers/usb/cdns3/cdnsp-ring.c | 28 ++++++++++++++++++++++++++++ 2 files changed, 31 insertions(+) diff --git a/drivers/usb/cdns3/cdnsp-gadget.h b/drivers/usb/cdns3/cdnsp-gadget.h index e1b5801fdddf..9a5577a772af 100644 --- a/drivers/usb/cdns3/cdnsp-gadget.h +++ b/drivers/usb/cdns3/cdnsp-gadget.h @@ -811,6 +811,7 @@ struct cdnsp_stream_info { * generate Missed Service Error Event. * Set skip flag when receive a Missed Service Error Event and * process the missed tds on the endpoint ring. + * @wa1_nop_trb: hold pointer to NOP trb. */ struct cdnsp_ep { struct usb_ep endpoint; @@ -838,6 +839,8 @@ struct cdnsp_ep { #define EP_UNCONFIGURED BIT(7) bool skip; + union cdnsp_trb *wa1_nop_trb; + }; /** diff --git a/drivers/usb/cdns3/cdnsp-ring.c b/drivers/usb/cdns3/cdnsp-ring.c index 275a6a2fa671..75724e60653c 100644 --- a/drivers/usb/cdns3/cdnsp-ring.c +++ b/drivers/usb/cdns3/cdnsp-ring.c @@ -1904,6 +1904,23 @@ int cdnsp_queue_bulk_tx(struct cdnsp_device *pdev, struct cdnsp_request *preq) if (ret) return ret; + /* + * workaround 1: STOP EP command on LINK TRB with TC bit set to 1 + * causes that internal cycle bit can have incorrect state after + * command complete. In consequence empty transfer ring can be + * incorrectly detected when EP is resumed. + * NOP TRB before LINK TRB avoid such scenario. STOP EP command is + * then on NOP TRB and internal cycle bit is not changed and have + * correct value. + */ + if (pep->wa1_nop_trb) { + field = le32_to_cpu(pep->wa1_nop_trb->trans_event.flags); + field ^= TRB_CYCLE; + + pep->wa1_nop_trb->trans_event.flags = cpu_to_le32(field); + pep->wa1_nop_trb = NULL; + } + /* * Don't give the first TRB to the hardware (by toggling the cycle bit) * until we've finished creating all the other TRBs. The ring's cycle @@ -1999,6 +2016,17 @@ int cdnsp_queue_bulk_tx(struct cdnsp_device *pdev, struct cdnsp_request *preq) send_addr = addr; } + if (cdnsp_trb_is_link(ring->enqueue + 1)) { + field = TRB_TYPE(TRB_TR_NOOP) | TRB_IOC; + if (!ring->cycle_state) + field |= TRB_CYCLE; + + pep->wa1_nop_trb = ring->enqueue; + + cdnsp_queue_trb(pdev, ring, 0, 0x0, 0x0, + TRB_INTR_TARGET(0), field); + } + cdnsp_check_trb_math(preq, enqd_len); ret = cdnsp_giveback_first_trb(pdev, pep, preq->request.stream_id, start_cycle, start_trb); -- 2.43.0

8 months, 1 week

2
3
0 0

[PATCH net v3] net: ngbe: Fix phy mode set to external phy

by Mengyuan Lou

The MAC only has add the TX delay and it can not be modified. MAC and PHY are both set the TX delay cause transmission problems. So just disable TX delay in PHY, when use rgmii to attach to external phy, set PHY_INTERFACE_MODE_RGMII_RXID to phy drivers. And it is does not matter to internal phy. Fixes: bc2426d74aa3 ("net: ngbe: convert phylib to phylink") Signed-off-by: Mengyuan Lou <mengyuanlou(a)net-swift.com> Cc: stable(a)vger.kernel.org # 6.3+ --- v3: -Rebase the fix commit for net. v2: -Add a comment for the code modification. -Add the problem in commit messages. https://lore.kernel.org/netdev/E9C427FDDCF0CBC3+20240812103025.42417-1-meng… v1: https://lore.kernel.org/netdev/C1587837D62D1BC0+20240806082520.29193-1-meng… drivers/net/ethernet/wangxun/ngbe/ngbe_mdio.c | 8 ++++++-- 1 file changed, 6 insertions(+), 2 deletions(-) diff --git a/drivers/net/ethernet/wangxun/ngbe/ngbe_mdio.c b/drivers/net/ethernet/wangxun/ngbe/ngbe_mdio.c index ec54b18c5fe7..a5e9b779c44d 100644 --- a/drivers/net/ethernet/wangxun/ngbe/ngbe_mdio.c +++ b/drivers/net/ethernet/wangxun/ngbe/ngbe_mdio.c @@ -124,8 +124,12 @@ static int ngbe_phylink_init(struct wx *wx) MAC_SYM_PAUSE | MAC_ASYM_PAUSE; config->mac_managed_pm = true; - phy_mode = PHY_INTERFACE_MODE_RGMII_ID; - __set_bit(PHY_INTERFACE_MODE_RGMII_ID, config->supported_interfaces); + /* The MAC only has add the Tx delay and it can not be modified. + * So just disable TX delay in PHY, and it is does not matter to + * internal phy. + */ + phy_mode = PHY_INTERFACE_MODE_RGMII_RXID; + __set_bit(PHY_INTERFACE_MODE_RGMII_RXID, config->supported_interfaces); phylink = phylink_create(config, NULL, phy_mode, &ngbe_mac_ops); if (IS_ERR(phylink)) -- 2.43.2

8 months, 1 week

3
2
0 0

[PATCH 01/12] KVM: arm64: Make ICC_*SGI*_EL1 undef in the absence of a vGICv3

by Marc Zyngier

On a system with a GICv3, if a guest hasn't been configured with GICv3 and that the host is not capable of GICv2 emulation, a write to any of the ICC_*SGI*_EL1 registers is trapped to EL2. We therefore try to emulate the SGI access, only to hit a NULL pointer as no private interrupt is allocated (no GIC, remember?). The obvious fix is to give the guest what it deserves, in the shape of a UNDEF exception. Reported-by: Alexander Potapenko <glider(a)google.com> Signed-off-by: Marc Zyngier <maz(a)kernel.org> Cc: stable(a)vger.kernel.org --- arch/arm64/kvm/sys_regs.c | 6 ++++++ arch/arm64/kvm/vgic/vgic.h | 7 +++++++ 2 files changed, 13 insertions(+) diff --git a/arch/arm64/kvm/sys_regs.c b/arch/arm64/kvm/sys_regs.c index c90324060436..31e49da867ff 100644 --- a/arch/arm64/kvm/sys_regs.c +++ b/arch/arm64/kvm/sys_regs.c @@ -33,6 +33,7 @@ #include <trace/events/kvm.h> #include "sys_regs.h" +#include "vgic/vgic.h" #include "trace.h" @@ -435,6 +436,11 @@ static bool access_gic_sgi(struct kvm_vcpu *vcpu, { bool g1; + if (!kvm_has_gicv3(vcpu->kvm)) { + kvm_inject_undefined(vcpu); + return false; + } + if (!p->is_write) return read_from_write_only(vcpu, p, r); diff --git a/arch/arm64/kvm/vgic/vgic.h b/arch/arm64/kvm/vgic/vgic.h index ba8f790431bd..8532bfe3fed4 100644 --- a/arch/arm64/kvm/vgic/vgic.h +++ b/arch/arm64/kvm/vgic/vgic.h @@ -346,4 +346,11 @@ void vgic_v4_configure_vsgis(struct kvm *kvm); void vgic_v4_get_vlpi_state(struct vgic_irq *irq, bool *val); int vgic_v4_request_vpe_irq(struct kvm_vcpu *vcpu, int irq); +static inline bool kvm_has_gicv3(struct kvm *kvm) +{ + return (static_branch_unlikely(&kvm_vgic_global_state.gicv3_cpuif) && + irqchip_in_kernel(kvm) && + kvm->arch.vgic.vgic_model == KVM_DEV_TYPE_ARM_VGIC_V3); +} + #endif -- 2.39.2

8 months, 1 week

2
4
0 0

[PATCH] firmware_loader: Block path traversal

by Jann Horn

Most firmware names are hardcoded strings, or are constructed from fairly constrained format strings where the dynamic parts are just some hex numbers or such. However, there are a couple codepaths in the kernel where firmware file names contain string components that are passed through from a device or semi-privileged userspace; the ones I could find (not counting interfaces that require root privileges) are: - lpfc_sli4_request_firmware_update() seems to construct the firmware filename from "ModelName", a string that was previously parsed out of some descriptor ("Vital Product Data") in lpfc_fill_vpd() - nfp_net_fw_find() seems to construct a firmware filename from a model name coming from nfp_hwinfo_lookup(pf->hwinfo, "nffw.partno"), which I think parses some descriptor that was read from the device. (But this case likely isn't exploitable because the format string looks like "netronome/nic_%s", and there shouldn't be any *folders* starting with "netronome/nic_". The previous case was different because there, the "%s" is *at the start* of the format string.) - module_flash_fw_schedule() is reachable from the ETHTOOL_MSG_MODULE_FW_FLASH_ACT netlink command, which is marked as GENL_UNS_ADMIN_PERM (meaning CAP_NET_ADMIN inside a user namespace is enough to pass the privilege check), and takes a userspace-provided firmware name. (But I think to reach this case, you need to have CAP_NET_ADMIN over a network namespace that a special kind of ethernet device is mapped into, so I think this is not a viable attack path in practice.) For what it's worth, I went looking and haven't found any USB device drivers that use the firmware loader dangerously. Cc: stable(a)vger.kernel.org Fixes: abb139e75c2c ("firmware: teach the kernel to load firmware files directly from the filesystem") Signed-off-by: Jann Horn <jannh(a)google.com> --- I wasn't sure whether to mark this one for stable or not - but I think since there seems to be at least one PCI device model which could trigger firmware loading with directory traversal, we should probably backport the fix? --- drivers/base/firmware_loader/main.c | 10 +++++++++- 1 file changed, 9 insertions(+), 1 deletion(-) diff --git a/drivers/base/firmware_loader/main.c b/drivers/base/firmware_loader/main.c index a03ee4b11134..a32be64f3bf5 100644 --- a/drivers/base/firmware_loader/main.c +++ b/drivers/base/firmware_loader/main.c @@ -864,7 +864,15 @@ _request_firmware(const struct firmware **firmware_p, const char *name, if (!firmware_p) return -EINVAL; - if (!name || name[0] == '\0') { + /* + * Reject firmware file names with "/../" sequences in them. + * There are drivers that construct firmware file names from + * device-supplied strings, and we don't want some device to be able + * to tell us "I would like to be sent my firmware from + * ../../../etc/shadow, please". + */ + if (!name || name[0] == '\0' || + strstr(name, "/../") != NULL || strncmp(name, "../", 3) == 0) { ret = -EINVAL; goto out; } --- base-commit: b0da640826ba3b6506b4996a6b23a429235e6923 change-id: 20240820-firmware-traversal-6df8501b0fe4 -- Jann Horn <jannh(a)google.com>

8 months, 1 week

4
7
0 0

Patch "drm/amd/display: Don't register panel_power_savings on OLED panels"

by Gergo Koteles

Hi Greg, I think commit 76cb763e6ea62e838ccc8f7a1ea4246d690fccc9 should be applied to 6.10 kernel to disable Adaptive Backlight Management for OLED displays. Thanks, Gergo Koteles

8 months, 1 week

2
1
0 0

[PATCH 5.15.y 00/18] Backport "make svc_stat per-net instead of global"

by cel＠kernel.org

From: Chuck Lever <chuck.lever(a)oracle.com> Following up on https://lore.kernel.org/linux-nfs/d4b235df-4ee5-4824-9d48-e3b3c1f1f4d1@orac… Here is a backport series targeting origin/linux-5.15.y that closes the information leak described in the above thread. Review comments welcome. Chuck Lever (6): NFSD: Refactor nfsd_reply_cache_free_locked() NFSD: Rename nfsd_reply_cache_alloc() NFSD: Replace nfsd_prune_bucket() NFSD: Refactor the duplicate reply cache shrinker NFSD: Rewrite synopsis of nfsd_percpu_counters_init() NFSD: Fix frame size warning in svc_export_parse() Jeff Layton (2): nfsd: move reply cache initialization into nfsd startup nfsd: move init of percpu reply_cache_stats counters back to nfsd_init_net Josef Bacik (10): sunrpc: don't change ->sv_stats if it doesn't exist nfsd: stop setting ->pg_stats for unused stats sunrpc: pass in the sv_stats struct through svc_create_pooled sunrpc: remove ->pg_stats from svc_program sunrpc: use the struct net as the svc proc private nfsd: rename NFSD_NET_* to NFSD_STATS_* nfsd: expose /proc/net/sunrpc/nfsd in net namespaces nfsd: make all of the nfsd stats per-network namespace nfsd: remove nfsd_stats, make th_cnt a global counter nfsd: make svc_stat per-network namespace instead of global fs/lockd/svc.c | 3 - fs/nfs/callback.c | 3 - fs/nfsd/export.c | 32 ++++-- fs/nfsd/export.h | 4 +- fs/nfsd/netns.h | 25 ++++- fs/nfsd/nfs4proc.c | 6 +- fs/nfsd/nfscache.c | 202 ++++++++++++++++++++++--------------- fs/nfsd/nfsctl.c | 24 ++--- fs/nfsd/nfsd.h | 1 + fs/nfsd/nfsfh.c | 3 +- fs/nfsd/nfssvc.c | 24 +++-- fs/nfsd/stats.c | 52 ++++------ fs/nfsd/stats.h | 83 ++++++--------- fs/nfsd/trace.h | 22 ++++ fs/nfsd/vfs.c | 6 +- include/linux/sunrpc/svc.h | 5 +- net/sunrpc/stats.c | 2 +- net/sunrpc/svc.c | 36 ++++--- 18 files changed, 302 insertions(+), 231 deletions(-) -- 2.45.2

8 months, 1 week

2
19
0 0

[PATCH 6.6.y] stm32mp15: WARNING after poweroff command

by Christoph Niedermaier

Hi stable team, I would suggest to apply the patch 470a66268856 ("i2c: stm32f7: Add atomic_xfer method to driver") from 6.7-rc1 to the stable Kernel 6.6.y. Here is why: After the commit 6e9df38f359a ("mfd: stpmic1: Add PMIC poweroff via sys-off handler") from 6.5-rc1 the following WARNING appears after calling the poweroff command: [ 791.813369] systemd-shutdown[1]: Syncing filesystems and block devices. [ 792.865580] systemd-shutdown[1]: Sending SIGTERM to remaining processes... [ 792.921103] systemd-journald[101]: Received SIGTERM from PID 1 (systemd-shutdow). [ 792.936515] systemd-shutdown[1]: Sending SIGKILL to remaining processes... [ 792.968715] systemd-shutdown[1]: Unmounting file systems. [ 792.979332] (sd-remount)[315]: Remounting '/' read-only with options ''. [ 793.219266] EXT4-fs (mmcblk2p4): re-mounted f7da42a1-2eed-4d39-a31e-e0ffadb97b28 ro. Quota mode: disabled. [ 793.238398] systemd-shutdown[1]: All filesystems unmounted. [ 793.242736] systemd-shutdown[1]: Deactivating swaps. [ 793.248004] systemd-shutdown[1]: All swaps deactivated. [ 793.252937] systemd-shutdown[1]: Detaching loop devices. [ 793.272548] systemd-shutdown[1]: All loop devices detached. [ 793.276918] systemd-shutdown[1]: Stopping MD devices. [ 793.282790] systemd-shutdown[1]: All MD devices stopped. [ 793.287128] systemd-shutdown[1]: Detaching DM devices. [ 793.292995] systemd-shutdown[1]: All DM devices detached. [ 793.297731] systemd-shutdown[1]: All filesystems, swaps, loop devices, MD devices and DM devices detached. [ 793.320636] systemd-shutdown[1]: Syncing filesystems and block devices. [ 793.326078] systemd-shutdown[1]: Powering off. [ 793.348421] reboot: Power down [ 793.350129] ------------[ cut here ]------------ [ 793.354691] WARNING: CPU: 0 PID: 1 at drivers/i2c/i2c-core.h:42 i2c_transfer+0x5d/0x7c [ 793.362617] No atomic I2C transfer handler for 'i2c-2' [ 793.367780] Modules linked in: [ 793.370838] CPU: 0 PID: 1 Comm: systemd-shutdow Not tainted 6.6.41-lardisbox2-00053-g41e0b7f0166f #12 [ 793.380047] Hardware name: STM32 (Device Tree Support) [ 793.385122] unwind_backtrace from show_stack+0xb/0xc [ 793.390215] show_stack from dump_stack_lvl+0x2b/0x34 [ 793.395202] dump_stack_lvl from __warn+0x5d/0xc4 [ 793.399993] __warn from warn_slowpath_fmt+0x55/0xa8 [ 793.404887] warn_slowpath_fmt from i2c_transfer+0x5d/0x7c [ 793.410387] i2c_transfer from regmap_i2c_read+0x41/0x6c [ 793.415681] regmap_i2c_read from _regmap_raw_read+0x87/0xe8 [ 793.421378] _regmap_raw_read from _regmap_bus_read+0x21/0x38 [ 793.427079] _regmap_bus_read from _regmap_read+0x55/0x9c [ 793.432477] _regmap_read from _regmap_update_bits+0x71/0xa4 [ 793.438175] _regmap_update_bits from regmap_update_bits_base+0x2f/0x42 [ 793.444784] regmap_update_bits_base from stpmic1_power_off+0x19/0x20 [ 793.451188] stpmic1_power_off from sys_off_notify+0x1b/0x38 [ 793.456880] sys_off_notify from notifier_call_chain+0x57/0x78 [ 793.462668] notifier_call_chain from atomic_notifier_call_chain+0x11/0x16 [ 793.469562] atomic_notifier_call_chain from do_kernel_power_off+0x21/0x38 [ 793.476461] do_kernel_power_off from __do_sys_reboot+0xdf/0x150 [ 793.482456] __do_sys_reboot from ret_fast_syscall+0x1/0x5c [ 793.488042] Exception stack(0xf0815fa8 to 0xf0815ff0) [ 793.493017] 5fa0: 00000000 00000000 fee1dead 28121969 4321fedc 00000000 [ 793.501218] 5fc0: 00000000 00000000 00000000 00000058 0001884c 00000003 00000000 00018140 [ 793.509414] 5fe0: 00000058 bee18c34 b6c20cdd b6b995a6 [ 793.514478] ---[ end trace 000000000000000 This can be eliminated by backporting the above mentioned patch. I tested it with a DHCOM stm32mp157c on a PDK2 board. Thanks and regards Christoph

8 months, 1 week

2
1
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror August 2024