forked from Minki/linux
idr: explain WARN_ON_ONCE() on negative IDs out-of-range ID
Until recently, when an negative ID is specified, idr functions used to ignore the sign bit and proceeded with the operation with the rest of bits, which is bizarre and error-prone. The behavior recently got changed so that negative IDs are treated as invalid but we're triggering WARN_ON_ONCE() on negative IDs just in case somebody was depending on the sign bit being ignored, so that those can be detected and fixed easily. We only need this for a while. Explain why WARN_ON_ONCE()s are there and that they can be removed later. Signed-off-by: Tejun Heo <tj@kernel.org> Acked-by: Thomas Gleixner <tglx@linutronix.de> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
This commit is contained in:
parent
0ffc2a9c80
commit
7175c61cc6
10
lib/idr.c
10
lib/idr.c
@ -569,6 +569,7 @@ void idr_remove(struct idr *idp, int id)
|
||||
struct idr_layer *p;
|
||||
struct idr_layer *to_free;
|
||||
|
||||
/* see comment in idr_find_slowpath() */
|
||||
if (WARN_ON_ONCE(id < 0))
|
||||
return;
|
||||
|
||||
@ -666,6 +667,14 @@ void *idr_find_slowpath(struct idr *idp, int id)
|
||||
int n;
|
||||
struct idr_layer *p;
|
||||
|
||||
/*
|
||||
* If @id is negative, idr_find() used to ignore the sign bit and
|
||||
* performed lookup with the rest of bits, which is weird and can
|
||||
* lead to very obscure bugs. We're now returning NULL for all
|
||||
* negative IDs but just in case somebody was depending on the sign
|
||||
* bit being ignored, let's trigger WARN_ON_ONCE() so that they can
|
||||
* be detected and fixed. WARN_ON_ONCE() can later be removed.
|
||||
*/
|
||||
if (WARN_ON_ONCE(id < 0))
|
||||
return NULL;
|
||||
|
||||
@ -815,6 +824,7 @@ void *idr_replace(struct idr *idp, void *ptr, int id)
|
||||
int n;
|
||||
struct idr_layer *p, *old_p;
|
||||
|
||||
/* see comment in idr_find_slowpath() */
|
||||
if (WARN_ON_ONCE(id < 0))
|
||||
return ERR_PTR(-EINVAL);
|
||||
|
||||
|
Loading…
Reference in New Issue
Block a user