linux-kernel - Re: [PATCH v2 1/2] mm/gup: stop leaking pinned pages in low memory conditions

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <8734kqcr5g.fsf@nvdebian.thelocal>
Date: Mon, 21 Oct 2024 09:59:39 +1100
From: Alistair Popple <apopple@...dia.com>
To: John Hubbard <jhubbard@...dia.com>
Cc: David Hildenbrand <david@...hat.com>, Andrew Morton
 <akpm@...ux-foundation.org>, LKML <linux-kernel@...r.kernel.org>,
 linux-mm@...ck.org, Shigeru Yoshida <syoshida@...hat.com>, Jason Gunthorpe
 <jgg@...dia.com>, Minchan Kim <minchan@...nel.org>, Pasha Tatashin
 <pasha.tatashin@...een.com>
Subject: Re: [PATCH v2 1/2] mm/gup: stop leaking pinned pages in low memory
 conditions


John Hubbard <jhubbard@...dia.com> writes:

> On 10/18/24 12:47 AM, David Hildenbrand wrote:
>> On 18.10.24 03:17, John Hubbard wrote:

[...]

> And actually this whole thing of "pin the pages, just for a short time, even
> though you're not allowed to" is partly why this area is so entertaining.

I'm looking at your v3 but as an aside I disagree with this
statement. AFAIK you're always allowed to pin the pages for a short time
(ie. !FOLL_LONGTERM), or did I misunderstand your comment?

>> diff --git a/mm/gup.c b/mm/gup.c
>> index a82890b46a36..81fc8314e687 100644
>> --- a/mm/gup.c
>> +++ b/mm/gup.c
>> @@ -2403,8 +2403,9 @@ static int migrate_longterm_unpinnable_folios(
>>    * -EAGAIN. The caller should re-pin the entire range with
>> FOLL_PIN and then
>>    * call this routine again.
>>    *
>> - * If an error other than -EAGAIN occurs, this indicates a
>> migration failure.
>> - * The caller should give up, and propagate the error back up the
>> call stack.
>> + * If an error occurs, all folios are unpinned. If an error other than
>> + * -EAGAIN occurs, this indicates a migration failure. The caller
>> should give
>> + * up, and propagate the error back up the call stack.
>>    *
>>    * If everything is OK and all folios in the range are allowed to
>> be pinned,
>>    * then this routine leaves all folios pinned and returns zero for
>> success.
>> @@ -2437,8 +2438,10 @@ static long
>> check_and_migrate_movable_pages(unsigned long nr_pages,
>>          long i, ret;
>>          folios = kmalloc_array(nr_pages, sizeof(*folios),
>> GFP_KERNEL);
>> -       if (!folios)
>> +       if (!folios) {
>> +               unpin_user_pages(pages, nr_pages);
>>                  return -ENOMEM;
>> +       }
>>          for (i = 0; i < nr_pages; i++)
>>                  folios[i] = page_folio(pages[i]);
>> Then, check_and_migrate_movable_pages() will never return with an
>> error and
>> having folios pinned.
>> If check_and_migrate_movable_pages() ->
>> check_and_migrate_movable_folios()
>> returns "0", all folios remain pinned an no harm is done.
>> Consequently, I think patch #2 is not really required, because it
>> doesn't
>> perform the temporary allocation that could fail with -ENOMEM.
>> 
>
> Yes!
>
>> Sorry for taking a closer look only now ...
>> 
>
> It's all still in review, so the timing is perfectly fine. I really
> appreciate the closer look, it's definitely making things better.
>
>
> thanks,