linux-kernel - Re: [RFC PATCH] usb: gadget: f_tcm: Added DMA32 flag while allocation of command buffer

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] [day] [month] [year] [list]

Message-ID: <20191125163111.GB21800@char.us.oracle.com>
Date:   Mon, 25 Nov 2019 11:31:11 -0500
From:   Konrad Rzeszutek Wilk <konrad.wilk@...cle.com>
To:     Jayshri Dajiram Pawar <jpawar@...ence.com>
Cc:     Roger Quadros <rogerq@...com>, Peter Chen <peter.chen@....com>,
        "linux-usb@...r.kernel.org" <linux-usb@...r.kernel.org>,
        "gregkh@...uxfoundation.org" <gregkh@...uxfoundation.org>,
        "felipe.balbi@...ux.intel.com" <felipe.balbi@...ux.intel.com>,
        "heikki.krogerus@...ux.intel.com" <heikki.krogerus@...ux.intel.com>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "jbergsagel@...com" <jbergsagel@...com>,
        "nsekhar@...com" <nsekhar@...com>, "nm@...com" <nm@...com>,
        Rahul Kumar <kurahul@...ence.com>,
        Pawel Laszczak <pawell@...ence.com>,
        Sanket Parmar <sparmar@...ence.com>,
        "iommu@...ts.linux-foundation.org" <iommu@...ts.linux-foundation.org>
Subject: Re: [RFC PATCH] usb: gadget: f_tcm: Added DMA32 flag while
 allocation of command buffer

. massive snip..
> > > Why is swiotlb buffer getting full? How much is it on your system?
> 
> On our system swiotlb max mapping size is 256KB.
> UASP receive data state tries to queue and map buffer of length 524288 (512KB), which is greater than 256KB that's why swiotlb buffer is getting full.

What is the reason for the UASP not being able to break the buffer in say two
256KB sg entries?

> 
> > > Are you sure that dma_unmap is happening on requests that complete?
> > else we'll just keep hogging the swiotlb buffer.
> 
> Yes, dma_unmap is happening on requests that complete.
> 
> I could map buffer of length 512KB with  IO_TLB_SEGSIZE changed to 256.
> With this max mapping size is increased to  256*2048 = 512KB.

If we go this route (which I rather dislike as this is a workaround, because
what if the next time there is 1MB buffer? Do we keep on increasing this?) - then
this should be dynamic and an option on the 'swiotlb' command line.