Messages in this thread | | | Date | Tue, 25 Sep 2012 11:00:55 -0300 | From | Rafael Aquini <> | Subject | Re: [PATCH v10 1/5] mm: introduce a common interface for balloon pages mobility |
| |
On Tue, Sep 25, 2012 at 03:05:49AM +0200, Michael S. Tsirkin wrote: > If these are all under page lock these barriers just confuse things, > because they are almost never enough by themselves. > So in that case it would be better to drop them and document > usage as you are going to. >
Would the following make more sense (with the proprer comments, as well) ?
---8<--- +static inline void balloon_page_set(struct page *page, + struct address_space *mapping, + struct list_head *head) +{ + list_add(&page->lru, head); + smp_wmb(); + page->mapping = mapping; +} + +static inline void balloon_page_del(struct page *page) +{ + page->mapping = NULL; + smp_wmb(); + list_del(&page->lru); +} + +static inline bool __is_movable_balloon_page(struct page *page) +{ + struct address_space *mapping = ACCESS_ONCE(page->mapping); + smp_read_barrier_depends(); + return mapping_balloon(mapping); +} + ---8<---
There's still a case where we have to test page->mapping->flags and we cannot afford to wait for, or grab, the page lock @ isolate_migratepages_range(). The barriers won't avoid leak_ballon() racing against isolate_migratepages_range(), but they surely will make tests for page->mapping more consistent. And for those cases where leak_balloon() races against isolate_migratepages_range->isolate_balloon_page(), we solve the conflict of interest through page refcounting and page lock. I'm preparing a more extensive doc to include at Documentation/ to explain the interfaces and how we cope with these mentioned races, as well.
| |