[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-Id: <20140323150557.288925975@linutronix.de>
Date: Sun, 23 Mar 2014 15:09:24 -0000
From: Thomas Gleixner <tglx@...utronix.de>
To: LKML <linux-kernel@...r.kernel.org>
Cc: Julia Lawall <Julia.Lawall@...6.fr>,
Andrew Morton <akpm@...ux-foundation.org>
Subject: [patch 00/16] timers: Plug debugobject leaks and use del_timer_sync()
in exit/teardown
Timers on stack must be initialized with init_timer_on_stack() which
creates a tracking object if DEBUG_OBJECTS is enabled. Quite some
places miss the complementary destroy_timer_on_stack(), which frees the
tracking object. So we leak the tracking object in the debug objects
store.
While looking at that, one affected driver also used del_timer()
instead of del_timer_sync() before returning, which is wrong as well
as del_timer() meriliy dequeues an armed timer, but does not wait for
a callback which is executed on a different cpu.
So I started to look through del_timer() sites and fixed a bunch of
obvious teardown, module exit pathes which must use del_timer_sync().
As I'm about to travel, I gave up on reviewing all the usage sites of
del_timer().
Maybe Julia has an idea to automate the scan a bit. The paring for
init_timer_on_stack/destroy_timer_on_stack should be easy enough, but
the del_timer() one is pretty complex and definitly needs manual
auditing, but having a scan assistant to identify potential places
would be definitely helpful.
Thanks,
tglx
---
drivers/atm/firestream.c | 2 +-
drivers/atm/idt77105.c | 6 +++---
drivers/block/cpqarray.c | 2 +-
drivers/block/umem.c | 2 +-
drivers/block/xsysace.c | 2 ++
drivers/bluetooth/bluecard_cs.c | 2 +-
drivers/bluetooth/hci_bcsp.c | 2 +-
drivers/bluetooth/hci_h5.c | 2 +-
drivers/cpufreq/intel_pstate.c | 2 +-
drivers/input/serio/hp_sdc.c | 2 +-
drivers/s390/char/tape_std.c | 3 ++-
drivers/s390/net/lcs.c | 1 +
drivers/scsi/qla1280.c | 1 +
drivers/thermal/intel_powerclamp.c | 1 +
kernel/rcu/torture.c | 4 +++-
15 files changed, 21 insertions(+), 13 deletions(-)
--
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