2c: 28 07 23 e9 ld r9,1832(r3)
30: 50 00 89 e9 ld r12,80(r9)
Where r3 is *chip.
r9 is NULL, and 80 = 0x50.
Looks like a NULL chip->ops, which oopses in:
static int tpm_request_locality(struct tpm_chip *chip)
{
int rc;
if (!chip->ops->request_locality)
Can you test the patch below?
cheers
2c: 28 07 23 e9 ld r9,1832(r3)
30: 50 00 89 e9 ld r12,80(r9)
Where r3 is *chip.
r9 is NULL, and 80 = 0x50.
Looks like a NULL chip->ops, which oopses in:
static int tpm_request_locality(struct tpm_chip *chip)
{
int rc;
if (!chip->ops->request_locality)
Can you test the patch below?
[CCing the regression list, as it should be in the loop for regressions:
https://docs.kernel.org/admin-guide/reporting-regressions.html]
[TLDR: I'm adding this report to the list of tracked Linux kernel
regressions; the text you find below is based on a few templates
paragraphs you might have encountered already in similar form.
See link in footer if these mails annoy you.]
On 14.06.23 17:12, Sachin Sant wrote:
Thanks for the report. To be sure the issue doesn't fall through the
cracks unnoticed, I'm adding it to regzbot, the Linux kernel regression
tracking bot:
#regzbot ^introduced bd8621ca1510e6e802df9855bdc35a04a3cfa932
#regzbot title tpm/ppc: crash during a kexec
#regzbot ignore-activity
This isn't a regression? This issue or a fix for it are already
discussed somewhere else? It was fixed already? You want to clarify when
the regression started to happen? Or point out I got the title or
something else totally wrong? Then just reply and tell me -- ideally
while also telling regzbot about it, as explained by the page listed in
the footer of this mail.
Developers: When fixing the issue, remember to add 'Link:' tags pointing
to the report (the parent of this mail). See page linked in footer for
details.
Ciao, Thorsten (wearing his 'the Linux kernel's regression tracker' hat)
--
Everything you wanna know about Linux kernel regression tracking:
https://linux-regtracking.leemhuis.info/about/#tldr
That page also explains what to do if mails like this annoy you.
From: Linux regression tracking (Thorsten Leemhuis) <hidden> Date: 2023-06-22 07:44:51
Hi, Thorsten here, the Linux kernel's regression tracker. Top-posting
for once, to make this easily accessible to everyone.
As Linus will likely release 6.4 on this or the following Sunday a quick
question: is there any hope this regression might be fixed any time
soon? Doesn't look like it, as it seems nothing happened for a few days,
but maybe I missed something.
Ciao, Thorsten (wearing his 'the Linux kernel's regression tracker' hat)
--
Everything you wanna know about Linux kernel regression tracking:
https://linux-regtracking.leemhuis.info/about/#tldr
If I did something stupid, please tell me, as explained on that page.
#regzbot poke
On 15.06.23 06:57, Sachin Sant wrote:
2c: 28 07 23 e9 ld r9,1832(r3)
30: 50 00 89 e9 ld r12,80(r9)
Where r3 is *chip.
r9 is NULL, and 80 = 0x50.
Looks like a NULL chip->ops, which oopses in:
static int tpm_request_locality(struct tpm_chip *chip)
{
int rc;
if (!chip->ops->request_locality)
Can you test the patch below?
Hi, Thorsten here, the Linux kernel's regression tracker. Top-posting
for once, to make this easily accessible to everyone.
As Linus will likely release 6.4 on this or the following Sunday a quick
question: is there any hope this regression might be fixed any time
soon?
No.
I have added the author of the commit to Cc, maybe they can help?
The immediate question is, is it expected for chip->ops to be NULL in
this path? Obviously on actual AMD systems that isn't the case,
otherwise the code would crash there. But is the fact that chip->ops is
NULL a bug in the ibmvtpm driver, or a possibility that has been
overlooked by the checking code.
cheers
Ciao, Thorsten (wearing his 'the Linux kernel's regression tracker' hat)
--
Everything you wanna know about Linux kernel regression tracking:
https://linux-regtracking.leemhuis.info/about/#tldr
If I did something stupid, please tell me, as explained on that page.
#regzbot poke
On 15.06.23 06:57, Sachin Sant wrote:
2c: 28 07 23 e9 ld r9,1832(r3)
30: 50 00 89 e9 ld r12,80(r9)
Where r3 is *chip.
r9 is NULL, and 80 = 0x50.
Looks like a NULL chip->ops, which oopses in:
static int tpm_request_locality(struct tpm_chip *chip)
{
int rc;
if (!chip->ops->request_locality)
Can you test the patch below?
Hi, Thorsten here, the Linux kernel's regression tracker. Top-posting
for once, to make this easily accessible to everyone.
As Linus will likely release 6.4 on this or the following Sunday a quick
question: is there any hope this regression might be fixed any time
soon?
No.
I have added the author of the commit to Cc, maybe they can help?
The immediate question is, is it expected for chip->ops to be NULL in
this path? Obviously on actual AMD systems that isn't the case,
otherwise the code would crash there. But is the fact that chip->ops is
NULL a bug in the ibmvtpm driver, or a possibility that has been
overlooked by the checking code.
cheers
All that code assumes that the TPM is still functional which
seems not to be the case for your TPM.
This should fix it:
*chip)
u64 version;
int ret;
+ if (!chip->ops)
+ return false;
+
if (!(chip->flags & TPM_CHIP_FLAG_TPM2))
return false;
quoted
Ciao, Thorsten (wearing his 'the Linux kernel's regression tracker' hat)
--
Everything you wanna know about Linux kernel regression tracking:
https://linux-regtracking.leemhuis.info/about/#tldr
If I did something stupid, please tell me, as explained on that page.
#regzbot poke
On 15.06.23 06:57, Sachin Sant wrote:
2c: 28 07 23 e9 ld r9,1832(r3)
30: 50 00 89 e9 ld r12,80(r9)
Where r3 is *chip.
r9 is NULL, and 80 = 0x50.
Looks like a NULL chip->ops, which oopses in:
static int tpm_request_locality(struct tpm_chip *chip)
{
int rc;
if (!chip->ops->request_locality)
Can you test the patch below?
Hi, Thorsten here, the Linux kernel's regression tracker. Top-posting
for once, to make this easily accessible to everyone.
As Linus will likely release 6.4 on this or the following Sunday a quick
question: is there any hope this regression might be fixed any time
soon?
No.
I have added the author of the commit to Cc, maybe they can help?
The immediate question is, is it expected for chip->ops to be NULL in
this path? Obviously on actual AMD systems that isn't the case,
otherwise the code would crash there. But is the fact that chip->ops is
NULL a bug in the ibmvtpm driver, or a possibility that has been
overlooked by the checking code.
cheers
All that code assumes that the TPM is still functional which
seems not to be the case for your TPM.
This should fix it:
Yes, with this change kexec works correctly.
Since Aneesh first reported this problem including reported by credit for him
Reported-by: Aneesh Kumar K. V <redacted>
Reported-by: Sachin Sant <redacted>
Tested-by: Sachin Sant <redacted>
-Sachin
Hi, Thorsten here, the Linux kernel's regression tracker. Top-posting
for once, to make this easily accessible to everyone.
As Linus will likely release 6.4 on this or the following Sunday a quick
question: is there any hope this regression might be fixed any time
soon?
No.
I have added the author of the commit to Cc, maybe they can help?
The immediate question is, is it expected for chip->ops to be NULL in
this path? Obviously on actual AMD systems that isn't the case,
otherwise the code would crash there. But is the fact that chip->ops is
NULL a bug in the ibmvtpm driver, or a possibility that has been
overlooked by the checking code.
cheers
All that code assumes that the TPM is still functional which
seems not to be the case for your TPM.
This should fix it:
*chip)
u64 version;
int ret;
+ if (!chip->ops)
+ return false;
+
if (!(chip->flags & TPM_CHIP_FLAG_TPM2))
return false;
Should tpm_amd_is_rng_defective compile to nothing on non-x86 architectures? This code is all about
working around an issue with the AMD fTPM, right?
Regards,
Jerry
-----Original Message-----
From: Jerry Snitselaar <redacted>
Sent: Thursday, June 29, 2023 12:07 PM
To: Limonciello, Mario <Mario.Limonciello@amd.com>
Cc: Michael Ellerman <mpe@ellerman.id.au>; Linux regressions mailing list
[off-list ref]; Sachin Sant [off-list ref]; open
list [off-list ref]; linuxppc-dev <linuxppc-
dev@lists.ozlabs.org>; jarkko@kernel.org; linux-integrity@vger.kernel.org
Subject: Re: [6.4-rc6] Crash during a kexec operation
(tpm_amd_is_rng_defective)
On Thu, Jun 22, 2023 at 09:38:04AM -0500, Limonciello, Mario wrote:
quoted
On 6/22/2023 7:36 AM, Michael Ellerman wrote:
quoted
"Linux regression tracking (Thorsten Leemhuis)"
[off-list ref] writes:
quoted
quoted
quoted
Hi, Thorsten here, the Linux kernel's regression tracker. Top-posting
for once, to make this easily accessible to everyone.
As Linus will likely release 6.4 on this or the following Sunday a quick
question: is there any hope this regression might be fixed any time
soon?
No.
I have added the author of the commit to Cc, maybe they can help?
The immediate question is, is it expected for chip->ops to be NULL in
this path? Obviously on actual AMD systems that isn't the case,
otherwise the code would crash there. But is the fact that chip->ops is
NULL a bug in the ibmvtpm driver, or a possibility that has been
overlooked by the checking code.
cheers
All that code assumes that the TPM is still functional which
seems not to be the case for your TPM.
This should fix it:
From: Jerry Snitselaar <hidden> Date: 2023-06-29 17:44:12
On Thu, Jun 29, 2023 at 05:28:58PM +0000, Limonciello, Mario wrote:
[Public]
quoted
-----Original Message-----
From: Jerry Snitselaar <redacted>
Sent: Thursday, June 29, 2023 12:07 PM
To: Limonciello, Mario <Mario.Limonciello@amd.com>
Cc: Michael Ellerman <mpe@ellerman.id.au>; Linux regressions mailing list
[off-list ref]; Sachin Sant [off-list ref]; open
list [off-list ref]; linuxppc-dev <linuxppc-
dev@lists.ozlabs.org>; jarkko@kernel.org; linux-integrity@vger.kernel.org
Subject: Re: [6.4-rc6] Crash during a kexec operation
(tpm_amd_is_rng_defective)
On Thu, Jun 22, 2023 at 09:38:04AM -0500, Limonciello, Mario wrote:
quoted
On 6/22/2023 7:36 AM, Michael Ellerman wrote:
quoted
"Linux regression tracking (Thorsten Leemhuis)"
[off-list ref] writes:
quoted
quoted
quoted
Hi, Thorsten here, the Linux kernel's regression tracker. Top-posting
for once, to make this easily accessible to everyone.
As Linus will likely release 6.4 on this or the following Sunday a quick
question: is there any hope this regression might be fixed any time
soon?
No.
I have added the author of the commit to Cc, maybe they can help?
The immediate question is, is it expected for chip->ops to be NULL in
this path? Obviously on actual AMD systems that isn't the case,
otherwise the code would crash there. But is the fact that chip->ops is
NULL a bug in the ibmvtpm driver, or a possibility that has been
overlooked by the checking code.
cheers
All that code assumes that the TPM is still functional which
seems not to be the case for your TPM.
This should fix it:
-----Original Message-----
From: Jerry Snitselaar <redacted>
Sent: Thursday, June 29, 2023 12:43 PM
To: Limonciello, Mario <Mario.Limonciello@amd.com>
Cc: Michael Ellerman <mpe@ellerman.id.au>; Linux regressions mailing list
[off-list ref]; Sachin Sant [off-list ref]; open
list [off-list ref]; linuxppc-dev <linuxppc-
dev@lists.ozlabs.org>; jarkko@kernel.org; linux-integrity@vger.kernel.org
Subject: Re: [6.4-rc6] Crash during a kexec operation
(tpm_amd_is_rng_defective)
On Thu, Jun 29, 2023 at 05:28:58PM +0000, Limonciello, Mario wrote:
quoted
[Public]
quoted
-----Original Message-----
From: Jerry Snitselaar <redacted>
Sent: Thursday, June 29, 2023 12:07 PM
To: Limonciello, Mario <Mario.Limonciello@amd.com>
Cc: Michael Ellerman <mpe@ellerman.id.au>; Linux regressions mailing list
[off-list ref]; Sachin Sant [off-list ref];
open
quoted
quoted
list [off-list ref]; linuxppc-dev <linuxppc-
dev@lists.ozlabs.org>; jarkko@kernel.org; linux-integrity@vger.kernel.org
Subject: Re: [6.4-rc6] Crash during a kexec operation
(tpm_amd_is_rng_defective)
On Thu, Jun 22, 2023 at 09:38:04AM -0500, Limonciello, Mario wrote:
quoted
On 6/22/2023 7:36 AM, Michael Ellerman wrote:
quoted
"Linux regression tracking (Thorsten Leemhuis)"
[off-list ref] writes:
quoted
quoted
quoted
Hi, Thorsten here, the Linux kernel's regression tracker. Top-posting
for once, to make this easily accessible to everyone.
As Linus will likely release 6.4 on this or the following Sunday a quick
question: is there any hope this regression might be fixed any time
soon?
No.
I have added the author of the commit to Cc, maybe they can help?
The immediate question is, is it expected for chip->ops to be NULL in
this path? Obviously on actual AMD systems that isn't the case,
otherwise the code would crash there. But is the fact that chip->ops is
NULL a bug in the ibmvtpm driver, or a possibility that has been
overlooked by the checking code.
cheers
All that code assumes that the TPM is still functional which
seems not to be the case for your TPM.
This should fix it: