535.54.03

src/common/inc/nvlog_defs.h

@@ -120,12 +120,14 @@ struct _NVLOG_BUFFER
 
 #if !PORT_IS_KERNEL_BUILD
 typedef struct PORT_SPINLOCK PORT_SPINLOCK;
+typedef struct PORT_MUTEX PORT_MUTEX;
 #else
 #include "nvport/nvport.h"
 #endif
 
 #elif !defined(PORT_IS_KERNEL_BUILD)
 typedef struct PORT_SPINLOCK PORT_SPINLOCK;
+typedef struct PORT_MUTEX PORT_MUTEX;
 #else
 #include "nvport/nvport.h"
 #endif
@@ -143,11 +145,33 @@ typedef struct _NVLOG_LOGGER
     NvU32           nextFree;
     /** Total number of free buffer slots */
     NvU32           totalFree;
-    /** Lock for all buffer oprations */
+    /** Lock for some buffer oprations */
     PORT_SPINLOCK*  mainLock;
+    /** Lock for creating/deleting pBuffers and accessing them from RmCtrls */
+    PORT_MUTEX*  buffersLock;
 } NVLOG_LOGGER;
 extern NVLOG_LOGGER NvLogLogger;
 
+/**
+ * NvLog uses two locks:
+ * - NVLOG_LOGGER::mainLock is used to protect some accesses to pBuffers, or
+ * an individual pBuffers entry depending on locking flags.
+ * - NVLOG_LOGGER::buffersLock is used to protect creating/deleting pBuffers and accessing them
+ * from certain RmCtrl handlers.
+ *
+ * Historically in most contexts obtaining RMAPI lock would suffice, and mainLock would optionally
+ * be used for certain buffers. Ioctl NV_ESC_RM_NVLOG_CTRL cannot touch RMAPI lock and needs
+ * to access NvLog. The latter operation might race if called at an inopportune time: e.g. if the
+ * ioctl is called during RM init when KGSP creates/deletes GSP NvLog buffers. Using buffersLock is
+ * thus necessary to resolve the potential race.
+ *
+ * This leads to an unfortunate sequence where mainLock and buffersLock are nested. The latter lock
+ * cannot be removed as it is used in IRQ paths.
+ *
+ * This should be refactored to use a single RWLock that does conditional acquire in possible IRQ
+ * paths.
+ */
+
 //
 // Buffer flags
 //