linux-kernel - Re: [PATCH v4 33/66] xtensa: Remove vma linked list walks

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] [thread-next>] [day] [month] [year] [list]

Date:   Tue, 25 Jan 2022 16:17:07 +0000
From:   Liam Howlett <liam.howlett@...cle.com>
To:     Vlastimil Babka <vbabka@...e.cz>
CC:     "maple-tree@...ts.infradead.org" <maple-tree@...ts.infradead.org>,
        "linux-mm@...ck.org" <linux-mm@...ck.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        Andrew Morton <akpm@...ux-foundation.org>,
        Song Liu <songliubraving@...com>,
        Davidlohr Bueso <dave@...olabs.net>,
        "Paul E . McKenney" <paulmck@...nel.org>,
        Matthew Wilcox <willy@...radead.org>,
        Laurent Dufour <ldufour@...ux.ibm.com>,
        David Rientjes <rientjes@...gle.com>,
        Axel Rasmussen <axelrasmussen@...gle.com>,
        Suren Baghdasaryan <surenb@...gle.com>,
        Rik van Riel <riel@...riel.com>,
        Peter Zijlstra <peterz@...radead.org>,
        Michel Lespinasse <walken.cr@...il.com>,
        Jerome Glisse <jglisse@...hat.com>,
        Minchan Kim <minchan@...gle.com>,
        Joel Fernandes <joelaf@...gle.com>,
        Rom Lemarchand <romlem@...gle.com>
Subject: Re: [PATCH v4 33/66] xtensa: Remove vma linked list walks

* Vlastimil Babka <vbabka@...e.cz> [220118 07:23]:
> On 12/1/21 15:30, Liam Howlett wrote:
> > From: "Liam R. Howlett" <Liam.Howlett@...cle.com>
> > 
> > Use the VMA iterator instead.
> > 
> > Signed-off-by: Matthew Wilcox (Oracle) <willy@...radead.org>
> > Signed-off-by: Liam R. Howlett <Liam.Howlett@...cle.com>
> > ---
> >  arch/xtensa/kernel/syscall.c | 3 ++-
> >  1 file changed, 2 insertions(+), 1 deletion(-)
> > 
> > diff --git a/arch/xtensa/kernel/syscall.c b/arch/xtensa/kernel/syscall.c
> > index 201356faa7e6..20ec9534e01f 100644
> > --- a/arch/xtensa/kernel/syscall.c
> > +++ b/arch/xtensa/kernel/syscall.c
> > @@ -58,6 +58,7 @@ unsigned long arch_get_unmapped_area(struct file *filp, unsigned long addr,
> >  		unsigned long len, unsigned long pgoff, unsigned long flags)
> >  {
> >  	struct vm_area_struct *vmm;
> > +	VMA_ITERATOR(vmi, mm, addr)
> 
> Need to use current->mm or it won't compile, AFAICS.

I will fix this.

> 
> ;
> >  
> >  	if (flags & MAP_FIXED) {
> >  		/* We do not accept a shared mapping if it would violate
> > @@ -79,7 +80,7 @@ unsigned long arch_get_unmapped_area(struct file *filp, unsigned long addr,
> >  	else
> >  		addr = PAGE_ALIGN(addr);
> >  
> > -	for (vmm = find_vma(current->mm, addr); ; vmm = vmm->vm_next) {
> > +	for_each_vma(vmi, vmm) {
> >  		/* At this point:  (!vmm || addr < vmm->vm_end). */
> 
> Well if at this point !vmm then we are no longer here due to for_each_vma().
> 
> >  		if (TASK_SIZE - len < addr)
> >  			return -ENOMEM;
> 
> Thus we can miss this? But maybe it could be moved above the for loop and
> checked just once, as addr only grows inside the for loop?

Yes, it could be missed.  We could move it below, but not before as it
is to detect the VMA overrunning TASK_SIZE.  The check below will need
to break.  I think it's rare enough that it's okay to run slightly
longer when returning -ENOMEM.

> 
> However, the loop body continues:
> 
> >                 if (!vmm || addr + len <= vm_start_gap(vmm))
> >                         return addr;
> 
> So after your patch we fail to return the unmapped area after the last vma.

I will restructure the loop to avoid this issue.