[LTP] [PATCH v7] fanotify22.c: handle multiple asynchronous error events

[Jan Kara]

Hi!

On Sat 28-03-26 00:44:21, Wei Gao wrote:
> On Fri, Mar 27, 2026 at 02:19:28PM +0000, Andrea Cervesato wrote:
> > Hi Wei,
> > 
> > we still have a problem with the patch. We are considering deterministic
> > events, where one event comes after the other.
> > 
> > consolidate_events() accepts events matching either ex->error or
> > ex->error2:
> > 
> > > +		if (info->error != ex->error && (ex->error2 == 0 || info->error != ex->error2)) {
> > 
> > but the first accepted event becomes the one passed to check_event().
> > Since event delivery order is non-deterministic, the first event could
> > have error == ESHUTDOWN (error2). check_error_event_info_error() then
> > only checks against ex->error:
> > 
> > > 	if (info_error->error != ex->error) {
> > > 		tst_res(TFAIL, "Unexpected error code value (%d!=%d)",
> > > 			info_error->error, ex->error);
> > 
> > So it compares ESHUTDOWN against EFSCORRUPTED, doesn't match, and
> > reports TFAIL.
> > 
> > We need to change that into:
> > 
> >   if (info_error->error != ex->error &&
> >       (ex->error2 == 0 || info_error->error != ex->error2)) {
> > 
> > Similar to the consolidate_events(), otherwise we will have a TFAIL when
> > events don't arrive in the same order. Did you try to run patch with a high
> > number of `-i` ? It should fails sometimes with the actual code.
> I remember i have tested in openqa with -i1000 without error in early version such
> as v4 or v5(The main logic not touched compared with v6/v7).
> 
> BTW: is this the final comments?

Andrea is correct, that strictly speaking the ordering of fanotify
notification events is not guaranteed. In practice however error events are
never reordered so you definitely won't be able to observe test failures
due to that currently. I'm fine with the test not handling reordering of
error events, we can always fix that up if the kernel ever decides it is
unavoidable (we'd have to have really strong reason for that).

								Honza
-- 
Jan Kara <jack@suse.com>
SUSE Labs, CR