On Sun, Feb 25, 2007 at 04:06:57AM -0800, Andrew Morton wrote:
>
> What an unpleasing patchset. I really really hope we really have a bug in
> there, and that all this crap isn't pointless uglification.
It's the same bug for file pages as we had for anonymous pages, which
the POWER guys actually hit. Do you disagree? I like this patch much
better than the smp_wmb that we currently do just for anon pages.
> We _do_ need a flush_dcaceh_page() in all cases which you're concerned
> about. Perhaps we should stick the appropriate barriers in there.
I think the memorder problem is conceptually a page data vs PG_uptodate
one, because the read-side assumes that the data will be initialised before
PG_uptodate is set.
After the page is uptodate, you don't need subsequent barriers (that you
would get via flush_dcache_page), because we've never really tried to
impose any synchronisation on parallel read vs write.
A memory barrier in flush_dcache_page would do the trick as well, I think,
but it is not really any better. It is misleading because it is not the
canonical fix. And we'd still need the smp_rmb in the PageUptodate read-side.
> > On Thu, 15 Feb 2007 08:31:31 +0100 (CET) Nick Piggin <[email protected]> wrote:
> > +static inline void SetNewPageUptodate(struct page *page)
> > +{
> > + /*
> > + * S390 sets page dirty bit on IO operations, which is why it is
> > + * cleared in SetPageUptodate. This is not an issue for newly
> > + * allocated pages that are brought uptodate by zeroing memory.
> > + */
> > + smp_wmb();
> > + __set_bit(PG_uptodate, &(page)->flags);
> > +}
>
> __SetPageUptodate() might be more conventional.
I guess so. I guess that the __ variants *can* only be used on new pages
anyway. I wanted to make it clear that it wasn't a non-atomic version of
exactly the same operation, but __SetPageUptodate probably would be fine.
> Boy we'd better get the callers of this little handgrenade right.
Newly initialised pages, before they become visible to anyone else. We
could put a BUG_ON(page_count(page) != 1); in there?
-
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]
