[patch 00/16] timers: Plug debugobject leaks and use del_timer_sync() in exit/teardown

[Thomas Gleixner]

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@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/