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 E8FDDC433F5 for ; Wed, 11 May 2022 10:09:08 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S239972AbiEKKJD (ORCPT ); Wed, 11 May 2022 06:09:03 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:49174 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229877AbiEKKI5 (ORCPT ); Wed, 11 May 2022 06:08:57 -0400 Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id B7FDD7A828; Wed, 11 May 2022 03:08:55 -0700 (PDT) Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by mailout.nyi.internal (Postfix) with ESMTP id 299615C01BF; Wed, 11 May 2022 06:08:55 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute5.internal (MEProxy); Wed, 11 May 2022 06:08:55 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fastmail.fm; h= cc:cc:content-transfer-encoding:content-type:date:date:from:from :in-reply-to:in-reply-to:message-id:mime-version:references :reply-to:sender:subject:subject:to:to; s=fm1; t=1652263735; x= 1652350135; bh=/JrNB2Fx41iDaNUHQ1Mupt47psUq7cPRK1CxJ1DI5H8=; b=U iPyQU1umS2dHaDmIxM9V+ihgsBbZvm5ytXkgUqxRqTufJ147iBMcLm780ZYmdRW+ ea3/H/NSyIYFUnnqTcg4aREbTo6yDcMWD+9zhpBV0Qgz7/yDTCsOwO7wi8d8UDTU PVyc45yYFSEVz0CTKI2dd/JLHqsY8+JoMXTrySFBkDu5sQn2JJDYvbxRyyVEeuZI Z/VFGC/zXL3tDV8LO7ngioWrer7y+oXETypQs013Syh9tUFsN8FmZjgEnNIFIFqN yCLH49d1e/vjdSM0ERoAqFJx7wLnVPGxGjLK1UszSleLWPhPGQunRffrrsIBPZAA PKxS0QuRfzNYxU1ve41DA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-transfer-encoding :content-type:date:date:from:from:in-reply-to:in-reply-to :message-id:mime-version:references:reply-to:sender:subject :subject:to:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm1; t=1652263735; x=1652350135; bh=/JrNB2Fx41iDa NUHQ1Mupt47psUq7cPRK1CxJ1DI5H8=; b=oroW1ukq0czGLRH4pqXhuDnfREq2t L4kkxKkx2YMj8QbPj+rYrTcWm5lL+yulCUZ9b71M9Zd9fVDS04djzHSwXFEeEhJ9 /pbuoEHsj/7qLAEGBtgNqeORCiWFbzCwJ2K37cC1jdVNvI8nrEq78WRS81+oucMv s9OXIweiOk4nDNRvv4rPiJDI+jKMQUfS/gv/1C6kNCTo4wubXmmh8S0smDim2DoU 5n0kP8SYkZnjxVLaca7GxXrhVXloVUyTMIZqdXeMiMk72SxDsPWjTXsb1t+vnuWb XlFj3KongPnx74x7NSplfXVsMxh8/Bl+LDiSQdruPA91ONOmKVXyzSlww== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvfedrgeehgddvfecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpefkffggfgfuvfevfhfhjggtgfesthekredttdefjeenucfhrhhomhepuegvrhhn ugcuufgthhhusggvrhhtuceosggvrhhnugdrshgthhhusggvrhhtsehfrghsthhmrghilh drfhhmqeenucggtffrrghtthgvrhhnpefgheevteeuveelkedtudekffefvdehueevffej iedvjeelhedvtdevudekjeehjeenucffohhmrghinhepghhithhhuhgsrdgtohhmnecuve hluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepsggvrhhnugdr shgthhhusggvrhhtsehfrghsthhmrghilhdrfhhm X-ME-Proxy: Received: by mail.messagingengine.com (Postfix) with ESMTPA; Wed, 11 May 2022 06:08:54 -0400 (EDT) Message-ID: Date: Wed, 11 May 2022 12:08:53 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.8.1 Subject: Re: [PATCH v4 1/3] FUSE: Implement atomic lookup + create Content-Language: en-US To: =?UTF-8?Q?Jean-Pierre_Andr=c3=a9?= , linux-fsdevel@vger.kernel.org, Vivek Goyal , Miklos Szeredi Cc: fuse-devel@lists.sourceforge.net, linux-kernel@vger.kernel.org References: <20220502102521.22875-1-dharamhans87@gmail.com> <20220502102521.22875-2-dharamhans87@gmail.com> <78c2beed-b221-71b4-019f-b82522d98f1e@ddn.com> <90fbe06b-4af7-c9ce-4aca-393aed709722@ddn.com> From: Bernd Schubert In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 5/7/22 12:42, Jean-Pierre André wrote: > Bernd Schubert wrote on 5/6/22 8:45 PM: >> >> >> On 5/6/22 19:07, Vivek Goyal wrote: >>> I looked at fuse_lowlevel API and passthrough_ll.c and there is no >>> assumption whether FUSE_LOOKUP has already been called by client >>> before calling FUSE_CREATE. Similarly, I looked at virtiofs code >>> and I can't see any such assumption there as well. >> >> The current linux kernel code does this right now, skipping the lookup >> just changes behavior.  Personally I would see it as bug if the >> userspace implementation does not handle EEXIST for FUSE_CREATE. >> Implementation developer and especially users might see it differently >> if a kernel update breaks/changes things out of the sudden. >> passthrough_ll.c is not the issue here, it handles it correctly, but >> what about the XYZ other file systems out there - do you want to check >> them one by one, including closed source ones? And wouldn't even a >> single broken application count as regression? >> >>> >>> https://github.com/qemu/qemu/blob/master/tools/virtiofsd/passthrough_ll.c >>> >>> >>> So I am sort of lost. May be you can help me understsand this. >> >> I guess it would be more interesting to look at different file systems >> that are not overlay based. Like ntfs-3g - I have not looked at the >> code yet, but especially disk based file system didn't have a reason >> so far to handle EEXIST. And > > AFAIK ntfs-3g proper does not keep a context across calls and does > not know what LOOKUP was preparing a CREATE. However this may have > consequences in the high level of libfuse for managing the file tree. I don't think high level is effected. I'm really just scared to break > > The kernel apparently issues a LOOKUP to decide whether issuing a > CREATE (create+open) or an OPEN. If it sent blindly a CREATE, > ntfs-3g would return EEXIST if the name was already present in > the directory. Ok, so ntfs-3g is ok - which leaves N-1 file systems to check... > > For a test, can you suggest a way to force ignore of such lookup > within libfuse, without applying your kernel patches ? Is there a > way to detect the purpose of a lookup ? (A possible way is to > hardcode a directory inode within which the lookups return ENOENT). What I mean is that we need to check the code or test N file systems - if ntfs-3g handles it, N-1 are left... I we all agree on that there is no issue in skipping the lookup - fine with me - it slightly simplifies the patches. Thanks, Bernd