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]
Date:   Thu, 5 Apr 2018 21:35:10 -0400
From:   Sinan Kaya <okaya@...eaurora.org>
To:     linux-alpha@...r.kernel.org, timur@...eaurora.org,
        sulrich@...eaurora.org
Cc:     arnd@...db.de, linux-arm-msm@...r.kernel.org,
        linux-arm-kernel@...ts.infradead.org,
        Richard Henderson <rth@...ddle.net>,
        Ivan Kokshaysky <ink@...assic.park.msu.ru>,
        Matt Turner <mattst88@...il.com>,
        Philippe Ombredanne <pombredanne@...b.com>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Guenter Roeck <linux@...ck-us.net>,
        Kate Stewart <kstewart@...uxfoundation.org>,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH] alpha: io: reorder barriers to guarantee writeX() and
 iowriteX() ordering

On 4/2/2018 1:48 PM, Sinan Kaya wrote:
> memory-barriers.txt has been updated with the following requirement.
> 
> "When using writel(), a prior wmb() is not needed to guarantee that the
> cache coherent memory writes have completed before writing to the MMIO
> region."
> 
> Current writeX() and iowriteX() implementations on alpha are not
> satisfying this requirement as the barrier is after the register write.
> 
> Move mb() in writeX() and iowriteX() functions to guarantee that HW
> observes memory changes before performing register operations.
> 
> Signed-off-by: Sinan Kaya <okaya@...eaurora.org>
> Reported-by: Arnd Bergmann <arnd@...db.de>
> ---
>  arch/alpha/include/asm/io.h | 14 +++++++-------
>  1 file changed, 7 insertions(+), 7 deletions(-)
> 
> diff --git a/arch/alpha/include/asm/io.h b/arch/alpha/include/asm/io.h
> index d123ff9..4c533fc 100644
> --- a/arch/alpha/include/asm/io.h
> +++ b/arch/alpha/include/asm/io.h
> @@ -341,14 +341,14 @@ extern inline unsigned int ioread16(void __iomem *addr)
>  
>  extern inline void iowrite8(u8 b, void __iomem *addr)
>  {
> -	IO_CONCAT(__IO_PREFIX,iowrite8)(b, addr);
>  	mb();
> +	IO_CONCAT(__IO_PREFIX, iowrite8)(b, addr);
>  }
>  
>  extern inline void iowrite16(u16 b, void __iomem *addr)
>  {
> -	IO_CONCAT(__IO_PREFIX,iowrite16)(b, addr);
>  	mb();
> +	IO_CONCAT(__IO_PREFIX, iowrite16)(b, addr);
>  }
>  
>  extern inline u8 inb(unsigned long port)
> @@ -382,8 +382,8 @@ extern inline unsigned int ioread32(void __iomem *addr)
>  
>  extern inline void iowrite32(u32 b, void __iomem *addr)
>  {
> -	IO_CONCAT(__IO_PREFIX,iowrite32)(b, addr);
>  	mb();
> +	IO_CONCAT(__IO_PREFIX, iowrite32)(b, addr);
>  }
>  
>  extern inline u32 inl(unsigned long port)
> @@ -434,14 +434,14 @@ extern inline u16 readw(const volatile void __iomem *addr)
>  
>  extern inline void writeb(u8 b, volatile void __iomem *addr)
>  {
> -	__raw_writeb(b, addr);
>  	mb();
> +	__raw_writeb(b, addr);
>  }
>  
>  extern inline void writew(u16 b, volatile void __iomem *addr)
>  {
> -	__raw_writew(b, addr);
>  	mb();
> +	__raw_writew(b, addr);
>  }
>  #endif
>  
> @@ -482,14 +482,14 @@ extern inline u64 readq(const volatile void __iomem *addr)
>  
>  extern inline void writel(u32 b, volatile void __iomem *addr)
>  {
> -	__raw_writel(b, addr);
>  	mb();
> +	__raw_writel(b, addr);
>  }
>  
>  extern inline void writeq(u64 b, volatile void __iomem *addr)
>  {
> -	__raw_writeq(b, addr);
>  	mb();
> +	__raw_writeq(b, addr);
>  }
>  #endif
>  
> 


Can we get these merged to 4.17? 

There was a consensus to fix the architectures having API violation issues.
https://www.mail-archive.com/netdev@vger.kernel.org/msg225971.html



-- 
Sinan Kaya
Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm Technologies, Inc.
Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ