The msgque test uses the MSG_COPY flag, which depends on
CONFIG_CHECKPOINT_RESTORE. On kernels where this option is disabled,
msgrcv() fails with ENOSYS.

Currently, the test reports this as a failure:

Change it to skip the test instead, as the failure is due to missing
kernel configuration rather than a bug in the IPC subsystem.
 # selftests: ipc: msgque
 # not ok 1 Failed to copy IPC message: Function not implemented (38)
 # not ok 2 Failed to dump queue: -38

After this patch, the test reports a skip instead of failure:
1..0 # SKIP MSG_COPY not supported

Signed-off-by: UYeol Jo <jouyeol8739@gmail.com>
---
 tools/testing/selftests/ipc/msgque.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/tools/testing/selftests/ipc/msgque.c b/tools/testing/selftests/ipc/msgque.c
index e107379d185c..82f73cdae120 100644
--- a/tools/testing/selftests/ipc/msgque.c
+++ b/tools/testing/selftests/ipc/msgque.c
@@ -161,6 +161,9 @@ int dump_queue(struct msgque_data *msgque)
 		ret = msgrcv(msgque->msq_id, &msgque->messages[i].mtype,
 				MAX_MSG_SIZE, i, IPC_NOWAIT | MSG_COPY);
 		if (ret < 0) {
+			if (errno == ENOSYS)
+				ksft_exit_skip("MSG_COPY not supported\n");
+
 			ksft_test_result_fail("Failed to copy IPC message: %m (%d)\n", errno);
 			return -errno;
 		}
-- 
2.43.0

On 1/19/26 04:21, UYeol Jo wrote:
> The msgque test uses the MSG_COPY flag, which depends on
> CONFIG_CHECKPOINT_RESTORE. On kernels where this option is disabled,
> msgrcv() fails with ENOSYS.
> 
> Currently, the test reports this as a failure:
> 
> Change it to skip the test instead, as the failure is due to missing
> kernel configuration rather than a bug in the IPC subsystem.
>   # selftests: ipc: msgque
>   # not ok 1 Failed to copy IPC message: Function not implemented (38)
>   # not ok 2 Failed to dump queue: -38
> 
> After this patch, the test reports a skip instead of failure:
> 1..0 # SKIP MSG_COPY not supported

Did you happen to test this with CONFIG_CHECKPOINT_RESTORE
enabled and without?

MSG_COPY is not specific to CONFIG_CHECKPOINT_RESTORE - I see
MSG_COPY flag handling on non-CONFIG_CHECKPOINT_RESTORE code
in ipc/msg.c.

thanks,
-- Shuah

Hi Shuah,

Thank you for your feedback.

I have verified the behavior on kernel 6.19.0-rc1+ by testing both
kernel configurations (with and without CONFIG_CHECKPOINT_RESTORE).

Regarding the MSG_COPY handling in ipc/msg.c (between lines 1098-1262),
my analysis of do_msgrcv() shows the following execution flow:

1. Early Return (Lines 1112-1118):
   While the check 'if (msgflg & MSG_COPY)' is indeed outside the
   #ifdef blocks for validation, it immediately calls prepare_copy().
   Since prepare_copy() is stubbed to return ERR_PTR(-ENOSYS) when
   CONFIG_CHECKPOINT_RESTORE is disabled (line 1066), the system call
   fails and returns early at line 1118.

2. Unreachable Logic (Lines 1158-1161):
   The subsequent logic that calls copy_msg() is only reached if
   prepare_copy() succeeds. Without the config, this entire path
   becomes unreachable "dead code" in practice.

This confirms that while the flag handling is visible in the source,
the actual functionality is strictly dependent on the configuration.

To demonstrate the necessity of this patch, I ran the mainline test
in both environments:

1. With CONFIG_CHECKPOINT_RESTORE=y:
   # ./msgque
   # Totals: pass:0 fail:0 xfail:0 xpass:0 skip:0 error:0
   ok 1 selftests: ipc: msgque
   (Note: 'pass:0' is normal for this test as msgque.c does not
   explicitly call ksft_test_result_pass() for individual steps.)

2. With CONFIG_CHECKPOINT_RESTORE disabled (Mainline behavior):
   # ./msgque
   not ok 1 Failed to copy IPC message: Function not implemented (38)
   not ok 2 Failed to dump queue: -38
   # Totals: pass:0 fail:2 xfail:0 xpass:0 skip:0 error:0

Current mainline reports a "FAIL" for what is essentially a missing
kernel feature. My patch changes this to a "SKIP", which aligns
with kselftest standards.

With the patch applied, the result correctly becomes:
1..0 # SKIP MSG_COPY not supported

Best regards,
UYeol Jo