linux-kernel - Re: [patch] mm: fix PageUptodate data race

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <20080126220356.0b77f0e9.akpm@linux-foundation.org>
Date:	Sat, 26 Jan 2008 22:03:56 -0800
From:	Andrew Morton <akpm@...ux-foundation.org>
To:	Nick Piggin <npiggin@...e.de>
Cc:	hugh@...itas.com, linux-mm@...ck.org, linux-kernel@...r.kernel.org
Subject: Re: [patch] mm: fix PageUptodate data race

> On Tue, 22 Jan 2008 05:01:14 +0100 Nick Piggin <npiggin@...e.de> 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 majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/