Received: by 2002:a05:6a10:6744:0:0:0:0 with SMTP id w4csp5794644pxu; Thu, 22 Oct 2020 11:11:23 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwQ73J37YQ3WUcEjx3DUZektaqj0ElBAdi8i+NbnpNZ+BuBS9SVuIwOimKX/c0b47PsQFdT X-Received: by 2002:a17:906:6d0c:: with SMTP id m12mr3472966ejr.498.1603390282889; Thu, 22 Oct 2020 11:11:22 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1603390282; cv=none; d=google.com; s=arc-20160816; b=c6zNgWmMyCVJyXHd1lJpw5WOZpj4MnoJvhkYMV+bL0KZ/RUcxMD4AcNxCgbdYmKl5E GURNOZEHPp8BXDBBNnm5zr+vGZVDENV38lR6hpXjycwu0RziqZhlW+oTS4ICEQBMCHm7 w3xzSwEZ6cH23cuFrEOdnjBNmIB1yrNv9IXtD2zEmWuKEZynpkEHpaFRXOexdZp51h/b ehDjsZMXuIOSjGQ853uo4vQYYZxTwXukVqkvauUrEhdS5Q9J5DX6MJUWLxVcHlMEbFWf NLmbVrPsz0azl7u1+DjCU7S6qBeleZqhKr8hTnHayCb3Z0A9tgb8uJMjI25duFdZfaa7 naEg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-disposition:mime-version :references:message-id:subject:cc:to:from:date:dkim-signature; bh=v7FaFaTdMJ8tRDnhGBi1+id41DhCNPtJjvfWqcIsB1c=; b=YdyQ4QFMVMRymhZyx7RAS5EF/QbiidS3zoXgNoS9fxqaul8XIjWl+oNYVaZClSgng+ lremgcM6Uh3ztS7Q8UepB/j+eSSOoVQDmRQYurpYNnefQ+g9LuSVZRQHiRAB2DDEWLJ8 lK8yWIISG+xJBLzoWu0N+0AysDvpoCtZvFENEp+IoFkZ2ruwIarG//RoqfZx2iIDmZms z7hpLFn2uDjcrnF/Tcv8/ZPhkoOy1z//SBGyBDbZKk0OoahuublA8MqxwA8Qfe00scXY FEvBKmBY8ktYAg3sYNBfAZdJ5zLuOKmYVpukBk4P5T7Ea7vs8jxIORzV+E6fPkfNHQMR z2CA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@android.com header.s=20161025 header.b=bWxDfT2D; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=android.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id x1si1374833ede.408.2020.10.22.11.11.00; Thu, 22 Oct 2020 11:11:22 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@android.com header.s=20161025 header.b=bWxDfT2D; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=android.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2901908AbgJVQiZ (ORCPT + 99 others); Thu, 22 Oct 2020 12:38:25 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:53380 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2897421AbgJVQiY (ORCPT ); Thu, 22 Oct 2020 12:38:24 -0400 Received: from mail-wr1-x443.google.com (mail-wr1-x443.google.com [IPv6:2a00:1450:4864:20::443]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 3FB19C0613CE for ; Thu, 22 Oct 2020 09:38:24 -0700 (PDT) Received: by mail-wr1-x443.google.com with SMTP id y12so3237843wrp.6 for ; Thu, 22 Oct 2020 09:38:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=android.com; s=20161025; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=v7FaFaTdMJ8tRDnhGBi1+id41DhCNPtJjvfWqcIsB1c=; b=bWxDfT2Dsx5Kvnhe7Mx+CApRxX2EtdjqCMjmsTK/eYMeEXZsTt0RJpSB3CZxHvRluA /C5QuVeAsZ/DeEPdKdhM0E0WGJx2T2v9m3MYhRW4THHYtS+ZE0DpFGmpGRt0IrHa82d0 Xv3iNh3SjhnIzs4SwmEIXMAdEaKHncc6EizoIKb2cmRXjknWU5304kZN9OG6XDiQpZxH SerU5F0hZYBs905dOGoLpPMGvDJuO1BG3E++xZPursi7dE3b9wXy8NHFxPCu5h5w1pZ3 25XeVxXqCgjjGfO2eAUqnw28i9pF+/kRA21vMvb41oR7Wrr0+/g0yrh0R/IHAXK8n9/9 E2Uw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=v7FaFaTdMJ8tRDnhGBi1+id41DhCNPtJjvfWqcIsB1c=; b=pJdvyZmnKg7X2zoh2iaqfGz0X3lsOoqQh2oKDR1MeT5eKyS6WrWdX0ZalgY3/xKKJ7 dMpOHLISMclklVQvAWKMHpaExWqpTkz55AukEsfQl9UQrxHfPxKz+Enrz3h1i1Dk/w7r 0UJ7keuD1d57E4uqNVph1kmIZVqru6n2PWTdEBR15uL/2LBC8uV4H/4mnZPXwF1wMv7P lIt5POj4O4RQYMYMQFBG8wFnnEC7+MK9/KpWeEtQc9pZaS2yIXmpVrG3qwC+pZdb/Pg7 2VXPffsRVKjixtfVQ2rquZ1YKRgLpfk7EbCE80ASUVSqfIgTg6cHmY0yy0sZbyX8k6zt dGmw== X-Gm-Message-State: AOAM5304udqgp29OFs3IwUKeLQof5fz0g/aIDCDFnjpJi/16JtC59TsI sg21zWdABLPevW3jDL9Vz4nS8A== X-Received: by 2002:adf:fe09:: with SMTP id n9mr3801569wrr.144.1603384703024; Thu, 22 Oct 2020 09:38:23 -0700 (PDT) Received: from google.com ([2a00:79e0:d:210:7220:84ff:fe09:7d5c]) by smtp.gmail.com with ESMTPSA id u20sm4013890wmm.29.2020.10.22.09.38.22 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 22 Oct 2020 09:38:22 -0700 (PDT) Date: Thu, 22 Oct 2020 17:38:20 +0100 From: Alessio Balsini To: Miklos Szeredi Cc: Alessio Balsini , Akilesh Kailash , Amir Goldstein , Antonio SJ Musumeci , David Anderson , Giuseppe Scrivano , Jann Horn , Jens Axboe , Martijn Coenen , Palmer Dabbelt , Paul Lawrence , Stefano Duo , Zimuzo Ezeozue , fuse-devel , kernel-team , linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH V9 4/4] fuse: Handle asynchronous read and write in passthrough Message-ID: <20201022163820.GD36774@google.com> References: <20200924131318.2654747-1-balsini@android.com> <20200924131318.2654747-5-balsini@android.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Sep 30, 2020 at 08:54:03PM +0200, Miklos Szeredi wrote: > On Thu, Sep 24, 2020 at 3:13 PM Alessio Balsini wrote: > > > > Extend the passthrough feature by handling asynchronous IO both for read > > and write operations. > > > > When an AIO request is received, if the request targets a FUSE file with > > the passthrough functionality enabled, a new identical AIO request is > > created. The new request targets the lower file system file, and gets > > assigned a special FUSE passthrough AIO completion callback. > > When the lower file system AIO request is completed, the FUSE passthrough > > AIO completion callback is executed and propagates the completion signal to > > the FUSE AIO request by triggering its completion callback as well. > > This ends up with almost identical code in fuse and overlayfs, right? > Maybe it's worth looking into moving these into common helpers. > > Thanks, > Miklos > There are still a few differences between overlayfs and passthrough read/write_iter(), so that merge wouldn't be straightforward. And I would love to see this series merged before increasing its complexity, hopefully in the next version if everything is all right. I will anyway work on the cleanup patch you suggested right after FUSE passthrough gets in, so that I have a solid code base to work on. Would this work for you? That cleanup patch would be handy also for the upcoming plan of having something similar to FUSE passthrough extended to directories, as it was mentioned in a previous discussion on this series with Amir. Thanks! Alessio