linux-kernel - Re: [4.0-rc+] WARNING: CPU: 0 PID: 1 at ./drivers/dma/dmaengine.c:863 dma_async_device

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]

Date:	Thu, 09 Apr 2015 06:31:13 -0400
From:	Peter Hurley <peter@...leysoftware.com>
To:	Maxime Ripard <maxime.ripard@...e-electrons.com>
CC:	Vinod Koul <vinod.koul@...el.com>, Felipe Balbi <balbi@...com>,
	Laurent Pinchart <laurent.pinchart@...asonboard.com>,
	Linux kernel <linux-kernel@...r.kernel.org>
Subject: Re: [4.0-rc+] WARNING: CPU: 0 PID: 1 at ./drivers/dma/dmaengine.c:863
 dma_async_device_register+0xe0/0x540()

On 04/09/2015 03:09 AM, Maxime Ripard wrote:
> On Wed, Apr 08, 2015 at 12:07:14PM -0400, Peter Hurley wrote:
>> On 04/08/2015 11:59 AM, Maxime Ripard wrote:
>>> On Wed, Apr 08, 2015 at 11:53:33AM -0400, Peter Hurley wrote:
>>>> On 03/05/2015 11:12 AM, Vinod Koul wrote:
>>>>> On Thu, Mar 05, 2015 at 10:04:21AM -0500, Peter Hurley wrote:
>>>>>>> First boot of 4.0-rc+ gave me [1] on a Beaglebone Black due to
>>>>>>>
>>>>> The warning is intentional to get driver fixed and give the right behaviour
>>>>>
>>>>> Felipe had sent a patch for this but that one needs an update
>>>>
>>>> Vinod,
>>>>
>>>> Felipe's patch never made it to mainline, and this warning is 
>>>> still happening on 4.0-rc7 so please revert for 4.0-final.
>>>
>>> That patch isn't introducing any regression. I fail to see how that
>>> justifies a revert so late in the release cycle.
>>
>> Arguably it never should have been introduced in the first place
> 
> Upon which arguments? So far, I've seen none but "my boot logs look
> bad now".

1. Every subsystem has drivers that don't fully conform to a desired
   interface. If even a small fraction did this, everyone's logs would
   be cluttered with this garbage. For that matter, if just the serial
   subsystem alone did this, logs would be awash in warnings.

2. Now _every_ dmaengine driver "fix" for this will need to be pushed
   to -stable.

>> and this was at least known since Mar 5 (and likely earlier);
>> arguing that it's late in the cycle is a bit disingenuous.


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/