]> err.no Git - linux-2.6/commit
lockdep: in_range() fix
authorOleg Nesterov <oleg@tv-sign.ru>
Wed, 5 Dec 2007 14:46:09 +0000 (15:46 +0100)
committerIngo Molnar <mingo@elte.hu>
Wed, 5 Dec 2007 14:46:09 +0000 (15:46 +0100)
commit54561783ee99d73a086f3abbda3e44f87f6bf65b
tree73f836a158f9c05ece41cae6cdb80888d9d6ba07
parent856848737bd944c1db3ce0a66bbf67e56bd6f77d
lockdep: in_range() fix

Torsten Kaiser wrote:

| static inline int in_range(const void *start, const void *addr, const void *end)
| {
|         return addr >= start && addr <= end;
| }
| This  will return true, if addr is in the range of start (including)
| to end (including).
|
| But debug_check_no_locks_freed() seems does:
| const void *mem_to = mem_from + mem_len
| -> mem_to is the last byte of the freed range, that fits in_range
| lock_from = (void *)hlock->instance;
| -> first byte of the lock
| lock_to = (void *)(hlock->instance + 1);
| -> first byte of the next lock, not last byte of the lock that is being checked!
|
| The test is:
| if (!in_range(mem_from, lock_from, mem_to) &&
|                                         !in_range(mem_from, lock_to, mem_to))
|                         continue;
| So it tests, if the first byte of the lock is in the range that is freed ->OK
| And if the first byte of the *next* lock is in the range that is freed
| -> Not OK.

We can also simplify in_range checks, we need only 2 comparisons, not 4.
If the lock is not in memory range, it should be either at the left of range
or at the right.

Signed-off-by: Oleg Nesterov <oleg@tv-sign.ru>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
Signed-off-by: Peter Zijlstra <a.p.zijlstra@chello.nl>
kernel/lockdep.c