linux-kernel - Re: + posix_timers-remove-dead-task-timer-expiry-caching.patch added to -mm tree

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]

Message-ID: <CAFTL4hxGUPudBNuX8a68CFkM80aKr1M74A4SODZJzj7bypcavw@mail.gmail.com>
Date:	Wed, 17 Apr 2013 03:34:27 +0200
From:	Frederic Weisbecker <fweisbec@...il.com>
To:	akpm@...ux-foundation.org
Cc:	mm-commits@...r.kernel.org, a.p.zijlstra@...llo.nl, mingo@...e.hu,
	oleg@...hat.com, sgruszka@...hat.com, tglx@...utronix.de,
	LKML <linux-kernel@...r.kernel.org>
Subject: Re: + posix_timers-remove-dead-task-timer-expiry-caching.patch added
 to -mm tree

2013/4/9  <akpm@...ux-foundation.org>:
>
> The patch titled
>      Subject: posix_timers: Remove dead task timer expiry caching
> has been added to the -mm tree.  Its filename is
>      posix_timers-remove-dead-task-timer-expiry-caching.patch
>
> Before you just go and hit "reply", please:
>    a) Consider who else should be cc'ed
>    b) Prefer to cc a suitable mailing list as well
>    c) Ideally: find the original patch on the mailing list and do a
>       reply-to-all to that, adding suitable additional cc's
>
> *** Remember to use Documentation/SubmitChecklist when testing your code ***
>
> The -mm tree is included into linux-next and is updated
> there every 3-4 working days
>
> ------------------------------------------------------
> From: Frederic Weisbecker <fweisbec@...il.com>
> Subject: posix_timers: Remove dead task timer expiry caching
>
> When reading a timer sample, posix_cpu_timer_get() and
> posix_cpu_timer_schedule() both perform a caching of the timer expiry time
> by converting its value from absolute to relative if the task has exited.
>
> The reason for this caching is not clear though, it could be:
>
> 1) For performance reasons: no need to calculate the delta after the
>    task has died, its cputime won't change anymore.  We can thus avoid
>    some locking (sighand, tasklist_lock, rq->lock for task_delta_exec(),
>    ...), and various operations to calculate the sample...
>
> 2) To keep the remaining delta for the timer available after the task
>    has died.  When it gets reaped, its sighand disappears, so accessing
>    the process wide cputime through tsk->signal is probably not safe.
>
> Now, is the first reason really worth it?  I have no idea if it is a case
> we really want to optimize.
>
> Considering the second reason, we return a disarmed zero'ed timer when
> tsk->sighand == NULL.  So if this is an assumed reason, it's broken.  And
> this case only concern process wide timers that have their group leader
> reaped.  The posix cpu timer shouldn't even be available anymore at that
> time.  Unless the group leader changed since we called
> posix_cpu_timer_create() after an exec?
>
> Anyway for now I'm sending this as an RFC because there may well be subtle
> things I left behind.
>
> Signed-off-by: Frederic Weisbecker <fweisbec@...il.com>
> Cc: Stanislaw Gruszka <sgruszka@...hat.com>
> Cc: Thomas Gleixner <tglx@...utronix.de>
> Cc: Peter Zijlstra <a.p.zijlstra@...llo.nl>
> Cc: Ingo Molnar <mingo@...e.hu>
> Cc: Oleg Nesterov <oleg@...hat.com>
> Signed-off-by: Andrew Morton <akpm@...ux-foundation.org>

So this very patch probably shouldn't go to 3.10, I sent it early in
case I could get some hindsight from reviewers.
Anyway, let me some time to think more about it and all the possible
implications against exit, de_thread, etc... then I'll resend if that
sounds palatable.

Thanks.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/