| 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
| ||
|
Message-ID: <e8026d75acfcf0eebc7bdb95120efe86c23bb917.camel@linux.ibm.com>
Date: Tue, 08 Oct 2024 15:42:23 +0200
From: Niklas Schnelle <schnelle@...ux.ibm.com>
To: Julian Vetter <jvetter@...rayinc.com>, Arnd Bergmann <arnd@...db.de>,
Russell King <linux@...linux.org.uk>,
Catalin Marinas
<catalin.marinas@....com>,
Will Deacon <will@...nel.org>, Guo Ren
<guoren@...nel.org>,
Huacai Chen <chenhuacai@...nel.org>, WANG Xuerui
<kernel@...0n.name>,
Andrew Morton <akpm@...ux-foundation.org>,
Geert
Uytterhoeven <geert@...ux-m68k.org>,
Richard Henderson
<richard.henderson@...aro.org>,
Ivan Kokshaysky <ink@...assic.park.msu.ru>,
Matt Turner <mattst88@...il.com>,
"James E . J . Bottomley"
<James.Bottomley@...senpartnership.com>,
Helge Deller <deller@....de>,
Yoshinori Sato <ysato@...rs.sourceforge.jp>,
Rich Felker <dalias@...c.org>,
John Paul Adrian Glaubitz <glaubitz@...sik.fu-berlin.de>,
Richard
Weinberger <richard@....at>,
Anton Ivanov
<anton.ivanov@...bridgegreys.com>,
Johannes Berg
<johannes@...solutions.net>,
Michael Ellerman <mpe@...erman.id.au>,
Nicholas Piggin <npiggin@...il.com>,
Christophe Leroy
<christophe.leroy@...roup.eu>,
Naveen N Rao <naveen@...nel.org>,
Madhavan
Srinivasan <maddy@...ux.ibm.com>,
Heiko Carstens <hca@...ux.ibm.com>, Vasily Gorbik <gor@...ux.ibm.com>,
Alexander Gordeev
<agordeev@...ux.ibm.com>,
Christian Borntraeger
<borntraeger@...ux.ibm.com>,
Sven Schnelle <svens@...ux.ibm.com>,
Manivannan Sadhasivam <manivannan.sadhasivam@...aro.org>,
Miquel Raynal
<miquel.raynal@...tlin.com>,
Vignesh Raghavendra <vigneshr@...com>,
Jaroslav Kysela <perex@...ex.cz>, Takashi Iwai <tiwai@...e.com>
Cc: linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org,
linux-csky@...r.kernel.org, loongarch@...ts.linux.dev,
linux-m68k@...ts.linux-m68k.org, linux-alpha@...r.kernel.org,
linux-parisc@...r.kernel.org, linux-sh@...r.kernel.org,
linux-um@...ts.infradead.org, linux-arch@...r.kernel.org,
linuxppc-dev@...ts.ozlabs.org, linux-s390@...r.kernel.org,
mhi@...ts.linux.dev, linux-arm-msm@...r.kernel.org,
linux-mtd@...ts.infradead.org, linux-sound@...r.kernel.org,
Yann Sionneau
<ysionneau@...rayinc.com>
Subject: Re: [PATCH v8 11/14] s390: Add wrappers around
zpci_memcpy/zpci_memset
On Tue, 2024-10-08 at 09:50 +0200, Julian Vetter wrote:
> Add wrapper functions around zpci_memcpy_{from,to}io and zpci_memset_io,
> which have aligned prototypes with the ones from iomap_copy.c. These
> wrappers are necessary because the prototypes of the zpci_ functions
> can't be changed. In s390 arch code they are directly being called and
> the return value is checked, At the same time they serve as generic
> memcpy_{from,to}io and memset_io functions, without a return value.
>
> Reviewed-by: Yann Sionneau <ysionneau@...rayinc.com>
> Signed-off-by: Julian Vetter <jvetter@...rayinc.com>
> ---
> Changes for v8:
> - New patch
> ---
> arch/s390/include/asm/io.h | 27 +++++++++++++++++++++++----
> arch/s390/include/asm/pci_io.h | 6 +++---
> 2 files changed, 26 insertions(+), 7 deletions(-)
>
> diff --git a/arch/s390/include/asm/io.h b/arch/s390/include/asm/io.h
> index 0fbc992d7a5e..f3ef6d4130b3 100644
> --- a/arch/s390/include/asm/io.h
> +++ b/arch/s390/include/asm/io.h
> @@ -58,10 +58,6 @@ static inline void ioport_unmap(void __iomem *p)
> #define pci_iomap_wc pci_iomap_wc
> #define pci_iomap_wc_range pci_iomap_wc_range
>
> -#define memcpy_fromio(dst, src, count) zpci_memcpy_fromio(dst, src, count)
> -#define memcpy_toio(dst, src, count) zpci_memcpy_toio(dst, src, count)
> -#define memset_io(dst, val, count) zpci_memset_io(dst, val, count)
> -
> #define mmiowb() zpci_barrier()
>
> #define __raw_readb zpci_read_u8
> @@ -73,6 +69,10 @@ static inline void ioport_unmap(void __iomem *p)
> #define __raw_writel zpci_write_u32
> #define __raw_writeq zpci_write_u64
>
> +#define memcpy_fromio memcpy_fromio
> +#define memcpy_toio memcpy_toio
> +#define memset_io memset_io
> +
> /* combine single writes by using store-block insn */
> static inline void __iowrite32_copy(void __iomem *to, const void *from,
> size_t count)
> @@ -88,6 +88,25 @@ static inline void __iowrite64_copy(void __iomem *to, const void *from,
> }
> #define __iowrite64_copy __iowrite64_copy
>
> +static inline void memcpy_fromio(void *dst, const volatile void __iomem *src,
> + size_t n)
> +{
> + zpci_memcpy_fromio(dst, src, n);
> +}
> +
> +static inline void memcpy_toio(volatile void __iomem *dst,
> + const void *src, size_t n)
> +{
> + zpci_memcpy_toio(dst, src, n);
> +}
> +
> +static inline void memset_io(volatile void __iomem *dst,
> + int val, size_t count)
> +{
> + zpci_memset_io(dst, val, count);
> +}
> +
> +
> #endif /* CONFIG_PCI */
>
> #include <asm-generic/io.h>
> diff --git a/arch/s390/include/asm/pci_io.h b/arch/s390/include/asm/pci_io.h
> index 2686bee800e3..43a5ea4ee20f 100644
> --- a/arch/s390/include/asm/pci_io.h
> +++ b/arch/s390/include/asm/pci_io.h
> @@ -143,7 +143,7 @@ static inline int zpci_get_max_io_size(u64 src, u64 dst, int len, int max)
>
> static inline int zpci_memcpy_fromio(void *dst,
> const volatile void __iomem *src,
> - unsigned long n)
> + size_t n)
> {
> int size, rc = 0;
>
> @@ -162,7 +162,7 @@ static inline int zpci_memcpy_fromio(void *dst,
> }
>
> static inline int zpci_memcpy_toio(volatile void __iomem *dst,
> - const void *src, unsigned long n)
> + const void *src, size_t n)
> {
> int size, rc = 0;
>
> @@ -187,7 +187,7 @@ static inline int zpci_memcpy_toio(volatile void __iomem *dst,
> }
>
> static inline int zpci_memset_io(volatile void __iomem *dst,
> - unsigned char val, size_t count)
> + int val, size_t count)
> {
> u8 *src = kmalloc(count, GFP_KERNEL);
> int rc;
The code makes sense to me. If I understand Arnd's comment correctly
the wrappers may not be necessary if you don't have the global
prototypes though, right? In this case I think we might want to still
align the parameter types as this seems generally cleaner and the
internal callers already use size_t anyway.
Either way I gave the whole series a quick test on s390x with PCI
devices and all looks good. So feel free to add:
Acked-by: Niklas Schnelle <schnelle@...ux.ibm.com>
Tested-by: Niklas Schnelle <schnelle@...ux.ibm.com>
Powered by blists - more mailing lists