Skip to content

[pull] master from torvalds:master #1966

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom
Merged
merged 17 commits into from
Jun 29, 2025
Merged

[pull] master from torvalds:master #1966

merged 17 commits into from
Jun 29, 2025

Conversation

pull[bot]
Copy link

@pull pull bot commented Jun 29, 2025 •
edited
Loading

See Commits and Changes for more details.

Created by pull[bot] (v2.0.0-alpha.2)

Can you help keep this open source service alive? 💖 Please sponsor : )

Nicolas Pitre and others added 17 commits June 19, 2025 13:27
@gregkh
vt: add missing notification when switching back to text mode
ff78538 
Programs using poll() on /dev/vcsa to be notified when VT changes occur
were missing one case: the switch from gfx to text mode.

Signed-off-by: Nicolas Pitre <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Greg Kroah-Hartman <[email protected]>
@rddunlap @gregkh
vt: fix kernel-doc warnings in ucs_get_fallback()
747b524 
Use the correct function parameter name in ucs_get_fallback() to prevent
kernel-doc warnings:

Warning: drivers/tty/vt/ucs.c:218 function parameter 'cp' not described in 'ucs_get_fallback'
Warning: drivers/tty/vt/ucs.c:218 Excess function parameter 'base' description in 'ucs_get_fallback'

Fixes: fe26933 ("vt: add ucs_get_fallback()")
Signed-off-by: Randy Dunlap <[email protected]>
Cc: Nicolas Pitre <[email protected]>
Cc: Greg Kroah-Hartman <[email protected]>
Cc: Jiri Slaby <[email protected]>
Cc: [email protected]
Reviewed-by: Nicolas Pitre <[email protected]>.
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Greg Kroah-Hartman <[email protected]>
@astew-tek @gregkh
serial: core: restore of_node information in sysfs
d36f0e9 
Since in v6.8-rc1, the of_node symlink under tty devices is
missing. This breaks any udev rules relying on this information.

Link the of_node information in the serial controller device with the
parent defined in the device tree. This will also apply to the serial
device which takes the serial controller as a parent device.

Fixes: b286f4e ("serial: core: Move tty and serdev to be children of serial core port device")
Cc: [email protected]
Signed-off-by: Aidan Stewart <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Greg Kroah-Hartman <[email protected]>
@nathanchance @gregkh
staging: rtl8723bs: Avoid memset() in aes_cipher() and aes_decipher()
a55bc4f 
After commit 6f110a5 ("Disable SLUB_TINY for build testing"), which
causes CONFIG_KASAN to be enabled in allmodconfig again, arm64
allmodconfig builds with older versions of clang (15 through 17) show an
instance of -Wframe-larger-than (which breaks the build with
CONFIG_WERROR=y):

  drivers/staging/rtl8723bs/core/rtw_security.c:1287:5: error: stack frame size (2208) exceeds limit (2048) in 'rtw_aes_decrypt' [-Werror,-Wframe-larger-than]
   1287 | u32 rtw_aes_decrypt(struct adapter *padapter, u8 *precvframe)
        |     ^

This comes from aes_decipher() being inlined in rtw_aes_decrypt().
Running the same build with CONFIG_FRAME_WARN=128 shows aes_cipher()
also uses a decent amount of stack, just under the limit of 2048:

  drivers/staging/rtl8723bs/core/rtw_security.c:864:19: warning: stack frame size (1952) exceeds limit (128) in 'aes_cipher' [-Wframe-larger-than]
    864 | static signed int aes_cipher(u8 *key, uint      hdrlen,
        |                   ^

-Rpass-analysis=stack-frame-layout only shows one large structure on the
stack, which is the ctx variable inlined from aes128k128d(). A good
number of the other variables come from the additional checks of
fortified string routines, which are present in memset(), which both
aes_cipher() and aes_decipher() use to initialize some temporary
buffers. In this case, since the size is known at compile time, these
additional checks should not result in any code generation changes but
allmodconfig has several sanitizers enabled, which may make it harder
for the compiler to eliminate the compile time checks and the variables
that come about from them.

The memset() calls are just initializing these buffers to zero, so use
'= {}' instead, which is used all over the kernel and does the exact
same thing as memset() without the fortify checks, which drops the stack
usage of these functions by a few hundred kilobytes.

  drivers/staging/rtl8723bs/core/rtw_security.c:864:19: warning: stack frame size (1584) exceeds limit (128) in 'aes_cipher' [-Wframe-larger-than]
    864 | static signed int aes_cipher(u8 *key, uint      hdrlen,
        |                   ^
  drivers/staging/rtl8723bs/core/rtw_security.c:1271:5: warning: stack frame size (1456) exceeds limit (128) in 'rtw_aes_decrypt' [-Wframe-larger-than]
   1271 | u32 rtw_aes_decrypt(struct adapter *padapter, u8 *precvframe)
        |     ^

Cc: [email protected]
Fixes: 554c0a3 ("staging: Add rtl8723bs sdio wifi driver")
Signed-off-by: Nathan Chancellor <[email protected]>
Reviewed-by: Dan Carpenter <[email protected]>
Link: https://lore.kernel.org/r/20250609-rtl8723bs-fix-clang-arm64-wflt-v1-1-e2accba43def@kernel.org
Signed-off-by: Greg Kroah-Hartman <[email protected]>
futex: Initialize futex_phash_new during fork().
a24cc6c 
During a hash resize operation the new private hash is stored in
mm_struct::futex_phash_new if the current hash can not be immediately
replaced.

The new hash must not be copied during fork() into the new task. Doing
so will lead to a double-free of the memory by the two tasks.

Initialize the mm_struct::futex_phash_new during fork().

Closes: https://lore.kernel.org/all/[email protected]/
Fixes: bd54df5 ("futex: Allow to resize the private local hash")
Reported-by: Calvin Owens <[email protected]>
Signed-off-by: Sebastian Andrzej Siewior <[email protected]>
Signed-off-by: Peter Zijlstra (Intel) <[email protected]>
Tested-by: Calvin Owens <[email protected]>
Link: https://lkml.kernel.org/r/[email protected]
@fabioestevam @gregkh
serial: imx: Restore original RXTL for console to fix data loss
f23c52a 
Commit 7a63778 ("serial: imx: reduce RX interrupt frequency")
introduced a regression on the i.MX6UL EVK board. The issue can be
reproduced with the following steps:

- Open vi on the board.
- Paste a text file (~150 characters).
- Save the file, then repeat the process.
- Compare the sha256sum of the saved files.

The checksums do not match due to missing characters or entire lines.

Fix this by restoring the RXTL value to 1 when the UART is used as a
console.

This ensures timely RX interrupts and reliable data reception in console
mode.

With this change, pasted content is saved correctly, and checksums are
always consistent.

Cc: stable <[email protected]>
Fixes: 7a63778 ("serial: imx: reduce RX interrupt frequency")
Signed-off-by: Fabio Estevam <[email protected]>
Reviewed-by: Stefan Wahren <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Greg Kroah-Hartman <[email protected]>
@ziyao233 @gregkh
dt-bindings: serial: 8250: Make clocks and clock-frequency exclusive
0981213 
The 8250 binding before converting to json-schema states,

  - clock-frequency : the input clock frequency for the UART
  	or
  - clocks phandle to refer to the clk used as per Documentation/devicetree

for clock-related properties, where "or" indicates these properties
shouldn't exist at the same time.

Additionally, the behavior of Linux's driver is strange when both clocks
and clock-frequency are specified: it ignores clocks and obtains the
frequency from clock-frequency, left the specified clocks unclaimed. It
may even be disabled, which is undesired most of the time.

But "anyOf" doesn't prevent these two properties from coexisting, as it
considers the object valid as long as there's at LEAST one match.

Let's switch to "oneOf" and disallows the other property if one exists,
precisely matching the original binding and avoiding future confusion on
the driver's behavior.

Fixes: e69f5dc ("dt-bindings: serial: Convert 8250 to json-schema")
Cc: stable <[email protected]>
Signed-off-by: Yao Zi <[email protected]>
Reviewed-by: Conor Dooley <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Greg Kroah-Hartman <[email protected]>
@xinli-intel @hansendc
x86/traps: Initialize DR6 by writing its architectural reset value
5f465c1 
Initialize DR6 by writing its architectural reset value to avoid
incorrectly zeroing DR6 to clear DR6.BLD at boot time, which leads
to a false bus lock detected warning.

The Intel SDM says:

  1) Certain debug exceptions may clear bits 0-3 of DR6.

  2) BLD induced #DB clears DR6.BLD and any other debug exception
     doesn't modify DR6.BLD.

  3) RTM induced #DB clears DR6.RTM and any other debug exception
     sets DR6.RTM.

  To avoid confusion in identifying debug exceptions, debug handlers
  should set DR6.BLD and DR6.RTM, and clear other DR6 bits before
  returning.

The DR6 architectural reset value 0xFFFF0FF0, already defined as
macro DR6_RESERVED, satisfies these requirements, so just use it to
reinitialize DR6 whenever needed.

Since clear_all_debug_regs() no longer zeros all debug registers,
rename it to initialize_debug_regs() to better reflect its current
behavior.

Since debug_read_clear_dr6() no longer clears DR6, rename it to
debug_read_reset_dr6() to better reflect its current behavior.

Fixes: ebb1064 ("x86/traps: Handle #DB for bus lock")
Reported-by: Sohil Mehta <[email protected]>
Suggested-by: H. Peter Anvin (Intel) <[email protected]>
Signed-off-by: Xin Li (Intel) <[email protected]>
Signed-off-by: Dave Hansen <[email protected]>
Reviewed-by: H. Peter Anvin (Intel) <[email protected]>
Reviewed-by: Sohil Mehta <[email protected]>
Acked-by: Peter Zijlstra (Intel) <[email protected]>
Tested-by: Sohil Mehta <[email protected]>
Link: https://lore.kernel.org/lkml/[email protected]/
Cc:[email protected]
Link: https://lore.kernel.org/all/20250620231504.2676902-2-xin%40zytor.com
@xinli-intel @hansendc
x86/traps: Initialize DR7 by writing its architectural reset value
fa7d0f8 
Initialize DR7 by writing its architectural reset value to always set
bit 10, which is reserved to '1', when "clearing" DR7 so as not to
trigger unanticipated behavior if said bit is ever unreserved, e.g. as
a feature enabling flag with inverted polarity.

Signed-off-by: Xin Li (Intel) <[email protected]>
Signed-off-by: Dave Hansen <[email protected]>
Reviewed-by: H. Peter Anvin (Intel) <[email protected]>
Reviewed-by: Sohil Mehta <[email protected]>
Acked-by: Peter Zijlstra (Intel) <[email protected]>
Acked-by: Sean Christopherson <[email protected]>
Tested-by: Sohil Mehta <[email protected]>
Cc:[email protected]
Link: https://lore.kernel.org/all/20250620231504.2676902-3-xin%40zytor.com
@bp3tk0v
EDAC/amd64: Fix size calculation for Non-Power-of-Two DIMMs
a3f3040 
Each Chip-Select (CS) of a Unified Memory Controller (UMC) on AMD Zen-based
SOCs has an Address Mask and a Secondary Address Mask register associated with
it. The amd64_edac module logs DIMM sizes on a per-UMC per-CS granularity
during init using these two registers.

Currently, the module primarily considers only the Address Mask register for
computing DIMM sizes. The Secondary Address Mask register is only considered
for odd CS. Additionally, if it has been considered, the Address Mask register
is ignored altogether for that CS. For power-of-two DIMMs i.e. DIMMs whose
total capacity is a power of two (32GB, 64GB, etc), this is not an issue
since only the Address Mask register is used.

For non-power-of-two DIMMs i.e., DIMMs whose total capacity is not a power of
two (48GB, 96GB, etc), however, the Secondary Address Mask register is used
in conjunction with the Address Mask register. However, since the module only
considers either of the two registers for a CS, the size computed by the
module is incorrect. The Secondary Address Mask register is not considered for
even CS, and the Address Mask register is not considered for odd CS.

Introduce a new helper function so that both Address Mask and Secondary
Address Mask registers are considered, when valid, for computing DIMM sizes.
Furthermore, also rename some variables for greater clarity.

Fixes: 81f5090 ("EDAC/amd64: Support asymmetric dual-rank DIMMs")
Closes: https://lore.kernel.org/[email protected]
Reported-by: Žilvinas Žaltiena <[email protected]>
Signed-off-by: Avadhut Naik <[email protected]>
Signed-off-by: Borislav Petkov (AMD) <[email protected]>
Reviewed-by: Yazen Ghannam <[email protected]>
Tested-by: Žilvinas Žaltiena <[email protected]>
Cc: [email protected]
Link: https://lore.kernel.org/[email protected]
@Leo-Yan
perf/aux: Fix pending disable flow when the AUX ring buffer overruns
1476b21 
If an AUX event overruns, the event core layer intends to disable the
event by setting the 'pending_disable' flag. Unfortunately, the event
is not actually disabled afterwards.

In commit:

  ca6c213 ("perf: Fix missing SIGTRAPs")

the 'pending_disable' flag was changed to a boolean. However, the
AUX event code was not updated accordingly. The flag ends up holding a
CPU number. If this number is zero, the flag is taken as false and the
IRQ work is never triggered.

Later, with commit:

  2b84def ("perf: Split __perf_pending_irq() out of perf_pending_irq()")

a new IRQ work 'pending_disable_irq' was introduced to handle event
disabling. The AUX event path was not updated to kick off the work queue.

To fix this bug, when an AUX ring buffer overrun is detected, call
perf_event_disable_inatomic() to initiate the pending disable flow.

Also update the outdated comment for setting the flag, to reflect the
boolean values (0 or 1).

Fixes: 2b84def ("perf: Split __perf_pending_irq() out of perf_pending_irq()")
Fixes: ca6c213 ("perf: Fix missing SIGTRAPs")
Signed-off-by: Leo Yan <[email protected]>
Signed-off-by: Ingo Molnar <[email protected]>
Reviewed-by: James Clark <[email protected]>
Reviewed-by: Yeoreum Yun <[email protected]>
Cc: Adrian Hunter <[email protected]>
Cc: Alexander Shishkin <[email protected]>
Cc: Arnaldo Carvalho de Melo <[email protected]>
Cc: Ian Rogers <[email protected]>
Cc: Jiri Olsa <[email protected]>
Cc: Liang Kan <[email protected]>
Cc: Marco Elver <[email protected]>
Cc: Mark Rutland <[email protected]>
Cc: Namhyung Kim <[email protected]>
Cc: Peter Zijlstra <[email protected]>
Cc: Sebastian Andrzej Siewior <[email protected]>
Cc: [email protected]
Link: https://lore.kernel.org/r/[email protected]
@torvalds
Merge tag 'locking_urgent_for_v6.16_rc4' of git://git.kernel.org/pub/…
753a0f6 
…scm/linux/kernel/git/tip/tip

Pull locking fix from Borislav Petkov:

 - Make sure the new futex phash is not copied during fork in order to
   avoid a double-free

* tag 'locking_urgent_for_v6.16_rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
  futex: Initialize futex_phash_new during fork().
@torvalds
Merge tag 'perf_urgent_for_v6.16_rc4' of git://git.kernel.org/pub/scm…
2fc18d0 
…/linux/kernel/git/tip/tip

Pull perf fix from Borislav Petkov:

 - Make sure an AUX perf event is really disabled when it overruns

* tag 'perf_urgent_for_v6.16_rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
  perf/aux: Fix pending disable flow when the AUX ring buffer overruns
@torvalds
Merge tag 'x86_urgent_for_v6.16_rc4' of git://git.kernel.org/pub/scm/…
cc69ac7 
…linux/kernel/git/tip/tip

Pull x86 fixes from Borislav Petkov:

 - Make sure DR6 and DR7 are initialized to their architectural values
   and not accidentally cleared, leading to misconfigurations

* tag 'x86_urgent_for_v6.16_rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
  x86/traps: Initialize DR7 by writing its architectural reset value
  x86/traps: Initialize DR6 by writing its architectural reset value
@torvalds
Merge tag 'edac_urgent_for_v6.16_rc4' of git://git.kernel.org/pub/scm…
3b1890e 
…/linux/kernel/git/ras/ras

Pull EDAC fix from Borislav Petkov:

 - Consider secondary address mask registers in amd64_edac in order to
   get the correct total memory size of the system

* tag 'edac_urgent_for_v6.16_rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/ras/ras:
  EDAC/amd64: Fix size calculation for Non-Power-of-Two DIMMs
@torvalds
Merge tag 'tty-6.16-rc4' of git://git.kernel.org/pub/scm/linux/kernel…
798804b 
…/git/gregkh/tty

Pull tty/serial driver fixes from Greg KH:
 "Here are five small serial and tty and vt fixes for 6.16-rc4. Included
  in here are:

   - kerneldoc fixes for recent vt changes

   - imx serial driver fix

   - of_node sysfs fix for a regression

   - vt missing notification fix

   - 8250 dt bindings fix

  All of these have been in linux-next for a while with no reported issues"

* tag 'tty-6.16-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/tty:
  dt-bindings: serial: 8250: Make clocks and clock-frequency exclusive
  serial: imx: Restore original RXTL for console to fix data loss
  serial: core: restore of_node information in sysfs
  vt: fix kernel-doc warnings in ucs_get_fallback()
  vt: add missing notification when switching back to text mode
@torvalds
Merge tag 'staging-6.16-rc4' of git://git.kernel.org/pub/scm/linux/ke…
afa9a6f 
…rnel/git/gregkh/staging

Pull staging driver fix from Greg KH:
 "Here is a single staging driver fix for 6.16-rc4. It resolves a build
  error in the rtl8723bs driver for some versions of clang on arm64 when
  checking the frame size with -Wframe-larger-than.

  It has been in linux-next for a while now with no reported issues"

* tag 'staging-6.16-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging:
  staging: rtl8723bs: Avoid memset() in aes_cipher() and aes_decipher()
@pull pull bot locked and limited conversation to collaborators Jun 29, 2025
@pull pull bot added the ⤵️ pull label Jun 29, 2025
@pull pull bot merged commit afa9a6f into AwesomeGitHubRepos:master Jun 29, 2025
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Reviewers
No reviews
Assignees
No one assigned
Labels
⤵️ pull
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.
8 participants
@rddunlap @astew-tek @nathanchance @fabioestevam @ziyao233 @xinli-intel @Leo-Yan @torvalds