diff options
author | Tejun Heo <tj@kernel.org> | 2013-02-27 17:03:35 -0800 |
---|---|---|
committer | Linus Torvalds <torvalds@linux-foundation.org> | 2013-02-27 19:10:13 -0800 |
commit | 9bb26bc1ffa32ec983860a5a66b6f291a875e39d (patch) | |
tree | e821dc2bc21d6a61ae086d4eb45890f9c9c37920 /lib/crc7.c | |
parent | 6cdae7416a1c45c2ce105a78187d9b7e8feb9e24 (diff) | |
download | linux-stable-9bb26bc1ffa32ec983860a5a66b6f291a875e39d.tar.gz linux-stable-9bb26bc1ffa32ec983860a5a66b6f291a875e39d.tar.bz2 linux-stable-9bb26bc1ffa32ec983860a5a66b6f291a875e39d.zip |
idr: make idr_destroy() imply idr_remove_all()
idr is silly in quite a few ways, one of which is how it's supposed to
be destroyed - idr_destroy() doesn't release IDs and doesn't even whine
if the idr isn't empty. If the caller forgets idr_remove_all(), it
simply leaks memory.
Even ida gets this wrong and leaks memory on destruction. There is
absoltely no reason not to call idr_remove_all() from idr_destroy().
Nobody is abusing idr_destroy() for shrinking free layer buffer and
continues to use idr after idr_destroy(), so it's safe to do remove_all
from destroy.
In the whole kernel, there is only one place where idr_remove_all() is
legitimiately used without following idr_destroy() while there are quite
a few places where the caller forgets either idr_remove_all() or
idr_destroy() leaking memory.
This patch makes idr_destroy() call idr_destroy_all() and updates the
function description accordingly.
Signed-off-by: Tejun Heo <tj@kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Diffstat (limited to 'lib/crc7.c')
0 files changed, 0 insertions, 0 deletions