Messages in this thread | | | Date | Thu, 1 Jun 2006 14:57:47 -0700 | From | Andrew Morton <> | Subject | Re: [PATCH] cramfs corruption after BLKFLSBUF on loop device |
| |
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.
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |