* udmabuf vmap failed (Revert "udmabuf: fix vmap_udmabuf error page set" can help) @ 2025-03-11 6:40 Bingbu Cao 2025-03-11 7:12 ` Huan Yang 0 siblings, 1 reply; 9+ messages in thread From: Bingbu Cao @ 2025-03-11 6:40 UTC (permalink / raw) To: link, vivek.kasireddy; +Cc: linux-kernel, christian.koenig, dri-devel Huan Yang and Vivek, I am trying to use udmabuf for my test, and I cannot vmap the udmabuf buffers now. vmap_pfn_apply() will report a warning to complain that the pfns are invalid. I dump the pfn numbers as below: [ 3365.399641] pg[0] pfn 1148695 [ 3365.399642] pg[1] pfn 1145057 [ 3365.399642] pg[2] pfn 1134070 [ 3365.399643] pg[3] pfn 1148700 [ 3365.399643] pg[4] pfn 1144871 [ 3365.399643] pg[5] pfn 1408686 [ 3365.399643] pg[6] pfn 1408683 ... [ 3365.399660] WARNING: CPU: 3 PID: 2772 at mm/vmalloc.c:3489 vmap_pfn_apply+0xb7/0xd0 [ 3365.399667] Modules linked in:... [ 3365.399750] CPU: 3 UID: 0 PID: 2772 Comm: drm-test Not tainted 6.13.0-rc2-rvp #845 [ 3365.399752] Hardware name: Intel Corporation Client Platform/xxxx, BIOS xxxFWI1.R00.3221.D83.2408120121 08/12/2024 [ 3365.399753] RIP: 0010:vmap_pfn_apply+0xb7/0xd0 [ 3365.399755] Code: 5b 41 5c 41 5d 5d c3 cc cc cc cc 48 21 c3 eb d1 48 21 c3 48 23 3d 31 c0 26 02 eb c5 48 c7 c7 c4 3c 20 a8 e8 5b c0 d8 ff eb 8a <0f> 0b b8 ea ff ff ff 5b 41 5c 41 5d 5d c3 cc cc cc cc 0f 1f 80 00 [ 3365.399756] RSP: 0018:ffffb9b50c32fad0 EFLAGS: 00010202 [ 3365.399757] RAX: 0000000000000001 RBX: 0000000000118717 RCX: 0000000000000000 [ 3365.399758] RDX: 0000000080000000 RSI: ffffb9b50c358000 RDI: 00000000ffffffff [ 3365.399758] RBP: ffffb9b50c32fae8 R08: ffffb9b50c32fbd0 R09: 0000000000000001 [ 3365.399759] R10: ffff941602479288 R11: 0000000000000000 R12: ffffb9b50c32fbd0 [ 3365.399759] R13: ffff941618665ac0 R14: ffffb9b50c358000 R15: ffff941618665ac8 [ 3365.399760] FS: 00007ff9e9ddd740(0000) GS:ffff94196f780000(0000) knlGS:0000000000000000 [ 3365.399760] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 3365.399761] CR2: 000055fda5dc69d9 CR3: 00000001544de003 CR4: 0000000000f72ef0 [ 3365.399762] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 3365.399762] DR3: 0000000000000000 DR6: 00000000ffff07f0 DR7: 0000000000000400 [ 3365.399763] PKRU: 55555554 [ 3365.399763] Call Trace: [ 3365.399765] <TASK> [ 3365.399769] ? show_regs+0x6d/0x80 [ 3365.399773] ? __warn+0x97/0x160 [ 3365.399777] ? vmap_pfn_apply+0xb7/0xd0 [ 3365.399777] ? report_bug+0x1ec/0x240 [ 3365.399782] ? handle_bug+0x63/0xa0 [ 3365.399784] ? exc_invalid_op+0x1d/0x80 [ 3365.399785] ? asm_exc_invalid_op+0x1f/0x30 [ 3365.399790] ? vmap_pfn_apply+0xb7/0xd0 [ 3365.399791] __apply_to_page_range+0x522/0x8a0 [ 3365.399794] ? __pfx_vmap_pfn_apply+0x10/0x10 [ 3365.399795] apply_to_page_range+0x18/0x20 [ 3365.399796] vmap_pfn+0x77/0xd0 [ 3365.399797] vmap_udmabuf+0xc5/0x110 [ 3365.399802] dma_buf_vmap+0x96/0x130 I did an experiment to revert 18d7de823b7150344d242c3677e65d68c5271b04, then I can vmap the pages. Could you help what's wrong with that? -- Best regards, Bingbu Cao ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: udmabuf vmap failed (Revert "udmabuf: fix vmap_udmabuf error page set" can help) 2025-03-11 6:40 udmabuf vmap failed (Revert "udmabuf: fix vmap_udmabuf error page set" can help) Bingbu Cao @ 2025-03-11 7:12 ` Huan Yang 2025-03-11 8:42 ` Bingbu Cao 0 siblings, 1 reply; 9+ messages in thread From: Huan Yang @ 2025-03-11 7:12 UTC (permalink / raw) To: Bingbu Cao, vivek.kasireddy; +Cc: linux-kernel, christian.koenig, dri-devel 在 2025/3/11 14:40, Bingbu Cao 写道: > [You don't often get email from bingbu.cao@linux.intel.com. Learn why this is important at https://aka.ms/LearnAboutSenderIdentification ] > > Huan Yang and Vivek, > > I am trying to use udmabuf for my test, and I cannot vmap the udmabuf > buffers now. vmap_pfn_apply() will report a warning to complain that > the pfns are invalid. > I dump the pfn numbers as below: > [ 3365.399641] pg[0] pfn 1148695 > [ 3365.399642] pg[1] pfn 1145057 > [ 3365.399642] pg[2] pfn 1134070 > [ 3365.399643] pg[3] pfn 1148700 > [ 3365.399643] pg[4] pfn 1144871 > [ 3365.399643] pg[5] pfn 1408686 > [ 3365.399643] pg[6] pfn 1408683 > ... > [ 3365.399660] WARNING: CPU: 3 PID: 2772 at mm/vmalloc.c:3489 vmap_pfn_apply+0xb7/0xd0 > [ 3365.399667] Modules linked in:... > [ 3365.399750] CPU: 3 UID: 0 PID: 2772 Comm: drm-test Not tainted 6.13.0-rc2-rvp #845 > [ 3365.399752] Hardware name: Intel Corporation Client Platform/xxxx, BIOS xxxFWI1.R00.3221.D83.2408120121 08/12/2024 > [ 3365.399753] RIP: 0010:vmap_pfn_apply+0xb7/0xd0 > [ 3365.399755] Code: 5b 41 5c 41 5d 5d c3 cc cc cc cc 48 21 c3 eb d1 48 21 c3 48 23 3d 31 c0 26 02 eb c5 48 c7 c7 c4 3c 20 a8 e8 5b c0 d8 ff eb 8a <0f> 0b b8 ea ff ff ff 5b 41 5c 41 5d 5d c3 cc cc cc cc 0f 1f 80 00 > [ 3365.399756] RSP: 0018:ffffb9b50c32fad0 EFLAGS: 00010202 > [ 3365.399757] RAX: 0000000000000001 RBX: 0000000000118717 RCX: 0000000000000000 > [ 3365.399758] RDX: 0000000080000000 RSI: ffffb9b50c358000 RDI: 00000000ffffffff > [ 3365.399758] RBP: ffffb9b50c32fae8 R08: ffffb9b50c32fbd0 R09: 0000000000000001 > [ 3365.399759] R10: ffff941602479288 R11: 0000000000000000 R12: ffffb9b50c32fbd0 > [ 3365.399759] R13: ffff941618665ac0 R14: ffffb9b50c358000 R15: ffff941618665ac8 > [ 3365.399760] FS: 00007ff9e9ddd740(0000) GS:ffff94196f780000(0000) knlGS:0000000000000000 > [ 3365.399760] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 > [ 3365.399761] CR2: 000055fda5dc69d9 CR3: 00000001544de003 CR4: 0000000000f72ef0 > [ 3365.399762] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 > [ 3365.399762] DR3: 0000000000000000 DR6: 00000000ffff07f0 DR7: 0000000000000400 > [ 3365.399763] PKRU: 55555554 > [ 3365.399763] Call Trace: > [ 3365.399765] <TASK> > [ 3365.399769] ? show_regs+0x6d/0x80 > [ 3365.399773] ? __warn+0x97/0x160 > [ 3365.399777] ? vmap_pfn_apply+0xb7/0xd0 > [ 3365.399777] ? report_bug+0x1ec/0x240 > [ 3365.399782] ? handle_bug+0x63/0xa0 > [ 3365.399784] ? exc_invalid_op+0x1d/0x80 > [ 3365.399785] ? asm_exc_invalid_op+0x1f/0x30 > [ 3365.399790] ? vmap_pfn_apply+0xb7/0xd0 > [ 3365.399791] __apply_to_page_range+0x522/0x8a0 > [ 3365.399794] ? __pfx_vmap_pfn_apply+0x10/0x10 > [ 3365.399795] apply_to_page_range+0x18/0x20 > [ 3365.399796] vmap_pfn+0x77/0xd0 > [ 3365.399797] vmap_udmabuf+0xc5/0x110 > [ 3365.399802] dma_buf_vmap+0x96/0x130 > > I did an experiment to revert 18d7de823b7150344d242c3677e65d68c5271b04, > then I can vmap the pages. Could you help what's wrong with that? Sorry for that, as I reviewed pfn_valid, that's someting wired: /** * pfn_valid - check if there is a valid memory map entry for a PFN * @pfn: the page frame number to check * * Check if there is a valid memory map entry aka struct page for the @pfn. * Note, that availability of the memory map entry does not imply that * there is actual usable memory at that @pfn. The struct page may * represent a hole or an unusable page frame. * * Return: 1 for PFNs that have memory map entries and 0 otherwise */ So, if pfn valid, it's return 1, else 0. So mean, only 1 is a valid pfn. But vmap_pfn_apply in there: static int vmap_pfn_apply(pte_t *pte, unsigned long addr, void *private) { struct vmap_pfn_data *data = private; unsigned long pfn = data->pfns[data->idx]; pte_t ptent; if (WARN_ON_ONCE(pfn_valid(pfn))) return -EINVAL; ptent = pte_mkspecial(pfn_pte(pfn, data->prot)); set_pte_at(&init_mm, addr, pte, ptent); data->idx++; return 0; } Do it give a wrong check? maybe should fix by: static int vmap_pfn_apply(pte_t *pte, unsigned long addr, void *private) { struct vmap_pfn_data *data = private; unsigned long pfn = data->pfns[data->idx]; pte_t ptent; - if (WARN_ON_ONCE(pfn_valid(pfn))) + if (WARN_ON_ONCE(!pfn_valid(pfn))) return -EINVAL; ptent = pte_mkspecial(pfn_pte(pfn, data->prot)); set_pte_at(&init_mm, addr, pte, ptent); data->idx++; return 0; } Please help me check it, also, you can apply this and then check it.:) > > > -- > Best regards, > Bingbu Cao ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: udmabuf vmap failed (Revert "udmabuf: fix vmap_udmabuf error page set" can help) 2025-03-11 7:12 ` Huan Yang @ 2025-03-11 8:42 ` Bingbu Cao 2025-03-11 8:54 ` Huan Yang 0 siblings, 1 reply; 9+ messages in thread From: Bingbu Cao @ 2025-03-11 8:42 UTC (permalink / raw) To: Huan Yang, vivek.kasireddy; +Cc: linux-kernel, christian.koenig, dri-devel Huan, Thanks for your response. On 3/11/25 3:12 PM, Huan Yang wrote: > > 在 2025/3/11 14:40, Bingbu Cao 写道: >> [You don't often get email from bingbu.cao@linux.intel.com. Learn why this is important at https://aka.ms/LearnAboutSenderIdentification ] >> >> Huan Yang and Vivek, >> >> I am trying to use udmabuf for my test, and I cannot vmap the udmabuf >> buffers now. vmap_pfn_apply() will report a warning to complain that >> the pfns are invalid. >> I dump the pfn numbers as below: >> [ 3365.399641] pg[0] pfn 1148695 >> [ 3365.399642] pg[1] pfn 1145057 >> [ 3365.399642] pg[2] pfn 1134070 >> [ 3365.399643] pg[3] pfn 1148700 >> [ 3365.399643] pg[4] pfn 1144871 >> [ 3365.399643] pg[5] pfn 1408686 >> [ 3365.399643] pg[6] pfn 1408683 >> ... >> [ 3365.399660] WARNING: CPU: 3 PID: 2772 at mm/vmalloc.c:3489 vmap_pfn_apply+0xb7/0xd0 >> [ 3365.399667] Modules linked in:... >> [ 3365.399750] CPU: 3 UID: 0 PID: 2772 Comm: drm-test Not tainted 6.13.0-rc2-rvp #845 >> [ 3365.399752] Hardware name: Intel Corporation Client Platform/xxxx, BIOS xxxFWI1.R00.3221.D83.2408120121 08/12/2024 >> [ 3365.399753] RIP: 0010:vmap_pfn_apply+0xb7/0xd0 >> [ 3365.399755] Code: 5b 41 5c 41 5d 5d c3 cc cc cc cc 48 21 c3 eb d1 48 21 c3 48 23 3d 31 c0 26 02 eb c5 48 c7 c7 c4 3c 20 a8 e8 5b c0 d8 ff eb 8a <0f> 0b b8 ea ff ff ff 5b 41 5c 41 5d 5d c3 cc cc cc cc 0f 1f 80 00 >> [ 3365.399756] RSP: 0018:ffffb9b50c32fad0 EFLAGS: 00010202 >> [ 3365.399757] RAX: 0000000000000001 RBX: 0000000000118717 RCX: 0000000000000000 >> [ 3365.399758] RDX: 0000000080000000 RSI: ffffb9b50c358000 RDI: 00000000ffffffff >> [ 3365.399758] RBP: ffffb9b50c32fae8 R08: ffffb9b50c32fbd0 R09: 0000000000000001 >> [ 3365.399759] R10: ffff941602479288 R11: 0000000000000000 R12: ffffb9b50c32fbd0 >> [ 3365.399759] R13: ffff941618665ac0 R14: ffffb9b50c358000 R15: ffff941618665ac8 >> [ 3365.399760] FS: 00007ff9e9ddd740(0000) GS:ffff94196f780000(0000) knlGS:0000000000000000 >> [ 3365.399760] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 >> [ 3365.399761] CR2: 000055fda5dc69d9 CR3: 00000001544de003 CR4: 0000000000f72ef0 >> [ 3365.399762] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 >> [ 3365.399762] DR3: 0000000000000000 DR6: 00000000ffff07f0 DR7: 0000000000000400 >> [ 3365.399763] PKRU: 55555554 >> [ 3365.399763] Call Trace: >> [ 3365.399765] <TASK> >> [ 3365.399769] ? show_regs+0x6d/0x80 >> [ 3365.399773] ? __warn+0x97/0x160 >> [ 3365.399777] ? vmap_pfn_apply+0xb7/0xd0 >> [ 3365.399777] ? report_bug+0x1ec/0x240 >> [ 3365.399782] ? handle_bug+0x63/0xa0 >> [ 3365.399784] ? exc_invalid_op+0x1d/0x80 >> [ 3365.399785] ? asm_exc_invalid_op+0x1f/0x30 >> [ 3365.399790] ? vmap_pfn_apply+0xb7/0xd0 >> [ 3365.399791] __apply_to_page_range+0x522/0x8a0 >> [ 3365.399794] ? __pfx_vmap_pfn_apply+0x10/0x10 >> [ 3365.399795] apply_to_page_range+0x18/0x20 >> [ 3365.399796] vmap_pfn+0x77/0xd0 >> [ 3365.399797] vmap_udmabuf+0xc5/0x110 >> [ 3365.399802] dma_buf_vmap+0x96/0x130 >> >> I did an experiment to revert 18d7de823b7150344d242c3677e65d68c5271b04, >> then I can vmap the pages. Could you help what's wrong with that? > > Sorry for that, as I reviewed pfn_valid, that's someting wired: > > /** > * pfn_valid - check if there is a valid memory map entry for a PFN > * @pfn: the page frame number to check > * > * Check if there is a valid memory map entry aka struct page for the @pfn. > * Note, that availability of the memory map entry does not imply that > * there is actual usable memory at that @pfn. The struct page may > * represent a hole or an unusable page frame. > * > * Return: 1 for PFNs that have memory map entries and 0 otherwise > */ > > So, if pfn valid, it's return 1, else 0. So mean, only 1 is a valid pfn. But vmap_pfn_apply in there: > > static int vmap_pfn_apply(pte_t *pte, unsigned long addr, void *private) > { > struct vmap_pfn_data *data = private; > unsigned long pfn = data->pfns[data->idx]; > pte_t ptent; > > if (WARN_ON_ONCE(pfn_valid(pfn))) > return -EINVAL; > > ptent = pte_mkspecial(pfn_pte(pfn, data->prot)); > set_pte_at(&init_mm, addr, pte, ptent); > > data->idx++; > return 0; > } > > Do it give a wrong check? maybe should fix by: I guess not, it looks more like warning when you trying to vmap a pfn which already took a valid entry in pte. However, the MM code is so complex for me, just my guess. :) > > static int vmap_pfn_apply(pte_t *pte, unsigned long addr, void *private) > { > struct vmap_pfn_data *data = private; > unsigned long pfn = data->pfns[data->idx]; > pte_t ptent; > > - if (WARN_ON_ONCE(pfn_valid(pfn))) > + if (WARN_ON_ONCE(!pfn_valid(pfn))) > return -EINVAL; > > ptent = pte_mkspecial(pfn_pte(pfn, data->prot)); > set_pte_at(&init_mm, addr, pte, ptent); > > data->idx++; > return 0; > } > > Please help me check it, also, you can apply this and then check it.:) > >> >> >> -- >> Best regards, >> Bingbu Cao -- Best regards, Bingbu Cao ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: udmabuf vmap failed (Revert "udmabuf: fix vmap_udmabuf error page set" can help) 2025-03-11 8:42 ` Bingbu Cao @ 2025-03-11 8:54 ` Huan Yang 2025-03-11 9:02 ` Bingbu Cao 0 siblings, 1 reply; 9+ messages in thread From: Huan Yang @ 2025-03-11 8:54 UTC (permalink / raw) To: Bingbu Cao, vivek.kasireddy; +Cc: linux-kernel, christian.koenig, dri-devel 在 2025/3/11 16:42, Bingbu Cao 写道: > [You don't often get email from bingbu.cao@linux.intel.com. Learn why this is important at https://aka.ms/LearnAboutSenderIdentification ] > > Huan, > > Thanks for your response. > > On 3/11/25 3:12 PM, Huan Yang wrote: >> 在 2025/3/11 14:40, Bingbu Cao 写道: >>> [You don't often get email from bingbu.cao@linux.intel.com. Learn why this is important at https://aka.ms/LearnAboutSenderIdentification ] >>> >>> Huan Yang and Vivek, >>> >>> I am trying to use udmabuf for my test, and I cannot vmap the udmabuf >>> buffers now. vmap_pfn_apply() will report a warning to complain that >>> the pfns are invalid. >>> I dump the pfn numbers as below: >>> [ 3365.399641] pg[0] pfn 1148695 >>> [ 3365.399642] pg[1] pfn 1145057 >>> [ 3365.399642] pg[2] pfn 1134070 >>> [ 3365.399643] pg[3] pfn 1148700 >>> [ 3365.399643] pg[4] pfn 1144871 >>> [ 3365.399643] pg[5] pfn 1408686 >>> [ 3365.399643] pg[6] pfn 1408683 >>> ... >>> [ 3365.399660] WARNING: CPU: 3 PID: 2772 at mm/vmalloc.c:3489 vmap_pfn_apply+0xb7/0xd0 >>> [ 3365.399667] Modules linked in:... >>> [ 3365.399750] CPU: 3 UID: 0 PID: 2772 Comm: drm-test Not tainted 6.13.0-rc2-rvp #845 >>> [ 3365.399752] Hardware name: Intel Corporation Client Platform/xxxx, BIOS xxxFWI1.R00.3221.D83.2408120121 08/12/2024 >>> [ 3365.399753] RIP: 0010:vmap_pfn_apply+0xb7/0xd0 >>> [ 3365.399755] Code: 5b 41 5c 41 5d 5d c3 cc cc cc cc 48 21 c3 eb d1 48 21 c3 48 23 3d 31 c0 26 02 eb c5 48 c7 c7 c4 3c 20 a8 e8 5b c0 d8 ff eb 8a <0f> 0b b8 ea ff ff ff 5b 41 5c 41 5d 5d c3 cc cc cc cc 0f 1f 80 00 >>> [ 3365.399756] RSP: 0018:ffffb9b50c32fad0 EFLAGS: 00010202 >>> [ 3365.399757] RAX: 0000000000000001 RBX: 0000000000118717 RCX: 0000000000000000 >>> [ 3365.399758] RDX: 0000000080000000 RSI: ffffb9b50c358000 RDI: 00000000ffffffff >>> [ 3365.399758] RBP: ffffb9b50c32fae8 R08: ffffb9b50c32fbd0 R09: 0000000000000001 >>> [ 3365.399759] R10: ffff941602479288 R11: 0000000000000000 R12: ffffb9b50c32fbd0 >>> [ 3365.399759] R13: ffff941618665ac0 R14: ffffb9b50c358000 R15: ffff941618665ac8 >>> [ 3365.399760] FS: 00007ff9e9ddd740(0000) GS:ffff94196f780000(0000) knlGS:0000000000000000 >>> [ 3365.399760] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 >>> [ 3365.399761] CR2: 000055fda5dc69d9 CR3: 00000001544de003 CR4: 0000000000f72ef0 >>> [ 3365.399762] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 >>> [ 3365.399762] DR3: 0000000000000000 DR6: 00000000ffff07f0 DR7: 0000000000000400 >>> [ 3365.399763] PKRU: 55555554 >>> [ 3365.399763] Call Trace: >>> [ 3365.399765] <TASK> >>> [ 3365.399769] ? show_regs+0x6d/0x80 >>> [ 3365.399773] ? __warn+0x97/0x160 >>> [ 3365.399777] ? vmap_pfn_apply+0xb7/0xd0 >>> [ 3365.399777] ? report_bug+0x1ec/0x240 >>> [ 3365.399782] ? handle_bug+0x63/0xa0 >>> [ 3365.399784] ? exc_invalid_op+0x1d/0x80 >>> [ 3365.399785] ? asm_exc_invalid_op+0x1f/0x30 >>> [ 3365.399790] ? vmap_pfn_apply+0xb7/0xd0 >>> [ 3365.399791] __apply_to_page_range+0x522/0x8a0 >>> [ 3365.399794] ? __pfx_vmap_pfn_apply+0x10/0x10 >>> [ 3365.399795] apply_to_page_range+0x18/0x20 >>> [ 3365.399796] vmap_pfn+0x77/0xd0 >>> [ 3365.399797] vmap_udmabuf+0xc5/0x110 >>> [ 3365.399802] dma_buf_vmap+0x96/0x130 >>> >>> I did an experiment to revert 18d7de823b7150344d242c3677e65d68c5271b04, >>> then I can vmap the pages. Could you help what's wrong with that? >> Sorry for that, as I reviewed pfn_valid, that's someting wired: >> >> /** >> * pfn_valid - check if there is a valid memory map entry for a PFN >> * @pfn: the page frame number to check >> * >> * Check if there is a valid memory map entry aka struct page for the @pfn. >> * Note, that availability of the memory map entry does not imply that >> * there is actual usable memory at that @pfn. The struct page may >> * represent a hole or an unusable page frame. >> * >> * Return: 1 for PFNs that have memory map entries and 0 otherwise >> */ >> >> So, if pfn valid, it's return 1, else 0. So mean, only 1 is a valid pfn. But vmap_pfn_apply in there: >> >> static int vmap_pfn_apply(pte_t *pte, unsigned long addr, void *private) >> { >> struct vmap_pfn_data *data = private; >> unsigned long pfn = data->pfns[data->idx]; >> pte_t ptent; >> >> if (WARN_ON_ONCE(pfn_valid(pfn))) >> return -EINVAL; >> >> ptent = pte_mkspecial(pfn_pte(pfn, data->prot)); >> set_pte_at(&init_mm, addr, pte, ptent); >> >> data->idx++; >> return 0; >> } >> >> Do it give a wrong check? maybe should fix by: > I guess not, it looks more like warning when you trying to vmap a > pfn which already took a valid entry in pte. No, I think here check need pfn is valid, then can set it. If a pfn is invalid, why we set it in PTE? Also, I can't make sure. BTW, can you fix it then retest? Thank you. > > However, the MM code is so complex for me, just my guess. :) > >> static int vmap_pfn_apply(pte_t *pte, unsigned long addr, void *private) >> { >> struct vmap_pfn_data *data = private; >> unsigned long pfn = data->pfns[data->idx]; >> pte_t ptent; >> >> - if (WARN_ON_ONCE(pfn_valid(pfn))) >> + if (WARN_ON_ONCE(!pfn_valid(pfn))) >> return -EINVAL; >> >> ptent = pte_mkspecial(pfn_pte(pfn, data->prot)); >> set_pte_at(&init_mm, addr, pte, ptent); >> >> data->idx++; >> return 0; >> } >> >> Please help me check it, also, you can apply this and then check it.:) >> >>> >>> -- >>> Best regards, >>> Bingbu Cao > -- > Best regards, > Bingbu Cao ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: udmabuf vmap failed (Revert "udmabuf: fix vmap_udmabuf error page set" can help) 2025-03-11 8:54 ` Huan Yang @ 2025-03-11 9:02 ` Bingbu Cao 2025-03-11 9:34 ` Huan Yang 0 siblings, 1 reply; 9+ messages in thread From: Bingbu Cao @ 2025-03-11 9:02 UTC (permalink / raw) To: Huan Yang, vivek.kasireddy, ryan.roberts, hch Cc: linux-kernel, christian.koenig, dri-devel Christoph and Ryan, Could you help check this? Thanks. On 3/11/25 4:54 PM, Huan Yang wrote: > > 在 2025/3/11 16:42, Bingbu Cao 写道: >> [You don't often get email from bingbu.cao@linux.intel.com. Learn why this is important at https://aka.ms/LearnAboutSenderIdentification ] >> >> Huan, >> >> Thanks for your response. >> >> On 3/11/25 3:12 PM, Huan Yang wrote: >>> 在 2025/3/11 14:40, Bingbu Cao 写道: >>>> [You don't often get email from bingbu.cao@linux.intel.com. Learn why this is important at https://aka.ms/LearnAboutSenderIdentification ] >>>> >>>> Huan Yang and Vivek, >>>> >>>> I am trying to use udmabuf for my test, and I cannot vmap the udmabuf >>>> buffers now. vmap_pfn_apply() will report a warning to complain that >>>> the pfns are invalid. >>>> I dump the pfn numbers as below: >>>> [ 3365.399641] pg[0] pfn 1148695 >>>> [ 3365.399642] pg[1] pfn 1145057 >>>> [ 3365.399642] pg[2] pfn 1134070 >>>> [ 3365.399643] pg[3] pfn 1148700 >>>> [ 3365.399643] pg[4] pfn 1144871 >>>> [ 3365.399643] pg[5] pfn 1408686 >>>> [ 3365.399643] pg[6] pfn 1408683 >>>> ... >>>> [ 3365.399660] WARNING: CPU: 3 PID: 2772 at mm/vmalloc.c:3489 vmap_pfn_apply+0xb7/0xd0 >>>> [ 3365.399667] Modules linked in:... >>>> [ 3365.399750] CPU: 3 UID: 0 PID: 2772 Comm: drm-test Not tainted 6.13.0-rc2-rvp #845 >>>> [ 3365.399752] Hardware name: Intel Corporation Client Platform/xxxx, BIOS xxxFWI1.R00.3221.D83.2408120121 08/12/2024 >>>> [ 3365.399753] RIP: 0010:vmap_pfn_apply+0xb7/0xd0 >>>> [ 3365.399755] Code: 5b 41 5c 41 5d 5d c3 cc cc cc cc 48 21 c3 eb d1 48 21 c3 48 23 3d 31 c0 26 02 eb c5 48 c7 c7 c4 3c 20 a8 e8 5b c0 d8 ff eb 8a <0f> 0b b8 ea ff ff ff 5b 41 5c 41 5d 5d c3 cc cc cc cc 0f 1f 80 00 >>>> [ 3365.399756] RSP: 0018:ffffb9b50c32fad0 EFLAGS: 00010202 >>>> [ 3365.399757] RAX: 0000000000000001 RBX: 0000000000118717 RCX: 0000000000000000 >>>> [ 3365.399758] RDX: 0000000080000000 RSI: ffffb9b50c358000 RDI: 00000000ffffffff >>>> [ 3365.399758] RBP: ffffb9b50c32fae8 R08: ffffb9b50c32fbd0 R09: 0000000000000001 >>>> [ 3365.399759] R10: ffff941602479288 R11: 0000000000000000 R12: ffffb9b50c32fbd0 >>>> [ 3365.399759] R13: ffff941618665ac0 R14: ffffb9b50c358000 R15: ffff941618665ac8 >>>> [ 3365.399760] FS: 00007ff9e9ddd740(0000) GS:ffff94196f780000(0000) knlGS:0000000000000000 >>>> [ 3365.399760] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 >>>> [ 3365.399761] CR2: 000055fda5dc69d9 CR3: 00000001544de003 CR4: 0000000000f72ef0 >>>> [ 3365.399762] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 >>>> [ 3365.399762] DR3: 0000000000000000 DR6: 00000000ffff07f0 DR7: 0000000000000400 >>>> [ 3365.399763] PKRU: 55555554 >>>> [ 3365.399763] Call Trace: >>>> [ 3365.399765] <TASK> >>>> [ 3365.399769] ? show_regs+0x6d/0x80 >>>> [ 3365.399773] ? __warn+0x97/0x160 >>>> [ 3365.399777] ? vmap_pfn_apply+0xb7/0xd0 >>>> [ 3365.399777] ? report_bug+0x1ec/0x240 >>>> [ 3365.399782] ? handle_bug+0x63/0xa0 >>>> [ 3365.399784] ? exc_invalid_op+0x1d/0x80 >>>> [ 3365.399785] ? asm_exc_invalid_op+0x1f/0x30 >>>> [ 3365.399790] ? vmap_pfn_apply+0xb7/0xd0 >>>> [ 3365.399791] __apply_to_page_range+0x522/0x8a0 >>>> [ 3365.399794] ? __pfx_vmap_pfn_apply+0x10/0x10 >>>> [ 3365.399795] apply_to_page_range+0x18/0x20 >>>> [ 3365.399796] vmap_pfn+0x77/0xd0 >>>> [ 3365.399797] vmap_udmabuf+0xc5/0x110 >>>> [ 3365.399802] dma_buf_vmap+0x96/0x130 >>>> >>>> I did an experiment to revert 18d7de823b7150344d242c3677e65d68c5271b04, >>>> then I can vmap the pages. Could you help what's wrong with that? >>> Sorry for that, as I reviewed pfn_valid, that's someting wired: >>> >>> /** >>> * pfn_valid - check if there is a valid memory map entry for a PFN >>> * @pfn: the page frame number to check >>> * >>> * Check if there is a valid memory map entry aka struct page for the @pfn. >>> * Note, that availability of the memory map entry does not imply that >>> * there is actual usable memory at that @pfn. The struct page may >>> * represent a hole or an unusable page frame. >>> * >>> * Return: 1 for PFNs that have memory map entries and 0 otherwise >>> */ >>> >>> So, if pfn valid, it's return 1, else 0. So mean, only 1 is a valid pfn. But vmap_pfn_apply in there: >>> >>> static int vmap_pfn_apply(pte_t *pte, unsigned long addr, void *private) >>> { >>> struct vmap_pfn_data *data = private; >>> unsigned long pfn = data->pfns[data->idx]; >>> pte_t ptent; >>> >>> if (WARN_ON_ONCE(pfn_valid(pfn))) >>> return -EINVAL; >>> >>> ptent = pte_mkspecial(pfn_pte(pfn, data->prot)); >>> set_pte_at(&init_mm, addr, pte, ptent); >>> >>> data->idx++; >>> return 0; >>> } >>> >>> Do it give a wrong check? maybe should fix by: >> I guess not, it looks more like warning when you trying to vmap a >> pfn which already took a valid entry in pte. > > No, I think here check need pfn is valid, then can set it. If a pfn is invalid, why we set it in PTE? > > Also, I can't make sure. > > BTW, can you fix it then retest? > > Thank you. > >> >> However, the MM code is so complex for me, just my guess. :) >> >>> static int vmap_pfn_apply(pte_t *pte, unsigned long addr, void *private) >>> { >>> struct vmap_pfn_data *data = private; >>> unsigned long pfn = data->pfns[data->idx]; >>> pte_t ptent; >>> >>> - if (WARN_ON_ONCE(pfn_valid(pfn))) >>> + if (WARN_ON_ONCE(!pfn_valid(pfn))) >>> return -EINVAL; >>> >>> ptent = pte_mkspecial(pfn_pte(pfn, data->prot)); >>> set_pte_at(&init_mm, addr, pte, ptent); >>> >>> data->idx++; >>> return 0; >>> } >>> >>> Please help me check it, also, you can apply this and then check it.:) >>> >>>> >>>> -- >>>> Best regards, >>>> Bingbu Cao >> -- >> Best regards, >> Bingbu Cao -- Best regards, Bingbu Cao ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: udmabuf vmap failed (Revert "udmabuf: fix vmap_udmabuf error page set" can help) 2025-03-11 9:02 ` Bingbu Cao @ 2025-03-11 9:34 ` Huan Yang 2025-03-11 11:14 ` Ryan Roberts 0 siblings, 1 reply; 9+ messages in thread From: Huan Yang @ 2025-03-11 9:34 UTC (permalink / raw) To: Bingbu Cao, vivek.kasireddy, ryan.roberts, hch, Ryan Roberts, Christoph Hellwig Cc: linux-kernel, christian.koenig, dri-devel Hi Christoph and Ryan, Can you help us check vmap_pfn's pfn check is right? Did here mischecked pfn_valid? Thank you. 在 2025/3/11 17:02, Bingbu Cao 写道: > Christoph and Ryan, > > Could you help check this? Thanks. > > On 3/11/25 4:54 PM, Huan Yang wrote: >> 在 2025/3/11 16:42, Bingbu Cao 写道: >>> [You don't often get email from bingbu.cao@linux.intel.com. Learn why this is important at https://aka.ms/LearnAboutSenderIdentification ] >>> >>> Huan, >>> >>> Thanks for your response. >>> >>> On 3/11/25 3:12 PM, Huan Yang wrote: >>>> 在 2025/3/11 14:40, Bingbu Cao 写道: >>>>> [You don't often get email from bingbu.cao@linux.intel.com. Learn why this is important at https://aka.ms/LearnAboutSenderIdentification ] >>>>> >>>>> Huan Yang and Vivek, >>>>> >>>>> I am trying to use udmabuf for my test, and I cannot vmap the udmabuf >>>>> buffers now. vmap_pfn_apply() will report a warning to complain that >>>>> the pfns are invalid. >>>>> I dump the pfn numbers as below: >>>>> [ 3365.399641] pg[0] pfn 1148695 >>>>> [ 3365.399642] pg[1] pfn 1145057 >>>>> [ 3365.399642] pg[2] pfn 1134070 >>>>> [ 3365.399643] pg[3] pfn 1148700 >>>>> [ 3365.399643] pg[4] pfn 1144871 >>>>> [ 3365.399643] pg[5] pfn 1408686 >>>>> [ 3365.399643] pg[6] pfn 1408683 >>>>> ... >>>>> [ 3365.399660] WARNING: CPU: 3 PID: 2772 at mm/vmalloc.c:3489 vmap_pfn_apply+0xb7/0xd0 >>>>> [ 3365.399667] Modules linked in:... >>>>> [ 3365.399750] CPU: 3 UID: 0 PID: 2772 Comm: drm-test Not tainted 6.13.0-rc2-rvp #845 >>>>> [ 3365.399752] Hardware name: Intel Corporation Client Platform/xxxx, BIOS xxxFWI1.R00.3221.D83.2408120121 08/12/2024 >>>>> [ 3365.399753] RIP: 0010:vmap_pfn_apply+0xb7/0xd0 >>>>> [ 3365.399755] Code: 5b 41 5c 41 5d 5d c3 cc cc cc cc 48 21 c3 eb d1 48 21 c3 48 23 3d 31 c0 26 02 eb c5 48 c7 c7 c4 3c 20 a8 e8 5b c0 d8 ff eb 8a <0f> 0b b8 ea ff ff ff 5b 41 5c 41 5d 5d c3 cc cc cc cc 0f 1f 80 00 >>>>> [ 3365.399756] RSP: 0018:ffffb9b50c32fad0 EFLAGS: 00010202 >>>>> [ 3365.399757] RAX: 0000000000000001 RBX: 0000000000118717 RCX: 0000000000000000 >>>>> [ 3365.399758] RDX: 0000000080000000 RSI: ffffb9b50c358000 RDI: 00000000ffffffff >>>>> [ 3365.399758] RBP: ffffb9b50c32fae8 R08: ffffb9b50c32fbd0 R09: 0000000000000001 >>>>> [ 3365.399759] R10: ffff941602479288 R11: 0000000000000000 R12: ffffb9b50c32fbd0 >>>>> [ 3365.399759] R13: ffff941618665ac0 R14: ffffb9b50c358000 R15: ffff941618665ac8 >>>>> [ 3365.399760] FS: 00007ff9e9ddd740(0000) GS:ffff94196f780000(0000) knlGS:0000000000000000 >>>>> [ 3365.399760] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 >>>>> [ 3365.399761] CR2: 000055fda5dc69d9 CR3: 00000001544de003 CR4: 0000000000f72ef0 >>>>> [ 3365.399762] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 >>>>> [ 3365.399762] DR3: 0000000000000000 DR6: 00000000ffff07f0 DR7: 0000000000000400 >>>>> [ 3365.399763] PKRU: 55555554 >>>>> [ 3365.399763] Call Trace: >>>>> [ 3365.399765] <TASK> >>>>> [ 3365.399769] ? show_regs+0x6d/0x80 >>>>> [ 3365.399773] ? __warn+0x97/0x160 >>>>> [ 3365.399777] ? vmap_pfn_apply+0xb7/0xd0 >>>>> [ 3365.399777] ? report_bug+0x1ec/0x240 >>>>> [ 3365.399782] ? handle_bug+0x63/0xa0 >>>>> [ 3365.399784] ? exc_invalid_op+0x1d/0x80 >>>>> [ 3365.399785] ? asm_exc_invalid_op+0x1f/0x30 >>>>> [ 3365.399790] ? vmap_pfn_apply+0xb7/0xd0 >>>>> [ 3365.399791] __apply_to_page_range+0x522/0x8a0 >>>>> [ 3365.399794] ? __pfx_vmap_pfn_apply+0x10/0x10 >>>>> [ 3365.399795] apply_to_page_range+0x18/0x20 >>>>> [ 3365.399796] vmap_pfn+0x77/0xd0 >>>>> [ 3365.399797] vmap_udmabuf+0xc5/0x110 >>>>> [ 3365.399802] dma_buf_vmap+0x96/0x130 >>>>> >>>>> I did an experiment to revert 18d7de823b7150344d242c3677e65d68c5271b04, >>>>> then I can vmap the pages. Could you help what's wrong with that? >>>> Sorry for that, as I reviewed pfn_valid, that's someting wired: >>>> >>>> /** >>>> * pfn_valid - check if there is a valid memory map entry for a PFN >>>> * @pfn: the page frame number to check >>>> * >>>> * Check if there is a valid memory map entry aka struct page for the @pfn. >>>> * Note, that availability of the memory map entry does not imply that >>>> * there is actual usable memory at that @pfn. The struct page may >>>> * represent a hole or an unusable page frame. >>>> * >>>> * Return: 1 for PFNs that have memory map entries and 0 otherwise >>>> */ >>>> >>>> So, if pfn valid, it's return 1, else 0. So mean, only 1 is a valid pfn. But vmap_pfn_apply in there: >>>> >>>> static int vmap_pfn_apply(pte_t *pte, unsigned long addr, void *private) >>>> { >>>> struct vmap_pfn_data *data = private; >>>> unsigned long pfn = data->pfns[data->idx]; >>>> pte_t ptent; >>>> >>>> if (WARN_ON_ONCE(pfn_valid(pfn))) >>>> return -EINVAL; >>>> >>>> ptent = pte_mkspecial(pfn_pte(pfn, data->prot)); >>>> set_pte_at(&init_mm, addr, pte, ptent); >>>> >>>> data->idx++; >>>> return 0; >>>> } >>>> >>>> Do it give a wrong check? maybe should fix by: >>> I guess not, it looks more like warning when you trying to vmap a >>> pfn which already took a valid entry in pte. >> No, I think here check need pfn is valid, then can set it. If a pfn is invalid, why we set it in PTE? >> >> Also, I can't make sure. >> >> BTW, can you fix it then retest? >> >> Thank you. >> >>> However, the MM code is so complex for me, just my guess. :) >>> >>>> static int vmap_pfn_apply(pte_t *pte, unsigned long addr, void *private) >>>> { >>>> struct vmap_pfn_data *data = private; >>>> unsigned long pfn = data->pfns[data->idx]; >>>> pte_t ptent; >>>> >>>> - if (WARN_ON_ONCE(pfn_valid(pfn))) >>>> + if (WARN_ON_ONCE(!pfn_valid(pfn))) >>>> return -EINVAL; >>>> >>>> ptent = pte_mkspecial(pfn_pte(pfn, data->prot)); >>>> set_pte_at(&init_mm, addr, pte, ptent); >>>> >>>> data->idx++; >>>> return 0; >>>> } >>>> >>>> Please help me check it, also, you can apply this and then check it.:) >>>> >>>>> -- >>>>> Best regards, >>>>> Bingbu Cao >>> -- >>> Best regards, >>> Bingbu Cao ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: udmabuf vmap failed (Revert "udmabuf: fix vmap_udmabuf error page set" can help) 2025-03-11 9:34 ` Huan Yang @ 2025-03-11 11:14 ` Ryan Roberts 2025-03-12 1:52 ` Huan Yang 2025-03-12 5:32 ` Christoph Hellwig 0 siblings, 2 replies; 9+ messages in thread From: Ryan Roberts @ 2025-03-11 11:14 UTC (permalink / raw) To: Huan Yang, Bingbu Cao, vivek.kasireddy, hch Cc: linux-kernel, christian.koenig, dri-devel Hi, On 11/03/2025 09:34, Huan Yang wrote: > Hi Christoph and Ryan, > > Can you help us check vmap_pfn's pfn check is right? Did here mischecked pfn_valid? I'm no expert on this piece of code, but I believe pfn_valid() is checking to see if a pfn is valid *memory*. i.e. does it have a corresponding struct page? I'm guessing that vmap_pfn() is only intended to be used for non-memory pfns, e.g. mmio regions. You probably want either vmap() or vm_map_ram()? Thanks, Ryan > > Thank you. > > 在 2025/3/11 17:02, Bingbu Cao 写道: >> Christoph and Ryan, >> >> Could you help check this? Thanks. >> >> On 3/11/25 4:54 PM, Huan Yang wrote: >>> 在 2025/3/11 16:42, Bingbu Cao 写道: >>>> [You don't often get email from bingbu.cao@linux.intel.com. Learn why this >>>> is important at https://aka.ms/LearnAboutSenderIdentification ] >>>> >>>> Huan, >>>> >>>> Thanks for your response. >>>> >>>> On 3/11/25 3:12 PM, Huan Yang wrote: >>>>> 在 2025/3/11 14:40, Bingbu Cao 写道: >>>>>> [You don't often get email from bingbu.cao@linux.intel.com. Learn why this >>>>>> is important at https://aka.ms/LearnAboutSenderIdentification ] >>>>>> >>>>>> Huan Yang and Vivek, >>>>>> >>>>>> I am trying to use udmabuf for my test, and I cannot vmap the udmabuf >>>>>> buffers now. vmap_pfn_apply() will report a warning to complain that >>>>>> the pfns are invalid. >>>>>> I dump the pfn numbers as below: >>>>>> [ 3365.399641] pg[0] pfn 1148695 >>>>>> [ 3365.399642] pg[1] pfn 1145057 >>>>>> [ 3365.399642] pg[2] pfn 1134070 >>>>>> [ 3365.399643] pg[3] pfn 1148700 >>>>>> [ 3365.399643] pg[4] pfn 1144871 >>>>>> [ 3365.399643] pg[5] pfn 1408686 >>>>>> [ 3365.399643] pg[6] pfn 1408683 >>>>>> ... >>>>>> [ 3365.399660] WARNING: CPU: 3 PID: 2772 at mm/vmalloc.c:3489 >>>>>> vmap_pfn_apply+0xb7/0xd0 >>>>>> [ 3365.399667] Modules linked in:... >>>>>> [ 3365.399750] CPU: 3 UID: 0 PID: 2772 Comm: drm-test Not tainted 6.13.0- >>>>>> rc2-rvp #845 >>>>>> [ 3365.399752] Hardware name: Intel Corporation Client Platform/xxxx, BIOS >>>>>> xxxFWI1.R00.3221.D83.2408120121 08/12/2024 >>>>>> [ 3365.399753] RIP: 0010:vmap_pfn_apply+0xb7/0xd0 >>>>>> [ 3365.399755] Code: 5b 41 5c 41 5d 5d c3 cc cc cc cc 48 21 c3 eb d1 48 21 >>>>>> c3 48 23 3d 31 c0 26 02 eb c5 48 c7 c7 c4 3c 20 a8 e8 5b c0 d8 ff eb 8a >>>>>> <0f> 0b b8 ea ff ff ff 5b 41 5c 41 5d 5d c3 cc cc cc cc 0f 1f 80 00 >>>>>> [ 3365.399756] RSP: 0018:ffffb9b50c32fad0 EFLAGS: 00010202 >>>>>> [ 3365.399757] RAX: 0000000000000001 RBX: 0000000000118717 RCX: >>>>>> 0000000000000000 >>>>>> [ 3365.399758] RDX: 0000000080000000 RSI: ffffb9b50c358000 RDI: >>>>>> 00000000ffffffff >>>>>> [ 3365.399758] RBP: ffffb9b50c32fae8 R08: ffffb9b50c32fbd0 R09: >>>>>> 0000000000000001 >>>>>> [ 3365.399759] R10: ffff941602479288 R11: 0000000000000000 R12: >>>>>> ffffb9b50c32fbd0 >>>>>> [ 3365.399759] R13: ffff941618665ac0 R14: ffffb9b50c358000 R15: >>>>>> ffff941618665ac8 >>>>>> [ 3365.399760] FS: 00007ff9e9ddd740(0000) GS:ffff94196f780000(0000) >>>>>> knlGS:0000000000000000 >>>>>> [ 3365.399760] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 >>>>>> [ 3365.399761] CR2: 000055fda5dc69d9 CR3: 00000001544de003 CR4: >>>>>> 0000000000f72ef0 >>>>>> [ 3365.399762] DR0: 0000000000000000 DR1: 0000000000000000 DR2: >>>>>> 0000000000000000 >>>>>> [ 3365.399762] DR3: 0000000000000000 DR6: 00000000ffff07f0 DR7: >>>>>> 0000000000000400 >>>>>> [ 3365.399763] PKRU: 55555554 >>>>>> [ 3365.399763] Call Trace: >>>>>> [ 3365.399765] <TASK> >>>>>> [ 3365.399769] ? show_regs+0x6d/0x80 >>>>>> [ 3365.399773] ? __warn+0x97/0x160 >>>>>> [ 3365.399777] ? vmap_pfn_apply+0xb7/0xd0 >>>>>> [ 3365.399777] ? report_bug+0x1ec/0x240 >>>>>> [ 3365.399782] ? handle_bug+0x63/0xa0 >>>>>> [ 3365.399784] ? exc_invalid_op+0x1d/0x80 >>>>>> [ 3365.399785] ? asm_exc_invalid_op+0x1f/0x30 >>>>>> [ 3365.399790] ? vmap_pfn_apply+0xb7/0xd0 >>>>>> [ 3365.399791] __apply_to_page_range+0x522/0x8a0 >>>>>> [ 3365.399794] ? __pfx_vmap_pfn_apply+0x10/0x10 >>>>>> [ 3365.399795] apply_to_page_range+0x18/0x20 >>>>>> [ 3365.399796] vmap_pfn+0x77/0xd0 >>>>>> [ 3365.399797] vmap_udmabuf+0xc5/0x110 >>>>>> [ 3365.399802] dma_buf_vmap+0x96/0x130 >>>>>> >>>>>> I did an experiment to revert 18d7de823b7150344d242c3677e65d68c5271b04, >>>>>> then I can vmap the pages. Could you help what's wrong with that? >>>>> Sorry for that, as I reviewed pfn_valid, that's someting wired: >>>>> >>>>> /** >>>>> * pfn_valid - check if there is a valid memory map entry for a PFN >>>>> * @pfn: the page frame number to check >>>>> * >>>>> * Check if there is a valid memory map entry aka struct page for the @pfn. >>>>> * Note, that availability of the memory map entry does not imply that >>>>> * there is actual usable memory at that @pfn. The struct page may >>>>> * represent a hole or an unusable page frame. >>>>> * >>>>> * Return: 1 for PFNs that have memory map entries and 0 otherwise >>>>> */ >>>>> >>>>> So, if pfn valid, it's return 1, else 0. So mean, only 1 is a valid pfn. >>>>> But vmap_pfn_apply in there: >>>>> >>>>> static int vmap_pfn_apply(pte_t *pte, unsigned long addr, void *private) >>>>> { >>>>> struct vmap_pfn_data *data = private; >>>>> unsigned long pfn = data->pfns[data->idx]; >>>>> pte_t ptent; >>>>> >>>>> if (WARN_ON_ONCE(pfn_valid(pfn))) >>>>> return -EINVAL; >>>>> >>>>> ptent = pte_mkspecial(pfn_pte(pfn, data->prot)); >>>>> set_pte_at(&init_mm, addr, pte, ptent); >>>>> >>>>> data->idx++; >>>>> return 0; >>>>> } >>>>> >>>>> Do it give a wrong check? maybe should fix by: >>>> I guess not, it looks more like warning when you trying to vmap a >>>> pfn which already took a valid entry in pte. >>> No, I think here check need pfn is valid, then can set it. If a pfn is >>> invalid, why we set it in PTE? >>> >>> Also, I can't make sure. >>> >>> BTW, can you fix it then retest? >>> >>> Thank you. >>> >>>> However, the MM code is so complex for me, just my guess. :) >>>> >>>>> static int vmap_pfn_apply(pte_t *pte, unsigned long addr, void *private) >>>>> { >>>>> struct vmap_pfn_data *data = private; >>>>> unsigned long pfn = data->pfns[data->idx]; >>>>> pte_t ptent; >>>>> >>>>> - if (WARN_ON_ONCE(pfn_valid(pfn))) >>>>> + if (WARN_ON_ONCE(!pfn_valid(pfn))) >>>>> return -EINVAL; >>>>> >>>>> ptent = pte_mkspecial(pfn_pte(pfn, data->prot)); >>>>> set_pte_at(&init_mm, addr, pte, ptent); >>>>> >>>>> data->idx++; >>>>> return 0; >>>>> } >>>>> >>>>> Please help me check it, also, you can apply this and then check it.:) >>>>> >>>>>> -- >>>>>> Best regards, >>>>>> Bingbu Cao >>>> -- >>>> Best regards, >>>> Bingbu Cao ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: udmabuf vmap failed (Revert "udmabuf: fix vmap_udmabuf error page set" can help) 2025-03-11 11:14 ` Ryan Roberts @ 2025-03-12 1:52 ` Huan Yang 2025-03-12 5:32 ` Christoph Hellwig 1 sibling, 0 replies; 9+ messages in thread From: Huan Yang @ 2025-03-12 1:52 UTC (permalink / raw) To: Ryan Roberts, Bingbu Cao, vivek.kasireddy, hch Cc: linux-kernel, christian.koenig, dri-devel [-- Attachment #1: Type: text/plain, Size: 7673 bytes --] 在 2025/3/11 19:14, Ryan Roberts 写道: > Hi, > > On 11/03/2025 09:34, Huan Yang wrote: >> Hi Christoph and Ryan, >> >> Can you help us check vmap_pfn's pfn check is right? Did here mischecked pfn_valid? > I'm no expert on this piece of code, but I believe pfn_valid() is checking to > see if a pfn is valid *memory*. i.e. does it have a corresponding struct page? Yes, so, why vmap_pfn abandon a valid pfn when invoke apply_to_page_range? That's wierd. > > I'm guessing that vmap_pfn() is only intended to be used for non-memory pfns, > e.g. mmio regions. You probably want either vmap() or vm_map_ram()? Original invoke vmap, but with HVO(page struct may release to save memory), if udmabuf use page struct to record which page need to vmap, will cause some problem. So we record this folio's pfn to map. Each pfn **absolutally** valid, As this test report, it enter vmap_pfn_apply then valid is true, so trigger WRAN_ON_ONCE and return -EINVAL, I think this is a mischeck, Normal rule should be: If a pfn is not a valid, warn and return, else set this **valid** pfn into vmalloc area's pte. Thanks > > Thanks, > Ryan > >> Thank you. >> >> 在 2025/3/11 17:02, Bingbu Cao 写道: >>> Christoph and Ryan, >>> >>> Could you help check this? Thanks. >>> >>> On 3/11/25 4:54 PM, Huan Yang wrote: >>>> 在 2025/3/11 16:42, Bingbu Cao 写道: >>>>> [You don't often get email frombingbu.cao@linux.intel.com. Learn why this >>>>> is important athttps://aka.ms/LearnAboutSenderIdentification ] >>>>> >>>>> Huan, >>>>> >>>>> Thanks for your response. >>>>> >>>>> On 3/11/25 3:12 PM, Huan Yang wrote: >>>>>> 在 2025/3/11 14:40, Bingbu Cao 写道: >>>>>>> [You don't often get email frombingbu.cao@linux.intel.com. Learn why this >>>>>>> is important athttps://aka.ms/LearnAboutSenderIdentification ] >>>>>>> >>>>>>> Huan Yang and Vivek, >>>>>>> >>>>>>> I am trying to use udmabuf for my test, and I cannot vmap the udmabuf >>>>>>> buffers now. vmap_pfn_apply() will report a warning to complain that >>>>>>> the pfns are invalid. >>>>>>> I dump the pfn numbers as below: >>>>>>> [ 3365.399641] pg[0] pfn 1148695 >>>>>>> [ 3365.399642] pg[1] pfn 1145057 >>>>>>> [ 3365.399642] pg[2] pfn 1134070 >>>>>>> [ 3365.399643] pg[3] pfn 1148700 >>>>>>> [ 3365.399643] pg[4] pfn 1144871 >>>>>>> [ 3365.399643] pg[5] pfn 1408686 >>>>>>> [ 3365.399643] pg[6] pfn 1408683 >>>>>>> ... >>>>>>> [ 3365.399660] WARNING: CPU: 3 PID: 2772 at mm/vmalloc.c:3489 >>>>>>> vmap_pfn_apply+0xb7/0xd0 >>>>>>> [ 3365.399667] Modules linked in:... >>>>>>> [ 3365.399750] CPU: 3 UID: 0 PID: 2772 Comm: drm-test Not tainted 6.13.0- >>>>>>> rc2-rvp #845 >>>>>>> [ 3365.399752] Hardware name: Intel Corporation Client Platform/xxxx, BIOS >>>>>>> xxxFWI1.R00.3221.D83.2408120121 08/12/2024 >>>>>>> [ 3365.399753] RIP: 0010:vmap_pfn_apply+0xb7/0xd0 >>>>>>> [ 3365.399755] Code: 5b 41 5c 41 5d 5d c3 cc cc cc cc 48 21 c3 eb d1 48 21 >>>>>>> c3 48 23 3d 31 c0 26 02 eb c5 48 c7 c7 c4 3c 20 a8 e8 5b c0 d8 ff eb 8a >>>>>>> <0f> 0b b8 ea ff ff ff 5b 41 5c 41 5d 5d c3 cc cc cc cc 0f 1f 80 00 >>>>>>> [ 3365.399756] RSP: 0018:ffffb9b50c32fad0 EFLAGS: 00010202 >>>>>>> [ 3365.399757] RAX: 0000000000000001 RBX: 0000000000118717 RCX: >>>>>>> 0000000000000000 >>>>>>> [ 3365.399758] RDX: 0000000080000000 RSI: ffffb9b50c358000 RDI: >>>>>>> 00000000ffffffff >>>>>>> [ 3365.399758] RBP: ffffb9b50c32fae8 R08: ffffb9b50c32fbd0 R09: >>>>>>> 0000000000000001 >>>>>>> [ 3365.399759] R10: ffff941602479288 R11: 0000000000000000 R12: >>>>>>> ffffb9b50c32fbd0 >>>>>>> [ 3365.399759] R13: ffff941618665ac0 R14: ffffb9b50c358000 R15: >>>>>>> ffff941618665ac8 >>>>>>> [ 3365.399760] FS: 00007ff9e9ddd740(0000) GS:ffff94196f780000(0000) >>>>>>> knlGS:0000000000000000 >>>>>>> [ 3365.399760] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 >>>>>>> [ 3365.399761] CR2: 000055fda5dc69d9 CR3: 00000001544de003 CR4: >>>>>>> 0000000000f72ef0 >>>>>>> [ 3365.399762] DR0: 0000000000000000 DR1: 0000000000000000 DR2: >>>>>>> 0000000000000000 >>>>>>> [ 3365.399762] DR3: 0000000000000000 DR6: 00000000ffff07f0 DR7: >>>>>>> 0000000000000400 >>>>>>> [ 3365.399763] PKRU: 55555554 >>>>>>> [ 3365.399763] Call Trace: >>>>>>> [ 3365.399765] <TASK> >>>>>>> [ 3365.399769] ? show_regs+0x6d/0x80 >>>>>>> [ 3365.399773] ? __warn+0x97/0x160 >>>>>>> [ 3365.399777] ? vmap_pfn_apply+0xb7/0xd0 >>>>>>> [ 3365.399777] ? report_bug+0x1ec/0x240 >>>>>>> [ 3365.399782] ? handle_bug+0x63/0xa0 >>>>>>> [ 3365.399784] ? exc_invalid_op+0x1d/0x80 >>>>>>> [ 3365.399785] ? asm_exc_invalid_op+0x1f/0x30 >>>>>>> [ 3365.399790] ? vmap_pfn_apply+0xb7/0xd0 >>>>>>> [ 3365.399791] __apply_to_page_range+0x522/0x8a0 >>>>>>> [ 3365.399794] ? __pfx_vmap_pfn_apply+0x10/0x10 >>>>>>> [ 3365.399795] apply_to_page_range+0x18/0x20 >>>>>>> [ 3365.399796] vmap_pfn+0x77/0xd0 >>>>>>> [ 3365.399797] vmap_udmabuf+0xc5/0x110 >>>>>>> [ 3365.399802] dma_buf_vmap+0x96/0x130 >>>>>>> >>>>>>> I did an experiment to revert 18d7de823b7150344d242c3677e65d68c5271b04, >>>>>>> then I can vmap the pages. Could you help what's wrong with that? >>>>>> Sorry for that, as I reviewed pfn_valid, that's someting wired: >>>>>> >>>>>> /** >>>>>> * pfn_valid - check if there is a valid memory map entry for a PFN >>>>>> * @pfn: the page frame number to check >>>>>> * >>>>>> * Check if there is a valid memory map entry aka struct page for the @pfn. >>>>>> * Note, that availability of the memory map entry does not imply that >>>>>> * there is actual usable memory at that @pfn. The struct page may >>>>>> * represent a hole or an unusable page frame. >>>>>> * >>>>>> * Return: 1 for PFNs that have memory map entries and 0 otherwise >>>>>> */ >>>>>> >>>>>> So, if pfn valid, it's return 1, else 0. So mean, only 1 is a valid pfn. >>>>>> But vmap_pfn_apply in there: >>>>>> >>>>>> static int vmap_pfn_apply(pte_t *pte, unsigned long addr, void *private) >>>>>> { >>>>>> struct vmap_pfn_data *data = private; >>>>>> unsigned long pfn = data->pfns[data->idx]; >>>>>> pte_t ptent; >>>>>> >>>>>> if (WARN_ON_ONCE(pfn_valid(pfn))) >>>>>> return -EINVAL; >>>>>> >>>>>> ptent = pte_mkspecial(pfn_pte(pfn, data->prot)); >>>>>> set_pte_at(&init_mm, addr, pte, ptent); >>>>>> >>>>>> data->idx++; >>>>>> return 0; >>>>>> } >>>>>> >>>>>> Do it give a wrong check? maybe should fix by: >>>>> I guess not, it looks more like warning when you trying to vmap a >>>>> pfn which already took a valid entry in pte. >>>> No, I think here check need pfn is valid, then can set it. If a pfn is >>>> invalid, why we set it in PTE? >>>> >>>> Also, I can't make sure. >>>> >>>> BTW, can you fix it then retest? >>>> >>>> Thank you. >>>> >>>>> However, the MM code is so complex for me, just my guess. :) >>>>> >>>>>> static int vmap_pfn_apply(pte_t *pte, unsigned long addr, void *private) >>>>>> { >>>>>> struct vmap_pfn_data *data = private; >>>>>> unsigned long pfn = data->pfns[data->idx]; >>>>>> pte_t ptent; >>>>>> >>>>>> - if (WARN_ON_ONCE(pfn_valid(pfn))) >>>>>> + if (WARN_ON_ONCE(!pfn_valid(pfn))) >>>>>> return -EINVAL; >>>>>> >>>>>> ptent = pte_mkspecial(pfn_pte(pfn, data->prot)); >>>>>> set_pte_at(&init_mm, addr, pte, ptent); >>>>>> >>>>>> data->idx++; >>>>>> return 0; >>>>>> } >>>>>> >>>>>> Please help me check it, also, you can apply this and then check it.:) >>>>>> >>>>>>> -- >>>>>>> Best regards, >>>>>>> Bingbu Cao >>>>> -- >>>>> Best regards, >>>>> Bingbu Cao [-- Attachment #2: Type: text/html, Size: 9935 bytes --] ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: udmabuf vmap failed (Revert "udmabuf: fix vmap_udmabuf error page set" can help) 2025-03-11 11:14 ` Ryan Roberts 2025-03-12 1:52 ` Huan Yang @ 2025-03-12 5:32 ` Christoph Hellwig 1 sibling, 0 replies; 9+ messages in thread From: Christoph Hellwig @ 2025-03-12 5:32 UTC (permalink / raw) To: Ryan Roberts Cc: Huan Yang, Bingbu Cao, vivek.kasireddy, hch, linux-kernel, christian.koenig, dri-devel On Tue, Mar 11, 2025 at 11:14:28AM +0000, Ryan Roberts wrote: > Hi, > > On 11/03/2025 09:34, Huan Yang wrote: > > Hi Christoph and Ryan, > > > > Can you help us check vmap_pfn's pfn check is right? Did here mischecked pfn_valid? > > I'm no expert on this piece of code, but I believe pfn_valid() is checking to > see if a pfn is valid *memory*. i.e. does it have a corresponding struct page? > > I'm guessing that vmap_pfn() is only intended to be used for non-memory pfns, > e.g. mmio regions. You probably want either vmap() or vm_map_ram()? Exactly. vmap_pfn is a special case for mapping non-page backed memory. Wjile looking ad udmabuf, the crap it does with dma mapping to the misc device-attached struct device also can't work except by chance in a few very exceptional setups. So as far as I can tell udmabuf isn't really something usable to start with, which might explain why the issues with vmap/vmap_pfn weren't easily noticed. ^ permalink raw reply [flat|nested] 9+ messages in thread
end of thread, other threads:[~2025-03-12 9:22 UTC | newest] Thread overview: 9+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2025-03-11 6:40 udmabuf vmap failed (Revert "udmabuf: fix vmap_udmabuf error page set" can help) Bingbu Cao 2025-03-11 7:12 ` Huan Yang 2025-03-11 8:42 ` Bingbu Cao 2025-03-11 8:54 ` Huan Yang 2025-03-11 9:02 ` Bingbu Cao 2025-03-11 9:34 ` Huan Yang 2025-03-11 11:14 ` Ryan Roberts 2025-03-12 1:52 ` Huan Yang 2025-03-12 5:32 ` Christoph Hellwig
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.