linux-kernel - Re: [PATCH v5 3/3] mm/oom_kill: allow process_mrelease to run under mmap

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: <CAJuCfpFr-3S2Ge56p3d8CYWFCSmVheLi-9aVBv2Utg9mwBgrcw@mail.gmail.com>
Date:   Fri, 10 Dec 2021 07:54:31 -0800
From:   Suren Baghdasaryan <surenb@...gle.com>
To:     Jason Gunthorpe <jgg@...pe.ca>
Cc:     akpm@...ux-foundation.org, mhocko@...nel.org, mhocko@...e.com,
        rientjes@...gle.com, willy@...radead.org, hannes@...xchg.org,
        guro@...com, riel@...riel.com, minchan@...nel.org,
        kirill@...temov.name, aarcange@...hat.com, christian@...uner.io,
        hch@...radead.org, oleg@...hat.com, david@...hat.com,
        jannh@...gle.com, shakeelb@...gle.com, luto@...nel.org,
        christian.brauner@...ntu.com, fweimer@...hat.com, jengelh@...i.de,
        timmurray@...gle.com, linux-mm@...ck.org,
        linux-kernel@...r.kernel.org, kernel-team@...roid.com
Subject: Re: [PATCH v5 3/3] mm/oom_kill: allow process_mrelease to run under
 mmap_lock protection

On Thu, Dec 9, 2021 at 12:48 PM Jason Gunthorpe <jgg@...pe.ca> wrote:
>
> On Thu, Dec 09, 2021 at 11:13:25AM -0800, Suren Baghdasaryan wrote:
> > With exit_mmap holding mmap_write_lock during free_pgtables call,
> > process_mrelease does not need to elevate mm->mm_users in order to
> > prevent exit_mmap from destrying pagetables while __oom_reap_task_mm
> > is walking the VMA tree. The change prevents process_mrelease from
> > calling the last mmput, which can lead to waiting for IO completion
> > in exit_aio.
> >
> > Signed-off-by: Suren Baghdasaryan <surenb@...gle.com>
> > Acked-by: Michal Hocko <mhocko@...e.com>
> > ---
> > changes in v5
> > - Removed Fixes: tag, per Michal Hocko
> > - Added Acked-by's
> >
> >  mm/oom_kill.c | 27 +++++++++++++++------------
> >  1 file changed, 15 insertions(+), 12 deletions(-)
>
> Reviewed-by: Jason Gunthorpe <jgg@...dia.com>

Thanks!

>
> There are mmget_not_zero's all over the place, can others be cleaned
> after this series goes ahead too?
>
> It seems like anything doing the mmget just to look at the vma list
> under the mmap lock is now fine with only a mmgrab?

Sounds reasonable to me. I'll try to carve out some time to look into
it but no promises. Lots of loose ends to tie at the end of the year
:(

>
> A few I know about:
>
> drivers/infiniband/core/umem_odp.c:     if (!mmget_not_zero(umem->owning_mm)) {
>
> This is because mmu_interval_notifier_insert() might call
> mm_take_all_locks() which was unsafe with concurrent exit_mmap
>
> drivers/infiniband/core/umem_odp.c:     if (!owning_process || !mmget_not_zero(owning_mm)) {
>
> This is because it calls hmm_range_fault() which iterates over the vma
> list which is safe now
>
> drivers/iommu/iommu-sva-lib.c:  return mmget_not_zero(mm);
> drivers/iommu/iommu-sva-lib.c:  return ioasid_find(&iommu_sva_pasid, pasid, __mmget_not_zero);
>
> It calls find_extend_vma() - but also it doesn't seem to have a mmgrab when it
> does that mmget. The rcu is messed up here too, so humm.
>
> Jason