On Wed, Aug 21, 2002 at 07:29:04PM -0700, Andrew Morton wrote:
>
> I've uploaded a rollup of pending fixes and feature work
> against 2.5.31 to
>
> http://www.zip.com.au/~akpm/linux/patches/2.5/2.5.31/2.5.31-mm1/
>
> The rolled up patch there is suitable for ongoing testing and
> development. The individual patches are in the broken-out/
> directory and should all be documented.
Sorry, but we still have the page release race in multiple places.
Look at the following (page starts with page_count == 1):
Processor 1 Processor 2
refill_inactive: lines 378-395
as page count == 1 we'll
continue with line 401
__pagevec_release: line 138
calls release_pages
release_pages: line 100-111
put_page_test_zero brings the
page count to 0 and we'll continue
at line 114. Note that this may
happen while another processor holds
the lru lock, i.e. there is no
point in checking for page count == 0
with the lru lock held because
the lru lock doesn't protect against
decrements of page count after
the check.
line 401: page_cache_get
resurrects the page, page
count is now 1.
lines 402-448.
line 448 calls __pagevec_release
__pagevec_release: line 138
calls release_pages
release_pages: lines 100-111
put_page_test_zero brings the
page count back to 0 (!!!)
i.e. we continue at line 114:
lines 114-123.
The page count == 0 check in line
123 is successful and the page
is returned to the buddy allocator
lines 114-123.
The page count == 0 check in line
123 is successful, i.e. the page
is returned to the buddy allocator
a second time. ===> BOOM
Neither the lru lock nor any of the page count == 0 checks can
prevent this from happening.
regards Christian
-- THAT'S ALL FOLKS! - 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/
This archive was generated by hypermail 2b29 : Fri Aug 23 2002 - 22:00:24 EST