Olaf Hering <[email protected]> wrote:
>
> On Thu, Jun 01, Andrew Morton wrote:
>
> > Olaf Hering <[email protected]> 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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
