All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ingo Molnar <mingo@kernel.org>
To: Sasha Levin <sasha.levin@oracle.com>
Cc: penberg@kernel.org, mingo@redhat.com, peterz@infradead.org,
	asias.hejun@gmail.com, tglx@linutronix.de, gorcunov@openvz.org,
	kvm@vger.kernel.org
Subject: Re: [RFC 2/3] lockdep: be nice about compiling from userspace
Date: Thu, 25 Oct 2012 10:05:02 +0200	[thread overview]
Message-ID: <20121025080502.GF3712@gmail.com> (raw)
In-Reply-To: <1351098010-20849-2-git-send-email-sasha.levin@oracle.com>


* Sasha Levin <sasha.levin@oracle.com> wrote:

> We can rather easily make lockdep work from userspace, although 3 issues
> remain which I'm not sure about:
> 
>  - Kernel naming - we can just wrap init_utsname() to return kvmtool related
> utsname, is that what we want though?
> 
>  - static_obj() - I don't have a better idea than calling mprobe(), which sounds
> wrong as well.
> 
>  - debug_show_all_locks() - we don't actually call it from userspace yet, but I think
> we might want to, so I'm not sure how to make it pretty using existing kernel code.
> 
> Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
> ---
>  kernel/lockdep.c | 9 +++++++--
>  1 file changed, 7 insertions(+), 2 deletions(-)
> 
> diff --git a/kernel/lockdep.c b/kernel/lockdep.c
> index 7981e5b..fdd3670 100644
> --- a/kernel/lockdep.c
> +++ b/kernel/lockdep.c
> @@ -567,10 +567,12 @@ static void lockdep_print_held_locks(struct task_struct *curr)
>  
>  static void print_kernel_ident(void)
>  {
> +#ifdef __KERNEL__
>  	printk("%s %.*s %s\n", init_utsname()->release,
>  		(int)strcspn(init_utsname()->version, " "),
>  		init_utsname()->version,
>  		print_tainted());
> +#endif

I guess wrapping init_utsname() is not worth it. Although 
kvmtool could provide the host system's utsname - kernel 
identity is useful for debugging info.

You could generate a Git hash version string like tools/perf/ 
does (see PERF_VERSION and tools/perf/util/PERF-VERSION-GEN), 
and put that into the ->version field.

->release could be the kvmtool version, and print_tainted() 
could return an empty string.

That way you could provide init_utsname() and could remove this 
#ifdef.

>  }
>  
>  static int very_verbose(struct lock_class *class)
> @@ -586,6 +588,7 @@ static int very_verbose(struct lock_class *class)
>   */
>  static int static_obj(void *obj)
>  {
> +#ifdef __KERNEL__
>  	unsigned long start = (unsigned long) &_stext,
>  		      end   = (unsigned long) &_end,
>  		      addr  = (unsigned long) obj;
> @@ -609,6 +612,8 @@ static int static_obj(void *obj)
>  	 * module static or percpu var?
>  	 */
>  	return is_module_address(addr) || is_module_percpu_address(addr);
> +#endif
> +	return 1;

Could you put an:

#ifndef static_obj

around it? Then kvmtool could define its own trivial version of 
static_obj():

  #define static_obj(x) 1U

or so.

> @@ -4108,7 +4113,7 @@ void debug_check_no_locks_held(struct task_struct *task)
>  	if (unlikely(task->lockdep_depth > 0))
>  		print_held_locks_bug(task);
>  }
> -
> +#ifdef __KERNEL__
>  void debug_show_all_locks(void)
>  {
>  	struct task_struct *g, *p;

I guess a show-all-locks functionality would be useful to 
kvmtool as well?

Thanks,

	Ingo

  reply	other threads:[~2012-10-25  8:05 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-10-24 17:00 [RFC 1/3] kvm tools: use mutex abstraction instead of pthread mutex Sasha Levin
2012-10-24 17:00 ` [RFC 2/3] lockdep: be nice about compiling from userspace Sasha Levin
2012-10-25  8:05   ` Ingo Molnar [this message]
2012-10-25 16:58     ` Sasha Levin
2012-10-25 17:06       ` Ingo Molnar
2012-10-25 19:17         ` Sasha Levin
2012-10-24 17:00 ` [RFC 3/3] kvm tools: use lockdep to detect locking issues Sasha Levin
2012-10-25  6:50 ` [RFC 1/3] kvm tools: use mutex abstraction instead of pthread mutex Pekka Enberg

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=20121025080502.GF3712@gmail.com \
    --to=mingo@kernel.org \
    --cc=asias.hejun@gmail.com \
    --cc=gorcunov@openvz.org \
    --cc=kvm@vger.kernel.org \
    --cc=mingo@redhat.com \
    --cc=penberg@kernel.org \
    --cc=peterz@infradead.org \
    --cc=sasha.levin@oracle.com \
    --cc=tglx@linutronix.de \
    /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.