recvfrom01: fix test for invalid message flags

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

Sorry for the delay, acked, tested and pushed, thanks.

Will you also send similar patches for the rest of the recv testcases?

From: "Chuck Ebbert" <[email protected]>
To: [email protected]
Sent: Thursday, 2 October, 2014 12:10:32 AM
Subject: [LTP] recvfrom01: fix test for invalid message 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.

testcases/kernel/syscalls/recvfrom/recvfrom01.c +7 -3

@@ -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
[email protected]
https://lists.sourceforge.net/lists/listinfo/ltp-list

Quoted 4 lines

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

I hit a failure in this testcase while trying latest LTP before release. Are you sure this is a bug?

Looking at commit history and man-pages, this looks more like new feature to me, flag that has not been supported before and now it is.

"MSG_ERRQUEUE is illegal on SOCK_STREAM sockets." [1]
"TCP timestamping introduced MSG_ERRQUEUE handling for TCP sockets." [2][3]

Until commit [3], tcp_recvmsg() has ignored this flag and it was also documented that way. So, I don't see why TFAIL is valid result on <3.17 for MSG_ERRQUEUE test: