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
