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 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.