linux-kernel - Re: [PATCH] fix unsafe operation in high resolution timer

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]

Message-ID: <AANLkTimWTKsRnL_=kiD-8Nc7Gc2SeW024TdWCYChXJdP@mail.gmail.com>
Date:	Wed, 29 Dec 2010 23:43:03 +0800
From:	Hillf Danton <dhillf@...il.com>
To:	Yong Zhang <yong.zhang0@...il.com>
Cc:	Thomas Gleixner <tglx@...utronix.de>, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] fix unsafe operation in high resolution timer

On Sun, Dec 26, 2010 at 9:12 PM, Yong Zhang <yong.zhang0@...il.com> wrote:
> On Sat, Dec 25, 2010 at 10:19:11PM +0800, Hillf Danton wrote:
>> > But for a hrtimer which is not free in its callback, like a
>> > static defined one. the hrtimer could be referenced at the same
>> > time. So here you cann't just delete the two lines.
>>
>> After callback, as you agree, it is hard to determine in the current
>> implementation if the hrtimer is static defined, though another bit
>> could be added, say, in the flag word of hrtimer
>
> Yeah, that is an option, like a flag FREE_IN_CALLBACK/ONESHOT which
> indicate that. Or just let the callback return another value like
> HRTIMER_FREED. But as I said before I'm not sure what's the best way
> to fix that. And maybe there's more suitable method.
>
> BTW, is there any user who free the hrtimer in its callback?
>
>> , so cutting the two
>> lines off is deserved.
>> And more, who will take care of the NORESTART again after callback?
>
> It's not related to NORESTART, just HRTIMER_STATE_CALLBACK.
> hrtimer'strategy somehow depends on HRTIMER_STATE_CALLBACK.
> You can take a look at the caller of hrtimer_callback_running().
>

Then the callback is responsible for signaling correctly.
Hillf
---

--- a/include/linux/hrtimer.h	2010-11-01 19:54:12.000000000 +0800
+++ b/include/linux/hrtimer.h	2010-12-29 23:43:16.000000000 +0800
@@ -44,6 +44,7 @@ enum hrtimer_mode {
 enum hrtimer_restart {
 	HRTIMER_NORESTART,	/* Timer is not restarted */
 	HRTIMER_RESTART,	/* Timer must be restarted */
+	HRTIMER_RECLAIM,	/* Timer is recycled */
 };

 /*
--- a/kernel/hrtimer.c	2010-11-01 19:54:12.000000000 +0800
+++ b/kernel/hrtimer.c	2010-12-29 23:45:48.000000000 +0800
@@ -1225,9 +1225,13 @@ static void __run_hrtimer(struct hrtimer
 	raw_spin_unlock(&cpu_base->lock);
 	trace_hrtimer_expire_entry(timer, now);
 	restart = fn(timer);
+	if (restart != HRTIMER_RECLAIM)
 	trace_hrtimer_expire_exit(timer);
 	raw_spin_lock(&cpu_base->lock);

+	if (restart == HRTIMER_RECLAIM)
+		return;
+
 	/*
 	 * Note: We clear the CALLBACK bit after enqueue_hrtimer and
 	 * we do not reprogramm the event hardware. Happens either in
--
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/