From: yebin <yebin@huaweicloud.com>
To: Ahmad Fatoum <a.fatoum@pengutronix.de>,
kernel@pengutronix.de, James.Bottomley@HansenPartnership.com,
jarkko@kernel.org, zohar@linux.ibm.com, dhowells@redhat.com,
paul@paul-moore.com, jmorris@namei.org, serge@hallyn.com,
linux-integrity@vger.kernel.org, keyrings@vger.kernel.org,
linux-security-module@vger.kernel.org, yebin10@huawei.com
Subject: Re: [PATCH] KEYS: fix compilation warnings in the dump_options() function
Date: Tue, 28 Oct 2025 10:39:54 +0800 [thread overview]
Message-ID: <69002CFA.2040701@huaweicloud.com> (raw)
In-Reply-To: <85aca6f9-f279-4977-8888-416af127edac@pengutronix.de>
On 2025/10/24 16:10, Ahmad Fatoum wrote:
> Hello,
>
> On 10/24/25 9:02 AM, yebin wrote:
>> Ignore this patch as 275a9a3f9b6a(“KEYS: trusted: Pass argument by
>> pointer in dump_options”)already fix this issue.
>
> What tree are you looking at? I can't find this commit in my git and the
> code you are purportedly patching never existed upstream.
>
> If you run into issues exclusive to a vendor fork, you need to submit
> your patches to the vendor. The upstream mailing lists are for upstream.
>
This patch was submitted by Herbert Xu and is on linux-next.
https://git.kernel.org/pub/scm/linux/kernel/git/herbert/cryptodev-2.6.git
commit 275a9a3f9b6a2158bfb7826074b72d5bdfb2ac35
Author: Herbert Xu <herbert@gondor.apana.org.au>
Date: Tue Oct 21 12:07:56 2025 +0800
KEYS: trusted: Pass argument by pointer in dump_options
Instead of passing pkey_info into dump_options by value, using a
pointer instead.
Reported-by: Stephen Rothwell <sfr@canb.auug.org.au>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
> Thanks,
> Ahmad
>
>>
>> On 2025/10/24 14:11, Ye Bin wrote:
>>> From: Ye Bin <yebin10@huawei.com>
>>>
>>> There's issue as follows:
>>> security/keys/trusted-keys/trusted_caam.c: In function ‘dump_options’:
>>> security/keys/trusted-keys/trusted_caam.c:37:20: note: the ABI of
>>> passing struct with a flexible array member has changed in GCC 4.4
>>> 37 | static inline void dump_options(struct caam_pkey_info pkey_info)
>>> | ^~~~~~~~~~~~
>>>
>>> To solve the above problem, pass 'struct caam_pkey_info*' type parameter
>>> to the dump_options() function.
>>>
>>> Fixes: 9eb25ca6c973 ("KEYS: trusted: caam based protected key")
>>> Signed-off-by: Ye Bin <yebin10@huawei.com>
>>> ---
>>> security/keys/trusted-keys/trusted_caam.c | 10 +++++-----
>>> 1 file changed, 5 insertions(+), 5 deletions(-)
>>>
>>> diff --git a/security/keys/trusted-keys/trusted_caam.c b/security/
>>> keys/trusted-keys/trusted_caam.c
>>> index 090099d1b04d..dd7a69bcf6a3 100644
>>> --- a/security/keys/trusted-keys/trusted_caam.c
>>> +++ b/security/keys/trusted-keys/trusted_caam.c
>>> @@ -29,12 +29,12 @@ static const match_table_t key_tokens = {
>>> };
>>>
>>> #ifdef CAAM_DEBUG
>>> -static inline void dump_options(struct caam_pkey_info pkey_info)
>>> +static inline void dump_options(struct caam_pkey_info *pkey_info)
>>> {
>>> - pr_info("key encryption algo %d\n", pkey_info.key_enc_algo);
>>> + pr_info("key encryption algo %d\n", pkey_info->key_enc_algo);
>>> }
>>> #else
>>> -static inline void dump_options(struct caam_pkey_info pkey_info)
>>> +static inline void dump_options(struct caam_pkey_info *pkey_info)
>>> {
>>> }
>>> #endif
>>> @@ -108,7 +108,7 @@ static int trusted_caam_seal(struct
>>> trusted_key_payload *p, char *datablob)
>>> ret = get_pkey_options(datablob, &info.pkey_info);
>>> if (ret < 0)
>>> return 0;
>>> - dump_options(info.pkey_info);
>>> + dump_options(&info.pkey_info);
>>> }
>>>
>>> ret = caam_encap_blob(blobifier, &info);
>>> @@ -140,7 +140,7 @@ static int trusted_caam_unseal(struct
>>> trusted_key_payload *p, char *datablob)
>>> ret = get_pkey_options(datablob, &info.pkey_info);
>>> if (ret < 0)
>>> return 0;
>>> - dump_options(info.pkey_info);
>>> + dump_options(&info.pkey_info);
>>>
>>> p->key_len = p->blob_len + sizeof(struct caam_pkey_info);
>>> memcpy(p->key, &info.pkey_info, sizeof(struct caam_pkey_info));
>>>
>>
>>
>
next prev parent reply other threads:[~2025-10-28 2:40 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-10-24 6:11 [PATCH] KEYS: fix compilation warnings in the dump_options() function Ye Bin
2025-10-24 7:02 ` yebin
2025-10-24 8:10 ` Ahmad Fatoum
2025-10-28 2:39 ` yebin [this message]
2025-10-28 7:03 ` Ahmad Fatoum
2025-10-27 20:04 ` Jarkko Sakkinen
2025-10-28 2:41 ` yebin
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=69002CFA.2040701@huaweicloud.com \
--to=yebin@huaweicloud.com \
--cc=James.Bottomley@HansenPartnership.com \
--cc=a.fatoum@pengutronix.de \
--cc=dhowells@redhat.com \
--cc=jarkko@kernel.org \
--cc=jmorris@namei.org \
--cc=kernel@pengutronix.de \
--cc=keyrings@vger.kernel.org \
--cc=linux-integrity@vger.kernel.org \
--cc=linux-security-module@vger.kernel.org \
--cc=paul@paul-moore.com \
--cc=serge@hallyn.com \
--cc=yebin10@huawei.com \
--cc=zohar@linux.ibm.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.