commit: 10685681bafc ("net_sched: sch_sfq: don't allow 1 packet limit")
fixes CVE-2024-57996 and commit: b3bf8f63e617 ("net_sched: sch_sfq: move
the limit validation") fixes CVE-2025-37752.
Patches 3 and 5 are CVE fixes for above mentioned CVEs. Patch 1,2 and 4
are pulled in as stable-deps.
Testing performed on the patched 5.10.238 kernel with the above 5
patches: (Used latest upstream kselftests for tc-testing)
# uname -a
Linux hamogala-vm-6 5.10.238+ #2 SMP Sun Jun 15 17:27:54 GMT 2025 x86_64 x86_64 x86_64 GNU/Linux
# ./tdc.py -f tc-tests/qdiscs/sfq.json
-- ns/SubPlugin.__init__
Test 7482: Create SFQ with default setting
Test c186: Create SFQ with limit setting
Test ae23: Create SFQ with perturb setting
Test a430: Create SFQ with quantum setting
Test 4539: Create SFQ with divisor setting
Test b089: Create SFQ with flows setting
Test 99a0: Create SFQ with depth setting
Test 7389: Create SFQ with headdrop setting
Test 6472: Create SFQ with redflowlimit setting
Test 8929: Show SFQ class
Test 4d6f: Check that limit of 1 is rejected
Test 7f8f: Check that a derived limit of 1 is rejected (limit 2 depth 1 flows 1)
Test 5168: Check that a derived limit of 1 is rejected (limit 2 depth 1 divisor 1)
All test results:
1..13
ok 1 7482 - Create SFQ with default setting
ok 2 c186 - Create SFQ with limit setting
ok 3 ae23 - Create SFQ with perturb setting
ok 4 a430 - Create SFQ with quantum setting
ok 5 4539 - Create SFQ with divisor setting
ok 6 b089 - Create SFQ with flows setting
ok 7 99a0 - Create SFQ with depth setting
ok 8 7389 - Create SFQ with headdrop setting
ok 9 6472 - Create SFQ with redflowlimit setting
ok 10 8929 - Show SFQ class
ok 11 4d6f - Check that limit of 1 is rejected
ok 12 7f8f - Check that a derived limit of 1 is rejected (limit 2 depth 1 flows 1)
ok 13 5168 - Check that a derived limit of 1 is rejected (limit 2 depth 1 divisor 1)
Thanks,
Harshit
Eric Dumazet (2):
net_sched: sch_sfq: annotate data-races around q->perturb_period
net_sched: sch_sfq: handle bigger packets
Octavian Purdila (3):
net_sched: sch_sfq: don't allow 1 packet limit
net_sched: sch_sfq: use a temporary work area for validating
configuration
net_sched: sch_sfq: move the limit validation
net/sched/sch_sfq.c | 112 ++++++++++++++++++++++++++++----------------
1 file changed, 71 insertions(+), 41 deletions(-)
--
2.47.1
When transitioning from USB_ROLE_DEVICE to USB_ROLE_NONE, the code
assumed that the regulator should be disabled. However, if the regulator
is marked as always-on, regulator_is_enabled() continues to return true,
leading to an incorrect attempt to disable a regulator which is not
enabled.
This can result in warnings such as:
[ 250.155624] WARNING: CPU: 1 PID: 7326 at drivers/regulator/core.c:3004
_regulator_disable+0xe4/0x1a0
[ 250.155652] unbalanced disables for VIN_SYS_5V0
To fix this, we move the regulator control logic into
tegra186_xusb_padctl_id_override() function since it's directly related
to the ID override state. The regulator is now only disabled when the role
transitions from USB_ROLE_HOST to USB_ROLE_NONE, by checking the VBUS_ID
register. This ensures that regulator enable/disable operations are
properly balanced and only occur when actually transitioning to/from host
mode.
Fixes: 49d46e3c7e59 ("phy: tegra: xusb: Add set_mode support for UTMI phy on Tegra186")
Cc: stable(a)vger.kernel.org
Signed-off-by: Wayne Chang <waynec(a)nvidia.com>
---
drivers/phy/tegra/xusb-tegra186.c | 59 +++++++++++++++++++------------
1 file changed, 37 insertions(+), 22 deletions(-)
diff --git a/drivers/phy/tegra/xusb-tegra186.c b/drivers/phy/tegra/xusb-tegra186.c
index fae6242aa730..1b35d50821f7 100644
--- a/drivers/phy/tegra/xusb-tegra186.c
+++ b/drivers/phy/tegra/xusb-tegra186.c
@@ -774,13 +774,15 @@ static int tegra186_xusb_padctl_vbus_override(struct tegra_xusb_padctl *padctl,
}
static int tegra186_xusb_padctl_id_override(struct tegra_xusb_padctl *padctl,
- bool status)
+ struct tegra_xusb_usb2_port *port, bool status)
{
- u32 value;
+ u32 value, id_override;
+ int err = 0;
dev_dbg(padctl->dev, "%s id override\n", status ? "set" : "clear");
value = padctl_readl(padctl, USB2_VBUS_ID);
+ id_override = value & ID_OVERRIDE(~0);
if (status) {
if (value & VBUS_OVERRIDE) {
@@ -791,15 +793,35 @@ static int tegra186_xusb_padctl_id_override(struct tegra_xusb_padctl *padctl,
value = padctl_readl(padctl, USB2_VBUS_ID);
}
- value &= ~ID_OVERRIDE(~0);
- value |= ID_OVERRIDE_GROUNDED;
+ if (id_override != ID_OVERRIDE_GROUNDED) {
+ value &= ~ID_OVERRIDE(~0);
+ value |= ID_OVERRIDE_GROUNDED;
+ padctl_writel(padctl, value, USB2_VBUS_ID);
+
+ err = regulator_enable(port->supply);
+ if (err) {
+ dev_err(padctl->dev, "Failed to enable regulator: %d\n", err);
+ return err;
+ }
+ }
} else {
- value &= ~ID_OVERRIDE(~0);
- value |= ID_OVERRIDE_FLOATING;
+ if (id_override == ID_OVERRIDE_GROUNDED) {
+ /*
+ * The regulator is disabled only when the role transitions
+ * from USB_ROLE_HOST to USB_ROLE_NONE.
+ */
+ err = regulator_disable(port->supply);
+ if (err) {
+ dev_err(padctl->dev, "Failed to disable regulator: %d\n", err);
+ return err;
+ }
+
+ value &= ~ID_OVERRIDE(~0);
+ value |= ID_OVERRIDE_FLOATING;
+ padctl_writel(padctl, value, USB2_VBUS_ID);
+ }
}
- padctl_writel(padctl, value, USB2_VBUS_ID);
-
return 0;
}
@@ -818,27 +840,20 @@ static int tegra186_utmi_phy_set_mode(struct phy *phy, enum phy_mode mode,
if (mode == PHY_MODE_USB_OTG) {
if (submode == USB_ROLE_HOST) {
- tegra186_xusb_padctl_id_override(padctl, true);
-
- err = regulator_enable(port->supply);
+ err = tegra186_xusb_padctl_id_override(padctl, port, true);
+ if (err)
+ goto out;
} else if (submode == USB_ROLE_DEVICE) {
tegra186_xusb_padctl_vbus_override(padctl, true);
} else if (submode == USB_ROLE_NONE) {
- /*
- * When port is peripheral only or role transitions to
- * USB_ROLE_NONE from USB_ROLE_DEVICE, regulator is not
- * enabled.
- */
- if (regulator_is_enabled(port->supply))
- regulator_disable(port->supply);
-
- tegra186_xusb_padctl_id_override(padctl, false);
+ err = tegra186_xusb_padctl_id_override(padctl, port, false);
+ if (err)
+ goto out;
tegra186_xusb_padctl_vbus_override(padctl, false);
}
}
-
+out:
mutex_unlock(&padctl->lock);
-
return err;
}
--
2.25.1
* Sasha Levin (sashal(a)kernel.org) wrote:
> This is a note to let you know that I've just added the patch titled
>
> Bluetooth: MGMT: Remove unused mgmt_pending_find_data
>
> to the 6.12-stable tree which can be found at:
> http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
>
> The filename of the patch is:
> bluetooth-mgmt-remove-unused-mgmt_pending_find_data.patch
> and it can be found in the queue-6.12 subdirectory.
>
> If you, or anyone else, feels it should not be added to the stable tree,
> please let <stable(a)vger.kernel.org> know about it.
It's a cleanup only, so I wouldn't backport it unless it makes backporting
a useful patch easier.
Dave
>
>
> commit 17d285fbdeb9dabee6c6c348a528ac81ca65a6da
> Author: Dr. David Alan Gilbert <linux(a)treblig.org>
> Date: Mon Jan 27 21:37:15 2025 +0000
>
> Bluetooth: MGMT: Remove unused mgmt_pending_find_data
>
> [ Upstream commit 276af34d82f13bda0b2a4d9786c90b8bbf1cd064 ]
>
> mgmt_pending_find_data() last use was removed in 2021 by
> commit 5a7501374664 ("Bluetooth: hci_sync: Convert MGMT_OP_GET_CLOCK_INFO")
>
> Remove it.
>
> Signed-off-by: Dr. David Alan Gilbert <linux(a)treblig.org>
> Reviewed-by: Simon Horman <horms(a)kernel.org>
> Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz(a)intel.com>
> Stable-dep-of: 6fe26f694c82 ("Bluetooth: MGMT: Protect mgmt_pending list with its own lock")
> Signed-off-by: Sasha Levin <sashal(a)kernel.org>
>
> diff --git a/net/bluetooth/mgmt_util.c b/net/bluetooth/mgmt_util.c
> index 67db32a60c6a9..3713ff490c65d 100644
> --- a/net/bluetooth/mgmt_util.c
> +++ b/net/bluetooth/mgmt_util.c
> @@ -229,23 +229,6 @@ struct mgmt_pending_cmd *mgmt_pending_find(unsigned short channel, u16 opcode,
> return NULL;
> }
>
> -struct mgmt_pending_cmd *mgmt_pending_find_data(unsigned short channel,
> - u16 opcode,
> - struct hci_dev *hdev,
> - const void *data)
> -{
> - struct mgmt_pending_cmd *cmd;
> -
> - list_for_each_entry(cmd, &hdev->mgmt_pending, list) {
> - if (cmd->user_data != data)
> - continue;
> - if (cmd->opcode == opcode)
> - return cmd;
> - }
> -
> - return NULL;
> -}
> -
> void mgmt_pending_foreach(u16 opcode, struct hci_dev *hdev,
> void (*cb)(struct mgmt_pending_cmd *cmd, void *data),
> void *data)
> diff --git a/net/bluetooth/mgmt_util.h b/net/bluetooth/mgmt_util.h
> index bdf978605d5a8..f2ba994ab1d84 100644
> --- a/net/bluetooth/mgmt_util.h
> +++ b/net/bluetooth/mgmt_util.h
> @@ -54,10 +54,6 @@ int mgmt_cmd_complete(struct sock *sk, u16 index, u16 cmd, u8 status,
>
> struct mgmt_pending_cmd *mgmt_pending_find(unsigned short channel, u16 opcode,
> struct hci_dev *hdev);
> -struct mgmt_pending_cmd *mgmt_pending_find_data(unsigned short channel,
> - u16 opcode,
> - struct hci_dev *hdev,
> - const void *data);
> void mgmt_pending_foreach(u16 opcode, struct hci_dev *hdev,
> void (*cb)(struct mgmt_pending_cmd *cmd, void *data),
> void *data);
--
-----Open up your eyes, open up your mind, open up your code -------
/ Dr. David Alan Gilbert | Running GNU/Linux | Happy \
\ dave @ treblig.org | | In Hex /
\ _________________________|_____ http://www.treblig.org |_______/
* Sasha Levin (sashal(a)kernel.org) wrote:
> This is a note to let you know that I've just added the patch titled
>
> Bluetooth: MGMT: Remove unused mgmt_pending_find_data
>
> to the 6.6-stable tree which can be found at:
> http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
>
> The filename of the patch is:
> bluetooth-mgmt-remove-unused-mgmt_pending_find_data.patch
> and it can be found in the queue-6.6 subdirectory.
>
> If you, or anyone else, feels it should not be added to the stable tree,
> please let <stable(a)vger.kernel.org> know about it.
<rewinds, copies same message I did for 6.12 - please take this to mean all of them>
It's a cleanup only, so I wouldn't backport it unless it makes backporting
a useful patch easier.
Dave
>
>
>
> commit af31788b431f56d9b304d32701f1f9143aae8f95
> Author: Dr. David Alan Gilbert <linux(a)treblig.org>
> Date: Mon Jan 27 21:37:15 2025 +0000
>
> Bluetooth: MGMT: Remove unused mgmt_pending_find_data
>
> [ Upstream commit 276af34d82f13bda0b2a4d9786c90b8bbf1cd064 ]
>
> mgmt_pending_find_data() last use was removed in 2021 by
> commit 5a7501374664 ("Bluetooth: hci_sync: Convert MGMT_OP_GET_CLOCK_INFO")
>
> Remove it.
>
> Signed-off-by: Dr. David Alan Gilbert <linux(a)treblig.org>
> Reviewed-by: Simon Horman <horms(a)kernel.org>
> Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz(a)intel.com>
> Stable-dep-of: 6fe26f694c82 ("Bluetooth: MGMT: Protect mgmt_pending list with its own lock")
> Signed-off-by: Sasha Levin <sashal(a)kernel.org>
>
> diff --git a/net/bluetooth/mgmt_util.c b/net/bluetooth/mgmt_util.c
> index 17e32605d9b00..dba6a0d66500f 100644
> --- a/net/bluetooth/mgmt_util.c
> +++ b/net/bluetooth/mgmt_util.c
> @@ -229,23 +229,6 @@ struct mgmt_pending_cmd *mgmt_pending_find(unsigned short channel, u16 opcode,
> return NULL;
> }
>
> -struct mgmt_pending_cmd *mgmt_pending_find_data(unsigned short channel,
> - u16 opcode,
> - struct hci_dev *hdev,
> - const void *data)
> -{
> - struct mgmt_pending_cmd *cmd;
> -
> - list_for_each_entry(cmd, &hdev->mgmt_pending, list) {
> - if (cmd->user_data != data)
> - continue;
> - if (cmd->opcode == opcode)
> - return cmd;
> - }
> -
> - return NULL;
> -}
> -
> void mgmt_pending_foreach(u16 opcode, struct hci_dev *hdev,
> void (*cb)(struct mgmt_pending_cmd *cmd, void *data),
> void *data)
> diff --git a/net/bluetooth/mgmt_util.h b/net/bluetooth/mgmt_util.h
> index bdf978605d5a8..f2ba994ab1d84 100644
> --- a/net/bluetooth/mgmt_util.h
> +++ b/net/bluetooth/mgmt_util.h
> @@ -54,10 +54,6 @@ int mgmt_cmd_complete(struct sock *sk, u16 index, u16 cmd, u8 status,
>
> struct mgmt_pending_cmd *mgmt_pending_find(unsigned short channel, u16 opcode,
> struct hci_dev *hdev);
> -struct mgmt_pending_cmd *mgmt_pending_find_data(unsigned short channel,
> - u16 opcode,
> - struct hci_dev *hdev,
> - const void *data);
> void mgmt_pending_foreach(u16 opcode, struct hci_dev *hdev,
> void (*cb)(struct mgmt_pending_cmd *cmd, void *data),
> void *data);
--
-----Open up your eyes, open up your mind, open up your code -------
/ Dr. David Alan Gilbert | Running GNU/Linux | Happy \
\ dave @ treblig.org | | In Hex /
\ _________________________|_____ http://www.treblig.org |_______/
After reverting the transition to the generic min heap library, bcache
no longer depends on MIN_HEAP. The select entry can be removed to
reduce code size and shrink the kernel's attack surface.
This change effectively reverts the bcache-related part of commit
92a8b224b833 ("lib/min_heap: introduce non-inline versions of min heap
API functions").
This is part of a series of changes to address a performance
regression caused by the use of the generic min_heap implementation.
As reported by Robert, bcache now suffers from latency spikes, with
P100 (max) latency increasing from 600 ms to 2.4 seconds every 5
minutes. These regressions degrade bcache's effectiveness as a
low-latency cache layer and lead to frequent timeouts and application
stalls in production environments.
Link: https://lore.kernel.org/lkml/CAJhEC05+0S69z+3+FB2Cd0hD+pCRyWTKLEOsc8BOmH73p…
Fixes: 866898efbb25 ("bcache: remove heap-related macros and switch to generic min_heap")
Fixes: 92a8b224b833 ("lib/min_heap: introduce non-inline versions of min heap API functions")
Reported-by: Robert Pang <robertpang(a)google.com>
Closes: https://lore.kernel.org/linux-bcache/CAJhEC06F_AtrPgw2-7CvCqZgeStgCtitbD-ry…
Cc: stable(a)vger.kernel.org
Signed-off-by: Kuan-Wei Chiu <visitorckw(a)gmail.com>
---
drivers/md/bcache/Kconfig | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/md/bcache/Kconfig b/drivers/md/bcache/Kconfig
index d4697e79d5a3..b2d10063d35f 100644
--- a/drivers/md/bcache/Kconfig
+++ b/drivers/md/bcache/Kconfig
@@ -5,7 +5,6 @@ config BCACHE
select BLOCK_HOLDER_DEPRECATED if SYSFS
select CRC64
select CLOSURES
- select MIN_HEAP
help
Allows a block device to be used as cache for other devices; uses
a btree for indexing and the layout is optimized for SSDs.
--
2.34.1
From: Eric Biggers <ebiggers(a)google.com>
Make fscrypt no longer use Crypto API drivers for non-inline crypto
accelerators, even when the Crypto API prioritizes them over CPU-based
code (which unfortunately it often does). These drivers tend to be
really problematic, especially for fscrypt's synchronous workload.
Specifically, exclude drivers that have CRYPTO_ALG_KERN_DRIVER_ONLY or
CRYPTO_ALG_ALLOCATES_MEMORY set. (Later, CRYPTO_ALG_ASYNC should be
excluded too. That's omitted for now to keep this commit backportable,
since until recently some CPU-based code had CRYPTO_ALG_ASYNC set.)
There are two major issues with these drivers: bugs and performance.
First, these drivers tend to be buggy. They're fundamentally much more
error-prone and harder to test than the CPU-based code, and they often
don't get tested before kernel releases. Released drivers have
en/decrypted data incorrectly. These bugs cause real issues for fscrypt
users who often didn't even want to use these drivers, for example:
- https://github.com/google/fscryptctl/issues/32
- https://github.com/google/fscryptctl/issues/9
- https://lore.kernel.org/r/PH0PR02MB731916ECDB6C613665863B6CFFAA2@PH0PR02MB7…
These drivers have also caused issues for dm-crypt users, including data
corruption and deadlocks. Since Linux v5.10, dm-crypt has disabled most
of these drivers by excluding CRYPTO_ALG_ALLOCATES_MEMORY.
Second, the CPU-based crypto tends to be faster, often *much* faster.
This may seem counterintuitive, but benchmarks clearly show it. There's
a *lot* of overhead associated with going to a hardware driver, off the
CPU, and back again. Measuring synchronous AES-256-XTS encryption of
4096-byte messages (fscrypt's workload) on two platforms with non-inline
crypto accelerators that I have access to:
Intel Emerald Rapids server:
xts-aes-vaes-avx512: 16171 MB/s [CPU-based, Vector AES]
xts(ecb(aes-generic)): 305 MB/s [CPU-based, generic C code]
qat_aes_xts: 289 MB/s [Offload, Intel QuickAssist]
Qualcomm SM8650 HDK:
xts-aes-ce: 4301 MB/s [CPU-based, ARMv8 Crypto Extensions]
xts(ecb(aes-generic)): 265 MB/s [CPU-based, generic C code]
xts-aes-qce: 73 MB/s [Offload, Qualcomm Crypto Engine]
So, using the "accelerators" is over 50 times slower than just using the
CPU. Not only that, it's even slower than the generic C code, which
suggests that even on platforms whose CPUs lack AES instructions the
performance benefit of any accelerator would be marginal at best.
The usefulness of the accelerators could be improved with a different
software architecture that allows blocks to be efficiently en/decrypted
in parallel. But fscrypt does not do that today, and even the async
support in the Crypto API isn't really all that efficient. And even if
the accelerator was used perfectly efficiently, it seems unlikely to
help on small I/O requests, for which latency is really important.
As of this writing, the Crypto API prioritizes qat_aes_xts over
xts-aes-vaes-avx512. Therefore, this commit greatly improves fscrypt
performance on Intel servers that have QAT and the QAT driver enabled.
qat_aes_xts is going to be deprioritized in the Crypto API (like I did
for xts-aes-qce recently too). But as this seems to be a common pattern
with all the "accelerators", fscrypt should just disable all of them.
An argument that has been given in favor of non-inline crypto
accelerators is that they can protect keys in hardware. But fscrypt
does not take advantage of that, so it is irrelevant. (Also, it would
be quite difficult for fscrypt to do that.)
Note that fscrypt does support inline encryption engines, using raw or
hardware-wrapped keys. These actually do work well and are widely used.
These do not use the "Crypto API" and are unaffected by this commit.
Fixes: b30ab0e03407 ("ext4 crypto: add ext4 encryption facilities")
Cc: stable(a)vger.kernel.org
Signed-off-by: Eric Biggers <ebiggers(a)google.com>
---
Changed in v2:
- Improved commit message and comment
- Dropped CRYPTO_ALG_ASYNC from the mask, to make this patch
backport-friendly
- Added Fixes and Cc stable
fs/crypto/fscrypt_private.h | 16 ++++++++++++++++
fs/crypto/hkdf.c | 2 +-
fs/crypto/keysetup.c | 3 ++-
fs/crypto/keysetup_v1.c | 3 ++-
4 files changed, 21 insertions(+), 3 deletions(-)
diff --git a/fs/crypto/fscrypt_private.h b/fs/crypto/fscrypt_private.h
index c1d92074b65c5..0e95c7a095d49 100644
--- a/fs/crypto/fscrypt_private.h
+++ b/fs/crypto/fscrypt_private.h
@@ -43,10 +43,26 @@
* hardware-wrapped keys has made it misleading as it's only for raw keys.
* Don't use it in kernel code; use one of the above constants instead.
*/
#undef FSCRYPT_MAX_KEY_SIZE
+/*
+ * This mask is passed as the third argument to the crypto_alloc_*() functions
+ * to prevent fscrypt from using the Crypto API drivers for non-inline crypto
+ * accelerators. Those drivers have been problematic for fscrypt. fscrypt
+ * users have reported hangs and even incorrect en/decryption with these
+ * drivers. Since going to the driver, off CPU, and back again is really slow,
+ * such drivers can be over 50 times slower than the CPU-based code for
+ * fscrypt's synchronous workload. Even on platforms that lack AES instructions
+ * on the CPU, any performance benefit is likely to be marginal at best.
+ *
+ * Note that fscrypt also supports inline encryption engines. Those don't use
+ * the Crypto API and work much better than non-inline accelerators.
+ */
+#define FSCRYPT_CRYPTOAPI_MASK \
+ (CRYPTO_ALG_ALLOCATES_MEMORY | CRYPTO_ALG_KERN_DRIVER_ONLY)
+
#define FSCRYPT_CONTEXT_V1 1
#define FSCRYPT_CONTEXT_V2 2
/* Keep this in sync with include/uapi/linux/fscrypt.h */
#define FSCRYPT_MODE_MAX FSCRYPT_MODE_AES_256_HCTR2
diff --git a/fs/crypto/hkdf.c b/fs/crypto/hkdf.c
index 0f3028adc9c72..5b9c21cfe2b45 100644
--- a/fs/crypto/hkdf.c
+++ b/fs/crypto/hkdf.c
@@ -56,11 +56,11 @@ int fscrypt_init_hkdf(struct fscrypt_hkdf *hkdf, const u8 *master_key,
struct crypto_shash *hmac_tfm;
static const u8 default_salt[HKDF_HASHLEN];
u8 prk[HKDF_HASHLEN];
int err;
- hmac_tfm = crypto_alloc_shash(HKDF_HMAC_ALG, 0, 0);
+ hmac_tfm = crypto_alloc_shash(HKDF_HMAC_ALG, 0, FSCRYPT_CRYPTOAPI_MASK);
if (IS_ERR(hmac_tfm)) {
fscrypt_err(NULL, "Error allocating " HKDF_HMAC_ALG ": %ld",
PTR_ERR(hmac_tfm));
return PTR_ERR(hmac_tfm);
}
diff --git a/fs/crypto/keysetup.c b/fs/crypto/keysetup.c
index 0d71843af9469..d8113a7196979 100644
--- a/fs/crypto/keysetup.c
+++ b/fs/crypto/keysetup.c
@@ -101,11 +101,12 @@ fscrypt_allocate_skcipher(struct fscrypt_mode *mode, const u8 *raw_key,
const struct inode *inode)
{
struct crypto_skcipher *tfm;
int err;
- tfm = crypto_alloc_skcipher(mode->cipher_str, 0, 0);
+ tfm = crypto_alloc_skcipher(mode->cipher_str, 0,
+ FSCRYPT_CRYPTOAPI_MASK);
if (IS_ERR(tfm)) {
if (PTR_ERR(tfm) == -ENOENT) {
fscrypt_warn(inode,
"Missing crypto API support for %s (API name: \"%s\")",
mode->friendly_name, mode->cipher_str);
diff --git a/fs/crypto/keysetup_v1.c b/fs/crypto/keysetup_v1.c
index b70521c55132b..158ceae8a5bce 100644
--- a/fs/crypto/keysetup_v1.c
+++ b/fs/crypto/keysetup_v1.c
@@ -50,11 +50,12 @@ static int derive_key_aes(const u8 *master_key,
{
int res = 0;
struct skcipher_request *req = NULL;
DECLARE_CRYPTO_WAIT(wait);
struct scatterlist src_sg, dst_sg;
- struct crypto_skcipher *tfm = crypto_alloc_skcipher("ecb(aes)", 0, 0);
+ struct crypto_skcipher *tfm =
+ crypto_alloc_skcipher("ecb(aes)", 0, FSCRYPT_CRYPTOAPI_MASK);
if (IS_ERR(tfm)) {
res = PTR_ERR(tfm);
tfm = NULL;
goto out;
base-commit: 19272b37aa4f83ca52bdf9c16d5d81bdd1354494
--
2.49.0
Hi,
Just wanted to check if you have received my previous email.
Any update for me?
Awaiting your reply.
Regards,
Delilah
___________________________________________________________________________________
From: Delilah Murray
Subject: Attendee’s List “Mobile World Congress Shanghai 2025”.
Hi,
We're excited to offer exclusive access to the “Mobile World Congress Shanghai 2025” Visitor Contact List.
Event Recap:-
Date: 18 - 20 Jun 2025
Location: Shanghai, China
Registrants Counts: 42,276 Visitors Contacts
Data Fields Available: Individual Email Address, Cell Phone Number, Contact Name, Job Title, Company Name, Website, Physical Address, LinkedIn Profile, and more.
This list gives you a direct line to your ideal audience—no gatekeepers, no guesswork.
If you're interested in the list, just reply "Send me Pricing" or sample?
Best regards,
Delilah Murray
Sr. Marketing Manager
Prefer not to receive these emails? Just reply “NOT INTERESTED”.
[cc += Joel Mathew Thomas]
On Tue, Jun 10, 2025 at 08:16:05AM -0400, Sasha Levin wrote:
> This is a note to let you know that I've just added the patch titled
>
> PCI: pciehp: Ignore Link Down/Up caused by Secondary Bus Reset
>
> to the 6.15-stable tree which can be found at:
> http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
>
> The filename of the patch is:
> pci-pciehp-ignore-link-down-up-caused-by-secondary-b.patch
> and it can be found in the queue-6.15 subdirectory.
>
> If you, or anyone else, feels it should not be added to the stable tree,
> please let <stable(a)vger.kernel.org> know about it.
Hi Sasha, thanks for selecting the above (which is 2af781a9edc4 upstream)
as a 6.15 backport.
A small feature request, could you amend the stable tooling to cc
people tagged as Reported-by and Tested-by? I think they're the
ones most interested in seeing something backported.
Thanks!
Lukas
> commit 161a7237de69f65ccfe68da318343f3719149480
> Author: Lukas Wunner <lukas(a)wunner.de>
> Date: Thu Apr 10 17:27:12 2025 +0200
>
> PCI: pciehp: Ignore Link Down/Up caused by Secondary Bus Reset
>
> [ Upstream commit 2af781a9edc4ef5f6684c0710cc3542d9be48b31 ]
>
> When a Secondary Bus Reset is issued at a hotplug port, it causes a Data
> Link Layer State Changed event as a side effect. On hotplug ports using
> in-band presence detect, it additionally causes a Presence Detect Changed
> event.
>
> These spurious events should not result in teardown and re-enumeration of
> the device in the slot. Hence commit 2e35afaefe64 ("PCI: pciehp: Add
> reset_slot() method") masked the Presence Detect Changed Enable bit in the
> Slot Control register during a Secondary Bus Reset. Commit 06a8d89af551
> ("PCI: pciehp: Disable link notification across slot reset") additionally
> masked the Data Link Layer State Changed Enable bit.
>
> However masking those bits only disables interrupt generation (PCIe r6.2
> sec 6.7.3.1). The events are still visible in the Slot Status register
> and picked up by the IRQ handler if it runs during a Secondary Bus Reset.
> This can happen if the interrupt is shared or if an unmasked hotplug event
> occurs, e.g. Attention Button Pressed or Power Fault Detected.
>
> The likelihood of this happening used to be small, so it wasn't much of a
> problem in practice. That has changed with the recent introduction of
> bandwidth control in v6.13-rc1 with commit 665745f27487 ("PCI/bwctrl:
> Re-add BW notification portdrv as PCIe BW controller"):
>
> Bandwidth control shares the interrupt with PCIe hotplug. A Secondary Bus
> Reset causes a Link Bandwidth Notification, so the hotplug IRQ handler
> runs, picks up the masked events and tears down the device in the slot.
>
> As a result, Joel reports VFIO passthrough failure of a GPU, which Ilpo
> root-caused to the incorrect handling of masked hotplug events.
>
> Clearly, a more reliable way is needed to ignore spurious hotplug events.
>
> For Downstream Port Containment, a new ignore mechanism was introduced by
> commit a97396c6eb13 ("PCI: pciehp: Ignore Link Down/Up caused by DPC").
> It has been working reliably for the past four years.
>
> Adapt it for Secondary Bus Resets.
>
> Introduce two helpers to annotate code sections which cause spurious link
> changes: pci_hp_ignore_link_change() and pci_hp_unignore_link_change()
> Use those helpers in lieu of masking interrupts in the Slot Control
> register.
>
> Introduce a helper to check whether such a code section is executing
> concurrently and if so, await it: pci_hp_spurious_link_change()
> Invoke the helper in the hotplug IRQ thread pciehp_ist(). Re-use the
> IRQ thread's existing code which ignores DPC-induced link changes unless
> the link is unexpectedly down after reset recovery or the device was
> replaced during the bus reset.
>
> That code block in pciehp_ist() was previously only executed if a Data
> Link Layer State Changed event has occurred. Additionally execute it for
> Presence Detect Changed events. That's necessary for compatibility with
> PCIe r1.0 hotplug ports because Data Link Layer State Changed didn't exist
> before PCIe r1.1. DPC was added with PCIe r3.1 and thus DPC-capable
> hotplug ports always support Data Link Layer State Changed events.
> But the same cannot be assumed for Secondary Bus Reset, which already
> existed in PCIe r1.0.
>
> Secondary Bus Reset is only one of many causes of spurious link changes.
> Others include runtime suspend to D3cold, firmware updates or FPGA
> reconfiguration. The new pci_hp_{,un}ignore_link_change() helpers may be
> used by all kinds of drivers to annotate such code sections, hence their
> declarations are publicly visible in <linux/pci.h>. A case in point is
> the Mellanox Ethernet driver which disables a firmware reset feature if
> the Ethernet card is attached to a hotplug port, see commit 3d7a3f2612d7
> ("net/mlx5: Nack sync reset request when HotPlug is enabled"). Going
> forward, PCIe hotplug will be able to cope gracefully with all such use
> cases once the code sections are properly annotated.
>
> The new helpers internally use two bits in struct pci_dev's priv_flags as
> well as a wait_queue. This mirrors what was done for DPC by commit
> a97396c6eb13 ("PCI: pciehp: Ignore Link Down/Up caused by DPC"). That may
> be insufficient if spurious link changes are caused by multiple sources
> simultaneously. An example might be a Secondary Bus Reset issued by AER
> during FPGA reconfiguration. If this turns out to happen in real life,
> support for it can easily be added by replacing the PCI_LINK_CHANGING flag
> with an atomic_t counter incremented by pci_hp_ignore_link_change() and
> decremented by pci_hp_unignore_link_change(). Instead of awaiting a zero
> PCI_LINK_CHANGING flag, the pci_hp_spurious_link_change() helper would
> then simply await a zero counter.
>
> Fixes: 665745f27487 ("PCI/bwctrl: Re-add BW notification portdrv as PCIe BW controller")
> Reported-by: Joel Mathew Thomas <proxy0(a)tutamail.com>
> Closes: https://bugzilla.kernel.org/show_bug.cgi?id=219765
> Signed-off-by: Lukas Wunner <lukas(a)wunner.de>
> Signed-off-by: Bjorn Helgaas <bhelgaas(a)google.com>
> Tested-by: Joel Mathew Thomas <proxy0(a)tutamail.com>
> Reviewed-by: Kuppuswamy Sathyanarayanan <sathyanarayanan.kuppuswamy(a)linux.intel.com>
> Reviewed-by: Ilpo Järvinen <ilpo.jarvinen(a)linux.intel.com>
> Link: https://patch.msgid.link/d04deaf49d634a2edf42bf3c06ed81b4ca54d17b.174429823…
> Signed-off-by: Sasha Levin <sashal(a)kernel.org>