[PATCH] might_sleep on con_lock (was Re: [openib-general] SDP_CONN_LOCK)
Michael S. Tsirkin
mst at mellanox.co.il
Sun Mar 6 02:38:40 PST 2005
Quoting r. Libor Michalek <libor at topspin.com>:
> Subject: Re: [openib-general] SDP_CONN_LOCK
> > > They do implement exclusive access to the socket, but they implement
> > > exclusive access from both process and irq context, which is why a
> > > semaphore was not used. In interrupt context SDP_CONN_LOCK_BH is used
> > > to lock the connection, look in sdp_cq_event_handler() for it's use,
> > > and in process context SDP_CONN_LOCK is used.
> >
> > I dont really understand how it works.
> > When an interrupt arrives while users != 0, it seems you are
> > calling scheduler().
> > What is sdp_conn_internal_lock doing? I understand it is to be called
> > from interrupt context, but how can it call scheduler() then?
>
> SDP_CONN_LOCK and SDP_CONN_UNLOCK are never called from interrupt
> context, only from process context.
So how about this patch, to make sure we get a stack dump if they are:
Signed-off-by: Michael S. Tsirkin <mst at mellanox.co.il>
Index: sdp_conn.h
===================================================================
--- sdp_conn.h (revision 1953)
+++ sdp_conn.h (working copy)
@@ -477,6 +477,8 @@ static inline void sdp_conn_lock(struct
{
unsigned long flags;
+ might_sleep();
+
spin_lock_irqsave(&conn->lock.slock, flags);
if (conn->lock.users != 0) {
--
MST - Michael S. Tsirkin
More information about the general
mailing list