Re99: how to flush out cache.?

[Julian Elischer]

with this bug could a user zero out /etc/group or similar?
I am not sure what the ramification of the bug is..


On Fri, 23 Apr 2004, Stephan Uphoff wrote:

> 
> Matthew Dillon wrote:
>  
> >    The idea with the fix is as follows:
> > 
> >    * It's hard to make the VM system invalidate buffers, so don't try.
> >
> 	
> But it is easy to throw away clean buffers since they are nicely sorted
> and easy to release.
> Efficient locking is a bit tricky but should not be to bad. 
> 
> >
> >      Instead, make UFS recognize the IO_INVAL ioflag and mark the buffer
> >      appropriately in the putpages -> generic put pages -> VOP_WRITE() path.
> 
> This is a nice optimization - so we don't have to delete the buffer
> once it is clean.
> 
> > 
> >      This only occurs if the msync'd map was writable.  If the msync'd map was
> >      only readable, then the data is not flushed through the vnode system and
> >      the pages will not be removed if there happens to be a buffer associated
> >      with them, even if the buffer is clean.
> 
> I would advise to also flush read only mapped data. (like 5.x)
> On writeable maps clean pages will also not be removed if a buffer is
> associated with them. 
> ( For example the sequence  msync(a,l,MS_SYNC); msync(a,l,MS_INVALIDATE|MS_SYNC
> )
>   will not invalidate/destroy the buffers)
> 
> > 
> >      I think this is reasonable.  Not perfect, but reasonable.
> > 
> >    * Set clean_only to TRUE when calling vm_object_page_remove(), which
> >      causes vm_object_page_remove() to ignore wired or dirty pages.  This
> >      code is called for both readable and writable maps so we can't just 
> >      remove the page unconditionallty, hence clean_only should be
> >      set to TRUE.
> 
> Yes - see earlier email. 
> 
> > 
> >      This means that any pages associated with the buffer cache will NOT
> >      be removed if the map was read-only.  If the map was writable, then
> >      the IO_INVAL fix above will destroy the buffer and the page should
> >      wind up not being wired any more, and thus will be properly removed.
> > 
> >     That's it!
> > 
> > 						-Matt 
> 
> The patch solves the data loss problem.
> This is the really critical part.
> 
> When I get the time (probably not next week) I will write a patch
> to release the cached buffers that would prevent page removal.
> 
> 
> 	Stephan
> 
>