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 6E796334C35; Mon, 23 Feb 2026 23:02:41 +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=1771887761; cv=none; b=nSLS0oFE8U7XoiNOW9PkQzhieKiFCON0AI/mpaFM25pzmw5qaRYaUvShJwy83ZZdAOEjcmsr662TCIwc9gV0ap8vJRIy4J+0XGEWm/cZfDFl44OgBV8OPchD6Fgj8JGwViZVvT+UvSERnS6Fv7vZ5B4u+CyXH9tLl0UYON+mNL0= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1771887761; c=relaxed/simple; bh=icioDdUw7adyz75g3/0RUCgFlwco5oQ9dEvohY1Znys=; h=Date:Subject:From:To:Cc:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=Hm3g66+sR/qJU2zUFR2JFqtQu87ZlWoXYBrRpQf38EGlKpi0WfcMo45SaYnEjaTQalThW997HCu9n+y/FnlOoB/rHPblKXil2eJWdY3mF1KES4pxpxZnPUGA31OYOKmR3ezyx1MVm7lBnVynzaJc1r7c9EVyfO7aGGDLTIPOaXk= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=JXpTH9W6; 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="JXpTH9W6" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 08FCAC116C6; Mon, 23 Feb 2026 23:02:41 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1771887761; bh=icioDdUw7adyz75g3/0RUCgFlwco5oQ9dEvohY1Znys=; h=Date:Subject:From:To:Cc:In-Reply-To:References:From; b=JXpTH9W6YUC0Fdd1F/WHRUy6ErrdnlzSsa9dRVkRntNnslKEO70oq4Eb4tIScdQuB W+Muqt61S2pscZd/jPbsY7BsiLkPmpUn19DP1C8JqATHHpdeKwMZ5yjfFtXi9RG4IF x/OddPLOULMS37GhlOWIcsyQCOkIbetl7BftQiKTa5URxL3sxCOvOmkSKClIU+wYXt S9XpTNJ2k4Y2RCLRdX5SLLIPBmiV+N4+wH1CMevI8Hb83SMcxPRy53cqP5lHEm7WXh cnvBXZJ+CsTbbgfA1t5yYM7mMApvbgC+Ojf1/zmRQtGOfO891CUoq8Wffo7TlP0h9Z MF2OK80LIt08w== Date: Mon, 23 Feb 2026 15:02:40 -0800 Subject: [PATCHSET RFC 9/9] fuse: allow fuse servers to upload iomap BPF programs From: "Darrick J. Wong" To: miklos@szeredi.hu, djwong@kernel.org Cc: bpf@vger.kernel.org, joannelkoong@gmail.com, bpf@vger.kernel.org, john@groves.net, bernd@bsbernd.com, neal@gompa.dev, linux-fsdevel@vger.kernel.org, linux-ext4@vger.kernel.org Message-ID: <177188736765.3938194.6770791688236041940.stgit@frogsfrogsfrogs> In-Reply-To: <20260223224617.GA2390314@frogsfrogsfrogs> References: <20260223224617.GA2390314@frogsfrogsfrogs> 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="utf-8" Content-Transfer-Encoding: 7bit Hi all, There are certain fuse servers that might benefit from the ability to upload a BPF program into the kernel to respond to ->iomap_begin requests instead of upcalling the fuse server itself. For example, consider a fuse server that abstracts a large amount of storage for use as intermediate storage by programs. If the storage is striped across hardware devices (e.g. RAID0 or interleaved memory controllers) then the iomapping pattern will be completely regular but the mappings themselves might be very small. Performance for large IOs will suck if it is necessary to upcall the fuse server every time we cross a mapping boundary. The fuse server can try to mitigate that hit by upserting mappings ahead of time, but there's a better solution for this usecase: BPF programs. In this case, the fuse server can compile a BPF program that will compute the mapping data for a given request and upload the program. This avoids the overhead of cache lookups and server upcalls. Note that the BPF verifier still imposes instruction count and complexity limits on the uploaded programs. Note that I embraced and extended some code from Joanne, but at this point I've modified it so heavily that it's not really the original anymore. But she still gets credit for coming up with the idea and engaging me in flinging prototypes around. Now with kfuncs to manage the cache, and some ability to restrict memory access from within the BPF program. If you're going to start using this code, I strongly recommend pulling from my git trees, which are linked below. With a bit of luck, this should all go splendidly. Comments and questions are, as always, welcome. --D kernel git tree: https://git.kernel.org/cgit/linux/kernel/git/djwong/xfs-linux.git/log/?h=fuse-iomap-bpf --- Commits in this patchset: * fuse: enable fuse servers to upload BPF programs to handle iomap requests * fuse_trace: enable fuse servers to upload BPF programs to handle iomap requests * fuse: prevent iomap bpf programs from writing to most of the system * fuse: add kfuncs for iomap bpf programs to manage the cache * fuse: make fuse_inode opaque to iomap bpf programs --- fs/fuse/fuse_i.h | 5 fs/fuse/fuse_iomap_bpf.h | 123 ++++++++++++ fs/fuse/fuse_iomap_i.h | 6 + fs/fuse/fuse_trace.h | 53 +++++ fs/fuse/Makefile | 4 fs/fuse/fuse_iomap.c | 17 +- fs/fuse/fuse_iomap_bpf.c | 464 ++++++++++++++++++++++++++++++++++++++++++++++ fs/fuse/inode.c | 7 + fs/fuse/trace.c | 1 kernel/bpf/btf.c | 1 10 files changed, 676 insertions(+), 5 deletions(-) create mode 100644 fs/fuse/fuse_iomap_bpf.h create mode 100644 fs/fuse/fuse_iomap_bpf.c