linux-kernel - Re: [PATCH] mmc: dw_mmc: take SWIOTLB memory size limitation into account

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: <63780c938a9d2b640b3ef8c2c577383b@jing.rocks>
Date: Tue, 22 Oct 2024 00:26:15 +0900
From: Jing Luo <jing@...g.rocks>
To: Aurelien Jarno <aurelien@...el32.net>
Cc: William Qiu <william.qiu@...rfivetech.com>,
 linux-riscv@...ts.infradead.org, Jaehoon Chung <jh80.chung@...sung.com>, Ulf
 Hansson <ulf.hansson@...aro.org>, Sam Protsenko
 <semen.protsenko@...aro.org>, linux-mmc@...r.kernel.org,
 linux-kernel@...r.kernel.org, Ron Economos <re@...z.net>,
 stable@...r.kernel.org
Subject: Re: [PATCH] mmc: dw_mmc: take SWIOTLB memory size limitation into
 account

On 2024-10-20 23:29, Aurelien Jarno wrote:
> The Synopsys DesignWare mmc controller on the JH7110 SoC
> (dw_mmc-starfive.c driver) is using a 32-bit IDMAC address bus width,
> and thus requires the use of SWIOTLB.
> 
> The commit 8396c793ffdf ("mmc: dw_mmc: Fix IDMAC operation with pages
> bigger than 4K") increased the max_seq_size, even for 4K pages, causing
> "swiotlb buffer is full" to happen because swiotlb can only handle a
> memory size up to 256kB only.
> 
> Fix the issue, by making sure the dw_mmc driver doesn't use segments
> bigger than what SWIOTLB can handle.
> 
> Reported-by: Ron Economos <re@...z.net>
> Reported-by: Jing Luo <jing@...g.rocks>
> Fixes: 8396c793ffdf ("mmc: dw_mmc: Fix IDMAC operation with pages 
> bigger than 4K")
> Cc: stable@...r.kernel.org
> Signed-off-by: Aurelien Jarno <aurelien@...el32.net>

Feel free to add:

Tested-by: Jing Luo <jing@...g.rocks>

This patch not only fixes the kernel log spam by dwmmc_starfive 
reporting "swiotlb buffer is full", but also seems to have fixed a 
serious bug that causes data corruption on emmc (as I reported to Debian 
[1]), which at least can be observed on both Visionfive 2 and Star64 
boards. To add a cherry on the top, with this patch applied, I see 
massive performance improvement (sequential rw speed) on emmc: with a 
quick-and-dirty test using `dd bs=1M`, on Visionfive 2, it goes from 
28MB/s to 42MB/s (+50%); on Star64, it goes from 13MB/s to 46MB/s 
(+253%).

[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1085425

Thanks & cheers,

Jing Luo

> ---
>  drivers/mmc/host/dw_mmc.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/mmc/host/dw_mmc.c b/drivers/mmc/host/dw_mmc.c
> index 41e451235f637..dc0d6201f7b73 100644
> --- a/drivers/mmc/host/dw_mmc.c
> +++ b/drivers/mmc/host/dw_mmc.c
> @@ -2958,7 +2958,8 @@ static int dw_mci_init_slot(struct dw_mci *host)
>  		mmc->max_segs = host->ring_size;
>  		mmc->max_blk_size = 65535;
>  		mmc->max_req_size = DW_MCI_DESC_DATA_LENGTH * host->ring_size;
> -		mmc->max_seg_size = mmc->max_req_size;
> +		mmc->max_seg_size =
> +		    min_t(size_t, mmc->max_req_size, 
> dma_max_mapping_size(host->dev));
>  		mmc->max_blk_count = mmc->max_req_size / 512;
>  	} else if (host->use_dma == TRANS_MODE_EDMAC) {
>  		mmc->max_segs = 64;