> On Tue, 22 Jan 2008 05:01:14 +0100 Nick Piggin <[EMAIL PROTECTED]> wrote: > > After running SetPageUptodate, preceeding stores to the page contents to > actually bring it uptodate may not be ordered with the store to set the page > uptodate. > > Therefore, another CPU which checks PageUptodate is true, then reads the > page contents can get stale data. > > Fix this by having an smp_wmb before SetPageUptodate, and smp_rmb after > PageUptodate. > > Many places that test PageUptodate, do so with the page locked, and this > would be enough to ensure memory ordering in those places if SetPageUptodate > were only called while the page is locked. Unfortunately that is not always > the case for some filesystems, but it could be an idea for the future. > > Also bring the handling of anonymous page uptodateness in line with that of > file backed page management, by marking anon pages as uptodate when they _are_ > uptodate, rather than when our implementation requires that they be marked as > such. Doing allows us to get rid of the smp_wmb's in the page copying > functions, which were especially added for anonymous pages for an analogous > memory ordering problem. Both file and anonymous pages are handled with the > same barriers. >
So... it's two patches in one. What kernel is this against? Looks like mainline. Is it complete and correct when applied against the large number of pending MM changes? -- 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/
