[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <200808062110.58764.nickpiggin@yahoo.com.au>
Date: Wed, 6 Aug 2008 21:10:58 +1000
From: Nick Piggin <nickpiggin@...oo.com.au>
To: tvrtko.ursulin@...hos.com
Cc: Eric Paris <eparis@...hat.com>, linux-kernel@...r.kernel.org,
malware-list@...ts.printk.net
Subject: Re: [malware-list] [RFC 0/5] [TALPA] Intro to a linux interface for on access scanning
On Wednesday 06 August 2008 19:44, tvrtko.ursulin@...hos.com wrote:
> Nick Piggin wrote on 05/08/2008 19:08:05:
> > On Tuesday 05 August 2008 07:00, Eric Paris wrote:
> > > 5. Define which filesystems are cacheable and which are not
> >
> > This is practically impossible to do completely without rewriting a lot
> > of code (which will never be accepted). I don't see why it is needed
>
> though
>
> > as the filesystem cache is supposed to be kept coherent with disk.
>
> Problem is with network filesystems. So could it be a flag somewhere per
> filesystem which would say something like "this filesystem guarantees
> content of a file cannot change without get_write_access or
> file_update_time being called locally"? That doesn't sound like a lot of
> code so what am I missing?
Maybe... but that's not the same as what requirement 5 calls for.
But depending on exactly what semantics you really call for, it can get
tricky to account for all of pagecache. Writes can happen through page
tables or get_user_pages. True that a process has to at some point have
write permission to the file, but the cache itself could be modified
even after the file is closed and all mmaps disappear.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists