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: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <c4c90bfb-5e94-84fb-aec8-cc0edb9b7efb@suse.cz>
Date:   Tue, 18 Jan 2022 13:23:49 +0100
From:   Vlastimil Babka <vbabka@...e.cz>
To:     Liam Howlett <liam.howlett@...cle.com>,
        "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>
Cc:     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

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.

;
>  
>  	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?

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.