Re: [PATCH] cramfs corruption after BLKFLSBUF on loop device

[Andrew Morton <akpm@osdl.org>]

Olaf Hering <olh@suse.de> wrote:
>
>  On Thu, Jun 01, Andrew Morton wrote:
> 
> > Olaf Hering <olh@suse.de> wrote:
> > >
> > > 
> > >  
> > > +/* return a page in PageUptodate state, BLKFLSBUF may have flushed the page */
> > > +static struct page *cramfs_read_cache_page(struct address_space *m, unsigned int n)
> > > +{
> > > +	struct page *page;
> > > +	int readagain = 5;
> > > +retry:
> > > +	page = read_cache_page(m, n, (filler_t *)m->a_ops->readpage, NULL);
> > > +	if (IS_ERR(page))
> > > +		return NULL;
> > > +	lock_page(page);
> > > +	if (PageUptodate(page))
> > > +		return page;
> > > +	unlock_page(page);
> > > +	page_cache_release(page);
> > > +	if (readagain--)
> > > +		goto retry;
> > > +	return NULL;
> > > +}
> > 
> > Better, but it's still awful, isn't it?  The things you were discussing
> > with Chris look more promising.  PG_Dirty would be a bit of a hack, but at
> > least it'd be a 100% reliable hack, whereas the above is a
> > whatever-the-previous-failure-rate-was-to-the-fifth hack.
> 
> Do you want it like that?
> 
> lock_page(page);
> if (PageUptodate(page)) {
>         SetPageDirty(page);
>         mb();
>         return page;
> }

Not really ;)  It's hacky.  It'd be better to take a lock.

I expect it'd work though, as long as...

> and perhaps a ClearPageDirty() after memcpy.

I assume this is a read-only filesystem?  I mean, if someone had really
tried to dirty the page in the meanwhile via, say, munmap or msync which
don't lock the page, we just lost their data.