* [PATCH 4/6] crypto: qat - skip restart for down devices
From: Ahsan Atta @ 2026-05-13 15:16 UTC (permalink / raw)
To: herbert; +Cc: linux-crypto, qat-linux, Ahsan Atta, stable, Giovanni Cabiddu
In-Reply-To: <cover.1778685152.git.ahsan.atta@intel.com>
Skip the shutdown and restart flow when adf_slot_reset() is entered
for a device that is already down. In that case, leave
ADF_STATUS_RESTARTING clear and let adf_slot_reset() restore PCI
function state without calling adf_dev_up(), re-enabling SR-IOV, or
sending restarted notifications.
This is in preparation for adding reset_prepare() and reset_done()
callbacks in adf_aer.c.
Cc: stable@vger.kernel.org
Signed-off-by: Ahsan Atta <ahsan.atta@intel.com>
Reviewed-by: Giovanni Cabiddu <giovanni.cabiddu@intel.com>
---
drivers/crypto/intel/qat/qat_common/adf_aer.c | 8 ++++++++
1 file changed, 8 insertions(+)
diff --git a/drivers/crypto/intel/qat/qat_common/adf_aer.c b/drivers/crypto/intel/qat/qat_common/adf_aer.c
index 365637e40439..7255cac5aaa6 100644
--- a/drivers/crypto/intel/qat/qat_common/adf_aer.c
+++ b/drivers/crypto/intel/qat/qat_common/adf_aer.c
@@ -33,6 +33,9 @@ static pci_ers_result_t adf_error_detected(struct pci_dev *pdev,
return PCI_ERS_RESULT_DISCONNECT;
}
+ if (!adf_dev_started(accel_dev))
+ return PCI_ERS_RESULT_CAN_RECOVER;
+
adf_error_notifier(accel_dev);
adf_pf2vf_notify_fatal_error(accel_dev);
set_bit(ADF_STATUS_RESTARTING, &accel_dev->status);
@@ -204,6 +207,9 @@ static pci_ers_result_t adf_slot_reset(struct pci_dev *pdev)
return PCI_ERS_RESULT_DISCONNECT;
}
+ if (!adf_devmgr_in_reset(accel_dev))
+ goto reset_complete;
+
pci_restore_state(pdev);
res = adf_dev_up(accel_dev, false);
if (res && res != -EALREADY)
@@ -213,6 +219,8 @@ static pci_ers_result_t adf_slot_reset(struct pci_dev *pdev)
adf_pf2vf_notify_restarted(accel_dev);
adf_dev_restarted_notify(accel_dev);
clear_bit(ADF_STATUS_RESTARTING, &accel_dev->status);
+
+reset_complete:
return PCI_ERS_RESULT_RECOVERED;
}
--
2.45.0
--------------------------------------------------------------
Intel Research and Development Ireland Limited
Registered in Ireland
Registered Office: Collinstown Industrial Park, Leixlip, County Kildare
Registered Number: 308263
This e-mail and any attachments may contain confidential material for the sole
use of the intended recipient(s). Any review or distribution by others is
strictly prohibited. If you are not the intended recipient, please contact the
sender and delete all copies.
^ permalink raw reply related
* [PATCH 5/6] crypto: qat - factor out AER reset helpers
From: Ahsan Atta @ 2026-05-13 15:16 UTC (permalink / raw)
To: herbert
Cc: linux-crypto, qat-linux, Ahsan Atta, stable, Giovanni Cabiddu,
Damian Muszynski
In-Reply-To: <cover.1778685152.git.ahsan.atta@intel.com>
Move the shutdown and recovery sequences out of adf_error_detected()
and adf_slot_reset() into reset_prepare() and reset_done() helpers.
This makes the AER recovery path easier to follow and prepares the
common reset flow for reuse by additional PCI reset callbacks without
duplicating the logic.
No functional change intended.
Cc: stable@vger.kernel.org
Signed-off-by: Ahsan Atta <ahsan.atta@intel.com>
Reviewed-by: Giovanni Cabiddu <giovanni.cabiddu@intel.com>
Reviewed-by: Damian Muszynski <damian.muszynski@intel.com>
---
drivers/crypto/intel/qat/qat_common/adf_aer.c | 86 ++++++++++++-------
1 file changed, 53 insertions(+), 33 deletions(-)
diff --git a/drivers/crypto/intel/qat/qat_common/adf_aer.c b/drivers/crypto/intel/qat/qat_common/adf_aer.c
index 7255cac5aaa6..d29f70eb84b8 100644
--- a/drivers/crypto/intel/qat/qat_common/adf_aer.c
+++ b/drivers/crypto/intel/qat/qat_common/adf_aer.c
@@ -17,27 +17,18 @@ struct adf_fatal_error_data {
static struct workqueue_struct *device_reset_wq;
static struct workqueue_struct *device_sriov_wq;
-static pci_ers_result_t adf_error_detected(struct pci_dev *pdev,
- pci_channel_state_t state)
+static pci_ers_result_t reset_prepare(struct pci_dev *pdev)
{
struct adf_accel_dev *accel_dev = adf_devmgr_pci_to_accel_dev(pdev);
- dev_info(&pdev->dev, "Acceleration driver hardware error detected.\n");
if (!accel_dev) {
dev_err(&pdev->dev, "Can't find acceleration device\n");
return PCI_ERS_RESULT_DISCONNECT;
}
- if (state == pci_channel_io_perm_failure) {
- dev_err(&pdev->dev, "Can't recover from device error\n");
- return PCI_ERS_RESULT_DISCONNECT;
- }
-
if (!adf_dev_started(accel_dev))
return PCI_ERS_RESULT_CAN_RECOVER;
- adf_error_notifier(accel_dev);
- adf_pf2vf_notify_fatal_error(accel_dev);
set_bit(ADF_STATUS_RESTARTING, &accel_dev->status);
if (accel_dev->hw_device->exit_arb) {
dev_dbg(&pdev->dev, "Disabling arbitration\n");
@@ -49,6 +40,57 @@ static pci_ers_result_t adf_error_detected(struct pci_dev *pdev,
return PCI_ERS_RESULT_NEED_RESET;
}
+static pci_ers_result_t reset_done(struct pci_dev *pdev)
+{
+ struct adf_accel_dev *accel_dev = adf_devmgr_pci_to_accel_dev(pdev);
+ int res;
+
+ if (!accel_dev) {
+ dev_err(&pdev->dev, "Can't find acceleration device\n");
+ return PCI_ERS_RESULT_DISCONNECT;
+ }
+
+ if (!adf_devmgr_in_reset(accel_dev))
+ goto reset_complete;
+
+ pci_restore_state(pdev);
+ res = adf_dev_up(accel_dev, false);
+ if (res && res != -EALREADY)
+ return PCI_ERS_RESULT_DISCONNECT;
+
+ adf_reenable_sriov(accel_dev);
+ adf_pf2vf_notify_restarted(accel_dev);
+ adf_dev_restarted_notify(accel_dev);
+ clear_bit(ADF_STATUS_RESTARTING, &accel_dev->status);
+
+reset_complete:
+ dev_info(&pdev->dev, "Device reset completed successfully\n");
+
+ return PCI_ERS_RESULT_RECOVERED;
+}
+
+static pci_ers_result_t adf_error_detected(struct pci_dev *pdev,
+ pci_channel_state_t state)
+{
+ struct adf_accel_dev *accel_dev = adf_devmgr_pci_to_accel_dev(pdev);
+
+ dev_info(&pdev->dev, "Acceleration driver hardware error detected.\n");
+ if (!accel_dev) {
+ dev_err(&pdev->dev, "Can't find acceleration device\n");
+ return PCI_ERS_RESULT_DISCONNECT;
+ }
+
+ if (state == pci_channel_io_perm_failure) {
+ dev_err(&pdev->dev, "Can't recover from device error\n");
+ return PCI_ERS_RESULT_DISCONNECT;
+ }
+
+ adf_error_notifier(accel_dev);
+ adf_pf2vf_notify_fatal_error(accel_dev);
+
+ return reset_prepare(pdev);
+}
+
/* reset dev data */
struct adf_reset_dev_data {
int mode;
@@ -199,29 +241,7 @@ static int adf_dev_aer_schedule_reset(struct adf_accel_dev *accel_dev,
static pci_ers_result_t adf_slot_reset(struct pci_dev *pdev)
{
- struct adf_accel_dev *accel_dev = adf_devmgr_pci_to_accel_dev(pdev);
- int res = 0;
-
- if (!accel_dev) {
- pr_err("QAT: Can't find acceleration device\n");
- return PCI_ERS_RESULT_DISCONNECT;
- }
-
- if (!adf_devmgr_in_reset(accel_dev))
- goto reset_complete;
-
- pci_restore_state(pdev);
- res = adf_dev_up(accel_dev, false);
- if (res && res != -EALREADY)
- return PCI_ERS_RESULT_DISCONNECT;
-
- adf_reenable_sriov(accel_dev);
- adf_pf2vf_notify_restarted(accel_dev);
- adf_dev_restarted_notify(accel_dev);
- clear_bit(ADF_STATUS_RESTARTING, &accel_dev->status);
-
-reset_complete:
- return PCI_ERS_RESULT_RECOVERED;
+ return reset_done(pdev);
}
static void adf_resume(struct pci_dev *pdev)
--
2.45.0
--------------------------------------------------------------
Intel Research and Development Ireland Limited
Registered in Ireland
Registered Office: Collinstown Industrial Park, Leixlip, County Kildare
Registered Number: 308263
This e-mail and any attachments may contain confidential material for the sole
use of the intended recipient(s). Any review or distribution by others is
strictly prohibited. If you are not the intended recipient, please contact the
sender and delete all copies.
^ permalink raw reply related
* [PATCH 6/6] crypto: qat - handle sysfs-triggered reset callbacks
From: Ahsan Atta @ 2026-05-13 15:16 UTC (permalink / raw)
To: herbert
Cc: linux-crypto, qat-linux, Ahsan Atta, stable, Giovanni Cabiddu,
Damian Muszynski
In-Reply-To: <cover.1778685152.git.ahsan.atta@intel.com>
A reset requested through /sys/bus/pci/devices/.../reset invokes the
driver reset_prepare() and reset_done() callbacks. The QAT driver does
not implement those callbacks today, so the reset proceeds without
quiescing the device or bringing it back up afterward, which leaves
the device unusable.
Hook reset_prepare() and reset_done() into adf_err_handler so the
common shutdown and recovery flow also runs for reset. Skip device
quiesce if the device is already in a down state.
Cc: stable@vger.kernel.org
Signed-off-by: Ahsan Atta <ahsan.atta@intel.com>
Reviewed-by: Giovanni Cabiddu <giovanni.cabiddu@intel.com>
Reviewed-by: Damian Muszynski <damian.muszynski@intel.com>
---
drivers/crypto/intel/qat/qat_common/adf_aer.c | 12 ++++++++++++
1 file changed, 12 insertions(+)
diff --git a/drivers/crypto/intel/qat/qat_common/adf_aer.c b/drivers/crypto/intel/qat/qat_common/adf_aer.c
index d29f70eb84b8..af028488e660 100644
--- a/drivers/crypto/intel/qat/qat_common/adf_aer.c
+++ b/drivers/crypto/intel/qat/qat_common/adf_aer.c
@@ -250,10 +250,22 @@ static void adf_resume(struct pci_dev *pdev)
dev_info(&pdev->dev, "Device is up and running\n");
}
+static void adf_reset_prepare(struct pci_dev *pdev)
+{
+ reset_prepare(pdev);
+}
+
+static void adf_reset_done(struct pci_dev *pdev)
+{
+ reset_done(pdev);
+}
+
const struct pci_error_handlers adf_err_handler = {
.error_detected = adf_error_detected,
.slot_reset = adf_slot_reset,
.resume = adf_resume,
+ .reset_prepare = adf_reset_prepare,
+ .reset_done = adf_reset_done,
};
EXPORT_SYMBOL_GPL(adf_err_handler);
--
2.45.0
--------------------------------------------------------------
Intel Research and Development Ireland Limited
Registered in Ireland
Registered Office: Collinstown Industrial Park, Leixlip, County Kildare
Registered Number: 308263
This e-mail and any attachments may contain confidential material for the sole
use of the intended recipient(s). Any review or distribution by others is
strictly prohibited. If you are not the intended recipient, please contact the
sender and delete all copies.
^ permalink raw reply related
* [PATCH] Documentation: qat_rl: make rate limiting wording clearer
From: Giovanni Cabiddu @ 2026-05-13 15:33 UTC (permalink / raw)
To: herbert; +Cc: linux-crypto, qat-linux, Fiona Trahe, Ahsan Atta,
Giovanni Cabiddu
From: Fiona Trahe <fiona.trahe@intel.com>
The term "capability" typically refers to an ability to perform an
action, whereas "capacity" denotes a measurable amount of resources.
Since the sysfs-driver-qat_rl document describes remaining resources
available to perform work, "capacity" is the more accurate term.
Replace "capability" with "capacity" in the document.
Signed-off-by: Fiona Trahe <fiona.trahe@intel.com>
Reviewed-by: Ahsan Atta <ahsan.atta@intel.com>
Signed-off-by: Giovanni Cabiddu <giovanni.cabiddu@intel.com>
---
Documentation/ABI/testing/sysfs-driver-qat_rl | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Documentation/ABI/testing/sysfs-driver-qat_rl b/Documentation/ABI/testing/sysfs-driver-qat_rl
index d534f89b4971..422333a0eb69 100644
--- a/Documentation/ABI/testing/sysfs-driver-qat_rl
+++ b/Documentation/ABI/testing/sysfs-driver-qat_rl
@@ -209,7 +209,7 @@ Date: January 2024
KernelVersion: 6.7
Contact: qat-linux@intel.com
Description:
- (RW) This file will return the remaining capability for a
+ (RW) This file will return the remaining capacity for a
particular service/sla. This is the remaining value that a new
SLA can be set to or a current SLA can be increased with.
--
2.54.0
^ permalink raw reply related
* Re: [PATCH 01/19] btrfs: require at least 4 devices for RAID 6
From: H. Peter Anvin @ 2026-05-13 16:14 UTC (permalink / raw)
To: Christoph Hellwig, Andrew Morton
Cc: Catalin Marinas, Will Deacon, Ard Biesheuvel, Huacai Chen,
WANG Xuerui, Madhavan Srinivasan, Michael Ellerman,
Nicholas Piggin, Christophe Leroy (CS GROUP), Paul Walmsley,
Palmer Dabbelt, Albert Ou, Alexandre Ghiti, Heiko Carstens,
Vasily Gorbik, Alexander Gordeev, Christian Borntraeger,
Sven Schnelle, Thomas Gleixner, Ingo Molnar, Borislav Petkov,
Dave Hansen, x86, Herbert Xu, Dan Williams, Chris Mason,
David Sterba, Arnd Bergmann, Song Liu, Yu Kuai, Li Nan,
linux-kernel, linux-arm-kernel, loongarch, linuxppc-dev,
linux-riscv, linux-s390, linux-crypto, linux-btrfs, linux-arch,
linux-raid
In-Reply-To: <20260512052230.2947683-2-hch@lst.de>
On May 11, 2026 10:20:41 PM PDT, Christoph Hellwig <hch@lst.de> wrote:
>While the RAID6 algorithm could in theory support 3 devices by just
>copying the data disk to the two parity disks, this version is not only
>useless because it is a suboptimal version of 3-way mirroring, but also
>broken with various crashes and incorrect parity generation in various
>architecture-optimized implementations. Disallow it similar to mdraid
>which requires at least 4 devices for RAID 6.
>
>Fixes: 53b381b3abeb ("Btrfs: RAID5 and RAID6")
>Signed-off-by: Christoph Hellwig <hch@lst.de>
>---
> fs/btrfs/volumes.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
>diff --git a/fs/btrfs/volumes.c b/fs/btrfs/volumes.c
>index a88e68f90564..0b54b97bdad8 100644
>--- a/fs/btrfs/volumes.c
>+++ b/fs/btrfs/volumes.c
>@@ -159,7 +159,7 @@ const struct btrfs_raid_attr btrfs_raid_array[BTRFS_NR_RAID_TYPES] = {
> .sub_stripes = 1,
> .dev_stripes = 1,
> .devs_max = 0,
>- .devs_min = 3,
>+ .devs_min = 4,
> .tolerated_failures = 2,
> .devs_increment = 1,
> .ncopies = 1,
Yes, if anyone cares about < 4 disks for the RAID-6 case (or < 3 for the RAID-4/5 case), just use the RAID-1 code.
^ permalink raw reply
* Re: FAILED: patch "[PATCH] lib/crypto: mpi: Fix integer underflow in" failed to apply to 6.1-stable tree
From: Eric Biggers @ 2026-05-13 17:04 UTC (permalink / raw)
To: Greg KH; +Cc: lukas, ignat, jarkko, yimingqian591, stable, linux-crypto
In-Reply-To: <2026051334-showgirl-hurdle-22eb@gregkh>
On Wed, May 13, 2026 at 12:34:38PM +0200, Greg KH wrote:
> On Tue, May 12, 2026 at 07:51:30PM -0700, Eric Biggers wrote:
> > [+Cc linux-crypto@vger.kernel.org]
> >
> > On Tue, May 12, 2026 at 04:01:23PM +0200, gregkh@linuxfoundation.org wrote:
> > >
> > > 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@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 8c2f1288250a90a4b5cabed5d888d7e3aeed4035
> > > # <resolve conflicts, build, test, etc.>
> > > git commit -s
> > > git send-email --to '<stable@vger.kernel.org>' --in-reply-to '2026051223-undercoat-reps-6626@gregkh' --subject-prefix 'PATCH 6.1.y' HEAD^..
> > >
> > > Possible dependencies:
> >
> > A couple issues. First, this email wasn't sent to the subsystem's
> > mailing list (linux-crypto@vger.kernel.org in this case). That greatly
> > reduces the number of people who are made aware that this didn't get
> > automatically backported.
>
> We never send out these FAILED emails to the mailing lists, as that
> would make just even more noise. It's always been this way, sorry.
Yes, this has been a problem for a long time, resulting in lots of
missed backports including the copy.fail ones. It's time for you to fix
your process.
> > Second, the upstream commit cherry-picks to 6.1, 5.15, and 5.10 without
> > conflict. (The file being changed was renamed between 6.1 and 6.6, but
> > 'git cherry-pick' handles that automatically.)
> >
> > I don't know what you're doing exactly that caused it to be
> > unnecessarily marked as FAILED. But whatever it is, it's not working,
> > and it is causing backports to be missed.
>
> We don't use git for cherry-picking as we have a patch queue, so renames
> will often times fail, like it did here. This has always been the case
> in the decades we have been running the stable kernels :)
Again, this has been a problem for a long time, and it's time for you to
fix your process. You can still have the patch queue; just use git for
the actual cherry-pick.
- Eric
^ permalink raw reply
* Re: [PATCH v5 01/13] dt-bindings: crypto: qcom,ice: Fix missing power-domain and iface clk
From: Harshal Dev @ 2026-05-13 17:21 UTC (permalink / raw)
To: Bjorn Andersson
Cc: David S. Miller, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Konrad Dybcio, Abel Vesa, Manivannan Sadhasivam,
cros-qcom-dts-watchers, Eric Biggers, Dmitry Baryshkov,
Jingyi Wang, Tengfei Fan, Bartosz Golaszewski, David Wronek,
Luca Weiss, Neil Armstrong, Melody Olvera, Alexander Koskovich,
Abel Vesa, Brian Masney, Neeraj Soni, Gaurav Kashyap,
linux-arm-msm, linux-crypto, devicetree, linux-kernel,
Krzysztof Kozlowski, Konrad Dybcio, Kuldeep Singh,
Krzysztof Kozlowski
In-Reply-To: <agHkmKq-q7_6m4nl@baldur>
Hi Bjorn,
On 5/11/2026 7:47 PM, Bjorn Andersson wrote:
> On Sat, May 09, 2026 at 09:24:00AM +0800, Herbert Xu wrote:
>> On Fri, May 08, 2026 at 08:11:45PM +0530, Harshal Dev wrote:
>>>
>>> Can you please confirm for Bjorn once
>>> that you're not picking this up and he
>>> can pick it from his tree?
>>
>> Bjorn, please feel free to pick this patch up.
>>
>
> Thanks Herbert, I've picked the binding up.
> If you need it, you can find it at:
>
> https://git.kernel.org/pub/scm/linux/kernel/git/qcom/linux.git 20260416-qcom_ice_power_and_clk_vote-v5-1-5ccf5d7e2846@oss.qualcomm.com
>
I hope you are planning to pick up the rest of the fixes in this series. I can
see Kernel CI Robot reported some dtcheck warnings since your tree doesn't yet
have patch 12 and 13 from this series which have the corresponding DTS changes
to comply to this DT binding.
https://lore.kernel.org/all/202605130731.Gi7H8zjD-lkp@intel.com/#R
If we can pick the rest of the fixes in this series, the warnings would be resolved.
Many thanks for your support,
Harshal
> Regards,
> Bjorn
>
>> Thanks,
>> --
>> Email: Herbert Xu <herbert@gondor.apana.org.au>
>> Home Page: http://gondor.apana.org.au/~herbert/
>> PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: [PATCH 5.10.y 1/3] net: ipv4: stop checking crypto_ahash_alignmask
From: Eric Biggers @ 2026-05-13 17:51 UTC (permalink / raw)
To: Sasha Levin; +Cc: stable, Herbert Xu, linux-crypto, netdev, Steffen Klassert
In-Reply-To: <20260513171555.3876989-1-sashal@kernel.org>
[+Cc linux-crypto@vger.kernel.org, netdev@vger.kernel.org,
Steffen Klassert <steffen.klassert@secunet.com> ]
On Wed, May 13, 2026 at 01:15:52PM -0400, Sasha Levin wrote:
> From: Eric Biggers <ebiggers@google.com>
>
> [ Upstream commit e77f5dd701381cef35b9ea8b6dea6e62c8a7f9f3 ]
>
> Now that the alignmask for ahash and shash algorithms is always 0,
> crypto_ahash_alignmask() always returns 0 and will be removed. In
> preparation for this, stop checking crypto_ahash_alignmask() in ah4.c.
>
> Signed-off-by: Eric Biggers <ebiggers@google.com>
> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
> Stable-dep-of: ec54093e6a8f ("xfrm: ah: account for ESN high bits in async callbacks")
> Signed-off-by: Sasha Levin <sashal@kernel.org>
You forgot to send this to the IPsec maintainers, linux-crypto, and
netdev. See Documentation/process/submitting-patches.rst for some tips
on how to use scripts/get_maintainer.pl to find the right place to send
kernel patches.
This commit was part of the series
https://lore.kernel.org/linux-crypto/20231022081100.123613-1-ebiggers@kernel.org/
What is your rationale for why it's safe to backport this patch 18 of a
30-patch series by itself? "The alignmask for ahash and shash
algorithms is always 0" is definitely *not* true in older kernels.
I *think* it's probably okay. I think this would just regress AH
performance in some cases, and "no one" uses AH anyway.
Just keep in mind this is effectively new development, which needs
review like any other kernel patch. Not even Cc'ing the subsystem
mailing lists isn't a great approach.
- Eric
^ permalink raw reply
* Re: [PATCH net v2 2/4] crypto/krb5, rxrpc: Fix lack of pre-decrypt/pre-verify length checks
From: David Howells @ 2026-05-13 20:16 UTC (permalink / raw)
Cc: dhowells, netdev, Hyunwoo Kim, Marc Dionne, Jakub Kicinski,
David S. Miller, Eric Dumazet, Paolo Abeni, Simon Horman,
linux-afs, linux-kernel, Jeffrey Altman, Herbert Xu, Chuck Lever,
linux-nfs, linux-crypto, stable
In-Reply-To: <20260513131941.1439155-3-dhowells@redhat.com>
David Howells <dhowells@redhat.com> wrote:
> + if (crypto_krb5_check_data_len(gk->krb5, KRB5_ENCRYPT_MODE,
> + len, sizeof(*hdr)) < 0)
This should be sizeof(hdr) here in patch 2 and sizeof(*hdr) in patch 3.
David
^ permalink raw reply
* Re: [PATCH 01/19] btrfs: require at least 4 devices for RAID 6
From: David Sterba @ 2026-05-13 20:19 UTC (permalink / raw)
To: Christoph Hellwig
Cc: Andrew Morton, Catalin Marinas, Will Deacon, Ard Biesheuvel,
Huacai Chen, WANG Xuerui, Madhavan Srinivasan, Michael Ellerman,
Nicholas Piggin, Christophe Leroy (CS GROUP), Paul Walmsley,
Palmer Dabbelt, Albert Ou, Alexandre Ghiti, Heiko Carstens,
Vasily Gorbik, Alexander Gordeev, Christian Borntraeger,
Sven Schnelle, Thomas Gleixner, Ingo Molnar, Borislav Petkov,
Dave Hansen, x86, H. Peter Anvin, Herbert Xu, Dan Williams,
Chris Mason, David Sterba, Arnd Bergmann, Song Liu, Yu Kuai,
Li Nan, linux-kernel, linux-arm-kernel, loongarch, linuxppc-dev,
linux-riscv, linux-s390, linux-crypto, linux-btrfs, linux-arch,
linux-raid
In-Reply-To: <20260513054742.GA1018@lst.de>
On Wed, May 13, 2026 at 07:47:42AM +0200, Christoph Hellwig wrote:
> On Tue, May 12, 2026 at 01:42:31PM +0200, David Sterba wrote:
> > On Tue, May 12, 2026 at 07:20:41AM +0200, Christoph Hellwig wrote:
> > > While the RAID6 algorithm could in theory support 3 devices by just
> > > copying the data disk to the two parity disks, this version is not only
> > > useless because it is a suboptimal version of 3-way mirroring, but also
> > > broken with various crashes and incorrect parity generation in various
> > > architecture-optimized implementations. Disallow it similar to mdraid
> > > which requires at least 4 devices for RAID 6.
> > >
> > > Fixes: 53b381b3abeb ("Btrfs: RAID5 and RAID6")
> > > Signed-off-by: Christoph Hellwig <hch@lst.de>
> >
> > This patch should have been sent separately as it has user visible
> > impact and can potentially break some setups.
>
> It _is_ sent out separate.
It's public interface change of btrfs but in a patch series cleaning
up some library code, I noticed it by accident.
> > The degenerate modes of
> > raid0, 5, or 6 are explicit as a possible middle step when converting
> > profiles. We can use a fallback implementation for this case if the
> > accelerated implementations cannot do it.
>
> This is not about a degenerated mode. For a degenerated RAID 6, parity
> generation uses the RAID 5 XOR routines as the second parity will be
> missing. This is about generating two parities for a single data disk,
> which must be explicitly selected.
The calcuation is a different than what I'm concened about, changing
minimum devices from 3 to 4 is a breaking change. If the library won't
provide the xor/parity functions then we'll have to add a fallback for
this special case.
^ permalink raw reply
* Re: [PATCH v2] crypto: ecc - Fix carry overflow in vli multiplication
From: David Laight @ 2026-05-13 21:08 UTC (permalink / raw)
To: Qingfang Deng
Cc: Anastasia Tishchenko, Lukas Wunner, Stefan Berger,
Ignat Korchagin, Herbert Xu, David S. Miller, linux-crypto,
linux-kernel, stable
In-Reply-To: <20260513123948.842-1-qingfang.deng@linux.dev>
On Wed, 13 May 2026 20:39:48 +0800
Qingfang Deng <qingfang.deng@linux.dev> wrote:
> On Wed, 13 May 2026 at 13:57:40 +0300, Anastasia Tishchenko wrote:
> > diff --git a/crypto/ecc.c b/crypto/ecc.c
> > index 43b0def3a225..6eb4d97a5f0d 100644
> > --- a/crypto/ecc.c
> > +++ b/crypto/ecc.c
> > @@ -393,14 +393,26 @@ static uint128_t mul_64_64(u64 left, u64 right)
> > return result;
> > }
> >
> > -static uint128_t add_128_128(uint128_t a, uint128_t b)
> > +/* Calculate addition with overflow checking. Returns true on wrap-around,
> > + * false otherwise.
> > + */
> > +static bool check_add_128_128_overflow(uint128_t *result, uint128_t a,
> > + uint128_t b)
> > {
> > - uint128_t result;
> > + bool carry;
> >
> > - result.m_low = a.m_low + b.m_low;
> > - result.m_high = a.m_high + b.m_high + (result.m_low < a.m_low);
> > + result->m_low = a.m_low + b.m_low;
> > + carry = (result->m_low < a.m_low);
> >
> > - return result;
> > + result->m_high = a.m_high + b.m_high + carry;
>
> If CONFIG_ARCH_SUPPORTS_INT128 is defined, you can convert them to
> "unsigned __int128" as done in mul_64_64(), and use check_add_overflow()
> to get the carry.
Can you guarantee the compiler generates 'constant time' code for
any of this?
If you care then relying on compiler support for anything that might
generate a conditional jump isn't a good idea.
Just writing 'bitwise' arithmetic doesn't mean the compiler won't
use branches.
Even if you don't get one today, someone else might get one tomorrow.
IIRC even on x86 'x += (a < b)' can generate a branch rather than the
obvious 'cmp a, b; adc $0, x', or the longer cmov or setc sequences.
You pretty much have to use asm for anything that isn't trivial arithmetic.
-- David
>
> > +
> > + /* Using constant-time bitwise arithmetic to prevent timing
> > + * side-channels.
> > + */
> > + carry = (result->m_high < a.m_high) |
> > + ((result->m_high == a.m_high) & carry);
> > +
> > + return carry;
> > }
> >
>
> Regards,
> Qingfang
>
^ permalink raw reply
* Re: FAILED: patch "[PATCH] lib/crypto: mpi: Fix integer underflow in" failed to apply to 6.1-stable tree
From: Eric Biggers @ 2026-05-13 22:59 UTC (permalink / raw)
To: Greg KH; +Cc: lukas, ignat, jarkko, yimingqian591, stable, linux-crypto
In-Reply-To: <20260513170445.GA2128@quark>
On Wed, May 13, 2026 at 10:04:47AM -0700, Eric Biggers wrote:
> > > A couple issues. First, this email wasn't sent to the subsystem's
> > > mailing list (linux-crypto@vger.kernel.org in this case). That greatly
> > > reduces the number of people who are made aware that this didn't get
> > > automatically backported.
> >
> > We never send out these FAILED emails to the mailing lists, as that
> > would make just even more noise. It's always been this way, sorry.
>
> Yes, this has been a problem for a long time, resulting in lots of
> missed backports including the copy.fail ones. It's time for you to fix
> your process.
>
> > > Second, the upstream commit cherry-picks to 6.1, 5.15, and 5.10 without
> > > conflict. (The file being changed was renamed between 6.1 and 6.6, but
> > > 'git cherry-pick' handles that automatically.)
> > >
> > > I don't know what you're doing exactly that caused it to be
> > > unnecessarily marked as FAILED. But whatever it is, it's not working,
> > > and it is causing backports to be missed.
> >
> > We don't use git for cherry-picking as we have a patch queue, so renames
> > will often times fail, like it did here. This has always been the case
> > in the decades we have been running the stable kernels :)
>
> Again, this has been a problem for a long time, and it's time for you to
> fix your process. You can still have the patch queue; just use git for
> the actual cherry-pick.
Also I should mention that your own instructions for "reproducing" the
conflict use 'git cherry-pick':
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 8c2f1288250a90a4b5cabed5d888d7e3aeed4035
# <resolve conflicts, build, test, etc.>
git commit -s
git send-email --to '<stable@vger.kernel.org>' --in-reply-to '2026051223-undercoat-reps-6626@gregkh' --subject-prefix 'PATCH 6.1.y' HEAD^..
When these instructions are followed, there is no conflict. The
"conflict" is purely because you didn't use 'git cherry-pick' yourself.
So just start using 'git cherry-pick', and stop asking other people to
do it for you when there are no conflicts, please.
And please start Cc'ing the mailing lists. Linux kernel development
isn't done in private email. I would have backported the copy.fail
fixes earlier, but I never received the FAILED emails (which I'm
guessing you sent, but only in private email to other people), so I
didn't know they weren't being backported...
- Eric
^ permalink raw reply
* Re: [PATCH RFC 01/17] lib/crc: add crc32c_flip_range() for incremental CRC update
From: Eric Biggers @ 2026-05-14 3:52 UTC (permalink / raw)
To: Baokun Li
Cc: linux-ext4, linux-crypto, ardb, tytso, adilger.kernel, jack,
yi.zhang, ojaswin, ritesh.list
In-Reply-To: <20260508121539.4174601-2-libaokun@linux.alibaba.com>
On Fri, May 08, 2026 at 08:15:23PM +0800, Baokun Li wrote:
> When a contiguous range of bits in a buffer is flipped, the CRC32c
> checksum can be updated incrementally without re-scanning the entire
> buffer, by exploiting the linearity of CRCs over GF(2):
>
> New_CRC = Old_CRC ^ CRC(flip_mask << trailing_bits)
>
> Introduce crc32c_flip_range() which computes this delta using
> precomputed GF(2) shift matrices and nibble-indexed lookup tables.
> The implementation decomposes nbits and trailing_bits into
> power-of-2 components and combines them via the CRC concatenation
> property:
>
> CRC(A || B) = shift(CRC(A), len(B)) ^ CRC(B)
>
> This gives O(log N) complexity with only ~9.8KB of static tables
> (fits in L1 cache). The current maximum supported buffer size is
> 64KB (INCR_MAX_ORDER = 19, i.e. 2^19 bits = 524288 bits = 64KB).
It will be a little while before I can do a full review of this, but
just a high-level comment: "only ~9.8KB of static tables (fits in L1
cache)" isn't ideal. Large tables tend to microbenchmark well, then
have worse real-world performance due to lots of other things contending
for the L1 cache.
Another consideration is that basically every Linux kernel has
CONFIG_CRC32 enabled, regardless of whether they would actually find
this new functionality useful.
I'm not necessarily saying this should be its own option, especially if
it's useful for ext4 even in the non-LBS case. But I do think it would
be nice if it could be a bit smaller and more memory-optimized.
Anyway, I'll look into the algorithm more when I have time.
- Eric
^ permalink raw reply
* [PATCH] X.509: Fix validation of ASN.1 certificate header
From: Lukas Wunner @ 2026-05-14 6:55 UTC (permalink / raw)
To: Herbert Xu, David S. Miller, David Howells, Ignat Korchagin
Cc: keyrings, linux-crypto
x509_load_certificate_list() seeks to enforce that a certificate starts
with 0x30 0x82 (ASN.1 SEQUENCE tag followed by a length of more than 256
and less than 65535 bytes).
But it only enforces that *either* of those two byte values are present,
instead of checking for the *conjunction* of the two values. Fix it.
Fixes: 631cc66eb9ea ("MODSIGN: Provide module signing public keys to the kernel")
Reported-by: Sashiko <sashiko-bot@kernel.org>
Closes: https://lore.kernel.org/r/20260508033917.B5873C2BCB0@smtp.kernel.org/
Signed-off-by: Lukas Wunner <lukas@wunner.de>
Cc: stable@vger.kernel.org # v3.7+
---
crypto/asymmetric_keys/x509_loader.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/crypto/asymmetric_keys/x509_loader.c b/crypto/asymmetric_keys/x509_loader.c
index a417413..0d516c7 100644
--- a/crypto/asymmetric_keys/x509_loader.c
+++ b/crypto/asymmetric_keys/x509_loader.c
@@ -20,7 +20,7 @@ int x509_load_certificate_list(const u8 cert_list[],
*/
if (end - p < 4)
goto dodgy_cert;
- if (p[0] != 0x30 &&
+ if (p[0] != 0x30 ||
p[1] != 0x82)
goto dodgy_cert;
plen = (p[2] << 8) | p[3];
--
2.51.0
^ permalink raw reply related
* 回复: [PATCH v1 1/2] dt-bindings: Add bindings for StarFive JHB100 SoC trng controller.
From: Lianfeng Ouyang @ 2026-05-14 6:41 UTC (permalink / raw)
To: Conor Dooley
Cc: Olivia Mackall, Herbert Xu, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Philipp Zabel, linux-crypto@vger.kernel.org,
devicetree@vger.kernel.org, linux-kernel@vger.kernel.org
In-Reply-To: <20260512-rifling-granny-a467a53ef289@spud>
> -----邮件原件-----
> 发件人: Conor Dooley <conor@kernel.org>
> 发送时间: 2026年5月13日 3:36
> 收件人: Lianfeng Ouyang <lianfeng.ouyang@starfivetech.com>
> 抄送: Olivia Mackall <olivia@selenic.com>; Herbert Xu
> <herbert@gondor.apana.org.au>; Rob Herring <robh@kernel.org>; Krzysztof
> Kozlowski <krzk+dt@kernel.org>; Conor Dooley <conor+dt@kernel.org>; Philipp
> Zabel <p.zabel@pengutronix.de>; linux-crypto@vger.kernel.org;
> devicetree@vger.kernel.org; linux-kernel@vger.kernel.org
> 主题: Re: [PATCH v1 1/2] dt-bindings: Add bindings for StarFive JHB100 SoC trng
> controller.
>
> On Tue, May 12, 2026 at 06:15:07PM +0100, Conor Dooley wrote:
> > On Tue, May 12, 2026 at 02:24:03PM +0800, lianfeng.ouyang wrote:
> > > From: Lianfeng Ouyang <lianfeng.ouyang@starfivetech.com>
> > >
> > > Signed-off-by: Lianfeng Ouyang <lianfeng.ouyang@starfivetech.com>
> > > ---
> > > Documentation/devicetree/bindings/rng/starfive,jh7110-trng.yaml | 2
> > > +-
> > > 1 file changed, 1 insertion(+), 1 deletion(-)
> > >
> > > diff --git
> > > a/Documentation/devicetree/bindings/rng/starfive,jh7110-trng.yaml
> > > b/Documentation/devicetree/bindings/rng/starfive,jh7110-trng.yaml
> > > index 4639247e9e51..11346d77b2f6 100644
> > > ---
> > > a/Documentation/devicetree/bindings/rng/starfive,jh7110-trng.yaml
> > > +++ b/Documentation/devicetree/bindings/rng/starfive,jh7110-trng.yam
> > > +++ l
> > > @@ -13,8 +13,8 @@ properties:
> > > compatible:
> > > oneOf:
> > > - items:
> > > - - const: starfive,jh8100-trng
> > > - const: starfive,jh7110-trng
> > > + - const: starfive,jhb100-trng
> >
> > You need to add a commit message here explaining why removing the
> > jh8100 is okay.
> > pw-bot: changes-requested
Okay, Jh8100 will no longer be supported, so it will be removed from the driver. In the next version, I will add these descriptions to the commit message
>
> Additionally, given the driver changes, it looks like using a jh7110 fallback is
> invalid anyway.
Thank you for your correction. The next version will be revised as follows
compatible:
enum:
- starfive,jh7110-trng
- starfive,jhb100-trng
>
> >
> > > - const: starfive,jh7110-trng
> > >
> > > reg:
> > > --
> > > 2.43.0
> > >
> > >
>
^ permalink raw reply
* Re: [PATCH] X.509: Fix validation of ASN.1 certificate header
From: Ignat Korchagin @ 2026-05-14 7:20 UTC (permalink / raw)
To: Lukas Wunner
Cc: Herbert Xu, David S. Miller, David Howells, keyrings,
linux-crypto
In-Reply-To: <782bc59d5939aa69b58cad42f71946f1c0a6dccb.1778741457.git.lukas@wunner.de>
On Thu, May 14, 2026 at 7:55 AM Lukas Wunner <lukas@wunner.de> wrote:
>
> x509_load_certificate_list() seeks to enforce that a certificate starts
> with 0x30 0x82 (ASN.1 SEQUENCE tag followed by a length of more than 256
> and less than 65535 bytes).
>
> But it only enforces that *either* of those two byte values are present,
> instead of checking for the *conjunction* of the two values. Fix it.
>
> Fixes: 631cc66eb9ea ("MODSIGN: Provide module signing public keys to the kernel")
> Reported-by: Sashiko <sashiko-bot@kernel.org>
> Closes: https://lore.kernel.org/r/20260508033917.B5873C2BCB0@smtp.kernel.org/
> Signed-off-by: Lukas Wunner <lukas@wunner.de>
> Cc: stable@vger.kernel.org # v3.7+
Reviewed-by: Ignat Korchagin <ignat@linux.win>
> ---
> crypto/asymmetric_keys/x509_loader.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/crypto/asymmetric_keys/x509_loader.c b/crypto/asymmetric_keys/x509_loader.c
> index a417413..0d516c7 100644
> --- a/crypto/asymmetric_keys/x509_loader.c
> +++ b/crypto/asymmetric_keys/x509_loader.c
> @@ -20,7 +20,7 @@ int x509_load_certificate_list(const u8 cert_list[],
> */
> if (end - p < 4)
> goto dodgy_cert;
> - if (p[0] != 0x30 &&
> + if (p[0] != 0x30 ||
Whoa! Nice catch...
> p[1] != 0x82)
> goto dodgy_cert;
> plen = (p[2] << 8) | p[3];
> --
> 2.51.0
>
>
^ permalink raw reply
* Re: [PATCH v3] dt-bindings: crypto: qcom,prng: Document TRNG on Nord SoC
From: Krzysztof Kozlowski @ 2026-05-14 10:56 UTC (permalink / raw)
To: Shawn Guo
Cc: Herbert Xu, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Konrad Dybcio, Bartosz Golaszewski, Deepti Jaggi, linux-arm-msm,
linux-crypto, devicetree, linux-kernel
In-Reply-To: <20260510021809.1130114-1-shengchao.guo@oss.qualcomm.com>
On Sun, May 10, 2026 at 10:18:09AM +0800, Shawn Guo wrote:
> From: Deepti Jaggi <deepti.jaggi@oss.qualcomm.com>
>
> Document True Random Number Generator on Qualcomm Nord SoC.
>
> Signed-off-by: Deepti Jaggi <deepti.jaggi@oss.qualcomm.com>
> Signed-off-by: Shawn Guo <shengchao.guo@oss.qualcomm.com>
> ---
Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v2 0/3] soc: qcom: ice: Enable firmware managed resource
From: Krzysztof Kozlowski @ 2026-05-14 12:52 UTC (permalink / raw)
To: Linlin Zhang
Cc: Rob Herring, Conor Dooley, Bjorn Andersson, Konrad Dybcio,
Herbert Xu, David S . Miller, devicetree, linux-crypto,
linux-arm-msm, linux-kernel
In-Reply-To: <20260512033750.3393050-1-linlin.zhang@oss.qualcomm.com>
On Mon, May 11, 2026 at 08:37:47PM -0700, Linlin Zhang wrote:
> From: linlzhan <linlzhan@qti.qualcomm.com>
>
> The Qualcomm automotive SA8255p SoC relies on firmware to configure
> platform resources, including clocks, interconnects and TLMM (GPIOs).
> These resources are controlled by the driver via SCMI power and
> performance protocols.
>
> The SCMI power protocol is used to enable and disable platform
> resources, including clocks, interconnect paths, and TLMM, by mapping
> resource state transitions to the runtime PM framework?s
> resume/suspend callbacks.
>
> In this design, the ICE driver acts as an SCMI client, with clocks and
> power domains abstracted and controlled by the SCMI server in firmware.
> This implementation depends on pm_runtime_resume_and_get() and
> pm_runtime_put_sync(), which are available in the OPP tree?s
> linux-next branch.
>
> v2:
> -- rebase the patchset
> -- update to/cc lists
> -- Link to v1: https://lore.kernel.org/all/20260430032136.3058773-1-linlin.zhang@oss.qualcomm.com/
>
> -- To Linux Community
>
> v6:
> - Protect calling clock API with fw_managed flag in ICE runtime OPS callbacks.
> - Link to v5: http://shc-kerarch-hyd:8080/kernel_archive/20260324095703.1306437-1-linlin.zhang@oss.qualcomm.com/T/#t
Please do not include non-working links in public postings.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v2 1/3] dt-bindings: crypto: qcom,ice: Add sa8255p support
From: Krzysztof Kozlowski @ 2026-05-14 12:55 UTC (permalink / raw)
To: Linlin Zhang
Cc: Rob Herring, Conor Dooley, Bjorn Andersson, Konrad Dybcio,
Herbert Xu, David S . Miller, devicetree, linux-crypto,
linux-arm-msm, linux-kernel
In-Reply-To: <20260512033750.3393050-2-linlin.zhang@oss.qualcomm.com>
On Mon, May 11, 2026 at 08:37:48PM -0700, Linlin Zhang wrote:
> On sa8255p, resources such as PHY, clocks, regulators, and resets are
> managed by remote firmware via the SCMI power protocol. As a result, the
> ICE driver cannot directly access clocks and must instead use power-domains
> to request resource configuration.
Then how can it be compatible with qcom,inline-crypto-engine?
>
> Add the qcom,sa8255p-inline-crypto-engine compatible string and make clocks
> optional for platforms that use power-domains instead.
>
> Signed-off-by: Linlin Zhang <linlin.zhang@oss.qualcomm.com>
> ---
> .../crypto/qcom,inline-crypto-engine.yaml | 27 ++++++++++++++++++-
> 1 file changed, 26 insertions(+), 1 deletion(-)
So this is v2? But previous was v6? Look:
b4 diff '20260512033750.3393050-1-linlin.zhang@oss.qualcomm.com'
Looking up https://lore.kernel.org/all/20260512033750.3393050-1-linlin.zhang@oss.qualcomm.com/
Grabbing thread from lore.kernel.org/all/20260512033750.3393050-1-linlin.zhang@oss.qualcomm.com/t.mbox.gz
Checking for older revisions
Grabbing search results from lore.kernel.org
---
Analyzing 8 messages in the thread
Could not find lower series to compare against.
>
> diff --git a/Documentation/devicetree/bindings/crypto/qcom,inline-crypto-engine.yaml b/Documentation/devicetree/bindings/crypto/qcom,inline-crypto-engine.yaml
> index 876bf90ed96e..4e7d9111d0eb 100644
> --- a/Documentation/devicetree/bindings/crypto/qcom,inline-crypto-engine.yaml
> +++ b/Documentation/devicetree/bindings/crypto/qcom,inline-crypto-engine.yaml
This should go to its own binding file just like in all other
SCMI-variant cases. And if you looked how these other files are done,
you would see my complains already that generic fallback is most likely
wrong.
Otherwise explain me what the generic fallback means here and how is it
supposed to work?
Best regards,
Krzysztof
^ permalink raw reply
* [PATCH 0/2] Add support for rng on shikra
From: Kuldeep Singh @ 2026-05-14 13:16 UTC (permalink / raw)
To: Herbert Xu, David S. Miller, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Vinod Koul, Bjorn Andersson, Konrad Dybcio
Cc: linux-arm-msm, linux-crypto, devicetree, linux-kernel,
Kuldeep Singh
The patchseries contain dt-binding and DT changes for enabling rng on
shikra.
This series depends on the following prerequisite patchset:
- https://lore.kernel.org/all/20260512-shikra-dt-v1-0-716438330dd0@oss.qualcomm.com/
Tested-on: shikra-iqs-evk
Testing:
- Boot the board and verify qcom_rng driver probe success.
- Validated rngtest utils
- validated against dt_binding and dtbs_check.
Steps followed:
- cat /sys/class/misc/hw_random/rng_available
- echo qcom_hwrng > /sys/class/misc/hw_random/rng_current
- cat /sys/class/misc/hw_random/rng_current
- cat /dev/random | rngtest -c 1000
Signed-off-by: Kuldeep Singh <kuldeep.singh@oss.qualcomm.com>
---
Kuldeep Singh (2):
dt-bindings: crypto: qcom,prng: Document Shikra TRNG
arm64: dts: qcom: shikra: Add TRNG support
Documentation/devicetree/bindings/crypto/qcom,prng.yaml | 1 +
arch/arm64/boot/dts/qcom/shikra.dtsi | 5 +++++
2 files changed, 6 insertions(+)
---
base-commit: 33c8e3305b65a2e757e68b10af521ad54ea051a6
change-id: 20260514-shikra_rng-ce87409afd22
Best regards,
--
Kuldeep Singh <kuldeep.singh@oss.qualcomm.com>
^ permalink raw reply
* [PATCH 1/2] dt-bindings: crypto: qcom,prng: Document Shikra TRNG
From: Kuldeep Singh @ 2026-05-14 13:16 UTC (permalink / raw)
To: Herbert Xu, David S. Miller, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Vinod Koul, Bjorn Andersson, Konrad Dybcio
Cc: linux-arm-msm, linux-crypto, devicetree, linux-kernel,
Kuldeep Singh
In-Reply-To: <20260514-shikra_rng-v1-0-4ea721a1429a@oss.qualcomm.com>
Document shikra compatible for the True Random Number Generator.
Signed-off-by: Kuldeep Singh <kuldeep.singh@oss.qualcomm.com>
---
Documentation/devicetree/bindings/crypto/qcom,prng.yaml | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation/devicetree/bindings/crypto/qcom,prng.yaml b/Documentation/devicetree/bindings/crypto/qcom,prng.yaml
index 498d6914135e..e2430280b2a3 100644
--- a/Documentation/devicetree/bindings/crypto/qcom,prng.yaml
+++ b/Documentation/devicetree/bindings/crypto/qcom,prng.yaml
@@ -28,6 +28,7 @@ properties:
- qcom,sa8255p-trng
- qcom,sa8775p-trng
- qcom,sc7280-trng
+ - qcom,shikra-trng
- qcom,sm8450-trng
- qcom,sm8550-trng
- qcom,sm8650-trng
--
2.34.1
^ permalink raw reply related
* [PATCH 2/2] arm64: dts: qcom: shikra: Add TRNG support
From: Kuldeep Singh @ 2026-05-14 13:16 UTC (permalink / raw)
To: Herbert Xu, David S. Miller, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Vinod Koul, Bjorn Andersson, Konrad Dybcio
Cc: linux-arm-msm, linux-crypto, devicetree, linux-kernel,
Kuldeep Singh
In-Reply-To: <20260514-shikra_rng-v1-0-4ea721a1429a@oss.qualcomm.com>
Add True Random Number Generator(TRNG) node for shikra.
Signed-off-by: Kuldeep Singh <kuldeep.singh@oss.qualcomm.com>
---
arch/arm64/boot/dts/qcom/shikra.dtsi | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/shikra.dtsi b/arch/arm64/boot/dts/qcom/shikra.dtsi
index 262c488add1e..e81210254ba4 100644
--- a/arch/arm64/boot/dts/qcom/shikra.dtsi
+++ b/arch/arm64/boot/dts/qcom/shikra.dtsi
@@ -580,6 +580,11 @@ spmi_bus: spmi@1c40000 {
qcom,ee = <0>;
};
+ rng: rng@4454000 {
+ compatible = "qcom,shikra-trng", "qcom,trng";
+ reg = <0 0x04454000 0 0x1000>;
+ };
+
rpm_msg_ram: sram@45f0000 {
compatible = "qcom,rpm-msg-ram", "mmio-sram";
reg = <0x0 0x045f0000 0x0 0x7000>;
--
2.34.1
^ permalink raw reply related
* Re: [PATCH v2 0/3] soc: qcom: ice: Enable firmware managed resource
From: Krzysztof Kozlowski @ 2026-05-14 14:00 UTC (permalink / raw)
To: Linlin Zhang, Rob Herring, Conor Dooley
Cc: Herbert Xu, David S . Miller, Bjorn Andersson, devicetree,
linux-crypto, linux-arm-msm, linux-kernel
In-Reply-To: <20260507112454.2527088-1-linlin.zhang@oss.qualcomm.com>
On 07/05/2026 13:24, Linlin Zhang wrote:
> From: linlzhan <linlzhan@qti.qualcomm.com>
>
> The Qualcomm automotive SA8255p SoC relies on firmware to configure
> platform resources, including clocks, interconnects and TLMM (GPIOs).
> These resources are controlled by the driver via SCMI power and
> performance protocols.
>
> The SCMI power protocol is used to enable and disable platform
> resources, including clocks, interconnect paths, and TLMM, by mapping
> resource state transitions to the runtime PM framework�s
> resume/suspend callbacks.
>
> In this design, the ICE driver acts as an SCMI client, with clocks and
> power domains abstracted and controlled by the SCMI server in firmware.
> This implementation depends on pm_runtime_resume_and_get() and
> pm_runtime_put_sync(), which are available in the OPP tree�s
> linux-next branch.
>
> v2:
> -- rebase the patchset
> -- update to/cc lists
> -- Link to v1: https://lore.kernel.org/all/20260430032136.3058773-1-linlin.zhang@oss.qualcomm.com/
>
> -- To Linux Community
>
Why did I receive this twice? First posted on 7th of May and then on
12th of May?
https://lore.kernel.org/all/20260507112454.2527088-2-linlin.zhang@oss.qualcomm.com/
And why do you still Cc incorrect address?
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v2 2/3] soc: qcom: ice: Enable PM runtime for ICE driver
From: Krzysztof Kozlowski @ 2026-05-14 14:06 UTC (permalink / raw)
To: Linlin Zhang, Rob Herring, Conor Dooley, Bjorn Andersson,
Konrad Dybcio
Cc: Herbert Xu, David S . Miller, devicetree, linux-crypto,
linux-arm-msm, linux-kernel, Neeraj Soni, Deepti Jaggi
In-Reply-To: <20260512033750.3393050-3-linlin.zhang@oss.qualcomm.com>
On 12/05/2026 05:37, Linlin Zhang wrote:
> The QCOM ICE driver manages the ICE core clock through direct calls to
> clk_prepare_enable() and clk_disable_unprepare(), which limits integration
No, it does not limit any integration.
> with platforms that rely on firmware-managed resources or platform-specific
> power management mechanisms.
Nope. It's perfectly correct way of managing clocks. Adding runtime PM
ONLY to toggle clocks is absolute killer, pointless overhead without
benefits.
>
> Replace direct clock management with runtime PM support by moving clock
> enable and disable into runtime PM callbacks. Use
> pm_runtime_resume_and_get() and pm_runtime_put_sync() in qcom_ice_resume()
> and qcom_ice_suspend() to drive power state transitions, and enable runtime
> PM in qcom_ice_probe().
>
> Reviewed-by: Neeraj Soni <neeraj.soni@oss.qualcomm.com>
> Reviewed-by: Deepti Jaggi <deepti.jaggi@oss.qualcomm.com>
> Signed-off-by: Linlin Zhang <linlin.zhang@oss.qualcomm.com>
> ---
> drivers/soc/qcom/ice.c | 58 ++++++++++++++++++++++++++++++++++++++----
> 1 file changed, 53 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/soc/qcom/ice.c b/drivers/soc/qcom/ice.c
> index b203bc685cad..6f9d679b530c 100644
> --- a/drivers/soc/qcom/ice.c
> +++ b/drivers/soc/qcom/ice.c
> @@ -16,6 +16,7 @@
> #include <linux/of.h>
> #include <linux/of_platform.h>
> #include <linux/platform_device.h>
> +#include <linux/pm_runtime.h>
>
> #include <linux/firmware/qcom/qcom_scm.h>
>
> @@ -310,8 +311,8 @@ int qcom_ice_resume(struct qcom_ice *ice)
> struct device *dev = ice->dev;
> int err;
>
> - err = clk_prepare_enable(ice->core_clk);
> - if (err) {
> + err = pm_runtime_resume_and_get(dev);
> + if (err < 0) {
> dev_err(dev, "failed to enable core clock (%d)\n",
> err);
> return err;
> @@ -323,7 +324,7 @@ EXPORT_SYMBOL_GPL(qcom_ice_resume);
>
> int qcom_ice_suspend(struct qcom_ice *ice)
> {
> - clk_disable_unprepare(ice->core_clk);
> + pm_runtime_put_sync(ice->dev);
> ice->hwkm_init_complete = false;
>
> return 0;
This is pretty pointless change. At least by quick glance. You changed
nothing here for PM, except adding indirection layer and more locks.
Clocks will be gated the same way, no energy savings. But on the other
hand introducing runtime PM subsystem is huge bunch of code with its own
locks, completely unnecessary here.
This itself is poor choice and has NEGATIVE impact on all existing
platforms without any benefit.
I am surprised you went through SIX internal reviews, collected two
internal review tags and no one suggested that using runtime PM ONLY to
toggle clocks is pretty pointless and undesired.
Best regards,
Krzysztof
^ permalink raw reply
* [PATCH net v3 2/4] crypto/krb5, rxrpc: Fix lack of pre-decrypt/pre-verify length checks
From: David Howells @ 2026-05-14 15:53 UTC (permalink / raw)
To: netdev
Cc: David Howells, Hyunwoo Kim, Marc Dionne, Jakub Kicinski,
David S. Miller, Eric Dumazet, Paolo Abeni, Simon Horman,
linux-afs, linux-kernel, Jeffrey Altman, Herbert Xu, Chuck Lever,
linux-nfs, linux-crypto, stable
In-Reply-To: <20260514155304.2249591-1-dhowells@redhat.com>
Change the krb5 crypto library to provide facilities to precheck the length
of the message about to be decrypted or verified.
Fix AF_RXRPC to make use of this to validate DATA packets secured with
RxGK.
Fixes: 9d1d2b59341f ("rxrpc: rxgk: Implement the yfs-rxgk security class (GSSAPI)")
Closes: https://sashiko.dev/#/patchset/20260511160753.607296-1-dhowells%40redhat.com
Signed-off-by: David Howells <dhowells@redhat.com>
cc: Marc Dionne <marc.dionne@auristor.com>
cc: Jeffrey Altman <jaltman@auristor.com>
cc: Herbert Xu <herbert@gondor.apana.org.au>
cc: "David S. Miller" <davem@davemloft.net>
cc: Eric Dumazet <edumazet@google.com>
cc: Jakub Kicinski <kuba@kernel.org>
cc: Paolo Abeni <pabeni@redhat.com>
cc: Simon Horman <horms@kernel.org>
cc: Chuck Lever <chuck.lever@oracle.com>
cc: netdev@vger.kernel.org
cc: linux-afs@lists.infradead.org
cc: linux-nfs@vger.kernel.org
cc: linux-crypto@vger.kernel.org
cc: stable@vger.kernel.org
---
Documentation/crypto/krb5.rst | 17 ++++++++---
crypto/krb5/krb5_api.c | 54 +++++++++++++++++++++++++++++++----
include/crypto/krb5.h | 9 ++++--
include/trace/events/rxrpc.h | 1 +
net/rxrpc/rxgk.c | 15 ++++++++--
5 files changed, 81 insertions(+), 15 deletions(-)
diff --git a/Documentation/crypto/krb5.rst b/Documentation/crypto/krb5.rst
index beffa0133446..f62e07ac6811 100644
--- a/Documentation/crypto/krb5.rst
+++ b/Documentation/crypto/krb5.rst
@@ -158,13 +158,22 @@ returned.
When a message has been received, the location and size of the data with the
message can be determined by calling::
- void crypto_krb5_where_is_the_data(const struct krb5_enctype *krb5,
- enum krb5_crypto_mode mode,
- size_t *_offset, size_t *_len);
+ int crypto_krb5_where_is_the_data(const struct krb5_enctype *krb5,
+ enum krb5_crypto_mode mode,
+ size_t *_offset, size_t *_len);
The caller provides the offset and length of the message to the function, which
then alters those values to indicate the region containing the data (plus any
-padding). It is up to the caller to determine how much padding there is.
+padding). It is up to the caller to determine how much padding there is. The
+function returns an error if the length is too small or if the mode is
+unsupported. An additional function::
+
+ int crypto_krb5_check_data_len(const struct krb5_enctype *krb5,
+ enum krb5_crypto_mode mode,
+ size_t len, size_t min_content);
+
+is provided to just do a basic check that the decrypted/verified message would
+have a sufficient minimum payload.
Preparation Functions
---------------------
diff --git a/crypto/krb5/krb5_api.c b/crypto/krb5/krb5_api.c
index 23026d4206c8..c7ea40f900a7 100644
--- a/crypto/krb5/krb5_api.c
+++ b/crypto/krb5/krb5_api.c
@@ -134,27 +134,69 @@ EXPORT_SYMBOL(crypto_krb5_how_much_data);
* Find the offset and size of the data in a secure message so that this
* information can be used in the metadata buffer which will get added to the
* digest by crypto_krb5_verify_mic().
+ *
+ * Return: 0 if successful, -EBADMSG if the message is too short or -EINVAL if
+ * the mode is unsupported.
*/
-void crypto_krb5_where_is_the_data(const struct krb5_enctype *krb5,
- enum krb5_crypto_mode mode,
- size_t *_offset, size_t *_len)
+int crypto_krb5_where_is_the_data(const struct krb5_enctype *krb5,
+ enum krb5_crypto_mode mode,
+ size_t *_offset, size_t *_len)
{
switch (mode) {
case KRB5_CHECKSUM_MODE:
+ if (*_len < krb5->cksum_len)
+ return -EBADMSG;
*_offset += krb5->cksum_len;
*_len -= krb5->cksum_len;
- return;
+ return 0;
case KRB5_ENCRYPT_MODE:
+ if (*_len < krb5->conf_len + krb5->cksum_len)
+ return -EBADMSG;
*_offset += krb5->conf_len;
*_len -= krb5->conf_len + krb5->cksum_len;
- return;
+ return 0;
default:
WARN_ON_ONCE(1);
- return;
+ return -EINVAL;
}
}
EXPORT_SYMBOL(crypto_krb5_where_is_the_data);
+/**
+ * crypto_krb5_check_data_len - Check a message is big enough
+ * @krb5: The encoding to use.
+ * @mode: Mode of operation.
+ * @len: The length of the secure blob.
+ * @min_content: Minimum length of the content inside the blob.
+ *
+ * Check that a message is large enough to hold whatever bits the encryption
+ * type wants to glue on (nonce, checksum) plus a minimum amount of content.
+ *
+ * Return: 0 if successful, -EBADMSG if the message is too short or -EINVAL if
+ * the mode is unsupported.
+ */
+int crypto_krb5_check_data_len(const struct krb5_enctype *krb5,
+ enum krb5_crypto_mode mode,
+ size_t len, size_t min_content)
+{
+ switch (mode) {
+ case KRB5_CHECKSUM_MODE:
+ if (len < krb5->cksum_len ||
+ len - krb5->cksum_len < min_content)
+ return -EBADMSG;
+ return 0;
+ case KRB5_ENCRYPT_MODE:
+ if (len < krb5->conf_len + krb5->cksum_len ||
+ len - (krb5->conf_len + krb5->cksum_len) < min_content)
+ return -EBADMSG;
+ return 0;
+ default:
+ WARN_ON_ONCE(1);
+ return -EINVAL;
+ }
+}
+EXPORT_SYMBOL(crypto_krb5_check_data_len);
+
/*
* Prepare the encryption with derived key data.
*/
diff --git a/include/crypto/krb5.h b/include/crypto/krb5.h
index 71dd38f59be1..aac3ecf88467 100644
--- a/include/crypto/krb5.h
+++ b/include/crypto/krb5.h
@@ -121,9 +121,12 @@ size_t crypto_krb5_how_much_buffer(const struct krb5_enctype *krb5,
size_t crypto_krb5_how_much_data(const struct krb5_enctype *krb5,
enum krb5_crypto_mode mode,
size_t *_buffer_size, size_t *_offset);
-void crypto_krb5_where_is_the_data(const struct krb5_enctype *krb5,
- enum krb5_crypto_mode mode,
- size_t *_offset, size_t *_len);
+int crypto_krb5_where_is_the_data(const struct krb5_enctype *krb5,
+ enum krb5_crypto_mode mode,
+ size_t *_offset, size_t *_len);
+int crypto_krb5_check_data_len(const struct krb5_enctype *krb5,
+ enum krb5_crypto_mode mode,
+ size_t len, size_t min_content);
struct crypto_aead *crypto_krb5_prepare_encryption(const struct krb5_enctype *krb5,
const struct krb5_buffer *TK,
u32 usage, gfp_t gfp);
diff --git a/include/trace/events/rxrpc.h b/include/trace/events/rxrpc.h
index 573f2df3a2c9..704a10de6670 100644
--- a/include/trace/events/rxrpc.h
+++ b/include/trace/events/rxrpc.h
@@ -71,6 +71,7 @@
EM(rxkad_abort_resp_unknown_tkt, "rxkad-resp-unknown-tkt") \
EM(rxkad_abort_resp_version, "rxkad-resp-version") \
/* RxGK security errors */ \
+ EM(rxgk_abort_1_short_header, "rxgk1-short-hdr") \
EM(rxgk_abort_1_verify_mic_eproto, "rxgk1-vfy-mic-eproto") \
EM(rxgk_abort_2_decrypt_eproto, "rxgk2-dec-eproto") \
EM(rxgk_abort_2_short_data, "rxgk2-short-data") \
diff --git a/net/rxrpc/rxgk.c b/net/rxrpc/rxgk.c
index 0d5e654da918..26e723052a37 100644
--- a/net/rxrpc/rxgk.c
+++ b/net/rxrpc/rxgk.c
@@ -480,8 +480,12 @@ static int rxgk_verify_packet_integrity(struct rxrpc_call *call,
_enter("");
- crypto_krb5_where_is_the_data(gk->krb5, KRB5_CHECKSUM_MODE,
- &data_offset, &data_len);
+ if (crypto_krb5_where_is_the_data(gk->krb5, KRB5_CHECKSUM_MODE,
+ &data_offset, &data_len) < 0) {
+ ret = rxrpc_abort_eproto(call, skb, RXGK_PACKETSHORT,
+ rxgk_abort_1_short_header);
+ goto put_gk;
+ }
hdr = kzalloc_obj(*hdr, GFP_NOFS);
if (!hdr)
@@ -529,6 +533,13 @@ static int rxgk_verify_packet_encrypted(struct rxrpc_call *call,
_enter("");
+ if (crypto_krb5_check_data_len(gk->krb5, KRB5_ENCRYPT_MODE,
+ len, sizeof(hdr)) < 0) {
+ ret = rxrpc_abort_eproto(call, skb, RXGK_PACKETSHORT,
+ rxgk_abort_2_short_header);
+ goto error;
+ }
+
ret = rxgk_decrypt_skb(gk->krb5, gk->rx_enc, skb, &offset, &len, &ac);
if (ret < 0) {
if (ret != -ENOMEM)
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox