From: Martin Karac <martin.karac@oracle.com>
To: ltp@lists.linux.it
Subject: [LTP] [PATCH 1/1] do not test undefined behavior
Date: Thu, 01 Jun 2017 17:16:56 +0200 [thread overview]
Message-ID: <59302FE8.5020502@oracle.com> (raw)
The test_flags() function's first test for each file is an attempt
to write a space character into that file (NULL translates to " ").
The test expects that this attempt will be successful and that the flag
will get set to 0.
This behavior was changed in Linux kernel between versions 3.13.74 and
3.14. with the commit a742c59de66ea080afa3edaf3428b3cdd5aa87cd
"cgroup: unify cgroup_write_X64() and cgroup_write_string()".
With the new behavior, attempting to write a space character into
a flag file returns EINVAL; I find this behavior more consistent.
Flag files are an interface which is known to expect numeric values.
We already have a test in test_flags() which covers invalid input.
We should not attempt to write a space into a flag file because
the resulting behavior is not strictly defined anywhere.
Therefore, it would be best to drop the first test.
---
.../cpuset_base_ops_testset.sh | 1 -
1 file changed, 1 deletion(-)
diff --git a/testcases/kernel/controllers/cpuset/cpuset_base_ops_test/cpuset_base_ops_testset.sh b/testcases/kernel/controllers/cpuset/cpuset_base_ops_test/cpuset_base_ops_testset.sh
index 992b8f2..70e7203 100755
--- a/testcases/kernel/controllers/cpuset/cpuset_base_ops_test/cpuset_base_ops_testset.sh
+++ b/testcases/kernel/controllers/cpuset/cpuset_base_ops_test/cpuset_base_ops_testset.sh
@@ -181,7 +181,6 @@ test_flags()
do
base_op_test "$CPUSET/$filename" "$flags" "$result"
done <<- EOF
- NULL 0
0 0
1 1
-1 WRITE_ERROR
--
1.7.9.2
next reply other threads:[~2017-06-01 15:16 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-06-01 15:16 Martin Karac [this message]
2017-06-02 11:45 ` [LTP] [PATCH 1/1] do not test undefined behavior Jan Stancek
2017-06-02 12:11 ` Martin Karac
-- strict thread matches above, loose matches on Subject: below --
2017-06-05 17:00 Martin Karac
2017-06-07 10:50 ` Jan Stancek
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=59302FE8.5020502@oracle.com \
--to=martin.karac@oracle.com \
--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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.