On Wed 08-06-22 15:14:12, Amir Goldstein wrote: > 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. Yes, what you suggest looks like a clean way out of this situation. BTW -EFAULT handling is strange as well (that seems to come from inotify times). If we get -EFAULT during copying event, we'll just report it and ignore whatever we have already copied to userspace. But I guess in this case it is at least consistent with the behavior of standard read(2) and if you hit -EFAULT, you are doing something seriously wrong and lost events are the least of your worries (although for fanotify it means we have just leaked the file descriptors for already copied events and with permission events that's going to be deadly for the system). Ugh. > 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. Yes. Honza -- Jan Kara <jack@xxxxxxxx> SUSE Labs, CR
