linux-kernel - Re: [PATCH 0/5] iommu/amd: fixes for suspend/resume

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <6f0d9b07073ca6d3657500ec076edc1ad2a3e40a.camel@redhat.com>
Date:   Tue, 25 Jan 2022 21:26:21 +0200
From:   Maxim Levitsky <mlevitsk@...hat.com>
To:     Mike Lothian <mike@...eburn.co.uk>
Cc:     dwmw@...zon.co.uk, iommu@...ts.linux-foundation.org,
        joro@...tes.org, linux-kernel@...r.kernel.org,
        suravee.suthikulpanit@....com, tglx@...utronix.de, will@...nel.org
Subject: Re: [PATCH 0/5] iommu/amd: fixes for suspend/resume

On Tue, 2022-01-25 at 15:08 +0000, Mike Lothian wrote:
> Hi
> 
> I'm seeing a WARNING that I think might be related to these patches, unfortunately another issue is making bisecting difficult
> 
> [    0.359362] AMD-Vi: X2APIC enabled
> [    0.395140] ------------[ cut here ]------------
> [    0.395142] WARNING: CPU: 0 PID: 1 at amd_iommu_enable_interrupts+0x1da/0x440
> [    0.395146] Modules linked in:
> [    0.395148] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 5.17.0-rc1-tip+ #2995
> [    0.395150] Hardware name: ASUSTeK COMPUTER INC. ROG Strix G513QY_G513QY/G513QY, BIOS G513QY.316 11/29/2021
> [    0.395152] RIP: 0010:amd_iommu_enable_interrupts+0x1da/0x440
> [    0.395154] Code: 4b 38 48 89 41 18 b8 a0 86 01 00 0f 1f 44 00 00 48 8b 4b 38 8b 89 20 20 00 00 f7 c1 00 01 00 00 0f 85 7a fe ff ff ff c8 75 e6 <0f> 0b e9 6f fe ff ff 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00
> [    0.395157] RSP: 0018:ffff88810022fc68 EFLAGS: 00010246
> [    0.395158] RAX: 0000000000000000 RBX: ffff88810004b000 RCX: 0000000000000018
> [    0.395160] RDX: 0000000000000008 RSI: ffff88810022fc70 RDI: ffffc900000800f0
> [    0.395161] RBP: ffff88810022fc68 R08: ffff888100fce088 R09: 0000000000000000
> [    0.395162] R10: 0000000000000000 R11: ffffffffffffffff R12: ffffffff7fffffff
> [    0.395163] R13: 0000777f80000000 R14: 0000000000000000 R15: ffffffff8357c9e8
> [    0.395165] FS:  0000000000000000(0000) GS:ffff888fde400000(0000) knlGS:0000000000000000
> [    0.395166] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> [    0.395167] CR2: ffff88901e1ff000 CR3: 00000000b440c000 CR4: 0000000000150ef0
> [    0.395169] Call Trace:
> [    0.395170]  <TASK>
> [    0.395171]  ? iommu_setup+0x29a/0x29a
> [    0.395174]  ? state_next+0x6e/0x1c9
> [    0.395177]  ? iommu_setup+0x29a/0x29a
> [    0.395178]  ? iommu_go_to_state+0x1f/0x33
> [    0.395180]  ? amd_iommu_init+0xa/0x23
> [    0.395182]  ? pci_iommu_init+0xf/0x45
> [    0.395183]  ? iommu_setup+0x29a/0x29a
> [    0.395184]  ? __initstub__kmod_pci_dma__250_136_pci_iommu_initrootfs+0x5/0x8
> [    0.395186]  ? do_one_initcall+0x100/0x290
> [    0.395190]  ? do_initcall_level+0x8b/0xe5
> [    0.395192]  ? do_initcalls+0x44/0x6d
> [    0.395194]  ? kernel_init_freeable+0xc7/0x10d
> [    0.395196]  ? rest_init+0xc0/0xc0
> [    0.395198]  ? kernel_init+0x11/0x150
> [    0.395200]  ? ret_from_fork+0x22/0x30
> [    0.395201]  </TASK>
> [    0.395202] ---[ end trace 0000000000000000 ]---
> [    0.395204] PCI-DMA: Using software bounce buffer
> 
> Let me know if you need any more info
> 
> Cheers
> 
> Mike


Could you just apply these patches on top of 5.15 kernel and see if you get the warning?

If something could case it is I think patch 1, it does move the GA log enabled
to be a bit later.
I also added few warnings there. I wonder why your dmesg quote doesn't contain the C line
where the warning happens.

In partucular I added:

if (WARN_ON(status & (MMIO_STATUS_GALOG_RUN_MASK)))

That will fire if GA log is already running (maybe BIOS enabled it? - it really shouldn't do that)


And that:

if (WARN_ON(i >= LOOP_TIMEOUT))

also should not happen and worth to be logged IMHO.

Best regards,
	Maxim Levitsky