MIME-Version: 1.0
References: <20221216171807.760147-1-dvyukov@google.com> <20230112112411.813356-1-dvyukov@google.com>
 <20230125124304.GA13746@redhat.com> <20230125151717.GB13746@redhat.com>
 <CACT4Y+YKy_4mBLYomr49+fTm31Y6Q_kXhJz8O-_RTjMe=B-6eg@mail.gmail.com>
 <20230125163137.GC13746@redhat.com> <20230125170708.GE13746@redhat.com>
In-Reply-To: <20230125170708.GE13746@redhat.com>
From:   Dmitry Vyukov <dvyukov@google.com>
Date:   Thu, 26 Jan 2023 11:58:16 +0100
Message-ID: <CACT4Y+ZMOLw0QZ=ssmgs5oU8+jRxt0JZScQzKneG036vWZ=0wg@mail.gmail.com>
Subject: Re: [RFC PATCH v2] posix-timers: Support delivery of signals to the
 current thread
To:     Oleg Nesterov <oleg@redhat.com>
Cc:     tglx@linutronix.de, linux-kernel@vger.kernel.org,
        "Eric W . Biederman" <ebiederm@xmission.com>,
        Frederic Weisbecker <frederic@kernel.org>,
        Marco Elver <elver@google.com>
Content-Type: text/plain; charset="UTF-8"
Precedence: bulk

On Wed, 25 Jan 2023 at 18:07, Oleg Nesterov <oleg@redhat.com> wrote:
>
> On 01/25, Oleg Nesterov wrote:
> >
> > > >  int posix_timer_event(struct k_itimer *timr, int si_private)
> > > >  {
> > > >         enum pid_type type;
> > > > +       struct pid *pid;
> > > >         int ret;
> > > >         /*
> > > >          * FIXME: if ->sigq is queued we can race with
> > > > @@ -350,8 +351,9 @@ int posix_timer_event(struct k_itimer *timr, int si_private)
> > > >          */
> > > >         timr->sigq->info.si_sys_private = si_private;
> > > >
> > > > -       type = !(timr->it_sigev_notify & SIGEV_THREAD_ID) ? PIDTYPE_TGID : PIDTYPE_PID;
> > > > -       ret = send_sigqueue(timr->sigq, timr->it_pid, type);
> > > > +       type = (timr->it_sigev_notify & SIGEV_THREAD_ID) ? PIDTYPE_PID : PIDTYPE_TGID;
> > > > +       pid = (type == PIDTYPE_PID) ? timr->it_pid : task_pid(current);
> > > > +       ret = send_sigqueue(timr->sigq, pid, type);
> > > >         /* If we failed to send the signal the timer stops. */
> > > >         return ret > 0;
> > > >  }
>
> ...
>
> > But! I just noticed send_sigqueue() does pid_task(pid, type), so the patch
> > above needs another change
> >
> >       --- a/kernel/signal.c
> >       +++ b/kernel/signal.c
> >       @@ -1970,7 +1970,8 @@ int send_sigqueue(struct sigqueue *q, struct pid *pid, enum pid_type type)
> >
> >               ret = -1;
> >               rcu_read_lock();
> >       -       t = pid_task(pid, type);
> >       +       // comment to explain why don't we use "type"
> >       +       t = pid_task(pid, PIDTYPE_PID);
> >               if (!t || !likely(lock_task_sighand(t, &flags)))
> >                       goto ret;
>
> So. Unless I missed something (quite possibly) we do not even need the patch
> above. The one liner change below can work just fine.
>
> Oleg.
>
> --- a/kernel/signal.c
> +++ b/kernel/signal.c
> @@ -1970,7 +1970,8 @@ int send_sigqueue(struct sigqueue *q, struct pid *pid, enum pid_type type)
>
>         ret = -1;
>         rcu_read_lock();
> -       t = pid_task(pid, type);
> +       /* GOOD COMMENT */
> +       t = type == PIDTYPE_PID ? pid_task(pid, type) : current;
>         if (!t || !likely(lock_task_sighand(t, &flags)))
>                 goto ret;

This works for my use-case.

However, this is a bit trickier since current may be completely
unrelated to the original timer/process (think of monotonic timers).

Please take a look at v3:
https://lore.kernel.org/lkml/20221216171807.760147-1-dvyukov@google.com/T/#me78642cc096184da681cf91c39932be2bd2b74e1