From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from fhigh-a5-smtp.messagingengine.com (fhigh-a5-smtp.messagingengine.com [103.168.172.156]) (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 CFDE01632E7; Wed, 11 Feb 2026 20:36:18 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=103.168.172.156 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1770842180; cv=none; b=OcdtUx2fQXa9qRpMC3sBlRROb44fLdj+zdms+RLLGl5m/ENOgUTQSD6JjeMZ0OE9qepIHX4urvNdcYAbi9vJXOhEzQXwxP2kMw7Gbh0rIX8Q6gpDHOc7CpMRvB6n+zIlJ/IeWqxd6iYZtCikNyVFx+lG9N5KhdxYTAAUuseIm5A= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1770842180; c=relaxed/simple; bh=JfKExKGAXbOz0IGnae61GWNu6MMiefXI457BJdV8hnY=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=W0WPEHCqoMR8S+38wvjWljujbb9mzH9VE/gamxGkxT5Rlc+nK15017ilE8+oG/FPnn8y3upcztbdiDwYJs+5a4E8yq1zImMC6w9q/Atlh1HTMj6FQkogB7xDFVHVwLPb3Qc6gl99pu5n2QkqYFsnP/XpGXk4RGlyoFhiHMwHWC4= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=bsbernd.com; spf=pass smtp.mailfrom=bsbernd.com; dkim=pass (2048-bit key) header.d=bsbernd.com header.i=@bsbernd.com header.b=KsN1TXQf; dkim=pass (2048-bit key) header.d=messagingengine.com header.i=@messagingengine.com header.b=Hfr3u1H0; arc=none smtp.client-ip=103.168.172.156 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=bsbernd.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=bsbernd.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=bsbernd.com header.i=@bsbernd.com header.b="KsN1TXQf"; dkim=pass (2048-bit key) header.d=messagingengine.com header.i=@messagingengine.com header.b="Hfr3u1H0" Received: from phl-compute-07.internal (phl-compute-07.internal [10.202.2.47]) by mailfhigh.phl.internal (Postfix) with ESMTP id E614A1400076; Wed, 11 Feb 2026 15:36:17 -0500 (EST) Received: from phl-frontend-04 ([10.202.2.163]) by phl-compute-07.internal (MEProxy); Wed, 11 Feb 2026 15:36:17 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsbernd.com; h= cc:cc:content-transfer-encoding:content-type:content-type:date :date:from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:subject:subject:to:to; s=fm2; t=1770842177; x=1770928577; bh=abtgy9OHuvjbDvR8RcsKvJLwI4WkSm7DPZQSxZMN0pU=; b= KsN1TXQfEQkstszEebHwRBFoabohirbly08FO9WDQ+8soEMe8MnT4Se39aDquj88 TIYQr0+kE/U0dS/Fq7QknyalHGC0TGybXeDOS0cf+FEQpZxesioXEolw7zD0XMJH 6iE5/CtuuLHprbDSSHiKSAlMLcVhJRAhphhrhFTIBotoyN4OGMwBzCnuwBp5MVXB mjclG4Zdz5SLHtKU3O0YaumOGHkGPmUgADewxEdAMDYAI6dGY1FRhg+HJ0sOsnIm bxkNnUxjT8eMt0DglkuoBCdiRIHI8/BhqjwNyYv1nDnscvk9I5QHA1H+zEmY2cXJ w+VY1YBMqx+VxOFKUuuNyA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-transfer-encoding :content-type:content-type:date:date:feedback-id:feedback-id :from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:subject:subject:to:to:x-me-proxy :x-me-sender:x-me-sender:x-sasl-enc; s=fm3; t=1770842177; x= 1770928577; bh=abtgy9OHuvjbDvR8RcsKvJLwI4WkSm7DPZQSxZMN0pU=; b=H fr3u1H0zJqKQighkNmemrVFT0oKP0X4pgscWOvzIJZDctxjYInZuIY3kTSO+jOQ6 KmxX8YJ7S5GsLVeCsIVqoi7m7STK9SRZ7Qw3Ivrdia3hTBkCc9i4T6jjrUfMgcDE pYMyEpIhcmitQwMG8Fg7QNF12j82a4hk7RXczAp4ZiZjIJxLb61Satfh3nL6Xurn jQmTiQHNGRl/oGaAW5B7t4Q4axvlFyE/eOu1HUxKKQlNv0cIQfVTrO181vdvzpFH V0ePkb1XwDfsF0mEhtglwo6ueEY7Kw/WxxIBS1pVJ+aliaDgF6g2S9JgNh+76Re4 kmonh8nhlVW7bpoDatFRg== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeefgedrtddtgddvtdefheefucetufdoteggodetrf dotffvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfurfetoffkrfgpnffqhgenuceu rghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmnecujf gurhepkfffgggfuffvvehfhfgjtgfgsehtjeertddtvdejnecuhfhrohhmpeeuvghrnhgu ucfutghhuhgsvghrthcuoegsvghrnhgusegsshgsvghrnhgurdgtohhmqeenucggtffrrg htthgvrhhnpeehhfejueejleehtdehteefvdfgtdelffeuudejhfehgedufedvhfehueev udeugeenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpe gsvghrnhgusegsshgsvghrnhgurdgtohhmpdhnsggprhgtphhtthhopeekpdhmohguvgep shhmthhpohhuthdprhgtphhtthhopehmihhklhhoshesshiivghrvgguihdrhhhupdhrtg hpthhtohephhhorhhsthessghirhhthhgvlhhmvghrrdgtohhmpdhrtghpthhtohepsghs tghhuhgsvghrthesuggunhdrtghomhdprhgtphhtthhopehjohgrnhhnvghlkhhoohhngh esghhmrghilhdrtghomhdprhgtphhtthhopehluhhishesihhgrghlihgrrdgtohhmpdhr tghpthhtoheplhhinhhugidqkhgvrhhnvghlsehvghgvrhdrkhgvrhhnvghlrdhorhhgpd hrtghpthhtoheplhhinhhugidqfhhsuggvvhgvlhesvhhgvghrrdhkvghrnhgvlhdrohhr ghdprhgtphhtthhopehhsghirhhthhgvlhhmvghrseguughnrdgtohhm X-ME-Proxy: Feedback-ID: i5c2e48a5:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Wed, 11 Feb 2026 15:36:16 -0500 (EST) Message-ID: Date: Wed, 11 Feb 2026 21:36:14 +0100 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v5 1/3] fuse: add compound command to combine multiple requests To: Miklos Szeredi , Horst Birthelmer Cc: Bernd Schubert , Joanne Koong , Luis Henriques , linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org, Horst Birthelmer References: <20260210-fuse-compounds-upstream-v5-0-ea0585f62daa@ddn.com> <20260210-fuse-compounds-upstream-v5-1-ea0585f62daa@ddn.com> From: Bernd Schubert Content-Language: en-US, de-DE, fr In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 2/11/26 17:13, Miklos Szeredi wrote: > On Tue, 10 Feb 2026 at 09:46, Horst Birthelmer wrote: > >> +static char *fuse_compound_build_one_op(struct fuse_conn *fc, >> + struct fuse_args *op_args, >> + char *buffer_pos) >> +{ >> + struct fuse_in_header *hdr; >> + size_t needed_size = sizeof(struct fuse_in_header); >> + int j; >> + >> + for (j = 0; j < op_args->in_numargs; j++) >> + needed_size += op_args->in_args[j].size; >> + >> + hdr = (struct fuse_in_header *)buffer_pos; >> + memset(hdr, 0, sizeof(*hdr)); >> + hdr->len = needed_size; >> + hdr->opcode = op_args->opcode; >> + hdr->nodeid = op_args->nodeid; > > hdr->unique is notably missing. > > I don't know. Maybe just fill it with the index? > >> + hdr->uid = from_kuid(fc->user_ns, current_fsuid()); >> + hdr->gid = from_kgid(fc->user_ns, current_fsgid()); > > uid/gid are not needed except for creation ops, and those need idmap > to calculate the correct values. I don't think we want to keep legacy > behavior of always setting these. > >> + hdr->pid = pid_nr_ns(task_pid(current), fc->pid_ns); > > This will be the same as the value in the compound header, so it's > redundant. That might not be bad, but I feel that we're better off > setting this to zero and letting the userspace server fetch the pid > value from the compound header if that's needed. > >> +#define FUSE_MAX_COMPOUND_OPS 16 /* Maximum operations per compound */ > > Don't see a good reason to declare this in the API. More sensible > would be to negotiate a max_request_size during INIT. > >> + >> +#define FUSE_COMPOUND_SEPARABLE (1<<0) >> +#define FUSE_COMPOUND_ATOMIC (1<<1) > > What is the meaning of these flags? > >> + >> +/* >> + * Compound request header >> + * >> + * This header is followed by the fuse requests >> + */ >> +struct fuse_compound_in { >> + uint32_t count; /* Number of operations */ > > This is redundant, as the sum of the sub-request lengths is equal to > the compound request length, hence calculating the number of ops is > trivial. > >> + uint32_t flags; /* Compound flags */ >> + >> + /* Total size of all results. >> + * This is needed for preallocating the whole result for all >> + * commands in this compound. >> + */ >> + uint32_t result_size; > > I don't understand why this is needed. Preallocation by the userspace > server? Why is this different from a simple request? With simple request and a single request per buffer, one can re-use the existing buffer for the reply in fuse-server - write: Do the write operation, then store the result into the io-buffer - read: Copy the relatively small header, store the result into the io-buffer - Meta-operations: Same as read Compound: - iterate over each compound, store the result into a temporary buffer - After completion, copy the temporary buffer back into the compound Which then results in the choice of - Make the temporary buffer as large as the IO buffer - Reallocate for each compound, or something like 2x 1st buffer - Allocate the exact size of what kernel nows the reply is supposed to be on success In this specific case I had especially asked to store the result size into the compound to simplify code in libfuse. Question, this is a just a uint32_t, does it hurt to leave it? Maybe with the additional comment like "Optimization, not strictly needed, but might simplify fuse-server". Thanks, Bernd