[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20190821155125.GB22020@lenoir>
Date: Wed, 21 Aug 2019 17:51:25 +0200
From: Frederic Weisbecker <frederic@...nel.org>
To: Thomas Gleixner <tglx@...utronix.de>
Cc: LKML <linux-kernel@...r.kernel.org>,
Oleg Nesterov <oleg@...hat.com>,
Ingo Molnar <mingo@...nel.org>,
Peter Zijlstra <peterz@...radead.org>,
John Stultz <john.stultz@...aro.org>,
Frederic Weisbecker <fweisbec@...il.com>,
Anna-Maria Behnsen <anna-maria@...utronix.de>
Subject: Re: [patch 04/44] posix-cpu-timers: Fixup stale comment
On Wed, Aug 21, 2019 at 03:31:39PM +0200, Thomas Gleixner wrote:
> On Wed, 21 Aug 2019, Frederic Weisbecker wrote:
> > 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.
Ah right, there can be concurrent owners, nevermind.
Powered by blists - more mailing lists