All of lore.kernel.org
 help / color / mirror / Atom feed
From: Rik van Riel <riel@surriel.com>
To: Mike Kravetz <mike.kravetz@oracle.com>
Cc: linux-kernel@vger.kernel.org, kernel-team@meta.com,
	linux-mm@kvack.org, akpm@linux-foundation.org,
	muchun.song@linux.dev, leit@meta.com, willy@infradead.org
Subject: Re: [PATCH 2/3] hugetlbfs: close race between MADV_DONTNEED and page fault
Date: Tue, 03 Oct 2023 15:35:25 -0400	[thread overview]
Message-ID: <8d19b6d092b7b5d9b1d0829e0d99c9915db3ed61.camel@surriel.com> (raw)
In-Reply-To: <20231002043958.GB11194@monkey>

On Sun, 2023-10-01 at 21:39 -0700, Mike Kravetz wrote:
> 
> Something is not right here.  I have not looked closely at the patch,
> but running libhugetlbfs test suite hits this NULL deref in misalign
> (2M: 32).

Hi Mike,

fixing the null dereference was easy, but I continued running
into a test case failure with linkhuge_rw. After tweaking the
code in my patches quite a few times, I finally ran out of
ideas and tried it on a tree without my patches.

I still see the test failure on upstream
2cf0f7156238 ("Merge tag 'nfs-for-6.6-2' of git://git.linux-
nfs.org/projects/anna/linux-nfs")

This is with a modern glibc, and the __morecore assignments
in libhugetlbfs/morecore.c commented out.


HUGETLB_ELFMAP=R HUGETLB_SHARE=1 linkhuge_rw (2M: 32):	Pool state:
(('hugepages-2048kB', (('free_hugepages', 1), ('resv_hugepages', 0),
('surplus_hugepages', 0), ('nr_hugepages_mempolicy', 1),
('nr_hugepages', 1), ('nr_overcommit_hugepages', 0))),)
Hugepage pool state not preserved!
BEFORE: (('hugepages-2048kB', (('free_hugepages', 1),
('resv_hugepages', 0), ('surplus_hugepages', 0),
('nr_hugepages_mempolicy', 1), ('nr_hugepages', 1),
('nr_overcommit_hugepages', 0))),)
AFTER: (('hugepages-2048kB', (('free_hugepages', 0), ('resv_hugepages',
0), ('surplus_hugepages', 0), ('nr_hugepages_mempolicy', 1),
('nr_hugepages', 1), ('nr_overcommit_hugepages', 0))),)


It may take a little while to figure this one out. I did some
bpftracing, but don't have a real smoking gun yet. The trace
certainly shows the last user of the leaked huge page going
into __unmap_hugepage_range.

-- 
All Rights Reversed.

  parent reply	other threads:[~2023-10-03 19:35 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-10-01  0:55 [PATCH v5 0/3] hugetlbfs: close race between MADV_DONTNEED and page fault riel
2023-10-01  0:55 ` [PATCH 1/3] hugetlbfs: extend hugetlb_vma_lock to private VMAs riel
2023-10-01  0:55 ` [PATCH 2/3] hugetlbfs: close race between MADV_DONTNEED and page fault riel
2023-10-02  4:39   ` Mike Kravetz
2023-10-02 13:13     ` Rik van Riel
2023-10-03 19:35     ` Rik van Riel [this message]
2023-10-03 20:19       ` Mike Kravetz
2023-10-04  0:20         ` Rik van Riel
2023-10-01  0:55 ` [PATCH 3/3] hugetlbfs: replace hugetlb_vma_lock with invalidate_lock riel
2023-10-02  5:22   ` Mike Kravetz
2023-10-01  2:54 ` [PATCH v5 0/3] hugetlbfs: close race between MADV_DONTNEED and page fault Andrew Morton
  -- strict thread matches above, loose matches on Subject: below --
2023-10-04  3:25 [PATCH v6 " riel
2023-10-04  3:25 ` [PATCH 2/3] " riel
2023-10-05  3:19   ` Mike Kravetz
2023-10-05 13:23     ` Rik van Riel
2023-10-05 22:59       ` Mike Kravetz
2023-09-26  3:10 [PATCH v4 0/3] " riel
2023-09-26  3:10 ` [PATCH 2/3] " riel
2023-09-26 21:15   ` Andrew Morton
2023-09-26 23:57     ` Rik van Riel
2023-09-25 20:28 [PATCH v3 0/3] " riel
2023-09-25 20:28 ` [PATCH 2/3] " riel
2023-09-25 22:25   ` Mike Kravetz
2023-09-26  0:46     ` Rik van Riel
2023-09-22 19:02 [PATCH v2 0/3] " riel
2023-09-22 19:02 ` [PATCH 2/3] " riel

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=8d19b6d092b7b5d9b1d0829e0d99c9915db3ed61.camel@surriel.com \
    --to=riel@surriel.com \
    --cc=akpm@linux-foundation.org \
    --cc=kernel-team@meta.com \
    --cc=leit@meta.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=mike.kravetz@oracle.com \
    --cc=muchun.song@linux.dev \
    --cc=willy@infradead.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.