From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-oi1-f169.google.com (mail-oi1-f169.google.com [209.85.167.169]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id EE8A6363C6B for ; Mon, 1 Jun 2026 19:25:56 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.167.169 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1780341958; cv=none; b=E1Vl5UUpxAMt10bIed4hrDU3WkwAokePNpWHq3+EeUhu6EPA3wL4zoQIY1d3w+wM7tAADVeNVR5PX4+x5hOfCFhHwy+C0Lz3St7q1orve8X1GGRq+yaDH3PlNywFNj/oyZsyhYJsPZ8Y0dGegfZQ1N0l2vmea2Qbx4yYigyWFAg= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1780341958; c=relaxed/simple; bh=OWRuh/RR8NJ5UTF40FybsEdKJgrcmOFPEN3Dxz4VubM=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Message-Id:References:To; b=h6FaiqSEOSQJOBdh8WX4/M8nyF6gTEVpyaPkMb+bKySE7OhUdSlnLMUvga30/hlu1XwvPKOY51IpHPeZQAjUWvs3wm2QqtZFQAikBC7PUIlIm2ia1inM45OcVfIdbc5SL4j2SVbBLlQxi7ZrqzaNt4Jm0mESVO8P6lyrOKLmxRE= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=Com3fMZj; arc=none smtp.client-ip=209.85.167.169 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="Com3fMZj" Received: by mail-oi1-f169.google.com with SMTP id 5614622812f47-48611dd2139so2143365b6e.3 for ; Mon, 01 Jun 2026 12:25:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1780341956; x=1780946756; darn=vger.kernel.org; h=to:references:message-id:content-transfer-encoding:cc:date :in-reply-to:from:subject:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=oUcR4pbJRw7eHCuwwMVNxCHcKa3q8+6m2Z16fn9DjGg=; b=Com3fMZjkuy7lIagmBX8i8vMyu+UXlDiCMaFsfWr+WEHkDso+lNictsXYhHmOEtZr0 5pq2E7pvU14CuaA/h9bMYSC+g1rNHlkgzmNEH6dBo6GXFvaeZ6q28ZgmSnsmbSXT6TPp mViq4QAzNdYjgZFW0NV90y7G70XBMsoI5YJH6DkNkY6cp9ObCkntLzPZw9uKvgVurXH+ NgvJJL03yr8IBPsijMDmm0GGCiBBhosUthHr5KwNzdDFSuz8CcUMrFrekx1b6FY0hquD OiKSJaC5+EDmCQ0VDovBbaBqNw1ZzdnJNZtpip82Sz4kcoKd0Usj5QXpLZkN+1wsF743 137w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1780341956; x=1780946756; h=to:references:message-id:content-transfer-encoding:cc:date :in-reply-to:from:subject:mime-version:x-gm-gg:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=oUcR4pbJRw7eHCuwwMVNxCHcKa3q8+6m2Z16fn9DjGg=; b=FMpzPUcg6EksTL6GabkVkpnaON3DrqhtfjFvovFFsawU9yD2EZGX9saisgik2E3V5n zZMovVdQfRZDCxCc8GyU5xKOHtqFkZ5CTCTm/0JgzFaK87DX/V8SYQoGd94l4CAyQqVS HKWLuNlU3Jm+uj7/k/ZQ4bxNKfOAgZN+cYb/xizuQaur1lXtbIZlK2LetY/N+UaZRSHo Jxl7Ha0li0gF00HI6PiCcNDtK5kR20jE/M2AAgIVojTX4DO7r6J4kS23K5xGL7D+mqKY 2tFCngnZoccn925YJywG0SnJd4KR27C3XMuu1PssTsGBjBWj4yexDKreywW3F7H/WQ2B GR/Q== X-Forwarded-Encrypted: i=1; AFNElJ99mbtRZ73YdSKxintamWDB9KLyhZRj4V95TppYq2M2Ya7jAwmvTMPd1YoUTsQuP6rwhSmGkC22H2FJvDw=@vger.kernel.org X-Gm-Message-State: AOJu0YzXAREdCq5u3nY2hpRJlK8XpGM1SxB9r8HnZuUfO7pNcEutypei G4vhPvZk15xP67Hfo+5KvYkcQtvrHUmWkFEpkpV0xUA66n3yGHFI1ztboO1yBA== X-Gm-Gg: Acq92OFK07YOk4A1fQ1OBm2P1Br/cP2hhJcQBIV05PeJ0cRs6ZhnH5wccWN5C6Rsd6y Jn1TR156aXro598Q3uk11OC5EWAocopKyuwgUY8P0NDC6AVCxnsxuIlPyytywsUX4eVg7qn1x2d lHF0q1ZHozOu5mWc5so4MdP727yPONbUrh+T5WuZ+cZFSvScKiibwrKQ/DzHNJZ1gsD5k4bPQCt GHS1ndTW9sn9mVlwNYSLfOQGCXEGtVijeXu92mylv9ot4Io2d++zy4YUJrVq2XlBAMEGcxNTzub EKzZhQ1dG/4f/aiGEH09lhLXJ9wvP9kSweGaAmFJtNXQaI8tjJW+MXzV/fhtmBqn7RrVKnMDdgq hWjPCSrI1kgDCaCQke7HbxMH7zMyQIHiuF4XW3ESH7lpyZcvbAkUucD7sT801aELwRHU673qw09 t/7JcNga1MqOa2QM4Q3eTlb/TlSuu5X1t7HpChbWH2M1/kEdLdxBbhyg== X-Received: by 2002:a05:6808:318f:b0:47b:d07b:ec9b with SMTP id 5614622812f47-485fb3a1033mr7732122b6e.24.1780341955751; Mon, 01 Jun 2026 12:25:55 -0700 (PDT) Received: from smtpclient.apple ([38.175.164.190]) by smtp.gmail.com with ESMTPSA id 5614622812f47-4863f0c9848sm374903b6e.14.2026.06.01.12.25.55 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Mon, 01 Jun 2026 12:25:55 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3776.700.51.11.7\)) Subject: Re: [PATCH 1/2] fuse: fix FOPEN_PARALLEL_DIRECT_WRITES being ignored for passthrough writes From: Russ Fellows In-Reply-To: Date: Mon, 1 Jun 2026 13:25:44 -0600 Cc: linux-fsdevel@vger.kernel.org, miklos@szeredi.hu, linux-kernel@vger.kernel.org, fuse-devel@lists.linux.dev Content-Transfer-Encoding: quoted-printable Message-Id: <02AD69BF-A91D-4798-A90D-7692D3C1ABD0@gmail.com> References: <20260529031918.7361-1-russ.fellows@gmail.com> <20260529031918.7361-2-russ.fellows@gmail.com> To: Amir Goldstein X-Mailer: Apple Mail (2.3776.700.51.11.7) Amir, I appreciate your feedback. I will review and revise my proposed = changes. =20 I will also remove the =E2=80=9Cfix=E2=80=9D tag and mark this as an = enhancement to FUSE parallel I/O. As an aside, I have tested the kernel changes quite a bit and have had = no crashes or corruption, and the write performance is 3x. But, I will = use your input to focus these changes more appropriately and eliminate = their unintended consequences. Regards, =E2=80=94Russ > On Jun 1, 2026, at 12:52=E2=80=AFPM, Amir Goldstein = wrote: >=20 > Removing stable list - this is definetly NOT a bug fix > Please CC fuse-devel@lists.linux.dev for future fuse patches >=20 >=20 > Not a fix, because this was very intentional. > It is a new feature that you are proposing to support parallel > passthrough dio. >=20 > Anyway, this patch has many problems >=20 >>=20 >=20 > You can't just use fuse_dio_lock() like this > it plays nasty games with the iomode. > It does not even check for O_DIRECT mode, so this would do > parallel buffered write (at least until it meets the filesystem lock > but its not something we would want. > You should study this code better. >=20 >> ret =3D backing_file_write_iter(backing_file, iter, iocb, = iocb->ki_flags, >> &ctx); >=20 > The problem is that while backing_file_write_iter() does not seem to > directly require an exclusive lock (apart from maybe = file_remove_privs) > the fuse_passthrough_end_write() callback does I think rely on this > exclusive lock. >=20 > So proving that this can work will require more research and more = effort > and I am not really sure how that is going to work out. >=20 > Thanks, > Amir.