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 13:52:15 +0200 [thread overview]
Message-ID: <aNPbb6IDKO2IaMaj@yuki.lan> (raw)
In-Reply-To: <1c7404a7-87aa-4c1f-a8f5-08fab2c69fea@suse.cz>
Hi!
> >> diff --git a/testcases/kernel/syscalls/epoll_pwait/epoll_pwait06.c b/testcases/kernel/syscalls/epoll_pwait/epoll_pwait06.c
> >> index 3bedc2cf5..d47327bed 100644
> >> --- a/testcases/kernel/syscalls/epoll_pwait/epoll_pwait06.c
> >> +++ b/testcases/kernel/syscalls/epoll_pwait/epoll_pwait06.c
> >> @@ -36,6 +36,7 @@ static void run(void)
> >> case TST_FD_DIR:
> >> case TST_FD_DEV_ZERO:
> >> case TST_FD_PROC_MAPS:
> >> + case TST_FD_BPF_MAP:
> >> case TST_FD_FSOPEN:
> >> case TST_FD_FSPICK:
> >> case TST_FD_OPEN_TREE:
> >
> > Can we make this kernel version dependent? I do not like disabling tests
> > that work on newer kernels just because it does not work on something
> > that is eight years old.
>
> I like kernel version checks even less. I could call epoll_ctl()
> directly without the safe macro instead and check for EPERM. That's the
> appropriate feature check.
That does not work either. We had patches that were misapplied and broke
kernel so that it wrongly returned error instead of the expected
operation. Just checking for EPERM would silence such bugs.
In the end I came to a conclusion that the only way how to make sure
things are not broken is to expect that certain functionality is present
either on CONFIG_ options or if that is not possible on kernel version.
It's ugly but that's how things are.
--
Cyril Hrubis
chrubis@suse.cz
--
Mailing list info: https://lists.linux.it/listinfo/ltp
next prev parent reply other threads:[~2025-09-24 11:52 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 [this message]
2025-09-24 11:59 ` Martin Doucha
2025-09-24 12:08 ` Cyril Hrubis
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=aNPbb6IDKO2IaMaj@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