From: John Hubbard <jhubbard@xxxxxxxxxx>
Hi,
I'm including people who have been talking about this. This is in one sense
a medium-term work around, because there is a plan to talk about more
extensive fixes at the upcoming Linux Plumbers Conference. I am seeing
several customer bugs, though, and I really want to fix those sooner.
I've come up with what I claim is a simple, robust fix, but...I'm
presuming to burn a struct page flag, and limit it to 64-bit arches, in
order to get there. Given that the problem is old (Jason Gunthorpe noted
that RDMA has been living with this problem since 2005), I think it's
worth it.
Leaving the new page flag set "nearly forever" is not great, but on the
other hand, once the page is actually freed, the flag does get cleared.
It seems like an acceptable tradeoff, given that we only get one bit
(and are lucky to even have that).
As hinted at in the longer writeup in patch #2, I really don't like the
various other approaches in which we try to hook into the (many!)
downstream symptoms and try to deduce that we're in this situation. It's
more appropriate to say, "these pages shall not be unmapped, nor buffers
removed ("do not disturb"), because they have been, well, pinned by the
get_user_pages call. I believe that this is what the original intention
might have been, and in any case, that's certainly how a lot of device
driver writers have interpreted get_user_pages memory over the last
decade.
John Hubbard (2):
consolidate get_user_pages error handling
mm: set PG_dma_pinned on get_user_pages*()
include/linux/page-flags.h | 9 +++++++
include/trace/events/mmflags.h | 9 ++++++-
mm/gup.c | 48 ++++++++++++++++++++++------------
mm/page_alloc.c | 1 +
mm/rmap.c | 2 ++
5 files changed, 51 insertions(+), 18 deletions(-)
--
2.17.1
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
