Received: by 2002:a05:6358:d09b:b0:dc:cd0c:909e with SMTP id jc27csp5198458rwb; Mon, 21 Nov 2022 18:30:46 -0800 (PST) X-Google-Smtp-Source: AA0mqf4l2u+cZs7eNBZunC0zhoRR7gpnv+atoCjirzqjWmlg2pla/ne2KylvkvFLPDWFkFdWo8Es X-Received: by 2002:aa7:d3cb:0:b0:461:8d98:3d6d with SMTP id o11-20020aa7d3cb000000b004618d983d6dmr5257158edr.116.1669084246355; Mon, 21 Nov 2022 18:30:46 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1669084246; cv=none; d=google.com; s=arc-20160816; b=yFy+W6eCXa63SKh/IPHAOkKYc2O06yLK+hSuNOLnPc5mhmoftLT2Z/3Lg7X9E9V4Qf jWOGigOwh618DNuq8xYpNDTO9AJ8wsckKwpXNgqYhMjwJm3CcQRNMOeQeHCAGzb0qAPa MpuGrlC++RGCjQKUZLhd2bgen9zDn9YYUyM9H5Y++nd25+q2J/PuRF2ve9Yd2MHhdoKC ri/em8EL/9owIeFdjF+qf0ANRHGMO4vhXARhvzqe/8ta3Bi6I7CKFCPngDSjRCDqSKIy fWYKDLy2iwgn0oqpgRfdExZuRnNmuR2iYjFJ0BjEYLdiprL5pvCd+Yxb0mRpJbLXYtEh Fcsg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:cc:to:from:subject:message-id:mime-version:date :dkim-signature; bh=QwnVufQmqgsD71rU58/FXnZ6Kqu/OdIMDvlzn78hKF0=; b=Rf3qcqn8Y1EhjmXlQOMamAfVolJ1jkUR3460/P/7UTXyro3pH1gYXZnHCTdW7zcEar Adk4cYxchZjFBGy2M8n9dLwjnhLk3+mfJgh5hygqRSou/Hy6C+lwjl7yHxQtJ774GHTt hTBkKtG6jtPxHLHS3hMi/NCwp5r4J+imIpi3GZjif7q6c1tS+CYNeS78vTSbMwgmA8Ky UarwqWzcwtJhfSCjHbxRqRMZFT3+L6n1/3vKzLEIzNKv5F2Z258XqaXjG9hTVq5tno02 A7D7vMa1pT1E5Zb2V90aY92aIAeIX3N58T8C8TnhKQ7dbDYu1ENGwEz6CCK8U5Goh7uo IsDA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20210112 header.b="k4vZ9/HU"; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id ji22-20020a170907981600b007adf16570c3si6826892ejc.17.2022.11.21.18.30.24; Mon, 21 Nov 2022 18:30:46 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@google.com header.s=20210112 header.b="k4vZ9/HU"; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232461AbiKVCQA (ORCPT + 92 others); Mon, 21 Nov 2022 21:16:00 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:41550 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231678AbiKVCP4 (ORCPT ); Mon, 21 Nov 2022 21:15:56 -0500 Received: from mail-yw1-x114a.google.com (mail-yw1-x114a.google.com [IPv6:2607:f8b0:4864:20::114a]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id B9FDBE0CB2 for ; Mon, 21 Nov 2022 18:15:54 -0800 (PST) Received: by mail-yw1-x114a.google.com with SMTP id 00721157ae682-39967085ae9so75175667b3.11 for ; Mon, 21 Nov 2022 18:15:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=cc:to:from:subject:message-id:mime-version:date:from:to:cc:subject :date:message-id:reply-to; bh=QwnVufQmqgsD71rU58/FXnZ6Kqu/OdIMDvlzn78hKF0=; b=k4vZ9/HUzOIP2zBuWKoMtl7qYaF7WljtXH1qLMOjUPNFZJcho4S6mcX9oJEpI4eEhd jQaDsDTCWLUiqZD9gEJJFxO5PXor/IPqkbWeHOf7/uBxPI/E42dhTBwWw9pGFQOWfXAz XDQ8fyBePklEduv9JeWkDQ4ti9U2YQjgKEpwKg/jWHBZfFhH4Wu+UWVBtFUv25SKyusZ fSg7ZhiEjA0ThA2qFhWu1e3M4PLIRyFPrs/duf2FcIkJ/FvMpg33uhosLAvbGHdEgxYZ /ZnujCg1Q8yPcTksxCuAuCvR2S9fKlQMl0DKNoWVw/W4d1VCUoEAFxKyWrQ4PB5xS8r4 TzGA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:from:subject:message-id:mime-version:date:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=QwnVufQmqgsD71rU58/FXnZ6Kqu/OdIMDvlzn78hKF0=; b=Xj8XwZwyxy/tB3L8vQyXOPg88MKA2+s8x9trJGYy3ed6+IRI+/c1fnBOPjKua4xc3B SXA00jtVcHnMEbgJiC8/l35luWUQdKQ10bCO70RytQilZZh8QGl32b/5mUWdbOiGyySN OVxdtANbH0J4AptH3mqoB5zV2uPiMt/ySLQs6Zrp2m1dqLa0NBD+NEKJPzwv39MpquEd 5G44/d4yHA7JarQl72kcR5zrFW+HEfGIfLWOZtgwjhga3YAmgZimpl9UOvSM7Jz19RiM s46hVznaszIyHL9Fb/yojr9TMtPNH+koe4kWU5lFWiiupCsvqbQIe7DYWDTQqEyil6cy WzVQ== X-Gm-Message-State: ANoB5pmk9XAZziJ+GhX0kr6ta59LVRL9CI1lWrHKDr0TSnBB/t+Q65Kd /LZcKJ8U9odcFRryjzRj0md4U3XOo4k= X-Received: from drosen.mtv.corp.google.com ([2620:15c:211:200:8539:aadd:13be:6e82]) (user=drosen job=sendgmr) by 2002:a81:d449:0:b0:38f:af02:ee94 with SMTP id g9-20020a81d449000000b0038faf02ee94mr3ywl.230.1669083353587; Mon, 21 Nov 2022 18:15:53 -0800 (PST) Date: Mon, 21 Nov 2022 18:15:15 -0800 Mime-Version: 1.0 X-Mailer: git-send-email 2.38.1.584.g0f3c55d4c2-goog Message-ID: <20221122021536.1629178-1-drosen@google.com> Subject: [RFC PATCH v2 00/21] FUSE BPF: A Stacked Filesystem Extension for FUSE From: Daniel Rosenberg To: Miklos Szeredi Cc: Amir Goldstein , linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org, linux-unionfs@vger.kernel.org, bpf@vger.kernel.org, kernel-team@android.com, Daniel Rosenberg Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-9.6 required=5.0 tests=BAYES_00,DKIMWL_WL_MED, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_NONE, SPF_HELO_NONE,SPF_PASS,USER_IN_DEF_DKIM_WL autolearn=unavailable autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org These patches extend FUSE to be able to act as a stacked filesystem. This allows pure passthrough, where the fuse file system simply reflects the lower filesystem, and also allows optional pre and post filtering in BPF and/or the userspace daemon as needed. This can dramatically reduce or even eliminate transitions to and from userspace. For this patch set, I have removed the code related to the bpf side of things since that is undergoing some large reworks to get it in line with the more recent BPF developements. This set of patches implements direct passthrough to the lower filesystem with no alteration. Looking at the v1 code should give a pretty good idea of what the general shape of the bpf calls will look like. Without the bpf side, it's like a less efficient bind mount. Not very useful on its own, but still useful to get eyes on it since the backing calls will be larglely the same when bpf is in the mix. This changes the format of adding a backing file/bpf slightly from v1. It's now a bit more modular. You add a block of data at the end of a lookup response to give the bpf fd and backing id, but there is now a type header to both blocks, and a reserved value for future additions. In the future, we may allow for multiple bpfs or backing files, and this will allow us to extend it without any UAPI breaking changes. Multiple BPFs would be useful for combining fuse-bpf implementations without needing to manually combine bpf fragments. Multiple backing files would allow implementing things like a limited overlayfs. In this patch set, this is only a single block, with only backing supported, although I've left the definitions reflecting the BPF case as well. For bpf, the plan is to have two blocks, with the bpf one coming first. Any further extensions are currently just speculative. You can run this without needing to set up a userspace daemon by adding these mount options: root_dir=[fd],no_daemon where fd is an open file descriptor pointing to the folder you'd like to use as the root directory. The fd can be immediately closed after mounting. This is useful for running various fs tests. The main changes for v2: -Refactored code to remove many of the ifdefs -Adjusted attr related code per Amir's suggestions -Added ioctl interface for responding to fuse requests (required for backing) -Adjusted lookup add-on block for adding backing file/bpf -Moved bpf related patches to the end of the stack (not included currently) TODO: override_creds to interact with backing files in the same context the daemon would Implement backing calls for other FUSE operations (i.e. File Locking/tmp files) Convert BPF over to more modern version Alessio Balsini (1): fs: Generic function to convert iocb to rw flags Daniel Rosenberg (20): fuse-bpf: Update fuse side uapi fuse-bpf: Prepare for fuse-bpf patch fuse: Add fuse-bpf, a stacked fs extension for FUSE fuse-bpf: Add ioctl interface for /dev/fuse fuse-bpf: Don't support export_operations fuse-bpf: Add support for FUSE_ACCESS fuse-bpf: Partially add mapping support fuse-bpf: Add lseek support fuse-bpf: Add support for fallocate fuse-bpf: Support file/dir open/close fuse-bpf: Support mknod/unlink/mkdir/rmdir fuse-bpf: Add support for read/write iter fuse-bpf: support FUSE_READDIR fuse-bpf: Add support for sync operations fuse-bpf: Add Rename support fuse-bpf: Add attr support fuse-bpf: Add support for FUSE_COPY_FILE_RANGE fuse-bpf: Add xattr support fuse-bpf: Add symlink/link support fuse-bpf: allow mounting with no userspace daemon fs/fuse/Kconfig | 8 + fs/fuse/Makefile | 1 + fs/fuse/backing.c | 3118 +++++++++++++++++++++++++++++++++++++ fs/fuse/control.c | 2 +- fs/fuse/dev.c | 83 +- fs/fuse/dir.c | 326 ++-- fs/fuse/file.c | 62 +- fs/fuse/fuse_i.h | 424 ++++- fs/fuse/inode.c | 264 +++- fs/fuse/ioctl.c | 2 +- fs/fuse/readdir.c | 5 + fs/fuse/xattr.c | 18 + fs/overlayfs/file.c | 23 +- include/linux/fs.h | 5 + include/uapi/linux/fuse.h | 24 +- 15 files changed, 4154 insertions(+), 211 deletions(-) create mode 100644 fs/fuse/backing.c base-commit: 23a60a03d9a9980d1e91190491ceea0dc58fae62 -- 2.38.1.584.g0f3c55d4c2-goog