linux-kernel - Re: [PATCH] ipc/msg: add msgsnd_timed and msgrcv

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [day] [month] [year] [list]

Date:   Sun, 28 Feb 2021 16:38:07 +0100
From:   Arnd Bergmann <arnd@...nel.org>
To:     Eric Gao <eric.tech@...mail.com>
Cc:     "catalin.marinas" <catalin.marinas@....com>,
        will <will@...nel.org>, geert <geert@...ux-m68k.org>,
        monstr <monstr@...str.eu>, tsbogend <tsbogend@...ha.franken.de>,
        James Bottomley <James.Bottomley@...senpartnership.com>,
        deller <deller@....de>, mpe <mpe@...erman.id.au>,
        hca <hca@...ux.ibm.com>, gor <gor@...ux.ibm.com>,
        borntraeger <borntraeger@...ibm.com>,
        ysato <ysato@...rs.sourceforge.jp>, dalias <dalias@...c.org>,
        davem <davem@...emloft.net>, luto <luto@...nel.org>,
        tglx <tglx@...utronix.de>, mingo <mingo@...hat.com>,
        bp <bp@...en8.de>, chris <chris@...kel.net>,
        jcmvbkbc <jcmvbkbc@...il.com>, arnd <arnd@...db.de>,
        benh <benh@...nel.crashing.org>, paulus <paulus@...ba.org>,
        hpa <hpa@...or.com>, linux-alpha <linux-alpha@...r.kernel.org>,
        linux-kernel <linux-kernel@...r.kernel.org>,
        linux-arm-kernel <linux-arm-kernel@...ts.infradead.org>,
        linux-api <linux-api@...r.kernel.org>,
        linux-arch <linux-arch@...r.kernel.org>
Subject: Re: [PATCH] ipc/msg: add msgsnd_timed and msgrcv_timed syscall for
 system V message queue

On Sun, Feb 28, 2021 at 4:16 PM Eric Gao <eric.tech@...mail.com> wrote:
>
> Hi Arnd:
>
>             Thanks for your kindly reply.
>
>             I want to prove you and all of others that these syscalls are very useful and necessary. Actually,  I add these syscalls
>
>     when I try to implement the local rpc by system v message queue (some people might think I am crazy to using message
>
>     queue, but it's truly a very efficient method than socket except it don't have a time-controlled msgrcv syscall).

(note: please don't reply in html)

>             In addition,  msgrcv_timed is also necessary in usual bidirection communication.  For example:
> A send a message to B, and try to receive a reply  from B  by msgrcv syscall.  But A need to do
> something else in case of  that B has terminated. So
>
>     we need the msgrcv syscall return after a preset time. The similar syscall can be found in
> posix message queue(mq_timedreceive)  and in z/OS system of
>  IBM(https://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.2.0/com.ibm.zos.v2r2.bpxbd00/msgrcvt.htm).
>
>   And when I search the web, I can find that many people need such like syscall in their
> applications. so I hope this patch can be merged into the mainline, Thanks a lot.

It might help to add some explanation on why you need to add the timeout
to the old sysv message queues, when the more modern posix message
queues already support this.

Is there something that mq_timedsend/mq_timedreceive cannot do that
you need? Would it be possible to add that feature to the posix message
queues instead?

> +COMPAT_SYSCALL_DEFINE5(msgsnd_timed, int, msqid, compat_uptr_t, msgp,
> +                      compat_ssize_t, msgsz, int, msgflg, compat_long_t, timeoutms)
> +{
> +       struct compat_msgbuf __user *up = compat_ptr(msgp);
> +       compat_long_t mtype;
> +
> +       timeoutms = (timeoutms + 9) / 10;
> +
> +       if (get_user(mtype, &up->mtype))
> +               return -EFAULT;
> +
> +       return do_msgsnd(msqid, mtype, up->mtext, (ssize_t)msgsz, msgflg, (long)timeoutms);
> +}
>
> My preference would be to simplify both the timed and non-timed version by
> moving the get_user() into do_msgsnd() and using in_compat_task() to pick
> the right type. Same for the receive side of course. If you do this,
> watch out for x32 support, which uses the 64-bit version.
>
>     Actually, the timed and non-timed version have different number of
>  parameter(timed version have timeoutms), so I don't
> think they can be combine together,  and I don't want to impact the
> applications which  have been using the old style msgrcv syscall.

What I meant was combining the implementation of the native and
compat versions, not combining the timed and non-timed versions,
which you already do to the degree possible.

           Arnd