linux-kernel - Re: [PATCH] Increase default MLOCK

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: <2adca04f-92e1-5f99-6094-5fac66a22a77@redhat.com>
Date:   Wed, 24 Nov 2021 09:57:32 +0100
From:   David Hildenbrand <david@...hat.com>
To:     Jason Gunthorpe <jgg@...pe.ca>, Vlastimil Babka <vbabka@...e.cz>
Cc:     Jens Axboe <axboe@...nel.dk>,
        Andrew Dona-Couch <andrew@...acou.ch>,
        Andrew Morton <akpm@...ux-foundation.org>,
        Drew DeVault <sir@...wn.com>,
        Ammar Faizi <ammarfaizi2@...weeb.org>,
        linux-kernel@...r.kernel.org, linux-api@...r.kernel.org,
        io_uring Mailing List <io-uring@...r.kernel.org>,
        Pavel Begunkov <asml.silence@...il.com>, linux-mm@...ck.org
Subject: Re: [PATCH] Increase default MLOCK_LIMIT to 8 MiB

On 24.11.21 00:59, Jason Gunthorpe wrote:
> On Tue, Nov 23, 2021 at 11:04:04PM +0100, Vlastimil Babka wrote:
>> On 11/23/21 18:00, Jason Gunthorpe wrote:
>>>
>>>> believe what you say and I trust your experience :) So could as well be
>>>> that on such a "special" (or not so special) systems there should be a
>>>> way to restrict it to privileged users only.
>>>
>>> At this point RDMA is about as "special" as people running large
>>> ZONE_MOVABLE systems, and the two are going to start colliding
>>> heavily. The RDMA VFIO migration driver should be merged soon which
>>> makes VMs using this stuff finally practical.
>>
>> How does that work, I see the word migration, so does it cause pages to
> 
> Sorry I mean what is often called "VM live migration". Typically that
> cannot be done if a PCI device is assigned to the VM as suspending and
> the migrating a PCI device to another server is complicated. With
> forthcoming hardware mlx5 can do this and thus the entire RDMA stack
> becomes practically usable and performant within a VM.
> 
>> be migrated out of ZONE_MOVABLE before they are pinned?
> 
> GUP already does this automatically for FOLL_LONGTERM.
> 
>> Similarly for io-uring we could be migrating pages to be pinned so that
>> the end up consolidated close together, and prevent pathologic
>> situations like in David's reproducer. 
> 
> It is an interesting idea to have GUP do some kind of THP preserving
> migration.


Unfortunately it will only be a band aid AFAIU. I can rewrite my
reproducer fairly easily to pin the whole 2M range first, pin a second
time only a single page, and then unpin the 2M range, resulting in the
very same way to block THP. (I can block some THP less because I always
need the possibility to memlock 2M first, though).

-- 
Thanks,

David / dhildenb