Donny9 commented on code in PR #16431:
URL: https://github.com/apache/nuttx/pull/16431#discussion_r2104217444
##########
fs/inode/fs_files.c:
##########
@@ -476,14 +479,32 @@ void files_putlist(FAR struct filelist *list)
* because there should not be any references in this context.
*/
+#ifdef CONFIG_FS_REFCOUNT
+again:
+ loop = false;
+#endif
for (i = list->fl_rows - 1; i >= 0; i--)
{
for (j = CONFIG_NFILE_DESCRIPTORS_PER_BLOCK - 1; j >= 0; j--)
{
+#ifdef CONFIG_FS_REFCOUNT
+ if (fs_putfilep(&list->fl_files[i][j]) > 0)
Review Comment:
@pussuw Hello, the call of this function occurs when a task exits. There are
two key points that need to be clarified first:
1. All resources must be released when a task exits, including any opened
file descriptors (fd).
2. If the reference count (refs) of the filep corresponding to an fd is
greater than 1, it means that the filep is still being used somewhere, possibly
by another duplicated fd.
Currently, we close all fds in the file_list in reverse order.
For example:
Suppose the epoll fd is 5, and we add fd1=10, fd2=6, and fd3=3 to the epoll
queue.
So the closing order would be: fd1 -> fd2 -> epoll fd -> fd3.
When we close the epoll fd, since it's part of the task exit process,
there's no opportunity to execute epoll_ctl delete to remove fd1 and fd2.
Therefore, when we call close(epoll_fd)->epoll_close, trying to find the filep
through fd1 and fd2 will result in an error from fdcheck because they have
already been closed.
This is why we're considering replacing the fds in epoll with file
references. By doing so, when we close fd1 and fd2 for the first time, we only
decrement their reference counts by 1 instead of actually closing them.
However, we need to iterate through the for loop again to close them
properly and release the resources.
"What do you mean by 'other CPUs'? Are you referring to scenarios where
other CPUs access across cores through rpmsg services? In such cases, other
CPUs would receive a POLLHUP event from this fd, and this event needs to be
handled properly."
--
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: commits-unsubscr...@nuttx.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
