From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-alma10-1.taild15c8.ts.net [100.103.45.18]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 1E5B147ECFA for ; Thu, 4 Jun 2026 17:25:49 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=100.103.45.18 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1780593951; cv=none; b=iQuRTbYChhVgvtab3WjjHI2vegv2IXBUI/ONDzgsbZBBShv6WwDBoevTYpLviQUNqiP0VGxkS4NRuSL/95loSZX3PtF2k2hSBL1yN9bCx75CC8W3UI7Kjb7NcdbnL7cEdEse8CHOkbSrDmWGu3MjaId6tLPRdxbbgBHDa87uM9Y= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1780593951; c=relaxed/simple; bh=uFvCx508CsbvR47UFVJPBghrH3d2h1nGC6Cr+X0YvwE=; h=From:Subject:To:Cc:In-Reply-To:References:Content-Type:Date: Message-Id; b=aJLvWAK8aonKx5zFom36HsMEhTTLreDt7GSSi8RdYQ0U6j77Ku3moBhLXWvQFrP5ihvfdNTFupQ2j+1RYpExjdYXIEu0Z/9lRfEqFgQVBOr1LDb5ir6jDIWczotwXq7JT2tC60EgUklw4ZA2kN9MEOUEHYLSzZ8r1hBwEDS6eD8= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=RhNMk4M1; arc=none smtp.client-ip=100.103.45.18 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="RhNMk4M1" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 942F41F00893; Thu, 4 Jun 2026 17:25:49 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1780593949; bh=MRAcPqvWT7jxOLKZZYYgLxgifRTkrZsyvjxQQww/koA=; h=From:Subject:Reply-To:To:Cc:In-Reply-To:References:Date; b=RhNMk4M1O+hDH8kDdWAnwbrJP8a3ZotqIBQrtGJgb7noLaGQVSlZ95SlXJOd2oxz3 XfriRVd7syifjl7+DJ+NU5ZzFgJdbuqHs4bBHdwhh8OGsbtX44/D0s24MsWJrBgWW6 qSyRvE6XpT+4Ur73LT/pcYHLF+7hbfEzchg9LqvVfbNLOmxmsETowP3D2bjucnvKGp CXb0sVOwvIdS8UnLu9jk5ur80C4JLztEOUlCgHC4gb/a0k7OZsIBjfEK7bFmouax5s CBqfs3FYeeqSFvt5HyXXtnu9QUTRtq51NsieEenhL/IUMcJ39cRSZk5CUuTn85ZQb2 UX2vJH7OFXhrQ== From: sashiko-bot@kernel.org Subject: Re: [PATCH net v2] hv_netvsc: use kmap_local_page in netvsc_copy_to_send_buf Reply-To: sashiko-reviews@lists.linux.dev To: "Anton Leontev" Cc: linux-hyperv@vger.kernel.org In-Reply-To: <20260603172543.19230-1-leontyevantony@gmail.com> References: <20260603172543.19230-1-leontyevantony@gmail.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Date: Thu, 04 Jun 2026 17:25:49 +0000 Message-Id: <20260604172549.942F41F00893@smtp.kernel.org> Precedence: bulk X-Mailing-List: linux-hyperv@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: Thank you for your contribution! Sashiko AI review found 2 potential issue(= s) to consider: New issues: - [Critical] `memcpy()` overruns the single-page mapping created by `kmap_l= ocal_page()` when an SKB fragment spans multiple pages. Pre-existing issues: - [High] Concurrent writers to the per-channel `tx_stats.syncp` will corrup= t the statistics seqcount, deadlocking readers on 32-bit systems. -- commit f885c2ff3318238c254b9deff5078d8c10f79e15 Author: Anton Leontev hv_netvsc: use kmap_local_page in netvsc_copy_to_send_buf This commit replaces phys_to_virt() with kmap_local_page() to safely access highmem SKB fragments on 32-bit systems, preventing page faults. > diff --git a/drivers/net/hyperv/netvsc.c b/drivers/net/hyperv/netvsc.c > index 59e95341f9b1e..2038d9f5c9f9a 100644 > --- a/drivers/net/hyperv/netvsc.c > +++ b/drivers/net/hyperv/netvsc.c [ ... ] > @@ -965,11 +966,14 @@ static void netvsc_copy_to_send_buf(struct netvsc_d= evice *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); [Severity: Critical] Does this memcpy() risk overrunning the single-page mapping? kmap_local_page() creates a temporary thread-local virtual mapping of exact= ly one native page (4096 bytes on x86). However, the length of the fragment (l= en) can exceed a single page.=20 For example, init_page_array() maps the entire linear skb->data into a sing= le hv_page_buffer entry, and skb_headlen() can exceed 4096 bytes with jumbo frames or GRO/TSO packets. If pb[i].len + offset > PAGE_SIZE, this will read beyond the mapped 4096-by= te window and access unmapped fixmap slots, potentially triggering a page fault on the transmit softirq path. > + kunmap_local(src); > dest +=3D len; > } > =20 [Severity: High] This is a pre-existing issue, but can concurrent writers to the per-channel tx_stats.syncp corrupt the statistics seqcount? Looking at netvsc_ndoxdp_xmit() in drivers/net/hyperv/netvsc_bpf.c, it sele= cts a transmit queue using q_idx =3D smp_processor_id() % queues and updates th= e stats: drivers/net/hyperv/netvsc_bpf.c:netvsc_ndoxdp_xmit() { ... tx_stats =3D &nvsc_dev->chan_table[q_idx].tx_stats; u64_stats_update_begin(&tx_stats->syncp); tx_stats->xdp_xmit +=3D count; u64_stats_update_end(&tx_stats->syncp); ... } If num_online_cpus() > real_num_tx_queues, multiple CPUs can simultaneously execute XDP transmit for the same queue. Additionally, the NAPI TX completion path independently updates the same syncp on the CPU bound to the VMBus interrupt: drivers/net/hyperv/netvsc.c:netvsc_send_tx_complete() { ... tx_stats =3D &net_device->chan_table[q_idx].tx_stats; u64_stats_update_begin(&tx_stats->syncp); tx_stats->packets +=3D packet->total_packets; tx_stats->bytes +=3D packet->total_bytes; u64_stats_update_end(&tx_stats->syncp); ... } Since u64_stats_update_begin() does not use locks, concurrent updates could leave the seqcount odd forever. This would cause readers like ndo_get_stats= 64() to spin infinitely in u64_stats_fetch_retry(), deadlocking the CPU on 32-bit systems. --=20 Sashiko AI review =C2=B7 https://sashiko.dev/#/patchset/20260603172543.1923= 0-1-leontyevantony@gmail.com?part=3D1