All of lore.kernel.org
 help / color / mirror / Atom feed
From: Peter Zijlstra <a.p.zijlstra@chello.nl>
To: Vegard Nossum <vegard.nossum@gmail.com>
Cc: Yong Zhang <yong.zhang0@gmail.com>,
	linux-kernel@vger.kernel.org, sergey.senozhatsky@gmail.com,
	bp@alien8.de, Ingo Molnar <mingo@elte.hu>,
	Tejun Heo <tj@kernel.org>, David Rientjes <rientjes@google.com>,
	casteyde.christian@free.fr
Subject: Re: [PATCH 1/4] lockdep: lock_set_subclass() fix
Date: Mon, 07 Nov 2011 17:10:29 +0100	[thread overview]
Message-ID: <1320682230.17809.11.camel@twins> (raw)
In-Reply-To: <CAOMGZ=EC0eHahfHy2K=5HwBwOCWEdF6u-mDaeLhb4GQVKVxLLA@mail.gmail.com>

On Mon, 2011-11-07 at 16:28 +0100, Vegard Nossum wrote:
> On 7 November 2011 13:34, Peter Zijlstra <a.p.zijlstra@chello.nl> wrote:
> > Arguably kmemcheck is on crack or so since both name and key pointers
> > should be in .data so there cannot be a leak by copying the thing over.
> 
> There is no leak, it's only about uninitialised memory.
> 
> The problem is that kmemcheck cannot track "initialisedness" of stack
> data and we're doing a heap-to-stack copy in process_one_work(), as
> Tejun pointed out:
> 
>         struct lockdep_map lockdep_map = work->lockdep_map;
> 
> This is of course fine in itself. But how can we tell kmemcheck that
> it's fine? There are basically two options:
> 
> 1. Initialise the thing completely before doing the copy, or
> 2. Ignore the warning.
> 
> The memset() patch (f59de8992aa6dc85e81aadc26b0f69e17809721d) attempts
> to do the first, i.e. to clear the whole struct in lockdep_init_map().
> 
> I think nr. 1 is the best way to go in principle, but I don't know
> what it takes for this to work properly. The blanket-clear memset()
> presumably doesn't work because it clears out something that was
> already initialised by the caller (right?).
> 
> Yong Zhang, can you think of a way to avoid the race you described,
> perhaps by memset()ing only the right/relevant parts of struct
> lockdep_map in lockdep_init_map()?

We could move the key and name pointer to the start of the structure and
memset everything after that, however wouldn't that leave kmemcheck with
the same problem? It wouldn't know those two pointers would be
initialized properly.

> Peter Zijlstra, if you prefer, we can also just tell kmemcheck that
> this particular copy is fine, but it means that kmemcheck will not be
> able to detect any real bugs in this code. It can be done with
> something like:

Something like this, although it would be best to come up with a nicer
way to write it..

---
 include/linux/lockdep.h |    2 +-
 kernel/lockdep.c        |    3 ++-
 2 files changed, 3 insertions(+), 2 deletions(-)

diff --git a/include/linux/lockdep.h b/include/linux/lockdep.h
index b6a56e3..7d66268 100644
--- a/include/linux/lockdep.h
+++ b/include/linux/lockdep.h
@@ -148,9 +148,9 @@ void clear_lock_stats(struct lock_class *class);
  * This is embedded into specific lock instances:
  */
 struct lockdep_map {
+	const char			*name;
 	struct lock_class_key		*key;
 	struct lock_class		*class_cache[NR_LOCKDEP_CACHING_CLASSES];
-	const char			*name;
 #ifdef CONFIG_LOCK_STAT
 	int				cpu;
 	unsigned long			ip;
diff --git a/kernel/lockdep.c b/kernel/lockdep.c
index e69434b..81855cf 100644
--- a/kernel/lockdep.c
+++ b/kernel/lockdep.c
@@ -2948,7 +2948,8 @@ static int mark_lock(struct task_struct *curr, struct held_lock *this,
 void lockdep_init_map(struct lockdep_map *lock, const char *name,
 		      struct lock_class_key *key, int subclass)
 {
-	memset(lock, 0, sizeof(*lock));
+	kmemcheck_mark_initialized(lock, 2*sizeof(void *));
+	memset(&lock->class_cache[0], 0, sizeof(*lock)-2*sizeof(void *));
 
 #ifdef CONFIG_LOCK_STAT
 	lock->cpu = raw_smp_processor_id();


  reply	other threads:[~2011-11-07 16:11 UTC|newest]

Thread overview: 31+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-11-04  9:26 [PATCH 0/4] patches to cure race in lock_set_class() Yong Zhang
2011-11-04  9:26 ` [PATCH 1/4] lockdep: lock_set_subclass() fix Yong Zhang
2011-11-07 12:34   ` Peter Zijlstra
2011-11-07 13:31     ` Yong Zhang
2011-11-07 14:03       ` Tejun Heo
2011-11-07 13:54     ` Borislav Petkov
2011-11-07 15:28     ` Vegard Nossum
2011-11-07 16:10       ` Peter Zijlstra [this message]
2011-11-07 16:21         ` Tejun Heo
2011-11-07 16:26           ` Peter Zijlstra
2011-11-08  2:58         ` Yong Zhang
2011-11-08  3:02           ` Yong Zhang
2011-11-08  7:56           ` Peter Zijlstra
2011-11-08  8:14             ` Yong Zhang
2011-11-08  8:46               ` Peter Zijlstra
2011-11-08  9:07                 ` Yong Zhang
2011-11-08  9:37                   ` Yong Zhang
2011-11-08  9:40                   ` Peter Zijlstra
2011-11-09  8:04                     ` [PATCH 1/2] lockdep: kmemcheck: annotate ->lock in lockdep_init_map() Yong Zhang
2011-11-09  8:07                       ` [PATCH 2/2] lockdep: always try to set ->class_cache in register_lock_class() lockdep_init_map() Yong Zhang
2011-11-18 23:39                         ` [tip:core/locking] lockdep: Always " tip-bot for Yong Zhang
2011-12-06  9:39                       ` [tip:core/locking] lockdep, kmemcheck: Annotate ->lock in lockdep_init_map() tip-bot for Yong Zhang
2011-12-06 19:56                         ` David Rientjes
2011-12-06 20:14                       ` [tip:perf/urgent] " tip-bot for Yong Zhang
2011-11-08  2:22       ` [PATCH 1/4] lockdep: lock_set_subclass() fix Yong Zhang
2011-11-04  9:26 ` [RFC PATCH 2/4] lockdep: Let register_lock_class() can be called with/without graph_lock Yong Zhang
2011-11-04  9:26 ` [RFC PATCH 3/4] lockdep: split lockdep_init_map() Yong Zhang
2011-11-04  9:26 ` [RFC PATCH 4/4] lockdep: fix race condition in __lock_set_class() Yong Zhang
2011-11-07 12:30   ` Peter Zijlstra
2011-11-07 13:26     ` Yong Zhang
2011-11-06 11:52 ` [PATCH 0/4] patches to cure race in lock_set_class() Borislav Petkov

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1320682230.17809.11.camel@twins \
    --to=a.p.zijlstra@chello.nl \
    --cc=bp@alien8.de \
    --cc=casteyde.christian@free.fr \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@elte.hu \
    --cc=rientjes@google.com \
    --cc=sergey.senozhatsky@gmail.com \
    --cc=tj@kernel.org \
    --cc=vegard.nossum@gmail.com \
    --cc=yong.zhang0@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.