netdev - capi.c calls receive_buf with interrupts disabled (was: N_PPP_SYNC ldisc BUG: sleeping function called from invalid context)

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]

Message-ID: <4AC3E6AC.3000107@imap.cc>
Date:	Thu, 01 Oct 2009 01:15:56 +0200
From:	Tilman Schmidt <tilman@...p.cc>
To:	Jarek Poplawski <jarkao2@...il.com>
CC:	Alan Cox <alan@...rguk.ukuu.org.uk>, linux-kernel@...r.kernel.org,
	netdev@...r.kernel.org, Alan Cox <alan@...ux.intel.com>,
	Michael Buesch <mb@...sch.de>,
	isdn4linux <isdn4linux@...tserv.isdn4linux.de>
Subject: capi.c calls receive_buf with interrupts disabled (was: N_PPP_SYNC
 ldisc BUG: sleeping function called from invalid context)

Jarek Poplawski schrieb:
> Tilman Schmidt wrote, On 09/30/2009 08:55 PM:
[...]
>> - 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?
> 
> Hmm... capi_recv_message() calls handle_minor_recv() under
> spin_lock_irqsave(), doesn't it?

Well spotted. Indeed it does. That explains it, of course.

The spinlock in question was added by:

commit 053b47ff249b9e0a634dae807f81465205e7c228
Author: Michael Buesch <mb@...sch.de>
Date:   Mon Feb 12 00:53:26 2007 -0800

    [PATCH] Workaround CAPI subsystem locking issue
    
    I think the following patch should go into the kernel, until the ISDN/CAPI
    guys create the real fix for this issue.
     
    The issue is a concurrency issue with some internal CAPI data structure
    which can crash the kernel.

    On my FritzCard DSL with the AVM driver it crashes about once a day without
    this workaround patch.  With this workaround patch it's rock-stable (at
    least on UP, but I don't see why this shouldn't work on SMP as well.  But
    maybe I'm missing something.)
    
    This workaround is kind of a sledgehammer which inserts a global lock to
    wrap around all the critical sections.  Of course, this is a scalability
    issue, if you have many ISDN/CAPI cards.  But it prevents a crash.  So I
    vote for this fix to get merged, until people come up with a better
    solution.  Better have a stable kernel that's less scalable, than a
    crashing and useless kernel.
    
So let's cc the author of that patch, and also the good people on the
isdn4linux developer mailing list ...

Any ideas for a fix?

Thanks,
Tilman

-- 
Tilman Schmidt                    E-Mail: tilman@...p.cc
Bonn, Germany
Diese Nachricht besteht zu 100% aus wiederverwerteten Bits.
Ungeöffnet mindestens haltbar bis: (siehe Rückseite)


Download attachment "signature.asc" of type "application/pgp-signature" (255 bytes)