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] [day] [month] [year] [list]
Message-ID: <f5a0afe9-cca4-4ed2-bdf1-0cd82f6e92b4@nvidia.com>
Date: Sun, 20 Oct 2024 23:38:47 -0700
From: John Hubbard <jhubbard@...dia.com>
To: Alistair Popple <apopple@...dia.com>
Cc: Andrew Morton <akpm@...ux-foundation.org>,
 LKML <linux-kernel@...r.kernel.org>, linux-mm@...ck.org,
 David Hildenbrand <david@...hat.com>, Shigeru Yoshida <syoshida@...hat.com>,
 Jason Gunthorpe <jgg@...dia.com>, Minchan Kim <minchan@...nel.org>,
 Pasha Tatashin <pasha.tatashin@...een.com>
Subject: Re: [PATCH v3] mm/gup: stop leaking pinned pages in low memory
 conditions

On 10/20/24 10:39 PM, Alistair Popple wrote:
> 
> John Hubbard <jhubbard@...dia.com> writes:
> 
>> On 10/20/24 4:26 PM, Alistair Popple wrote:
>>> John Hubbard <jhubbard@...dia.com> writes:
>>> [...]
>>>> @@ -2437,8 +2440,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);
>>> ie. Doesn't this unpinning need to happen in
>>> check_and_migrate_movable_folios()?
>>
>> It already does.
>>
>> check_and_migrate_movable_folios() calls
>> migrate_longterm_unpinnable_folios(), which unpins if errors occur.
> 
> Right you are.
> 
> Reviewed-by: Alistair Popple <apopple@...dia.com>

Thanks for the review!

> 
> As an aside for future clean-ups we could probably get something nicer
> if we reversed the process of pin/migrate to migrate/pin. In other words
> if FOLL_LONGERM try and migrate the entire range first out of
> ZONE_MOVABLE first. Migration invovles walking page tables and getting a
> reference on the pages anyway, so if it turns out there is nothing to
> migrate you haven't lost anything performance wise.
> 

Yes. In fact, I see our emails crossed, and I just suggested the same thing
in reply to your other comment (in the v2 review thread) about short vs.
long term pinning. Great! :)


thanks,
-- 
John Hubbard


Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ