mbox series

[v10,0/3] fix hugetlb MADV_DONTNEED vma_lock handling

Message ID 20221114235507.294320-1-mike.kravetz@oracle.com
Headers
Series fix hugetlb MADV_DONTNEED vma_lock handling |

Message

Mike Kravetz Nov. 14, 2022, 11:55 p.m. UTC 
  This series addresses the issue first reported in [1], and fully
described in patch 2.  Patches 1 and 2 address the user visible issue
and are tagged for stable backports.

While exploring solutions to this issue, related problems with mmu
notification calls were discovered.  This is addressed in patch 3.
Since there are no user visible effects, patch 3 is not tagged for
stable backports.

Previous discussions suggested further cleanup by removing the
routine zap_page_range.  This is possible because zap_page_range_single
is now exported, and all callers of zap_page_range pass ranges entirely
within a single vma.  This work will be done in a later patch so as not
to distract from this bug fix.

[1] https://lore.kernel.org/lkml/CAO4mrfdLMXsao9RF4fUE8-Wfde8xmjsKrTNMNC9wjUb6JudD0g@mail.gmail.com/

v9-v10 Rearrange series and do not tag "remove duplicate mmu notifications"
       patch for stable as suggested by David.

Mike Kravetz (3):
  madvise: use zap_page_range_single for madvise dontneed
  hugetlb: don't delete vma_lock in hugetlb MADV_DONTNEED processing
  hugetlb: remove duplicate mmu notifications

 include/linux/mm.h | 29 +++++++++++++++++++++--------
 mm/hugetlb.c       | 45 +++++++++++++++++++++++++--------------------
 mm/madvise.c       |  6 +++---
 mm/memory.c        | 25 ++++++++++++-------------
 4 files changed, 61 insertions(+), 44 deletions(-)

Comments

Andrew Morton Nov. 23, 2022, 2:07 a.m. UTC | #1 
Could this series be implicated in
https://lkml.kernel.org/r/00000000000041a69905edf8c1e3@google.com?
Mike Kravetz Nov. 23, 2022, 2:21 a.m. UTC | #2 
On 11/22/22 18:07, Andrew Morton wrote:
> Could this series be implicated in
> https://lkml.kernel.org/r/00000000000041a69905edf8c1e3@google.com?

If I am reading the report correctly, I would say that this series (at least
the first two patches) would address that issue.  The bot is running against
6.1-rcX and those patches have not yet been sent to the 6.1 stream.