[RFC] Add new system call for non-destructive peek and inspection to posix ipc mqueue

Hi, Andrei,Pavel and Radostin Stoyanov

I hope everyone is doing well.

I would like to start a discussion and gather feedback on my recent
work regarding kernel interface here,
As encouraged by Andrei to do review in the criu community first
before proposing to the wider kernel community
in our earlier conversation, although initially patch was already
submitted in the kernel community two weeks ago and
some of the initial versions a month ago.

Short Description:
Evaluated Approach and Constraints:

In last 3 month, I studied various documentation, CRIU codebases and
kernel codebases related with posix queue,
deeply analysed queue implementation and related existing system call,
I tried to figure out any clean way to add feature
but following constraint I faced and reach to some conclusion:

1) In the handler of the existing mq_receive() function given below if
we add a new flag like MQ_PEEK to it as we can add
because it still has one vacant args count which make total 6 args
after adding MQ_PEEK which possible but it surely break existing
userspace code running or ABI using it, so this idea dropped out.
static int do_mq_timedreceive(mqd_t mqdes, char __user *u_msg_ptr,
size_t msg_len, unsigned int __user *u_msg_prio, struct timespec64
*ts)

2) Using ioctl () system call on the queue file descriptor and somehow
tweak the queue but it will be very fragile
or probably not work like fully non-intrusive. It may trigger
notification because queue implementation in the virtual file system
currently also does not have logic to handle this kind of invocation.
As we know ioctl is purely made to control behaviour with device
drivers and io.

 3) One other janky approach by abusing fcntl() system call to do
operation on a posix queue file descriptor and
call some function internally to copy data to user space.

Why this is a poor idea as per my thought:
fcntl() is a global general purpose system call to control file
related behavior like-
             1. Getting, Setting file descriptor flags eg
O_NONBLOCK,O_RDWR e.t.c
             2. Locking test, duplication like dup2().
Adding “peek” feature via fcntl()
            1.mixes queue semantics with file descriptor control.
            2. makes the API confusing and non-discoverable.

4) After considering various self intuition and brainstorming I
decided that the only reliable and clean way left out is
adding new system calls (but I am still open to discussion and new
ideas on these problems) and so I proceed with
adding new system calls.

Implementation details available in patch itself so I am not
mentioning in depth here-
The changes are implemented,tested for three common arch x86-64,arm64,
risc-v with build and calling runtime test
in some of arch and the final patch is available at:
https://lore.kernel.org/linux-arch/[email protected]/T/#t

Discussion points:
1) Does the current design and implementation make sense ?
2) Are there any additional considerations or improvements we should include?
3) Anything you may want to add.

I would greatly appreciate any feedback or suggestions.


Thanks for reviewing and time,
Mathura_kumar