Alan Cox schrieb: >> [] tty_unthrottle+0x10/0x38 >> [] ppp_sync_receive+0x168/0x170 [ppp_synctty] >> [] handle_minor_recv+0x187/0x1cd [capi] >> [] capi_recv_message+0x1d9/0x24e [capi] > > Really need to see the rest of the call trace to be sure There wasn't more than what I posted. I had six of them, they looked all identical, and all of them ended after the kernel_thread_helper line. >> Turns out the ppp_sync_receive() function (drivers/net/ppp_synctty.c >> line 385ff.) has a comment in front stating: >> >> /* >> * This can now be called from hard interrupt level as well >> * as soft interrupt level or mainline. >> */ > > Which is wrong. The flip_buffer_push -> rx processing path should never > be called from IRQ context and that was fixed for various drivers that > mis-set tty->low_latency, as well as in the PPP rework. The PPP case is > actually unrelated in many was. Might be worth correcting that text then before is misleads someone. >> Opinions? > > See how we got into that code direct from an IRQ path. The expectation of > the tty logic is that it gets processed from work queues either > specifically in driver or via tty_flip_buffer_push when tty->low_latency > = 0 I'm at a loss here. According to all the backtraces: - ppp_sync_receive() was called, as the LD's receive_buf method, via handle_recv_skb() [drivers/isdn/capi/capi.c line 504, inlined] from handle_minor_recv() [drivers/isdn/capi/capi.c line 519] - handle_minor_recv() was called from capi_recv_message() [drivers/isdn/capi/capi.c line 656] - capi_recv_message() was called, as the CAPI application's recv_message method, from recv_handler() [drivers/isdn/capi/kcapi.c line 268] - recv_handler() is never called directly. It's only scheduled via the work queue ap->recv_work from capi_ctr_handle_message() [drivers/isdn/capi/kcapi.c line 349] Even if we don't trust the backtraces, there's not much room for another activation path. So for all I know, the expectation of the tty logic should have been met. The call was indeed processed from a work queue. Why then does mutex_lock() complain? -- Tilman Schmidt E-Mail: tilman@imap.cc Bonn, Germany Diese Nachricht besteht zu 100% aus wiederverwerteten Bits. Ungeöffnet mindestens haltbar bis: (siehe Rückseite)