Re: [PATCH v3 0/5] Add new system call for non-destructive peek and inspection to posix ipc mqueue

Hi, Andrei

Thanks for reviewing and time,
I saw the code what you pointing to, here is current constraint what I see-

 1) "Kernel will figure out dilemma"- current implementation is seems
to be highly tied with System V MSG semantic, If we try to add logic
to handle Posix queue as well, then I think we need to mix posix queue
and current system V path, its create cross subsystem coupling,we need
to detect is msqid input passed in arg of msgrcv() is file descriptor
for posix queue or integer id of kernel object for system V (As we all
know posix queue is implemented on virtual file system), then route to
SysV path or POSIX path.We require  extra lookup attempts and
ambiguous failure modes.
Both are integers so in extremely rare cases ,it may overlap then, We
may end-up copying unrelated data to user_space

2) Readability issue- we need to think  about many things before
merging both, like Wakeup semantic,data structure, priority and FIFO
handling for posix msg.

3) Backward compatibility risk- changing behavior of msgrcv() to
accept FDs behave differently based on detection, Could break existing
programs and introduce silent misbehavior.

4) Non-Trivial to extend existing one- from given below snippet, it
seem pretty much clear that no input to size of user_space struct
taken, "msgsz" used for buffer or how many byte actually going to
copy, if we just add new member in struct as input in case we required
,it may cause compatibility issue with different arch and 32 bit or 64
bit struct layout handling be tricky without the size of struct.

SYSCALL_DEFINE5(msgrcv, int, msqid, struct msgbuf __user *, msgp,
size_t, msgsz, long, msgtyp, int, msgflg)
 {
  return ksys_msgrcv(msqid, msgp, msgsz, msgtyp, msgflg);
}

and static long do_msgrcv(int msqid, void __user *buf, size_t bufsz,
long msgtyp, int msgflg,
      long (*msg_handler)(void __user *, struct msg_msg *, size_t)){}


Thanks,
Mathura


On Tue, 14 Apr 2026 at 04:53, Mathura <[email protected]> wrote:
>
> Hi, Andrei
>
> Thanks for reviewing and time,
> I saw the code what you pointing to, here is current constraint what I se=
e-
>
>  1) "Kernel will figure out dilemma"- current implementation is seems to =
be highly tied with System V MSG semantic, If we try to add logic to handle=
 Posix queue as well, then I think we need to mix posix queue and current s=
ystem V path, its create cross subsystem coupling,we need to detect is msqi=
d input passed in arg of msgrcv() is file descriptor for posix queue or int=
eger id of kernel object for system V (As we all know posix queue is implem=
ented on virtual file system), then route to SysV path or POSIX path.We req=
uire  extra lookup attempts and ambiguous failure modes.
> Both are integers so in extremely rare cases ,it may overlap then, We may=
 end-up copying unrelated data to user_space
>
> 2) Readability issue- we need to think  about many things before merging =
both, like Wakeup semantic,data structure, priority and FIFO handling for p=
osix msg.
>
> 3) Backward compatibility risk- changing behavior of msgrcv() to accept F=
Ds behave differently based on detection, Could break existing programs and=
 introduce silent misbehavior.
>
> 4) Non-Trivial to extend existing one- from given below snippet, it seem =
pretty much clear that no input to size of user_space struct  taken, "msgsz=
" used for buffer or how many byte actually going to copy, if we just add n=
ew member in struct as input in case we required ,it may cause compatibilit=
y issue with different arch and 32 bit or 64 bit struct layout handling be =
tricky without the size of struct.
>
> SYSCALL_DEFINE5(msgrcv, int, msqid, struct msgbuf __user *, msgp, size_t,=
 msgsz, long, msgtyp, int, msgflg)
>  {
>   return ksys_msgrcv(msqid, msgp, msgsz, msgtyp, msgflg);
> }
>
> and static long do_msgrcv(int msqid, void __user *buf, size_t bufsz, long=
 msgtyp, int msgflg,
>       long (*msg_handler)(void __user *, struct msg_msg *, size_t)){}
>
> Thanks,
> Mathura
>
>
> On Mon, 13 Apr 2026 at 22:06, Andrei Vagin <[email protected]> wrote:
>>
>> On Wed, Apr 8, 2026 at 2:53=E2=80=AFAM Mathura_Kumar <academic1mathura@g=
mail.com> wrote:
>> >
>> >
>> > Patch series overview:
>> >
>> >   1. Add New system call do_mq_timedreceive2() and handler implementat=
ion
>> >   2. Add system call number in all most common arch.
>> >   3. Prepared Documentation and test
>> >   4. Add entry in performance tools all most common file
>> >   5. Add bitmask flag and user struct size as input for extensibility
>>
>> Could you please explain why MSG_COPY can't be used to implement C/R?
>> It was introduced by 4a674f34ba04a ("ipc: introduce message queue copy f=
eature")
>>
>> >
>> > change since v2:
>> >  - bitmask flag is added and check for valid operation
>> >  - userspace struct argument size is added for extensibility
>> >  - new test is added
>> >  - documentation is updated approximately
>> >  - increased the total system call count in performance tool as well
>> >  - v2 Link: https://lore.kernel.org/linux-arch/20260320052340.6696-1-a=
[email protected]/T/#t
>> >
>> >
>> >   Thanks for reviewing.
>> >
>> >
>> >  Documentation/userspace-api/index.rst         |   1 +
>> >  Documentation/userspace-api/ipc.rst           | 228 +++++
>> >  arch/alpha/kernel/syscalls/syscall.tbl        |   1 +
>> >  arch/arm/tools/syscall.tbl                    |   1 +
>> >  arch/arm64/tools/syscall_32.tbl               |   1 +
>> >  arch/m68k/kernel/syscalls/syscall.tbl         |   1 +
>> >  arch/microblaze/kernel/syscalls/syscall.tbl   |   1 +
>> >  arch/mips/kernel/syscalls/syscall_n32.tbl     |   1 +
>> >  arch/mips/kernel/syscalls/syscall_n64.tbl     |   1 +
>> >  arch/mips/kernel/syscalls/syscall_o32.tbl     |   1 +
>> >  arch/parisc/kernel/syscalls/syscall.tbl       |   1 +
>> >  arch/powerpc/kernel/syscalls/syscall.tbl      |   1 +
>> >  arch/s390/kernel/syscalls/syscall.tbl         |   1 +
>> >  arch/sh/kernel/syscalls/syscall.tbl           |   1 +
>> >  arch/sparc/kernel/syscalls/syscall.tbl        |   1 +
>> >  arch/x86/entry/syscalls/syscall_32.tbl        |   1 +
>> >  arch/x86/entry/syscalls/syscall_64.tbl        |   1 +
>> >  arch/xtensa/kernel/syscalls/syscall.tbl       |   1 +
>> >  include/linux/compat.h                        |   6 +-
>> >  include/linux/syscalls.h                      |   6 +
>> >  include/uapi/asm-generic/unistd.h             |   7 +-
>> >  include/uapi/linux/mqueue.h                   |  14 +-
>> >  ipc/mqueue.c                                  | 211 ++++-
>> >  ipc/msg.c                                     |   2 +-
>> >  ipc/msgutil.c                                 |  48 +-
>> >  ipc/util.h                                    |   3 +-
>> >  kernel/sys_ni.c                               |   3 +
>> >  scripts/syscall.tbl                           |   1 +
>> >  tools/include/uapi/asm-generic/unistd.h       |   6 +-
>> >  .../arch/alpha/entry/syscalls/syscall.tbl     |   1 +
>> >  .../perf/arch/arm/entry/syscalls/syscall.tbl  |   1 +
>> >  .../arch/arm64/entry/syscalls/syscall_32.tbl  |   1 +
>> >  .../arch/mips/entry/syscalls/syscall_n64.tbl  |   1 +
>> >  .../arch/parisc/entry/syscalls/syscall.tbl    |   1 +
>> >  .../arch/powerpc/entry/syscalls/syscall.tbl   |   1 +
>> >  .../perf/arch/s390/entry/syscalls/syscall.tbl |   1 +
>> >  tools/perf/arch/sh/entry/syscalls/syscall.tbl |   1 +
>> >  .../arch/sparc/entry/syscalls/syscall.tbl     |   1 +
>> >  .../arch/x86/entry/syscalls/syscall_32.tbl    |   1 +
>> >  .../arch/x86/entry/syscalls/syscall_64.tbl    |   1 +
>> >  .../arch/xtensa/entry/syscalls/syscall.tbl    |   1 +
>> >  tools/scripts/syscall.tbl                     |   1 +
>> >  tools/testing/selftests/ipc/.gitignore        |   1 +
>> >  tools/testing/selftests/ipc/Makefile          |   9 +-
>> >  tools/testing/selftests/ipc/mq_peek.c         | 813 +++++++++++++++++=
+
>> >  45 files changed, 1343 insertions(+), 45 deletions(-)
>> >  create mode 100644 Documentation/userspace-api/ipc.rst
>> >  create mode 100644 tools/testing/selftests/ipc/mq_peek.c
>> >
>> > --
>> > 2.43.0
>> >