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: <20140414173947.GA25057@sackheads.org>
Date:	Mon, 14 Apr 2014 13:39:48 -0400
From:	Jimmie Mayfield <jimmie@...kheads.org>
To:	linux-kernel@...r.kernel.org
Subject: Basic questions regarding del_timer_sync() and re-registering
	timers


Hi.  The common wisdom when mixing del_timer_sync() with timer functions
that re-register themselves is that the caller must ensure that re-registration
does not happen.

>From timer.c:
 * Synchronization rules: Callers must prevent restarting of the timer,
 * otherwise this function is meaningless.

I'm curious if someone could briefly explain why?

The pseudo-code for del_timer_sync and try_to_del_timer_sync looks 
something like this (ignoring the lock manipulation):

while (1) {
	if (timer is not running) {
		if timer is pending then detach it
		break
	}
	else {
		sleep
	}
}

So that the loop continues to spin until the timer function is no longer 
running at which point the kernel checks the pending list and removes it if 
necessary.

Q:  So given this construct, why is it imperative that the timer 
    function not re-register itself?  

I could understand that restriction if the timer function might be running on 
another CPU when the "if timer is pending then detach" step is executed but 
it's not obvious to me how that's possible since base->lock is owned at 
that point (not shown in the pseudocode)?

Can someone briefly point out what I've missed?


(while I am subscribed to LKML, please cc: me on replies so that they don't
get lost in the noise)

JM

-- 
Jimmie Mayfield  

--
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ