[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