On Sun, May 4, 2014 at 10:31 AM, Heinrich Schuchardt <xypron.glpk@xxxxxx> wrote: > On 03.05.2014 21:21, Michael Kerrisk (man-pages) wrote: >> >> [CC += Eric] >> >> Hello Heinrich, >> >> On 05/03/2014 06:57 PM, Heinrich Schuchardt wrote: >>> >>> The last lines of fanotify_read() in fanotify_user.c are: >>> if (start != buf && ret != -EFAULT) >>> ret = buf - start; >>> return ret; >>> >>> This implies that an error code is only returned, if reading the first >>> event on the queue fails or if EFAULT occurs. >> >> >> I'm not quite sure if this text is needed. What sort of errors >> are we talking about here that are not reported? > > > EMFILE The per-process limit on the number of open files has been reached. > See the description of RLIMIT_NOFILE in getrlimit(2). > > ENFILE The system-wide limit on the number of open files has been reached. > See /proc/sys/fs/file-max in proc(5). > > ETXTBSY This error is returned by read(2) if O_RDWR or O_WRONLY was > specified in the event_f_flags argument when calling fanotify_init(2) and > an event occurred for a monitored file that is currently being executed. But, then won't we see something like this 1. First read() reads the events up to the point of the error. 2. The next read reports the event that has an error. This is just my expectation of reasonable behavior, I have not checked what actually does happen. Or are you saying that some events will actually be lost (i.e., won't appear as events in read() buffers and won't be reported as errors from read()) in this scenario? If so, that sounds like (another) bug to me. Cheers, Michael >>> Signed-off-by: Heinrich Schuchardt <xypron.glpk@xxxxxx> >>> --- >>> man7/fanotify.7 | 8 ++++++++ >>> 1 file changed, 8 insertions(+) >>> >>> diff --git a/man7/fanotify.7 b/man7/fanotify.7 >>> index 083244f..6936b88 100644 >>> --- a/man7/fanotify.7 >>> +++ b/man7/fanotify.7 >>> @@ -131,6 +131,14 @@ until either a file event occurs or the call is >>> interrupted by a signal >>> The return value of >>> .BR read (2) >>> is the length of the filled buffer, or \-1 in case of an error. >>> +If multiple events are on the fanotify queue, >>> +.BR read (2) >>> +will only report an error, if reading the first event fails or an error >>> +.B EFAULT >>> +occurs. >>> +If reading the first event is successful but reading any further event >>> fails, >>> +.BR read (2) >>> +returns the length of the buffer filled with all prior events. >>> After a successful >>> .BR read (2), >>> the read buffer contains one or more of the following structures: >>> >> >> > -- Michael Kerrisk Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/ Linux/UNIX System Programming Training: http://man7.org/training/ -- To unsubscribe from this list: send the line "unsubscribe linux-man" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
