netdev - Re: Bug in cadence macb driver

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]

Date:   Thu, 27 Oct 2016 19:16:39 +1000
From:   Steve Bennett <steveb@...kware.net.au>
To:     Nicolas Ferre <nicolas.ferre@...el.com>
Cc:     netdev@...r.kernel.org, Cyrille Pitchen <cyrille.pitchen@...el.com>
Subject: Re: Bug in cadence macb driver


> On 27 Oct 2016, at 7:05 PM, Nicolas Ferre <nicolas.ferre@...el.com> wrote:
> 
> Le 27/10/2016 à 09:22, Steve Bennett a écrit :
>> Hi,
>> 
>> We are seeing the following problem in the cadence macb driver.
>> 
>> BUG: scheduling while atomic: kworker/0:1/44/0x00000002
>> Modules linked in: 8021q of_serial beacon_sigproc io_processor emsattr ems_dma_fifo xaxi_dma libgpioreg leds_gpio
>> CPU: 0 PID: 44 Comm: kworker/0:1 Not tainted 4.4.0 #1
>> Hardware name: Xilinx Zynq Platform
>> Workqueue: events macb_tx_error_task
>> [<c0016a18>] (unwind_backtrace) from [<c0012ad4>] (show_stack+0x10/0x14)
>> [<c0012ad4>] (show_stack) from [<c01b089c>] (dump_stack+0x88/0xd8)
>> [<c01b089c>] (dump_stack) from [<c008e94c>] (__schedule_bug+0x48/0x60)
>> [<c008e94c>] (__schedule_bug) from [<c03592d4>] (__schedule+0x80/0x4c4)
>> [<c03592d4>] (__schedule) from [<c0359968>] (schedule+0xac/0xd4)
>> [<c0359968>] (schedule) from [<c035c284>] (schedule_hrtimeout_range_clock+0xc0/0xf4)
>> [<c035c284>] (schedule_hrtimeout_range_clock) from [<c035bebc>] (usleep_range+0x44/0x48)
>> [<c035bebc>] (usleep_range) from [<c025ec48>] (macb_tx_error_task+0xa0/0x270)
>> [<c025ec48>] (macb_tx_error_task) from [<c0035b6c>] (process_one_work+0x1b8/0x2f0)
>> [<c0035b6c>] (process_one_work) from [<c0035fb4>] (worker_thread+0x2e4/0x3f0)
>> [<c0035fb4>] (worker_thread) from [<c003ac94>] (kthread+0xdc/0xf0)
>> [<c003ac94>] (kthread) from [<c000f698>] (ret_from_fork+0x14/0x3c)
>> 
>> Here we are running at 10M half duplex, so tx is slow.
>> The problem was introduced in e4bfd971b where a spinlock is taken before
> 
> I can't find this commit ID. Can you please give the one on Linus' tree
> together with the commit subject?

Ahh yes. My apologies. Here it is in Linus' tree

commit 02c958dd344643259212e50f04f0ec90a3ace34c
Author: Cyrille Pitchen <cyrille.pitchen@...el.com>
Date:   Fri Dec 12 13:26:44 2014 +0100

    net/macb: add TX multiqueue support for gem

> 
> Thanks,
> 
>> calling macb_halt_tx() which may then sleep waiting for the current packet to finish
>> transmitting.
>> 
>> We don't need the spinlock on our platform since we don't have multiple queues, but
>> this should be fixed properly in the general case.
>> 
>> Cheers,
>> Steve
>> 
>> --
>> µWeb: Embedded Web Framework - http://uweb.workware.net.au/
>> WorkWare Systems Pty Ltd
>> W: www.workware.net.au      P: +61 434 921 300
>> E: steveb@...kware.net.au
>> 
>> 
>> 
>> 
>> 
>> 
> 
> 
> -- 
> Nicolas Ferre