From: Cyril Hrubis <chrubis@suse.cz>
To: Martin Doucha <mdoucha@suse.cz>
Cc: ltp@lists.linux.it
Subject: Re: [LTP] [PATCH] epoll_pwait06: Skip BPF map file descriptor
Date: Wed, 24 Sep 2025 14:08:04 +0200 [thread overview]
Message-ID: <aNPfJMs4nWRSeEu8@yuki.lan> (raw)
In-Reply-To: <48487e51-0e3d-4dcd-b25f-2dc9dba74172@suse.cz>
Hi!
> I'll accept EPERM only for the file descriptor types which are now
> unconditionally skipped. The only file descriptor type which could then
> get skipped incorrectly will be BPF. But that's not a problem because
> verifying epoll support is out of scope of this test. The primary
> purpose is to verify that small epoll_pwait() timeouts won't get
> misinterpreted as infinity. In theory, verifying that on a single file
> descriptor type should be sufficient.
Ah, I had no idea that this is a regression test for a generic epoll
code, it never occured to me that we run something like that for all
types of file descriptors. For that test it makes sense to just skip
unsupported fds.
I guess that we are actually mixing two tests and it would make sense to
separate these two. I.e. one that is a regression test for the epoll bug
and second, probably called epoll_ctl06.c that would hammer the
EPOLL_CTL_ADD with all kinds of fds and expect either success or error.
--
Cyril Hrubis
chrubis@suse.cz
--
Mailing list info: https://lists.linux.it/listinfo/ltp
next prev parent reply other threads:[~2025-09-24 12:07 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-09-23 15:48 [LTP] [PATCH] epoll_pwait06: Skip BPF map file descriptor Martin Doucha
2025-09-24 8:56 ` Cyril Hrubis
2025-09-24 11:06 ` Martin Doucha
2025-09-24 11:52 ` Cyril Hrubis
2025-09-24 11:59 ` Martin Doucha
2025-09-24 12:08 ` Cyril Hrubis [this message]
2025-09-24 13:06 ` Martin Doucha
2025-09-24 13:16 ` Cyril Hrubis
2025-09-26 14:07 ` Cyril Hrubis
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=aNPfJMs4nWRSeEu8@yuki.lan \
--to=chrubis@suse.cz \
--cc=ltp@lists.linux.it \
--cc=mdoucha@suse.cz \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox