From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:53082) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZvvrY-0000Wv-EY for qemu-devel@nongnu.org; Mon, 09 Nov 2015 18:28:37 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZvvrU-0006ue-Dw for qemu-devel@nongnu.org; Mon, 09 Nov 2015 18:28:36 -0500 Received: from mx1.redhat.com ([209.132.183.28]:34502) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZvvrU-0006uI-7t for qemu-devel@nongnu.org; Mon, 09 Nov 2015 18:28:32 -0500 Received: from int-mx10.intmail.prod.int.phx2.redhat.com (int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23]) by mx1.redhat.com (Postfix) with ESMTPS id 047D946264 for ; Mon, 9 Nov 2015 23:28:30 +0000 (UTC) From: Bandan Das References: <1446595225-23608-1-git-send-email-bsd@redhat.com> <1446595225-23608-3-git-send-email-bsd@redhat.com> <1446713343.30393.16.camel@redhat.com> Date: Mon, 09 Nov 2015 18:28:29 -0500 In-Reply-To: (Bandan Das's message of "Mon, 09 Nov 2015 18:12:45 -0500") Message-ID: MIME-Version: 1.0 Content-Type: text/plain Subject: Re: [Qemu-devel] [PATCH 2/3] usb-mtp: Add support for inotify based file monitoring List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Gerd Hoffmann Cc: qemu-devel@nongnu.org Bandan Das writes: > Gerd Hoffmann writes: > >> On Di, 2015-11-03 at 19:00 -0500, Bandan Das wrote: >>> + /* Add a new watch asap so as to not lose events >>> */ >> >> This comment sounds like there is a race ("asap"). There isn't one, >> correct ordering (adding the watch before reading the directory) is > > Hmm, seems like there's still a small window. We may not have even > started processing the event because we are still processing the earlier > ones. > >> enough to make sure you don't miss anything. You might see create >> events for objects already in the tree though, are you prepared to >> handle that? > > Oh, interesting. Current version will happily add duplicate entries. > I will add a check. By the way, did you mean this as a duplicate create event ? I took a quick look at fs/notify/inotify_fsnotify.c: int inotify_handle_event(... ret = fsnotify_add_event(group, fsn_event, inotify_merge); if (ret) { /* Our event wasn't used in the end. Free it. */ fsnotify_destroy_event(group, fsn_event); } So, atleast for consecutive duplicate events, the kernel seems to be doing some filtering of its own. >> cheers, >> Gerd