Re: get_zone_device_page() in get_page() and page_cache_get_speculative()

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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>



[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Bugtraq]     [Linux OMAP]     [Linux MIPS]     [eCos]     [Asterisk Internet PBX]     [Linux API]
  Powered by Linux