> > > > > -----Original Message----- > > From: LeantionX <[email protected]> > > Sent: Tuesday, June 2, 2026 11:52 AM > > To: [email protected] > > Cc: [email protected]; KY Srinivasan <[email protected]>; > > Haiyang Zhang <[email protected]>; [email protected]; Dexuan Cui > > <[email protected]>; Long Li <[email protected]>; > > [email protected]; [email protected]; [email protected]; > > [email protected]; [email protected]; [email protected]; linux- > > [email protected]; Anton Leontev <[email protected]> > > Subject: [EXTERNAL] [PATCH net] hv_netvsc: use kmap_local_page in > > netvsc_copy_to_send_buf > > > > [You don't often get email from [email protected]. Learn why this > > is important at https://aka.ms/LearnAboutSenderIdentification ] > > > > From: Anton Leontev <[email protected]> > > > > netvsc_copy_to_send_buf() copies skb fragment pages into the shared > > VMBus send buffer using phys_to_virt() on the fragment PFN. On 32-bit > > x86 with CONFIG_HIGHMEM=y, phys_to_virt() (i.e. __va()) is only valid > > for LOWMEM addresses below 896 MiB. For a HIGHMEM page it returns an > > address that has no kernel page table entry and lies outside the > > kernel direct map, so the subsequent memcpy() faults. As this happens > > on the transmit softirq path, the fault is fatal. > Please include the stack trace in patch description. > > > A HIGHMEM fragment reaches this path whenever the page backing an skb > > fragment lives above the LOWMEM boundary, which is common on a 32-bit > > guest with several GiB of RAM (for example when the in-kernel NFS > > server splices page cache pages directly into the reply skb). > > > > Map the fragment page on demand with kmap_local_page()/kunmap_local() > > instead. Using pfn_to_page() on pb[i].pfn maps exactly the page > > described by the page buffer entry. On configurations without HIGHMEM > > (amd64, i386 without CONFIG_HIGHMEM) kmap_local_page() reduces to > > page_address(), so this is a no-op there. > > So, on 64bit kernel, it has no performance impact? > > Thanks, > - Haiyang >
Correct. On 64-bit (and any !CONFIG_HIGHMEM config) all pages are permanently present in the kernel direct map, so kmap_local_page() folds to page_address() and kunmap_local() is a no-op. The generated code is therefore equivalent to the previous direct-map access, with no extra mapping cost on the tx path. The kmap is only meaningful on 32-bit CONFIG_HIGHMEM, where the fragment page may live above the LOWMEM boundary and the old phys_to_virt() result is invalid. Thanks, Anton
