From: Cyril Hrubis <chrubis@suse.cz>
To: ltp@lists.linux.it
Subject: [LTP] [PATCH v4] syscalls/prctl02: add more error tests
Date: Tue, 12 Nov 2019 11:10:54 +0100 [thread overview]
Message-ID: <20191112101054.GA9373@rei.lan> (raw)
In-Reply-To: <43e4f419-0100-dc52-7159-2355e9de1639@cn.fujitsu.com>
Hi!
> > 1) Add fallback definitions to lapi
> > 2) Ensure these tests does not fail on older kernels
> >
> > We do expect EINVAL in these cases anyways, which is what we would
> > get if the prctl() option is unknown to the kernel anyways, so here
> > we can just get rid of these ifdefs and things should work fine.
>
> For me, a fallback definitions into the lapi header is only for fixing undefined error on old kernel.
>
> IMO, we only test options that kernel supports.
> If we test an unsupported option, our case reports EINVAL that will give user a false impression(kernel
> supports it, but argument or environment is bad). I think we should check they whether supported before run
> (ifdef is a way).
However using ifdefs to assert kernel features never worked at all. The
kernel headers usally lag behind the installed kernel in distribution
and it's even more wrong when you are testing latest kernel on any given
distro.
If you want to check for kernel support the best thing is to use the
tst_kvercmp() that checks the kernel version and even that does not work
100% reliably.
> ps: If we test EPERM error(cap is not in PI or PP) of PR_CAP_AMBIENT on old kernel, they will report EINVAL.
> So, I think ifdef is needed.
No, ifdefs are never solution here. It will still fail if you compiled
the test on newer distro and booted it up with older kernel.
--
Cyril Hrubis
chrubis@suse.cz
next prev parent reply other threads:[~2019-11-12 10:10 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-10-25 12:39 [LTP] [PATCH] syscalls/prctl02: add more error tests Yang Xu
2019-10-31 8:59 ` [LTP] [PATCH v2] " Yang Xu
2019-11-01 8:49 ` Petr Vorel
2019-11-01 11:24 ` Yang Xu
2019-11-01 12:59 ` [LTP] [PATCH v3] " Yang Xu
2019-11-07 14:54 ` Cyril Hrubis
2019-11-08 12:12 ` Yang Xu
2019-11-08 13:20 ` Yang Xu
2019-11-08 14:24 ` Cyril Hrubis
2019-11-11 8:59 ` [LTP] [PATCH v4] " Yang Xu
2019-11-11 16:31 ` Cyril Hrubis
2019-11-12 3:02 ` Yang Xu
[not found] ` <5DCA5206.3040508@cn.fujitsu.com>
2019-11-12 7:27 ` Yang Xu
2019-11-12 10:15 ` Cyril Hrubis
2019-11-12 10:31 ` Yang Xu
2019-11-13 5:23 ` [LTP] [PATCH v5] " Yang Xu
2019-11-13 10:33 ` Cyril Hrubis
2019-11-12 10:10 ` Cyril Hrubis [this message]
2019-11-12 10:25 ` [LTP] [PATCH v4] " Yang Xu
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=20191112101054.GA9373@rei.lan \
--to=chrubis@suse.cz \
--cc=ltp@lists.linux.it \
/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