summaryrefslogtreecommitdiff
path: root/lib/crc7.c
diff options
context:
space:
mode:
authorTejun Heo <tj@kernel.org>2013-02-27 17:03:35 -0800
committerLinus Torvalds <torvalds@linux-foundation.org>2013-02-27 19:10:13 -0800
commit9bb26bc1ffa32ec983860a5a66b6f291a875e39d (patch)
treee821dc2bc21d6a61ae086d4eb45890f9c9c37920 /lib/crc7.c
parent6cdae7416a1c45c2ce105a78187d9b7e8feb9e24 (diff)
downloadlinux-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