Re: [malware-list] A few concerns about fanotify implementation.

[Vasily Novikov <vasily.novikov@kaspersky.com>]

>> 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