aspeed-video WARN_ON in dma_free_attrs with 5.2

[Jae Hyun Yoo]

On 7/8/2019 9:26 AM, Jae Hyun Yoo wrote:
> On 7/7/2019 9:15 PM, Joel Stanley wrote:
>> I am running with Jae's fixes from dev-5.1 applied to 5.2.. I see this
>> on boot, early on as userspace is coming up. The host is not running.
>>
>>   WARNING: CPU: 0 PID: 140 at kernel/dma/mapping.c:281 
>> dma_free_attrs+0xd0/0xe0
>>
>> The driver is calling dma_free_attrs from aspeed_video_release. The
>> comment in dma_free_attrs says:
>>
>>          /*
>>           * On non-coherent platforms which implement DMA-coherent 
>> buffers via
>>           * non-cacheable remaps, ops->free() may call vunmap(). Thus 
>> getting
>>           * this far in IRQ context is a) at risk of a BUG_ON() or 
>> trying to
>>           * sleep on some machines, and b) an indication that the 
>> driver is
>>           * probably misusing the coherent API anyway.
>>           */
>>          WARN_ON(irqs_disabled());
>>
>> Which suggests aspeed-video might be at fault.
>>
>> I can reproduce it in qemu. It does not reproduce with vanilla 5.2,
>> which does not contain Jae's various fixes.
> 
> Hi Joel,
> 
> Thanks for reporting the issue.
> I'll check it on dev-5.2 and will share the result.

Hi Joel,

I root caused the issue. That is caused by calling DMA buffer alloc/free
APIs in an interrupt disabled context. It cannot be seen in upstream
linux tree because a patch is slightly different.

I tested it on dev-5.2 branch in git://github.com/shenki/linux.
In this repo, the commit 233d753bad072caee5dbb7325158a086c9e9dcf4
should be replaced with an upstreamed version. You can cherry pick the
upstreamed version from:

https://lists.ozlabs.org/pipermail/linux-aspeed/2019-June/001793.html

or from:

commit 9698ed4d4a2993ce54b9f7d71a2891e972caa117 in next-20190708
branch of upstream linux tree.

Please let me know if you need an incremental patch on top of the latest
git://github.com/shenki/linux dev-5.2 branch instead of cherry-picking
above options.

Thanks,
Jae