LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
* [PATCH] tools/liblockdep: Fix debug_check thinko in mutex destroy
@ 2014-12-08 11:07 Kirill Smelkov
  2014-12-08 14:59 ` Sasha Levin
  0 siblings, 1 reply; 4+ messages in thread
From: Kirill Smelkov @ 2014-12-08 11:07 UTC (permalink / raw)
  To: Sasha Levin; +Cc: Ingo Molnar, linux-kernel, Kirill Smelkov

In mutex destroy code currently we pass to debug_check_no_locks_freed()

    [mem_from, mem_end)

address region. But debug_check_no_locks_freed() accepts

    mem_from, mem_*len*

i.e. second parameter is region length, not end address. And it was
always so, starting from 2006 (fbb9ce95 "lockdep: core").

Fix it, or else on a mutex destroy we wrongly check
much-wider-than-mutex region and can find not-yet-released other locks
there and wrongly report BUGs on them.

Signed-off-by: Kirill Smelkov <kirr@nexedi.com>
---
 tools/lib/lockdep/preload.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/tools/lib/lockdep/preload.c b/tools/lib/lockdep/preload.c
index 6f80360..0b0112c 100644
--- a/tools/lib/lockdep/preload.c
+++ b/tools/lib/lockdep/preload.c
@@ -317,7 +317,7 @@ int pthread_mutex_destroy(pthread_mutex_t *mutex)
 	 *
 	 * TODO: Hook into free() and add that check there as well.
 	 */
-	debug_check_no_locks_freed(mutex, mutex + sizeof(*mutex));
+	debug_check_no_locks_freed(mutex, sizeof(*mutex));
 	__del_lock(__get_lock(mutex));
 	return ll_pthread_mutex_destroy(mutex);
 }
@@ -341,7 +341,7 @@ int pthread_rwlock_destroy(pthread_rwlock_t *rwlock)
 {
 	try_init_preload();
 
-	debug_check_no_locks_freed(rwlock, rwlock + sizeof(*rwlock));
+	debug_check_no_locks_freed(rwlock, sizeof(*rwlock));
 	__del_lock(__get_lock(rwlock));
 	return ll_pthread_rwlock_destroy(rwlock);
 }
-- 
2.2.0.309.gc3c329f

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: [PATCH] tools/liblockdep: Fix debug_check thinko in mutex destroy
  2014-12-08 11:07 [PATCH] tools/liblockdep: Fix debug_check thinko in mutex destroy Kirill Smelkov
@ 2014-12-08 14:59 ` Sasha Levin
  2014-12-14 14:21   ` Kirill Smelkov
  0 siblings, 1 reply; 4+ messages in thread
From: Sasha Levin @ 2014-12-08 14:59 UTC (permalink / raw)
  To: Kirill Smelkov; +Cc: Ingo Molnar, linux-kernel

On 12/08/2014 06:07 AM, Kirill Smelkov wrote:
> In mutex destroy code currently we pass to debug_check_no_locks_freed()
> 
>     [mem_from, mem_end)
> 
> address region. But debug_check_no_locks_freed() accepts
> 
>     mem_from, mem_*len*
> 
> i.e. second parameter is region length, not end address. And it was
> always so, starting from 2006 (fbb9ce95 "lockdep: core").
> 
> Fix it, or else on a mutex destroy we wrongly check
> much-wider-than-mutex region and can find not-yet-released other locks
> there and wrongly report BUGs on them.

Great catch, thanks!


Thanks,
Sasha

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: [PATCH] tools/liblockdep: Fix debug_check thinko in mutex destroy
  2014-12-08 14:59 ` Sasha Levin
@ 2014-12-14 14:21   ` Kirill Smelkov
  2014-12-14 14:30     ` Sasha Levin
  0 siblings, 1 reply; 4+ messages in thread
From: Kirill Smelkov @ 2014-12-14 14:21 UTC (permalink / raw)
  To: Sasha Levin; +Cc: Ingo Molnar, linux-kernel

On Mon, Dec 08, 2014 at 09:59:54AM -0500, Sasha Levin wrote:
> On 12/08/2014 06:07 AM, Kirill Smelkov wrote:
> > In mutex destroy code currently we pass to debug_check_no_locks_freed()
> > 
> >     [mem_from, mem_end)
> > 
> > address region. But debug_check_no_locks_freed() accepts
> > 
> >     mem_from, mem_*len*
> > 
> > i.e. second parameter is region length, not end address. And it was
> > always so, starting from 2006 (fbb9ce95 "lockdep: core").
> > 
> > Fix it, or else on a mutex destroy we wrongly check
> > much-wider-than-mutex region and can find not-yet-released other locks
> > there and wrongly report BUGs on them.
> 
> Great catch, thanks!

Thanks, where is this patch is/will-be applied?

I mean I could not find it neither in

    git://git.kernel.org/pub/scm/linux/kernel/git/sashal/linux.git

nor anywhere in linux-next nor in Linus's tree.

Thanks,
Kirill

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: [PATCH] tools/liblockdep: Fix debug_check thinko in mutex destroy
  2014-12-14 14:21   ` Kirill Smelkov
@ 2014-12-14 14:30     ` Sasha Levin
  0 siblings, 0 replies; 4+ messages in thread
From: Sasha Levin @ 2014-12-14 14:30 UTC (permalink / raw)
  To: Kirill Smelkov; +Cc: Ingo Molnar, linux-kernel

On 12/14/2014 09:21 AM, Kirill Smelkov wrote:
> On Mon, Dec 08, 2014 at 09:59:54AM -0500, Sasha Levin wrote:
>> > On 12/08/2014 06:07 AM, Kirill Smelkov wrote:
>>> > > In mutex destroy code currently we pass to debug_check_no_locks_freed()
>>> > > 
>>> > >     [mem_from, mem_end)
>>> > > 
>>> > > address region. But debug_check_no_locks_freed() accepts
>>> > > 
>>> > >     mem_from, mem_*len*
>>> > > 
>>> > > i.e. second parameter is region length, not end address. And it was
>>> > > always so, starting from 2006 (fbb9ce95 "lockdep: core").
>>> > > 
>>> > > Fix it, or else on a mutex destroy we wrongly check
>>> > > much-wider-than-mutex region and can find not-yet-released other locks
>>> > > there and wrongly report BUGs on them.
>> > 
>> > Great catch, thanks!
> Thanks, where is this patch is/will-be applied?
> 
> I mean I could not find it neither in
> 
>     git://git.kernel.org/pub/scm/linux/kernel/git/sashal/linux.git
> 
> nor anywhere in linux-next nor in Linus's tree.

I'll send it to Ingo once v3.19-rc1 is out.


Thanks,
Sasha

^ permalink raw reply	[flat|nested] 4+ messages in thread

end of thread, other threads:[~2014-12-14 14:31 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2014-12-08 11:07 [PATCH] tools/liblockdep: Fix debug_check thinko in mutex destroy Kirill Smelkov
2014-12-08 14:59 ` Sasha Levin
2014-12-14 14:21   ` Kirill Smelkov
2014-12-14 14:30     ` Sasha Levin

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).