August 2024 - Linux-stable-mirror

[PATCH] x86/hyperv: fix kexec crash due to VP assist page corruption

by Anirudh Rayabharam

From: Anirudh Rayabharam (Microsoft) <anirudh(a)anirudhrb.com> 9636be85cc5b ("x86/hyperv: Fix hyperv_pcpu_input_arg handling when CPUs go online/offline") introduces a new cpuhp state for hyperv initialization. cpuhp_setup_state() returns the state number if state is CPUHP_AP_ONLINE_DYN or CPUHP_BP_PREPARE_DYN and 0 for all other states. For the hyperv case, since a new cpuhp state was introduced it would return 0. However, in hv_machine_shutdown(), the cpuhp_remove_state() call is conditioned upon "hyperv_init_cpuhp > 0". This will never be true and so hv_cpu_die() won't be called on all CPUs. This means the VP assist page won't be reset. When the kexec kernel tries to setup the VP assist page again, the hypervisor corrupts the memory region of the old VP assist page causing a panic in case the kexec kernel is using that memory elsewhere. This was originally fixed in dfe94d4086e4 ("x86/hyperv: Fix kexec panic/hang issues"). Set hyperv_init_cpuhp to CPUHP_AP_HYPERV_ONLINE upon successful setup so that the hyperv cpuhp state is removed correctly on kexec and the necessary cleanup takes place. Cc: stable(a)vger.kernel.org Fixes: 9636be85cc5b ("x86/hyperv: Fix hyperv_pcpu_input_arg handling when CPUs go online/offline") Signed-off-by: Anirudh Rayabharam (Microsoft) <anirudh(a)anirudhrb.com> --- arch/x86/hyperv/hv_init.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/arch/x86/hyperv/hv_init.c b/arch/x86/hyperv/hv_init.c index 17a71e92a343..81d1981a75d1 100644 --- a/arch/x86/hyperv/hv_init.c +++ b/arch/x86/hyperv/hv_init.c @@ -607,7 +607,7 @@ void __init hyperv_init(void) register_syscore_ops(&hv_syscore_ops); - hyperv_init_cpuhp = cpuhp; + hyperv_init_cpuhp = CPUHP_AP_HYPERV_ONLINE; if (cpuid_ebx(HYPERV_CPUID_FEATURES) & HV_ACCESS_PARTITION_ID) hv_get_partition_id(); @@ -637,7 +637,7 @@ void __init hyperv_init(void) clean_guest_os_id: wrmsrl(HV_X64_MSR_GUEST_OS_ID, 0); hv_ivm_msr_write(HV_X64_MSR_GUEST_OS_ID, 0); - cpuhp_remove_state(cpuhp); + cpuhp_remove_state(CPUHP_AP_HYPERV_ONLINE); free_ghcb_page: free_percpu(hv_ghcb_pg); free_vp_assist_page: -- 2.45.2

8 months

2
2
0 0

[PATCH] wifi: wfx: repair open network AP mode

by A. Sverdlin

From: Alexander Sverdlin <alexander.sverdlin(a)siemens.com> RSN IE missing in beacon is normal in open networks. Avoid returning -ENODEV in this case. Steps to reproduce: $ cat /etc/wpa_supplicant.conf network={ ssid="testNet" mode=2 key_mgmt=NONE } $ wpa_supplicant -iwlan0 -c /etc/wpa_supplicant.conf nl80211: Beacon set failed: -22 (Invalid argument) Failed to set beacon parameters Interface initialization failed wlan0: interface state UNINITIALIZED->DISABLED wlan0: AP-DISABLED wlan0: Unable to setup interface. Failed to initialize AP interface After the change: $ wpa_supplicant -iwlan0 -c /etc/wpa_supplicant.conf Successfully initialized wpa_supplicant wlan0: interface state UNINITIALIZED->ENABLED wlan0: AP-ENABLED Cc: stable(a)vger.kernel.org Fixes: fe0a7776d4d1 ("wifi: wfx: fix possible NULL pointer dereference in wfx_set_mfp_ap()") Signed-off-by: Alexander Sverdlin <alexander.sverdlin(a)siemens.com> --- drivers/net/wireless/silabs/wfx/sta.c | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/drivers/net/wireless/silabs/wfx/sta.c b/drivers/net/wireless/silabs/wfx/sta.c index 216d43c8bd6e..7c04810dbf3d 100644 --- a/drivers/net/wireless/silabs/wfx/sta.c +++ b/drivers/net/wireless/silabs/wfx/sta.c @@ -352,8 +352,11 @@ static int wfx_set_mfp_ap(struct wfx_vif *wvif) ptr = (u16 *)cfg80211_find_ie(WLAN_EID_RSN, skb->data + ieoffset, skb->len - ieoffset); - if (unlikely(!ptr)) + if (!ptr) { + /* No RSN IE is fine in open networks */ + ret = 0; goto free_skb; + } ptr += pairwise_cipher_suite_count_offset; if (WARN_ON(ptr > (u16 *)skb_tail_pointer(skb))) -- 2.46.0

8 months

4
6
0 0

FAILED: patch "[PATCH] igc: Fix qbv tx latency by setting gtxoffset" 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 6c3fc0b1c3d073bd6fc3bf43dbd0e64240537464 # <resolve conflicts, build, test, etc.> git commit -s git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '2024082742-getting-scoured-1475@gregkh' --subject-prefix 'PATCH 5.15.y' HEAD^.. Possible dependencies: 6c3fc0b1c3d0 ("igc: Fix qbv tx latency by setting gtxoffset") 790835fcc0cb ("igc: Correct the launchtime offset") thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From 6c3fc0b1c3d073bd6fc3bf43dbd0e64240537464 Mon Sep 17 00:00:00 2001 From: Faizal Rahim <faizal.abdul.rahim(a)linux.intel.com> Date: Sun, 7 Jul 2024 08:53:18 -0400 Subject: [PATCH] igc: Fix qbv tx latency by setting gtxoffset A large tx latency issue was discovered during testing when only QBV was enabled. The issue occurs because gtxoffset was not set when QBV is active, it was only set when launch time is active. The patch "igc: Correct the launchtime offset" only sets gtxoffset when the launchtime_enable field is set by the user. Enabling launchtime_enable ultimately sets the register IGC_TXQCTL_QUEUE_MODE_LAUNCHT (referred to as LaunchT in the SW user manual). Section 7.5.2.6 of the IGC i225/6 SW User Manual Rev 1.2.4 states: "The latency between transmission scheduling (launch time) and the time the packet is transmitted to the network is listed in Table 7-61." However, the patch misinterprets the phrase "launch time" in that section by assuming it specifically refers to the LaunchT register, whereas it actually denotes the generic term for when a packet is released from the internal buffer to the MAC transmit logic. This launch time, as per that section, also implicitly refers to the QBV gate open time, where a packet waits in the buffer for the QBV gate to open. Therefore, latency applies whenever QBV is in use. TSN features such as QBU and QAV reuse QBV, making the latency universal to TSN features. Discussed with i226 HW owner (Shalev, Avi) and we were in agreement that the term "launch time" used in Section 7.5.2.6 is not clear and can be easily misinterpreted. Avi will update this section to: "When TQAVCTRL.TRANSMIT_MODE = TSN, the latency between transmission scheduling and the time the packet is transmitted to the network is listed in Table 7-61." Fix this issue by using igc_tsn_is_tx_mode_in_tsn() as a condition to write to gtxoffset, aligning with the newly updated SW User Manual. Tested: 1. Enrol taprio on talker board base-time 0 cycle-time 1000000 flags 0x2 index 0 cmd S gatemask 0x1 interval1 index 0 cmd S gatemask 0x1 interval2 Note: interval1 = interval for a 64 bytes packet to go through interval2 = cycle-time - interval1 2. Take tcpdump on listener board 3. Use udp tai app on talker to send packets to listener 4. Check the timestamp on listener via wireshark Test Result: 100 Mbps: 113 ~193 ns 1000 Mbps: 52 ~ 84 ns 2500 Mbps: 95 ~ 223 ns Note that the test result is similar to the patch "igc: Correct the launchtime offset". Fixes: 790835fcc0cb ("igc: Correct the launchtime offset") Signed-off-by: Faizal Rahim <faizal.abdul.rahim(a)linux.intel.com> Reviewed-by: Simon Horman <horms(a)kernel.org> Acked-by: Vinicius Costa Gomes <vinicius.gomes(a)intel.com> Tested-by: Mor Bar-Gabay <morx.bar.gabay(a)intel.com> Signed-off-by: Tony Nguyen <anthony.l.nguyen(a)intel.com> diff --git a/drivers/net/ethernet/intel/igc/igc_tsn.c b/drivers/net/ethernet/intel/igc/igc_tsn.c index ada751430517..d68fa7f3d5f0 100644 --- a/drivers/net/ethernet/intel/igc/igc_tsn.c +++ b/drivers/net/ethernet/intel/igc/igc_tsn.c @@ -61,7 +61,7 @@ void igc_tsn_adjust_txtime_offset(struct igc_adapter *adapter) struct igc_hw *hw = &adapter->hw; u16 txoffset; - if (!is_any_launchtime(adapter)) + if (!igc_tsn_is_tx_mode_in_tsn(adapter)) return; switch (adapter->link_speed) {

8 months

1
0
0 0

FAILED: patch "[PATCH] igc: Fix qbv tx latency by setting gtxoffset" failed to apply to 6.1-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 6.1-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.1.y git checkout FETCH_HEAD git cherry-pick -x 6c3fc0b1c3d073bd6fc3bf43dbd0e64240537464 # <resolve conflicts, build, test, etc.> git commit -s git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '2024082740-citadel-facelift-bc00@gregkh' --subject-prefix 'PATCH 6.1.y' HEAD^.. Possible dependencies: 6c3fc0b1c3d0 ("igc: Fix qbv tx latency by setting gtxoffset") 790835fcc0cb ("igc: Correct the launchtime offset") thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From 6c3fc0b1c3d073bd6fc3bf43dbd0e64240537464 Mon Sep 17 00:00:00 2001 From: Faizal Rahim <faizal.abdul.rahim(a)linux.intel.com> Date: Sun, 7 Jul 2024 08:53:18 -0400 Subject: [PATCH] igc: Fix qbv tx latency by setting gtxoffset A large tx latency issue was discovered during testing when only QBV was enabled. The issue occurs because gtxoffset was not set when QBV is active, it was only set when launch time is active. The patch "igc: Correct the launchtime offset" only sets gtxoffset when the launchtime_enable field is set by the user. Enabling launchtime_enable ultimately sets the register IGC_TXQCTL_QUEUE_MODE_LAUNCHT (referred to as LaunchT in the SW user manual). Section 7.5.2.6 of the IGC i225/6 SW User Manual Rev 1.2.4 states: "The latency between transmission scheduling (launch time) and the time the packet is transmitted to the network is listed in Table 7-61." However, the patch misinterprets the phrase "launch time" in that section by assuming it specifically refers to the LaunchT register, whereas it actually denotes the generic term for when a packet is released from the internal buffer to the MAC transmit logic. This launch time, as per that section, also implicitly refers to the QBV gate open time, where a packet waits in the buffer for the QBV gate to open. Therefore, latency applies whenever QBV is in use. TSN features such as QBU and QAV reuse QBV, making the latency universal to TSN features. Discussed with i226 HW owner (Shalev, Avi) and we were in agreement that the term "launch time" used in Section 7.5.2.6 is not clear and can be easily misinterpreted. Avi will update this section to: "When TQAVCTRL.TRANSMIT_MODE = TSN, the latency between transmission scheduling and the time the packet is transmitted to the network is listed in Table 7-61." Fix this issue by using igc_tsn_is_tx_mode_in_tsn() as a condition to write to gtxoffset, aligning with the newly updated SW User Manual. Tested: 1. Enrol taprio on talker board base-time 0 cycle-time 1000000 flags 0x2 index 0 cmd S gatemask 0x1 interval1 index 0 cmd S gatemask 0x1 interval2 Note: interval1 = interval for a 64 bytes packet to go through interval2 = cycle-time - interval1 2. Take tcpdump on listener board 3. Use udp tai app on talker to send packets to listener 4. Check the timestamp on listener via wireshark Test Result: 100 Mbps: 113 ~193 ns 1000 Mbps: 52 ~ 84 ns 2500 Mbps: 95 ~ 223 ns Note that the test result is similar to the patch "igc: Correct the launchtime offset". Fixes: 790835fcc0cb ("igc: Correct the launchtime offset") Signed-off-by: Faizal Rahim <faizal.abdul.rahim(a)linux.intel.com> Reviewed-by: Simon Horman <horms(a)kernel.org> Acked-by: Vinicius Costa Gomes <vinicius.gomes(a)intel.com> Tested-by: Mor Bar-Gabay <morx.bar.gabay(a)intel.com> Signed-off-by: Tony Nguyen <anthony.l.nguyen(a)intel.com> diff --git a/drivers/net/ethernet/intel/igc/igc_tsn.c b/drivers/net/ethernet/intel/igc/igc_tsn.c index ada751430517..d68fa7f3d5f0 100644 --- a/drivers/net/ethernet/intel/igc/igc_tsn.c +++ b/drivers/net/ethernet/intel/igc/igc_tsn.c @@ -61,7 +61,7 @@ void igc_tsn_adjust_txtime_offset(struct igc_adapter *adapter) struct igc_hw *hw = &adapter->hw; u16 txoffset; - if (!is_any_launchtime(adapter)) + if (!igc_tsn_is_tx_mode_in_tsn(adapter)) return; switch (adapter->link_speed) {

8 months

1
0
0 0

FAILED: patch "[PATCH] ksmbd: the buffer of smb2 query dir response has at least 1" 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 ce61b605a00502c59311d0a4b1f58d62b48272d0 # <resolve conflicts, build, test, etc.> git commit -s git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '2024082604-depose-iphone-7d55@gregkh' --subject-prefix 'PATCH 5.15.y' HEAD^.. Possible dependencies: ce61b605a005 ("ksmbd: the buffer of smb2 query dir response has at least 1 byte") e2b76ab8b5c9 ("ksmbd: add support for read compound") e202a1e8634b ("ksmbd: no response from compound read") 7b7d709ef7cf ("ksmbd: add missing compound request handing in some commands") 81a94b27847f ("ksmbd: use kvzalloc instead of kvmalloc") 38c8a9a52082 ("smb: move client and server files to common directory fs/smb") 30210947a343 ("ksmbd: fix racy issue under cocurrent smb2 tree disconnect") abcc506a9a71 ("ksmbd: fix racy issue from smb2 close and logoff with multichannel") ea174a918939 ("ksmbd: destroy expired sessions") f5c779b7ddbd ("ksmbd: fix racy issue from session setup and logoff") 74d7970febf7 ("ksmbd: fix racy issue from using ->d_parent and ->d_name") 34e8ccf9ce24 ("ksmbd: set NegotiateContextCount once instead of every inc") 42bc6793e452 ("Merge tag 'pull-lock_rename_child' of git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs into ksmbd-for-next") thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From ce61b605a00502c59311d0a4b1f58d62b48272d0 Mon Sep 17 00:00:00 2001 From: Namjae Jeon <linkinjeon(a)kernel.org> Date: Tue, 20 Aug 2024 22:07:38 +0900 Subject: [PATCH] ksmbd: the buffer of smb2 query dir response has at least 1 byte When STATUS_NO_MORE_FILES status is set to smb2 query dir response, ->StructureSize is set to 9, which mean buffer has 1 byte. This issue occurs because ->Buffer[1] in smb2_query_directory_rsp to flex-array. Fixes: eb3e28c1e89b ("smb3: Replace smb2pdu 1-element arrays with flex-arrays") Cc: stable(a)vger.kernel.org # v6.1+ Signed-off-by: Namjae Jeon <linkinjeon(a)kernel.org> Signed-off-by: Steve French <stfrench(a)microsoft.com> diff --git a/fs/smb/server/smb2pdu.c b/fs/smb/server/smb2pdu.c index 0bc9edf22ba4..e9204180919e 100644 --- a/fs/smb/server/smb2pdu.c +++ b/fs/smb/server/smb2pdu.c @@ -4409,7 +4409,8 @@ int smb2_query_dir(struct ksmbd_work *work) rsp->OutputBufferLength = cpu_to_le32(0); rsp->Buffer[0] = 0; rc = ksmbd_iov_pin_rsp(work, (void *)rsp, - sizeof(struct smb2_query_directory_rsp)); + offsetof(struct smb2_query_directory_rsp, Buffer) + + 1); if (rc) goto err_out; } else {

8 months

3
4
0 0

[PATCH] spi: rockchip: Resolve unbalanced runtime PM / system PM handling

by Brian Norris

Commit e882575efc77 ("spi: rockchip: Suspend and resume the bus during NOIRQ_SYSTEM_SLEEP_PM ops") stopped respecting runtime PM status and simply disabled clocks unconditionally when suspending the system. This causes problems when the device is already runtime suspended when we go to sleep -- in which case we double-disable clocks and produce a WARNing. Switch back to pm_runtime_force_{suspend,resume}(), because that still seems like the right thing to do, and the aforementioned commit makes no explanation why it stopped using it. Also, refactor some of the resume() error handling, because it's not actually a good idea to re-disable clocks on failure. Fixes: e882575efc77 ("spi: rockchip: Suspend and resume the bus during NOIRQ_SYSTEM_SLEEP_PM ops") Cc: <stable(a)vger.kernel.org> Reported-by: "Ondřej Jirman" <megi(a)xff.cz> Closes: https://lore.kernel.org/lkml/20220621154218.sau54jeij4bunf56@core/ Signed-off-by: Brian Norris <briannorris(a)chromium.org> --- drivers/spi/spi-rockchip.c | 21 +++++++-------------- 1 file changed, 7 insertions(+), 14 deletions(-) diff --git a/drivers/spi/spi-rockchip.c b/drivers/spi/spi-rockchip.c index e1ecd96c7858..f30af4316b8b 100644 --- a/drivers/spi/spi-rockchip.c +++ b/drivers/spi/spi-rockchip.c @@ -951,8 +951,11 @@ static int rockchip_spi_suspend(struct device *dev) if (ret < 0) return ret; - clk_disable_unprepare(rs->spiclk); - clk_disable_unprepare(rs->apb_pclk); + ret = pm_runtime_force_suspend(dev); + if (ret < 0) { + spi_controller_resume(ctlr); + return ret; + } pinctrl_pm_select_sleep_state(dev); @@ -967,21 +970,11 @@ static int rockchip_spi_resume(struct device *dev) pinctrl_pm_select_default_state(dev); - ret = clk_prepare_enable(rs->apb_pclk); + ret = pm_runtime_force_resume(dev); if (ret < 0) return ret; - ret = clk_prepare_enable(rs->spiclk); - if (ret < 0) - clk_disable_unprepare(rs->apb_pclk); - - ret = spi_controller_resume(ctlr); - if (ret < 0) { - clk_disable_unprepare(rs->spiclk); - clk_disable_unprepare(rs->apb_pclk); - } - - return 0; + return spi_controller_resume(ctlr); } #endif /* CONFIG_PM_SLEEP */ -- 2.46.0.295.g3b9ea8a38a-goog

8 months

2
1
0 0

[PATCH] drm/vmwgfx: Cleanup kms setup without 3d

by Zack Rusin

Do not validate format equality for the non 3d cases to allow xrgb to argb copies and make sure the dx binding flags are only used on dx compatible surfaces. Fixes basic 2d kms setup on configurations without 3d. There's little practical benefit to it because kms framebuffer coherence is disabled on configurations without 3d but with those changes the code actually makes sense. Signed-off-by: Zack Rusin <zack.rusin(a)broadcom.com> Fixes: d6667f0ddf46 ("drm/vmwgfx: Fix handling of dumb buffers") Cc: Broadcom internal kernel review list <bcm-kernel-feedback-list(a)broadcom.com> Cc: dri-devel(a)lists.freedesktop.org Cc: <stable(a)vger.kernel.org> # v6.9+ Cc: Maaz Mombasawala <maaz.mombasawala(a)broadcom.com> Cc: Martin Krastev <martin.krastev(a)broadcom.com> --- drivers/gpu/drm/vmwgfx/vmwgfx_kms.c | 9 --------- drivers/gpu/drm/vmwgfx/vmwgfx_surface.c | 9 ++++++--- 2 files changed, 6 insertions(+), 12 deletions(-) diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c b/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c index 288ed0bb75cb..b5fc5a9e123a 100644 --- a/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c +++ b/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c @@ -1339,15 +1339,6 @@ static int vmw_kms_new_framebuffer_surface(struct vmw_private *dev_priv, return -EINVAL; } - /* - * For DX, surface format validation is done when surface->scanout - * is set. - */ - if (!has_sm4_context(dev_priv) && format != surface->metadata.format) { - DRM_ERROR("Invalid surface format for requested mode.\n"); - return -EINVAL; - } - vfbs = kzalloc(sizeof(*vfbs), GFP_KERNEL); if (!vfbs) { ret = -ENOMEM; diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_surface.c b/drivers/gpu/drm/vmwgfx/vmwgfx_surface.c index 1625b30d9970..5721c74da3e0 100644 --- a/drivers/gpu/drm/vmwgfx/vmwgfx_surface.c +++ b/drivers/gpu/drm/vmwgfx/vmwgfx_surface.c @@ -2276,9 +2276,12 @@ int vmw_dumb_create(struct drm_file *file_priv, const struct SVGA3dSurfaceDesc *desc = vmw_surface_get_desc(format); SVGA3dSurfaceAllFlags flags = SVGA3D_SURFACE_HINT_TEXTURE | SVGA3D_SURFACE_HINT_RENDERTARGET | - SVGA3D_SURFACE_SCREENTARGET | - SVGA3D_SURFACE_BIND_SHADER_RESOURCE | - SVGA3D_SURFACE_BIND_RENDER_TARGET; + SVGA3D_SURFACE_SCREENTARGET; + + if (vmw_surface_is_dx_screen_target_format(format)) { + flags |= SVGA3D_SURFACE_BIND_SHADER_RESOURCE | + SVGA3D_SURFACE_BIND_RENDER_TARGET; + } /* * Without mob support we're just going to use raw memory buffer -- 2.43.0

8 months

1
0
0 0

[PATCH] cpuidle: haltpoll: Fix guest_halt_poll_ns failed to take effect

by Yanhao Dong

From: ysay <ysaydong(a)gmail.com> When guest_halt_poll_allow_shrink=N,setting guest_halt_poll_ns from a large value to 0 does not reset the CPU polling time, despite guest_halt_poll_ns being intended as a mandatory maximum time limit. The problem was situated in the adjust_poll_limit() within drivers/cpuidle/governors/haltpoll.c:79. Specifically, when guest_halt_poll_allow_shrink was set to N, resetting guest_halt_poll_ns to zero did not lead to executing any section of code that adjusts dev->poll_limit_ns. The issue has been resolved by relocating the check and assignment for dev->poll_limit_ns outside of the conditional block. This ensures that every modification to guest_halt_poll_ns properly influences the CPU polling time. Signed-off-by: ysay <ysaydong(a)gmail.com> Fixes: 2cffe9f6b96f ("cpuidle: add haltpoll governor") --- drivers/cpuidle/governors/haltpoll.c | 14 +++++++------- 1 file changed, 7 insertions(+), 7 deletions(-) diff --git a/drivers/cpuidle/governors/haltpoll.c b/drivers/cpuidle/governors/haltpoll.c index 663b7f164..99c6260d7 100644 --- a/drivers/cpuidle/governors/haltpoll.c +++ b/drivers/cpuidle/governors/haltpoll.c @@ -78,26 +78,22 @@ static int haltpoll_select(struct cpuidle_driver *drv, static void adjust_poll_limit(struct cpuidle_device *dev, u64 block_ns) { - unsigned int val; + unsigned int val = dev->poll_limit_ns; /* Grow cpu_halt_poll_us if * cpu_halt_poll_us < block_ns < guest_halt_poll_us */ if (block_ns > dev->poll_limit_ns && block_ns <= guest_halt_poll_ns) { - val = dev->poll_limit_ns * guest_halt_poll_grow; + val *= guest_halt_poll_grow; if (val < guest_halt_poll_grow_start) val = guest_halt_poll_grow_start; - if (val > guest_halt_poll_ns) - val = guest_halt_poll_ns; trace_guest_halt_poll_ns_grow(val, dev->poll_limit_ns); - dev->poll_limit_ns = val; } else if (block_ns > guest_halt_poll_ns && guest_halt_poll_allow_shrink) { unsigned int shrink = guest_halt_poll_shrink; - val = dev->poll_limit_ns; if (shrink == 0) { val = 0; } else { @@ -108,8 +104,12 @@ static void adjust_poll_limit(struct cpuidle_device *dev, u64 block_ns) } trace_guest_halt_poll_ns_shrink(val, dev->poll_limit_ns); - dev->poll_limit_ns = val; } + + if (val > guest_halt_poll_ns) + val = guest_halt_poll_ns; + + dev->poll_limit_ns = val; } /** -- 2.43.5

8 months

2
1
0 0

[PATCH 2/2] mmc : fix for check cqe halt.

by Seunghwan Baek

To check if mmc cqe is in halt state, need to check set/clear of CQHCI_HALT bit. At this time, we need to check with &, not &&. Therefore, code to check whether cqe is in halt state is modified to cqhci_halted, which has already been implemented. Fixes: 0653300224a6 ("mmc: cqhci: rename cqhci.c to cqhci-core.c") Cc: stable(a)vger.kernel.org Signed-off-by: Seunghwan Baek <sh8267.baek(a)samsung.com> --- drivers/mmc/host/cqhci-core.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/mmc/host/cqhci-core.c b/drivers/mmc/host/cqhci-core.c index c14d7251d0bb..3d5bcb92c78e 100644 --- a/drivers/mmc/host/cqhci-core.c +++ b/drivers/mmc/host/cqhci-core.c @@ -282,7 +282,7 @@ static void __cqhci_enable(struct cqhci_host *cq_host) cqhci_writel(cq_host, cqcfg, CQHCI_CFG); - if (cqhci_readl(cq_host, CQHCI_CTL) & CQHCI_HALT) + if (cqhci_halted(cq_host)) cqhci_writel(cq_host, 0, CQHCI_CTL); mmc->cqe_on = true; @@ -617,7 +617,7 @@ static int cqhci_request(struct mmc_host *mmc, struct mmc_request *mrq) cqhci_writel(cq_host, 0, CQHCI_CTL); mmc->cqe_on = true; pr_debug("%s: cqhci: CQE on\n", mmc_hostname(mmc)); - if (cqhci_readl(cq_host, CQHCI_CTL) && CQHCI_HALT) { + if (cqhci_halted(cq_host)) { pr_err("%s: cqhci: CQE failed to exit halt state\n", mmc_hostname(mmc)); } -- 2.17.1

8 months

2
2
0 0

[PATCH] binfmt_elf_fdpic: fix AUXV size calculation when ELF_HWCAP2 is defined

by Max Filippov

create_elf_fdpic_tables() does not correctly account the space for the AUX vector when an architecture has ELF_HWCAP2 defined. Prior to the commit 10e29251be0e ("binfmt_elf_fdpic: fix /proc/<pid>/auxv") it resulted in the last entry of the AUX vector being set to zero, but with that change it results in a kernel BUG. Fix that by adding one to the number of AUXV entries (nitems) when ELF_HWCAP2 is defined. Fixes: 10e29251be0e ("binfmt_elf_fdpic: fix /proc/<pid>/auxv") Cc: stable(a)vger.kernel.org Reported-by: Greg Ungerer <gregungerer(a)westnet.com.au> Closes: https://lore.kernel.org/lkml/5b51975f-6d0b-413c-8b38-39a6a45e8821@westnet.c… Signed-off-by: Max Filippov <jcmvbkbc(a)gmail.com> --- fs/binfmt_elf_fdpic.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/fs/binfmt_elf_fdpic.c b/fs/binfmt_elf_fdpic.c index c11289e1301b..a5cb45cb30c8 100644 --- a/fs/binfmt_elf_fdpic.c +++ b/fs/binfmt_elf_fdpic.c @@ -594,6 +594,9 @@ static int create_elf_fdpic_tables(struct linux_binprm *bprm, if (bprm->have_execfd) nitems++; +#ifdef ELF_HWCAP2 + nitems++; +#endif csp = sp; sp -= nitems * 2 * sizeof(unsigned long); -- 2.39.2

8 months

3
2
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror August 2024