If the free page and its buddy has different zone id, the current
zone->lock cann't prevent buddy page getting allocated, this could
trigger VM_BUG_ON_PAGE in a very tiny chance:
cpu 0: cpu 1:
hold zone_1 lock
check page and it buddy
PageBuddy(buddy) is true hold zone_2 lock
page_order(buddy) == order is true alloc buddy
trigger VM_BUG_ON_PAGE(page_count(buddy) != 0)
This patch fixes this issue by placing the zone id check before
the VM_BUG_ON_PAGE check.
Signed-off-by: Weijie Yang <[email protected]>
---
mm/page_alloc.c | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/mm/page_alloc.c b/mm/page_alloc.c
index 616a2c9..491d055 100644
--- a/mm/page_alloc.c
+++ b/mm/page_alloc.c
@@ -488,17 +488,15 @@ static inline int page_is_buddy(struct page *page, struct page *buddy,
return 0;
if (page_is_guard(buddy) && page_order(buddy) == order) {
- VM_BUG_ON_PAGE(page_count(buddy) != 0, buddy);
-
if (page_zone_id(page) != page_zone_id(buddy))
return 0;
+ VM_BUG_ON_PAGE(page_count(buddy) != 0, buddy);
+
return 1;
}
if (PageBuddy(buddy) && page_order(buddy) == order) {
- VM_BUG_ON_PAGE(page_count(buddy) != 0, buddy);
-
/*
* zone check is done late to avoid uselessly
* calculating zone/node ids for pages that could
@@ -507,6 +505,8 @@ static inline int page_is_buddy(struct page *page, struct page *buddy,
if (page_zone_id(page) != page_zone_id(buddy))
return 0;
+ VM_BUG_ON_PAGE(page_count(buddy) != 0, buddy);
+
return 1;
}
return 0;
--
1.7.10.4
On Tue, Dec 09, 2014 at 03:40:35PM +0800, Weijie Yang wrote:
> If the free page and its buddy has different zone id, the current
> zone->lock cann't prevent buddy page getting allocated, this could
> trigger VM_BUG_ON_PAGE in a very tiny chance:
>
Under what circumstances can a buddy page be allocated without the
zone->lock? Any parallel allocation from that zone that takes place will
be from the per-cpu allocator and should not be affected by this. Have
you actually hit this race?
--
Mel Gorman
SUSE Labs
On Tue, Dec 9, 2014 at 5:59 PM, Mel Gorman <[email protected]> wrote:
> On Tue, Dec 09, 2014 at 03:40:35PM +0800, Weijie Yang wrote:
>> If the free page and its buddy has different zone id, the current
>> zone->lock cann't prevent buddy page getting allocated, this could
>> trigger VM_BUG_ON_PAGE in a very tiny chance:
>>
>
> Under what circumstances can a buddy page be allocated without the
> zone->lock? Any parallel allocation from that zone that takes place will
> be from the per-cpu allocator and should not be affected by this. Have
> you actually hit this race?
My description maybe not clear, if the free page and its buddy is not
at the same zone, the holding zone->lock cann't prevent buddy page
getting allocated.
zone_1->lock prevents the freeing page getting allocated
zone_2->lock prevents the buddy page getting allocated
they are not the same zone->lock.
I found it when review the code, not a running test.
However, if we cann't remove the zone_id check statement, I think
we should handle this rare race.
If I miss something or make a mistake, please let me know.
Thanks
> --
> Mel Gorman
> SUSE Labs
On Wed, Dec 10, 2014 at 09:38:42PM +0800, Weijie Yang wrote:
> On Tue, Dec 9, 2014 at 5:59 PM, Mel Gorman <[email protected]> wrote:
> > On Tue, Dec 09, 2014 at 03:40:35PM +0800, Weijie Yang wrote:
> >> If the free page and its buddy has different zone id, the current
> >> zone->lock cann't prevent buddy page getting allocated, this could
> >> trigger VM_BUG_ON_PAGE in a very tiny chance:
> >>
> >
> > Under what circumstances can a buddy page be allocated without the
> > zone->lock? Any parallel allocation from that zone that takes place will
> > be from the per-cpu allocator and should not be affected by this. Have
> > you actually hit this race?
>
> My description maybe not clear, if the free page and its buddy is not
> at the same zone, the holding zone->lock cann't prevent buddy page
> getting allocated.
You're right, the description is not clear but now I see your
point. Thanks.
Acked-by: Mel Gorman <[email protected]>
--
Mel Gorman
SUSE Labs