On Mon, 04 Jun 2018 18:31:31 -0400, Hugo Lefeuvre said: > Do you mean that the ioctl/read/write call increments the reference > count in this case ? It would mean that these syscalls aren't really > using passed FD but instead create duplicates to make sure the open > file description won't be freed during their execution, right ?
One file descriptor is passed around, and each syscall or other code that needs to protect it from evaporating out from under it takes a reference. Think of it as "How many of you are still using it? 3? OK.. I won't clean up yet. Oh, it's down to zero? OK, it's clean up time" Another example of the same sort of thing can be seen in file systems, where one or more file descriptors can be opened on a given file, and the file is then unlinked - but the inode and the allocated space doesn't actually get freed until all the open descriptors (each of which increments the ref count) are closed and the refcount actually reaches zero. That's what's going on when you run 'lsof' and see files listed as '(deleted)', or when you *think* you've cleaned up the logs, but /var is still sitting at 98%....
pgpr6pyIe99O0.pgp
Description: PGP signature
_______________________________________________ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
