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: <20230611054455.GM52412@kernel.org>
Date:   Sun, 11 Jun 2023 08:44:55 +0300
From:   Mike Rapoport <rppt@...nel.org>
To:     Baoquan He <bhe@...hat.com>
Cc:     linux-kernel@...r.kernel.org, linux-arch@...r.kernel.org,
        linux-mm@...ck.org, arnd@...db.de, christophe.leroy@...roup.eu,
        hch@....de, willy@...radead.org, agordeev@...ux.ibm.com,
        wangkefeng.wang@...wei.com, schnelle@...ux.ibm.com,
        David.Laight@...LAB.COM, shorne@...il.com, deller@....de,
        Jonas Bonn <jonas@...thpole.se>,
        Stefan Kristiansson <stefan.kristiansson@...nalahti.fi>,
        openrisc@...ts.librecores.org
Subject: Re: [PATCH v6 03/19] openrisc: mm: remove unneeded early ioremap code

On Fri, Jun 09, 2023 at 03:55:12PM +0800, Baoquan He wrote:
> Under arch/openrisc, there isn't any place where ioremap() is called.
> It means that there isn't early ioremap handling needed in openrisc,
> So the early ioremap handling code in ioremap() of
> arch/openrisc/mm/ioremap.c is unnecessary and can be removed.
> 
> And also remove the special handling in iounmap() since no page
> is got from fixmap pool along with early ioremap code removing
> in ioremap().
> 
> Link: https://lore.kernel.org/linux-mm/YwxfxKrTUtAuejKQ@oscomms1/
> Signed-off-by: Baoquan He <bhe@...hat.com>
> Acked-by: Stafford Horne <shorne@...il.com>
> Cc: Jonas Bonn <jonas@...thpole.se>
> Cc: Stefan Kristiansson <stefan.kristiansson@...nalahti.fi>
> Cc: Stafford Horne <shorne@...il.com>
> Cc: openrisc@...ts.librecores.org

Reviewed-by: Mike Rapoport (IBM) <rppt@...nel.org>

> ---
> v5->v6:
>   Remove the special handling in iounmap() because no page is got from
>   fixmap pool along with early ioremap code removing in ioremap() - Mike.
> 
>  arch/openrisc/mm/ioremap.c | 43 +++++---------------------------------
>  1 file changed, 5 insertions(+), 38 deletions(-)
> 
> diff --git a/arch/openrisc/mm/ioremap.c b/arch/openrisc/mm/ioremap.c
> index 8ec0dafecf25..cdbcc7e73684 100644
> --- a/arch/openrisc/mm/ioremap.c
> +++ b/arch/openrisc/mm/ioremap.c
> @@ -22,8 +22,6 @@
>  
>  extern int mem_init_done;
>  
> -static unsigned int fixmaps_used __initdata;
> -
>  /*
>   * Remap an arbitrary physical address space into the kernel virtual
>   * address space. Needed when the kernel wants to access high addresses
> @@ -52,24 +50,14 @@ void __iomem *__ref ioremap(phys_addr_t addr, unsigned long size)
>  	p = addr & PAGE_MASK;
>  	size = PAGE_ALIGN(last_addr + 1) - p;
>  
> -	if (likely(mem_init_done)) {
> -		area = get_vm_area(size, VM_IOREMAP);
> -		if (!area)
> -			return NULL;
> -		v = (unsigned long)area->addr;
> -	} else {
> -		if ((fixmaps_used + (size >> PAGE_SHIFT)) > FIX_N_IOREMAPS)
> -			return NULL;
> -		v = fix_to_virt(FIX_IOREMAP_BEGIN + fixmaps_used);
> -		fixmaps_used += (size >> PAGE_SHIFT);
> -	}
> +	area = get_vm_area(size, VM_IOREMAP);
> +	if (!area)
> +		return NULL;
> +	v = (unsigned long)area->addr;
>  
>  	if (ioremap_page_range(v, v + size, p,
>  			__pgprot(pgprot_val(PAGE_KERNEL) | _PAGE_CI))) {
> -		if (likely(mem_init_done))
> -			vfree(area->addr);
> -		else
> -			fixmaps_used -= (size >> PAGE_SHIFT);
> +		vfree(area->addr);
>  		return NULL;
>  	}
>  
> @@ -79,27 +67,6 @@ EXPORT_SYMBOL(ioremap);
>  
>  void iounmap(volatile void __iomem *addr)
>  {
> -	/* If the page is from the fixmap pool then we just clear out
> -	 * the fixmap mapping.
> -	 */
> -	if (unlikely((unsigned long)addr > FIXADDR_START)) {
> -		/* This is a bit broken... we don't really know
> -		 * how big the area is so it's difficult to know
> -		 * how many fixed pages to invalidate...
> -		 * just flush tlb and hope for the best...
> -		 * consider this a FIXME
> -		 *
> -		 * Really we should be clearing out one or more page
> -		 * table entries for these virtual addresses so that
> -		 * future references cause a page fault... for now, we
> -		 * rely on two things:
> -		 *   i)  this code never gets called on known boards
> -		 *   ii) invalid accesses to the freed areas aren't made
> -		 */
> -		flush_tlb_all();
> -		return;
> -	}
> -
>  	return vfree((void *)(PAGE_MASK & (unsigned long)addr));
>  }
>  EXPORT_SYMBOL(iounmap);
> -- 
> 2.34.1
> 

-- 
Sincerely yours,
Mike.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ