linux-kernel - Re: [PATCH] arc: Hardcode ARCH_DMA_MINALIGN to max line length we may have

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

Message-ID: <8cf0a368-4912-e243-2039-32ee93e96c21@synopsys.com>
Date:   Tue, 18 Jul 2017 08:36:51 -0700
From:   Vineet Gupta <Vineet.Gupta1@...opsys.com>
To:     Alexey Brodkin <alexey.brodkin@...il.com>,
        "linux-snps-arc@...ts.infradead.org" 
        <linux-snps-arc@...ts.infradead.org>
CC:     "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "Vineet Gupta" <Vineet.Gupta1@...opsys.com>,
        Alexey Brodkin <Alexey.Brodkin@...opsys.com>
Subject: Re: [PATCH] arc: Hardcode ARCH_DMA_MINALIGN to max line length we may
 have

On 07/18/2017 07:31 AM, Alexey Brodkin wrote:
> Current implementation relies on L1 line length which might easily
> be smaller than L2 line (which is usually the case BTW).
>
> Imagine this typical case: L2 line is 128 bytes while L1 line is
> 64-bytes. Now we want to allocate small buffer and later use it for DMA
> (consider IOC is not available).
>
> kmalloc() allocates small KMALLOC_MIN_SIZE-sized, KMALLOC_MIN_SIZE-aligned
> That way if buffer happens to be aligned to L1 line and not L2 line we'll be
> flushing and invalidating extra portions of data from L2 which will cause
> cache coherency issues.
>
> And since KMALLOC_MIN_SIZE is bound to ARCH_DMA_MINALIGN the fix could
> be simple - set ARCH_DMA_MINALIGN to the largest cache line we may ever
> get. As of today neither L1 of ARC700 and ARC HS38 nor SLC might not be
> longer than 128 bytes.

The patch itself makes sense - but is this preventive / code review thing or does 
it really fix soem issue at your end ?

> Signed-off-by: Alexey Brodkin <abrodkin@...opsys.com>
> ---
>   arch/arc/include/asm/cache.h | 3 ++-
>   1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/arch/arc/include/asm/cache.h b/arch/arc/include/asm/cache.h
> index 19ebddffb279..e45eac8c5980 100644
> --- a/arch/arc/include/asm/cache.h
> +++ b/arch/arc/include/asm/cache.h
> @@ -47,7 +47,8 @@
>   	: "r"(data), "r"(ptr));		\
>   })
>   
> -#define ARCH_DMA_MINALIGN      L1_CACHE_BYTES
> +/* Largest line length for either L1 or L2 is 128 bytes */
> +#define ARCH_DMA_MINALIGN      128
>   
>   extern void arc_cache_init(void);
>   extern char *arc_cache_mumbojumbo(int cpu_id, char *buf, int len);