linux.git, branch v6.1.168

Linux 6.1.168

2026-04-11T12:16:39+00:00

Link: https://lore.kernel.org/r/20260408175933.715315542@linuxfoundation.org
Tested-by: Francesco Dolcini 
Tested-by: Peter Schneider 
Tested-by: Pavel Machek (CIP) 
Tested-by: Ron Economos 
Tested-by: Jon Hunter 
Tested-by: Salvatore Bonaccorso 
Tested-by: Miguel Ojeda 
Tested-by: Florian Fainelli 
Tested-by: Shuah Khan 
Tested-by: Barry K. Nathan 
Tested-by: Josh Law 
Signed-off-by: Greg Kroah-Hartman

ACPI: EC: Evaluate orphan _REG under EC device

2026-04-11T12:16:39+00:00

commit 0e6b6dedf16800df0ff73ffe2bb5066514db29c2 upstream.

After starting to install the EC address space handler at the ACPI
namespace root, if there is an "orphan" _REG method in the EC device's
scope, it will not be evaluated any more.  This breaks EC operation
regions on some systems, like Asus gu605.

To address this, use a wrapper around an existing ACPICA function to
look for an "orphan" _REG method in the EC device scope and evaluate
it if present.

Fixes: 60fa6ae6e6d0 ("ACPI: EC: Install address space handler at the namespace root")
Closes: https://bugzilla.kernel.org/show_bug.cgi?id=218945
Reported-by: VitaliiT 
Tested-by: VitaliiT 
Signed-off-by: Rafael J. Wysocki 
Signed-off-by: Greg Kroah-Hartman

ext4: fix unused iterator variable warnings

2026-04-11T12:16:38+00:00

commit 856dd6c5981260b4d1aa84b78373ad54a203db48 upstream.

When CONFIG_QUOTA is disabled, there are warnings around unused iterator
variables:

  fs/ext4/super.c: In function 'ext4_put_super':
  fs/ext4/super.c:1262:13: error: unused variable 'i' [-Werror=unused-variable]
   1262 |         int i, err;
        |             ^
  fs/ext4/super.c: In function '__ext4_fill_super':
  fs/ext4/super.c:5200:22: error: unused variable 'i' [-Werror=unused-variable]
   5200 |         unsigned int i;
        |                      ^
  cc1: all warnings being treated as errors

The kernel has updated to GNU11, allowing the variables to be declared
within the for loop.  Do so to clear up the warnings.

Fixes: dcbf87589d90 ("ext4: factor out ext4_flex_groups_free()")
Signed-off-by: Nathan Chancellor 
Reviewed-by: Geert Uytterhoeven 
Reviewed-by: Jan Kara 
Reviewed-by: Jason Yan 
Link: https://lore.kernel.org/r/20230420-ext4-unused-variables-super-c-v1-1-138b6db6c21c@kernel.org
Signed-off-by: Theodore Ts'o 
Signed-off-by: Greg Kroah-Hartman

ext4: fix lost error code reporting in __ext4_fill_super()

2026-04-11T12:16:38+00:00

commit d5e72c4e3256335d6fb75c2e321144f93141f4f5 upstream.

When code was factored out of __ext4_fill_super() into
ext4_percpu_param_init() the error return was discarded.  This meant
that it was possible for __ext4_fill_super() to return zero,
indicating success, without the struct super getting completely filled
in, leading to a potential NULL pointer dereference.

Reported-by: syzbot+bbf0f9a213c94f283a5c@syzkaller.appspotmail.com
Fixes: 1f79467c8a6b ("ext4: factor out ext4_percpu_param_init() ...")
Link: https://syzkaller.appspot.com/bug?id=6dac47d5e58af770c0055f680369586ec32e144c
Signed-off-by: Theodore Ts'o 
Reviewed-by: Jason Yan 
Signed-off-by: Greg Kroah-Hartman

block: Fix the blk_mq_destroy_queue() documentation

2026-04-11T12:16:38+00:00

commit 81ea42b9c3d61ea34d82d900ed93f4b4851f13b0 upstream.

Commit 2b3f056f72e5 moved a blk_put_queue() call from
blk_mq_destroy_queue() into its callers. Reflect this change in the
documentation block above blk_mq_destroy_queue().

Cc: Christoph Hellwig 
Cc: Sagi Grimberg 
Cc: Chaitanya Kulkarni 
Cc: Keith Busch 
Fixes: 2b3f056f72e5 ("blk-mq: move the call to blk_put_queue out of blk_mq_destroy_queue")
Signed-off-by: Bart Van Assche 
Reviewed-by: Christoph Hellwig 
Link: https://lore.kernel.org/r/20230130211233.831613-1-bvanassche@acm.org
Signed-off-by: Jens Axboe 
Signed-off-by: Greg Kroah-Hartman

Bluetooth: eir: Fix possible crashes on eir_create_adv_data

2026-04-11T12:16:38+00:00

[ Upstream commit 47c03902269aff377f959dc3fd94a9733aa31d6e ]

eir_create_adv_data may attempt to add EIR_FLAGS and EIR_TX_POWER
without checking if that would fit.

Link: https://github.com/bluez/bluez/issues/1117#issuecomment-2958244066
Fixes: 01ce70b0a274 ("Bluetooth: eir: Move EIR/Adv Data functions to its own file")
Signed-off-by: Luiz Augusto von Dentz 
[ Use pdu.data instead of pdu->data in hci_set_ext_adv_data_sync()
 to keep context consistency. ]
Signed-off-by: Robert Garcia 
Signed-off-by: Greg Kroah-Hartman

selftests: mptcp: join: check removing signal+subflow endp

2026-04-11T12:16:38+00:00

commit 1777f349ff41b62dfe27454b69c27b0bc99ffca5 upstream.

This validates the previous commit: endpoints with both the signal and
subflow flags should always be marked as used even if it was not
possible to create new subflows due to the MPTCP PM limits.

For this test, an extra endpoint is created with both the signal and the
subflow flags, and limits are set not to create extra subflows. In this
case, an ADD_ADDR is sent, but no subflows are created. Still, the local
endpoint is marked as used, and no warning is fired when removing the
endpoint, after having sent a RM_ADDR.

The 'Fixes' tag here below is the same as the one from the previous
commit: this patch here is not fixing anything wrong in the selftests,
but it validates the previous fix for an issue introduced by this commit
ID.

Fixes: 85df533a787b ("mptcp: pm: do not ignore 'subflow' if 'signal' flag is also set")
Cc: stable@vger.kernel.org
Reviewed-by: Mat Martineau 
Signed-off-by: Matthieu Baerts (NGI0) 
Link: https://patch.msgid.link/20260303-net-mptcp-misc-fixes-7-0-rc2-v1-5-4b5462b6f016@kernel.org
Signed-off-by: Jakub Kicinski 
[ No conflicts, but in this kernel version 'run_tests' doesn't support
  parameters set via env vars: positional parameters need to be used.
  See commit 595ef566a2ef ("selftests: mptcp: drop addr_nr_ns1/2
  parameters") and commit e571fb09c893 ("selftests: mptcp: add speed env
  var") which are not in this kernel version. ]
Signed-off-by: Matthieu Baerts (NGI0) 
Signed-off-by: Greg Kroah-Hartman

selftests: mptcp: join: implicit: stop transfer after last check

2026-04-11T12:16:38+00:00

With this kernel version, the 'implicit EP' MPTCP Join selftest ended
with an error message:

  115 implicit EP                          creation[ ok ]
                                           ID change is prevented[ ok ]
                                           modif is allowed[ ok ]
  TcpPassiveOpens                 2                  0.0
  TcpEstabResets                  2                  0.0
  TcpInSegs                       315                0.0
  TcpOutSegs                      617                0.0
  TcpOutRsts                      1                  0.0
  TcpExtDelayedACKs               289                0.0
  TcpExtTCPPureAcks               6                  0.0
  TcpExtTCPOrigDataSent           306                0.0
  TcpExtTCPDelivered              306                0.0
  MPTcpExtMPCapableSYNRX          1                  0.0
  MPTcpExtMPCapableACKRX          1                  0.0
  MPTcpExtMPJoinSynRx             1                  0.0
  MPTcpExtMPJoinAckRx             1                  0.0
  MPTcpExtAddAddr                 1                  0.0
  MPTcpExtEchoAdd                 1                  0.0
  MPTcpExtMPFastcloseTx           1                  0.0
  MPTcpExtMPRstTx                 1                  0.0
  MPTcpExtMPRstRx                 1                  0.0
  TcpActiveOpens                  2                  0.0
  TcpEstabResets                  2                  0.0
  TcpInSegs                       617                0.0
  TcpOutSegs                      315                0.0
  TcpOutRsts                      1                  0.0
  TcpExtTCPPureAcks               308                0.0
  TcpExtTCPOrigDataSent           306                0.0
  TcpExtTCPDelivered              307                0.0
  MPTcpExtMPCapableSYNTX          1                  0.0
  MPTcpExtMPCapableSYNACKRX       1                  0.0
  MPTcpExtMPJoinSynAckRx          1                  0.0
  MPTcpExtAddAddr                 1                  0.0
  MPTcpExtEchoAdd                 1                  0.0
  MPTcpExtMPFastcloseRx           1                  0.0
  MPTcpExtMPRstTx                 1                  0.0
  MPTcpExtMPRstRx                 1                  0.0
  MPTcpExtRcvWndShared            1                  0.0

That's because the test was waiting for the end of the transfer for no
reasons, which ended after a timeout with an error. In this case, the
stats were displayed, but this error was ignored: the end of transfer is
not validated in this test.

To fix that, stop the transfer after the last check, similar to what is
done in the other tests.

Fixes: 699879d5f866 ("selftests: mptcp: join: endpoints: longer transfer")
Signed-off-by: Matthieu Baerts (NGI0) 
Signed-off-by: Greg Kroah-Hartman

gfs2: Fix unlikely race in gdlm_put_lock

2026-04-11T12:16:38+00:00

[ Upstream commit 28c4d9bc0708956c1a736a9e49fee71b65deee81 ]

In gdlm_put_lock(), there is a small window of time in which the
DFL_UNMOUNT flag has been set but the lockspace hasn't been released,
yet.  In that window, dlm may still call gdlm_ast() and gdlm_bast().
To prevent it from dereferencing freed glock objects, only free the
glock if the lockspace has actually been released.

Signed-off-by: Andreas Gruenbacher 
Reviewed-by: Andrew Price 
[ Minor context change fixed. ]
Signed-off-by: Robert Garcia 
Signed-off-by: Greg Kroah-Hartman

net: phy: fix phy_uses_state_machine()

2026-04-11T12:16:38+00:00

[ Upstream commit e0d1c55501d377163eb57feed863777ed1c973ad ]

The blamed commit changed the conditions which phylib uses to stop
and start the state machine in the suspend and resume paths, and
while improving it, has caused two issues.

The original code used this test:

	phydev->attached_dev && phydev->adjust_link

and if true, the paths would handle the PHY state machine. This test
evaluates true for normal drivers that are using phylib directly
while the PHY is attached to the network device, but false in all
other cases, which include the following cases:

- when the PHY has never been attached to a network device.
- when the PHY has been detached from a network device (as phy_detach()
   sets phydev->attached_dev to NULL, phy_disconnect() calls
   phy_detach() and additionally sets phydev->adjust_link NULL.)
- when phylink is using the driver (as phydev->adjust_link is NULL.)

Only the third case was incorrect, and the blamed commit attempted to
fix this by changing this test to (simplified for brevity, see
phy_uses_state_machine()):

	phydev->phy_link_change == phy_link_change ?
		phydev->attached_dev && phydev->adjust_link : true

However, this also incorrectly evaluates true in the first two cases.

Fix the first case by ensuring that phy_uses_state_machine() returns
false when phydev->phy_link_change is NULL.

Fix the second case by ensuring that phydev->phy_link_change is set to
NULL when phy_detach() is called.

Reported-by: Xu Yang 
Link: https://lore.kernel.org/r/20250806082931.3289134-1-xu.yang_2@nxp.com
Fixes: fc75ea20ffb4 ("net: phy: allow MDIO bus PM ops to start/stop state machine for phylink-controlled PHY")
Signed-off-by: Russell King (Oracle) 
Reviewed-by: Vladimir Oltean 
Link: https://patch.msgid.link/E1uvMEz-00000003Aoe-3qWe@rmk-PC.armlinux.org.uk
Signed-off-by: Jakub Kicinski 
Signed-off-by: Rajani Kantha <681739313@139.com>
Signed-off-by: Greg Kroah-Hartman