On Wed, Jun 8, 2022 at 2:57 PM Jan Kara <jack@xxxxxxx> wrote: > > Hello, > > On Wed 08-06-22 14:33:47, Gal Rosen wrote: > > One more question, if I do get into a situation in which I reach the limit > > of the number of open files per my process, can I continue ? Can I continue > > in my while loop and after a couple of microseconds for example can try to > > re-read ? > > If I get the error of EMFILE, it could be that some of the events > > successfully read and are already in my user buffer, but I still get return > > value of -1 on the read, does all the successful events are still in the > > kernel queue and will be still there for the next read ? > > So if you get the EMFILE error, it means that we were not able to open file > descriptor for the first event you are trying to read. If the same error > happens for the second or later event copied into user provided buffer, we > return length corresponding to the succesfully formatted events. Sadly, the > event for which we failed to open file will be silently dropped in that case > :-|. Amir, I guess we should at least report the event without the fd in > that case. What do you think? Yes, that is unfortunate. We could return an event without fd. We could return the error in event->fd but I don't like it. We could store the error in the group and return success for whatever events have been read so far, then on the next read we just return the error immediately and clear the group error state. That will keep existing UAPI semantics intact. BTW, in the category of possible errors from reading event there are also ENXIO ENODEV when a process tries to open a device file with nothing behind it, which is very easy to reproduce. Thanks, Amir.
