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: <CAPDyKFoQsf89NeX28ms7FtM0QWNqYQ5xtt2=+G1JNCVi2z9=dg@mail.gmail.com>
Date: Tue, 22 Oct 2024 14:42:39 +0200
From: Ulf Hansson <ulf.hansson@...aro.org>
To: Aurelien Jarno <aurelien@...el32.net>
Cc: William Qiu <william.qiu@...rfivetech.com>, 
	"open list:RISC-V MISC SOC SUPPORT" <linux-riscv@...ts.infradead.org>, Jaehoon Chung <jh80.chung@...sung.com>, 
	Sam Protsenko <semen.protsenko@...aro.org>, 
	"open list:SYNOPSYS DESIGNWARE MMC/SD/SDIO DRIVER" <linux-mmc@...r.kernel.org>, open list <linux-kernel@...r.kernel.org>, 
	Ron Economos <re@...z.net>, Jing Luo <jing@...g.rocks>, stable@...r.kernel.org, 
	Adam Green <greena88@...il.com>, Shawn Lin <shawn.lin@...k-chips.com>, sydarn@...ton.me, 
	Arnd Bergmann <arnd@...db.de>
Subject: Re: [PATCH] mmc: dw_mmc: take SWIOTLB memory size limitation into account

+ Adam, Arnd, Shawn-Lin, sydarn


On Sun, 20 Oct 2024 at 16:30, Aurelien Jarno <aurelien@...el32.net> 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>

Thanks for working on this! Looks like we have managed to mess things
up. Besides the issue that you have been working on to fix, apparently
there seems to be another one too [1].

Unfortunately, $subject patch doesn't seem to fix the problem in [1],
as has been reported by Adam.

I have looped in some more people to this thread, hopefully we agree
on how this should be fixed properly. Otherwise, I tend to say that we
should simply revert the offending commit and start over.

Kind regards
Uffe

[1]
https://lore.kernel.org/all/CAC8uq=Ppnmv98mpa1CrWLawWoPnu5abtU69v-=G-P7ysATQ2Pw@mail.gmail.com/

> ---
>  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;
> --
> 2.45.2
>