[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CA+55aFyte5bC4703QVruVL3y_DV3Y6CbRPpXo=OkyRiJKtoMTA@mail.gmail.com>
Date: Thu, 2 Jan 2014 17:00:06 -0800
From: Linus Torvalds <torvalds@...ux-foundation.org>
To: David Miller <davem@...emloft.net>
Cc: Samuel Ortiz <samuel@...tiz.org>,
Network Development <netdev@...r.kernel.org>
Subject: Re: IrDA woes..
On Thu, Jan 2, 2014 at 4:05 PM, David Miller <davem@...emloft.net> wrote:
>
> I'm worried that mixing hardIRQ locking (via the direct calls to
> skb_dequeue() et al.) with explicit softIRQ locking will make lockdep
> complain.
You're probably right. I don't see how to do it right, though. lockdep
(or maybe it's DEBUG_ATOMIC_SLEEP or whatever) definitely complains
about the "enable softirq's with hardirqs disabled" part, and the way
the queueing is set up in irda, I don't see how else to do it.
Unless it would be ok to only re-send the oldest packet, not all of
them. And thus get rid of the loop entirely. But with the obvious lack
of testing irda is getting, that kind of change sounds like a really
bad idea.
The warning is, in case you care:
WARNING: CPU: 2 PID: 0 at kernel/softirq.c:156 local_bh_enable+0x62/0x90()
Call Trace:
dev_queue_xmit
irlap_queue_xmit
irlap_send_i_frame
irlap_resend_rejected_frames
irlap_state_nrm_s
irlap_do_event
irlap_driver_rcv
__netif_receive_skb_core
and without the _irqsave() at least that part is fine. But no, I
didn't try it with lockdep, and I think you're right that it would
break.
Oh well. Since I can't seem to get my test-case to work anyway, I
guess it doesn't much matter..
Linus
--
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
Powered by blists - more mailing lists