From mboxrd@z Thu Jan 1 00:00:00 1970 From: Vasily Novikov Subject: Re: [malware-list] A few concerns about fanotify implementation. Date: Mon, 6 Jun 2011 13:19:02 +0400 Message-ID: <4DEC9B86.6060506@kaspersky.com> References: <1288095195.29745.4010.camel@novikov-v> <201010261358.46974.tvrtko.ursulin@sophos.com> <1288169699.7715.103.camel@novikov-v> <1288195134.2655.202.camel@localhost.localdomain> <4DE8ACAD.2080003@kaspersky.com> Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 7bit Cc: Eric Paris , "linux-fsdevel@vger.kernel.org" , "malware-list@dmesg.printk.net" To: Douglas Leeder Return-path: Received: from relay3.kaspersky-labs.com ([91.103.66.246]:57101 "EHLO relay3.kaspersky-labs.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752358Ab1FFJRU (ORCPT ); Mon, 6 Jun 2011 05:17:20 -0400 Received: from relay3.kaspersky-labs.com (localhost [127.0.0.1]) by mx3.kaspersky-labs.com (Postfix) with ESMTP id 97288402160E for ; Mon, 6 Jun 2011 13:17:17 +0400 (MSD) Received: from kas30pipe.localhost (localhost [127.0.0.1]) by mx3.kaspersky-labs.com (Postfix) with ESMTP id 34100402168D for ; Mon, 6 Jun 2011 13:17:17 +0400 (MSD) In-Reply-To: Sender: linux-fsdevel-owner@vger.kernel.org List-ID: >> 1. The file is thrown out of the cache only when it is modified. But in >> case there are different scan options for different dirs that's not >> enough. So we also need it to be evicted from cache on rename or number >> of hard links change. > > This is interesting, as it makes the cache less efficient for those > users who don't have different scanning within a filesystem. > > Our only equivalent things are exclusions, which we handle by not > marking the responses for exclusions as cache-able. > I suppose rename or make hard link is less frequent operation then modify so I believe it won't add a significant overhead. >> 2. We can't use unlimited cache because it can potentially grab too much >> memory and slow down a system. In case we use limited cache it can be >> easily filled with not very frequently used files. So the only option we >> have at the moment is to clear cache every time it is full. >> The solution we consider the most appropriate is to introduce >> replaceable marks and LRU cache for them in fanotify. >> So we suggest to introduce a new flag FAN_MARK_REPLACEABLE for marks. > > IIRC the cache is stored in the inodes themselves, so will automatically > be culled as inodes are pushed out of memory? If I understood the code correctly there is no cache by itself. It's just implemented through marks and it's ignored_mask field. So there is a list of marks for each inode that is empty initially. But when you add mark to this list you allocate fsnotify_mark structure which is about 64 bytes. -- Best regards, Vasily Novikov | Software developer | Kaspersky Lab Direct: +7 495 123 45 67 x2344 | Mobile: +7 964 786 44 82 | vasily.novikov@kaspersky.com 10/1, 1st Volokolamsky Proezd, Moscow, 123060, Russia | www.kaspersky.com, www.securelist.com