On Mon, Apr 24, 2017 at 10:47:43AM -0700, Dan Williams wrote: > On Mon, Apr 24, 2017 at 10:30 AM, Kirill A. Shutemov > >> >> [ 35.423841] WARNING: CPU: 8 PID: 245 at lib/percpu-refcount.c:155 > >> >> percpu_ref_switch_to_atomic_rcu+0x1f5/0x200 > >> > > >> > Okay, I've tracked it down. The issue is triggered by replacment > >> > get_page() with page_cache_get_speculative(). > >> > > >> > page_cache_get_speculative() doesn't have get_zone_device_page(). :-| > >> > > >> > And I think it's your bug, Dan: it's wrong to have > >> > get_/put_zone_device_page() in get_/put_page(). I must be handled by > >> > page_ref_* machinery to catch all cases where we manipulate with page > >> > refcount. > >> > >> The page_ref conversion landed in 4.6 *after* the ZONE_DEVICE > >> implementation that landed in 4.5, so there was a missed conversion of > >> the zone-device reference counting to page_ref. > > > > Fair enough. > > > > But get_page_unless_zero() definitely predates ZONE_DEVICE. :) > > > > It does, but that's deliberate. A ZONE_DEVICE page never has a zero > reference count, it's always owned by the device, never by the page > allocator. ZONE_DEVICE overrides the ->lru list_head to store private > device information and we rely on the behavior that a non-zero > reference means the page is not added to any lru or page cache list. So, what do you propose? Use get_page() instead of page_cache_get_speculative() in GUP_fast() if the page belong to zone device? I don't like it. This situation, when we only can use subset of helpers to manipulate page refcount creates situation waiting to explode. I think it's still better to do it on page_ref_* level. BTW, why do we need to pin pgmap from get_page() in first place? I don't have enough background in ZONE_DEVICE. -- Kirill A. Shutemov -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@xxxxxxxxx. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>
