* 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; 8+ 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] 8+ 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; 8+ 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] 8+ 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; 8+ 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] 8+ 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; 8+ 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] 8+ 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; 8+ 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] 8+ 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; 8+ 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] 8+ 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 5:32 ` Christoph Hellwig 0 siblings, 1 reply; 8+ 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] 8+ 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 5:32 ` Christoph Hellwig 0 siblings, 0 replies; 8+ 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] 8+ messages in thread
end of thread, other threads:[~2025-03-12 5:32 UTC | newest] Thread overview: 8+ 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 5:32 ` Christoph Hellwig
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox