Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
Subject: Re: [PATCH] USB: OHCI: ohci-sm501: complete URBs in BH context
To:     Christoph Hellwig <hch@lst.de>
Cc:     Alan Stern <stern@rowland.harvard.edu>,
        Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
        linux-usb@vger.kernel.org, linux-kernel@vger.kernel.org
References: <Pine.LNX.4.44L0.1808051424440.29532-100000@netrider.rowland.org>
 <55fffb30-1388-af6a-70a6-cb738dab062f@roeck-us.net>
 <20180806083322.GA31637@lst.de>
From:   Guenter Roeck <linux@roeck-us.net>
Message-ID: <2035bda7-90ce-0ec3-757a-5c2ca8113bf4@roeck-us.net>
Date:   Mon, 6 Aug 2018 08:58:07 -0700
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101
 Thunderbird/52.9.1
MIME-Version: 1.0
In-Reply-To: <20180806083322.GA31637@lst.de>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

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