linux-kernel - Re: dma api errors with swiotlb

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: <a78c4100-4f93-d96d-60d1-d965a7769fca@shipmail.org>
Date:   Wed, 4 Sep 2019 15:02:14 +0200
From:   Thomas Hellström (VMware) 
        <thomas_os@...pmail.org>
To:     Christoph Hellwig <hch@...radead.org>
Cc:     "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: dma api errors with swiotlb

On 9/4/19 2:55 PM, Christoph Hellwig wrote:
> On Wed, Sep 04, 2019 at 02:54:26PM +0200, Thomas Hellström (VMware) wrote:
>> On 9/4/19 2:17 PM, Christoph Hellwig wrote:
>>> A call to dma_max_mapping_size() to limit the maximum I/O size solves
>>> that problem.  With the latest kernel that should actually be done
>>> automatically by the SCSI midlayer for you.
>> Hmm, OK. I guess with a sufficient queue depth and many mappings waiting for
>> DMA completion, the SWIOTLB may fill up anyway...
>>
>> I'll see if I can come up with something.
> You are supposed to return SCSI_MLQUEUE_HOST_BUSY in that case,
> which means that the kernel won't send more commands until another
> one completed.

It looks like it does that, although when we send it, the SWIOTLB error 
has already occured and been printed out, and then the sequence starts 
again.

Seems like the most effective way to stop it is to decrease the queue depth.

/Thomas