On Sun, 7 Jun 2020, Alex Xu (Hello71) wrote:
On Sun, 7 Jun 2020, Pavel Machek wrote:
I have a similar issue, caused between aaa2faab4ed8 and b170290c2836.
[ 20.263098] BUG: unable to handle page fault for address: ffffb2b582cc2000 [ 20.263104] #PF: supervisor write access in kernel mode [ 20.263105] #PF: error_code(0x000b) - reserved bit violation [ 20.263107] PGD 3fd03b067 P4D 3fd03b067 PUD 3fd03c067 PMD 3f8822067 PTE 8000273942ab2163 [ 20.263113] Oops: 000b [#1] PREEMPT SMP [ 20.263117] CPU: 3 PID: 691 Comm: mpv Not tainted 5.7.0-11262-gb170290c2836 #1 [ 20.263119] Hardware name: To Be Filled By O.E.M. To Be Filled By O.E.M./B450 Pro4, BIOS P4.10 03/05/2020 [ 20.263125] RIP: 0010:__memset+0x24/0x30 [ 20.263128] Code: cc cc cc cc cc cc 0f 1f 44 00 00 49 89 f9 48 89 d1 83 e2 07 48 c1 e9 03 40 0f b6 f6 48 b8 01 01 01 01 01 01 01 01 48 0f af c6 <f3> 48 ab 89 d1 f3 aa 4c 89 c8 c3 90 49 89 f9 40 88 f0 48 89 d1 f3 [ 20.263131] RSP: 0018:ffffb2b583d07e10 EFLAGS: 00010216 [ 20.263133] RAX: 0000000000000000 RBX: ffff8b8000102c00 RCX: 0000000000004000 [ 20.263134] RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffffb2b582cc2000 [ 20.263136] RBP: ffff8b8000101000 R08: 0000000000000000 R09: ffffb2b582cc2000 [ 20.263137] R10: 0000000000005356 R11: ffff8b8000102c18 R12: 0000000000000000 [ 20.263139] R13: 0000000000000000 R14: ffff8b8039944200 R15: ffffffff9794daa0 [ 20.263141] FS: 00007f41aa4b4200(0000) GS:ffff8b803ecc0000(0000) knlGS:0000000000000000 [ 20.263143] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 20.263144] CR2: ffffb2b582cc2000 CR3: 00000003b6731000 CR4: 00000000003406e0 [ 20.263146] Call Trace: [ 20.263151] ? snd_pcm_hw_params+0x3f3/0x47a [ 20.263154] ? snd_pcm_common_ioctl+0xf2/0xf73 [ 20.263158] ? snd_pcm_ioctl+0x1e/0x29 [ 20.263161] ? ksys_ioctl+0x77/0x91 [ 20.263163] ? __x64_sys_ioctl+0x11/0x14 [ 20.263166] ? do_syscall_64+0x3d/0xf5 [ 20.263170] ? entry_SYSCALL_64_after_hwframe+0x44/0xa9 [ 20.263173] Modules linked in: uvcvideo videobuf2_vmalloc videobuf2_memops videobuf2_v4l2 videodev snd_usb_audio videobuf2_common snd_hwdep snd_usbmidi_lib input_leds snd_rawmidi led_class [ 20.263182] CR2: ffffb2b582cc2000 [ 20.263184] ---[ end trace c6b47a774b91f0a0 ]--- [ 20.263187] RIP: 0010:__memset+0x24/0x30 [ 20.263190] Code: cc cc cc cc cc cc 0f 1f 44 00 00 49 89 f9 48 89 d1 83 e2 07 48 c1 e9 03 40 0f b6 f6 48 b8 01 01 01 01 01 01 01 01 48 0f af c6 <f3> 48 ab 89 d1 f3 aa 4c 89 c8 c3 90 49 89 f9 40 88 f0 48 89 d1 f3 [ 20.263192] RSP: 0018:ffffb2b583d07e10 EFLAGS: 00010216 [ 20.263193] RAX: 0000000000000000 RBX: ffff8b8000102c00 RCX: 0000000000004000 [ 20.263195] RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffffb2b582cc2000 [ 20.263196] RBP: ffff8b8000101000 R08: 0000000000000000 R09: ffffb2b582cc2000 [ 20.263197] R10: 0000000000005356 R11: ffff8b8000102c18 R12: 0000000000000000 [ 20.263199] R13: 0000000000000000 R14: ffff8b8039944200 R15: ffffffff9794daa0 [ 20.263201] FS: 00007f41aa4b4200(0000) GS:ffff8b803ecc0000(0000) knlGS:0000000000000000 [ 20.263202] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 20.263204] CR2: ffffb2b582cc2000 CR3: 00000003b6731000 CR4: 00000000003406e0
I bisected this to 82fef0ad811f "x86/mm: unencrypted non-blocking DMA allocations use coherent pools". Reverting 1ee18de92927 resolves the issue.
Looks like Thinkpad X60 doesn't have VT-d, but could still be DMA related.
Note that newer -next releases seem to behave okay for me. The commit pointed out by siection is really simple:
AFAIK you could verify it is responsible by turning off CONFIG_AMD_MEM_ENCRYPT on latest kernel...
Best regards, Pavel
index 1d6104ea8af0..2bf2222819d3 100644 --- a/arch/x86/Kconfig +++ b/arch/x86/Kconfig @@ -1520,6 +1520,7 @@ config X86_CPA_STATISTICS config AMD_MEM_ENCRYPT bool "AMD Secure Memory Encryption (SME) support" depends on X86_64 && CPU_SUP_AMD
select DMA_COHERENT_POOL select DYNAMIC_PHYSICAL_MASK select ARCH_USE_MEMREMAP_PROT select ARCH_HAS_FORCE_DMA_UNENCRYPTEDThanks for the report!
Besides CONFIG_AMD_MEM_ENCRYPT, do you have CONFIG_DMA_DIRECT_REMAP enabled? If so, it may be caused by the virtual address passed to the set_memory_{decrypted,encrypted}() functions.
And I assume you are enabling SME by using mem_encrypt=on on the kernel command line or CONFIG_AMD_MEM_ENCRYPT_ACTIVE_BY_DEFAULT is enabled.
We likely need an atomic pool for devices that support DMA to addresses in sme_me_mask as well. I can test this tomorrow, but wanted to get it out early to see if it helps?
This patch doesn't seem to help. I have the same problem (kernel page fault, __memset, snd_pcm_hw_params...).
I don't have CONFIG_DMA_DIRECT_REMAP enabled, and AFAICT it doesn't seem to be selectable currently on x86, unless there are some patches floating around for that.
Thanks for trying it out, Alex. Would you mind sending your .config and command line? I assume either mem_encrypt=on or CONFIG_AMD_MEM_ENCRYPT_ACTIVE_BY_DEFAULT is enabled.
Could you also give this a try?
diff --git a/kernel/dma/direct.c b/kernel/dma/direct.c --- a/kernel/dma/direct.c +++ b/kernel/dma/direct.c @@ -99,10 +99,11 @@ static inline bool dma_should_alloc_from_pool(struct device *dev, gfp_t gfp, static inline bool dma_should_free_from_pool(struct device *dev, unsigned long attrs) { - if (IS_ENABLED(CONFIG_DMA_COHERENT_POOL)) + if (!IS_ENABLED(CONFIG_DMA_COHERENT_POOL)) + return false; + if (force_dma_unencrypted(dev)) return true; - if ((attrs & DMA_ATTR_NO_KERNEL_MAPPING) && - !force_dma_unencrypted(dev)) + if (attrs & DMA_ATTR_NO_KERNEL_MAPPING) return false; if (IS_ENABLED(CONFIG_DMA_DIRECT_REMAP)) return true;