From nobody Mon Jun 8 08:52:24 2026 Received: from mail-wr1-f54.google.com (mail-wr1-f54.google.com [209.85.221.54]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id DD9BE3E9C08 for ; Wed, 3 Jun 2026 16:38:54 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.221.54 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1780504736; cv=none; b=f9CKSTB7hdmZ8M92lKa5SQAxPK4C4oKxJK4OQXoWR81JYJsX8VSulv+J0UksIjIArhl51WojXJAEqZ/DeD2okuNm/R+dyUXrREvg2KhCs39+M0czJCc/va7zO1O7qssb4Vum0+9GvBacy6hsqeshxoZyu1ORe2hdmpSKMBn0ZbU= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1780504736; c=relaxed/simple; bh=K/YVSy3Jio3EDLqXiV7+CBIoj59O3grDjIPmiQ+k2Ks=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=Yq/fc8sbqScmR8/DhqjrLdT4jjLl0xJfPK/mPAaU6IEK/jWxOB7CoyxeMNCLkmON/Vz69AX0Qd8PMYTcIZLzxovJ1ohyk670iyezahUaJytpViLKnlz9bT+CW1hSHMXRsirZh8RzLEmodcbRNSdxnV+QBEaVyF247ctQz6cHOvs= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=R1ob+GOF; arc=none smtp.client-ip=209.85.221.54 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="R1ob+GOF" Received: by mail-wr1-f54.google.com with SMTP id ffacd0b85a97d-45ef41adbc1so3898710f8f.0 for ; Wed, 03 Jun 2026 09:38:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1780504733; x=1781109533; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=259LrnAOdGfiedRDzKiXBqB7ciLo61uHaIr6D3LBW08=; b=R1ob+GOFGbA8grfK3rS3WPnissX1XhOAzMRICSepyUSuJdAunS4UUXyFfJwrxaMdxo q7x8Rz62nl3ubmIJPrSesQ4BobY0rjmj/JpJriPh5kvAyl9VPt7Xam0dN0SlIwhKApUM 0/hBuRyfoAL1vWEcEJTvIALrWSOd0ERA+V47GQs+abXl8jkuoOfr0pezZXy2mw79Qi/A h0FigVtwIJ4630Bm55J/TWp9YsDEH/cbP9Tm3YPXEQQ7Kr36uceOEc+NK8Vs2BZ/83AV /hFPt3RtoMRLvmG2tKn8GwlE/bLACN/5v9OOe74+I/LMjtYQfazKTJXGI3GttcPX7fGf qxzg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1780504733; x=1781109533; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=259LrnAOdGfiedRDzKiXBqB7ciLo61uHaIr6D3LBW08=; b=VkGH+8bnYUdaiFP07ZMuvn/Q1UV6pk0i8hbbo2nKCHwBY69wCMuG3hAh/GHSOq7JJN 8zF9h2amsEGvxoBOYOSdqbA6BzM3oynHHAqSqyh7lk3IAVP0r8ogbYSdrmo9OQjxTJbH NTblTCQaGG6+fdY6IkVwuzv9D2KLokuw5OKPrW3WbK9USOx7S9/kxEqV3m1TaLxK8WAm 0gNG+5ULMwJvrJ4l/tdIKUkVL2Cv3R4lVHJrliS5nvvm4PaQQ0yC/7z0xwx/B1ZVlG6d RS3L+7hqyYMpSEFm9p6ZooRICkdhZQd4wtLCRFzCEVpYNG/MIsPjhnF59TCWPJ1Rl7eS VAyQ== X-Forwarded-Encrypted: i=1; AFNElJ+dEogZQhbvRY0u6K04LElE1mBu2m20eBKvNVeEAXP3uNPFGhhYS3SMNa+wN0x7Wp0b2py74jePkQIbzNE=@vger.kernel.org X-Gm-Message-State: AOJu0YyE2hRo+ZrZFwWeCZ/9RhdJsby4OwQZKNtqJqV+uMYTOdYIGOVJ qaYTRneDzNX000m/XdCWuNM/WIqBBSCwnvCZBGmfFfAmroSzLTWJCMVl X-Gm-Gg: Acq92OGaqprhiAD5doCdocI5jvbSuWIsNVwIX6CpuhstGX8klqhxy6na5iM9nc38fOm q7V2DDthZDtf0g0fWWttdEhQrqln/FjFs0/6cbGj9x0ti3flGEiBb14EN2B+7Ia4sWLaAO32iNG QZ0529QaNyjuQHRR5cWawfyYZzTlD5/X6Bg+5cam7ItZlWEITGc0ov/G74PvsA+pZXlceTDbQNs v7it9Wm8NkdFHsDQ473c2hVeX1uoR+3g4Qt2d4aXUkAh6rBbo0tDZDEX713HmZKdXlkrlrrm2+8 150qSicnqpvnwwsRIiCN/bXg8m//sr4k9886yFggJPvUlZGGIQbuPUWTUTJDNTmBJVMqZomfoIT tJUWidfsoGlFqjXa3FmDiG5P8/RI3uXYhnMlUEekOWe0RViJzvmBW/m1TFji9tqdSk09+61vy6L cxw0R/Hvdtwk8N6Ui36CEr5Kp10fLvIrsvHCPpVP68kt3ecSbawBK2snxAtJd8oAiU1n63Bs6iM GpqUg== X-Received: by 2002:a05:600c:1c1e:b0:490:b00c:8e6a with SMTP id 5b1f17b1804b1-490b5fe65a6mr69071435e9.28.1780504731298; Wed, 03 Jun 2026 09:38:51 -0700 (PDT) Received: from localhost.localdomain ([5.165.242.139]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-490bc3a8632sm7261405e9.8.2026.06.03.09.38.48 (version=TLS1_3 cipher=TLS_CHACHA20_POLY1305_SHA256 bits=256/256); Wed, 03 Jun 2026 09:38:50 -0700 (PDT) From: Anton Leontev To: netdev@vger.kernel.org Cc: linux-hyperv@vger.kernel.org, haiyangz@microsoft.com, kys@microsoft.com, wei.liu@kernel.org, decui@microsoft.com, longli@microsoft.com, kuba@kernel.org, pabeni@redhat.com, edumazet@google.com, davem@davemloft.net, stable@vger.kernel.org, linux-kernel@vger.kernel.org, Anton Leontev Subject: [PATCH net v2] hv_netvsc: use kmap_local_page in netvsc_copy_to_send_buf Date: Wed, 3 Jun 2026 19:38:51 +0300 Message-ID: <20260603163851.18058-1-leontyevantony@gmail.com> X-Mailer: git-send-email 2.54.0 In-Reply-To: <20260602155210.90987-1-leontyevanton1995@gmail.com> References: <20260602155210.90987-1-leontyevanton1995@gmail.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" 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=3Dy, 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. 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). pb[i].pfn is a Hyper-V PFN at HV_HYP_PAGE_SIZE (4K) granularity. The physical address is reconstructed first and phys_to_page() is used to obtain the native struct page, with offset_in_page() added so the in-page offset stays correct where PAGE_SIZE > HV_HYP_PAGE_SIZE (e.g. arm64 with 64K pages). The page is then mapped on demand with kmap_local_page()/kunmap_local(). On !CONFIG_HIGHMEM configs kmap_local_page() reduces to page_address(), so this is a no-op there. Fixes: c25aaf814a63 ("hyperv: Enable sendbuf mechanism on the send path") Cc: stable@vger.kernel.org Signed-off-by: Anton Leontev --- v2: - Reconstruct the physical address from the Hyper-V PFN and use phys_to_page() + offset_in_page() instead of pfn_to_page() on the raw PFN, correct where PAGE_SIZE > 4K (e.g. arm64 64K pages). Reported by Haiyang Zhang. - Built for i386 (CONFIG_HIGHMEM) and arm64 (64K pages). drivers/net/hyperv/netvsc.c | 8 ++++++-- 1 file changed, 6 insertions(+), 2 deletions(-) diff --git a/drivers/net/hyperv/netvsc.c b/drivers/net/hyperv/netvsc.c index 59e95341f9b1..2038d9f5c9f9 100644 --- a/drivers/net/hyperv/netvsc.c +++ b/drivers/net/hyperv/netvsc.c @@ -12,6 +12,7 @@ #include #include #include +#include #include #include #include @@ -965,11 +966,14 @@ static void netvsc_copy_to_send_buf(struct netvsc_dev= ice *net_device, } =20 for (i =3D 0; i < page_count; i++) { - char *src =3D phys_to_virt(pb[i].pfn << HV_HYP_PAGE_SHIFT); - u32 offset =3D pb[i].offset; + phys_addr_t paddr =3D pb[i].pfn << HV_HYP_PAGE_SHIFT; + struct page *page =3D phys_to_page(paddr); + u32 offset =3D offset_in_page(paddr) + pb[i].offset; u32 len =3D pb[i].len; + char *src =3D kmap_local_page(page); =20 memcpy(dest, (src + offset), len); + kunmap_local(src); dest +=3D len; } =20 --=20 2.43.0