From: Chuck Ebbert <cebbert.lkml@gmail.com>
To: ltp-list@lists.sourceforge.net
Subject: [LTP] recvfrom01: fix test for invalid message flags
Date: Wed, 1 Oct 2014 17:10:32 -0500 [thread overview]
Message-ID: <20141001171032.698f1356@as> (raw)
The recv tests were making invalid assumptions about how flags are
checked by the kernel. (It makes no explicit tests for invalid flags
or combinations of flags.) [1] So the current method of setting every
possible flag and checking for a specific error is not valid.
Before kernel 3.17 we were effectively just testing having the MSG_OOB
flag set with no out-of-band data available. With 3.17 and later we
were testing having MSG_ERRQUEUE set with no error data available,
which returns a different error (and causes the existing test to fail).
Replace the bogus test for invalid flags with two new tests that check
return codes for invalid MSG_OOB and MSG_ERRQUEUE flags.
Note that this introduces a failure on kernels before 3.17, which has
a bug fix for MSG_ERRQUEUE flag handling. This failure is a legitimate
bug on these older kernels. (They should not be returning success with
no data available.)
[1] http://marc.info/?t=141148149900006&r=1&w=2
---
Additional test cases for invalid flags could be added after these two.
And the recv01 and recvmsg01 tests need still need to be fixed, assuming
this is the right solution.
--- a/testcases/kernel/syscalls/recvfrom/recvfrom01.c
+++ b/testcases/kernel/syscalls/recvfrom/recvfrom01.c
@@ -115,9 +115,14 @@
-1, EFAULT, setup1, cleanup1, "invalid recv buffer"},
/* 6 */
{
- PF_INET, SOCK_STREAM, 0, (void *)buf, sizeof(buf), -1,
+ PF_INET, SOCK_STREAM, 0, (void *)buf, sizeof(buf), MSG_OOB,
(struct sockaddr *)&from, &fromlen,
- -1, EINVAL, setup1, cleanup1, "invalid flags set"},};
+ -1, EINVAL, setup1, cleanup1, "invalid MSG_OOB flag set"},
+/* 7 */
+ {
+ PF_INET, SOCK_STREAM, 0, (void *)buf, sizeof(buf), MSG_ERRQUEUE,
+ (struct sockaddr *)&from, &fromlen,
+ -1, EAGAIN, setup1, cleanup1, "invalid MSG_ERRQUEUE flag set"},};
int TST_TOTAL = sizeof(tdat) / sizeof(tdat[0]);
------------------------------------------------------------------------------
Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports
Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk
_______________________________________________
Ltp-list mailing list
Ltp-list@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ltp-list
next reply other threads:[~2014-10-01 22:10 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-10-01 22:10 Chuck Ebbert [this message]
2014-10-27 10:20 ` [LTP] recvfrom01: fix test for invalid message flags Cyril Hrubis
2014-11-26 11:38 ` Cyril Hrubis
2015-01-06 10:07 ` Jan Stancek
2015-01-08 10:43 ` 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=20141001171032.698f1356@as \
--to=cebbert.lkml@gmail.com \
--cc=ltp-list@lists.sourceforge.net \
/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