linux-kernel - Re: cma_alloc(), add sleep-and-retry for temporary page pinning

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]

Date:   Fri, 11 Sep 2020 18:39:15 +0000
From:   Chris Goldsworthy <cgoldswo@...eaurora.org>
To:     Andrew Morton <akpm@...ux-foundation.org>
Cc:     linux-mm@...ck.org, linux-arm-msm@...r.kernel.org,
        linux-kernel@...r.kernel.org, pratikp@...eaurora.org,
        pdaly@...eaurora.org, sudraja@...eaurora.org,
        iamjoonsoo.kim@....com, linux-arm-msm-owner@...r.kernel.org
Subject: Re: cma_alloc(), add sleep-and-retry for temporary page pinning

On 2020-08-21 15:01, Andrew Morton wrote:
> On Tue, 11 Aug 2020 15:20:47 -0700 cgoldswo@...eaurora.org wrote:
> 
>> One
>> thing to stress is that there are other instances of CMA page pinning,
>> that
>> this patch isn't attempting to address.
> 
> Oh.  How severe are these?

Hey Andrew,

   - get_user_pages() will pin pages (I think that's a 100% guarantee but 
I'd need to double check that). There isn't a workaround for this as far 
as I know.
   - One issue we've encountered is when the pages for buffer heads are 
stuck on an LRU list (see the call to buffer_busy() in drop_buffers() 
https://elixir.bootlin.com/linux/v5.8.8/source/fs/buffer.c#L3225). We 
deal with this by allowing the buffers to be dropped, if the reason 
buffer_busy() returns true is because the page is on an LRU list.

> Well.  Why not wait infinitely?  Because there are other sources of CMA
> page pinning, I guess.
> 
> Could we take a sleeping lock on the exit_mmap() path and on the
> migration path?  So that the migration path automatically waits for
> the exact amount of time?

Retrying indefinitely whilst alloc_contig_range() returns -EBUSY is 
actually a viable approach.  From the perspective of how long it takes 
to perform a CMA allocation, it is preferable compared to the lock-based 
method, in terms of how long it would take to do a CMA allocation.  With 
our current method, we attempt allocations across an entire CMA region 
before sleeping and retrying. With the lock-based method, we'd be 
sleeping on a per-page basis - this could lead to a situation where we 
spend a great deal of time waiting for a particular page A to be freed, 
that lies in the subset of the CMA region we're allocating form.  We 
could have instead given up on allocating that subset of the CMA region 
(because page A is pinned), and have moved on to a different subset of 
the CMA region, and have successfully allocated that subset, whilst page 
A is still pinned.

I have a patch ready that does this indefinite-retrying, that will be 
sent in reply to this e-mail.

Regards,

Chris.

--
The Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora
Forum,
a Linux Foundation Collaborative Project