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
| ||
|
Date: Thu, 2 Mar 2023 00:53:45 +0000 From: Hyeonggon Yoo <42.hyeyoo@...il.com> To: Suren Baghdasaryan <surenb@...gle.com> Cc: akpm@...ux-foundation.org, michel@...pinasse.org, jglisse@...gle.com, mhocko@...e.com, vbabka@...e.cz, hannes@...xchg.org, mgorman@...hsingularity.net, dave@...olabs.net, willy@...radead.org, liam.howlett@...cle.com, peterz@...radead.org, ldufour@...ux.ibm.com, paulmck@...nel.org, mingo@...hat.com, will@...nel.org, luto@...nel.org, songliubraving@...com, peterx@...hat.com, david@...hat.com, dhowells@...hat.com, hughd@...gle.com, bigeasy@...utronix.de, kent.overstreet@...ux.dev, punit.agrawal@...edance.com, lstoakes@...il.com, peterjung1337@...il.com, rientjes@...gle.com, chriscli@...gle.com, axelrasmussen@...gle.com, joelaf@...gle.com, minchan@...gle.com, rppt@...nel.org, jannh@...gle.com, shakeelb@...gle.com, tatashin@...gle.com, edumazet@...gle.com, gthelen@...gle.com, gurua@...gle.com, arjunroy@...gle.com, soheil@...gle.com, leewalsh@...gle.com, posk@...gle.com, michalechner92@...glemail.com, linux-mm@...ck.org, linux-arm-kernel@...ts.infradead.org, linuxppc-dev@...ts.ozlabs.org, x86@...nel.org, linux-kernel@...r.kernel.org, kernel-team@...roid.com Subject: Re: [PATCH v4 18/33] mm: write-lock VMAs before removing them from VMA tree On Wed, Mar 01, 2023 at 10:42:48AM -0800, Suren Baghdasaryan wrote: > On Wed, Mar 1, 2023 at 10:34 AM Suren Baghdasaryan <surenb@...gle.com> wrote: > > > > On Tue, Feb 28, 2023 at 11:57 PM Hyeonggon Yoo <42.hyeyoo@...il.com> wrote: > > > > > > On Wed, Mar 01, 2023 at 07:43:33AM +0000, Hyeonggon Yoo wrote: > > > > On Mon, Feb 27, 2023 at 09:36:17AM -0800, Suren Baghdasaryan wrote: > > > > > Write-locking VMAs before isolating them ensures that page fault > > > > > handlers don't operate on isolated VMAs. > > > > > > > > > > Signed-off-by: Suren Baghdasaryan <surenb@...gle.com> > > > > > --- > > > > > mm/mmap.c | 1 + > > > > > mm/nommu.c | 5 +++++ > > > > > 2 files changed, 6 insertions(+) > > > > > > > > > > diff --git a/mm/mmap.c b/mm/mmap.c > > > > > index 1f42b9a52b9b..f7ed357056c4 100644 > > > > > --- a/mm/mmap.c > > > > > +++ b/mm/mmap.c > > > > > @@ -2255,6 +2255,7 @@ int split_vma(struct vma_iterator *vmi, struct vm_area_struct *vma, > > > > > static inline int munmap_sidetree(struct vm_area_struct *vma, > > > > > struct ma_state *mas_detach) > > > > > { > > > > > + vma_start_write(vma); > > > > > mas_set_range(mas_detach, vma->vm_start, vma->vm_end - 1); > > > > > > > > I may be missing something, but have few questions: > > > > > > > > 1) Why does a writer need to both write-lock a VMA and mark the VMA detached > > > > when unmapping it, isn't it enough to just only write-lock a VMA? > > > > We need to mark the VMA detached to avoid handling page fault in a > > detached VMA. The possible scenario is: > > > > lock_vma_under_rcu > > vma = mas_walk(&mas) > > munmap_sidetree > > vma_start_write(vma) > > > > mas_store_gfp() // remove VMA from the tree > > vma_end_write_all() > > vma_start_read(vma) > > // we locked the VMA but it is not part of the tree anymore. > > > > So, marking the VMA locked before vma_end_write_all() and checking > > Sorry, I should have said "marking the VMA *detached* before > vma_end_write_all() and checking vma->detached after vma_start_read() > helps us avoid handling faults in the detached VMA." > > > vma->detached after vma_start_read() helps us avoid handling faults in > > the detached VMA. Thank you for explanation, that makes sense! By the way, if there are no 32bit users of Per-VMA lock (are there?), "detached" bool could be a VMA flag (i.e. making it depend on 64BIT and selecting ARCH_USES_HIGH_VMA_FLAGS) Thanks, Hyeonggon
Powered by blists - more mailing lists