* Re: [PATCH v3] crypto/ccp: Introduce SNP_VERIFY_MITIGATION command
From: Tom Lendacky @ 2026-05-21 13:12 UTC (permalink / raw)
To: Pratik R. Sampat, ashish.kalra, john.allen, herbert, davem
Cc: linux-crypto, linux-kernel, aik, tycho, nikunj, michael.roth
In-Reply-To: <4ccf6dc7-88e6-488c-8314-5bcd95164661@amd.com>
On 5/20/26 21:10, Pratik R. Sampat wrote:
> Hi Tom,
>
> On 5/20/26 4:22 PM, Tom Lendacky wrote:
>> On 5/19/26 14:50, Pratik R. Sampat wrote:
>>> The SEV-SNP firmware provides the SNP_VERIFY_MITIGATION command, which
>>> can be used to query the status of currently supported vulnerability
>>> mitigations and to initiate mitigations within the firmware.
>>>
>>> This command is an explicit mechanism to ascertain if a firmware
>>> mitigation is applied without needing a full RMP re-build, which is most
>>> useful in a live firmware update scenario.
>>>
>>> The firmware supports two subcommands: STATUS and VERIFY. The STATUS
>>> subcommand is used to query the supported and verified mitigation bits.
>>> The VERIFY subcommand initiates the mitigation process within the FW for
>>> the specified vulnerability. Expose a userspace interface under:
>>> /sys/firmware/sev/vulnerabilities/
>>> - supported_mitigations (read-only): supported mitigation vector mask
>>> - verified_mitigations (read/write): current verified mask; write a
>>> vector to request VERIFY for that bit
>>>
>>> The behavior of SNP_VERIFY_MITIGATION and the pre-requisites for using
>>> it are bug-specific. Information about supported mitigations and its
>>> corresponding vector is to be published as part of the AMD Security
>>> Bulletin.
>>>
>>> See SEV-SNP Firmware ABI specifications 1.58, SNP_VERIFY_MITIGATION for
>>> more details.
>>>
>>> Signed-off-by: Pratik R. Sampat <prsampat@amd.com>
>>> ---
>>> .../sysfs-firmware-sev-vulnerabilities | 17 ++
>>> drivers/crypto/ccp/sev-dev.c | 172 ++++++++++++++++++
>>> drivers/crypto/ccp/sev-dev.h | 3 +
>>> include/linux/psp-sev.h | 51 ++++++
>>> 4 files changed, 243 insertions(+)
>>> create mode 100644 Documentation/ABI/testing/sysfs-firmware-sev-vulnerabilities
>>>
>>> diff --git a/Documentation/ABI/testing/sysfs-firmware-sev-vulnerabilities b/Documentation/ABI/testing/sysfs-firmware-sev-vulnerabilities
>>> new file mode 100644
>>> index 000000000000..cc84adbac3c0
>>> --- /dev/null
>>> +++ b/Documentation/ABI/testing/sysfs-firmware-sev-vulnerabilities
>>> @@ -0,0 +1,17 @@
>>> +What: /sys/firmware/sev/vulnerabilities/
>>> + /sys/firmware/sev/vulnerabilities/supported_mitigations
>>> + /sys/firmware/sev/vulnerabilities/verified_mitigations
>>> +Date: May 2026
>>> +Contact: linux-crypto@vger.kernel.org
>>> +Description: Information about SEV-SNP firmware vulnerability mitigations.
>>> + supported_mitigations: Read-only interface that reports
>>> + the vector of mitigations supported by
>>> + the firmware.
>>> + verified_mitigations: Read/write interface that reports
>>> + the vector of mitigations already verified
>>> + by the firmware. Writing a vector value
>>> + requests the firmware to VERIFY the
>>> + corresponding mitigation bit(s).
>>> + The list of supported mitigations and the meaning of each
>>> + vector bit are both platform- and bug-specific and are
>>> + published as part of the AMD Security Bulletin.
>>> diff --git a/drivers/crypto/ccp/sev-dev.c b/drivers/crypto/ccp/sev-dev.c
>>> index d1e9e0ac63b6..eec4864c6597 100644
>>> --- a/drivers/crypto/ccp/sev-dev.c
>>> +++ b/drivers/crypto/ccp/sev-dev.c
>>> @@ -57,6 +57,7 @@
>>> #define CMD_BUF_DESC_MAX (CMD_BUF_FW_WRITABLE_MAX + 1)
>>>
>>> static DEFINE_MUTEX(sev_cmd_mutex);
>>> +static DEFINE_MUTEX(sev_mit_sysfs_mutex);
>>> static struct sev_misc_dev *misc_dev;
>>>
>>> static int psp_cmd_timeout = 100;
>>> @@ -245,6 +246,7 @@ static int sev_cmd_buffer_len(int cmd)
>>> case SEV_CMD_SNP_LAUNCH_FINISH: return sizeof(struct sev_data_snp_launch_finish);
>>> case SEV_CMD_SNP_DBG_DECRYPT: return sizeof(struct sev_data_snp_dbg);
>>> case SEV_CMD_SNP_DBG_ENCRYPT: return sizeof(struct sev_data_snp_dbg);
>>> + case SEV_CMD_SNP_VERIFY_MITIGATION: return sizeof(struct sev_data_snp_verify_mitigation);
>>> case SEV_CMD_SNP_PAGE_UNSMASH: return sizeof(struct sev_data_snp_page_unsmash);
>>> case SEV_CMD_SNP_PLATFORM_STATUS: return sizeof(struct sev_data_snp_addr);
>>> case SEV_CMD_SNP_GUEST_REQUEST: return sizeof(struct sev_data_snp_guest_request);
>>> @@ -1351,6 +1353,162 @@ static int snp_filter_reserved_mem_regions(struct resource *rs, void *arg)
>>> return 0;
>>> }
>>>
>>> +static int snp_verify_mitigation(u16 command, u64 vector,
>>> + struct sev_data_snp_verify_mitigation_dst *dst)
>>> +{
>>> + struct sev_data_snp_verify_mitigation_dst *mit_dst = NULL;
>>> + struct sev_data_snp_verify_mitigation data = {0};
>>> + struct sev_device *sev = psp_master->sev_data;
>>> + int ret, error = 0;
>>> +
>>> + mit_dst = snp_alloc_firmware_page(GFP_KERNEL | __GFP_ZERO);
>>> + if (!mit_dst)
>>> + return -ENOMEM;
>>> +
>>> + data.length = sizeof(data);
>>> + data.subcommand = command;
>>> + data.vector = vector;
>>> + data.dst_paddr = __psp_pa(mit_dst);
>>> + data.dst_paddr_en = true;
>>> +
>>> + ret = sev_do_cmd(SEV_CMD_SNP_VERIFY_MITIGATION, &data, &error);
>>> + if (!ret)
>>> + memcpy(dst, mit_dst, sizeof(*mit_dst));
>>> + else
>>> + dev_err(sev->dev, "SNP_VERIFY_MITIGATION command failed, ret = %d, error = %#x\n",
>>> + ret, error);
>>> +
>>> + snp_free_firmware_page(mit_dst);
>>> +
>>> + return ret;
>>> +}
>>
>> Should this function also be under the CONFIG_SYSFS #ifdef? Won't you get
>> an unused function warning if CONFIG_SYSFS isn't defined?
>
> That's right. Thanks for spotting that!
>
>>
>>> +
>>> +#ifdef CONFIG_SYSFS
>>> +static ssize_t supported_mitigations_show(struct kobject *kobj,
>>> + struct kobj_attribute *attr, char *buf)
>>> +{
>>> + struct sev_data_snp_verify_mitigation_dst dst;
>>> + int ret;
>>> +
>>> + ret = snp_verify_mitigation(SNP_MIT_SUBCMD_REQ_STATUS, 0, &dst);
>>> + if (ret)
>>> + return ret;
>>> +
>>> + return sysfs_emit(buf, "0x%llx\n", dst.mit_supported_vector);
>>> +}
>>> +
>>> +static struct kobj_attribute supported_attr =
>>> + __ATTR_RO_MODE(supported_mitigations, 0400);
>>> +
>>> +static ssize_t verified_mitigations_show(struct kobject *kobj,
>>> + struct kobj_attribute *attr, char *buf)
>>> +{
>>> + struct sev_data_snp_verify_mitigation_dst dst;
>>> + int ret;
>>> +
>>> + ret = snp_verify_mitigation(SNP_MIT_SUBCMD_REQ_STATUS, 0, &dst);
>>> + if (ret)
>>> + return ret;
>>> +
>>> + return sysfs_emit(buf, "0x%llx\n", dst.mit_verified_vector);
>>> +}
>>> +
>>> +static ssize_t verified_mitigations_store(struct kobject *kobj,
>>> + struct kobj_attribute *attr,
>>> + const char *buf, size_t count)
>>> +{
>>> + struct sev_data_snp_verify_mitigation_dst dst;
>>> + struct sev_device *sev = psp_master->sev_data;
>>> + u64 vector;
>>> + int ret;
>>> +
>>> + ret = kstrtoull(buf, 0, &vector);
>>> + if (ret)
>>> + return ret;
>>> +
>>> + ret = snp_verify_mitigation(SNP_MIT_SUBCMD_REQ_VERIFY, vector, &dst);
>>> + if (ret)
>>> + return ret;
>>> +
>>> + if (dst.mit_failure_status) {
>>> + dev_err(sev->dev, "Verify Mitigation - failure status: 0x%x\n",
>>> + dst.mit_failure_status);
>>> + return -EIO;
>>> + }
>>> +
>>> + return count;
>>> +}
>>> +
>>> +static struct kobj_attribute verified_attr =
>>> + __ATTR_RW_MODE(verified_mitigations, 0600);
>>> +
>>> +static struct attribute *mitigation_attrs[] = {
>>> + &supported_attr.attr,
>>> + &verified_attr.attr,
>>> + NULL
>>> +};
>>> +
>>> +static const struct attribute_group mit_attr_group = {
>>> + .attrs = mitigation_attrs,
>>> +};
>>> +
>>> +static void sev_snp_register_verify_mitigation(struct sev_device *sev)
>>> +{
>>> + int rc;
>>> +
>>> + if (!sev->snp_initialized || !sev->snp_plat_status.feature_info ||
>>> + !(sev->snp_feat_info_0.ecx & SNP_VERIFY_MITIGATION_SUPPORTED))
>>> + return;
>>> +
>>> + guard(mutex)(&sev_mit_sysfs_mutex);
>>> +
>>> + if (sev->verify_mit)
>>> + return;
>>> +
>>> + if (!sev->sev_kobj) {
>>> + sev->sev_kobj = kobject_create_and_add("sev", firmware_kobj);
>>> + if (!sev->sev_kobj)
>>> + return;
>>> + }
>>> +
>>> + sev->verify_mit = kobject_create_and_add("vulnerabilities", sev->sev_kobj);
>>> + if (!sev->verify_mit)
>>> + goto err_sev_kobj;
>>> +
>>> + rc = sysfs_create_group(sev->verify_mit, &mit_attr_group);
>>> + if (rc)
>>> + goto err_verify_mit;
>>> +
>>> + return;
>>> +
>>> +err_verify_mit:
>>> + kobject_put(sev->verify_mit);
>>> + sev->verify_mit = NULL;
>>> +err_sev_kobj:
>>> + kobject_put(sev->sev_kobj);
>>> + sev->sev_kobj = NULL;
>>> +}
>>> +
>>> +static void sev_snp_unregister_verify_mitigation(struct sev_device *sev)
>>> +{
>>> + guard(mutex)(&sev_mit_sysfs_mutex);
>>> +
>>> + if (sev->verify_mit) {
>>> + sysfs_remove_group(sev->verify_mit, &mit_attr_group);
>>> + kobject_put(sev->verify_mit);
>>> + sev->verify_mit = NULL;
>>> + }
>>> +
>>> + if (sev->sev_kobj) {
>>> + kobject_put(sev->sev_kobj);
>>> + sev->sev_kobj = NULL;
>>> + }
>>> +}
>>> +#else
>>> +static void sev_snp_register_verify_mitigation(struct sev_device *sev) { }
>>> +static void sev_snp_unregister_verify_mitigation(struct sev_device *sev) { }
>>> +#endif
>>> +
>>> static int __sev_snp_init_locked(int *error, unsigned int max_snp_asid)
>>> {
>>> struct sev_data_range_list *snp_range_list __free(kfree) = NULL;
>>> @@ -1670,6 +1828,14 @@ int sev_platform_init(struct sev_platform_init_args *args)
>>> rc = _sev_platform_init_locked(args);
>>> mutex_unlock(&sev_cmd_mutex);
>>>
>>> + /*
>>> + * The shutdown + init path can race with in-flight _show()/_store() operations
>>> + * which acquire the sev_cmd_mutex. Register the sysfs interface outside
>>> + * the sev_cmd_mutex and serialize by sev_mit_sysfs_mutex instead.
>>
>> I'm not quite sure I follow this. The shutdown and init path can't race
>> with each other, right? In which case this new mutex doesn't really matter
>> unless you take it on _show()/_short(), right?
>>
> What I meant here is the new mutex attempts to addresses the following scenario:
>
> First, assume sev_snp_[un]register_verify_mitigation() are protected under
> sev_cmd_mutex:
>
> t1 | t2
> ---------------------------------- | ----------------------------------
> sev_firmware_shutdown() |
> lock(sev_cmd_mutex) |
> | verified_mitigations_store()
> | lock(sev_cmd_mutex) <-- waits on t1
> unregister_verify_mitigation() |
> sysfs_remove_group() <-- waits for t2's _store to drain
>
> So sev_snp_unregister_verify_mitigation() has to run outside sev_cmd_mutex to
> avoid the sysfs_remove_group() <-> in-flight _show()/_store() deadlock.
>
> Now, with unregister no longer protected by sev_cmd_mutex, a concurrent init
> can race with shutdown on the sysfs lifetime like so:
Can it? Can init and shutdown race? Isn't that part of module load /
unload, I'm not sure how they can race...
> t1 | t2
> ---------------------------------- | ----------------------------------
> sev_firmware_shutdown() | sev_platform_init()
> unregister_verify_mitigation() | register_verify_mitigation()
> sysfs_remove_group() | sysfs_create_group()
>
> Both sides touch sev->verify_mit without serialization. The same race also
> exists for init vs init which is no longer covered by sev_cmd_mutex once
> register moves outside it.
I don't think you can have init vs init race, can you? This just all seems
odd to me. Have you created all these race scenarios to test this out?
Would putting the regsiter/unregister under the sev_cmd_mutex and then
taking the sev_cmd_mutex upon entry to _show()/_store() fix all this?
After obtaining the mutex in _show()/_store(), you check for
sev->verify_mit and return an error if NULL. Then you can use the
__sev_do_cmd_locked() to issue any commands.
Also, on the register function, all you need is the check for
!(sev->snp_feat_info_0.ecx & SNP_VERIFY_MITIGATION_SUPPORTED) since if
!sev->snp_plat_status.feature_info is true, so is this this check. And, as
the spec says, the required firmware state is based on the mitigation
requirements, so I don't think you should be checking for snp_initialized.
Thanks,
Tom
>
> So, I attempt address that with a sev_mit_sysfs_mutex guard.
>
> --Pratik
^ permalink raw reply
* Re: [PATCH 1/2] dt-bindings: crypto: qcom,prng: Document Hawi TRNG
From: Konrad Dybcio @ 2026-05-21 12:55 UTC (permalink / raw)
To: Manivannan Sadhasivam, Herbert Xu, David S. Miller, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Vinod Koul, Bjorn Andersson
Cc: linux-arm-msm, linux-crypto, devicetree, linux-kernel,
Manivannan Sadhasivam
In-Reply-To: <20260521-hawi-crypto-v1-1-9176a3b51bc0@kernel.org>
On 5/21/26 2:36 PM, Manivannan Sadhasivam wrote:
> From: Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com>
>
> Hawi SoC has the True Random Number Generator (TRNG) which is compatible
> with the baseline IP "qcom,trng". Hence, document the compatible as such.
>
> Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com>
> ---
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Konrad
^ permalink raw reply
* [PATCH 1/2] dt-bindings: crypto: qcom,prng: Document Hawi TRNG
From: Manivannan Sadhasivam @ 2026-05-21 12:36 UTC (permalink / raw)
To: Herbert Xu, David S. Miller, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Vinod Koul, Bjorn Andersson
Cc: linux-arm-msm, linux-crypto, devicetree, linux-kernel, mani,
Manivannan Sadhasivam
In-Reply-To: <20260521-hawi-crypto-v1-0-9176a3b51bc0@kernel.org>
From: Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com>
Hawi SoC has the True Random Number Generator (TRNG) which is compatible
with the baseline IP "qcom,trng". Hence, document the compatible as such.
Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@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 41402599e9ab..e5489941e769 100644
--- a/Documentation/devicetree/bindings/crypto/qcom,prng.yaml
+++ b/Documentation/devicetree/bindings/crypto/qcom,prng.yaml
@@ -17,6 +17,7 @@ properties:
- qcom,prng-ee # 8996 and later using EE
- items:
- enum:
+ - qcom,hawi-trng
- qcom,ipq5332-trng
- qcom,ipq5424-trng
- qcom,ipq9574-trng
--
2.43.0
^ permalink raw reply related
* [PATCH 0/2] dt-bindings: crypto: Add Qualcomm Hawi crypto support
From: Manivannan Sadhasivam @ 2026-05-21 12:36 UTC (permalink / raw)
To: Herbert Xu, David S. Miller, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Vinod Koul, Bjorn Andersson
Cc: linux-arm-msm, linux-crypto, devicetree, linux-kernel, mani,
Manivannan Sadhasivam
Hi,
This series adds the crypto (ICE, TRNG) dt-binding support for Qualcomm's
upcoming Hawi SoC.
Signed-off-by: Manivannan Sadhasivam <mani@kernel.org>
---
Manivannan Sadhasivam (2):
dt-bindings: crypto: qcom,prng: Document Hawi TRNG
dt-bindings: crypto: qcom,inline-crypto-engine: Document Hawi ICE
Documentation/devicetree/bindings/crypto/qcom,inline-crypto-engine.yaml | 1 +
Documentation/devicetree/bindings/crypto/qcom,prng.yaml | 1 +
2 files changed, 2 insertions(+)
---
base-commit: 254f49634ee16a731174d2ae34bc50bd5f45e731
change-id: 20260521-hawi-crypto-138bfd2a6ec5
Best regards,
--
Manivannan Sadhasivam <mani@kernel.org>
^ permalink raw reply
* [PATCH 2/2] dt-bindings: crypto: qcom,inline-crypto-engine: Document Hawi ICE
From: Manivannan Sadhasivam @ 2026-05-21 12:36 UTC (permalink / raw)
To: Herbert Xu, David S. Miller, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Vinod Koul, Bjorn Andersson
Cc: linux-arm-msm, linux-crypto, devicetree, linux-kernel, mani,
Manivannan Sadhasivam
In-Reply-To: <20260521-hawi-crypto-v1-0-9176a3b51bc0@kernel.org>
From: Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com>
The Inline Crypto Engine found in Hawi SoC is compatible with the common
baseline IP 'qcom,inline-crypto-engine'. Hence, document the compatible as
such.
Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com>
---
Documentation/devicetree/bindings/crypto/qcom,inline-crypto-engine.yaml | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation/devicetree/bindings/crypto/qcom,inline-crypto-engine.yaml b/Documentation/devicetree/bindings/crypto/qcom,inline-crypto-engine.yaml
index 876bf90ed96e..2a183b07b03a 100644
--- a/Documentation/devicetree/bindings/crypto/qcom,inline-crypto-engine.yaml
+++ b/Documentation/devicetree/bindings/crypto/qcom,inline-crypto-engine.yaml
@@ -14,6 +14,7 @@ properties:
items:
- enum:
- qcom,eliza-inline-crypto-engine
+ - qcom,hawi-inline-crypto-engine
- qcom,kaanapali-inline-crypto-engine
- qcom,milos-inline-crypto-engine
- qcom,qcs8300-inline-crypto-engine
--
2.43.0
^ permalink raw reply related
* Re: [PATCH] crypto: talitos - fix rename first/last to first_desc/last_desc
From: Paul Louvel @ 2026-05-21 10:20 UTC (permalink / raw)
To: Paul Louvel, Goetz Goerisch
Cc: herve.codina, miquel.raynal, stable, thomas.petazzoni, Herbert Xu,
linux-crypto, Greg Kroah-Hartman, Sasha Levin
In-Reply-To: <DIO9YUHO5VGT.3BLGH04NVJNHP@bootlin.com>
On Thu May 21, 2026 at 12:16 PM CEST, Paul Louvel wrote:
> On Wed May 20, 2026 at 6:58 PM CEST, Goetz Goerisch wrote:
>> Hi,
>>
>> Commit a1b80018b8cec27fc06a8b04a7f8b5f6cfe86eae
>> was backported to 6.6.y with a866e2b1c65edaee2e1bb1024ee2c761ced335f8
>> It renames last to last_desc but misses one occurrence which leads to compile errors on mpc85xx
>
> Hi Goetz,
>
> Thank you for the patch. I did not catch that since I worked on a mainline tree,
> and that specific line was removed in 9826d1d6ed5f ("crypto: talitos - stop
> using crypto_ahash::init"), which was not backported into the stable tree.
>
>> drivers/crypto/talitos.c: In function 'ahash_digest':
>> drivers/crypto/talitos.c:2204:16: error: 'struct talitos_ahash_req_ctx' has no member named 'last'
>> 2204 | req_ctx->last = 1;
>> | ^~4
>>
>> Fixes: a866e2b1c65e ("crypto: talitos - rename first/last to first_desc/last_desc")
>> Signed-off-by: Goetz Goerisch <ggoerisch@gmail.com>
>> ---
>> drivers/crypto/talitos.c | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/drivers/crypto/talitos.c b/drivers/crypto/talitos.c
>> index 347483f6fc5d..ed160c591346 100644
>> --- a/drivers/crypto/talitos.c
>> +++ b/drivers/crypto/talitos.c
>> @@ -2201,7 +2201,7 @@ static int ahash_digest(struct ahash_request *areq)
>> struct crypto_ahash *ahash = crypto_ahash_reqtfm(areq);
>>
>> ahash->init(areq);
>> - req_ctx->last = 1;
>> + req_ctx->last_desc = 1;
>
> Instead of renaming req_ctx->last, commit 9826d1d6ed5f8 ("crypto: talitos - stop
> using crypto_ahash::init") should be applied. Ideally before commit
> 655ef638a2bc ("crypto: talitos - fix SEC1 32k ahash request limitation") to
> avoid any compilation breakage and ensure correctness of the code.
Small correction:
Ideally before commit 00463d5f864a ("crypto: talitos - fix SEC1 32k ahash
request limitation") to avoid any compilation breakage and ensure correctness of
the code.
>
>>
>> return ahash_process_req(areq, areq->nbytes);
>> }
>
> Paul.
--
Paul Louvel, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
^ permalink raw reply
* Re: [PATCH v3 11/12] crypto: atmel-sha204a - fix heap info leak on I2C transfer failure
From: Krzysztof Kozlowski @ 2026-05-21 10:17 UTC (permalink / raw)
To: Lothar Rubusch, thorsten.blum, herbert, davem, nicolas.ferre,
alexandre.belloni, claudiu.beznea, tudor.ambarus, ardb, linusw
Cc: linux-crypto, linux-arm-kernel, linux-kernel
In-Reply-To: <20260520155703.23018-12-l.rubusch@gmail.com>
On 20/05/2026 17:57, Lothar Rubusch wrote:
> When a non-blocking read operation is requested, the driver dynamically
> allocates memory to track asynchronous transfer status. If the underlying
> I2C transmission fails, atmel_sha204a_rng_done() logs a rate-limited
> warning but incorrectly proceeds to cache the pointer to this uninitialized
> buffer inside the rng->priv data field anyway.
>
> On subsequent execution passes, atmel_sha204a_rng_read_nonblocking()
> detects the stale rng->priv value, skips executing a hardware data read,
> and copies up to 32 bytes of uninitialized kernel heap data from this
> garbage memory pool straight back into the system's hwrng data stream.
>
> Fix this information disclosure vector by immediately releasing the
> allocated asynchronous work data buffer and explicitly clearing the
> tracking pointer context whenever an I2C transaction returns a non-zero
> error status.
>
> Additionally, duplicate the tfm counter decrement within the new error
> path to ensure the reference counter is properly released before executing
> the early return, maintaining the driver's availability for subsequent
> requests.
>
> Fixes: da001fb651b0 ("crypto: atmel-i2c - add support for SHA204A random number generator")
This and other fixes should be first in the patchset. Or even separate
patchset.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v3 02/12] crypto: atmel-ecc - fix use after free situation
From: Krzysztof Kozlowski @ 2026-05-21 10:16 UTC (permalink / raw)
To: Lothar Rubusch, thorsten.blum, herbert, davem, nicolas.ferre,
alexandre.belloni, claudiu.beznea, tudor.ambarus, ardb, linusw
Cc: linux-crypto, linux-arm-kernel, linux-kernel
In-Reply-To: <20260520155703.23018-3-l.rubusch@gmail.com>
On 20/05/2026 17:56, Lothar Rubusch wrote:
> Fixes the very likely race condition, having multiple of such devices
> attached (identified by sashiko feedback).
>
> The Scenario:
> Thread A (Device 1 Probe): Successfully adds i2c_priv to the global
> list (Line 324). The lock is released.
> Thread B (An active crypto request): Concurrently calls
> atmel_ecc_i2c_client_alloc(). It scans the global list, sees
> Device 1, and assigns a crypto job to it.
> Thread A: Moves to line 332. crypto_register_kpp() fails (e.g., out of
> memory or name clash).
> Thread A: Enters the error path. It removes Device 1 from the list and
> frees the i2c_priv memory.
> Thread B: Is still actively trying to talk to the I2C hardware using
> the i2c_priv pointer it grabbed in Step 2. The memory is now
> gone. Result: Kernel crash (Use-After-Free).
>
> Fixes: 11105693fa05 ("crypto: atmel-ecc - introduce Microchip / Atmel ECC driver")
Please add Cc-stable
> Signed-off-by: Lothar Rubusch <l.rubusch@gmail.com>
> ---
And fixes must be before any code refactorings, so your rename patch
should be after.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH] crypto: talitos - fix rename first/last to first_desc/last_desc
From: Paul Louvel @ 2026-05-21 10:16 UTC (permalink / raw)
To: Goetz Goerisch, paul.louvel
Cc: herve.codina, miquel.raynal, stable, thomas.petazzoni, Herbert Xu,
linux-crypto, Greg Kroah-Hartman, Sasha Levin
In-Reply-To: <142603430.61540.1779296295550@app.mailbox.org>
On Wed May 20, 2026 at 6:58 PM CEST, Goetz Goerisch wrote:
> Hi,
>
> Commit a1b80018b8cec27fc06a8b04a7f8b5f6cfe86eae
> was backported to 6.6.y with a866e2b1c65edaee2e1bb1024ee2c761ced335f8
> It renames last to last_desc but misses one occurrence which leads to compile errors on mpc85xx
Hi Goetz,
Thank you for the patch. I did not catch that since I worked on a mainline tree,
and that specific line was removed in 9826d1d6ed5f ("crypto: talitos - stop
using crypto_ahash::init"), which was not backported into the stable tree.
> drivers/crypto/talitos.c: In function 'ahash_digest':
> drivers/crypto/talitos.c:2204:16: error: 'struct talitos_ahash_req_ctx' has no member named 'last'
> 2204 | req_ctx->last = 1;
> | ^~4
>
> Fixes: a866e2b1c65e ("crypto: talitos - rename first/last to first_desc/last_desc")
> Signed-off-by: Goetz Goerisch <ggoerisch@gmail.com>
> ---
> drivers/crypto/talitos.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/crypto/talitos.c b/drivers/crypto/talitos.c
> index 347483f6fc5d..ed160c591346 100644
> --- a/drivers/crypto/talitos.c
> +++ b/drivers/crypto/talitos.c
> @@ -2201,7 +2201,7 @@ static int ahash_digest(struct ahash_request *areq)
> struct crypto_ahash *ahash = crypto_ahash_reqtfm(areq);
>
> ahash->init(areq);
> - req_ctx->last = 1;
> + req_ctx->last_desc = 1;
Instead of renaming req_ctx->last, commit 9826d1d6ed5f8 ("crypto: talitos - stop
using crypto_ahash::init") should be applied. Ideally before commit
655ef638a2bc ("crypto: talitos - fix SEC1 32k ahash request limitation") to
avoid any compilation breakage and ensure correctness of the code.
>
> return ahash_process_req(areq, areq->nbytes);
> }
Paul.
--
Paul Louvel, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
^ permalink raw reply
* Re: [PATCH 3/3] arm64: dts: qcom: shikra: Add qcrypto node support
From: Kuldeep Singh @ 2026-05-21 8:45 UTC (permalink / raw)
To: Konrad Dybcio, Thara Gopinath, Herbert Xu, David S. Miller,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Bjorn Andersson,
Konrad Dybcio, Vinod Koul, Frank Li, Andy Gross
Cc: linux-arm-msm, linux-crypto, devicetree, linux-kernel, dmaengine
In-Reply-To: <8dfa0670-7605-497b-9d53-db9b4a8a3d8d@oss.qualcomm.com>
On 15-05-2026 15:58, Konrad Dybcio wrote:
> On 5/14/26 9:23 PM, Kuldeep Singh wrote:
>> Add qcrypto and cryptobam support for shikra target.
>>
>> Signed-off-by: Kuldeep Singh <kuldeep.singh@oss.qualcomm.com>
>> ---
>> arch/arm64/boot/dts/qcom/shikra.dtsi | 35 +++++++++++++++++++++++++++++++++++
>> 1 file changed, 35 insertions(+)
>>
>> diff --git a/arch/arm64/boot/dts/qcom/shikra.dtsi b/arch/arm64/boot/dts/qcom/shikra.dtsi
>> index 262c488add1e..dbac0e901d6e 100644
>> --- a/arch/arm64/boot/dts/qcom/shikra.dtsi
>> +++ b/arch/arm64/boot/dts/qcom/shikra.dtsi
>> @@ -541,6 +541,41 @@ config_noc: interconnect@1900000 {
>> #interconnect-cells = <2>;
>> };
>>
>> + cryptobam: dma-controller@1b04000 {
>> + compatible = "qcom,bam-v1.7.4", "qcom,bam-v1.7.0";
>> + reg = <0x0 0x01b04000 0x0 0x24000>;
>> + interrupts = <GIC_SPI 247 IRQ_TYPE_LEVEL_HIGH>;
>> + #dma-cells = <1>;
>> + iommus = <&apps_smmu 0x84 0x0011>,
>> + <&apps_smmu 0x86 0x0011>,
>> + <&apps_smmu 0x92 0x0>,
>
>> + <&apps_smmu 0x94 0x0011>,
>> + <&apps_smmu 0x96 0x0011>,
>
> These two entries are logically the same (SID & ~mask) as the first two,
> does it still work if you remove them?
Yes, resulting sid is same for 84/94 and 86/92.
Basically, the resulting sid could be same, it's an optimization which
smmu is doing which can result in same SMR(Stream matching register)
routing 2 different sid to same context bank.
So, 2 sid can be used even though resulting sid remains same.
Also, DT usually dictates what hw capabilities are supported and hence,
captured all apps entries here to match the hardware description.
I hope this answers your query.
>
>
>> + <&apps_smmu 0x98 0x0001>,
>> + <&apps_smmu 0x9F 0x0>;
>
> Let's keep lowercase hex
Sure, will update in next rev.
Please note, I'll be clubbing patches together in one series as
suggested by krzysztof and fix this too that time.
--
Regards
Kuldeep
^ permalink raw reply
* [linus:master] [rhashtable] 4fe9852927: stress-ng.msg.ops_per_sec 29.1% regression
From: kernel test robot @ 2026-05-21 8:09 UTC (permalink / raw)
To: Tejun Heo
Cc: oe-lkp, lkp, linux-kernel, Herbert Xu, linux-crypto, oliver.sang
Hello,
kernel test robot noticed a 29.1% regression of stress-ng.msg.ops_per_sec on:
commit: 4fe985292709eeb6a4653c71660f893e26c2f2dd ("rhashtable: Bounce deferred worker kick through irq_work")
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git master
[still regression on linus/master d458a240344c4369bf6f3da203f2779515177738]
[still regression on linux-next/master e98d21c170b01ddef366f023bbfcf6b31509fa83]
testcase: stress-ng
config: x86_64-rhel-9.4
compiler: gcc-14
test machine: 256 threads 4 sockets INTEL(R) XEON(R) PLATINUM 8592+ (Emerald Rapids) with 256G memory
parameters:
nr_threads: 100%
testtime: 60s
test: msg
cpufreq_governor: performance
If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot <oliver.sang@intel.com>
| Closes: https://lore.kernel.org/oe-lkp/202605211540.d9ef9555-lkp@intel.com
Details are as below:
-------------------------------------------------------------------------------------------------->
The kernel config and materials to reproduce are available at:
https://download.01.org/0day-ci/archive/20260521/202605211540.d9ef9555-lkp@intel.com
=========================================================================================
compiler/cpufreq_governor/kconfig/nr_threads/rootfs/tbox_group/test/testcase/testtime:
gcc-14/performance/x86_64-rhel-9.4/100%/debian-13-x86_64-20250902.cgz/lkp-emr-2sp1/msg/stress-ng/60s
commit:
5897ca15d2 ("selftests/sched_ext: Add non_scx_kfunc_deny test")
4fe9852927 ("rhashtable: Bounce deferred worker kick through irq_work")
5897ca15d2c444af 4fe985292709eeb6a4653c71660
---------------- ---------------------------
%stddev %change %stddev
\ | \
1.152e+09 -29.1% 8.168e+08 stress-ng.msg.ops
19204952 -29.1% 13619234 stress-ng.msg.ops_per_sec
14063 -11.6% 12434 ± 2% stress-ng.time.involuntary_context_switches
2876 -12.9% 2506 stress-ng.time.percent_of_cpu_this_job_got
1536 -10.3% 1378 stress-ng.time.system_time
192.04 -33.3% 128.15 stress-ng.time.user_time
5338409 ± 4% +9.7% 5858239 ± 3% cpuidle..usage
208311 ± 3% -15.9% 175134 ± 3% numa-meminfo.node3.Shmem
52091 ± 3% -15.9% 43797 ± 3% numa-vmstat.node3.nr_shmem
94334 ± 11% -31.0% 65055 ± 14% perf-c2c.HITM.remote
147112 ± 2% -14.6% 125569 ± 2% vmstat.system.in
9.74 -1.1 8.69 mpstat.cpu.all.sys%
1.39 -0.4 0.98 mpstat.cpu.all.usr%
53.91 -26.7% 39.53 mpstat.max_utilization_pct
986061 -5.1% 936129 meminfo.Active
986045 -5.1% 936112 meminfo.Active(anon)
128200 -7.7% 118344 meminfo.Mapped
276789 ± 2% -17.8% 227423 meminfo.Shmem
22.07 ± 3% +15.6% 25.50 perf-sched.total_wait_and_delay.average.ms
220780 ± 3% -13.1% 191816 perf-sched.total_wait_and_delay.count.ms
21.90 ± 3% +15.6% 25.31 perf-sched.total_wait_time.average.ms
22.07 ± 3% +15.6% 25.50 perf-sched.wait_and_delay.avg.ms.[unknown].[unknown].[unknown].[unknown].[unknown]
220780 ± 3% -13.1% 191816 perf-sched.wait_and_delay.count.[unknown].[unknown].[unknown].[unknown].[unknown]
21.90 ± 3% +15.6% 25.31 perf-sched.wait_time.avg.ms.[unknown].[unknown].[unknown].[unknown].[unknown]
3343 ± 3% -9.8% 3015 sched_debug.cfs_rq:/.avg_vruntime.min
2.67 ± 23% +137.5% 6.33 ± 14% sched_debug.cfs_rq:/.load_avg.min
2.67 ± 23% +140.6% 6.42 ± 15% sched_debug.cfs_rq:/.runnable_avg.min
2.67 ± 23% +140.6% 6.42 ± 15% sched_debug.cfs_rq:/.util_avg.min
3343 ± 3% -9.8% 3015 sched_debug.cfs_rq:/.zero_vruntime.min
157311 ± 10% -14.5% 134477 ± 6% sched_debug.cpu.avg_idle.stddev
137.50 ± 7% +18.9% 163.50 ± 13% sched_debug.cpu.nr_uninterruptible.max
246513 -5.1% 234040 proc-vmstat.nr_active_anon
1018888 -1.2% 1006555 proc-vmstat.nr_file_pages
32061 -7.7% 29594 proc-vmstat.nr_mapped
69201 ± 2% -17.8% 56871 proc-vmstat.nr_shmem
246513 -5.1% 234040 proc-vmstat.nr_zone_active_anon
1253740 -5.8% 1180805 proc-vmstat.numa_hit
857018 -8.6% 783537 proc-vmstat.numa_local
1345499 -5.2% 1275814 proc-vmstat.pgalloc_normal
397.00 -16.9% 330.00 turbostat.Avg_MHz
11.56 -1.3 10.25 turbostat.Busy%
3431 -6.1% 3221 turbostat.Bzy_MHz
0.18 ± 42% -0.1 0.05 turbostat.C1%
3.09 +0.6 3.65 turbostat.C1E%
2.85 ± 6% +15.3% 3.29 turbostat.CPU%c1
0.56 -11.7% 0.49 turbostat.IPC
9050091 ± 2% -16.4% 7567003 turbostat.IRQ
2892774 ± 2% -22.7% 2235774 turbostat.NMI
0.34 ± 12% +314.9% 1.39 ± 2% turbostat.Pkg%pc2
413.45 -6.0% 388.84 turbostat.PkgWatt
18.81 -3.9% 18.08 turbostat.RAMWatt
4.10 +9.3% 4.48 perf-stat.i.MPKI
1.092e+10 -26.1% 8.07e+09 perf-stat.i.branch-instructions
0.59 ± 2% +0.2 0.75 perf-stat.i.branch-miss-rate%
64835624 -6.6% 60546789 perf-stat.i.branch-misses
44.45 -3.2 41.27 perf-stat.i.cache-miss-rate%
2.394e+08 -20.0% 1.916e+08 perf-stat.i.cache-misses
5.409e+08 -13.9% 4.657e+08 perf-stat.i.cache-references
1.61 +14.5% 1.84 perf-stat.i.cpi
9.683e+10 -16.0% 8.132e+10 perf-stat.i.cpu-cycles
12795 +13.0% 14464 perf-stat.i.cpu-migrations
396.20 +5.0% 415.99 perf-stat.i.cycles-between-cache-misses
5.885e+10 -26.6% 4.32e+10 perf-stat.i.instructions
0.63 -12.6% 0.55 perf-stat.i.ipc
4.04 +8.8% 4.40 perf-stat.overall.MPKI
0.58 ± 2% +0.1 0.73 perf-stat.overall.branch-miss-rate%
44.02 -3.0 41.00 perf-stat.overall.cache-miss-rate%
1.70 +13.6% 1.93 perf-stat.overall.cpi
420.78 +4.4% 439.25 perf-stat.overall.cycles-between-cache-misses
0.59 -12.0% 0.52 perf-stat.overall.ipc
1.094e+10 -26.2% 8.07e+09 perf-stat.ps.branch-instructions
63709128 -7.4% 59001476 perf-stat.ps.branch-misses
2.377e+08 -20.2% 1.898e+08 perf-stat.ps.cache-misses
5.4e+08 -14.3% 4.629e+08 perf-stat.ps.cache-references
1e+11 -16.6% 8.337e+10 perf-stat.ps.cpu-cycles
15166 +2.4% 15525 perf-stat.ps.cpu-migrations
5.881e+10 -26.6% 4.314e+10 perf-stat.ps.instructions
3.592e+12 -27.0% 2.621e+12 perf-stat.total.instructions
32.87 ± 33% -11.6 21.22 ± 3% perf-profile.calltrace.cycles-pp.entry_SYSCALL_64_after_hwframe
32.52 ± 33% -11.5 21.00 ± 3% perf-profile.calltrace.cycles-pp.do_syscall_64.entry_SYSCALL_64_after_hwframe
25.53 ± 2% -6.7 18.80 ± 4% perf-profile.calltrace.cycles-pp.do_msgrcv.do_syscall_64.entry_SYSCALL_64_after_hwframe
6.40 -2.4 3.97 perf-profile.calltrace.cycles-pp.__kmalloc_node_noprof.load_msg.do_msgsnd.do_syscall_64.entry_SYSCALL_64_after_hwframe
4.33 ± 8% -2.4 1.90 perf-profile.calltrace.cycles-pp.native_queued_spin_lock_slowpath._raw_spin_lock.do_msgrcv.do_syscall_64.entry_SYSCALL_64_after_hwframe
4.80 -2.3 2.46 perf-profile.calltrace.cycles-pp.native_queued_spin_lock_slowpath._raw_spin_lock.do_msgsnd.do_syscall_64.entry_SYSCALL_64_after_hwframe
3.88 ± 7% -2.3 1.61 ± 4% perf-profile.calltrace.cycles-pp._raw_spin_lock.do_msgrcv.do_syscall_64.entry_SYSCALL_64_after_hwframe
6.96 ± 5% -2.2 4.78 perf-profile.calltrace.cycles-pp.kfree.free_msg.do_msgrcv.do_syscall_64.entry_SYSCALL_64_after_hwframe
5.60 ± 7% -2.2 3.43 ± 4% perf-profile.calltrace.cycles-pp.free_msg.do_msgrcv.do_syscall_64.entry_SYSCALL_64_after_hwframe
4.86 ± 20% -2.0 2.89 ± 4% perf-profile.calltrace.cycles-pp.store_msg.do_msgrcv.do_syscall_64.entry_SYSCALL_64_after_hwframe
4.53 ± 32% -1.6 2.98 perf-profile.calltrace.cycles-pp._copy_to_user.store_msg.do_msgrcv.do_syscall_64.entry_SYSCALL_64_after_hwframe
3.25 ± 4% -1.5 1.74 ± 4% perf-profile.calltrace.cycles-pp.stress_msg_receiver
2.53 ± 2% -1.4 1.10 ± 3% perf-profile.calltrace.cycles-pp.percpu_counter_add_batch.do_msgrcv.do_syscall_64.entry_SYSCALL_64_after_hwframe
2.73 ± 2% -1.4 1.37 perf-profile.calltrace.cycles-pp.__pcs_replace_empty_main.__kmalloc_node_noprof.load_msg.do_msgsnd.do_syscall_64
2.50 ± 2% -1.3 1.17 ± 2% perf-profile.calltrace.cycles-pp.refill_objects.__pcs_replace_empty_main.__kmalloc_node_noprof.load_msg.do_msgsnd
2.29 ± 2% -1.2 1.04 ± 2% perf-profile.calltrace.cycles-pp.__refill_objects_node.refill_objects.__pcs_replace_empty_main.__kmalloc_node_noprof.load_msg
4.07 ± 2% -1.1 2.99 perf-profile.calltrace.cycles-pp.__memcg_slab_free_hook.kfree.free_msg.do_msgrcv.do_syscall_64
1.75 ± 74% -0.8 0.92 perf-profile.calltrace.cycles-pp._copy_from_user.load_msg.do_msgsnd.do_syscall_64.entry_SYSCALL_64_after_hwframe
2.35 ± 3% -0.7 1.64 perf-profile.calltrace.cycles-pp.__memcg_slab_post_alloc_hook.__kmalloc_node_noprof.load_msg.do_msgsnd.do_syscall_64
1.41 ± 8% -0.5 0.94 ± 5% perf-profile.calltrace.cycles-pp._raw_spin_lock.do_msgrcv.do_syscall_64.entry_SYSCALL_64_after_hwframe.stress_msg
0.93 ± 9% -0.3 0.64 ± 6% perf-profile.calltrace.cycles-pp.percpu_counter_add_batch.do_msgrcv.do_syscall_64.entry_SYSCALL_64_after_hwframe.stress_msg
1.18 ± 6% -0.2 1.03 ± 6% perf-profile.calltrace.cycles-pp.stress_msg_receiver.stress_msg
0.79 ± 13% +0.3 1.13 perf-profile.calltrace.cycles-pp.down_read.sysvipc_proc_start.seq_read_iter.seq_read.vfs_read
0.83 ± 13% +0.4 1.19 perf-profile.calltrace.cycles-pp.sysvipc_proc_start.seq_read_iter.seq_read.vfs_read.ksys_read
0.77 ± 13% +0.4 1.13 perf-profile.calltrace.cycles-pp.rwsem_down_read_slowpath.down_read.sysvipc_proc_start.seq_read_iter.seq_read
0.95 +0.4 1.33 perf-profile.calltrace.cycles-pp.intel_idle_xstate.cpuidle_enter_state.cpuidle_enter.cpuidle_idle_call.do_idle
0.54 ± 44% +0.4 0.93 perf-profile.calltrace.cycles-pp.native_queued_spin_lock_slowpath._raw_spin_lock_irq.rwsem_down_read_slowpath.down_read.sysvipc_proc_start
0.55 ± 44% +0.4 0.95 perf-profile.calltrace.cycles-pp._raw_spin_lock_irq.rwsem_down_read_slowpath.down_read.sysvipc_proc_start.seq_read_iter
0.25 ±100% +0.4 0.69 perf-profile.calltrace.cycles-pp.flush_smp_call_function_queue.do_idle.cpu_startup_entry.start_secondary.common_startup_64
1.24 ± 2% +0.5 1.71 perf-profile.calltrace.cycles-pp.cpuidle_enter_state.cpuidle_enter.cpuidle_idle_call.do_idle.cpu_startup_entry
1.26 ± 2% +0.5 1.75 perf-profile.calltrace.cycles-pp.cpuidle_enter.cpuidle_idle_call.do_idle.cpu_startup_entry.start_secondary
0.00 +0.5 0.54 perf-profile.calltrace.cycles-pp.cpu_startup_entry.rest_init.start_kernel.x86_64_start_reservations.x86_64_start_kernel
0.00 +0.5 0.54 perf-profile.calltrace.cycles-pp.do_idle.cpu_startup_entry.rest_init.start_kernel.x86_64_start_reservations
0.00 +0.5 0.54 perf-profile.calltrace.cycles-pp.rest_init.start_kernel.x86_64_start_reservations.x86_64_start_kernel.common_startup_64
0.00 +0.5 0.54 perf-profile.calltrace.cycles-pp.start_kernel.x86_64_start_reservations.x86_64_start_kernel.common_startup_64
0.00 +0.5 0.54 perf-profile.calltrace.cycles-pp.x86_64_start_kernel.common_startup_64
0.00 +0.5 0.54 perf-profile.calltrace.cycles-pp.x86_64_start_reservations.x86_64_start_kernel.common_startup_64
0.00 +0.5 0.55 perf-profile.calltrace.cycles-pp.__schedule.schedule_idle.do_idle.cpu_startup_entry.start_secondary
0.00 +0.6 0.56 perf-profile.calltrace.cycles-pp.schedule_idle.do_idle.cpu_startup_entry.start_secondary.common_startup_64
0.00 +0.6 0.57 perf-profile.calltrace.cycles-pp.__flush_smp_call_function_queue.flush_smp_call_function_queue.do_idle.cpu_startup_entry.start_secondary
0.00 +0.6 0.64 perf-profile.calltrace.cycles-pp.sysvipc_proc_next.seq_read_iter.seq_read.vfs_read.ksys_read
1.96 ± 12% +0.6 2.60 perf-profile.calltrace.cycles-pp.seq_read.vfs_read.ksys_read.do_syscall_64.entry_SYSCALL_64_after_hwframe
1.96 ± 12% +0.6 2.60 perf-profile.calltrace.cycles-pp.seq_read_iter.seq_read.vfs_read.ksys_read.do_syscall_64
1.95 +0.8 2.73 perf-profile.calltrace.cycles-pp.cpuidle_idle_call.do_idle.cpu_startup_entry.start_secondary.common_startup_64
1.75 ± 44% +0.9 2.62 perf-profile.calltrace.cycles-pp.ksys_read.do_syscall_64.entry_SYSCALL_64_after_hwframe.stress_msg
1.74 ± 44% +0.9 2.61 perf-profile.calltrace.cycles-pp.vfs_read.ksys_read.do_syscall_64.entry_SYSCALL_64_after_hwframe.stress_msg
0.72 ± 9% +0.9 1.61 perf-profile.calltrace.cycles-pp.msgctl_down.ksys_msgctl.do_syscall_64.entry_SYSCALL_64_after_hwframe.msgctl
0.00 +0.9 0.94 perf-profile.calltrace.cycles-pp.rwsem_down_write_slowpath.down_write.msgctl_down.ksys_msgctl.do_syscall_64
0.00 +1.0 0.98 perf-profile.calltrace.cycles-pp.down_write.msgctl_down.ksys_msgctl.do_syscall_64.entry_SYSCALL_64_after_hwframe
0.00 +1.1 1.11 perf-profile.calltrace.cycles-pp.native_queued_spin_lock_slowpath._raw_spin_lock_irq.rwsem_down_read_slowpath.down_read.ksys_msgctl
0.00 +1.3 1.25 perf-profile.calltrace.cycles-pp._raw_spin_lock_irq.rwsem_down_read_slowpath.down_read.ksys_msgctl.do_syscall_64
3.25 +1.3 4.56 perf-profile.calltrace.cycles-pp.do_idle.cpu_startup_entry.start_secondary.common_startup_64
3.25 +1.3 4.57 perf-profile.calltrace.cycles-pp.cpu_startup_entry.start_secondary.common_startup_64
3.25 +1.3 4.57 perf-profile.calltrace.cycles-pp.start_secondary.common_startup_64
3.70 +1.4 5.12 perf-profile.calltrace.cycles-pp.common_startup_64
9.28 ± 6% +1.8 11.06 ± 6% perf-profile.calltrace.cycles-pp.do_msgrcv.do_syscall_64.entry_SYSCALL_64_after_hwframe.stress_msg
0.00 +1.9 1.86 perf-profile.calltrace.cycles-pp.rwsem_down_read_slowpath.down_read.ksys_msgctl.do_syscall_64.entry_SYSCALL_64_after_hwframe
0.00 +1.9 1.89 perf-profile.calltrace.cycles-pp.down_read.ksys_msgctl.do_syscall_64.entry_SYSCALL_64_after_hwframe.msgctl
1.40 ± 5% +2.5 3.90 ± 6% perf-profile.calltrace.cycles-pp.ipc_obtain_object_check.do_msgrcv.do_syscall_64.entry_SYSCALL_64_after_hwframe.stress_msg
3.85 ± 2% +2.8 6.64 ± 3% perf-profile.calltrace.cycles-pp.ipc_obtain_object_check.do_msgrcv.do_syscall_64.entry_SYSCALL_64_after_hwframe
4.24 ± 32% +5.0 9.22 perf-profile.calltrace.cycles-pp.ipc_obtain_object_check.do_msgsnd.do_syscall_64.entry_SYSCALL_64_after_hwframe.stress_msg
0.00 +6.2 6.17 perf-profile.calltrace.cycles-pp.idr_find.ipc_obtain_object_check.do_msgsnd.do_syscall_64.entry_SYSCALL_64_after_hwframe
0.00 +7.2 7.16 perf-profile.calltrace.cycles-pp.idr_find.ipc_obtain_object_check.do_msgrcv.do_syscall_64.entry_SYSCALL_64_after_hwframe
6.85 ± 6% +10.8 17.67 perf-profile.calltrace.cycles-pp.__percpu_counter_sum.ksys_msgctl.do_syscall_64.entry_SYSCALL_64_after_hwframe.msgctl
5.17 ± 7% +11.0 16.20 perf-profile.calltrace.cycles-pp._raw_spin_lock_irqsave.__percpu_counter_sum.ksys_msgctl.do_syscall_64.entry_SYSCALL_64_after_hwframe
4.98 ± 8% +11.0 16.02 perf-profile.calltrace.cycles-pp.native_queued_spin_lock_slowpath._raw_spin_lock_irqsave.__percpu_counter_sum.ksys_msgctl.do_syscall_64
57.21 ± 26% +13.1 70.26 perf-profile.calltrace.cycles-pp.stress_msg
7.58 ± 33% +13.7 21.27 perf-profile.calltrace.cycles-pp.ksys_msgctl.do_syscall_64.entry_SYSCALL_64_after_hwframe.msgctl.stress_msg
7.65 ± 33% +13.7 21.38 perf-profile.calltrace.cycles-pp.do_syscall_64.entry_SYSCALL_64_after_hwframe.msgctl.stress_msg
7.66 ± 33% +13.7 21.38 perf-profile.calltrace.cycles-pp.entry_SYSCALL_64_after_hwframe.msgctl.stress_msg
7.78 ± 33% +13.8 21.54 perf-profile.calltrace.cycles-pp.msgctl.stress_msg
33.29 ± 2% -6.4 26.92 perf-profile.children.cycles-pp.do_msgsnd
13.12 ± 4% -6.1 7.03 perf-profile.children.cycles-pp._raw_spin_lock
35.20 -5.0 30.19 perf-profile.children.cycles-pp.do_msgrcv
12.46 ± 10% -4.8 7.64 perf-profile.children.cycles-pp.load_msg
6.60 ± 2% -2.8 3.79 perf-profile.children.cycles-pp.percpu_counter_add_batch
6.62 -2.4 4.22 perf-profile.children.cycles-pp.__kmalloc_node_noprof
7.40 ± 6% -2.2 5.19 perf-profile.children.cycles-pp.kfree
7.70 ± 6% -2.2 5.52 perf-profile.children.cycles-pp.free_msg
6.70 ± 21% -2.0 4.66 perf-profile.children.cycles-pp.store_msg
4.48 ± 2% -1.7 2.81 perf-profile.children.cycles-pp.stress_msg_receiver
4.74 ± 30% -1.6 3.14 perf-profile.children.cycles-pp._copy_to_user
3.93 -1.5 2.46 perf-profile.children.cycles-pp.stress_msg_sender
2.81 ± 2% -1.4 1.45 perf-profile.children.cycles-pp.__pcs_replace_empty_main
2.56 ± 3% -1.3 1.24 ± 2% perf-profile.children.cycles-pp.refill_objects
2.52 ± 3% -1.3 1.22 ± 2% perf-profile.children.cycles-pp.__refill_objects_node
4.16 ± 2% -1.1 3.07 perf-profile.children.cycles-pp.__memcg_slab_free_hook
1.73 ± 12% -1.0 0.74 ± 3% perf-profile.children.cycles-pp.__slab_free
1.93 ± 72% -0.9 1.04 perf-profile.children.cycles-pp._copy_from_user
2.76 ± 2% -0.9 1.89 perf-profile.children.cycles-pp.__memcg_slab_post_alloc_hook
3.23 -0.7 2.54 perf-profile.children.cycles-pp.__check_object_size
1.84 -0.5 1.37 perf-profile.children.cycles-pp.check_heap_object
1.99 ± 2% -0.3 1.64 perf-profile.children.cycles-pp.entry_SYSRETQ_unsafe_stack
0.94 ± 2% -0.3 0.64 ± 2% perf-profile.children.cycles-pp.__account_obj_stock
1.05 ± 4% -0.2 0.86 perf-profile.children.cycles-pp.__x64_sys_msgsnd
0.96 ± 5% -0.2 0.78 perf-profile.children.cycles-pp.__get_user_8
1.06 ± 2% -0.2 0.90 perf-profile.children.cycles-pp.entry_SYSCALL_64
0.87 ± 3% -0.1 0.72 perf-profile.children.cycles-pp.sysvipc_msg_proc_show
0.88 -0.1 0.73 perf-profile.children.cycles-pp.__put_user_8
0.79 ± 3% -0.1 0.65 perf-profile.children.cycles-pp.seq_printf
0.78 -0.1 0.64 perf-profile.children.cycles-pp.entry_SYSCALL_64_safe_stack
0.78 ± 3% -0.1 0.64 perf-profile.children.cycles-pp.vsnprintf
0.37 ± 2% -0.1 0.24 perf-profile.children.cycles-pp.ss_wakeup
0.40 ± 3% -0.1 0.29 ± 2% perf-profile.children.cycles-pp.trylock_stock
0.63 -0.1 0.54 ± 2% perf-profile.children.cycles-pp.__check_heap_object
0.62 ± 3% -0.1 0.53 perf-profile.children.cycles-pp.ipcperms
0.65 -0.1 0.57 perf-profile.children.cycles-pp.prandom_u32_state
0.60 ± 2% -0.1 0.52 ± 2% perf-profile.children.cycles-pp.__virt_addr_valid
0.29 ± 4% -0.1 0.24 ± 2% perf-profile.children.cycles-pp.number
0.44 ± 2% -0.1 0.38 perf-profile.children.cycles-pp.syscall_return_via_sysret
0.29 -0.1 0.24 ± 2% perf-profile.children.cycles-pp.check_stack_object
0.34 ± 3% -0.1 0.29 perf-profile.children.cycles-pp._find_next_or_bit
0.18 ± 15% -0.1 0.12 ± 6% perf-profile.children.cycles-pp.__refill_objects_any
0.22 ± 3% -0.0 0.18 ± 3% perf-profile.children.cycles-pp.barn_replace_empty_sheaf
0.28 ± 3% -0.0 0.24 ± 2% perf-profile.children.cycles-pp.security_ipc_permission
0.23 ± 3% -0.0 0.20 ± 2% perf-profile.children.cycles-pp.format_decode
0.19 ± 5% -0.0 0.16 ± 4% perf-profile.children.cycles-pp.security_msg_msg_alloc
0.10 ± 6% -0.0 0.07 ± 8% perf-profile.children.cycles-pp.mod_memcg_lruvec_state
0.12 ± 3% -0.0 0.09 ± 5% perf-profile.children.cycles-pp.__libc_msgrcv
0.26 ± 2% -0.0 0.23 perf-profile.children.cycles-pp.__refill_obj_stock
0.28 ± 3% -0.0 0.26 ± 4% perf-profile.children.cycles-pp.x64_sys_call
0.17 ± 2% -0.0 0.15 perf-profile.children.cycles-pp.is_vmalloc_addr
0.19 ± 2% -0.0 0.16 ± 2% perf-profile.children.cycles-pp.security_msg_queue_msgrcv
0.22 ± 3% -0.0 0.20 perf-profile.children.cycles-pp._raw_spin_unlock
0.15 ± 2% -0.0 0.13 ± 4% perf-profile.children.cycles-pp.barn_replace_full_sheaf
0.14 ± 2% -0.0 0.12 ± 3% perf-profile.children.cycles-pp.security_msg_queue_msgsnd
0.08 ± 6% -0.0 0.06 perf-profile.children.cycles-pp.msgrcv@plt
0.08 ± 6% -0.0 0.06 ± 6% perf-profile.children.cycles-pp.wake_q_add
0.10 -0.0 0.09 ± 4% perf-profile.children.cycles-pp.ktime_get_real_seconds
0.07 -0.0 0.06 ± 6% perf-profile.children.cycles-pp.lsm_blob_alloc
0.05 +0.0 0.06 perf-profile.children.cycles-pp.update_other_load_avgs
0.06 ± 6% +0.0 0.08 ± 6% perf-profile.children.cycles-pp.__smp_call_single_queue
0.05 ± 7% +0.0 0.06 ± 7% perf-profile.children.cycles-pp.asm_sysvec_call_function_single
0.05 +0.0 0.07 ± 7% perf-profile.children.cycles-pp.select_task_rq_fair
0.07 +0.0 0.09 ± 8% perf-profile.children.cycles-pp.kick_ilb
0.08 ± 6% +0.0 0.09 ± 5% perf-profile.children.cycles-pp.ttwu_queue_wakelist
0.05 ± 7% +0.0 0.07 perf-profile.children.cycles-pp.update_se
0.04 ± 44% +0.0 0.06 ± 6% perf-profile.children.cycles-pp.ktime_get
0.06 ± 8% +0.0 0.08 ± 6% perf-profile.children.cycles-pp.update_cfs_rq_load_avg
0.05 +0.0 0.07 ± 5% perf-profile.children.cycles-pp.set_next_entity
0.04 ± 44% +0.0 0.06 ± 7% perf-profile.children.cycles-pp.clockevents_program_event
0.08 ± 4% +0.0 0.10 ± 3% perf-profile.children.cycles-pp.update_rq_clock_task
0.06 ± 9% +0.0 0.08 ± 4% perf-profile.children.cycles-pp.___perf_sw_event
0.06 ± 6% +0.0 0.08 ± 5% perf-profile.children.cycles-pp.kthread
0.06 ± 9% +0.0 0.08 perf-profile.children.cycles-pp.finish_task_switch
0.06 ± 6% +0.0 0.09 ± 5% perf-profile.children.cycles-pp.ret_from_fork
0.06 ± 6% +0.0 0.09 ± 5% perf-profile.children.cycles-pp.ret_from_fork_asm
0.06 ± 7% +0.0 0.09 perf-profile.children.cycles-pp.prepare_task_switch
0.04 ± 44% +0.0 0.07 ± 5% perf-profile.children.cycles-pp.timerqueue_linked_add
0.12 ± 6% +0.0 0.15 ± 4% perf-profile.children.cycles-pp.raw_spin_rq_lock_nested
0.06 ± 7% +0.0 0.09 ± 7% perf-profile.children.cycles-pp._find_next_and_bit
0.03 ± 70% +0.0 0.06 ± 6% perf-profile.children.cycles-pp.sysvec_call_function_single
0.11 ± 4% +0.0 0.14 ± 4% perf-profile.children.cycles-pp.__irq_exit_rcu
0.06 ± 6% +0.0 0.09 ± 4% perf-profile.children.cycles-pp.set_next_task_fair
0.09 ± 5% +0.0 0.12 ± 3% perf-profile.children.cycles-pp.update_curr
0.15 ± 3% +0.0 0.18 ± 2% perf-profile.children.cycles-pp.__sched_balance_update_blocked_averages
0.08 ± 6% +0.0 0.11 ± 4% perf-profile.children.cycles-pp.memchr_inv
0.16 ± 2% +0.0 0.20 ± 5% perf-profile.children.cycles-pp.sched_balance_domains
0.07 ± 5% +0.0 0.11 ± 5% perf-profile.children.cycles-pp.nohz_balance_exit_idle
0.27 ± 4% +0.0 0.30 perf-profile.children.cycles-pp.sched_balance_update_blocked_averages
0.02 ±141% +0.0 0.06 ± 8% perf-profile.children.cycles-pp.next_zone
0.02 ± 99% +0.0 0.07 ± 7% perf-profile.children.cycles-pp.leave_mm
0.10 ± 3% +0.0 0.14 perf-profile.children.cycles-pp.switch_mm_irqs_off
0.08 ± 4% +0.0 0.12 ± 4% perf-profile.children.cycles-pp.select_task_rq
0.09 ± 4% +0.0 0.14 ± 3% perf-profile.children.cycles-pp.tick_nohz_next_event
0.05 +0.0 0.10 ± 4% perf-profile.children.cycles-pp.rwsem_mark_wake
0.02 ±141% +0.0 0.06 ± 7% perf-profile.children.cycles-pp.tmigr_cpu_activate
0.07 ± 8% +0.0 0.12 perf-profile.children.cycles-pp._raw_spin_unlock_irqrestore
0.22 ± 3% +0.0 0.27 ± 2% perf-profile.children.cycles-pp.msgctl_stat
0.10 ± 4% +0.0 0.15 ± 3% perf-profile.children.cycles-pp.nohz_balancer_kick
0.00 +0.1 0.05 perf-profile.children.cycles-pp.__switch_to
0.00 +0.1 0.05 perf-profile.children.cycles-pp.__tmigr_cpu_activate
0.00 +0.1 0.05 perf-profile.children.cycles-pp.idle_cpu
0.00 +0.1 0.05 perf-profile.children.cycles-pp.put_prev_task_idle
0.00 +0.1 0.05 perf-profile.children.cycles-pp.select_idle_sibling
0.00 +0.1 0.05 perf-profile.children.cycles-pp.switch_fpu_return
0.00 +0.1 0.05 ± 7% perf-profile.children.cycles-pp.__update_load_avg_cfs_rq
0.00 +0.1 0.05 ± 7% perf-profile.children.cycles-pp.__update_load_avg_se
0.00 +0.1 0.05 ± 7% perf-profile.children.cycles-pp.cpuidle_governor_latency_req
0.00 +0.1 0.05 ± 7% perf-profile.children.cycles-pp.ipc_obtain_object_idr
0.00 +0.1 0.05 ± 7% perf-profile.children.cycles-pp.sysvec_call_function
0.11 ± 3% +0.1 0.16 ± 3% perf-profile.children.cycles-pp.update_load_avg
0.12 ± 4% +0.1 0.17 ± 2% perf-profile.children.cycles-pp.__get_next_timer_interrupt
0.13 ± 5% +0.1 0.18 ± 2% perf-profile.children.cycles-pp.__hrtimer_start_range_ns
0.50 ± 15% +0.1 0.55 perf-profile.children.cycles-pp.security_msg_msg_free
0.00 +0.1 0.06 ± 9% perf-profile.children.cycles-pp.radix_tree_next_chunk
0.00 +0.1 0.06 ± 9% perf-profile.children.cycles-pp.tmigr_cpu_deactivate
0.00 +0.1 0.06 ± 8% perf-profile.children.cycles-pp.native_sched_clock
0.00 +0.1 0.06 ± 6% perf-profile.children.cycles-pp.ipcctl_obtain_check
0.12 ± 3% +0.1 0.18 ± 2% perf-profile.children.cycles-pp.tick_nohz_get_sleep_length
0.00 +0.1 0.06 perf-profile.children.cycles-pp.ct_idle_exit
0.12 ± 4% +0.1 0.18 ± 4% perf-profile.children.cycles-pp.dequeue_entity
0.00 +0.1 0.07 ± 7% perf-profile.children.cycles-pp.asm_sysvec_call_function
0.30 ± 4% +0.1 0.36 perf-profile.children.cycles-pp.__pcs_replace_full_main
0.14 ± 2% +0.1 0.21 perf-profile.children.cycles-pp.enqueue_entity
0.14 ± 3% +0.1 0.22 ± 3% perf-profile.children.cycles-pp.dequeue_entities
0.46 ± 2% +0.1 0.54 ± 2% perf-profile.children.cycles-pp.hrtimer_interrupt
0.17 ± 2% +0.1 0.24 ± 3% perf-profile.children.cycles-pp.try_to_block_task
0.47 ± 2% +0.1 0.55 ± 2% perf-profile.children.cycles-pp.__sysvec_apic_timer_interrupt
0.16 ± 3% +0.1 0.24 ± 3% perf-profile.children.cycles-pp.dequeue_task_fair
0.40 ± 2% +0.1 0.48 ± 2% perf-profile.children.cycles-pp.tick_nohz_handler
0.00 +0.1 0.08 perf-profile.children.cycles-pp.osq_unlock
0.41 ± 2% +0.1 0.50 perf-profile.children.cycles-pp.do_softirq
0.21 ± 2% +0.1 0.29 ± 2% perf-profile.children.cycles-pp.need_update
0.09 ± 11% +0.1 0.17 ± 2% perf-profile.children.cycles-pp.__kmem_cache_free_bulk
0.34 ± 2% +0.1 0.42 ± 2% perf-profile.children.cycles-pp.update_process_times
0.20 ± 2% +0.1 0.28 perf-profile.children.cycles-pp.hrtimer_start_range_ns
0.41 ± 2% +0.1 0.50 ± 2% perf-profile.children.cycles-pp.__hrtimer_run_queues
0.22 ± 2% +0.1 0.30 ± 2% perf-profile.children.cycles-pp.quiet_vmstat
0.09 ± 11% +0.1 0.18 ± 3% perf-profile.children.cycles-pp.sheaf_flush_unused
0.00 +0.1 0.09 ± 7% perf-profile.children.cycles-pp.tlb_finish_mmu
0.56 +0.1 0.66 perf-profile.children.cycles-pp.sysvec_apic_timer_interrupt
0.21 ± 2% +0.1 0.30 perf-profile.children.cycles-pp.tick_nohz_restart_sched_tick
0.00 +0.1 0.10 ± 9% perf-profile.children.cycles-pp.change_prot_numa
0.00 +0.1 0.10 ± 6% perf-profile.children.cycles-pp.on_each_cpu_cond_mask
0.00 +0.1 0.10 ± 6% perf-profile.children.cycles-pp.task_numa_work
0.00 +0.1 0.10 ± 6% perf-profile.children.cycles-pp.task_work_run
0.44 ± 2% +0.1 0.54 perf-profile.children.cycles-pp.rest_init
0.44 ± 2% +0.1 0.54 perf-profile.children.cycles-pp.start_kernel
0.44 ± 2% +0.1 0.54 perf-profile.children.cycles-pp.x86_64_start_kernel
0.44 ± 2% +0.1 0.54 perf-profile.children.cycles-pp.x86_64_start_reservations
0.00 +0.1 0.10 ± 5% perf-profile.children.cycles-pp.flush_tlb_mm_range
0.00 +0.1 0.10 ± 5% perf-profile.children.cycles-pp.smp_call_function_many_cond
0.22 ± 3% +0.1 0.32 ± 2% perf-profile.children.cycles-pp.enqueue_task_fair
0.22 ± 2% +0.1 0.32 perf-profile.children.cycles-pp.menu_select
0.62 +0.1 0.72 perf-profile.children.cycles-pp.asm_sysvec_apic_timer_interrupt
0.00 +0.1 0.11 ± 6% perf-profile.children.cycles-pp.exit_to_user_mode_loop
0.47 ± 2% +0.1 0.58 perf-profile.children.cycles-pp._nohz_idle_balance
0.23 ± 2% +0.1 0.34 ± 2% perf-profile.children.cycles-pp.enqueue_task
0.52 ± 2% +0.1 0.63 perf-profile.children.cycles-pp.handle_softirqs
0.22 ± 4% +0.1 0.34 ± 2% perf-profile.children.cycles-pp.update_sg_lb_stats
0.27 +0.1 0.40 ± 2% perf-profile.children.cycles-pp.ttwu_do_activate
0.30 ± 3% +0.1 0.43 perf-profile.children.cycles-pp.tick_nohz_idle_exit
0.00 +0.1 0.13 ± 2% perf-profile.children.cycles-pp.rwsem_spin_on_owner
0.26 ± 3% +0.1 0.39 ± 2% perf-profile.children.cycles-pp.sched_balance_find_src_group
0.25 ± 3% +0.1 0.38 ± 2% perf-profile.children.cycles-pp.update_sd_lb_stats
0.36 ± 2% +0.1 0.51 ± 2% perf-profile.children.cycles-pp.tick_nohz_stop_tick
0.37 +0.1 0.52 perf-profile.children.cycles-pp.tick_nohz_idle_stop_tick
0.84 ± 2% +0.2 1.00 ± 3% perf-profile.children.cycles-pp.__radix_tree_lookup
0.36 ± 2% +0.2 0.52 perf-profile.children.cycles-pp.sched_ttwu_pending
0.25 ± 2% +0.2 0.41 ± 2% perf-profile.children.cycles-pp.sched_balance_newidle
0.31 ± 2% +0.2 0.48 ± 2% perf-profile.children.cycles-pp.sched_balance_rq
0.40 ± 2% +0.2 0.57 perf-profile.children.cycles-pp.schedule_idle
0.42 ± 3% +0.2 0.60 perf-profile.children.cycles-pp.__flush_smp_call_function_queue
0.52 +0.2 0.71 perf-profile.children.cycles-pp.wake_up_q
0.34 ± 3% +0.2 0.56 perf-profile.children.cycles-pp.schedule_preempt_disabled
0.23 ± 4% +0.2 0.47 ± 2% perf-profile.children.cycles-pp.try_to_wake_up
0.40 ± 2% +0.2 0.64 perf-profile.children.cycles-pp.pick_next_task_fair
0.46 ± 2% +0.3 0.72 perf-profile.children.cycles-pp.__pick_next_task
0.83 +0.3 1.09 perf-profile.children.cycles-pp.flush_smp_call_function_queue
0.25 +0.3 0.52 perf-profile.children.cycles-pp.up_write
0.10 ± 3% +0.3 0.40 perf-profile.children.cycles-pp.up_read
0.59 ± 2% +0.3 0.91 perf-profile.children.cycles-pp.schedule
0.09 ± 4% +0.3 0.41 ± 3% perf-profile.children.cycles-pp.osq_lock
0.86 ± 5% +0.3 1.19 perf-profile.children.cycles-pp.sysvipc_proc_start
0.27 +0.4 0.64 perf-profile.children.cycles-pp.rwsem_wake
0.98 +0.4 1.36 perf-profile.children.cycles-pp.intel_idle_xstate
0.24 ± 3% +0.4 0.64 perf-profile.children.cycles-pp.sysvipc_proc_next
0.06 ± 6% +0.5 0.52 perf-profile.children.cycles-pp.idr_get_next
0.05 ± 7% +0.5 0.52 ± 2% perf-profile.children.cycles-pp.idr_get_next_ul
0.97 +0.5 1.45 perf-profile.children.cycles-pp.__schedule
1.34 ± 2% +0.5 1.84 perf-profile.children.cycles-pp.cpuidle_enter_state
1.35 ± 2% +0.5 1.86 perf-profile.children.cycles-pp.cpuidle_enter
2.09 ± 3% +0.6 2.65 perf-profile.children.cycles-pp.ksys_read
2.08 ± 3% +0.6 2.64 perf-profile.children.cycles-pp.vfs_read
2.05 ± 3% +0.6 2.61 perf-profile.children.cycles-pp.seq_read
2.05 ± 3% +0.6 2.61 perf-profile.children.cycles-pp.seq_read_iter
0.35 ± 2% +0.7 1.03 perf-profile.children.cycles-pp.down_write
0.31 ± 3% +0.7 0.99 perf-profile.children.cycles-pp.rwsem_down_write_slowpath
2.05 +0.8 2.85 perf-profile.children.cycles-pp.cpuidle_idle_call
0.76 +0.9 1.69 perf-profile.children.cycles-pp.msgctl_down
3.25 +1.3 4.57 perf-profile.children.cycles-pp.start_secondary
3.69 +1.4 5.11 perf-profile.children.cycles-pp.do_idle
3.70 +1.4 5.12 perf-profile.children.cycles-pp.common_startup_64
3.70 +1.4 5.12 perf-profile.children.cycles-pp.cpu_startup_entry
0.89 ± 5% +1.5 2.41 perf-profile.children.cycles-pp._raw_spin_lock_irq
1.26 ± 5% +1.9 3.11 perf-profile.children.cycles-pp.down_read
1.21 ± 5% +1.9 3.08 perf-profile.children.cycles-pp.rwsem_down_read_slowpath
83.56 +2.3 85.86 perf-profile.children.cycles-pp.entry_SYSCALL_64_after_hwframe
82.93 +2.4 85.34 perf-profile.children.cycles-pp.do_syscall_64
15.69 ± 4% +7.3 23.00 perf-profile.children.cycles-pp.native_queued_spin_lock_slowpath
10.46 +9.9 20.40 perf-profile.children.cycles-pp.ipc_obtain_object_check
7.08 ± 6% +10.6 17.72 perf-profile.children.cycles-pp.__percpu_counter_sum
5.95 ± 8% +11.0 16.93 perf-profile.children.cycles-pp._raw_spin_lock_irqsave
56.30 ± 26% +13.0 69.30 perf-profile.children.cycles-pp.stress_msg
0.48 +13.3 13.78 perf-profile.children.cycles-pp.idr_find
8.76 ± 6% +13.5 22.29 perf-profile.children.cycles-pp.ksys_msgctl
9.05 ± 5% +13.6 22.62 perf-profile.children.cycles-pp.msgctl
9.11 -3.4 5.66 perf-profile.self.cycles-pp.ipc_obtain_object_check
6.42 ± 2% -2.8 3.64 perf-profile.self.cycles-pp.percpu_counter_add_batch
4.69 ± 3% -1.8 2.87 perf-profile.self.cycles-pp.do_msgsnd
4.42 ± 2% -1.7 2.76 perf-profile.self.cycles-pp.stress_msg_receiver
4.70 ± 31% -1.6 3.10 perf-profile.self.cycles-pp._copy_to_user
3.87 -1.5 2.42 perf-profile.self.cycles-pp.stress_msg_sender
4.61 ± 3% -1.3 3.27 perf-profile.self.cycles-pp.do_msgrcv
3.72 ± 13% -1.3 2.46 perf-profile.self.cycles-pp._raw_spin_lock
2.36 -1.2 1.12 ± 2% perf-profile.self.cycles-pp.load_msg
2.26 ± 2% -1.2 1.09 ± 2% perf-profile.self.cycles-pp.__refill_objects_node
3.48 ± 2% -1.0 2.50 perf-profile.self.cycles-pp.__memcg_slab_free_hook
1.88 ± 73% -0.9 1.00 perf-profile.self.cycles-pp._copy_from_user
1.33 ± 16% -0.8 0.55 ± 3% perf-profile.self.cycles-pp.__slab_free
2.05 ± 2% -0.7 1.36 perf-profile.self.cycles-pp.__memcg_slab_post_alloc_hook
1.06 ± 2% -0.4 0.69 perf-profile.self.cycles-pp.check_heap_object
1.94 ± 2% -0.3 1.61 perf-profile.self.cycles-pp.entry_SYSRETQ_unsafe_stack
1.47 -0.3 1.20 perf-profile.self.cycles-pp.__percpu_counter_sum
0.90 ± 5% -0.2 0.73 perf-profile.self.cycles-pp.__get_user_8
1.01 ± 2% -0.2 0.85 perf-profile.self.cycles-pp.entry_SYSCALL_64
1.02 ± 3% -0.2 0.86 perf-profile.self.cycles-pp.__kmalloc_node_noprof
0.85 -0.1 0.70 perf-profile.self.cycles-pp.__put_user_8
0.32 -0.1 0.21 ± 3% perf-profile.self.cycles-pp.ss_wakeup
0.37 ± 2% -0.1 0.26 ± 2% perf-profile.self.cycles-pp.trylock_stock
0.68 ± 2% -0.1 0.58 perf-profile.self.cycles-pp.entry_SYSCALL_64_after_hwframe
0.56 ± 2% -0.1 0.46 perf-profile.self.cycles-pp.prandom_u32_state
0.62 ± 2% -0.1 0.53 ± 2% perf-profile.self.cycles-pp.__check_object_size
0.51 -0.1 0.42 ± 2% perf-profile.self.cycles-pp.entry_SYSCALL_64_safe_stack
0.59 -0.1 0.50 ± 2% perf-profile.self.cycles-pp.__check_heap_object
0.52 ± 2% -0.1 0.43 perf-profile.self.cycles-pp.__account_obj_stock
0.57 ± 3% -0.1 0.49 ± 2% perf-profile.self.cycles-pp.ipcperms
0.55 ± 2% -0.1 0.48 ± 2% perf-profile.self.cycles-pp.__virt_addr_valid
0.43 ± 2% -0.1 0.38 perf-profile.self.cycles-pp.syscall_return_via_sysret
0.26 ± 4% -0.1 0.20 ± 3% perf-profile.self.cycles-pp.number
0.28 ± 3% -0.0 0.24 ± 2% perf-profile.self.cycles-pp._find_next_or_bit
0.20 ± 2% -0.0 0.16 perf-profile.self.cycles-pp.check_stack_object
0.22 ± 3% -0.0 0.18 ± 2% perf-profile.self.cycles-pp.vsnprintf
0.24 ± 3% -0.0 0.21 ± 2% perf-profile.self.cycles-pp.wake_up_q
0.26 ± 3% -0.0 0.22 ± 2% perf-profile.self.cycles-pp.store_msg
0.09 ± 7% -0.0 0.06 ± 6% perf-profile.self.cycles-pp.mod_memcg_lruvec_state
0.24 ± 2% -0.0 0.20 ± 2% perf-profile.self.cycles-pp.security_ipc_permission
0.18 ± 3% -0.0 0.15 ± 4% perf-profile.self.cycles-pp.barn_replace_empty_sheaf
0.21 ± 3% -0.0 0.18 ± 2% perf-profile.self.cycles-pp.format_decode
0.23 ± 3% -0.0 0.21 ± 2% perf-profile.self.cycles-pp.x64_sys_call
0.09 ± 5% -0.0 0.07 perf-profile.self.cycles-pp.__libc_msgrcv
0.15 ± 3% -0.0 0.12 ± 4% perf-profile.self.cycles-pp.arch_exit_to_user_mode_prepare
0.12 ± 4% -0.0 0.10 ± 4% perf-profile.self.cycles-pp.security_msg_msg_alloc
0.12 ± 3% -0.0 0.10 ± 3% perf-profile.self.cycles-pp.barn_replace_full_sheaf
0.12 ± 3% -0.0 0.10 ± 3% perf-profile.self.cycles-pp.security_msg_queue_msgsnd
0.14 ± 3% -0.0 0.12 ± 4% perf-profile.self.cycles-pp.is_vmalloc_addr
0.14 ± 2% -0.0 0.12 ± 3% perf-profile.self.cycles-pp.security_msg_queue_msgrcv
0.19 ± 3% -0.0 0.17 ± 3% perf-profile.self.cycles-pp.__refill_obj_stock
0.08 ± 6% -0.0 0.06 ± 6% perf-profile.self.cycles-pp.wake_q_add
0.12 ± 6% -0.0 0.10 ± 5% perf-profile.self.cycles-pp.__x64_sys_msgsnd
0.08 ± 6% +0.0 0.09 ± 4% perf-profile.self.cycles-pp.__sched_balance_update_blocked_averages
0.07 +0.0 0.09 ± 4% perf-profile.self.cycles-pp.update_rq_clock_task
0.03 ± 70% +0.0 0.06 perf-profile.self.cycles-pp.ktime_get
0.08 ± 6% +0.0 0.10 ± 4% perf-profile.self.cycles-pp.__schedule
0.06 +0.0 0.09 ± 7% perf-profile.self.cycles-pp._find_next_and_bit
0.06 ± 6% +0.0 0.09 ± 6% perf-profile.self.cycles-pp.enqueue_task_fair
0.08 +0.0 0.11 perf-profile.self.cycles-pp.need_update
0.07 ± 6% +0.0 0.10 ± 4% perf-profile.self.cycles-pp.memchr_inv
0.03 ± 70% +0.0 0.06 ± 7% perf-profile.self.cycles-pp.___perf_sw_event
0.06 ± 6% +0.0 0.10 ± 5% perf-profile.self.cycles-pp.menu_select
0.08 ± 4% +0.0 0.11 ± 4% perf-profile.self.cycles-pp.switch_mm_irqs_off
0.07 ± 7% +0.0 0.10 ± 3% perf-profile.self.cycles-pp.cpuidle_enter_state
0.07 ± 5% +0.0 0.11 ± 5% perf-profile.self.cycles-pp.nohz_balance_exit_idle
0.05 +0.0 0.09 ± 4% perf-profile.self.cycles-pp.rwsem_mark_wake
0.17 ± 16% +0.0 0.22 ± 2% perf-profile.self.cycles-pp.security_msg_msg_free
0.01 ±223% +0.0 0.06 ± 6% perf-profile.self.cycles-pp.timerqueue_linked_add
0.00 +0.1 0.05 perf-profile.self.cycles-pp.__switch_to
0.00 +0.1 0.05 perf-profile.self.cycles-pp.__update_load_avg_cfs_rq
0.00 +0.1 0.05 perf-profile.self.cycles-pp.__update_load_avg_se
0.00 +0.1 0.05 perf-profile.self.cycles-pp.update_load_avg
0.01 ±223% +0.1 0.06 perf-profile.self.cycles-pp.do_idle
0.00 +0.1 0.05 ± 8% perf-profile.self.cycles-pp.radix_tree_next_chunk
0.00 +0.1 0.06 ± 9% perf-profile.self.cycles-pp.finish_task_switch
0.00 +0.1 0.06 ± 9% perf-profile.self.cycles-pp.native_sched_clock
0.00 +0.1 0.06 ± 8% perf-profile.self.cycles-pp.cpuidle_idle_call
0.07 ± 5% +0.1 0.13 ± 5% perf-profile.self.cycles-pp.rwsem_down_write_slowpath
0.00 +0.1 0.06 perf-profile.self.cycles-pp.sched_balance_newidle
0.00 +0.1 0.08 ± 6% perf-profile.self.cycles-pp.osq_unlock
0.18 ± 3% +0.1 0.27 ± 2% perf-profile.self.cycles-pp.update_sg_lb_stats
0.00 +0.1 0.10 ± 6% perf-profile.self.cycles-pp.smp_call_function_many_cond
0.00 +0.1 0.10 ± 5% perf-profile.self.cycles-pp.up_write
0.08 ± 8% +0.1 0.18 ± 2% perf-profile.self.cycles-pp.ksys_msgctl
0.00 +0.1 0.13 ± 3% perf-profile.self.cycles-pp.rwsem_spin_on_owner
0.04 ± 44% +0.1 0.17 ± 4% perf-profile.self.cycles-pp.up_read
0.80 ± 2% +0.2 0.96 ± 3% perf-profile.self.cycles-pp.__radix_tree_lookup
0.51 ± 4% +0.2 0.70 perf-profile.self.cycles-pp._raw_spin_lock_irqsave
0.00 +0.2 0.19 perf-profile.self.cycles-pp._raw_spin_lock_irq
0.08 ± 6% +0.2 0.28 ± 3% perf-profile.self.cycles-pp.rwsem_down_read_slowpath
0.09 ± 6% +0.3 0.41 ± 3% perf-profile.self.cycles-pp.osq_lock
0.97 +0.4 1.35 perf-profile.self.cycles-pp.intel_idle_xstate
0.00 +0.5 0.46 ± 2% perf-profile.self.cycles-pp.idr_get_next_ul
15.58 ± 4% +7.4 22.94 perf-profile.self.cycles-pp.native_queued_spin_lock_slowpath
0.43 ± 2% +13.2 13.63 perf-profile.self.cycles-pp.idr_find
Disclaimer:
Results have been estimated based on internal Intel analysis and are provided
for informational purposes only. Any difference in system hardware or software
design or configuration may affect actual performance.
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
^ permalink raw reply
* [PATCH kernel] crypto/ccp/tsm: Enable the root port after the endpoint
From: Alexey Kardashevskiy @ 2026-05-21 7:43 UTC (permalink / raw)
To: linux-crypto
Cc: linux-kernel, Tom Lendacky, Herbert Xu, David S. Miller,
Dan Williams, Alexey Kardashevskiy, x86, linux-coco,
Pratik R . Sampat, Xu Yilun, Aneesh Kumar K . V
The PCIe r7.0, chapter "6.33.8 Other IDE Rules" mandates if selective IDE
is enabled for config requersts, a stream must be enabled on the endpoint
before enabling it on the rootport:
===
For Selective IDE, the Stream must not be used until it has been enabled in
both Partner Ports. For cases where one of the Partner Ports is a Root Port
and Selective IDE for Configuration Requests is enabled, the other
Partner Port must be enabled prior to the Root Port. For other scenarios,
the mechanisms to satisfy this requirement are implementation-specific.
===
Do what the spec says.
Fixes: 4be423572da1 ("crypto/ccp: Implement SEV-TIO PCIe IDE (phase1)")
Signed-off-by: Alexey Kardashevskiy <aik@amd.com>
---
drivers/crypto/ccp/sev-dev-tsm.c | 10 +++++-----
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/crypto/ccp/sev-dev-tsm.c b/drivers/crypto/ccp/sev-dev-tsm.c
index b07ae529b591..10549a2cc2ae 100644
--- a/drivers/crypto/ccp/sev-dev-tsm.c
+++ b/drivers/crypto/ccp/sev-dev-tsm.c
@@ -58,13 +58,13 @@ static int stream_enable(struct pci_ide *ide)
struct pci_dev *rp = pcie_find_root_port(ide->pdev);
int ret;
- ret = pci_ide_stream_enable(rp, ide);
- if (ret)
+ ret = pci_ide_stream_enable(ide->pdev, ide);
+ if (ret && ret != -ENXIO)
return ret;
- ret = pci_ide_stream_enable(ide->pdev, ide);
- if (ret)
- pci_ide_stream_disable(rp, ide);
+ ret = pci_ide_stream_enable(rp, ide);
+ if (ret && ret != -ENXIO)
+ pci_ide_stream_disable(ide->pdev, ide);
return ret;
}
--
2.53.0
^ permalink raw reply related
* Re: [PATCH 0/3] Add support for qcrypto on shikra
From: Kuldeep Singh @ 2026-05-21 6:51 UTC (permalink / raw)
To: Eric Biggers
Cc: Thara Gopinath, Herbert Xu, David S. Miller, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Bjorn Andersson, Konrad Dybcio,
Vinod Koul, Frank Li, Andy Gross, linux-arm-msm, linux-crypto,
devicetree, linux-kernel, dmaengine
In-Reply-To: <20260514194735.GA1939213@google.com>
On 15-05-2026 01:17, Eric Biggers wrote:
> On Fri, May 15, 2026 at 12:53:35AM +0530, Kuldeep Singh wrote:
>> Add qcrypto and cryptobam DT nodes for enabling qcrypto on kaanapali.
>> Shikra bam dma supports 7 iommus so update dt-bindings accordingly.
>>
>> The patchset depends on below. There's recursive dependency so referred
>> to base DT patch here.
>> - https://lore.kernel.org/all/20260512-shikra-dt-v1-0-716438330dd0@oss.qualcomm.com/
>>
>> Validations:
>> - make ARCH=arm64 DT_CHECKER_FLAGS=-m DT_SCHEMA_FILES=Documentation/devicetree/bindings/dma/qcom,bam-dma.yaml dt_binding_check
>> - make ARCH=arm64 qcom/shikra-cqs-evk.dtb CHECK_DTBS=1 DT_SCHEMA_FILES=Documentation/devicetree/bindings/dma/qcom,bam-dma.yaml
>> - cryptobam and crypto driver probe
>> - kcapi test
>>
>> Signed-off-by: Kuldeep Singh <kuldeep.singh@oss.qualcomm.com>
>
> What specific kernel features would this be useful for, and what
> specific performance improvements are you seeing with those features?
I hope you mean 7 iommu entries.
Please note, shikra is an old platform and differs with latest platforms
like kaanapali in terms of iommus#.
Kaanapali is optimised(in terms of iommus#) as same pipe index/sid i.e
4/5 can be used for general purpose or for any other usecase like
DRM/HDCP etc.
Whereas for shikra, there's dedicated iommu entry for each usecase and
same pipe index/sid cannot be used for other usecases.
The performance will be be effectively similar.
--
Regards
Kuldeep
^ permalink raw reply
* Re: [PATCH v3] crypto/ccp: Introduce SNP_VERIFY_MITIGATION command
From: Pratik R. Sampat @ 2026-05-21 2:10 UTC (permalink / raw)
To: Tom Lendacky, ashish.kalra, john.allen, herbert, davem
Cc: linux-crypto, linux-kernel, aik, tycho, nikunj, michael.roth
In-Reply-To: <6d5fd5eb-e54c-47fd-943a-6d03aaafe243@amd.com>
Hi Tom,
On 5/20/26 4:22 PM, Tom Lendacky wrote:
> On 5/19/26 14:50, Pratik R. Sampat wrote:
>> The SEV-SNP firmware provides the SNP_VERIFY_MITIGATION command, which
>> can be used to query the status of currently supported vulnerability
>> mitigations and to initiate mitigations within the firmware.
>>
>> This command is an explicit mechanism to ascertain if a firmware
>> mitigation is applied without needing a full RMP re-build, which is most
>> useful in a live firmware update scenario.
>>
>> The firmware supports two subcommands: STATUS and VERIFY. The STATUS
>> subcommand is used to query the supported and verified mitigation bits.
>> The VERIFY subcommand initiates the mitigation process within the FW for
>> the specified vulnerability. Expose a userspace interface under:
>> /sys/firmware/sev/vulnerabilities/
>> - supported_mitigations (read-only): supported mitigation vector mask
>> - verified_mitigations (read/write): current verified mask; write a
>> vector to request VERIFY for that bit
>>
>> The behavior of SNP_VERIFY_MITIGATION and the pre-requisites for using
>> it are bug-specific. Information about supported mitigations and its
>> corresponding vector is to be published as part of the AMD Security
>> Bulletin.
>>
>> See SEV-SNP Firmware ABI specifications 1.58, SNP_VERIFY_MITIGATION for
>> more details.
>>
>> Signed-off-by: Pratik R. Sampat <prsampat@amd.com>
>> ---
>> .../sysfs-firmware-sev-vulnerabilities | 17 ++
>> drivers/crypto/ccp/sev-dev.c | 172 ++++++++++++++++++
>> drivers/crypto/ccp/sev-dev.h | 3 +
>> include/linux/psp-sev.h | 51 ++++++
>> 4 files changed, 243 insertions(+)
>> create mode 100644 Documentation/ABI/testing/sysfs-firmware-sev-vulnerabilities
>>
>> diff --git a/Documentation/ABI/testing/sysfs-firmware-sev-vulnerabilities b/Documentation/ABI/testing/sysfs-firmware-sev-vulnerabilities
>> new file mode 100644
>> index 000000000000..cc84adbac3c0
>> --- /dev/null
>> +++ b/Documentation/ABI/testing/sysfs-firmware-sev-vulnerabilities
>> @@ -0,0 +1,17 @@
>> +What: /sys/firmware/sev/vulnerabilities/
>> + /sys/firmware/sev/vulnerabilities/supported_mitigations
>> + /sys/firmware/sev/vulnerabilities/verified_mitigations
>> +Date: May 2026
>> +Contact: linux-crypto@vger.kernel.org
>> +Description: Information about SEV-SNP firmware vulnerability mitigations.
>> + supported_mitigations: Read-only interface that reports
>> + the vector of mitigations supported by
>> + the firmware.
>> + verified_mitigations: Read/write interface that reports
>> + the vector of mitigations already verified
>> + by the firmware. Writing a vector value
>> + requests the firmware to VERIFY the
>> + corresponding mitigation bit(s).
>> + The list of supported mitigations and the meaning of each
>> + vector bit are both platform- and bug-specific and are
>> + published as part of the AMD Security Bulletin.
>> diff --git a/drivers/crypto/ccp/sev-dev.c b/drivers/crypto/ccp/sev-dev.c
>> index d1e9e0ac63b6..eec4864c6597 100644
>> --- a/drivers/crypto/ccp/sev-dev.c
>> +++ b/drivers/crypto/ccp/sev-dev.c
>> @@ -57,6 +57,7 @@
>> #define CMD_BUF_DESC_MAX (CMD_BUF_FW_WRITABLE_MAX + 1)
>>
>> static DEFINE_MUTEX(sev_cmd_mutex);
>> +static DEFINE_MUTEX(sev_mit_sysfs_mutex);
>> static struct sev_misc_dev *misc_dev;
>>
>> static int psp_cmd_timeout = 100;
>> @@ -245,6 +246,7 @@ static int sev_cmd_buffer_len(int cmd)
>> case SEV_CMD_SNP_LAUNCH_FINISH: return sizeof(struct sev_data_snp_launch_finish);
>> case SEV_CMD_SNP_DBG_DECRYPT: return sizeof(struct sev_data_snp_dbg);
>> case SEV_CMD_SNP_DBG_ENCRYPT: return sizeof(struct sev_data_snp_dbg);
>> + case SEV_CMD_SNP_VERIFY_MITIGATION: return sizeof(struct sev_data_snp_verify_mitigation);
>> case SEV_CMD_SNP_PAGE_UNSMASH: return sizeof(struct sev_data_snp_page_unsmash);
>> case SEV_CMD_SNP_PLATFORM_STATUS: return sizeof(struct sev_data_snp_addr);
>> case SEV_CMD_SNP_GUEST_REQUEST: return sizeof(struct sev_data_snp_guest_request);
>> @@ -1351,6 +1353,162 @@ static int snp_filter_reserved_mem_regions(struct resource *rs, void *arg)
>> return 0;
>> }
>>
>> +static int snp_verify_mitigation(u16 command, u64 vector,
>> + struct sev_data_snp_verify_mitigation_dst *dst)
>> +{
>> + struct sev_data_snp_verify_mitigation_dst *mit_dst = NULL;
>> + struct sev_data_snp_verify_mitigation data = {0};
>> + struct sev_device *sev = psp_master->sev_data;
>> + int ret, error = 0;
>> +
>> + mit_dst = snp_alloc_firmware_page(GFP_KERNEL | __GFP_ZERO);
>> + if (!mit_dst)
>> + return -ENOMEM;
>> +
>> + data.length = sizeof(data);
>> + data.subcommand = command;
>> + data.vector = vector;
>> + data.dst_paddr = __psp_pa(mit_dst);
>> + data.dst_paddr_en = true;
>> +
>> + ret = sev_do_cmd(SEV_CMD_SNP_VERIFY_MITIGATION, &data, &error);
>> + if (!ret)
>> + memcpy(dst, mit_dst, sizeof(*mit_dst));
>> + else
>> + dev_err(sev->dev, "SNP_VERIFY_MITIGATION command failed, ret = %d, error = %#x\n",
>> + ret, error);
>> +
>> + snp_free_firmware_page(mit_dst);
>> +
>> + return ret;
>> +}
>
> Should this function also be under the CONFIG_SYSFS #ifdef? Won't you get
> an unused function warning if CONFIG_SYSFS isn't defined?
That's right. Thanks for spotting that!
>
>> +
>> +#ifdef CONFIG_SYSFS
>> +static ssize_t supported_mitigations_show(struct kobject *kobj,
>> + struct kobj_attribute *attr, char *buf)
>> +{
>> + struct sev_data_snp_verify_mitigation_dst dst;
>> + int ret;
>> +
>> + ret = snp_verify_mitigation(SNP_MIT_SUBCMD_REQ_STATUS, 0, &dst);
>> + if (ret)
>> + return ret;
>> +
>> + return sysfs_emit(buf, "0x%llx\n", dst.mit_supported_vector);
>> +}
>> +
>> +static struct kobj_attribute supported_attr =
>> + __ATTR_RO_MODE(supported_mitigations, 0400);
>> +
>> +static ssize_t verified_mitigations_show(struct kobject *kobj,
>> + struct kobj_attribute *attr, char *buf)
>> +{
>> + struct sev_data_snp_verify_mitigation_dst dst;
>> + int ret;
>> +
>> + ret = snp_verify_mitigation(SNP_MIT_SUBCMD_REQ_STATUS, 0, &dst);
>> + if (ret)
>> + return ret;
>> +
>> + return sysfs_emit(buf, "0x%llx\n", dst.mit_verified_vector);
>> +}
>> +
>> +static ssize_t verified_mitigations_store(struct kobject *kobj,
>> + struct kobj_attribute *attr,
>> + const char *buf, size_t count)
>> +{
>> + struct sev_data_snp_verify_mitigation_dst dst;
>> + struct sev_device *sev = psp_master->sev_data;
>> + u64 vector;
>> + int ret;
>> +
>> + ret = kstrtoull(buf, 0, &vector);
>> + if (ret)
>> + return ret;
>> +
>> + ret = snp_verify_mitigation(SNP_MIT_SUBCMD_REQ_VERIFY, vector, &dst);
>> + if (ret)
>> + return ret;
>> +
>> + if (dst.mit_failure_status) {
>> + dev_err(sev->dev, "Verify Mitigation - failure status: 0x%x\n",
>> + dst.mit_failure_status);
>> + return -EIO;
>> + }
>> +
>> + return count;
>> +}
>> +
>> +static struct kobj_attribute verified_attr =
>> + __ATTR_RW_MODE(verified_mitigations, 0600);
>> +
>> +static struct attribute *mitigation_attrs[] = {
>> + &supported_attr.attr,
>> + &verified_attr.attr,
>> + NULL
>> +};
>> +
>> +static const struct attribute_group mit_attr_group = {
>> + .attrs = mitigation_attrs,
>> +};
>> +
>> +static void sev_snp_register_verify_mitigation(struct sev_device *sev)
>> +{
>> + int rc;
>> +
>> + if (!sev->snp_initialized || !sev->snp_plat_status.feature_info ||
>> + !(sev->snp_feat_info_0.ecx & SNP_VERIFY_MITIGATION_SUPPORTED))
>> + return;
>> +
>> + guard(mutex)(&sev_mit_sysfs_mutex);
>> +
>> + if (sev->verify_mit)
>> + return;
>> +
>> + if (!sev->sev_kobj) {
>> + sev->sev_kobj = kobject_create_and_add("sev", firmware_kobj);
>> + if (!sev->sev_kobj)
>> + return;
>> + }
>> +
>> + sev->verify_mit = kobject_create_and_add("vulnerabilities", sev->sev_kobj);
>> + if (!sev->verify_mit)
>> + goto err_sev_kobj;
>> +
>> + rc = sysfs_create_group(sev->verify_mit, &mit_attr_group);
>> + if (rc)
>> + goto err_verify_mit;
>> +
>> + return;
>> +
>> +err_verify_mit:
>> + kobject_put(sev->verify_mit);
>> + sev->verify_mit = NULL;
>> +err_sev_kobj:
>> + kobject_put(sev->sev_kobj);
>> + sev->sev_kobj = NULL;
>> +}
>> +
>> +static void sev_snp_unregister_verify_mitigation(struct sev_device *sev)
>> +{
>> + guard(mutex)(&sev_mit_sysfs_mutex);
>> +
>> + if (sev->verify_mit) {
>> + sysfs_remove_group(sev->verify_mit, &mit_attr_group);
>> + kobject_put(sev->verify_mit);
>> + sev->verify_mit = NULL;
>> + }
>> +
>> + if (sev->sev_kobj) {
>> + kobject_put(sev->sev_kobj);
>> + sev->sev_kobj = NULL;
>> + }
>> +}
>> +#else
>> +static void sev_snp_register_verify_mitigation(struct sev_device *sev) { }
>> +static void sev_snp_unregister_verify_mitigation(struct sev_device *sev) { }
>> +#endif
>> +
>> static int __sev_snp_init_locked(int *error, unsigned int max_snp_asid)
>> {
>> struct sev_data_range_list *snp_range_list __free(kfree) = NULL;
>> @@ -1670,6 +1828,14 @@ int sev_platform_init(struct sev_platform_init_args *args)
>> rc = _sev_platform_init_locked(args);
>> mutex_unlock(&sev_cmd_mutex);
>>
>> + /*
>> + * The shutdown + init path can race with in-flight _show()/_store() operations
>> + * which acquire the sev_cmd_mutex. Register the sysfs interface outside
>> + * the sev_cmd_mutex and serialize by sev_mit_sysfs_mutex instead.
>
> I'm not quite sure I follow this. The shutdown and init path can't race
> with each other, right? In which case this new mutex doesn't really matter
> unless you take it on _show()/_short(), right?
>
What I meant here is the new mutex attempts to addresses the following scenario:
First, assume sev_snp_[un]register_verify_mitigation() are protected under
sev_cmd_mutex:
t1 | t2
---------------------------------- | ----------------------------------
sev_firmware_shutdown() |
lock(sev_cmd_mutex) |
| verified_mitigations_store()
| lock(sev_cmd_mutex) <-- waits on t1
unregister_verify_mitigation() |
sysfs_remove_group() <-- waits for t2's _store to drain
So sev_snp_unregister_verify_mitigation() has to run outside sev_cmd_mutex to
avoid the sysfs_remove_group() <-> in-flight _show()/_store() deadlock.
Now, with unregister no longer protected by sev_cmd_mutex, a concurrent init
can race with shutdown on the sysfs lifetime like so:
t1 | t2
---------------------------------- | ----------------------------------
sev_firmware_shutdown() | sev_platform_init()
unregister_verify_mitigation() | register_verify_mitigation()
sysfs_remove_group() | sysfs_create_group()
Both sides touch sev->verify_mit without serialization. The same race also
exists for init vs init which is no longer covered by sev_cmd_mutex once
register moves outside it.
So, I attempt address that with a sev_mit_sysfs_mutex guard.
--Pratik
^ permalink raw reply
* [PATCH v6 9/9] crypto: atmel: Use dmaengine_prep_config_sg() API
From: Frank.Li @ 2026-05-20 22:00 UTC (permalink / raw)
To: Vinod Koul, Manivannan Sadhasivam, Krzysztof Wilczyński,
Kishon Vijay Abraham I, Bjorn Helgaas, Christoph Hellwig,
Sagi Grimberg, Chaitanya Kulkarni, Herbert Xu, David S. Miller,
Nicolas Ferre, Alexandre Belloni, Claudiu Beznea, Koichiro Den,
Niklas Cassel
Cc: dmaengine, linux-kernel, linux-pci, linux-nvme, mhi,
linux-arm-msm, linux-crypto, linux-arm-kernel, imx, Frank Li
In-Reply-To: <20260520-dma_prep_config-v6-0-06e49b7acb38@nxp.com>
From: Frank Li <Frank.Li@nxp.com>
Using new API dmaengine_prep_config_sg() to simple code.
dmaengine_prep_config_sg() does not distinguish between configuration
failures and descriptor preparation failures, as both are reported through
a NULL return value. Converting both cases to -ENOMEM is therefore
acceptable and consistent with the helper's abstraction.
In practice, most users only care whether the operation succeeds or fails,
and do not depend on the exact errno value returned from this path.
Tested-by: Niklas Cassel <cassel@kernel.org>
Acked-by: Nicolas Ferre <nicolas.ferre@microchip.com>
Signed-off-by: Frank Li <Frank.Li@nxp.com>
---
change in v6
- add commit message about error propagation (sashaki AI)
---
drivers/crypto/atmel-aes.c | 10 +++-------
1 file changed, 3 insertions(+), 7 deletions(-)
diff --git a/drivers/crypto/atmel-aes.c b/drivers/crypto/atmel-aes.c
index b393689400b4c..d890b5a277b9c 100644
--- a/drivers/crypto/atmel-aes.c
+++ b/drivers/crypto/atmel-aes.c
@@ -795,7 +795,6 @@ static int atmel_aes_dma_transfer_start(struct atmel_aes_dev *dd,
struct dma_slave_config config;
dma_async_tx_callback callback;
struct atmel_aes_dma *dma;
- int err;
memset(&config, 0, sizeof(config));
config.src_addr_width = addr_width;
@@ -820,12 +819,9 @@ static int atmel_aes_dma_transfer_start(struct atmel_aes_dev *dd,
return -EINVAL;
}
- err = dmaengine_slave_config(dma->chan, &config);
- if (err)
- return err;
-
- desc = dmaengine_prep_slave_sg(dma->chan, dma->sg, dma->sg_len, dir,
- DMA_PREP_INTERRUPT | DMA_CTRL_ACK);
+ desc = dmaengine_prep_config_sg(dma->chan, dma->sg, dma->sg_len, dir,
+ DMA_PREP_INTERRUPT | DMA_CTRL_ACK,
+ &config);
if (!desc)
return -ENOMEM;
--
2.43.0
^ permalink raw reply related
* [PATCH v6 8/9] PCI: epf-mhi: Use dmaengine_prep_config_single() to simplify code
From: Frank.Li @ 2026-05-20 22:00 UTC (permalink / raw)
To: Vinod Koul, Manivannan Sadhasivam, Krzysztof Wilczyński,
Kishon Vijay Abraham I, Bjorn Helgaas, Christoph Hellwig,
Sagi Grimberg, Chaitanya Kulkarni, Herbert Xu, David S. Miller,
Nicolas Ferre, Alexandre Belloni, Claudiu Beznea, Koichiro Den,
Niklas Cassel
Cc: dmaengine, linux-kernel, linux-pci, linux-nvme, mhi,
linux-arm-msm, linux-crypto, linux-arm-kernel, imx, Frank Li
In-Reply-To: <20260520-dma_prep_config-v6-0-06e49b7acb38@nxp.com>
From: Frank Li <Frank.Li@nxp.com>
Use dmaengine_prep_config_single() to simplify
pci_epf_mhi_edma_read[_sync]() and pci_epf_mhi_edma_write[_sync]().
No functional change.
Tested-by: Niklas Cassel <cassel@kernel.org>
Acked-by: Manivannan Sadhasivam <mani@kernel.org>
Signed-off-by: Frank Li <Frank.Li@nxp.com>
---
Keep mutex lock because sync with other function.
---
drivers/pci/endpoint/functions/pci-epf-mhi.c | 52 +++++++++-------------------
1 file changed, 16 insertions(+), 36 deletions(-)
diff --git a/drivers/pci/endpoint/functions/pci-epf-mhi.c b/drivers/pci/endpoint/functions/pci-epf-mhi.c
index 7f5326925ed54..c3e3b58fb86cd 100644
--- a/drivers/pci/endpoint/functions/pci-epf-mhi.c
+++ b/drivers/pci/endpoint/functions/pci-epf-mhi.c
@@ -328,12 +328,6 @@ static int pci_epf_mhi_edma_read(struct mhi_ep_cntrl *mhi_cntrl,
config.direction = DMA_DEV_TO_MEM;
config.src_addr = buf_info->host_addr;
- ret = dmaengine_slave_config(chan, &config);
- if (ret) {
- dev_err(dev, "Failed to configure DMA channel\n");
- goto err_unlock;
- }
-
dst_addr = dma_map_single(dma_dev, buf_info->dev_addr, buf_info->size,
DMA_FROM_DEVICE);
ret = dma_mapping_error(dma_dev, dst_addr);
@@ -342,9 +336,10 @@ static int pci_epf_mhi_edma_read(struct mhi_ep_cntrl *mhi_cntrl,
goto err_unlock;
}
- desc = dmaengine_prep_slave_single(chan, dst_addr, buf_info->size,
- DMA_DEV_TO_MEM,
- DMA_CTRL_ACK | DMA_PREP_INTERRUPT);
+ desc = dmaengine_prep_config_single(chan, dst_addr, buf_info->size,
+ DMA_DEV_TO_MEM,
+ DMA_CTRL_ACK | DMA_PREP_INTERRUPT,
+ &config);
if (!desc) {
dev_err(dev, "Failed to prepare DMA\n");
ret = -EIO;
@@ -401,12 +396,6 @@ static int pci_epf_mhi_edma_write(struct mhi_ep_cntrl *mhi_cntrl,
config.direction = DMA_MEM_TO_DEV;
config.dst_addr = buf_info->host_addr;
- ret = dmaengine_slave_config(chan, &config);
- if (ret) {
- dev_err(dev, "Failed to configure DMA channel\n");
- goto err_unlock;
- }
-
src_addr = dma_map_single(dma_dev, buf_info->dev_addr, buf_info->size,
DMA_TO_DEVICE);
ret = dma_mapping_error(dma_dev, src_addr);
@@ -415,9 +404,10 @@ static int pci_epf_mhi_edma_write(struct mhi_ep_cntrl *mhi_cntrl,
goto err_unlock;
}
- desc = dmaengine_prep_slave_single(chan, src_addr, buf_info->size,
- DMA_MEM_TO_DEV,
- DMA_CTRL_ACK | DMA_PREP_INTERRUPT);
+ desc = dmaengine_prep_config_single(chan, src_addr, buf_info->size,
+ DMA_MEM_TO_DEV,
+ DMA_CTRL_ACK | DMA_PREP_INTERRUPT,
+ &config);
if (!desc) {
dev_err(dev, "Failed to prepare DMA\n");
ret = -EIO;
@@ -506,12 +496,6 @@ static int pci_epf_mhi_edma_read_async(struct mhi_ep_cntrl *mhi_cntrl,
config.direction = DMA_DEV_TO_MEM;
config.src_addr = buf_info->host_addr;
- ret = dmaengine_slave_config(chan, &config);
- if (ret) {
- dev_err(dev, "Failed to configure DMA channel\n");
- goto err_unlock;
- }
-
dst_addr = dma_map_single(dma_dev, buf_info->dev_addr, buf_info->size,
DMA_FROM_DEVICE);
ret = dma_mapping_error(dma_dev, dst_addr);
@@ -520,9 +504,10 @@ static int pci_epf_mhi_edma_read_async(struct mhi_ep_cntrl *mhi_cntrl,
goto err_unlock;
}
- desc = dmaengine_prep_slave_single(chan, dst_addr, buf_info->size,
- DMA_DEV_TO_MEM,
- DMA_CTRL_ACK | DMA_PREP_INTERRUPT);
+ desc = dmaengine_prep_config_single(chan, dst_addr, buf_info->size,
+ DMA_DEV_TO_MEM,
+ DMA_CTRL_ACK | DMA_PREP_INTERRUPT,
+ &config);
if (!desc) {
dev_err(dev, "Failed to prepare DMA\n");
ret = -EIO;
@@ -585,12 +570,6 @@ static int pci_epf_mhi_edma_write_async(struct mhi_ep_cntrl *mhi_cntrl,
config.direction = DMA_MEM_TO_DEV;
config.dst_addr = buf_info->host_addr;
- ret = dmaengine_slave_config(chan, &config);
- if (ret) {
- dev_err(dev, "Failed to configure DMA channel\n");
- goto err_unlock;
- }
-
src_addr = dma_map_single(dma_dev, buf_info->dev_addr, buf_info->size,
DMA_TO_DEVICE);
ret = dma_mapping_error(dma_dev, src_addr);
@@ -599,9 +578,10 @@ static int pci_epf_mhi_edma_write_async(struct mhi_ep_cntrl *mhi_cntrl,
goto err_unlock;
}
- desc = dmaengine_prep_slave_single(chan, src_addr, buf_info->size,
- DMA_MEM_TO_DEV,
- DMA_CTRL_ACK | DMA_PREP_INTERRUPT);
+ desc = dmaengine_prep_config_single(chan, src_addr, buf_info->size,
+ DMA_MEM_TO_DEV,
+ DMA_CTRL_ACK | DMA_PREP_INTERRUPT,
+ &config);
if (!desc) {
dev_err(dev, "Failed to prepare DMA\n");
ret = -EIO;
--
2.43.0
^ permalink raw reply related
* [PATCH v6 7/9] nvmet: pci-epf: Use dmaengine_prep_config_single_safe() API
From: Frank.Li @ 2026-05-20 22:00 UTC (permalink / raw)
To: Vinod Koul, Manivannan Sadhasivam, Krzysztof Wilczyński,
Kishon Vijay Abraham I, Bjorn Helgaas, Christoph Hellwig,
Sagi Grimberg, Chaitanya Kulkarni, Herbert Xu, David S. Miller,
Nicolas Ferre, Alexandre Belloni, Claudiu Beznea, Koichiro Den,
Niklas Cassel
Cc: dmaengine, linux-kernel, linux-pci, linux-nvme, mhi,
linux-arm-msm, linux-crypto, linux-arm-kernel, imx, Frank Li
In-Reply-To: <20260520-dma_prep_config-v6-0-06e49b7acb38@nxp.com>
From: Frank Li <Frank.Li@nxp.com>
Use the new dmaengine_prep_config_single_safe() API to combine the
configuration and descriptor preparation into a single call.
Since dmaengine_prep_config_single_safe() performs the configuration and
preparation atomically and the mutex can be removed.
Tested-by: Niklas Cassel <cassel@kernel.org>
Acked-by: Manivannan Sadhasivam <mani@kernel.org>
Signed-off-by: Frank Li <Frank.Li@nxp.com>
---
change in v6
- remove local unused variable lock (sashika AI)
---
drivers/nvme/target/pci-epf.c | 21 ++++-----------------
1 file changed, 4 insertions(+), 17 deletions(-)
diff --git a/drivers/nvme/target/pci-epf.c b/drivers/nvme/target/pci-epf.c
index 2afe8f4d0e461..f917d6ec278b7 100644
--- a/drivers/nvme/target/pci-epf.c
+++ b/drivers/nvme/target/pci-epf.c
@@ -368,18 +368,15 @@ static int nvmet_pci_epf_dma_transfer(struct nvmet_pci_epf *nvme_epf,
struct dma_chan *chan;
dma_cookie_t cookie;
dma_addr_t dma_addr;
- struct mutex *lock;
int ret;
switch (dir) {
case DMA_FROM_DEVICE:
- lock = &nvme_epf->dma_rx_lock;
chan = nvme_epf->dma_rx_chan;
sconf.direction = DMA_DEV_TO_MEM;
sconf.src_addr = seg->pci_addr;
break;
case DMA_TO_DEVICE:
- lock = &nvme_epf->dma_tx_lock;
chan = nvme_epf->dma_tx_chan;
sconf.direction = DMA_MEM_TO_DEV;
sconf.dst_addr = seg->pci_addr;
@@ -388,22 +385,15 @@ static int nvmet_pci_epf_dma_transfer(struct nvmet_pci_epf *nvme_epf,
return -EINVAL;
}
- mutex_lock(lock);
-
dma_dev = dmaengine_get_dma_device(chan);
dma_addr = dma_map_single(dma_dev, seg->buf, seg->length, dir);
ret = dma_mapping_error(dma_dev, dma_addr);
if (ret)
- goto unlock;
-
- ret = dmaengine_slave_config(chan, &sconf);
- if (ret) {
- dev_err(dev, "Failed to configure DMA channel\n");
- goto unmap;
- }
+ return ret;
- desc = dmaengine_prep_slave_single(chan, dma_addr, seg->length,
- sconf.direction, DMA_CTRL_ACK);
+ desc = dmaengine_prep_config_single_safe(chan, dma_addr, seg->length,
+ sconf.direction,
+ DMA_CTRL_ACK, &sconf);
if (!desc) {
dev_err(dev, "Failed to prepare DMA\n");
ret = -EIO;
@@ -426,9 +416,6 @@ static int nvmet_pci_epf_dma_transfer(struct nvmet_pci_epf *nvme_epf,
unmap:
dma_unmap_single(dma_dev, dma_addr, seg->length, dir);
-unlock:
- mutex_unlock(lock);
-
return ret;
}
--
2.43.0
^ permalink raw reply related
* [PATCH v6 6/9] nvmet: pci-epf: Remove unnecessary dmaengine_terminate_sync() on each DMA transfer
From: Frank.Li @ 2026-05-20 22:00 UTC (permalink / raw)
To: Vinod Koul, Manivannan Sadhasivam, Krzysztof Wilczyński,
Kishon Vijay Abraham I, Bjorn Helgaas, Christoph Hellwig,
Sagi Grimberg, Chaitanya Kulkarni, Herbert Xu, David S. Miller,
Nicolas Ferre, Alexandre Belloni, Claudiu Beznea, Koichiro Den,
Niklas Cassel
Cc: dmaengine, linux-kernel, linux-pci, linux-nvme, mhi,
linux-arm-msm, linux-crypto, linux-arm-kernel, imx, Frank Li,
Damien Le Moal
In-Reply-To: <20260520-dma_prep_config-v6-0-06e49b7acb38@nxp.com>
From: Frank Li <Frank.Li@nxp.com>
dmaengine_terminate_sync() cancels all pending requests. Calling it for
every DMA transfer is unnecessary and counterproductive. This function is
generally intended for cleanup paths such as module removal, device close,
or unbind operations.
Remove the redundant calls for success path and keep it only at error path.
Tested-by: Niklas Cassel <cassel@kernel.org>
Reviewed-by: Damien Le Moal <dlemoal@kernel.org>
Acked-by: Manivannan Sadhasivam <mani@kernel.org>
Signed-off-by: Frank Li <Frank.Li@nxp.com>
---
This one also fix stress test failure after remove mutex and use new API
dmaengine_prep_slave_sg_config().
---
drivers/nvme/target/pci-epf.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/nvme/target/pci-epf.c b/drivers/nvme/target/pci-epf.c
index 4e9db96ebfecd..2afe8f4d0e461 100644
--- a/drivers/nvme/target/pci-epf.c
+++ b/drivers/nvme/target/pci-epf.c
@@ -420,10 +420,9 @@ static int nvmet_pci_epf_dma_transfer(struct nvmet_pci_epf *nvme_epf,
if (dma_sync_wait(chan, cookie) != DMA_COMPLETE) {
dev_err(dev, "DMA transfer failed\n");
ret = -EIO;
+ dmaengine_terminate_sync(chan);
}
- dmaengine_terminate_sync(chan);
-
unmap:
dma_unmap_single(dma_dev, dma_addr, seg->length, dir);
--
2.43.0
^ permalink raw reply related
* [PATCH v6 5/9] dmaengine: dw-edma: Pass dma_slave_config to dw_edma_device_transfer()
From: Frank.Li @ 2026-05-20 22:00 UTC (permalink / raw)
To: Vinod Koul, Manivannan Sadhasivam, Krzysztof Wilczyński,
Kishon Vijay Abraham I, Bjorn Helgaas, Christoph Hellwig,
Sagi Grimberg, Chaitanya Kulkarni, Herbert Xu, David S. Miller,
Nicolas Ferre, Alexandre Belloni, Claudiu Beznea, Koichiro Den,
Niklas Cassel
Cc: dmaengine, linux-kernel, linux-pci, linux-nvme, mhi,
linux-arm-msm, linux-crypto, linux-arm-kernel, imx, Frank Li
In-Reply-To: <20260520-dma_prep_config-v6-0-06e49b7acb38@nxp.com>
From: Frank Li <Frank.Li@nxp.com>
Pass dma_slave_config to dw_edma_device_transfer() to support atomic
configuration and descriptor preparation when a non-NULL config is
provided to device_prep_config_sg().
Tested-by: Niklas Cassel <cassel@kernel.org>
Reviewed-by: Manivannan Sadhasivam <mani@kernel.org>
Signed-off-by: Frank Li <Frank.Li@nxp.com>
---
change in v3
- rewrite dw_edma_device_slave_config() according to Damien's suggestion.
---
drivers/dma/dw-edma/dw-edma-core.c | 27 +++++++++++++++++++++------
1 file changed, 21 insertions(+), 6 deletions(-)
diff --git a/drivers/dma/dw-edma/dw-edma-core.c b/drivers/dma/dw-edma/dw-edma-core.c
index 92572dd8131e6..ba37bc983dcd2 100644
--- a/drivers/dma/dw-edma/dw-edma-core.c
+++ b/drivers/dma/dw-edma/dw-edma-core.c
@@ -267,6 +267,20 @@ static int dw_edma_device_config(struct dma_chan *dchan,
return 0;
}
+static struct dma_slave_config *
+dw_edma_device_get_config(struct dma_chan *dchan,
+ struct dma_slave_config *config)
+{
+ struct dw_edma_chan *chan;
+
+ if (config)
+ return config;
+
+ chan = dchan2dw_edma_chan(dchan);
+
+ return &chan->config;
+}
+
static int dw_edma_device_pause(struct dma_chan *dchan)
{
struct dw_edma_chan *chan = dchan2dw_edma_chan(dchan);
@@ -385,7 +399,8 @@ dw_edma_device_tx_status(struct dma_chan *dchan, dma_cookie_t cookie,
}
static struct dma_async_tx_descriptor *
-dw_edma_device_transfer(struct dw_edma_transfer *xfer)
+dw_edma_device_transfer(struct dw_edma_transfer *xfer,
+ struct dma_slave_config *config)
{
struct dw_edma_chan *chan = dchan2dw_edma_chan(xfer->dchan);
enum dma_transfer_direction dir = xfer->direction;
@@ -472,8 +487,8 @@ dw_edma_device_transfer(struct dw_edma_transfer *xfer)
src_addr = xfer->xfer.il->src_start;
dst_addr = xfer->xfer.il->dst_start;
} else {
- src_addr = chan->config.src_addr;
- dst_addr = chan->config.dst_addr;
+ src_addr = config->src_addr;
+ dst_addr = config->dst_addr;
}
if (dir == DMA_DEV_TO_MEM)
@@ -595,7 +610,7 @@ dw_edma_device_prep_config_sg(struct dma_chan *dchan, struct scatterlist *sgl,
if (config && dw_edma_device_config(dchan, config))
return NULL;
- return dw_edma_device_transfer(&xfer);
+ return dw_edma_device_transfer(&xfer, dw_edma_device_get_config(dchan, config));
}
static struct dma_async_tx_descriptor *
@@ -614,7 +629,7 @@ dw_edma_device_prep_dma_cyclic(struct dma_chan *dchan, dma_addr_t paddr,
xfer.flags = flags;
xfer.type = EDMA_XFER_CYCLIC;
- return dw_edma_device_transfer(&xfer);
+ return dw_edma_device_transfer(&xfer, dw_edma_device_get_config(dchan, NULL));
}
static struct dma_async_tx_descriptor *
@@ -630,7 +645,7 @@ dw_edma_device_prep_interleaved_dma(struct dma_chan *dchan,
xfer.flags = flags;
xfer.type = EDMA_XFER_INTERLEAVED;
- return dw_edma_device_transfer(&xfer);
+ return dw_edma_device_transfer(&xfer, dw_edma_device_get_config(dchan, NULL));
}
static void dw_hdma_set_callback_result(struct virt_dma_desc *vd,
--
2.43.0
^ permalink raw reply related
* [PATCH v6 4/9] dmaengine: dw-edma: Use new .device_prep_config_sg() callback
From: Frank.Li @ 2026-05-20 22:00 UTC (permalink / raw)
To: Vinod Koul, Manivannan Sadhasivam, Krzysztof Wilczyński,
Kishon Vijay Abraham I, Bjorn Helgaas, Christoph Hellwig,
Sagi Grimberg, Chaitanya Kulkarni, Herbert Xu, David S. Miller,
Nicolas Ferre, Alexandre Belloni, Claudiu Beznea, Koichiro Den,
Niklas Cassel
Cc: dmaengine, linux-kernel, linux-pci, linux-nvme, mhi,
linux-arm-msm, linux-crypto, linux-arm-kernel, imx, Frank Li,
Damien Le Moal
In-Reply-To: <20260520-dma_prep_config-v6-0-06e49b7acb38@nxp.com>
From: Frank Li <Frank.Li@nxp.com>
Use the new .device_prep_config_sg() callback to combine configuration and
descriptor preparation.
No functional changes.
Tested-by: Niklas Cassel <cassel@kernel.org>
Reviewed-by: Damien Le Moal <dlemoal@kernel.org>
Reviewed-by: Manivannan Sadhasivam <mani@kernel.org>
Signed-off-by: Frank Li <Frank.Li@nxp.com>
---
change in v6
- check dw_edma_device_config() return value; find by sashiko AI.
change in v4
- drop context in callback.
change in v3
- add Damien Le Moal review tag
---
drivers/dma/dw-edma/dw-edma-core.c | 14 +++++++++-----
1 file changed, 9 insertions(+), 5 deletions(-)
diff --git a/drivers/dma/dw-edma/dw-edma-core.c b/drivers/dma/dw-edma/dw-edma-core.c
index c2feb3adc79fa..92572dd8131e6 100644
--- a/drivers/dma/dw-edma/dw-edma-core.c
+++ b/drivers/dma/dw-edma/dw-edma-core.c
@@ -577,10 +577,11 @@ dw_edma_device_transfer(struct dw_edma_transfer *xfer)
}
static struct dma_async_tx_descriptor *
-dw_edma_device_prep_slave_sg(struct dma_chan *dchan, struct scatterlist *sgl,
- unsigned int len,
- enum dma_transfer_direction direction,
- unsigned long flags, void *context)
+dw_edma_device_prep_config_sg(struct dma_chan *dchan, struct scatterlist *sgl,
+ unsigned int len,
+ enum dma_transfer_direction direction,
+ unsigned long flags,
+ struct dma_slave_config *config)
{
struct dw_edma_transfer xfer;
@@ -591,6 +592,9 @@ dw_edma_device_prep_slave_sg(struct dma_chan *dchan, struct scatterlist *sgl,
xfer.flags = flags;
xfer.type = EDMA_XFER_SCATTER_GATHER;
+ if (config && dw_edma_device_config(dchan, config))
+ return NULL;
+
return dw_edma_device_transfer(&xfer);
}
@@ -970,7 +974,7 @@ static int dw_edma_channel_setup(struct dw_edma *dw, u32 wr_alloc, u32 rd_alloc)
dma->device_terminate_all = dw_edma_device_terminate_all;
dma->device_issue_pending = dw_edma_device_issue_pending;
dma->device_tx_status = dw_edma_device_tx_status;
- dma->device_prep_slave_sg = dw_edma_device_prep_slave_sg;
+ dma->device_prep_config_sg = dw_edma_device_prep_config_sg;
dma->device_prep_dma_cyclic = dw_edma_device_prep_dma_cyclic;
dma->device_prep_interleaved_dma = dw_edma_device_prep_interleaved_dma;
--
2.43.0
^ permalink raw reply related
* [PATCH v6 3/9] PCI: endpoint: pci-epf-test: Use dmaenigne_prep_config_single() to simplify code
From: Frank.Li @ 2026-05-20 22:00 UTC (permalink / raw)
To: Vinod Koul, Manivannan Sadhasivam, Krzysztof Wilczyński,
Kishon Vijay Abraham I, Bjorn Helgaas, Christoph Hellwig,
Sagi Grimberg, Chaitanya Kulkarni, Herbert Xu, David S. Miller,
Nicolas Ferre, Alexandre Belloni, Claudiu Beznea, Koichiro Den,
Niklas Cassel
Cc: dmaengine, linux-kernel, linux-pci, linux-nvme, mhi,
linux-arm-msm, linux-crypto, linux-arm-kernel, imx, Frank Li,
Damien Le Moal
In-Reply-To: <20260520-dma_prep_config-v6-0-06e49b7acb38@nxp.com>
From: Frank Li <Frank.Li@nxp.com>
Use dmaenigne_prep_config_single() to simplify code.
No functional change.
Tested-by: Niklas Cassel <cassel@kernel.org>
Reviewed-by: Damien Le Moal <dlemoal@kernel.org>
Acked-by: Manivannan Sadhasivam <mani@kernel.org>
Signed-off-by: Frank Li <Frank.Li@nxp.com>
---
change in v3
- add Damien Le Moal review tag
---
drivers/pci/endpoint/functions/pci-epf-test.c | 8 ++------
1 file changed, 2 insertions(+), 6 deletions(-)
diff --git a/drivers/pci/endpoint/functions/pci-epf-test.c b/drivers/pci/endpoint/functions/pci-epf-test.c
index 591d301fa89d8..0f5cf2d795108 100644
--- a/drivers/pci/endpoint/functions/pci-epf-test.c
+++ b/drivers/pci/endpoint/functions/pci-epf-test.c
@@ -182,12 +182,8 @@ static int pci_epf_test_data_transfer(struct pci_epf_test *epf_test,
else
sconf.src_addr = dma_remote;
- if (dmaengine_slave_config(chan, &sconf)) {
- dev_err(dev, "DMA slave config fail\n");
- return -EIO;
- }
- tx = dmaengine_prep_slave_single(chan, dma_local, len, dir,
- flags);
+ tx = dmaengine_prep_config_single(chan, dma_local, len,
+ dir, flags, &sconf);
} else {
tx = dmaengine_prep_dma_memcpy(chan, dma_dst, dma_src, len,
flags);
--
2.43.0
^ permalink raw reply related
* [PATCH v6 2/9] dmaengine: Add safe API to combine configuration and preparation
From: Frank.Li @ 2026-05-20 22:00 UTC (permalink / raw)
To: Vinod Koul, Manivannan Sadhasivam, Krzysztof Wilczyński,
Kishon Vijay Abraham I, Bjorn Helgaas, Christoph Hellwig,
Sagi Grimberg, Chaitanya Kulkarni, Herbert Xu, David S. Miller,
Nicolas Ferre, Alexandre Belloni, Claudiu Beznea, Koichiro Den,
Niklas Cassel
Cc: dmaengine, linux-kernel, linux-pci, linux-nvme, mhi,
linux-arm-msm, linux-crypto, linux-arm-kernel, imx, Frank Li
In-Reply-To: <20260520-dma_prep_config-v6-0-06e49b7acb38@nxp.com>
From: Frank Li <Frank.Li@nxp.com>
Introduce dmaengine_prep_config_single_safe() and
dmaengine_prep_config_sg_safe() to provide a reentrant-safe way to
combine slave configuration and transfer preparation.
Drivers may implement the new device_prep_config_sg() callback to perform
both steps atomically. If the callback is not provided, the helpers fall
back to calling dmaengine_slave_config() followed by
dmaengine_prep_slave_sg() under per-channel spinlock protection.
Tested-by: Niklas Cassel <cassel@kernel.org>
Signed-off-by: Frank Li <Frank.Li@nxp.com>
---
change in v6
- replace mutex with spinlock in commit message
- use spinlock_saveirq according to AI review results
"The documentation in struct dma_chan notes that *_prep() may be called
from a completion callback. Since completion callbacks often execute in
softirq or hardirq contexts, if a thread calls this function from
process context, local interrupts remain enabled.
If a DMA interrupt fires on the same CPU while the lock is held, the
completion callback could attempt to call this function again to queue
the next transfer, leading it to wait on the already-held chan->lock.
Does this fallback path need to use spin_lock_irqsave() and
spin_unlock_irqrestore() to safely disable interrupts?
"
chagne in v5
- remove reduntant lock commments.
- use kernel doc to descritp API
chagne in v4
- use spinlock() to protect config() and prep()
change in v3
- new patch
---
drivers/dma/dmaengine.c | 2 ++
include/linux/dmaengine.h | 86 +++++++++++++++++++++++++++++++++++++++++++++++
2 files changed, 88 insertions(+)
diff --git a/drivers/dma/dmaengine.c b/drivers/dma/dmaengine.c
index 405bd2fbb4a3b..ba29e60160c1a 100644
--- a/drivers/dma/dmaengine.c
+++ b/drivers/dma/dmaengine.c
@@ -1099,6 +1099,8 @@ static int __dma_async_device_channel_register(struct dma_device *device,
chan->dev->device.parent = device->dev;
chan->dev->chan = chan;
chan->dev->dev_id = device->dev_id;
+ spin_lock_init(&chan->lock);
+
if (!name)
dev_set_name(&chan->dev->device, "dma%dchan%d", device->dev_id, chan->chan_id);
else
diff --git a/include/linux/dmaengine.h b/include/linux/dmaengine.h
index defa377d2ef54..6fe46c0c94527 100644
--- a/include/linux/dmaengine.h
+++ b/include/linux/dmaengine.h
@@ -322,6 +322,8 @@ struct dma_router {
* @slave: ptr to the device using this channel
* @cookie: last cookie value returned to client
* @completed_cookie: last completed cookie for this channel
+ * @lock: protect between config and prepare transfer when driver have not
+ * implemented callback device_prep_config_sg().
* @chan_id: channel ID for sysfs
* @dev: class device for sysfs
* @name: backlink name for sysfs
@@ -341,6 +343,12 @@ struct dma_chan {
dma_cookie_t cookie;
dma_cookie_t completed_cookie;
+ /*
+ * protect between config and prepare transfer because *_prep() may be
+ * called from complete callback, which is in GFP_NOSLEEP context.
+ */
+ spinlock_t lock;
+
/* sysfs */
int chan_id;
struct dma_chan_dev *dev;
@@ -1068,6 +1076,84 @@ dmaengine_prep_slave_sg(struct dma_chan *chan, struct scatterlist *sgl,
return dmaengine_prep_config_sg(chan, sgl, sg_len, dir, flags, NULL);
}
+/**
+ * dmaengine_prep_config_sg_safe - prepare a scatter-gather DMA transfer
+ * with atomic slave configuration update
+ * @chan: DMA channel
+ * @sgl: scatterlist for the transfer
+ * @sg_len: number of entries in @sgl
+ * @dir: DMA transfer direction
+ * @flags: transfer preparation flags
+ * @config: DMA slave configuration for this transfer
+ *
+ * Prepare a DMA scatter-gather transfer together with a corresponding slave
+ * configuration update in a re-entrant and race-safe manner.
+ *
+ * DMA engine drivers may implement the optional
+ * device_prep_config_sg() callback to perform both the slave configuration
+ * and descriptor preparation atomically. In this case, the operation is
+ * fully handled by the DMA engine driver.
+ *
+ * If the DMA engine driver does not implement device_prep_config_sg(), falls
+ * back to calling dmaengine_slave_config() followed by dmaengine_prep_slave_sg().
+ * The fallback path is protected by a per-channel spinlock to ensure that
+ * concurrent callers cannot interleave configuration and descriptor preparation
+ * on the same DMA channel.
+ *
+ * Return: Pointer to a prepared DMA async transaction descriptor on success,
+ * or %NULL if the transfer could not be prepared.
+ */
+static inline struct dma_async_tx_descriptor *
+dmaengine_prep_config_sg_safe(struct dma_chan *chan, struct scatterlist *sgl,
+ unsigned int sg_len,
+ enum dma_transfer_direction dir,
+ unsigned long flags,
+ struct dma_slave_config *config)
+{
+ struct dma_async_tx_descriptor *tx;
+ unsigned long spinlock_flags;
+
+ if (!chan || !chan->device)
+ return NULL;
+
+ if (!chan->device->device_prep_config_sg)
+ spin_lock_irqsave(&chan->lock, spinlock_flags);
+
+ tx = dmaengine_prep_config_sg(chan, sgl, sg_len, dir, flags, config);
+
+ if (!chan->device->device_prep_config_sg)
+ spin_unlock_irqrestore(&chan->lock, spinlock_flags);
+
+ return tx;
+}
+
+/**
+ * dmaengine_prep_config_single_safe - prepare a single-buffer DMA transfer
+ * with atomic slave configuration update
+ * @chan: DMA channel
+ * @buf: DMA buffer address
+ * @len: length of the transfer in bytes
+ * @dir: DMA transfer direction
+ * @flags: transfer preparation flags
+ * @config: DMA slave configuration for this transfer
+ *
+ * Detail see dmaengine_prep_config_sg_safe().
+ */
+static inline struct dma_async_tx_descriptor *
+dmaengine_prep_config_single_safe(struct dma_chan *chan, dma_addr_t buf,
+ size_t len, enum dma_transfer_direction dir,
+ unsigned long flags,
+ struct dma_slave_config *config)
+{
+ struct scatterlist sg;
+
+ sg_init_table(&sg, 1);
+ sg_dma_address(&sg) = buf;
+ sg_dma_len(&sg) = len;
+
+ return dmaengine_prep_config_sg_safe(chan, &sg, 1, dir, flags, config);
+}
+
#ifdef CONFIG_RAPIDIO_DMA_ENGINE
struct rio_dma_ext;
static inline struct dma_async_tx_descriptor *dmaengine_prep_rio_sg(
--
2.43.0
^ permalink raw reply related
* [PATCH v6 1/9] dmaengine: Add API to combine configuration and preparation (sg and single)
From: Frank.Li @ 2026-05-20 22:00 UTC (permalink / raw)
To: Vinod Koul, Manivannan Sadhasivam, Krzysztof Wilczyński,
Kishon Vijay Abraham I, Bjorn Helgaas, Christoph Hellwig,
Sagi Grimberg, Chaitanya Kulkarni, Herbert Xu, David S. Miller,
Nicolas Ferre, Alexandre Belloni, Claudiu Beznea, Koichiro Den,
Niklas Cassel
Cc: dmaengine, linux-kernel, linux-pci, linux-nvme, mhi,
linux-arm-msm, linux-crypto, linux-arm-kernel, imx, Frank Li
In-Reply-To: <20260520-dma_prep_config-v6-0-06e49b7acb38@nxp.com>
From: Frank Li <Frank.Li@nxp.com>
Previously, configuration and preparation required two separate calls. This
works well when configuration is done only once during initialization.
However, in cases where the burst length or source/destination address must
be adjusted for each transfer, calling two functions is verbose and
requires additional locking to ensure both steps complete atomically.
Add a new API dmaengine_prep_config_single() and dmaengine_prep_config_sg()
and callback device_prep_config_sg() that combines configuration and
preparation into a single operation. If the configuration argument is
passed as NULL, fall back to the existing implementation.
Tested-by: Niklas Cassel <cassel@kernel.org>
Acked-by: Manivannan Sadhasivam <mani@kernel.org>
Signed-off-by: Frank Li <Frank.Li@nxp.com>
---
change in v4
- drop context in device_prep_config_sg()
change in v3
- remove Deprecated for callback device_prep_slave_sg().
- Move condition check before sg init.
- split function at return type.
- move safe version to next patch
change in v2
- add () for function
- use short name device_prep_sg(), remove "slave" and "config". the 'slave'
is reduntant. after remove slave, the function name is difference existed
one, so remove _config suffix.
---
Documentation/driver-api/dmaengine/client.rst | 9 ++++
include/linux/dmaengine.h | 63 +++++++++++++++++++++++----
2 files changed, 64 insertions(+), 8 deletions(-)
diff --git a/Documentation/driver-api/dmaengine/client.rst b/Documentation/driver-api/dmaengine/client.rst
index d491e385d61a9..5ee5d4a3596dd 100644
--- a/Documentation/driver-api/dmaengine/client.rst
+++ b/Documentation/driver-api/dmaengine/client.rst
@@ -80,6 +80,10 @@ The details of these operations are:
- slave_sg: DMA a list of scatter gather buffers from/to a peripheral
+ - config_sg: Similar with slave_sg, just pass down dma_slave_config
+ struct to avoid calling dmaengine_slave_config() every time adjusting the
+ burst length or the FIFO address is needed.
+
- peripheral_dma_vec: DMA an array of scatter gather buffers from/to a
peripheral. Similar to slave_sg, but uses an array of dma_vec
structures instead of a scatterlist.
@@ -106,6 +110,11 @@ The details of these operations are:
unsigned int sg_len, enum dma_data_direction direction,
unsigned long flags);
+ struct dma_async_tx_descriptor *dmaengine_prep_config_sg(
+ struct dma_chan *chan, struct scatterlist *sgl,
+ unsigned int sg_len, enum dma_transfer_direction dir,
+ unsigned long flags, struct dma_slave_config *config);
+
struct dma_async_tx_descriptor *dmaengine_prep_peripheral_dma_vec(
struct dma_chan *chan, const struct dma_vec *vecs,
size_t nents, enum dma_data_direction direction,
diff --git a/include/linux/dmaengine.h b/include/linux/dmaengine.h
index b3d251c9734e9..defa377d2ef54 100644
--- a/include/linux/dmaengine.h
+++ b/include/linux/dmaengine.h
@@ -835,6 +835,7 @@ struct dma_filter {
* where the address and size of each segment is located in one entry of
* the dma_vec array.
* @device_prep_slave_sg: prepares a slave dma operation
+ * @device_prep_config_sg: prepares a slave DMA operation with dma_slave_config
* @device_prep_dma_cyclic: prepare a cyclic dma operation suitable for audio.
* The function takes a buffer of size buf_len. The callback function will
* be called after period_len bytes have been transferred.
@@ -934,6 +935,10 @@ struct dma_device {
struct dma_chan *chan, struct scatterlist *sgl,
unsigned int sg_len, enum dma_transfer_direction direction,
unsigned long flags, void *context);
+ struct dma_async_tx_descriptor *(*device_prep_config_sg)(
+ struct dma_chan *chan, struct scatterlist *sgl,
+ unsigned int sg_len, enum dma_transfer_direction direction,
+ unsigned long flags, struct dma_slave_config *config);
struct dma_async_tx_descriptor *(*device_prep_dma_cyclic)(
struct dma_chan *chan, dma_addr_t buf_addr, size_t buf_len,
size_t period_len, enum dma_transfer_direction direction,
@@ -974,22 +979,44 @@ static inline bool is_slave_direction(enum dma_transfer_direction direction)
(direction == DMA_DEV_TO_DEV);
}
-static inline struct dma_async_tx_descriptor *dmaengine_prep_slave_single(
- struct dma_chan *chan, dma_addr_t buf, size_t len,
- enum dma_transfer_direction dir, unsigned long flags)
+static inline struct dma_async_tx_descriptor *
+dmaengine_prep_config_single(struct dma_chan *chan, dma_addr_t buf, size_t len,
+ enum dma_transfer_direction dir,
+ unsigned long flags,
+ struct dma_slave_config *config)
{
struct scatterlist sg;
+
+ if (!chan || !chan->device)
+ return NULL;
+
sg_init_table(&sg, 1);
sg_dma_address(&sg) = buf;
sg_dma_len(&sg) = len;
- if (!chan || !chan->device || !chan->device->device_prep_slave_sg)
+ if (chan->device->device_prep_config_sg)
+ return chan->device->device_prep_config_sg(chan, &sg, 1, dir,
+ flags, config);
+
+ if (config)
+ if (dmaengine_slave_config(chan, config))
+ return NULL;
+
+ if (!chan->device->device_prep_slave_sg)
return NULL;
return chan->device->device_prep_slave_sg(chan, &sg, 1,
dir, flags, NULL);
}
+static inline struct dma_async_tx_descriptor *
+dmaengine_prep_slave_single(struct dma_chan *chan, dma_addr_t buf, size_t len,
+ enum dma_transfer_direction dir,
+ unsigned long flags)
+{
+ return dmaengine_prep_config_single(chan, buf, len, dir, flags, NULL);
+}
+
/**
* dmaengine_prep_peripheral_dma_vec() - Prepare a DMA scatter-gather descriptor
* @chan: The channel to be used for this descriptor
@@ -1010,17 +1037,37 @@ static inline struct dma_async_tx_descriptor *dmaengine_prep_peripheral_dma_vec(
dir, flags);
}
-static inline struct dma_async_tx_descriptor *dmaengine_prep_slave_sg(
- struct dma_chan *chan, struct scatterlist *sgl, unsigned int sg_len,
- enum dma_transfer_direction dir, unsigned long flags)
+static inline struct dma_async_tx_descriptor *
+dmaengine_prep_config_sg(struct dma_chan *chan, struct scatterlist *sgl,
+ unsigned int sg_len, enum dma_transfer_direction dir,
+ unsigned long flags, struct dma_slave_config *config)
{
- if (!chan || !chan->device || !chan->device->device_prep_slave_sg)
+ if (!chan || !chan->device)
+ return NULL;
+
+ if (chan->device->device_prep_config_sg)
+ return chan->device->device_prep_config_sg(chan, sgl, sg_len,
+ dir, flags, config);
+
+ if (config)
+ if (dmaengine_slave_config(chan, config))
+ return NULL;
+
+ if (!chan->device->device_prep_slave_sg)
return NULL;
return chan->device->device_prep_slave_sg(chan, sgl, sg_len,
dir, flags, NULL);
}
+static inline struct dma_async_tx_descriptor *
+dmaengine_prep_slave_sg(struct dma_chan *chan, struct scatterlist *sgl,
+ unsigned int sg_len, enum dma_transfer_direction dir,
+ unsigned long flags)
+{
+ return dmaengine_prep_config_sg(chan, sgl, sg_len, dir, flags, NULL);
+}
+
#ifdef CONFIG_RAPIDIO_DMA_ENGINE
struct rio_dma_ext;
static inline struct dma_async_tx_descriptor *dmaengine_prep_rio_sg(
--
2.43.0
^ permalink raw reply related
* [PATCH v6 0/9] dmaengine: Add new API to combine configuration and descriptor preparation
From: Frank.Li @ 2026-05-20 22:00 UTC (permalink / raw)
To: Vinod Koul, Manivannan Sadhasivam, Krzysztof Wilczyński,
Kishon Vijay Abraham I, Bjorn Helgaas, Christoph Hellwig,
Sagi Grimberg, Chaitanya Kulkarni, Herbert Xu, David S. Miller,
Nicolas Ferre, Alexandre Belloni, Claudiu Beznea, Koichiro Den,
Niklas Cassel
Cc: dmaengine, linux-kernel, linux-pci, linux-nvme, mhi,
linux-arm-msm, linux-crypto, linux-arm-kernel, imx, Frank Li,
Damien Le Moal
Previously, configuration and preparation required two separate calls. This
works well when configuration is done only once during initialization.
However, in cases where the burst length or source/destination address must
be adjusted for each transfer, calling two functions is verbose.
if (dmaengine_slave_config(chan, &sconf)) {
dev_err(dev, "DMA slave config fail\n");
return -EIO;
}
tx = dmaengine_prep_slave_single(chan, dma_local, len, dir, flags);
After new API added
tx = dmaengine_prep_config_single(chan, dma_local, len, dir, flags, &sconf);
Additional, prevous two calls requires additional locking to ensure both
steps complete atomically.
mutex_lock()
dmaengine_slave_config()
dmaengine_prep_slave_single()
mutex_unlock()
after new API added, mutex lock can be moved. See patch
nvmet: pci-epf: Use dmaengine_prep_config_single_safe() API
Signed-off-by: Frank Li <Frank.Li@nxp.com>
---
Changes in v6:
- Fix sashaki AI report problem, detail see each patch's change log
- Link to v5: https://lore.kernel.org/r/20260512-dma_prep_config-v5-0-26865bf7d935@nxp.com
Changes in v5:
- collect Mani's reviewed-by tags
- use kernel doc for new APIs.
- Link to v4: https://lore.kernel.org/r/20260506-dma_prep_config-v4-0-85b3d22babff@nxp.com
Changes in v4:
- remove void* context in config_prep() callback
- use spin lock to protect config() and prep().
- Link to v3: https://lore.kernel.org/r/20260105-dma_prep_config-v3-0-a8480362fd42@nxp.com
Changes in v3:
- collect review tags
- create safe version in framework
- Link to v2: https://lore.kernel.org/r/20251218-dma_prep_config-v2-0-c07079836128@nxp.com
Changes in v2:
- Use name dmaengine_prep_config_single() and dmaengine_prep_config_sg()
- Add _safe version to avoid confuse, which needn't additional mutex.
- Update document/
- Update commit message. add () for function name. Use upcase for subject.
- Add more explain for remove lock.
- Link to v1: https://lore.kernel.org/r/20251208-dma_prep_config-v1-0-53490c5e1e2a@nxp.com
---
Frank Li (9):
dmaengine: Add API to combine configuration and preparation (sg and single)
dmaengine: Add safe API to combine configuration and preparation
PCI: endpoint: pci-epf-test: Use dmaenigne_prep_config_single() to simplify code
dmaengine: dw-edma: Use new .device_prep_config_sg() callback
dmaengine: dw-edma: Pass dma_slave_config to dw_edma_device_transfer()
nvmet: pci-epf: Remove unnecessary dmaengine_terminate_sync() on each DMA transfer
nvmet: pci-epf: Use dmaengine_prep_config_single_safe() API
PCI: epf-mhi: Use dmaengine_prep_config_single() to simplify code
crypto: atmel: Use dmaengine_prep_config_sg() API
Documentation/driver-api/dmaengine/client.rst | 9 ++
drivers/crypto/atmel-aes.c | 10 +-
drivers/dma/dmaengine.c | 2 +
drivers/dma/dw-edma/dw-edma-core.c | 41 +++++--
drivers/nvme/target/pci-epf.c | 24 +----
drivers/pci/endpoint/functions/pci-epf-mhi.c | 52 +++------
drivers/pci/endpoint/functions/pci-epf-test.c | 8 +-
include/linux/dmaengine.h | 149 ++++++++++++++++++++++++--
8 files changed, 208 insertions(+), 87 deletions(-)
---
base-commit: 254f49634ee16a731174d2ae34bc50bd5f45e731
change-id: 20251204-dma_prep_config-654170d245a2
Best regards,
--
Frank Li <Frank.Li@nxp.com>
^ permalink raw reply
* Re: [PATCH v3] crypto/ccp: Introduce SNP_VERIFY_MITIGATION command
From: Tom Lendacky @ 2026-05-20 20:22 UTC (permalink / raw)
To: Pratik R. Sampat, ashish.kalra, john.allen, herbert, davem
Cc: linux-crypto, linux-kernel, aik, tycho, nikunj, michael.roth
In-Reply-To: <36137b565d183fa2f2985ad098f2e2096f1c432f.1779219958.git.prsampat@amd.com>
On 5/19/26 14:50, Pratik R. Sampat wrote:
> The SEV-SNP firmware provides the SNP_VERIFY_MITIGATION command, which
> can be used to query the status of currently supported vulnerability
> mitigations and to initiate mitigations within the firmware.
>
> This command is an explicit mechanism to ascertain if a firmware
> mitigation is applied without needing a full RMP re-build, which is most
> useful in a live firmware update scenario.
>
> The firmware supports two subcommands: STATUS and VERIFY. The STATUS
> subcommand is used to query the supported and verified mitigation bits.
> The VERIFY subcommand initiates the mitigation process within the FW for
> the specified vulnerability. Expose a userspace interface under:
> /sys/firmware/sev/vulnerabilities/
> - supported_mitigations (read-only): supported mitigation vector mask
> - verified_mitigations (read/write): current verified mask; write a
> vector to request VERIFY for that bit
>
> The behavior of SNP_VERIFY_MITIGATION and the pre-requisites for using
> it are bug-specific. Information about supported mitigations and its
> corresponding vector is to be published as part of the AMD Security
> Bulletin.
>
> See SEV-SNP Firmware ABI specifications 1.58, SNP_VERIFY_MITIGATION for
> more details.
>
> Signed-off-by: Pratik R. Sampat <prsampat@amd.com>
> ---
> .../sysfs-firmware-sev-vulnerabilities | 17 ++
> drivers/crypto/ccp/sev-dev.c | 172 ++++++++++++++++++
> drivers/crypto/ccp/sev-dev.h | 3 +
> include/linux/psp-sev.h | 51 ++++++
> 4 files changed, 243 insertions(+)
> create mode 100644 Documentation/ABI/testing/sysfs-firmware-sev-vulnerabilities
>
> diff --git a/Documentation/ABI/testing/sysfs-firmware-sev-vulnerabilities b/Documentation/ABI/testing/sysfs-firmware-sev-vulnerabilities
> new file mode 100644
> index 000000000000..cc84adbac3c0
> --- /dev/null
> +++ b/Documentation/ABI/testing/sysfs-firmware-sev-vulnerabilities
> @@ -0,0 +1,17 @@
> +What: /sys/firmware/sev/vulnerabilities/
> + /sys/firmware/sev/vulnerabilities/supported_mitigations
> + /sys/firmware/sev/vulnerabilities/verified_mitigations
> +Date: May 2026
> +Contact: linux-crypto@vger.kernel.org
> +Description: Information about SEV-SNP firmware vulnerability mitigations.
> + supported_mitigations: Read-only interface that reports
> + the vector of mitigations supported by
> + the firmware.
> + verified_mitigations: Read/write interface that reports
> + the vector of mitigations already verified
> + by the firmware. Writing a vector value
> + requests the firmware to VERIFY the
> + corresponding mitigation bit(s).
> + The list of supported mitigations and the meaning of each
> + vector bit are both platform- and bug-specific and are
> + published as part of the AMD Security Bulletin.
> diff --git a/drivers/crypto/ccp/sev-dev.c b/drivers/crypto/ccp/sev-dev.c
> index d1e9e0ac63b6..eec4864c6597 100644
> --- a/drivers/crypto/ccp/sev-dev.c
> +++ b/drivers/crypto/ccp/sev-dev.c
> @@ -57,6 +57,7 @@
> #define CMD_BUF_DESC_MAX (CMD_BUF_FW_WRITABLE_MAX + 1)
>
> static DEFINE_MUTEX(sev_cmd_mutex);
> +static DEFINE_MUTEX(sev_mit_sysfs_mutex);
> static struct sev_misc_dev *misc_dev;
>
> static int psp_cmd_timeout = 100;
> @@ -245,6 +246,7 @@ static int sev_cmd_buffer_len(int cmd)
> case SEV_CMD_SNP_LAUNCH_FINISH: return sizeof(struct sev_data_snp_launch_finish);
> case SEV_CMD_SNP_DBG_DECRYPT: return sizeof(struct sev_data_snp_dbg);
> case SEV_CMD_SNP_DBG_ENCRYPT: return sizeof(struct sev_data_snp_dbg);
> + case SEV_CMD_SNP_VERIFY_MITIGATION: return sizeof(struct sev_data_snp_verify_mitigation);
> case SEV_CMD_SNP_PAGE_UNSMASH: return sizeof(struct sev_data_snp_page_unsmash);
> case SEV_CMD_SNP_PLATFORM_STATUS: return sizeof(struct sev_data_snp_addr);
> case SEV_CMD_SNP_GUEST_REQUEST: return sizeof(struct sev_data_snp_guest_request);
> @@ -1351,6 +1353,162 @@ static int snp_filter_reserved_mem_regions(struct resource *rs, void *arg)
> return 0;
> }
>
> +static int snp_verify_mitigation(u16 command, u64 vector,
> + struct sev_data_snp_verify_mitigation_dst *dst)
> +{
> + struct sev_data_snp_verify_mitigation_dst *mit_dst = NULL;
> + struct sev_data_snp_verify_mitigation data = {0};
> + struct sev_device *sev = psp_master->sev_data;
> + int ret, error = 0;
> +
> + mit_dst = snp_alloc_firmware_page(GFP_KERNEL | __GFP_ZERO);
> + if (!mit_dst)
> + return -ENOMEM;
> +
> + data.length = sizeof(data);
> + data.subcommand = command;
> + data.vector = vector;
> + data.dst_paddr = __psp_pa(mit_dst);
> + data.dst_paddr_en = true;
> +
> + ret = sev_do_cmd(SEV_CMD_SNP_VERIFY_MITIGATION, &data, &error);
> + if (!ret)
> + memcpy(dst, mit_dst, sizeof(*mit_dst));
> + else
> + dev_err(sev->dev, "SNP_VERIFY_MITIGATION command failed, ret = %d, error = %#x\n",
> + ret, error);
> +
> + snp_free_firmware_page(mit_dst);
> +
> + return ret;
> +}
Should this function also be under the CONFIG_SYSFS #ifdef? Won't you get
an unused function warning if CONFIG_SYSFS isn't defined?
> +
> +#ifdef CONFIG_SYSFS
> +static ssize_t supported_mitigations_show(struct kobject *kobj,
> + struct kobj_attribute *attr, char *buf)
> +{
> + struct sev_data_snp_verify_mitigation_dst dst;
> + int ret;
> +
> + ret = snp_verify_mitigation(SNP_MIT_SUBCMD_REQ_STATUS, 0, &dst);
> + if (ret)
> + return ret;
> +
> + return sysfs_emit(buf, "0x%llx\n", dst.mit_supported_vector);
> +}
> +
> +static struct kobj_attribute supported_attr =
> + __ATTR_RO_MODE(supported_mitigations, 0400);
> +
> +static ssize_t verified_mitigations_show(struct kobject *kobj,
> + struct kobj_attribute *attr, char *buf)
> +{
> + struct sev_data_snp_verify_mitigation_dst dst;
> + int ret;
> +
> + ret = snp_verify_mitigation(SNP_MIT_SUBCMD_REQ_STATUS, 0, &dst);
> + if (ret)
> + return ret;
> +
> + return sysfs_emit(buf, "0x%llx\n", dst.mit_verified_vector);
> +}
> +
> +static ssize_t verified_mitigations_store(struct kobject *kobj,
> + struct kobj_attribute *attr,
> + const char *buf, size_t count)
> +{
> + struct sev_data_snp_verify_mitigation_dst dst;
> + struct sev_device *sev = psp_master->sev_data;
> + u64 vector;
> + int ret;
> +
> + ret = kstrtoull(buf, 0, &vector);
> + if (ret)
> + return ret;
> +
> + ret = snp_verify_mitigation(SNP_MIT_SUBCMD_REQ_VERIFY, vector, &dst);
> + if (ret)
> + return ret;
> +
> + if (dst.mit_failure_status) {
> + dev_err(sev->dev, "Verify Mitigation - failure status: 0x%x\n",
> + dst.mit_failure_status);
> + return -EIO;
> + }
> +
> + return count;
> +}
> +
> +static struct kobj_attribute verified_attr =
> + __ATTR_RW_MODE(verified_mitigations, 0600);
> +
> +static struct attribute *mitigation_attrs[] = {
> + &supported_attr.attr,
> + &verified_attr.attr,
> + NULL
> +};
> +
> +static const struct attribute_group mit_attr_group = {
> + .attrs = mitigation_attrs,
> +};
> +
> +static void sev_snp_register_verify_mitigation(struct sev_device *sev)
> +{
> + int rc;
> +
> + if (!sev->snp_initialized || !sev->snp_plat_status.feature_info ||
> + !(sev->snp_feat_info_0.ecx & SNP_VERIFY_MITIGATION_SUPPORTED))
> + return;
> +
> + guard(mutex)(&sev_mit_sysfs_mutex);
> +
> + if (sev->verify_mit)
> + return;
> +
> + if (!sev->sev_kobj) {
> + sev->sev_kobj = kobject_create_and_add("sev", firmware_kobj);
> + if (!sev->sev_kobj)
> + return;
> + }
> +
> + sev->verify_mit = kobject_create_and_add("vulnerabilities", sev->sev_kobj);
> + if (!sev->verify_mit)
> + goto err_sev_kobj;
> +
> + rc = sysfs_create_group(sev->verify_mit, &mit_attr_group);
> + if (rc)
> + goto err_verify_mit;
> +
> + return;
> +
> +err_verify_mit:
> + kobject_put(sev->verify_mit);
> + sev->verify_mit = NULL;
> +err_sev_kobj:
> + kobject_put(sev->sev_kobj);
> + sev->sev_kobj = NULL;
> +}
> +
> +static void sev_snp_unregister_verify_mitigation(struct sev_device *sev)
> +{
> + guard(mutex)(&sev_mit_sysfs_mutex);
> +
> + if (sev->verify_mit) {
> + sysfs_remove_group(sev->verify_mit, &mit_attr_group);
> + kobject_put(sev->verify_mit);
> + sev->verify_mit = NULL;
> + }
> +
> + if (sev->sev_kobj) {
> + kobject_put(sev->sev_kobj);
> + sev->sev_kobj = NULL;
> + }
> +}
> +#else
> +static void sev_snp_register_verify_mitigation(struct sev_device *sev) { }
> +static void sev_snp_unregister_verify_mitigation(struct sev_device *sev) { }
> +#endif
> +
> static int __sev_snp_init_locked(int *error, unsigned int max_snp_asid)
> {
> struct sev_data_range_list *snp_range_list __free(kfree) = NULL;
> @@ -1670,6 +1828,14 @@ int sev_platform_init(struct sev_platform_init_args *args)
> rc = _sev_platform_init_locked(args);
> mutex_unlock(&sev_cmd_mutex);
>
> + /*
> + * The shutdown + init path can race with in-flight _show()/_store() operations
> + * which acquire the sev_cmd_mutex. Register the sysfs interface outside
> + * the sev_cmd_mutex and serialize by sev_mit_sysfs_mutex instead.
I'm not quite sure I follow this. The shutdown and init path can't race
with each other, right? In which case this new mutex doesn't really matter
unless you take it on _show()/_short(), right?
Thanks,
Tom
> + */
> + if (!rc)
> + sev_snp_register_verify_mitigation(psp_master->sev_data);
> +
> return rc;
> }
> EXPORT_SYMBOL_GPL(sev_platform_init);
> @@ -2796,6 +2962,12 @@ static void sev_firmware_shutdown(struct sev_device *sev)
> if (sev->tio_status)
> sev_tsm_uninit(sev);
>
> + /*
> + * Concurrent access to the sysfs entry will call sev_do_cmd() for
> + * SNP_VERIFY_MITIGATION which locks the mutex and can cause a deadlock.
> + */
> + sev_snp_unregister_verify_mitigation(sev);
> +
> mutex_lock(&sev_cmd_mutex);
>
> __sev_firmware_shutdown(sev, false);
> diff --git a/drivers/crypto/ccp/sev-dev.h b/drivers/crypto/ccp/sev-dev.h
> index b1cd556bbbf6..d5e596606def 100644
> --- a/drivers/crypto/ccp/sev-dev.h
> +++ b/drivers/crypto/ccp/sev-dev.h
> @@ -59,6 +59,9 @@ struct sev_device {
>
> bool snp_initialized;
>
> + struct kobject *sev_kobj;
> + struct kobject *verify_mit;
> +
> struct sev_user_data_status sev_plat_status;
>
> struct sev_user_data_snp_status snp_plat_status;
> diff --git a/include/linux/psp-sev.h b/include/linux/psp-sev.h
> index d5099a2baca5..98666c5a6f79 100644
> --- a/include/linux/psp-sev.h
> +++ b/include/linux/psp-sev.h
> @@ -129,6 +129,7 @@ enum sev_cmd {
> SEV_CMD_SNP_LAUNCH_FINISH = 0x0A2,
> SEV_CMD_SNP_DBG_DECRYPT = 0x0B0,
> SEV_CMD_SNP_DBG_ENCRYPT = 0x0B1,
> + SEV_CMD_SNP_VERIFY_MITIGATION = 0x0B2,
> SEV_CMD_SNP_PAGE_SWAP_OUT = 0x0C0,
> SEV_CMD_SNP_PAGE_SWAP_IN = 0x0C1,
> SEV_CMD_SNP_PAGE_MOVE = 0x0C2,
> @@ -898,10 +899,60 @@ struct snp_feature_info {
> #define SNP_CIPHER_TEXT_HIDING_SUPPORTED BIT(3)
> #define SNP_AES_256_XTS_POLICY_SUPPORTED BIT(4)
> #define SNP_CXL_ALLOW_POLICY_SUPPORTED BIT(5)
> +#define SNP_VERIFY_MITIGATION_SUPPORTED BIT(13)
>
> /* Feature bits in EBX */
> #define SNP_SEV_TIO_SUPPORTED BIT(1)
>
> +#define SNP_MIT_SUBCMD_REQ_STATUS 0x0
> +#define SNP_MIT_SUBCMD_REQ_VERIFY 0x1
> +
> +/**
> + * struct sev_data_snp_verify_mitigation - SNP_VERIFY_MITIGATION command params
> + *
> + * @length: Length of the command buffer read by the PSP
> + * @subcommand: Mitigation sub-command for the firmware to execute.
> + * REQ_STATUS: 0x0 - Request status about currently supported and
> + * verified mitigations
> + * REQ_VERIFY: 0x1 - Request to initiate verification mitigation
> + * operation on a specific mitigation
> + * @rsvd: Reserved
> + * @vector: Bit specifying the vulnerability mitigation to process
> + * @dst_paddr_en: Destination paddr enabled
> + * @src_paddr_en: Source paddr enabled
> + * @rsvd1: Reserved
> + * @rsvd2: Reserved
> + * @src_paddr: Source address for optional input data
> + * @dst_paddr: Destination address to write the result
> + * @rsvd3: Reserved
> + */
> +struct sev_data_snp_verify_mitigation {
> + u32 length;
> + u16 subcommand;
> + u16 rsvd;
> + u64 vector;
> + u32 dst_paddr_en : 1,
> + src_paddr_en : 1,
> + rsvd1 : 30;
> + u8 rsvd2[4];
> + u64 src_paddr;
> + u64 dst_paddr;
> + u8 rsvd3[24];
> +} __packed;
> +
> +/**
> + * struct sev_data_snp_verify_mitigation_dst - mitigation result vectors
> + *
> + * @mit_verified_vector: Bit vector of vulnerability mitigations verified
> + * @mit_supported_vector: Bit vector of vulnerability mitigations supported
> + * @mit_failure_status: Status of the verification operation
> + */
> +struct sev_data_snp_verify_mitigation_dst {
> + u64 mit_verified_vector; /* OUT */
> + u64 mit_supported_vector; /* OUT */
> + u32 mit_failure_status; /* OUT */
> +} __packed;
> +
> #ifdef CONFIG_CRYPTO_DEV_SP_PSP
>
> /**
^ permalink raw reply
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