linux-kernel - Re: [PATCH] swiotlb: suppress warning when __GFP

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]

Date:   Tue, 02 Jan 2018 15:39:51 +0000
From:   Chris Wilson <chris@...is-wilson.co.uk>
To:     Christian König         
        <ckoenig.leichtzumerken@...il.com>, imirkin@...m.mit.edu,
        efault@....de, michel@...nzer.net, konrad.wilk@...cle.com,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH] swiotlb: suppress warning when __GFP_NOWARN is set v2

Quoting Christian König (2018-01-02 12:13:58)
> TTM tries to allocate coherent memory in chunks of 2MB first to improve
> TLB efficiency and falls back to allocating 4K pages if that fails.
> 
> Suppress the warning when the 2MB allocations fails since there is a
> valid fall back path.
> 
> v2: suppress warnings from swiotlb_tbl_map_single as well
> 
> Signed-off-by: Christian König <christian.koenig@....com>
> Reported-by: Mike Galbraith <efault@....de>
> Bug: https://bugs.freedesktop.org/show_bug.cgi?id=104082
> CC: stable@...r.kernel.org
> ---
> @@ -989,7 +1002,8 @@ swiotlb_map_sg_attrs(struct device *hwdev, struct scatterlist *sgl, int nelems,
>                 if (swiotlb_force == SWIOTLB_FORCE ||
>                     !dma_capable(hwdev, dev_addr, sg->length)) {
>                         phys_addr_t map = map_single(hwdev, sg_phys(sg),
> -                                                    sg->length, dir, attrs);
> +                                                    sg->length, dir, attrs,
> +                                                    true);

This keeps the warning for dma_map_sg(), so seems quite ineffective.

>                         if (map == SWIOTLB_MAP_ERROR) {
>                                 /* Don't panic here, we expect map_sg users
>                                    to do proper error handling. */

And counter to the suggestion here?
-Chris