linux-kernel - Re: [PATCH] USB: OHCI: ohci-sm501: complete URBs in BH context

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <2035bda7-90ce-0ec3-757a-5c2ca8113bf4@roeck-us.net>
Date:   Mon, 6 Aug 2018 08:58:07 -0700
From:   Guenter Roeck <linux@...ck-us.net>
To:     Christoph Hellwig <hch@....de>
Cc:     Alan Stern <stern@...land.harvard.edu>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        linux-usb@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] USB: OHCI: ohci-sm501: complete URBs in BH context

On 08/06/2018 01:33 AM, Christoph Hellwig wrote:
> On Sun, Aug 05, 2018 at 02:38:22PM -0700, Guenter Roeck wrote:
>> AFAICS it used to be interrupt tolerant for all but x86 up to commit
>> 6894258eda ("dma-mapping: consolidate dma_{alloc,free}_{attrs,coherent}").
>> A quick test shows that the warning is indeed not seen if I run my test
>> on v3.18.y.
>>
>> You would have to ask Christoph why it is now interrupt-intolerant for all
>> architectures.
> 
> interrupt-tolerant actually is a very odd wording.  x86 itself (at least
> unless using an iommu) actually is fine with calling dma_free_* with
> interrupts disabled, but many other architectures are not.  For many
> architectures that are not cache coherent we'll have to manipulale
> the kernel page tables when freeing coherent memory, which we absolutely
> can't do from irq context.  And as usual in the kernel we try to enforce
> the same rules on everyone to allow for portable code.
> 
> Also except for the odd USB use cases that abuses dma_alloc_coherent
> for the bounce buffers in device local memory you are doing something
> wrong if you call dma_alloc*/dma_free* anywhere but during device
> initialization and removal.  These are slow path interfaces for
> allocating memory for things like descriptors and similar.  Your fast
> path should be using dma_map*/dma_unmap*.
> 

FWIW, that isn't "my" code. I just had the impunity to test it.

Cheers,
Guenter