From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (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 1260B38645C; Mon, 23 Mar 2026 09:13:08 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1774257189; cv=none; b=IAMoIWp50673lX7OldzuRG0xhq1aOEoavrH2k18cJQNaGBO2KEcEjoe30rvsm8zP2qVXcubCUDDH4gU3hfGLUwhdb7SFjQGoNFxFJryEKqulPUlwI08yNhdy2xZUSwwA4+z5LcJrtLRRJjhztv6leVIEMgpRxIDbrN9KcIPvIPw= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1774257189; c=relaxed/simple; bh=wzMrqKx3Jtzn/TAs56FycVP5WjxG7mSofPlph6puuTE=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=d/6cb/WTHpRio3DUgEoymf65kGKM/au8CA4Uq5/BbqZzTJf87+0opctAdhyFO8MSHkafnHCXcFT2J9npxeUdeo4eq5R4siGPzTbjZWQUA3u9Xbu5xu9aAouUujc7U9/nSwmImCxldAajJrEIaALUNQnxn8f835rOUXQC8WENpZk= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=joSxwlsp; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="joSxwlsp" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 06702C4CEF7; Mon, 23 Mar 2026 09:13:08 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1774257188; bh=wzMrqKx3Jtzn/TAs56FycVP5WjxG7mSofPlph6puuTE=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=joSxwlspVhKYcgE4zizMzEupkVxH7zBoRt16ItgpGqtktF8hLPrEEOTxfgh4aRR46 H0U9alpLsA83SdovjY4NjT0S8IVfoGCFHfdV08wBojK7QatPitGsHroy+nurmzIUo5 9LTrYrheRCty7XcM5Hdcd35jJVYk4YzX2FwqnAgbFVPaee1S/zk0OOYbb6dWKe54SV Qejn61X7CFhOqRsAbeUsXpGiEPrzUHGPx8hpLYNbDN7Ghgx9DVL33kddcsAYc4j5Sz AmCzqaip3eo7Xnd8PbIQkYXGzXvvJm8fegMwy8XoqhfyH8Ytxfa3hUrWvBicIE9Bu0 C1NjdvWhW+Gjw== Date: Mon, 23 Mar 2026 09:13:06 +0000 From: "Lorenzo Stoakes (Oracle)" To: Michael Kelley Cc: Long Li , Andrew Morton , Jonathan Corbet , Clemens Ladisch , Arnd Bergmann , Greg Kroah-Hartman , "K . Y . Srinivasan" , Haiyang Zhang , Wei Liu , Dexuan Cui , Alexander Shishkin , Maxime Coquelin , Alexandre Torgue , Miquel Raynal , Richard Weinberger , Vignesh Raghavendra , Bodo Stroesser , "Martin K . Petersen" , David Howells , Marc Dionne , Alexander Viro , Christian Brauner , Jan Kara , David Hildenbrand , "Liam R . Howlett" , Vlastimil Babka , Mike Rapoport , Suren Baghdasaryan , Michal Hocko , Jann Horn , Pedro Falcato , "linux-kernel@vger.kernel.org" , "linux-doc@vger.kernel.org" , "linux-hyperv@vger.kernel.org" , "linux-stm32@st-md-mailman.stormreply.com" , "linux-arm-kernel@lists.infradead.org" , "linux-mtd@lists.infradead.org" , "linux-staging@lists.linux.dev" , "linux-scsi@vger.kernel.org" , "target-devel@vger.kernel.org" , "linux-afs@lists.infradead.org" , "linux-fsdevel@vger.kernel.org" , "linux-mm@kvack.org" , Ryan Roberts Subject: Re: [PATCH v4 18/21] drivers: hv: vmbus: replace deprecated mmap hook with mmap_prepare Message-ID: <409ff1b0-43ff-4b1d-ad07-7624e0817640@lucifer.local> References: <05467cb62267d750e5c770147517d4df0246cda6.1774045440.git.ljs@kernel.org> Precedence: bulk X-Mailing-List: linux-fsdevel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: On Mon, Mar 23, 2026 at 04:16:20AM +0000, Michael Kelley wrote: > From: Lorenzo Stoakes (Oracle) Sent: Friday, March 20, 2026 3:40 PM > > > > The f_op->mmap interface is deprecated, so update the vmbus driver to use > > its successor, mmap_prepare. > > > > This updates all callbacks which referenced the function pointer > > hv_mmap_ring_buffer to instead reference hv_mmap_prepare_ring_buffer, > > utilising the newly introduced compat_set_desc_from_vma() and > > __compat_vma_mmap() to be able to implement this change. > > > > The UIO HV generic driver is the only user of hv_create_ring_sysfs(), > > which is the only function which references > > vmbus_channel->mmap_prepare_ring_buffer which, in turn, is the only > > external interface to hv_mmap_prepare_ring_buffer. > > > > This patch therefore updates this caller to use mmap_prepare instead, > > which also previously used vm_iomap_memory(), so this change replaces it > > with its mmap_prepare equivalent, mmap_action_simple_ioremap(). > > > > Signed-off-by: Lorenzo Stoakes (Oracle) > > --- > > drivers/hv/hyperv_vmbus.h | 4 ++-- > > drivers/hv/vmbus_drv.c | 31 +++++++++++++++++++------------ > > drivers/uio/uio_hv_generic.c | 11 ++++++----- > > include/linux/hyperv.h | 4 ++-- > > 4 files changed, 29 insertions(+), 21 deletions(-) > > > > There are two mmap() code paths in the Hyper-V UIO code. One path is > to mmap() the file descriptor for /dev/uio, and the other is to mmap() > the "ring" entry under /sys/devices/vmbus/devices/. The former is > done by uio_mmap(), and the latter by hv_uio_ring_mmap_prepare(). > > I tested both these paths using a combination of two methods in a > x86/x64 VM on Hyper-V: > > 1) Using the fcopy daemon, which maps the ring buffer for the primary > channel and sends/receives messages with the Hyper-V host. This > method tests only the 1st path because the fcopy daemon doesn't create > any subchannels that would use the "ring" entry. > > 2) Using a custom-built test program. This program doesn't communicate > with the Hyper-V host, but allows mostly verifying both code paths for the > primary channel. As a sanity check, it verifies that the two mmaps are > mapping the same memory, as expected. > > As such, > > Reviewed-by: Michael Kelley > Tested-by: Michael Kelley Perfect, thanks so much for this! It is tricky for me to test these, beyond fairly exhaustive logical confirmation of equivalence, so this is _hugely_ helpful. > > The most robust test would be to run DPDK networking against > UIO, as it would communicate with the Hyper-V host and use > multiple subchannels that resulting in mmap'ing the "ring" > entry under /sys. > > @Long Li -- I'll leave it to your discretion as to whether you want > to test DPDK against these mmap() changes. Thanks in advance for taking a look on this also! > > I've noted one minor issue below. > > [snip] > > --- a/include/linux/hyperv.h > +++ b/include/linux/hyperv.h > @@ -1015,8 +1015,8 @@ struct vmbus_channel { > /* The max size of a packet on this channel */ > u32 max_pkt_size; > > - /* function to mmap ring buffer memory to the channel's sysfs ring attribute */ > - int (*mmap_ring_buffer)(struct vmbus_channel *channel, struct vm_area_struct *vma); > + /* function to mmap_prepare ring buffer memory to the channel's sysfs ring attribute */ > > Changing the comment from "mmap ring buffer" to "mmap_prepare ring buffer" > produces awkward wording since "mmap" is used here as a verb. It might be better > to just leave the comment unchanged. Sure am happy with that of course, I think Sashiko moaned about this but it's obviously fine either way. Andrew - do you mind restoring the comment to its original form above? Thanks! > > Michael > > > + int (*mmap_prepare_ring_buffer)(struct vmbus_channel *channel, struct vm_area_desc *desc); > > /* boolean to control visibility of sysfs for ring buffer */ > bool ring_sysfs_visible; Cheers, Lorenzo