From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id EBF05EE49A3 for ; Tue, 22 Aug 2023 11:04:02 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S234408AbjHVLEC (ORCPT ); Tue, 22 Aug 2023 07:04:02 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:37982 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S234130AbjHVLEC (ORCPT ); Tue, 22 Aug 2023 07:04:02 -0400 Received: from mail-lf1-x136.google.com (mail-lf1-x136.google.com [IPv6:2a00:1450:4864:20::136]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 51DC5CC8 for ; Tue, 22 Aug 2023 04:04:00 -0700 (PDT) Received: by mail-lf1-x136.google.com with SMTP id 2adb3069b0e04-4ff09632194so6111652e87.2 for ; Tue, 22 Aug 2023 04:04:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=szeredi.hu; s=google; t=1692702238; x=1693307038; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=trVN3CuZ4Zhp9Ue7PGXCyXAOehB2OZABgpBxkBylf84=; b=ecHGyCPQo8H5x40ZFNHOeRj5+kqZ1P4F7rr69u8S7Pw9CydrEsm0/pwYtwLuzS81nO S1Ig/gpZ8l1nFgbosUBJG5HQlBrJ4H1dwp2GodBlDwKFmYjEf7VXK7oS4oW0GPEdGWk4 shnVVb8iP8RPJ9UBotomQ9DlD1tGHLyrEaWrY= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1692702238; x=1693307038; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=trVN3CuZ4Zhp9Ue7PGXCyXAOehB2OZABgpBxkBylf84=; b=P7/CJnuSAhFWdmHYf7pSvaFjtD+I6M0YT2NUZUkGoM+o7JwfWhgS4QizRGEZc0rS5t HRaNoHovKpGdeZP/j4QXgUCWsGuet6HjwEBmlsqmQqErPSID48fb4sD6R3lUVgw/s23I T4ccrcB1seEjQju717NPjqdnC/ZuAvMBq3wptgY/7Cwy4g3w3ffY52GtVN7Gp3XiUNDX nHDhPGe4SVn59DmpvkuPgG5rgPPhpTftGkN9oSXr5cZx70qHkNuHOJ2aBwjm35x3c88u Qh/0xolgx4TBjTAfybyqLSLDbZJigzjEGbk3QMT5YfBSziWw0cAHtD7HqABq8iMe0n77 wYcw== X-Gm-Message-State: AOJu0YyPgMDVSQ3OMgjqwAIRvaQx/Ogw/AgQ7CGM1UDmMiYCcTmT+yxa iL2Vfr7e2KkJ8ai6dd+ze/qKv+C7Vno7fPEdO0fR8g== X-Google-Smtp-Source: AGHT+IEjlewioVEmIve9ohhJ00v79UX4XU1Bu1tNq5wyCv6Oj2EB7s9xjSHgBX9SsM8lUufy0Q0T9b+1h6bBcZsrmnw= X-Received: by 2002:ac2:4db9:0:b0:500:8723:e457 with SMTP id h25-20020ac24db9000000b005008723e457mr2005827lfe.30.1692702238292; Tue, 22 Aug 2023 04:03:58 -0700 (PDT) MIME-Version: 1.0 References: <20230519125705.598234-1-amir73il@gmail.com> <20230519125705.598234-6-amir73il@gmail.com> In-Reply-To: From: Miklos Szeredi Date: Tue, 22 Aug 2023 13:03:46 +0200 Message-ID: Subject: Re: [PATCH v13 05/10] fuse: Handle asynchronous read and write in passthrough To: Amir Goldstein Cc: Daniel Rosenberg , Paul Lawrence , Alessio Balsini , fuse-devel@lists.sourceforge.net, linux-fsdevel@vger.kernel.org, overlayfs Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: linux-fsdevel@vger.kernel.org On Tue, 22 Aug 2023 at 12:18, Amir Goldstein wrote: > > On Mon, Aug 21, 2023 at 6:27=E2=80=AFPM Amir Goldstein wrote: > > Getting back to this. > > Did you mean something like that? (only compile tested) > > > > https://github.com/amir73il/linux/commits/backing_fs > > > > If yes, then I wonder: > > 1. Is the difference between FUSE_IOCB_MASK and OVL_IOCB_MASK > > (i.e. the APPEND flag) intentional? Setting IOCB_APPEND on the backing file doesn't make a difference as long as the backing file is not modified during the write. In overlayfs the case of the backing file being modified is not defined, so I guess that's the reason to omit it. However I don't see a problem with setting it on the backing file either, the file size/position is synchronized after the write, so nothing bad should happen if the backing file was modified. > > 2. What would be the right way to do ovl_copyattr() on io completion? > > Pass another completion handler to read/write helpers? > > This seems a bit ugly. Do you have a nicer idea? > > Ugh, I missed that little detail. I don't have a better idea than to use a callback function. > > Hmm. Looking closer, ovl_copyattr() in ovl_aio_cleanup_handler() > seems a bit racy as it is not done under inode_lock(). > > I wonder if it is enough to fix that by adding the lock or if we need > to resort to a more complicated scheme like FUSE_I_SIZE_UNSTABLE > for overlayfs aio? Quite recently rename didn't take inode lock on source, so ovl_aio_cleanup_handler() wasn't the only unlocked instance. I don't see a strong reason to always lock the inode before ovl_copyattr(), but I could be wrong. Thanks, Miklos