linux-kernel - Re: [PATCH v9 5/6] cache: Add L2 cache management for Andes AX45MP RISC-V core

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: <20d4d296-14d7-467d-826c-b5c9cdf4599a@app.fastmail.com>
Date:   Wed, 14 Jun 2023 15:10:45 +0200
From:   "Arnd Bergmann" <arnd@...db.de>
To:     Prabhakar <prabhakar.csengg@...il.com>,
        "Conor.Dooley" <conor.dooley@...rochip.com>,
        "Geert Uytterhoeven" <geert+renesas@...der.be>,
        guoren <guoren@...nel.org>,
        "Andrew Jones" <ajones@...tanamicro.com>,
        "Paul Walmsley" <paul.walmsley@...ive.com>,
        "Palmer Dabbelt" <palmer@...belt.com>,
        "Albert Ou" <aou@...s.berkeley.edu>,
        "Samuel Holland" <samuel@...lland.org>,
        linux-riscv@...ts.infradead.org,
        "Christoph Hellwig" <hch@...radead.org>
Cc:     "Rob Herring" <robh+dt@...nel.org>,
        "Krzysztof Kozlowski" <krzysztof.kozlowski+dt@...aro.org>,
        devicetree@...r.kernel.org, linux-kernel@...r.kernel.org,
        Linux-Renesas <linux-renesas-soc@...r.kernel.org>,
        "Biju Das" <biju.das.jz@...renesas.com>,
        "Lad, Prabhakar" <prabhakar.mahadev-lad.rj@...renesas.com>
Subject: Re: [PATCH v9 5/6] cache: Add L2 cache management for Andes AX45MP RISC-V core

On Wed, Jun 14, 2023, at 12:47, Prabhakar wrote:

> +static void ax45mp_dma_cache_inv(phys_addr_t paddr, unsigned long size)
> +{
> +	unsigned long start = (unsigned long)phys_to_virt(paddr);
> +	char cache_buf[2][AX45MP_CACHE_LINE_SIZE];
> +	unsigned long end = start + size;
> +	unsigned long old_start = start;
> +	unsigned long old_end = end;
> +	unsigned long line_size;
> +	unsigned long flags;
> +
> +	if (unlikely(start == end))
> +		return;
> +
> +	line_size = ax45mp_priv.ax45mp_cache_line_size;
> +
> +	memset(&cache_buf, 0x0, sizeof(cache_buf));
> +	start = start & (~(line_size - 1));
> +	end = ((end + line_size - 1) & (~(line_size - 1)));
> +
> +	local_irq_save(flags);
> +	if (unlikely(start != old_start))
> +		memcpy(&cache_buf[0][0], (void *)start, line_size);
> +
> +	if (unlikely(end != old_end))
> +		memcpy(&cache_buf[1][0], (void *)(old_end & (~(line_size - 1))), 
> line_size);
> +
> +	ax45mp_cpu_dcache_inval_range(start, end, line_size);
> +
> +	if (unlikely(start != old_start))
> +		memcpy((void *)start, &cache_buf[0][0], (old_start & (line_size - 
> 1)));
> +
> +	local_irq_restore(flags);
> +}

I'm not quite sure what this does, maybe some comments would help.

This looks like a novel method of preserving partial cache lines
at the beginning (but not the end?) of an unaligned area.

As far as I can tell, most dma_mapping implementations don't
even try to do that at all, but the ones that do take a different
approach by calling _wback_inv() on partial cache lines instead
of calling _inv().

I'd say this does not belong into the low-level operations
here, especially since the ZICBOM variant doesn't do this either.

      Arnd