Re: DEBUG_LOCKS_WARN_ON(in_interrupt()) triggering in socket code

2015-08-21 Thread Michal Kubecek
On Fri, Aug 21, 2015 at 03:42:33PM +0200, Jason A. Donenfeld wrote: > Ahhh, interesting, so it turns out you can't do a number of things > with a read_lock_bh held, because it increases the softirq count. > Mystery solved. You must not do anything that can sleep (like taking a mutex) while holding

Re: DEBUG_LOCKS_WARN_ON(in_interrupt()) triggering in socket code

2015-08-21 Thread Jason A. Donenfeld
Ahhh, interesting, so it turns out you can't do a number of things with a read_lock_bh held, because it increases the softirq count. Mystery solved. -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majord...@vger.kernel.org More majordomo info at htt

Re: DEBUG_LOCKS_WARN_ON(in_interrupt()) triggering in socket code

2015-08-21 Thread Jason A. Donenfeld
Bueller? ... Bueller? On Thu, Aug 20, 2015 at 2:39 AM, Jason A. Donenfeld wrote: > Hi folks, > > In setting up a socket, there are two functions I make use of that in > turn wind up calling static_key_slow_inc: setup_udp_tunnel_sock and > sk_set_memalloc. These both make use of static_key_slow_in

DEBUG_LOCKS_WARN_ON(in_interrupt()) triggering in socket code

2015-08-19 Thread Jason A. Donenfeld
Hi folks, In setting up a socket, there are two functions I make use of that in turn wind up calling static_key_slow_inc: setup_udp_tunnel_sock and sk_set_memalloc. These both make use of static_key_slow_inc because they selectively enable certain important code paths. This is all fine, except it