From mboxrd@z Thu Jan 1 00:00:00 1970 From: Lino Sanfilippo Subject: Re: [PATCH] fs, fanotify: dont send notification event for coredump file Date: Tue, 27 Mar 2012 00:27:00 +0200 Message-ID: <20120326222700.GB2805@Neptun> References: <20120325012813.GD3276@Neptun> <1332781423.384.1.camel@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Lino Sanfilippo , viro@ZenIV.linux.org.uk, linux-fsdevel@vger.kernel.org, vasily.novikov@kaspersky.com To: Eric Paris Return-path: Received: from mailout-de.gmx.net ([213.165.64.23]:59210 "HELO mailout-de.gmx.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with SMTP id S1750934Ab2CZW1F (ORCPT ); Mon, 26 Mar 2012 18:27:05 -0400 Content-Disposition: inline In-Reply-To: <1332781423.384.1.camel@localhost> Sender: linux-fsdevel-owner@vger.kernel.org List-ID: On Mon, Mar 26, 2012 at 01:03:43PM -0400, Eric Paris wrote: > How does this work with something like abrt, which causes core files to > be created in a known dir. It then watches (I have no idea if it uses > *notify) for new core files and processes them when they appear. Would > we be able to get any notification of core files with this patch? Maybe > we need a way to just not allow ourselves to block on core files? No we would not get notifications for core files with this patch any more. I see that this is a drawback for applications that want to track those files. But unfortunately I dont see how we could tell if a core file is created by a fanotify listener or not. The easiest thing would probably be if we had two flags, one to suppress "pure notification" events and one to suppress permission event. For example if we had: FMODE_NONOTIFY: suppress pure notification events FMODE_NOPERMNOTIFY: suppress permission events we would only use FMODE_NOPERMNOTIFY for core files then.