summaryrefslogtreecommitdiffstats
path: root/lib/iomap_copy.c
diff options
context:
space:
mode:
authorTejun Heo <tj@kernel.org>2013-03-08 12:43:30 -0800
committerLinus Torvalds <torvalds@linux-foundation.org>2013-03-08 15:05:34 -0800
commit2e1c9b2867656ff9a469d23e1dfe90cf77ec0c72 (patch)
treeb1f8c8a5fde730b2e3c71239e125e451df039fa5 /lib/iomap_copy.c
parent7880639c3e4fde5953ff243ee52204ddc5af641b (diff)
downloadlinux-2e1c9b2867656ff9a469d23e1dfe90cf77ec0c72.tar.gz
linux-2e1c9b2867656ff9a469d23e1dfe90cf77ec0c72.tar.bz2
linux-2e1c9b2867656ff9a469d23e1dfe90cf77ec0c72.zip
idr: remove WARN_ON_ONCE() on negative IDs
idr_find(), idr_remove() and idr_replace() used to silently ignore the sign bit and perform lookup with the rest of the bits. The weird behavior has been changed such that negative IDs are treated as invalid. As the behavior change was subtle, WARN_ON_ONCE() was added in the hope of determining who's calling idr functions with negative IDs so that they can be examined for problems. Up until now, all two reported cases are ID number coming directly from userland and getting fed into idr_find() and the warnings seem to cause more problems than being helpful. Drop the WARN_ON_ONCE()s. Signed-off-by: Tejun Heo <tj@kernel.org> Reported-by: <markus@trippelsdorf.de> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Diffstat (limited to 'lib/iomap_copy.c')
0 files changed, 0 insertions, 0 deletions