Received: by 2002:a05:6a10:5bc5:0:0:0:0 with SMTP id os5csp893565pxb; Wed, 27 Oct 2021 14:37:17 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxwKVgLhrQAPghETEIyqqAV+YMlqpFggltdA3m0V7SKEsBQDMKZeZ7ZczEBRkFq4RTdAyfh X-Received: by 2002:a17:906:5a62:: with SMTP id my34mr156491ejc.348.1635370637691; Wed, 27 Oct 2021 14:37:17 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1635370637; cv=none; d=google.com; s=arc-20160816; b=uGKzz35mTaNrGT9Agxdf1bWyhtdFTWwVyZbGVba5d+8iJBIl+kp0UO1Pq4drTaXwIM gq939tuNEtNkLT//9q9+VgbNT1DohMGDVFP/cM2epO6KdehPo8qPg4WCQ2ZKQQisbfRZ f+7mksN8NJOvCnRp2co2lE+64sb0s7pSyXNIzFyuuAh2esWUQbOXaAyaa2rjvkQtL5N3 +pwZ7/S6WbxwqIavZiqicclkmd7oPeYsoywTJFYh08f3mUXeAQChKixIbf7MTGT3N8ff VNIthQkj9iymPj92bRleSOivvOwpfD9WVmlcrDBe2+taNOV6xXJ4QCpLdUp/fjGV6x4P JTyg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-disposition:mime-version :references:message-id:subject:cc:to:from:date:dkim-signature; bh=tT8K5skUofoEZB+AU06iDtzHu0LXGPvZK8XU9SATDwY=; b=N/r65hpiqaFP8nDylb6dHtTIAu/MfbpFjdAn0y3FkaXWg7dQx/H3nUpp9lGLHb1uMF Xq9xlvw3alJyPI3h6hBenT1WMBaIfIwszZiC8CmL+BhtysImGfpH9otWZ0gQmmZvn+bh f7oDXku87dJBr9jeC/14ljR4K+apYGHdVE9hIui1It9Y1fGfPUB5mEjHhJhf8K9RP+Ka zLdrD0BsGXZlDVC333y0M51214g1pb6O1QPTOseDcDAST5XwehYSZ4EWztlyqnbK7z2+ d2AXGTDGvC4wo/qBClobciNTqeIVdcsg+dSGKFOuRGkUbPxMZ4PUnQqnvhznfIlJoV1n 6fWg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=DbtEhJDS; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id d12si644742edn.490.2021.10.27.14.36.54; Wed, 27 Oct 2021 14:37:17 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=DbtEhJDS; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S240863AbhJ0UcQ (ORCPT + 97 others); Wed, 27 Oct 2021 16:32:16 -0400 Received: from us-smtp-delivery-124.mimecast.com ([170.10.129.124]:21491 "EHLO us-smtp-delivery-124.mimecast.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S240753AbhJ0UcP (ORCPT ); Wed, 27 Oct 2021 16:32:15 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1635366589; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=tT8K5skUofoEZB+AU06iDtzHu0LXGPvZK8XU9SATDwY=; b=DbtEhJDSRWiWKv6yZjBwrOBMwvqCdLEg15aLWCAFPaCAep+vTCelc/FXmVg7EjqLz7n/o0 iL+ryqMWIrkj6qkBjbYkq6206sX8wTSeiqgb/9W4o+UONgLvK+hcLfE8t/Wmjkn1QCF2ei WemjX9gBMPgCuMppCRxjn/fRDprLJF0= Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-101-4LF2kb85P5GHPYs-TmW3FQ-1; Wed, 27 Oct 2021 16:29:45 -0400 X-MC-Unique: 4LF2kb85P5GHPYs-TmW3FQ-1 Received: from smtp.corp.redhat.com (int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 5E6B4343D1; Wed, 27 Oct 2021 20:29:44 +0000 (UTC) Received: from horse.redhat.com (unknown [10.22.34.10]) by smtp.corp.redhat.com (Postfix) with ESMTP id 751A760BF1; Wed, 27 Oct 2021 20:29:41 +0000 (UTC) Received: by horse.redhat.com (Postfix, from userid 10451) id 0B062220562; Wed, 27 Oct 2021 16:29:41 -0400 (EDT) Date: Wed, 27 Oct 2021 16:29:40 -0400 From: Vivek Goyal To: Jan Kara Cc: Amir Goldstein , Ioannis Angelakopoulos , linux-fsdevel , virtio-fs-list , linux-kernel , Al Viro , Miklos Szeredi , Steve French Subject: Re: [RFC PATCH 0/7] Inotify support in FUSE and virtiofs Message-ID: References: <20211025204634.2517-1-iangelak@redhat.com> <20211027132319.GA7873@quack2.suse.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20211027132319.GA7873@quack2.suse.cz> X-Scanned-By: MIMEDefang 2.79 on 10.5.11.12 Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Oct 27, 2021 at 03:23:19PM +0200, Jan Kara wrote: > On Wed 27-10-21 08:59:15, Amir Goldstein wrote: > > On Tue, Oct 26, 2021 at 10:14 PM Ioannis Angelakopoulos > > wrote: > > > On Tue, Oct 26, 2021 at 2:27 PM Vivek Goyal wrote: > > > The problem here is that the OPEN event might still be travelling towards the guest in the > > > virtqueues and arrives after the guest has already deleted its local inode. > > > While the remote event (OPEN) received by the guest is valid, its fsnotify > > > subsystem will drop it since the local inode is not there. > > > > > > > I have a feeling that we are mixing issues related to shared server > > and remote fsnotify. > > I don't think Ioannis was speaking about shared server case here. I think > he says that in a simple FUSE remote notification setup we can loose OPEN > events (or basically any other) if the inode for which the event happens > gets deleted sufficiently early after the event being generated. That seems > indeed somewhat unexpected and could be confusing if it happens e.g. for > some directory operations. Hi Jan, Agreed. That's what Ioannis is trying to say. That some of the remote events can be lost if fuse/guest local inode is unlinked. I think problem exists both for shared and non-shared directory case. With local filesystems we have a control that we can first queue up the event in buffer before we remove local watches. With events travelling from a remote server, there is no such control/synchronization. It can very well happen that events got delayed in the communication path somewhere and local watches went away and now there is no way to deliver those events to the application. Thanks Vivek