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>] [<thread-prev] [day] [month] [year] [list]

Date:   Thu, 4 Mar 2021 20:57:59 +0100
From:   Manfred Spraul <manfred@...orfullife.com>
To:     Andrew Morton <akpm@...ux-foundation.org>,
        Eric Gao <eric.tech@...mail.com>
Cc:     jbi.octave@...il.com, linux-kernel@...r.kernel.org,
        Davidlohr Bueso <dave@...olabs.net>
Subject: Re: [PATCH] ipc/msg: add msgsnd_timed and msgrcv_timed syscall for
 system V message queue

Hi Eric,


On 3/4/21 2:12 AM, Andrew Morton wrote:
> On Tue, 23 Feb 2021 23:11:43 +0800 Eric Gao <eric.tech@...mail.com> wrote:
>
>> sometimes, we need the msgsnd or msgrcv syscall can return after a limited
>> time, so that the business thread do not be blocked here all the time. In
>> this case, I add the msgsnd_timed and msgrcv_timed syscall that with time
>> parameter, which has a unit of ms.
> Please cc Manfred and Davidlohr on ipc/ changes.
>
> The above is a very brief description for a new syscall!  Please go to
> great lengths to tell us why this is considered useful - what are the
> use cases?
>
> Also, please fully describe the proposed syscall interface right here
> in the changelog.  Please be prepared to later prepare a full manpage.
>
>> ...
>> +SYSCALL_DEFINE5(msgsnd_timed, int, msqid, struct msgbuf __user *, msgp, size_t, msgsz,
>> +		int, msgflg, long, timeoutms)
> Specifying the timeout in milliseconds is problematic - it's very
> coarse.  See sys_epoll_pwait2()'s use of timespecs.

What about using an absolute timeout, like in mq_timedsend()?

That makes restart handling after signals far simpler.

> > -               schedule();
> > +
> > +               /* sometimes, we need msgsnd syscall return after a given time */
> > +               if (timeoutms <= 0) {
> > +                       schedule();
> > +               } else {
> > +                       timeoutms = schedule_timeout(timeoutms);
> > +                       if (timeoutms == 0)
> > +                               timeoutflag = true;
> > +               }
>
> I wonder if this should be schedule_timeout_interruptible() or at least
> schedule_timeout_killable() instead of schedule_timeout(). If it should,
> this should probably be done as a separate change.
No. schedule_timeout_interruptible() just means that 
__set_current_state() is called before the schedule_timeout().

The __set_current_state() is done directly in msg.c, before dropping the 
lock.

--

     Manfred