lkml.org 
[lkml]   [2019]   [Aug]   [21]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [patch 04/44] posix-cpu-timers: Fixup stale comment
On Wed, 21 Aug 2019, Frederic Weisbecker wrote:
> On Tue, Aug 20, 2019 at 11:43:26PM +0200, Thomas Gleixner wrote:
> > On Tue, 20 Aug 2019, Frederic Weisbecker wrote:
> > No it can't do that throughout posix_cpu_timer_del() because exit_itimers()
> > can only look at current->signal->posix_timers which does not contain the
> > posix timers owned by a different task/process.
> >
> > We could of course invoke posix_cpu_timers_exit() from exit_itimers() but
> > does that buy anything?
> >
> > > It would make things more simple to delete the timer off the target from
> > > the same caller and place and we could remove posix_cpu_timers_exit*().
> >
> > We can't. The foreign owned cpu timers are not in cur->signal->posix_timers
> > so how should we invoke posix_cpu_timer_del() on them. Only the owner task
> > can. The only thing the exiting task can do is to remove the foreign timer
> > from it's expiry list which has nothing to do with cur->signal->posix_timers.
>
> That's exactly what I'm proposing. I think you're misunderstanding me.
>
> I want the owner to handle all the list deletion work from the target.
>
> Ok let's imagine a timer $ITIMER, owned by task $OWNER and whose target is task $TARGET.
>
> So it's enqueued on $OWNER->signal->posix_timers and $TARGET->cputime_expires.
>
> Two scenarios can happen:
>
> 1) $TARGET exits first and is released. So it calls posix_cpu_timers_exit()
> which deletes $ITIMER from $TARGET->cputime_expires.
>
> Later on, $OWNER exits and calls exit_itimers() -> timer_delete_hook($ITIMER)
> -> posix_cpu_timer_del($ITIMER). It finds $TARGET as the target of $ITIMER but no
> more sighand. So it returns.
>
> 2) $OWNER exits first and calls exit_itimer() -> timer_delete_hook($ITIMER)
> -> posix_cpu_timer_del($ITIMER). It finds $TARGET as the target of $ITIMER and it
> finds a sighand to lock. So it deletes $ITIMER from $TARGET->cputime_expires
> (see list_del(&timer->it.cpu.entry)).
>
>
> So I propose to change the behaviour of case 1) so that $TARGET doesn't call
> posix_cpu_timers_exit(). We instead wait for $OWNER to exit and call
> exit_itimers() -> timer_delete_hook($ITIMER) -> posix_cpu_timer_del($ITIMER).
> It is going to find $TARGET as the target of $ITIMER but no more sighand. Then
> finally it removes $ITIMER from $TARGET->cputime_expires.
> We basically do the same thing as in 2) but without locking sighand since it's NULL
> on $TARGET at this time.

But what do we win with that? Horrors like this:

task A task B task C

arm_timer(A) arm_timer(A)

do_exit()

del_timer(A) del_timer(A)
no sighand no_sighand
list_del() list_del()

Guess how well concurrent list deletion works.

We must remove armed timers from the task/signal _before_ dropping sighand,
really.

Thanks,

tglx

\
 
 \ /
  Last update: 2019-08-21 15:32    [W:0.093 / U:1.768 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site