From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp05-ext.udag.de (smtp05-ext.udag.de [62.146.106.75]) (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 1A46B37E30A; Thu, 22 Jan 2026 10:59:45 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=62.146.106.75 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1769079588; cv=none; b=BDXFx+pNNAmLp3Dkc8LsDuaZ04O4zi4NiutFiL5uXx/h+CDiJ8HUUZ2h14eTDeYByt8swWs53CdTtOnMh7QpHbrIKF+gF4Bxix85AzDvmu5jQoXY4cnOnSYwW/xNn4MFrrKOElRE4ynARyDdfLEcbLEsbKl5tMgW7qDCmbCXWA8= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1769079588; c=relaxed/simple; bh=GPjquwSndP4TiPFtTpww3OozhjBM6PcCrbQsXsv/WpQ=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=Owiltka/JSQbrARf8GgJIAqTj1pLBBzSMdPE/tmYY+8/M3HxfWH1Ok/GFLEf2lrIYSVFf1br++IUeS00XfRzOJp6VIRRtXbKqWa4d4rOVAYtuRJBFFIqCT1UWtfJVaNILfbeht2XNgFXgh6y4lzXP/iOGnEXvipSQ8PBk4ogl4g= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=birthelmer.de; spf=pass smtp.mailfrom=birthelmer.de; arc=none smtp.client-ip=62.146.106.75 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=birthelmer.de Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=birthelmer.de Received: from localhost (200-143-067-156.ip-addr.inexio.net [156.67.143.200]) by smtp05-ext.udag.de (Postfix) with ESMTPA id CFAD9E0A71; Thu, 22 Jan 2026 11:59:42 +0100 (CET) Authentication-Results: smtp05-ext.udag.de; auth=pass smtp.auth=birthelmercom-0001 smtp.mailfrom=horst@birthelmer.de Date: Thu, 22 Jan 2026 11:59:41 +0100 From: Horst Birthelmer To: Luis Henriques Cc: Bernd Schubert , Bernd Schubert , Amir Goldstein , Miklos Szeredi , "Darrick J. Wong" , Kevin Chen , Horst Birthelmer , "linux-fsdevel@vger.kernel.org" , "linux-kernel@vger.kernel.org" , Matt Harvey , "kernel-dev@igalia.com" Subject: Re: Re: [RFC PATCH v2 4/6] fuse: implementation of the FUSE_LOOKUP_HANDLE operation Message-ID: References: <03ea69f4-f77b-4fe7-9a7c-5c5ca900e4bf@bsbernd.com> <5d022dc0-8423-4af2-918f-81ad04d50678@ddn.com> <87pl726kko.fsf@wotan.olymp> <87ldhp7wbf.fsf@wotan.olymp> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <87ldhp7wbf.fsf@wotan.olymp> On Thu, Jan 22, 2026 at 10:53:24AM +0000, Luis Henriques wrote: > On Thu, Jan 22 2026, Horst Birthelmer wrote: ... > >> > >> So, to summarise: > >> > >> In the end, even FUSE servers that do support compound operations will > >> need to check the operations within a request, and act accordingly. There > >> will be new combinations that will not be possible to be handle by servers > >> in a generic way: they'll need to return -EOPNOTSUPP if the combination of > >> operations is unknown. libfuse may then be able to support the > >> serialisation of that specific operation compound. But that'll require > >> flagging the request as "serialisable". > > > > OK, so this boils down to libfuse trying a bit harder than it does at the moment. > > After it calls the compound handler it should check for EOPNOTSUP and the flag > > and then execute the single requests itself. > > > > At the moment the fuse server implementation itself has to do this. > > Actually the patched passthrough_hp does exactly that. > > > > I think I can live with that. > > Well, I was trying to suggest to have, at least for now, as little changes > to libfuse as possible. Something like this: > > if (req->se->op.compound) > req->se->op.compound(req, arg->count, arg->flags, in_payload); > else if (arg->flags & FUSE_COMPOUND_SERIALISABLE) > fuse_execute_compound_sequential(req); > else > fuse_reply_err(req, ENOSYS); > > Eventually, support for specific non-serialisable operations could be > added, but that would have to be done for each individual compound. > Obviously, the server itself could also try to serialise the individual > operations in the compound handle, and use the same helper. > Is there a specific reason why you want that change in lowlevel.c? The patched passthrouhg_hp does this implicitly, actually without the flag. It handles what it knows as 'atomic' compound and uses the helper for the rest. If you don't want to handle specific combinations, just check for them and return an error. > Cheers, > -- > Luís