https://bugzilla.mindrot.org/show_bug.cgi?id=3049
--- Comment #6 from [email protected] --- Comment on attachment 3307 --> https://bugzilla.mindrot.org/attachment.cgi?id=3307 attempt #2 Online 129, you miss a semicolon after return, which makes it fail to compile. Also, we need to have "got < need" instead of "got <= need". Firstly, got == need means the buffer given to proc_pidinfo is full, so it is possible there are more file descriptors added, thus we need to retry in this case. Secondly, proc_pidinfo, if given NULL buffer, will return 20 more entries than the actual file table size, so in normal cases, the 'got < need' code path will be executed. In case got == need, ideally we should close file descriptors in the buffer returned, before we retry. In this way, the next retry will have far less number of elements to work on. Otherwise, if another thread keep adding new file descriptors, the next retry will have more file descriptors than previous retry, causing the proc_pidinfo syscall as well as malloc to be even slower, making it even lower chance that there is no file table changed between two proc_pidinfo syscalls. Again, I'd like to ask, in which case this closefrom is called while another thread is opening new file descriptors? The retry logic is complicated now, do we really need to introduce such a complicated logic to handle such a corner case? My understanding is, neither F_CLOSEM nor fallback implementation guarantees anything if there is another thread keep opening new file descriptors, therefore this closefrom is just on best effort basis. -- You are receiving this mail because: You are watching the assignee of the bug. You are watching someone on the CC list of the bug. _______________________________________________ openssh-bugs mailing list [email protected] https://lists.mindrot.org/mailman/listinfo/openssh-bugs
