Re: [Bug 215117] New: ucsi_acpi: kernel NULL pointer dereference

Re: [Bug 215117] New: ucsi_acpi: kernel NULL pointer dereference

[Thorsten Leemhuis]

Hi, this is your Linux kernel regression tracker speaking.

Parlty top-posting for once, to make this easy accessible to everyone.

Heikki, below bug sounds a awful lot like a regression. I'd be glad if
you could take a quick look at this, as the report seems have fallen
through the cracks; somebody else today confirmed the problem is still
happening with 5.16-rc3.

Chris or Manuel, could you please confirm v5.15.y worked fine?

On 23.11.21 04:51, bugzilla-daemon@bugzilla.kernel.org wrote:
> https://bugzilla.kernel.org/show_bug.cgi?id=215117
> 
>             Bug ID: 215117
>            Summary: ucsi_acpi: kernel NULL pointer dereference
>            Product: Drivers
>            Version: 2.5
>     Kernel Version: 5.16-rc2
>           Hardware: x86-64
>                 OS: Linux
>               Tree: Mainline
>             Status: NEW
>           Severity: normal
>           Priority: P1
>          Component: USB
>           Assignee: drivers_usb@kernel-bugs.kernel.org
>           Reporter: linux-kernel-bugs@hixontech.com
>         Regression: No
> 
> Created attachment 299677
>   --> https://bugzilla.kernel.org/attachment.cgi?id=299677&action=edit
> journal and lshw
> 
> The system fails to boot completely (or shutdown properly) after kernel oops,
> apparently in the ucsi_acpi module. It boots up fine with this module
> blacklisted. I first noticed the issue on 5.16-rc1; the problem continues with
> 5.16-rc2.
> 
> HW: HP ENVY x360, AMD Ryzen 7 4700U with Radeon Graphics, Renoir
> 
> Attached: full kernel journal log and output from lshw.
> 
> OOPS:
> 
> Nov 22 06:44:04 kernel: BUG: kernel NULL pointer dereference, address:
> 0000000000000058
> Nov 22 06:44:04 kernel: #PF: supervisor read access in kernel mode
> Nov 22 06:44:04 kernel: #PF: error_code(0x0000) - not-present page
> Nov 22 06:44:04 kernel: PGD 0 P4D 0 
> Nov 22 06:44:04 kernel: Oops: 0000 [#1] PREEMPT SMP NOPTI
> Nov 22 06:44:04 kernel: CPU: 0 PID: 394 Comm: kworker/0:2 Not tainted
> 5.16.0-rc2-1-mainline #1 4a5aa185cbfb8b63cd50dfec190bc41096ea30a5
> Nov 22 06:44:04 kernel: Hardware name: HP HP ENVY x360 Convertible
> 15-ds1xxx/87A9, BIOS F.07 03/18/2021
> Nov 22 06:44:04 kernel: Workqueue: events_long ucsi_init_work [typec_ucsi]
> Nov 22 06:44:04 kernel: RIP: 0010:typec_register_altmode+0x2e/0x3a0 [typec]
> Nov 22 06:44:04 kernel: Code: 00 41 57 41 56 41 55 41 54 49 89 f4 55 48 89 fd
> 48 8d bf 08 03 00 00 53 48 83 ec 28 65 48 8b 04 25 28 00 00 00 48 89 44 24 20
> <48> 8b 87 50 fd ff ff 48 3d e0 99 5b c0 74 18 48 8d 95 f8 02 00 00
> Nov 22 06:44:04 kernel: RSP: 0018:ffffa171c0f9fd30 EFLAGS: 00010286
> Nov 22 06:44:04 kernel: RAX: 8a5a9eb1bcae6600 RBX: ffff94994f1b7800 RCX:
> 0000000000000001
> Nov 22 06:44:04 kernel: RDX: 0000000000000000 RSI: ffffa171c0f9fdd0 RDI:
> 0000000000000308
> Nov 22 06:44:04 kernel: RBP: 0000000000000000 R08: 0000000000000000 R09:
> 0000000000000000
> Nov 22 06:44:04 kernel: R10: 0000000000000000 R11: 0000000000000000 R12:
> ffffa171c0f9fdd0
> Nov 22 06:44:04 kernel: R13: 0000000000000000 R14: 0000000000000000 R15:
> ffff94994f1b7800
> Nov 22 06:44:04 kernel: FS:  0000000000000000(0000) GS:ffff949c3f600000(0000)
> knlGS:0000000000000000
> Nov 22 06:44:04 kernel: CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> Nov 22 06:44:04 kernel: CR2: 0000000000000058 CR3: 0000000103c3e000 CR4:
> 0000000000350ef0
> Nov 22 06:44:04 kernel: Call Trace:
> Nov 22 06:44:04 kernel:  <TASK>
> Nov 22 06:44:04 kernel:  ? ucsi_acpi_sync_write+0x4a/0x70 [ucsi_acpi
> 02bdd89c7010256e11856d8931a8362b48e4c3f7]
> Nov 22 06:44:04 kernel:  ucsi_register_altmode.constprop.0+0x1f0/0x250
> [typec_ucsi 5c5256aa8a0bedb6e8965681f3f36303c0e1b18d]
> Nov 22 06:44:04 kernel:  ucsi_register_altmodes+0x161/0x1c0 [typec_ucsi
> 5c5256aa8a0bedb6e8965681f3f36303c0e1b18d]
> Nov 22 06:44:04 kernel:  ucsi_check_altmodes+0x17/0x50 [typec_ucsi
> 5c5256aa8a0bedb6e8965681f3f36303c0e1b18d]
> Nov 22 06:44:04 kernel:  ucsi_init_work+0x6c7/0x720 [typec_ucsi
> 5c5256aa8a0bedb6e8965681f3f36303c0e1b18d]
> Nov 22 06:44:04 kernel:  process_one_work+0x1e8/0x3c0
> Nov 22 06:44:04 kernel:  worker_thread+0x50/0x3c0
> Nov 22 06:44:04 kernel:  ? rescuer_thread+0x390/0x390
> Nov 22 06:44:04 kernel:  kthread+0x15c/0x180
> Nov 22 06:44:04 kernel:  ? set_kthread_struct+0x50/0x50
> Nov 22 06:44:04 kernel:  ret_from_fork+0x22/0x30
> Nov 22 06:44:04 kernel:  </TASK>
> Nov 22 06:44:04 kernel: Modules linked in: snd_hda_codec_realtek(+) fjes(-)
> snd_hda_codec_generic ledtrig_audio snd_hda_codec_hdmi joydev iwlmvm(+)
> mousedev snd_hda_intel snd_intel_dspcfg snd_intel_sdw_acpi mac80211
> nls_iso8859_1 snd_hda_codec btusb vfat amdgpu(+) libarc4 snd_hda_core btrtl fat
> snd_hwdep btbcm iwlwifi snd_pcm btintel snd_timer bluetooth snd_pci_acp5x
> snd_rn_pci_acp3x k10temp gpu_sched amd_sfh snd_pci_acp3x cfg80211 snd
> ecdh_generic ucsi_acpi drm_ttm_helper sp5100_tco soundcore rfkill typec_ucsi
> ttm i2c_piix4 typec mac_hid roles wmi video tpm_crb tpm_tis wireless_hotkey
> tpm_tis_core hp_accel acpi_cpufreq lis3lv02d amd_pmc acpi_tad 9pnet_virtio 9p
> 9pnet fscache netfs sg crypto_user fuse bpf_preload ip_tables x_tables ext4
> crc32c_generic crc16 mbcache jbd2 dm_crypt cbc encrypted_keys dm_mod trusted
> asn1_encoder tee tpm rtsx_pci_sdmmc mmc_core crct10dif_pclmul serio_raw
> crc32_pclmul crc32c_intel ghash_clmulni_intel atkbd aesni_intel libps2
> crypto_simd cryptd ccp xhci_pci
> Nov 22 06:44:04 kernel:  xhci_pci_renesas rng_core rtsx_pci i8042 serio
> hid_multitouch i2c_hid_acpi i2c_hid pinctrl_amd
> Nov 22 06:44:04 kernel: CR2: 0000000000000058
> Nov 22 06:44:04 kernel: ---[ end trace bdd82aa217da2b8a ]---
> Nov 22 06:44:04 kernel: RIP: 0010:typec_register_altmode+0x2e/0x3a0 [typec]
> Nov 22 06:44:04 kernel: Code: 00 41 57 41 56 41 55 41 54 49 89 f4 55 48 89 fd
> 48 8d bf 08 03 00 00 53 48 83 ec 28 65 48 8b 04 25 28 00 00 00 48 89 44 24 20
> <48> 8b 87 50 fd ff ff 48 3d e0 99 5b c0 74 18 48 8d 95 f8 02 00 00
> Nov 22 06:44:04 kernel: RSP: 0018:ffffa171c0f9fd30 EFLAGS: 00010286
> Nov 22 06:44:04 kernel: RAX: 8a5a9eb1bcae6600 RBX: ffff94994f1b7800 RCX:
> 0000000000000001
> Nov 22 06:44:04 kernel: RDX: 0000000000000000 RSI: ffffa171c0f9fdd0 RDI:
> 0000000000000308
> Nov 22 06:44:04 kernel: RBP: 0000000000000000 R08: 0000000000000000 R09:
> 0000000000000000
> Nov 22 06:44:04 kernel: R10: 0000000000000000 R11: 0000000000000000 R12:
> ffffa171c0f9fdd0
> Nov 22 06:44:04 kernel: R13: 0000000000000000 R14: 0000000000000000 R15:
> ffff94994f1b7800
> Nov 22 06:44:04 kernel: FS:  0000000000000000(0000) GS:ffff949c3f600000(0000)
> knlGS:0000000000000000
> Nov 22 06:44:04 kernel: CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> Nov 22 06:44:04 kernel: CR2: 0000000000000058 CR3: 0000000103c3e000 CR4:
> 0000000000350ef0

[TLDR for the rest: adding this regression to regzbot; this mail is
partly compiled from a few templates paragraphs some of you might have
seen already.]

Adding the regression mailing list to the list of recipients, as it
should be in the loop for all regressions, as explained here:
https://www.kernel.org/doc/html/latest/admin-guide/reporting-issues.html

To be sure this issue doesn't fall through the cracks unnoticed, I'm
adding it to regzbot, my Linux kernel regression tracking bot:

#regzbot ^introduced v5.15..v5.16-rc1
#regzbot title usb: ucsi_acpi: kernel NULL pointer dereference

Reminder: when fixing the issue, please add a 'Link:' tag with the URL
to the report (the parent of this mail), then regzbot will automatically
mark the regression as resolved once the fix lands in the appropriate
tree. For more details about regzbot see footer.

Sending this to everyone that got the initial report, to make all aware
of the tracking. I also hope that messages like this motivate people to
directly get at least the regression mailing list and ideally even
regzbot involved when dealing with regressions, as messages like this
wouldn't be needed then.

Don't worry, I'll send further messages wrt to this regression just to
the lists (with a tag in the subject so people can filter them away), as
long as they are intended just for regzbot. With a bit of luck no such
messages will be needed anyway.

Ciao, Thorsten (wearing his 'Linux kernel regression tracker' hat).

P.S.: As a Linux kernel regression tracker I'm getting a lot of reports
on my table. I can only look briefly into most of them. Unfortunately
therefore I sometimes will get things wrong or miss something important.
I hope that's not the case here; if you think it is, don't hesitate to
tell me about it in a public reply. That's in everyone's interest, as
what I wrote above might be misleading to everyone reading this; any
suggestion I gave thus might sent someone reading this down the wrong
rabbit hole, which none of us wants.

BTW, I have no personal interest in this issue, which is tracked using
regzbot, my Linux kernel regression tracking bot
(https://linux-regtracking.leemhuis.info/regzbot/). I'm only posting
this mail to get things rolling again and hence don't need to be CC on
all further activities wrt to this regression.

Re: [Bug 215117] New: ucsi_acpi: kernel NULL pointer dereference

[Heikki Krogerus]

Hi,

On Thu, Dec 16, 2021 at 10:22:17AM +0100, Thorsten Leemhuis wrote:
> Hi, this is your Linux kernel regression tracker speaking.
> 
> Parlty top-posting for once, to make this easy accessible to everyone.
> 
> Heikki, below bug sounds a awful lot like a regression. I'd be glad if
> you could take a quick look at this, as the report seems have fallen
> through the cracks; somebody else today confirmed the problem is still
> happening with 5.16-rc3.

It is most likely regression. This commit is quite likely the culprit:

        cbe4b2d5a3f ("usb: typec: ucsi: Check the partner alt modes always if there is PD contract")

I think this should fix it:

diff --git a/drivers/usb/typec/ucsi/ucsi.c b/drivers/usb/typec/ucsi/ucsi.c
index 6aa28384f77f1..08561bf7c40cd 100644
--- a/drivers/usb/typec/ucsi/ucsi.c
+++ b/drivers/usb/typec/ucsi/ucsi.c
@@ -1150,7 +1150,9 @@ static int ucsi_register_port(struct ucsi *ucsi, int index)
                ret = 0;
        }
 
-       if (UCSI_CONSTAT_PWR_OPMODE(con->status.flags) == UCSI_CONSTAT_PWR_OPMODE_PD) {
+       if (con->partner &&
+           UCSI_CONSTAT_PWR_OPMODE(con->status.flags) ==
+           UCSI_CONSTAT_PWR_OPMODE_PD) {
                ucsi_get_src_pdos(con);
                ucsi_check_altmodes(con);
        }

It's also attached to the bug report.

> Chris or Manuel, could you please confirm v5.15.y worked fine?
> 
> On 23.11.21 04:51, bugzilla-daemon@bugzilla.kernel.org wrote:
> > https://bugzilla.kernel.org/show_bug.cgi?id=215117
> > 
> >             Bug ID: 215117
> >            Summary: ucsi_acpi: kernel NULL pointer dereference
> >            Product: Drivers
> >            Version: 2.5
> >     Kernel Version: 5.16-rc2
> >           Hardware: x86-64
> >                 OS: Linux
> >               Tree: Mainline
> >             Status: NEW
> >           Severity: normal
> >           Priority: P1
> >          Component: USB
> >           Assignee: drivers_usb@kernel-bugs.kernel.org
> >           Reporter: linux-kernel-bugs@hixontech.com
> >         Regression: No
> > 
> > Created attachment 299677
> >   --> https://bugzilla.kernel.org/attachment.cgi?id=299677&action=edit
> > journal and lshw
> > 
> > The system fails to boot completely (or shutdown properly) after kernel oops,
> > apparently in the ucsi_acpi module. It boots up fine with this module
> > blacklisted. I first noticed the issue on 5.16-rc1; the problem continues with
> > 5.16-rc2.
> > 
> > HW: HP ENVY x360, AMD Ryzen 7 4700U with Radeon Graphics, Renoir
> > 
> > Attached: full kernel journal log and output from lshw.
> > 
> > OOPS:
> > 
> > Nov 22 06:44:04 kernel: BUG: kernel NULL pointer dereference, address:
> > 0000000000000058
> > Nov 22 06:44:04 kernel: #PF: supervisor read access in kernel mode
> > Nov 22 06:44:04 kernel: #PF: error_code(0x0000) - not-present page
> > Nov 22 06:44:04 kernel: PGD 0 P4D 0 
> > Nov 22 06:44:04 kernel: Oops: 0000 [#1] PREEMPT SMP NOPTI
> > Nov 22 06:44:04 kernel: CPU: 0 PID: 394 Comm: kworker/0:2 Not tainted
> > 5.16.0-rc2-1-mainline #1 4a5aa185cbfb8b63cd50dfec190bc41096ea30a5
> > Nov 22 06:44:04 kernel: Hardware name: HP HP ENVY x360 Convertible
> > 15-ds1xxx/87A9, BIOS F.07 03/18/2021
> > Nov 22 06:44:04 kernel: Workqueue: events_long ucsi_init_work [typec_ucsi]
> > Nov 22 06:44:04 kernel: RIP: 0010:typec_register_altmode+0x2e/0x3a0 [typec]
> > Nov 22 06:44:04 kernel: Code: 00 41 57 41 56 41 55 41 54 49 89 f4 55 48 89 fd
> > 48 8d bf 08 03 00 00 53 48 83 ec 28 65 48 8b 04 25 28 00 00 00 48 89 44 24 20
> > <48> 8b 87 50 fd ff ff 48 3d e0 99 5b c0 74 18 48 8d 95 f8 02 00 00
> > Nov 22 06:44:04 kernel: RSP: 0018:ffffa171c0f9fd30 EFLAGS: 00010286
> > Nov 22 06:44:04 kernel: RAX: 8a5a9eb1bcae6600 RBX: ffff94994f1b7800 RCX:
> > 0000000000000001
> > Nov 22 06:44:04 kernel: RDX: 0000000000000000 RSI: ffffa171c0f9fdd0 RDI:
> > 0000000000000308
> > Nov 22 06:44:04 kernel: RBP: 0000000000000000 R08: 0000000000000000 R09:
> > 0000000000000000
> > Nov 22 06:44:04 kernel: R10: 0000000000000000 R11: 0000000000000000 R12:
> > ffffa171c0f9fdd0
> > Nov 22 06:44:04 kernel: R13: 0000000000000000 R14: 0000000000000000 R15:
> > ffff94994f1b7800
> > Nov 22 06:44:04 kernel: FS:  0000000000000000(0000) GS:ffff949c3f600000(0000)
> > knlGS:0000000000000000
> > Nov 22 06:44:04 kernel: CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> > Nov 22 06:44:04 kernel: CR2: 0000000000000058 CR3: 0000000103c3e000 CR4:
> > 0000000000350ef0
> > Nov 22 06:44:04 kernel: Call Trace:
> > Nov 22 06:44:04 kernel:  <TASK>
> > Nov 22 06:44:04 kernel:  ? ucsi_acpi_sync_write+0x4a/0x70 [ucsi_acpi
> > 02bdd89c7010256e11856d8931a8362b48e4c3f7]
> > Nov 22 06:44:04 kernel:  ucsi_register_altmode.constprop.0+0x1f0/0x250
> > [typec_ucsi 5c5256aa8a0bedb6e8965681f3f36303c0e1b18d]
> > Nov 22 06:44:04 kernel:  ucsi_register_altmodes+0x161/0x1c0 [typec_ucsi
> > 5c5256aa8a0bedb6e8965681f3f36303c0e1b18d]
> > Nov 22 06:44:04 kernel:  ucsi_check_altmodes+0x17/0x50 [typec_ucsi
> > 5c5256aa8a0bedb6e8965681f3f36303c0e1b18d]
> > Nov 22 06:44:04 kernel:  ucsi_init_work+0x6c7/0x720 [typec_ucsi
> > 5c5256aa8a0bedb6e8965681f3f36303c0e1b18d]
> > Nov 22 06:44:04 kernel:  process_one_work+0x1e8/0x3c0
> > Nov 22 06:44:04 kernel:  worker_thread+0x50/0x3c0
> > Nov 22 06:44:04 kernel:  ? rescuer_thread+0x390/0x390
> > Nov 22 06:44:04 kernel:  kthread+0x15c/0x180
> > Nov 22 06:44:04 kernel:  ? set_kthread_struct+0x50/0x50
> > Nov 22 06:44:04 kernel:  ret_from_fork+0x22/0x30
> > Nov 22 06:44:04 kernel:  </TASK>
> > Nov 22 06:44:04 kernel: Modules linked in: snd_hda_codec_realtek(+) fjes(-)
> > snd_hda_codec_generic ledtrig_audio snd_hda_codec_hdmi joydev iwlmvm(+)
> > mousedev snd_hda_intel snd_intel_dspcfg snd_intel_sdw_acpi mac80211
> > nls_iso8859_1 snd_hda_codec btusb vfat amdgpu(+) libarc4 snd_hda_core btrtl fat
> > snd_hwdep btbcm iwlwifi snd_pcm btintel snd_timer bluetooth snd_pci_acp5x
> > snd_rn_pci_acp3x k10temp gpu_sched amd_sfh snd_pci_acp3x cfg80211 snd
> > ecdh_generic ucsi_acpi drm_ttm_helper sp5100_tco soundcore rfkill typec_ucsi
> > ttm i2c_piix4 typec mac_hid roles wmi video tpm_crb tpm_tis wireless_hotkey
> > tpm_tis_core hp_accel acpi_cpufreq lis3lv02d amd_pmc acpi_tad 9pnet_virtio 9p
> > 9pnet fscache netfs sg crypto_user fuse bpf_preload ip_tables x_tables ext4
> > crc32c_generic crc16 mbcache jbd2 dm_crypt cbc encrypted_keys dm_mod trusted
> > asn1_encoder tee tpm rtsx_pci_sdmmc mmc_core crct10dif_pclmul serio_raw
> > crc32_pclmul crc32c_intel ghash_clmulni_intel atkbd aesni_intel libps2
> > crypto_simd cryptd ccp xhci_pci
> > Nov 22 06:44:04 kernel:  xhci_pci_renesas rng_core rtsx_pci i8042 serio
> > hid_multitouch i2c_hid_acpi i2c_hid pinctrl_amd
> > Nov 22 06:44:04 kernel: CR2: 0000000000000058
> > Nov 22 06:44:04 kernel: ---[ end trace bdd82aa217da2b8a ]---
> > Nov 22 06:44:04 kernel: RIP: 0010:typec_register_altmode+0x2e/0x3a0 [typec]
> > Nov 22 06:44:04 kernel: Code: 00 41 57 41 56 41 55 41 54 49 89 f4 55 48 89 fd
> > 48 8d bf 08 03 00 00 53 48 83 ec 28 65 48 8b 04 25 28 00 00 00 48 89 44 24 20
> > <48> 8b 87 50 fd ff ff 48 3d e0 99 5b c0 74 18 48 8d 95 f8 02 00 00
> > Nov 22 06:44:04 kernel: RSP: 0018:ffffa171c0f9fd30 EFLAGS: 00010286
> > Nov 22 06:44:04 kernel: RAX: 8a5a9eb1bcae6600 RBX: ffff94994f1b7800 RCX:
> > 0000000000000001
> > Nov 22 06:44:04 kernel: RDX: 0000000000000000 RSI: ffffa171c0f9fdd0 RDI:
> > 0000000000000308
> > Nov 22 06:44:04 kernel: RBP: 0000000000000000 R08: 0000000000000000 R09:
> > 0000000000000000
> > Nov 22 06:44:04 kernel: R10: 0000000000000000 R11: 0000000000000000 R12:
> > ffffa171c0f9fdd0
> > Nov 22 06:44:04 kernel: R13: 0000000000000000 R14: 0000000000000000 R15:
> > ffff94994f1b7800
> > Nov 22 06:44:04 kernel: FS:  0000000000000000(0000) GS:ffff949c3f600000(0000)
> > knlGS:0000000000000000
> > Nov 22 06:44:04 kernel: CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> > Nov 22 06:44:04 kernel: CR2: 0000000000000058 CR3: 0000000103c3e000 CR4:
> > 0000000000350ef0
> 
> [TLDR for the rest: adding this regression to regzbot; this mail is
> partly compiled from a few templates paragraphs some of you might have
> seen already.]
> 
> Adding the regression mailing list to the list of recipients, as it
> should be in the loop for all regressions, as explained here:
> https://www.kernel.org/doc/html/latest/admin-guide/reporting-issues.html
> 
> To be sure this issue doesn't fall through the cracks unnoticed, I'm
> adding it to regzbot, my Linux kernel regression tracking bot:
> 
> #regzbot ^introduced v5.15..v5.16-rc1
> #regzbot title usb: ucsi_acpi: kernel NULL pointer dereference
> 
> Reminder: when fixing the issue, please add a 'Link:' tag with the URL
> to the report (the parent of this mail), then regzbot will automatically
> mark the regression as resolved once the fix lands in the appropriate
> tree. For more details about regzbot see footer.
> 
> Sending this to everyone that got the initial report, to make all aware
> of the tracking. I also hope that messages like this motivate people to
> directly get at least the regression mailing list and ideally even
> regzbot involved when dealing with regressions, as messages like this
> wouldn't be needed then.
> 
> Don't worry, I'll send further messages wrt to this regression just to
> the lists (with a tag in the subject so people can filter them away), as
> long as they are intended just for regzbot. With a bit of luck no such
> messages will be needed anyway.
> 
> Ciao, Thorsten (wearing his 'Linux kernel regression tracker' hat).
> 
> P.S.: As a Linux kernel regression tracker I'm getting a lot of reports
> on my table. I can only look briefly into most of them. Unfortunately
> therefore I sometimes will get things wrong or miss something important.
> I hope that's not the case here; if you think it is, don't hesitate to
> tell me about it in a public reply. That's in everyone's interest, as
> what I wrote above might be misleading to everyone reading this; any
> suggestion I gave thus might sent someone reading this down the wrong
> rabbit hole, which none of us wants.
> 
> BTW, I have no personal interest in this issue, which is tracked using
> regzbot, my Linux kernel regression tracking bot
> (https://linux-regtracking.leemhuis.info/regzbot/). I'm only posting
> this mail to get things rolling again and hence don't need to be CC on
> all further activities wrt to this regression.

-- 
heikki

Re: [Bug 215117] New: ucsi_acpi: kernel NULL pointer dereference #forregzbot

[Thorsten Leemhuis]

Hi, this is your Linux kernel regression tracker speaking.

For the record:

#regzbot fixed-by: 3f345e907a8e7c56fdebf7231cd67afc85d02aaa

https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git/commit/?h=usb-linus&id=3f345e907a8e7c56fdebf7231cd67afc85d02aaa

Greg helpfully added a "Link:" tag to make regzbot happy, but he
specified a reply to the report and not the report itself, as expected
by regzbot (I'm taken back and forth for a while already if that's a
good or bad idea). And that was not Greg's but my fault, as I had given
him the wrong link here:
https://lore.kernel.org/r/YcH2w9jmGnqUMWp4@kroah.com/

Sigh.

Ciao, Thorsten, your Linux kernel regression tracker.

TWIMC: this mail is primarily send for documentation purposes and for
regzbot, my Linux kernel regression tracking bot. These mails usually
contain '#forregzbot' in the subject, to make them easy to spot and filter.


On 16.12.21 10:22, Thorsten Leemhuis wrote:
> Hi, this is your Linux kernel regression tracker speaking.
> 
> Parlty top-posting for once, to make this easy accessible to everyone.
> 
> Heikki, below bug sounds a awful lot like a regression. I'd be glad if
> you could take a quick look at this, as the report seems have fallen
> through the cracks; somebody else today confirmed the problem is still
> happening with 5.16-rc3.
> 
> Chris or Manuel, could you please confirm v5.15.y worked fine?
> 
> On 23.11.21 04:51, bugzilla-daemon@bugzilla.kernel.org wrote:
>> https://bugzilla.kernel.org/show_bug.cgi?id=215117
>>
>>             Bug ID: 215117
>>            Summary: ucsi_acpi: kernel NULL pointer dereference
>>            Product: Drivers
>>            Version: 2.5
>>     Kernel Version: 5.16-rc2
>>           Hardware: x86-64
>>                 OS: Linux
>>               Tree: Mainline
>>             Status: NEW
>>           Severity: normal
>>           Priority: P1
>>          Component: USB
>>           Assignee: drivers_usb@kernel-bugs.kernel.org
>>           Reporter: linux-kernel-bugs@hixontech.com
>>         Regression: No
>>
>> Created attachment 299677
>>   --> https://bugzilla.kernel.org/attachment.cgi?id=299677&action=edit
>> journal and lshw
>>
>> The system fails to boot completely (or shutdown properly) after kernel oops,
>> apparently in the ucsi_acpi module. It boots up fine with this module
>> blacklisted. I first noticed the issue on 5.16-rc1; the problem continues with
>> 5.16-rc2.
>>
>> HW: HP ENVY x360, AMD Ryzen 7 4700U with Radeon Graphics, Renoir
>>
>> Attached: full kernel journal log and output from lshw.
>>
>> OOPS:
>>
>> Nov 22 06:44:04 kernel: BUG: kernel NULL pointer dereference, address:
>> 0000000000000058
>> Nov 22 06:44:04 kernel: #PF: supervisor read access in kernel mode
>> Nov 22 06:44:04 kernel: #PF: error_code(0x0000) - not-present page
>> Nov 22 06:44:04 kernel: PGD 0 P4D 0 
>> Nov 22 06:44:04 kernel: Oops: 0000 [#1] PREEMPT SMP NOPTI
>> Nov 22 06:44:04 kernel: CPU: 0 PID: 394 Comm: kworker/0:2 Not tainted
>> 5.16.0-rc2-1-mainline #1 4a5aa185cbfb8b63cd50dfec190bc41096ea30a5
>> Nov 22 06:44:04 kernel: Hardware name: HP HP ENVY x360 Convertible
>> 15-ds1xxx/87A9, BIOS F.07 03/18/2021
>> Nov 22 06:44:04 kernel: Workqueue: events_long ucsi_init_work [typec_ucsi]
>> Nov 22 06:44:04 kernel: RIP: 0010:typec_register_altmode+0x2e/0x3a0 [typec]
>> Nov 22 06:44:04 kernel: Code: 00 41 57 41 56 41 55 41 54 49 89 f4 55 48 89 fd
>> 48 8d bf 08 03 00 00 53 48 83 ec 28 65 48 8b 04 25 28 00 00 00 48 89 44 24 20
>> <48> 8b 87 50 fd ff ff 48 3d e0 99 5b c0 74 18 48 8d 95 f8 02 00 00
>> Nov 22 06:44:04 kernel: RSP: 0018:ffffa171c0f9fd30 EFLAGS: 00010286
>> Nov 22 06:44:04 kernel: RAX: 8a5a9eb1bcae6600 RBX: ffff94994f1b7800 RCX:
>> 0000000000000001
>> Nov 22 06:44:04 kernel: RDX: 0000000000000000 RSI: ffffa171c0f9fdd0 RDI:
>> 0000000000000308
>> Nov 22 06:44:04 kernel: RBP: 0000000000000000 R08: 0000000000000000 R09:
>> 0000000000000000
>> Nov 22 06:44:04 kernel: R10: 0000000000000000 R11: 0000000000000000 R12:
>> ffffa171c0f9fdd0
>> Nov 22 06:44:04 kernel: R13: 0000000000000000 R14: 0000000000000000 R15:
>> ffff94994f1b7800
>> Nov 22 06:44:04 kernel: FS:  0000000000000000(0000) GS:ffff949c3f600000(0000)
>> knlGS:0000000000000000
>> Nov 22 06:44:04 kernel: CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
>> Nov 22 06:44:04 kernel: CR2: 0000000000000058 CR3: 0000000103c3e000 CR4:
>> 0000000000350ef0
>> Nov 22 06:44:04 kernel: Call Trace:
>> Nov 22 06:44:04 kernel:  <TASK>
>> Nov 22 06:44:04 kernel:  ? ucsi_acpi_sync_write+0x4a/0x70 [ucsi_acpi
>> 02bdd89c7010256e11856d8931a8362b48e4c3f7]
>> Nov 22 06:44:04 kernel:  ucsi_register_altmode.constprop.0+0x1f0/0x250
>> [typec_ucsi 5c5256aa8a0bedb6e8965681f3f36303c0e1b18d]
>> Nov 22 06:44:04 kernel:  ucsi_register_altmodes+0x161/0x1c0 [typec_ucsi
>> 5c5256aa8a0bedb6e8965681f3f36303c0e1b18d]
>> Nov 22 06:44:04 kernel:  ucsi_check_altmodes+0x17/0x50 [typec_ucsi
>> 5c5256aa8a0bedb6e8965681f3f36303c0e1b18d]
>> Nov 22 06:44:04 kernel:  ucsi_init_work+0x6c7/0x720 [typec_ucsi
>> 5c5256aa8a0bedb6e8965681f3f36303c0e1b18d]
>> Nov 22 06:44:04 kernel:  process_one_work+0x1e8/0x3c0
>> Nov 22 06:44:04 kernel:  worker_thread+0x50/0x3c0
>> Nov 22 06:44:04 kernel:  ? rescuer_thread+0x390/0x390
>> Nov 22 06:44:04 kernel:  kthread+0x15c/0x180
>> Nov 22 06:44:04 kernel:  ? set_kthread_struct+0x50/0x50
>> Nov 22 06:44:04 kernel:  ret_from_fork+0x22/0x30
>> Nov 22 06:44:04 kernel:  </TASK>
>> Nov 22 06:44:04 kernel: Modules linked in: snd_hda_codec_realtek(+) fjes(-)
>> snd_hda_codec_generic ledtrig_audio snd_hda_codec_hdmi joydev iwlmvm(+)
>> mousedev snd_hda_intel snd_intel_dspcfg snd_intel_sdw_acpi mac80211
>> nls_iso8859_1 snd_hda_codec btusb vfat amdgpu(+) libarc4 snd_hda_core btrtl fat
>> snd_hwdep btbcm iwlwifi snd_pcm btintel snd_timer bluetooth snd_pci_acp5x
>> snd_rn_pci_acp3x k10temp gpu_sched amd_sfh snd_pci_acp3x cfg80211 snd
>> ecdh_generic ucsi_acpi drm_ttm_helper sp5100_tco soundcore rfkill typec_ucsi
>> ttm i2c_piix4 typec mac_hid roles wmi video tpm_crb tpm_tis wireless_hotkey
>> tpm_tis_core hp_accel acpi_cpufreq lis3lv02d amd_pmc acpi_tad 9pnet_virtio 9p
>> 9pnet fscache netfs sg crypto_user fuse bpf_preload ip_tables x_tables ext4
>> crc32c_generic crc16 mbcache jbd2 dm_crypt cbc encrypted_keys dm_mod trusted
>> asn1_encoder tee tpm rtsx_pci_sdmmc mmc_core crct10dif_pclmul serio_raw
>> crc32_pclmul crc32c_intel ghash_clmulni_intel atkbd aesni_intel libps2
>> crypto_simd cryptd ccp xhci_pci
>> Nov 22 06:44:04 kernel:  xhci_pci_renesas rng_core rtsx_pci i8042 serio
>> hid_multitouch i2c_hid_acpi i2c_hid pinctrl_amd
>> Nov 22 06:44:04 kernel: CR2: 0000000000000058
>> Nov 22 06:44:04 kernel: ---[ end trace bdd82aa217da2b8a ]---
>> Nov 22 06:44:04 kernel: RIP: 0010:typec_register_altmode+0x2e/0x3a0 [typec]
>> Nov 22 06:44:04 kernel: Code: 00 41 57 41 56 41 55 41 54 49 89 f4 55 48 89 fd
>> 48 8d bf 08 03 00 00 53 48 83 ec 28 65 48 8b 04 25 28 00 00 00 48 89 44 24 20
>> <48> 8b 87 50 fd ff ff 48 3d e0 99 5b c0 74 18 48 8d 95 f8 02 00 00
>> Nov 22 06:44:04 kernel: RSP: 0018:ffffa171c0f9fd30 EFLAGS: 00010286
>> Nov 22 06:44:04 kernel: RAX: 8a5a9eb1bcae6600 RBX: ffff94994f1b7800 RCX:
>> 0000000000000001
>> Nov 22 06:44:04 kernel: RDX: 0000000000000000 RSI: ffffa171c0f9fdd0 RDI:
>> 0000000000000308
>> Nov 22 06:44:04 kernel: RBP: 0000000000000000 R08: 0000000000000000 R09:
>> 0000000000000000
>> Nov 22 06:44:04 kernel: R10: 0000000000000000 R11: 0000000000000000 R12:
>> ffffa171c0f9fdd0
>> Nov 22 06:44:04 kernel: R13: 0000000000000000 R14: 0000000000000000 R15:
>> ffff94994f1b7800
>> Nov 22 06:44:04 kernel: FS:  0000000000000000(0000) GS:ffff949c3f600000(0000)
>> knlGS:0000000000000000
>> Nov 22 06:44:04 kernel: CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
>> Nov 22 06:44:04 kernel: CR2: 0000000000000058 CR3: 0000000103c3e000 CR4:
>> 0000000000350ef0
> 
> [TLDR for the rest: adding this regression to regzbot; this mail is
> partly compiled from a few templates paragraphs some of you might have
> seen already.]
> 
> Adding the regression mailing list to the list of recipients, as it
> should be in the loop for all regressions, as explained here:
> https://www.kernel.org/doc/html/latest/admin-guide/reporting-issues.html
> 
> To be sure this issue doesn't fall through the cracks unnoticed, I'm
> adding it to regzbot, my Linux kernel regression tracking bot:
> 
> #regzbot ^introduced v5.15..v5.16-rc1
> #regzbot title usb: ucsi_acpi: kernel NULL pointer dereference
> 
> Reminder: when fixing the issue, please add a 'Link:' tag with the URL
> to the report (the parent of this mail), then regzbot will automatically
> mark the regression as resolved once the fix lands in the appropriate
> tree. For more details about regzbot see footer.
> 
> Sending this to everyone that got the initial report, to make all aware
> of the tracking. I also hope that messages like this motivate people to
> directly get at least the regression mailing list and ideally even
> regzbot involved when dealing with regressions, as messages like this
> wouldn't be needed then.
> 
> Don't worry, I'll send further messages wrt to this regression just to
> the lists (with a tag in the subject so people can filter them away), as
> long as they are intended just for regzbot. With a bit of luck no such
> messages will be needed anyway.
> 
> Ciao, Thorsten (wearing his 'Linux kernel regression tracker' hat).
> 
> P.S.: As a Linux kernel regression tracker I'm getting a lot of reports
> on my table. I can only look briefly into most of them. Unfortunately
> therefore I sometimes will get things wrong or miss something important.
> I hope that's not the case here; if you think it is, don't hesitate to
> tell me about it in a public reply. That's in everyone's interest, as
> what I wrote above might be misleading to everyone reading this; any
> suggestion I gave thus might sent someone reading this down the wrong
> rabbit hole, which none of us wants.
> 
> BTW, I have no personal interest in this issue, which is tracked using
> regzbot, my Linux kernel regression tracking bot
> (https://linux-regtracking.leemhuis.info/regzbot/). I'm only posting
> this mail to get things rolling again and hence don't need to be CC on
> all further activities wrt to this regression.

Re: [Bug 215117] New: ucsi_acpi: kernel NULL pointer dereference #forregzbot

[Greg KH]

On Tue, Dec 21, 2021 at 07:06:30PM +0100, Thorsten Leemhuis wrote:
> Hi, this is your Linux kernel regression tracker speaking.
> 
> For the record:
> 
> #regzbot fixed-by: 3f345e907a8e7c56fdebf7231cd67afc85d02aaa
> 
> https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git/commit/?h=usb-linus&id=3f345e907a8e7c56fdebf7231cd67afc85d02aaa
> 
> Greg helpfully added a "Link:" tag to make regzbot happy, but he
> specified a reply to the report and not the report itself, as expected
> by regzbot (I'm taken back and forth for a while already if that's a
> good or bad idea). And that was not Greg's but my fault, as I had given
> him the wrong link here:
> https://lore.kernel.org/r/YcH2w9jmGnqUMWp4@kroah.com/

Sorry about that, I tried!  :(

Keep up the great work, we'll get the workflow down yet.

greg k-h

Re: [Bug 215117] New: ucsi_acpi: kernel NULL pointer dereference #forregzbot

[Thorsten Leemhuis]

On 22.12.21 07:32, Greg KH wrote:
> On Tue, Dec 21, 2021 at 07:06:30PM +0100, Thorsten Leemhuis wrote:
>> Hi, this is your Linux kernel regression tracker speaking.
>>
>> For the record:
>>
>> #regzbot fixed-by: 3f345e907a8e7c56fdebf7231cd67afc85d02aaa
>>
>> https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git/commit/?h=usb-linus&id=3f345e907a8e7c56fdebf7231cd67afc85d02aaa
>>
>> Greg helpfully added a "Link:" tag to make regzbot happy, but he
>> specified a reply to the report and not the report itself, as expected
>> by regzbot (I'm taken back and forth for a while already if that's a
>> good or bad idea). And that was not Greg's but my fault, as I had given
>> him the wrong link here:
>> https://lore.kernel.org/r/YcH2w9jmGnqUMWp4@kroah.com/
> 
> Sorry about that, I tried!  :(

Many thx. And as mentioned: it was my fault :-/

> Keep up the great work,

Will do, thx for saying this, there are sometimes tough days where
things like this help. :-D

> we'll get the workflow down yet.

FWIW, regzbot in a few cases already completely worked as intended to.
But yeah, things like this always take a while to get settled.

My biggest problem is: many developers don't place the Link: tags. I
obviously expected that up to a point. But what I didn't expect: so much
opposition to place them, because quite a few developers think they are
reserved for maintainers, as they are only meant for linking to the
submission of the applied patch; a few also think others tags should be
needed for linking to bugs.

My proposed "introduce the commit message tags 'Reported:' and
'Posted:'" patch likely would have helped here, but didn't get any
traction :-/
https://lore.kernel.org/lkml/c6724c7fb534a46e095e6aef13d996ed9589e578.1639042966.git.linux@leemhuis.info/

Maybe that was partly due to the stupid mixup in the subject of the
cover letter, but whatever. So I guess I'll drop the bold idea. I
consider proposing to create "Reported: <url>" while leaving ambiguous
Link: alone, which will help my case. Note sure if I also should propose
to drop "Reported-by" at the same time, which makes things easier for
developers, as that tag can only be set after asking the reporter.

Ciao, Thorsten

Re: [Bug 215117] New: ucsi_acpi: kernel NULL pointer dereference #forregzbot

[Greg KH]

On Wed, Dec 22, 2021 at 09:37:55AM +0100, Thorsten Leemhuis wrote:
> My biggest problem is: many developers don't place the Link: tags. I
> obviously expected that up to a point. But what I didn't expect: so much
> opposition to place them, because quite a few developers think they are
> reserved for maintainers, as they are only meant for linking to the
> submission of the applied patch; a few also think others tags should be
> needed for linking to bugs.

Hah, I can't even get developers to add a Fixes: or a Cc: stable tag,
trying to get them to add a Link: tag to a lore reference is going to be
an uphill battle.

Right now, the best thing we have is the git hook that auto-adds the
Link: tag that points to the lore thread where the patch came from.
Maintainers don't have the energy or time to add anything other than
that, so I think you just might have to rely on Fixes: for a while.

> My proposed "introduce the commit message tags 'Reported:' and
> 'Posted:'" patch likely would have helped here, but didn't get any
> traction :-/
> https://lore.kernel.org/lkml/c6724c7fb534a46e095e6aef13d996ed9589e578.1639042966.git.linux@leemhuis.info/
> 
> Maybe that was partly due to the stupid mixup in the subject of the
> cover letter, but whatever. So I guess I'll drop the bold idea. I
> consider proposing to create "Reported: <url>" while leaving ambiguous
> Link: alone, which will help my case. Note sure if I also should propose
> to drop "Reported-by" at the same time, which makes things easier for
> developers, as that tag can only be set after asking the reporter.

Nah, I add "Reported-by:" all the time without asking for explicit
permission, relying on the public email instead.  If there was some way
to automate the Reported: tag, maybe it could be used, but again, that's
a lot of manual work to do, which is going to be a hard sell.

thanks,

greg k-h

Re: [Bug 215117] New: ucsi_acpi: kernel NULL pointer dereference #forregzbot

[Thorsten Leemhuis]

On 22.12.21 10:02, Greg KH wrote:
> On Wed, Dec 22, 2021 at 09:37:55AM +0100, Thorsten Leemhuis wrote:
>> My biggest problem is: many developers don't place the Link: tags. I
>> obviously expected that up to a point. But what I didn't expect: so much
>> opposition to place them, because quite a few developers think they are
>> reserved for maintainers, as they are only meant for linking to the
>> submission of the applied patch; a few also think others tags should be
>> needed for linking to bugs.
> 
> Hah, I can't even get developers to add a Fixes: or a Cc: stable tag,
> trying to get them to add a Link: tag to a lore reference is going to be
> an uphill battle.

Yeah, that was expected, but I didn't expect how often I had to explain
"yes, this is how the Link: tag is used, too, just check the docs"... :-D

> Right now, the best thing we have is the git hook that auto-adds the
> Link: tag that points to the lore thread where the patch came from.
> Maintainers don't have the energy or time to add anything other than
> that, so I think you just might have to rely on Fixes: for a while.

Yeah, guess you are right.

>> My proposed "introduce the commit message tags 'Reported:' and
>> 'Posted:'" patch likely would have helped here, but didn't get any
>> traction :-/
>> https://lore.kernel.org/lkml/c6724c7fb534a46e095e6aef13d996ed9589e578.1639042966.git.linux@leemhuis.info/
>>
>> Maybe that was partly due to the stupid mixup in the subject of the
>> cover letter, but whatever. So I guess I'll drop the bold idea. I
>> consider proposing to create "Reported: <url>" while leaving ambiguous
>> Link: alone, which will help my case. Note sure if I also should propose
>> to drop "Reported-by" at the same time, which makes things easier for
>> developers, as that tag can only be set after asking the reporter.
> 
> Nah, I add "Reported-by:" all the time without asking for explicit
> permission, relying on the public email instead.

It was also news to me that an explicit permission is needed, but
Documentation/process/5.Posting.rst states so: ``Be careful in the
addition of tags to your patches: only Cc: is appropriate for addition
without the explicit permission of the person named.```

>  If there was some way
> to automate the Reported: tag, maybe it could be used, but again, that's
> a lot of manual work to do, which is going to be a hard sell.

Yeah :-/

Ciao, Thorsten