raiden00pl commented on code in PR #11140:
URL: https://github.com/apache/nuttx/pull/11140#discussion_r1387687536


##########
fs/inode/fs_files.c:
##########
@@ -51,59 +51,118 @@
  * Private Functions
  ****************************************************************************/
 
+/****************************************************************************
+ * Name: files_fget_index
+ ****************************************************************************/
+
+static FAR struct file *files_fget_index(FAR struct filelist *list,
+                                         int l1, int l2)
+{
+  FAR struct file *filep;
+  irqstate_t flags;
+
+  flags = enter_critical_section();

Review Comment:
   shouldn't we use spin_lock_irqsave here and below ?
   



##########
fs/inode/fs_files.c:
##########
@@ -278,10 +316,28 @@ void files_releaselist(FAR struct filelist *list)
     }
 
   kmm_free(list->fl_files);
+}
 
-  /* Destroy the mutex */
+/****************************************************************************
+ * Name: files_get_filecount
+ *
+ * Description:
+ *   Given a file descriptor, return the corresponding instance of struct
+ *   file.
+ *
+ * Input Parameters:
+ *   fd    - The file descriptor
+ *   filep - The location to return the struct file instance
+ *
+ * Returned Value:
+ *   Zero (OK) is returned on success; a negated errno value is returned on
+ *   any failure.
+ *
+ ****************************************************************************/
 
-  nxmutex_destroy(&list->fl_lock);
+int files_get_filecount(FAR struct filelist *list)
+{
+  return list->fl_rows * CONFIG_NFILE_DESCRIPTORS_PER_BLOCK;

Review Comment:
   what about protection `list->fl_rows` from race conditions? I know that 
`list->fl_rows` will rarely be changed, but won't this make any bugs even rarer 
and harder to detect? or is there no negative consequences from this ?
   
   



-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: [email protected]

For queries about this service, please contact Infrastructure at:
[email protected]

Reply via email to