From: Huan Yang <link@vivo.com>
To: Bingbu Cao <bingbu.cao@linux.intel.com>,
vivek.kasireddy@intel.com, ryan.roberts@arm.com, hch@lst.de,
Ryan Roberts <ryan.roberts@arm.com>,
Christoph Hellwig <hch@lst.de>
Cc: linux-kernel@vger.kernel.org, christian.koenig@amd.com,
dri-devel@lists.freedesktop.org
Subject: Re: udmabuf vmap failed (Revert "udmabuf: fix vmap_udmabuf error page set" can help)
Date: Tue, 11 Mar 2025 17:34:48 +0800 [thread overview]
Message-ID: <5da7bd8a-c6db-4995-b947-444e2c78aa7c@vivo.com> (raw)
In-Reply-To: <29445257-b8df-72bd-0650-44c8deb1506c@linux.intel.com>
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
next prev parent reply other threads:[~2025-03-11 9:34 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-03-11 6:40 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 [this message]
2025-03-11 11:14 ` Ryan Roberts
2025-03-12 5:32 ` Christoph Hellwig
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=5da7bd8a-c6db-4995-b947-444e2c78aa7c@vivo.com \
--to=link@vivo.com \
--cc=bingbu.cao@linux.intel.com \
--cc=christian.koenig@amd.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=hch@lst.de \
--cc=linux-kernel@vger.kernel.org \
--cc=ryan.roberts@arm.com \
--cc=vivek.kasireddy@intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®