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 for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date:   Thu, 10 Jan 2019 15:11:09 +1100
From:   David Gibson <david@...son.dropbear.id.au>
To:     "Aneesh Kumar K.V" <aneesh.kumar@...ux.ibm.com>
Cc:     Andrew Morton <akpm@...ux-foundation.org>,
        Michal Hocko <mhocko@...nel.org>,
        Alexey Kardashevskiy <aik@...abs.ru>,
        Andrea Arcangeli <aarcange@...hat.com>, mpe@...erman.id.au,
        linux-mm@...ck.org, linux-kernel@...r.kernel.org,
        linuxppc-dev@...ts.ozlabs.org
Subject: Re: [PATCH V6 0/4] mm/kvm/vfio/ppc64: Migrate compound pages out of
 CMA region

On Wed, Jan 09, 2019 at 02:11:25PM +0530, Aneesh Kumar K.V wrote:
> Andrew Morton <akpm@...ux-foundation.org> writes:
> 
> > On Tue,  8 Jan 2019 10:21:06 +0530 "Aneesh Kumar K.V" <aneesh.kumar@...ux.ibm.com> wrote:
> >
> >> ppc64 use CMA area for the allocation of guest page table (hash page table). We won't
> >> be able to start guest if we fail to allocate hash page table. We have observed
> >> hash table allocation failure because we failed to migrate pages out of CMA region
> >> because they were pinned. This happen when we are using VFIO. VFIO on ppc64 pins
> >> the entire guest RAM. If the guest RAM pages get allocated out of CMA region, we
> >> won't be able to migrate those pages. The pages are also pinned for the lifetime of the
> >> guest.
> >> 
> >> Currently we support migration of non-compound pages. With THP and with the addition of
> >>  hugetlb migration we can end up allocating compound pages from CMA region. This
> >> patch series add support for migrating compound pages. The first path adds the helper
> >> get_user_pages_cma_migrate() which pin the page making sure we migrate them out of
> >> CMA region before incrementing the reference count. 
> >
> > Does this code do anything for architectures other than powerpc?  If
> > not, should we be adding the ifdefs to avoid burdening other
> > architectures with unused code?
> 
> Any architecture enabling CMA may need this. I will move most of this below
> CONFIG_CMA.

In theory it could affect any architecture using CMA.  I suspect it's
much less likely to bite in practice on architectures other than ppc.
IIUC the main use of CMA there is to allocate things like framebuffers
or other large contiguous blocks used for hardware devices.  That's
usually going to happen rarely and during boot up.  What makes ppc
different is that we need a substantial CMA allocation every time we
start a (POWER8) guest for the HPT.  It's the fact that running guests
on a system both means we need the CMA unfragment and (with vfio added
in) can cause CMA fragmentation which makes this particularly
problematic.

-- 
David Gibson			| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au	| minimalist, thank you.  NOT _the_ _other_
				| _way_ _around_!
http://www.ozlabs.org/~dgibson

Download attachment "signature.asc" of type "application/pgp-signature" (834 bytes)

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ