Changes from v1:
* Fix minor typos
* Use the more generic and standard ex_handler_default(). Had the
original code used this helper, the bug would not have been there
in the first place.
--
From: Dave Hansen <dave.hansen(a)linux.intel.com>
Right now, if XRSTOR fails a console message like this is be printed:
Bad FPU state detected at restore_fpregs_from_fpstate+0x9a/0x170, reinitializing FPU registers.
However, the text location (...+0x9a in this case) is the instruction
*AFTER* the XRSTOR. The highlighted instruction in the "Code:" dump
also points one instruction late.
The reason is that the "fixup" moves RIP up to pass the bad XRSTOR and
keep on running after returning from the #GP handler. But it does this
fixup before warning.
The resulting warning output is nonsensical because it looks like the
non-FPU-related instruction is #GP'ing.
Do not fix up RIP until after printing the warning. Do this by using
the more generic and standard ex_handler_default().
Signed-off-by: Dave Hansen <dave.hansen(a)linux.intel.com>
Fixes: d5c8028b4788 ("x86/fpu: Reinitialize FPU registers if restoring FPU state fails")
Acked-by: Alison Schofield <alison.schofield(a)intel.com>
Cc: stable(a)vger.kernel.org
Cc: Eric Biggers <ebiggers(a)google.com>
Cc: Rik van Riel <riel(a)redhat.com>
Cc: Borislav Petkov <bp(a)alien8.de>
Cc: Chang S. Bae <chang.seok.bae(a)intel.com>
---
b/arch/x86/mm/extable.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff -puN arch/x86/mm/extable.c~fixup-fpu-gp-ip-later arch/x86/mm/extable.c
--- a/arch/x86/mm/extable.c~fixup-fpu-gp-ip-later 2025-06-24 13:58:09.722855233 -0700
+++ b/arch/x86/mm/extable.c 2025-06-24 13:58:09.736856435 -0700
@@ -122,13 +122,12 @@ static bool ex_handler_sgx(const struct
static bool ex_handler_fprestore(const struct exception_table_entry *fixup,
struct pt_regs *regs)
{
- regs->ip = ex_fixup_addr(fixup);
-
WARN_ONCE(1, "Bad FPU state detected at %pB, reinitializing FPU registers.",
(void *)instruction_pointer(regs));
fpu_reset_from_exception_fixup();
- return true;
+
+ return ex_handler_default(fixup, regs);
}
/*
_
'rx_ring->size' means the count of ring descriptors multiplied by the
size of one descriptor. When increasing the count of ring descriptors,
it may exceed the limit of pool size.
[ 864.209610] page_pool_create_percpu() gave up with errno -7
[ 864.209613] txgbe 0000:11:00.0: Page pool creation failed: -7
Fix to set the pool_size to the count of ring descriptors.
Fixes: 850b971110b2 ("net: libwx: Allocate Rx and Tx resources")
Cc: stable(a)vger.kernel.org
Signed-off-by: Jiawen Wu <jiawenwu(a)trustnetic.com>
---
drivers/net/ethernet/wangxun/libwx/wx_lib.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/wangxun/libwx/wx_lib.c b/drivers/net/ethernet/wangxun/libwx/wx_lib.c
index 7f2e6cddfeb1..c57cc4f27249 100644
--- a/drivers/net/ethernet/wangxun/libwx/wx_lib.c
+++ b/drivers/net/ethernet/wangxun/libwx/wx_lib.c
@@ -2623,7 +2623,7 @@ static int wx_alloc_page_pool(struct wx_ring *rx_ring)
struct page_pool_params pp_params = {
.flags = PP_FLAG_DMA_MAP | PP_FLAG_DMA_SYNC_DEV,
.order = 0,
- .pool_size = rx_ring->size,
+ .pool_size = rx_ring->count,
.nid = dev_to_node(rx_ring->dev),
.dev = rx_ring->dev,
.dma_dir = DMA_FROM_DEVICE,
--
2.48.1
The following commit has been merged into the x86/fpu branch of tip:
Commit-ID: 1cec9ac2d071cfd2da562241aab0ef701355762a
Gitweb: https://git.kernel.org/tip/1cec9ac2d071cfd2da562241aab0ef701355762a
Author: Dave Hansen <dave.hansen(a)linux.intel.com>
AuthorDate: Tue, 24 Jun 2025 14:01:48 -07:00
Committer: Dave Hansen <dave.hansen(a)linux.intel.com>
CommitterDate: Wed, 25 Jun 2025 16:28:06 -07:00
x86/fpu: Delay instruction pointer fixup until after warning
Right now, if XRSTOR fails a console message like this is be printed:
Bad FPU state detected at restore_fpregs_from_fpstate+0x9a/0x170, reinitializing FPU registers.
However, the text location (...+0x9a in this case) is the instruction
*AFTER* the XRSTOR. The highlighted instruction in the "Code:" dump
also points one instruction late.
The reason is that the "fixup" moves RIP up to pass the bad XRSTOR and
keep on running after returning from the #GP handler. But it does this
fixup before warning.
The resulting warning output is nonsensical because it looks like the
non-FPU-related instruction is #GP'ing.
Do not fix up RIP until after printing the warning. Do this by using
the more generic and standard ex_handler_default().
Fixes: d5c8028b4788 ("x86/fpu: Reinitialize FPU registers if restoring FPU state fails")
Signed-off-by: Dave Hansen <dave.hansen(a)linux.intel.com>
Reviewed-by: Chao Gao <chao.gao(a)intel.com>
Acked-by: Alison Schofield <alison.schofield(a)intel.com>
Acked-by: Peter Zijlstra (Intel) <peterz(a)infradead.org>
Cc:stable@vger.kernel.org
Link: https://lore.kernel.org/all/20250624210148.97126F9E%40davehans-spike.ostc.i…
---
arch/x86/mm/extable.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/arch/x86/mm/extable.c b/arch/x86/mm/extable.c
index bf8dab1..2fdc1f1 100644
--- a/arch/x86/mm/extable.c
+++ b/arch/x86/mm/extable.c
@@ -122,13 +122,12 @@ static bool ex_handler_sgx(const struct exception_table_entry *fixup,
static bool ex_handler_fprestore(const struct exception_table_entry *fixup,
struct pt_regs *regs)
{
- regs->ip = ex_fixup_addr(fixup);
-
WARN_ONCE(1, "Bad FPU state detected at %pB, reinitializing FPU registers.",
(void *)instruction_pointer(regs));
fpu_reset_from_exception_fixup();
- return true;
+
+ return ex_handler_default(fixup, regs);
}
/*
Hello Andy,
On Thu, Jun 26, 2025 at 12:39:26AM +0000, Andy Yang wrote:
> Thank you once again for your efforts on this patch. I also want to
> sincerely apologize for any inconvenience caused by the email reply
> incident.
Don't even think about it :)
We might have been able to avoid this extra fix,
but that's it. No biggie regardless.
Thank you for your help debugging this.
Kind regards,
Niklas
This patch series introduces a few minor fixes on Exynos7870 devices.
These fix USB gadget problems and serious crashes on certain variants of
devices. More information is provided in respective commits.
This series has no dependencies. Would be nice to get them merged in
6.16 itself. I assume it's okay to cc stable as the -rc releases are
also owned by the "Stable Group" in git.kernel.org... [1] [2]
[1] https://git.kernel.org/?q=Stable+Group
[2] https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Signed-off-by: Kaustabh Chakraborty <kauschluss(a)disroot.org>
---
Kaustabh Chakraborty (3):
arm64: dts: exynos7870: add quirk to disable USB2 LPM in gadget mode
arm64: dts: exynos7870-on7xelte: reduce memory ranges to base amount
arm64: dts: exynos7870-j6lte: reduce memory ranges to base amount
arch/arm64/boot/dts/exynos/exynos7870-j6lte.dts | 2 +-
arch/arm64/boot/dts/exynos/exynos7870-on7xelte.dts | 2 +-
arch/arm64/boot/dts/exynos/exynos7870.dtsi | 1 +
3 files changed, 3 insertions(+), 2 deletions(-)
---
base-commit: 1b152eeca84a02bdb648f16b82ef3394007a9dcf
change-id: 20250626-exynos7870-dts-fixes-e730f7086ddc
Best regards,
--
Kaustabh Chakraborty <kauschluss(a)disroot.org>
On 6/25/2025 3:15 AM, Baochen Qiang wrote:
>
>
> On 6/25/2025 5:51 PM, Johan Hovold wrote:
>> [ +CC: Gregoire ]
>>
>> On Fri, May 23, 2025 at 11:49:00AM +0800, Baochen Qiang wrote:
>>> We got report that WCN7850 is not working with IWD [1][2]. Debug
>>> shows the reason is that IWD installs group key before pairwise
>>> key, which goes against WCN7850's firmware.
>>>
>>> Reorder key install to workaround this.
>>>
>>> [1] https://bugzilla.kernel.org/show_bug.cgi?id=218733
>>> [2] https://lore.kernel.org/all/AS8P190MB12051DDBD84CD88E71C40AD7873F2@AS8P190M…
>>>
>>> Signed-off-by: Baochen Qiang <quic_bqiang(a)quicinc.com>
>>> ---
>>> ---
>>> Baochen Qiang (2):
>>> wifi: ath12k: avoid bit operation on key flags
>>> wifi: ath12k: install pairwise key first
>>
>> Thanks for fixing this, Baochen.
>>
>> I noticed the patches weren't clearly marked as fixes. Do you think we
>> should ask the stable team to backport these once they are in mainline
>> (e.g. after 6.17-rc1 is out)? Or do you think they are too intrusive and
>> risky to backport or similar?
>
> Yeah, I think they should be backported.
>
>>
>> [ Also please try to remember to CC any (public) reporters. I only found
>> out today that this had been addressed in linux-next. ]
>
> Thanks, will keep in mind.
+Stable team,
Per the above discussion please backport the series:
https://msgid.link/20250523-ath12k-unicast-key-first-v1-0-f53c3880e6d8@quic…
This is a 0-day issue so ideally this should be backported from 6.6+
/jeff
Hi Igor,
[For context, there was a regression report in Debian at
https://bugs.debian.org/1108069]
On Thu, Jun 19, 2025 at 09:36:13PM -0500, Igor Tamara wrote:
> Package: src:linux
> Version: 6.12.32-1
> Severity: normal
> Tags: a11y
>
> Dear Maintainer,
>
> The builtin microphone on my Asus X507UA does not record, is
> recognized and some time ago it worked on Bookworm with image-6.1.0-31,
> newer images are able to record when appending snd_hda_intel.model=1043:1271
> to the boot as a workaround.
>
> The images that work with the boot option appended are, but not without
> it are:
>
> linux-image-6.15-amd64
> linux-image-6.12.32-amd64
> linux-image-6.1.0-37-amd64
> linux-image-6.1.0-0.a.test-amd64-unsigned_6.1.129-1a~test_amd64.deb
> referenced by https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1100928
> Also compiled from upstream 6.12.22 and 6.1.133 with the same result
>
> The image linux-image-6.1.0-31-amd64 worked properly, the problem was
> introduced in 129 and the result of the bisect was
>
> d26408df0e25f2bd2808d235232ab776e4dd08b9 is the first bad commit
> commit d26408df0e25f2bd2808d235232ab776e4dd08b9
> Author: Kuan-Wei Chiu <visitorckw(a)gmail.com>
> Date: Wed Jan 29 00:54:15 2025 +0800
>
> ALSA: hda: Fix headset detection failure due to unstable sort
>
> commit 3b4309546b48fc167aa615a2d881a09c0a97971f upstream.
>
> The auto_parser assumed sort() was stable, but the kernel's sort() uses
> heapsort, which has never been stable. After commit 0e02ca29a563
> ("lib/sort: optimize heapsort with double-pop variation"), the order of
> equal elements changed, causing the headset to fail to work.
>
> Fix the issue by recording the original order of elements before
> sorting and using it as a tiebreaker for equal elements in the
> comparison function.
>
> Fixes: b9030a005d58 ("ALSA: hda - Use standard sort function in hda_auto_parser.c")
> Reported-by: Austrum <austrum.lab(a)gmail.com>
> Closes: https://bugzilla.kernel.org/show_bug.cgi?id=219158
> Tested-by: Austrum <austrum.lab(a)gmail.com>
> Cc: stable(a)vger.kernel.org
> Signed-off-by: Kuan-Wei Chiu <visitorckw(a)gmail.com>
> Link: https://patch.msgid.link/20250128165415.643223-1-visitorckw@gmail.com
> Signed-off-by: Takashi Iwai <tiwai(a)suse.de>
> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
>
> sound/pci/hda/hda_auto_parser.c | 8 +++++++-
> sound/pci/hda/hda_auto_parser.h | 1 +
> 2 files changed, 8 insertions(+), 1 deletion(-)
>
> I'm attaching the output of alsa-info_alsa-info.sh script
>
> Please let me know if I can provide more information.
Might you be able to try please the attached patch to see if it fixes
the issue?
Regards,
Salvatore