[Openib-windows] a patch for one case of a troublesome using of fast mutexes

[Leonid Keller]

Hi Fab,

I'm sending you a patch, that gives a particular solution to one case of
using fast mutexes, which increase IRQL and prevent using of
AllocateBuffer .

To remind:

> > > I come across the following problem: implementation of

> > > cl_mutex_acquire() via Fast Mutexes causes all the code 

> in critical 

> > > section to work at APC_LEVEL.

> > > 

> > > The first case i saw, was at the start-up of IpoIb driver,

> > which takes

> > > mutex in __ipoib_pnp_cb and makes all MTHCA driver control

> > verbs to work

> > > at APC_LEVEL, which is troublesome.

> > > (e.g., create_cq calls AllocateCommonBuffer, which requires 

> > > PASSIVE_LEVEL).

I've done that as you once suggested - by using usual mutexes (instead
of cl_mutex) in the file in question.

 
 
Index: E:/svn.openib/gen1/trunk/ulp/ipoib/kernel/ipoib_adapter.h
===================================================================
--- E:/svn.openib/gen1/trunk/ulp/ipoib/kernel/ipoib_adapter.h (revision
230)
+++ E:/svn.openib/gen1/trunk/ulp/ipoib/kernel/ipoib_adapter.h (working
copy)
@@ -161,9 +161,7 @@
  uint8_t     mcast_array_size;
 
  cl_qpool_t    item_pool;
-
- cl_mutex_t    mutex;
-
+ KMUTEX     mutex;
  cl_vector_t    ip_vector;
 
  cl_perf_t    perf;

 
Index: E:/svn.openib/gen1/trunk/ulp/ipoib/kernel/ipoib_adapter.c
===================================================================
--- E:/svn.openib/gen1/trunk/ulp/ipoib/kernel/ipoib_adapter.c (revision
230)
+++ E:/svn.openib/gen1/trunk/ulp/ipoib/kernel/ipoib_adapter.c (working
copy)
@@ -234,7 +234,7 @@
   * between destruction and AL callbacks (PnP, Query, Destruction).
   * The lock provides protection
   */
- cl_mutex_acquire( &p_adapter->mutex );
+ KeWaitForMutexObject( &p_adapter->mutex, Executive, KernelMode, FALSE,
NULL );
  cl_obj_lock( &p_adapter->obj );
  p_adapter->state = IB_PNP_PORT_REMOVE;
 
@@ -247,7 +247,7 @@
 
  cl_obj_unlock( &p_adapter->obj );
 
- cl_mutex_release( &p_adapter->mutex );
+ KeReleaseMutex( &p_adapter->mutex, FALSE );
 
  cl_obj_destroy( &p_adapter->obj );
 
@@ -263,7 +263,6 @@
  cl_spinlock_construct( &p_adapter->send_stat_lock );
  cl_spinlock_construct( &p_adapter->recv_stat_lock );
  cl_qpool_construct( &p_adapter->item_pool );
- cl_mutex_construct( &p_adapter->mutex );
  cl_vector_construct( &p_adapter->ip_vector );
 
  cl_perf_construct( &p_adapter->perf );
@@ -315,13 +314,7 @@
   return IB_ERROR;
  }
 
- cl_status = cl_mutex_init( &p_adapter->mutex );
- if( cl_status != CL_SUCCESS )
- {
-  IPOIB_TRACE_EXIT( IPOIB_DBG_ERROR,
-   ("cl_mutex_init returned %s\n", cl_status_text[cl_status]) );
-  return IB_ERROR;
- }
+ KeInitializeMutex( &p_adapter->mutex, 0 );
 
  /* We manually manage the size and capacity of the vector. */
  cl_status = cl_vector_init( &p_adapter->ip_vector, 0,
@@ -463,7 +456,6 @@
  cl_qpool_destroy( &p_adapter->item_pool );
  cl_spinlock_destroy( &p_adapter->recv_stat_lock );
  cl_spinlock_destroy( &p_adapter->send_stat_lock );
- cl_mutex_destroy( &p_adapter->mutex );
  cl_obj_deinit( p_obj );
 
  cl_perf_destroy( &p_adapter->perf, TRUE );
@@ -493,13 +485,13 @@
  CL_ASSERT( p_adapter );
 
  /* Synchronize with destruction */
- cl_mutex_acquire( &p_adapter->mutex );
+ KeWaitForMutexObject( &p_adapter->mutex, Executive, KernelMode, FALSE,
NULL );
  cl_obj_lock( &p_adapter->obj );
  old_state = p_adapter->state;
  cl_obj_unlock( &p_adapter->obj );
  if( old_state == IB_PNP_PORT_REMOVE )
  {
-  cl_mutex_release( &p_adapter->mutex );
+  KeReleaseMutex( &p_adapter->mutex, FALSE );
   IPOIB_TRACE_EXIT( IPOIB_DBG_PNP,
    ("Aborting - Adapter destroying.\n") );
   return IB_NOT_DONE;
@@ -635,7 +627,7 @@
   break;
  }
 
- cl_mutex_release( &p_adapter->mutex );
+ KeReleaseMutex( &p_adapter->mutex, FALSE );
 
  IPOIB_EXIT( IPOIB_DBG_PNP );
  return status;
@@ -753,8 +745,7 @@
  p_adapter = PARENT_STRUCT( context, ipoib_adapter_t, obj );
 
  /* Synchronize with destruction */
- cl_mutex_acquire( &p_adapter->mutex );
-
+ KeWaitForMutexObject( &p_adapter->mutex, Executive, KernelMode, FALSE,
NULL );
  cl_obj_lock( &p_adapter->obj );
 
  CL_ASSERT( !p_adapter->h_pnp );
@@ -800,7 +791,7 @@
  /* Dereference the adapter since the previous registration is now
gone. */
  cl_obj_deref( &p_adapter->obj );
 
- cl_mutex_release( &p_adapter->mutex );
+ KeReleaseMutex( &p_adapter->mutex, FALSE );
 
  IPOIB_EXIT( IPOIB_DBG_INIT );
 }
@@ -923,7 +914,7 @@
   NdisWriteErrorLogEntry( p_adapter->h_adapter,
    EVENT_IPOIB_PORT_UP + (p_adapter->rate/ONE_X_IN_100BPS),
    1, p_adapter->rate );
-
+ 
   NdisMIndicateStatus( p_adapter->h_adapter, NDIS_STATUS_MEDIA_CONNECT,
    NULL, 0 );
   NdisMIndicateStatusComplete( p_adapter->h_adapter );

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openfabrics.org/pipermail/ofw/attachments/20060314/a077c164/attachment.html>