[lkml]   [1998]   [Aug]   [27]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: Linux 2.1.118 SMP problem

    On Wed, 26 Aug 1998, Alan Cox wrote:
    > I can see this deadlock for 2 or more CPUs in the sunrpc code
    > Its
    > CPU #0
    > nfs->sunrpc->udp_sendmsg->lock_sock->copying
    > irq,bh
    > net_bh->udp_recv->rpc callback->sk_recv_datagram-lock_sock => Deadlock

    If the socket is locked, then it shouldn't call udp_recv, but put the new
    datagram on the backlog instead.

    > Im not sure why it should occur SMP only or if its the one you see, but that
    > does look like a deadlock to me. The lock_sock code also claims its
    > 'a very broken bottom half synchronization mechanism' which worries me
    > even more.

    The lock_sock() code works, it's just fairly inefficient on SMP (it's
    really effcient on UP). The main cause of inefficiency is that the "socket
    locked" case really has to wait for all bh's right now, simply because it
    doesn't know which bh (and when) is being in the critical region. So it
    does a "bh_synchronize()" even though that is potentially _way_ too much
    synchronization (it may end up waiting for a timer bh to run, even though
    the timer bh doesn't actually touch the socket at all).

    So it's really a granularity issue rather than a correctness issue.

    IF the NFS queueing really has the deadlock you point out, it should
    certainly be a deadlock on UP too. It may be that it only shows up on SMP
    for some magic timing reason rather than anything else.


    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    Please read the FAQ at

     \ /
      Last update: 2005-03-22 13:44    [W:0.019 / U:299.548 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site