netdev - Re: [PATCH RFC] spinlock: split out debugging check from spin_lock

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:	Fri, 19 Apr 2013 10:38:02 +0200
From:	Ingo Molnar <mingo@...nel.org>
To:	Bart Van Assche <bvanassche@....org>
Cc:	Neil Horman <nhorman@...driver.com>,
	David Miller <davem@...emloft.net>, netdev@...r.kernel.org,
	Ingo Molnar <mingo@...hat.com>,
	Peter Zijlstra <a.p.zijlstra@...llo.nl>,
	Thomas Gleixner <tglx@...utronix.de>
Subject: Re: [PATCH RFC] spinlock: split out debugging check from
 spin_lock_mutex


* Bart Van Assche <bvanassche@....org> wrote:

> WARNING: at kernel/mutex.c:313 __mutex_unlock_slowpath+0x157/0x160()
> Pid: 181, comm: kworker/0:1H Tainted: G           O 3.9.0-rc6-debug+ #1
> Call Trace:
> <IRQ>  [<ffffffff8103c3ef>] warn_slowpath_common+0x7f/0xc0
> [<ffffffff8103c44a>] warn_slowpath_null+0x1a/0x20
> [<ffffffff81432047>] __mutex_unlock_slowpath+0x157/0x160
> [<ffffffff8143205e>] mutex_unlock+0xe/0x10
> [<ffffffff8136d031>] netpoll_poll_dev+0x111/0x9a0
> [<ffffffff81345f32>] ? __alloc_skb+0x82/0x2a0
> [<ffffffff8136dac5>] netpoll_send_skb_on_dev+0x205/0x3b0
> [<ffffffff8136e00a>] netpoll_send_udp+0x28a/0x3a0
> [<ffffffffa0524843>] ? write_msg+0x53/0x110 [netconsole]
> [<ffffffffa05248bf>] write_msg+0xcf/0x110 [netconsole]
> [<ffffffff8103d7f1>] call_console_drivers.constprop.16+0xa1/0x120
> [<ffffffff8103e848>] console_unlock+0x3f8/0x450
> [<ffffffff8103ecce>] vprintk_emit+0x1ee/0x510
> [<ffffffff812d1f2c>] dev_vprintk_emit+0x5c/0x70
> [<ffffffff810ff047>] ? mempool_free_slab+0x17/0x20

I *really* think that using a mutex from a low level debug interface like netpoll 
is a mistake. We want such interfaces to be as atomic and as self-contained as 
possible: using spinlocks, which could possibly be converted to raw spinlocks, 
etc.

mutexes should be used when there's an expectation of possibly long blocking time. 
That's not really the case for netpoll, we either are able to generate the skb 
right then and send it off, or we are in trouble, right?

Thanks,

	Ingo
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html