From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from fhigh-b8-smtp.messagingengine.com (fhigh-b8-smtp.messagingengine.com [202.12.124.159]) (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 DBDF7376BFD; Wed, 28 Jan 2026 21:14:49 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=202.12.124.159 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1769634893; cv=none; b=FSY44HivDXkVT0vymBXcx31lrJ4tJnYDOzY2Ho0WDk/Z4osKGrTSSEcdO7EmUgIiUAPVH2/Ozh/X2S+oisTWjrkZDe++ePE9XXpzGl2NUbH8mHqYktetq9FiIv68ZBpR2Zh98YloBVGCqDubgvICZDU9ZfCQbsoTkjZh6SYmmV4= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1769634893; c=relaxed/simple; bh=y3nWOVaLspatkNC/G3jqcAfpY++QHJJhun0LP+5pJ+U=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=LWNDycM6CxQhyagPlS66WxOizOIwfyFCgkTGvAYVGL9FokX3r4u0Djl0q9V08Nvef8CCWbk2JK5MrE5x+yRmPuCpDFXeigU/iWNfSTgpTWZiU9B0I99PH28a6/ZaGsn5MbZOrQCj97lzslWvD87BGrLWVJoNdGmWoL+6FiLBrGU= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=bsbernd.com; spf=pass smtp.mailfrom=bsbernd.com; dkim=pass (2048-bit key) header.d=bsbernd.com header.i=@bsbernd.com header.b=Cw4FKDwh; dkim=pass (2048-bit key) header.d=messagingengine.com header.i=@messagingengine.com header.b=w0mFwtk6; arc=none smtp.client-ip=202.12.124.159 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=bsbernd.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=bsbernd.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=bsbernd.com header.i=@bsbernd.com header.b="Cw4FKDwh"; dkim=pass (2048-bit key) header.d=messagingengine.com header.i=@messagingengine.com header.b="w0mFwtk6" Received: from phl-compute-10.internal (phl-compute-10.internal [10.202.2.50]) by mailfhigh.stl.internal (Postfix) with ESMTP id F30377A007B; Wed, 28 Jan 2026 16:14:47 -0500 (EST) Received: from phl-frontend-03 ([10.202.2.162]) by phl-compute-10.internal (MEProxy); Wed, 28 Jan 2026 16:14:48 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsbernd.com; h= cc:cc:content-transfer-encoding:content-type:content-type:date :date:from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:subject:subject:to:to; s=fm1; t=1769634887; x=1769721287; bh=ibzcGPKq4hBXogV1V0bNOXxHlIUu7PQmkV8WqBqGn2Y=; b= Cw4FKDwhPk29dpSTeocxLCx1sxrfqOsZIGtwZv8HzeXLQU4EdUG5Bf5PqjlMUe1w LElE573A+KaHAvmuhn3AQfjXz52LvEAPtPysuokh9QRjuQIUtTWDcp6t9vbD3SJT LO89+ybjMx8HzDyLGajRAJqvWoJWGVAYgQhXlliqxxFIoUyEKPlFvtclC62ZKJI0 PS08GYoDJDB2rwpFWFB2j0G54H90RzYN7C8MjLdZI3wAHAXtTojAKvCDC9vVzSyv oaebhgKCfEkjCKMHJn+bqQAhJTSYAhLrwP4LfBbay9cQHHT9S4HXVPgBcbRVg8zt R3DQE9lczzZYGzCxvsgr6g== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-transfer-encoding :content-type:content-type:date:date:feedback-id:feedback-id :from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:subject:subject:to:to:x-me-proxy :x-me-sender:x-me-sender:x-sasl-enc; s=fm3; t=1769634887; x= 1769721287; bh=ibzcGPKq4hBXogV1V0bNOXxHlIUu7PQmkV8WqBqGn2Y=; b=w 0mFwtk6//qXorJFyWnqNrsDJQ4WexfoddyeRzR7tqr9bLm6hxT4GbmhTnjiY/bE2 VAlP2roJU1GKt4aHiXwLIZp+xRHp71gF35ePCSM5+XsmJ9QfLgxtugXx//v6BmuY tDRpLlcHHctQxT72XQj549lzNcZDd9uhCXosW1V0pBpHNQiXdRtBK5uuKVCJ3F66 xD3eHEw3rpB8Z9gAATpeGvGXLjPSP64PMMUlamUmmxcpMbrECihoAqEosLoYpev5 KU3N/dXxKCIoi8/L/XuAjGpWg2sUb++b6B7Ff41j5RLZNAPpW91oDnv+37wo8GcQ f4uFKO+LwIKyGp8NRyoCA== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeefgedrtddtgdduieegfeejucetufdoteggodetrf dotffvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfurfetoffkrfgpnffqhgenuceu rghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmnecujf gurhepkfffgggfuffvvehfhfgjtgfgsehtkeertddtvdejnecuhfhrohhmpeeuvghrnhgu ucfutghhuhgsvghrthcuoegsvghrnhgusegsshgsvghrnhgurdgtohhmqeenucggtffrrg htthgvrhhnpeefgeegfeffkeduudelfeehleelhefgffehudejvdfgteevvddtfeeiheef lefgvdenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpe gsvghrnhgusegsshgsvghrnhgurdgtohhmpdhnsggprhgtphhtthhopeduuddpmhhouggv pehsmhhtphhouhhtpdhrtghpthhtohepjhhorghnnhgvlhhkohhonhhgsehgmhgrihhlrd gtohhmpdhrtghpthhtohepsghstghhuhgsvghrthesuggunhdrtghomhdprhgtphhtthho pegrgigsohgvsehkvghrnhgvlhdrughkpdhrtghpthhtohepmhhikhhlohhssehsiigvrh gvughirdhhuhdprhgtphhtthhopegtshgrnhguvghrsehpuhhrvghsthhorhgrghgvrdgt ohhmpdhrtghpthhtohepkhhrihhsmhgrnhesshhushgvrdguvgdprhgtphhtthhopehioh dquhhrihhnghesvhhgvghrrdhkvghrnhgvlhdrohhrghdprhgtphhtthhopegrshhmlhdr shhilhgvnhgtvgesghhmrghilhdrtghomhdprhgtphhtthhopeigihgrohgsihhnghdrlh hisehsrghmshhunhhgrdgtohhm X-ME-Proxy: Feedback-ID: i5c2e48a5:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Wed, 28 Jan 2026 16:14:45 -0500 (EST) Message-ID: Date: Wed, 28 Jan 2026 22:14:43 +0100 Precedence: bulk X-Mailing-List: io-uring@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v4 18/25] fuse: support buffer copying for kernel addresses To: Joanne Koong , Bernd Schubert Cc: axboe@kernel.dk, miklos@szeredi.hu, csander@purestorage.com, krisman@suse.de, io-uring@vger.kernel.org, asml.silence@gmail.com, xiaobing.li@samsung.com, safinaskar@gmail.com, linux-fsdevel@vger.kernel.org References: <20260116233044.1532965-1-joannelkoong@gmail.com> <20260116233044.1532965-19-joannelkoong@gmail.com> <68b3ff9d-ebcf-45c9-a50a-b5a59d332f4c@ddn.com> From: Bernd Schubert Content-Language: en-US, de-DE, fr In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit On 1/28/26 01:23, Joanne Koong wrote: > On Tue, Jan 27, 2026 at 3:40 PM Bernd Schubert wrote: >> >> On 1/17/26 00:30, Joanne Koong wrote: >>> This is a preparatory patch needed to support kernel-managed ring >>> buffers in fuse-over-io-uring. For kernel-managed ring buffers, we get >>> the vmapped address of the buffer which we can directly use. >>> >>> Currently, buffer copying in fuse only supports extracting underlying >>> pages from an iov iter and kmapping them. This commit allows buffer >>> copying to work directly on a kaddr. >>> >>> Signed-off-by: Joanne Koong >>> --- >>> fs/fuse/dev.c | 23 +++++++++++++++++------ >>> fs/fuse/fuse_dev_i.h | 7 ++++++- >>> 2 files changed, 23 insertions(+), 7 deletions(-) >>> >>> diff --git a/fs/fuse/dev.c b/fs/fuse/dev.c >>> index 6d59cbc877c6..ceb5d6a553c0 100644 >>> --- a/fs/fuse/dev.c >>> +++ b/fs/fuse/dev.c >>> @@ -848,6 +848,9 @@ void fuse_copy_init(struct fuse_copy_state *cs, bool write, >>> /* Unmap and put previous page of userspace buffer */ >>> void fuse_copy_finish(struct fuse_copy_state *cs) >>> { >>> + if (cs->is_kaddr) >>> + return; >>> + >>> if (cs->currbuf) { >>> struct pipe_buffer *buf = cs->currbuf; >>> >>> @@ -873,6 +876,9 @@ static int fuse_copy_fill(struct fuse_copy_state *cs) >>> struct page *page; >>> int err; >>> >>> + if (cs->is_kaddr) >>> + return 0; >>> + >>> err = unlock_request(cs->req); >>> if (err) >>> return err; >>> @@ -931,15 +937,20 @@ static int fuse_copy_do(struct fuse_copy_state *cs, void **val, unsigned *size) >>> { >>> unsigned ncpy = min(*size, cs->len); >>> if (val) { >>> - void *pgaddr = kmap_local_page(cs->pg); >>> - void *buf = pgaddr + cs->offset; >>> + void *pgaddr, *buf; >>> + if (!cs->is_kaddr) { >>> + pgaddr = kmap_local_page(cs->pg); >>> + buf = pgaddr + cs->offset; >>> + } else { >>> + buf = cs->kaddr + cs->offset; >>> + } >>> >>> if (cs->write) >>> memcpy(buf, *val, ncpy); >>> else >>> memcpy(*val, buf, ncpy); >>> - >>> - kunmap_local(pgaddr); >>> + if (!cs->is_kaddr) >>> + kunmap_local(pgaddr); >>> *val += ncpy; >>> } >>> *size -= ncpy; >>> @@ -1127,7 +1138,7 @@ static int fuse_copy_folio(struct fuse_copy_state *cs, struct folio **foliop, >>> } >>> >>> while (count) { >>> - if (cs->write && cs->pipebufs && folio) { >>> + if (cs->write && cs->pipebufs && folio && !cs->is_kaddr) { >>> /* >>> * Can't control lifetime of pipe buffers, so always >>> * copy user pages. >>> @@ -1139,7 +1150,7 @@ static int fuse_copy_folio(struct fuse_copy_state *cs, struct folio **foliop, >>> } else { >>> return fuse_ref_folio(cs, folio, offset, count); >>> } >>> - } else if (!cs->len) { >>> + } else if (!cs->len && !cs->is_kaddr) { >>> if (cs->move_folios && folio && >>> offset == 0 && count == size) { >>> err = fuse_try_move_folio(cs, foliop); >>> diff --git a/fs/fuse/fuse_dev_i.h b/fs/fuse/fuse_dev_i.h >>> index 134bf44aff0d..aa1d25421054 100644 >>> --- a/fs/fuse/fuse_dev_i.h >>> +++ b/fs/fuse/fuse_dev_i.h >>> @@ -28,12 +28,17 @@ struct fuse_copy_state { >>> struct pipe_buffer *currbuf; >>> struct pipe_inode_info *pipe; >>> unsigned long nr_segs; >>> - struct page *pg; >>> + union { >>> + struct page *pg; >>> + void *kaddr; >>> + }; >>> unsigned int len; >>> unsigned int offset; >>> bool write:1; >>> bool move_folios:1; >>> bool is_uring:1; >>> + /* if set, use kaddr; otherwise use pg */ >>> + bool is_kaddr:1; >>> struct { >>> unsigned int copied_sz; /* copied size into the user buffer */ >>> } ring; >> >> >> I'm confused here, how cs->len will get initialized. So far that was >> done from fuse_copy_fill? > > With kaddrs, cs->len is initialized when the copy state is set up (in > setup_fuse_copy_state()) before we do any copying to/from the ring. > The changes for that are in the later patch that adds the ringbuffer > logic ("fuse: add io-uring kernel-managed buffer ring"). The kaddr and > len correspond to the address and length of the buffer that was > selected from the ring buffer (in fuse_uring_select_buffer()). Maybe we could add a sanity check into fuse_copy_do() or even into fuse_copy_fill in the cs->is_kaddr condition that cs->len is > 0? Otherwise looks good. Reviewed-by: Bernd Schubert