lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20081027154301.GM5704@elte.hu>
Date:	Mon, 27 Oct 2008 16:43:01 +0100
From:	Ingo Molnar <mingo@...e.hu>
To:	Frederic Weisbecker <fweisbec@...il.com>
Cc:	Steven Rostedt <rostedt@...dmis.org>,
	Linux Kernel <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] [RESEND v2] tracing/ftrace: Introduce the big kernel
	lock tracer


* Frederic Weisbecker <fweisbec@...il.com> wrote:

> diff --git a/lib/kernel_lock.c b/lib/kernel_lock.c
> index 01a3c22..45828b2 100644
> --- a/lib/kernel_lock.c
> +++ b/lib/kernel_lock.c
> @@ -9,6 +9,7 @@
>  #include <linux/module.h>
>  #include <linux/kallsyms.h>
>  #include <linux/semaphore.h>
> +#include <trace/bkl.h>
>  
>  /*
>   * The 'big kernel lock'
> @@ -107,6 +108,37 @@ static inline void __unlock_kernel(void)
>  	preempt_enable();
>  }
>  
> +#ifdef CONFIG_BKL_TRACER
> +static void lock_kernel_trace(void)
> +{
> +	int cpu;
> +	struct bkl_trace_acquire trace;
> +
> +	preempt_disable();
> +	cpu = raw_smp_processor_id();
> +	preempt_enable();
> +
> +	trace.acquire_req_time = cpu_clock(cpu);
> +	__lock_kernel();
> +	trace.acquire_time = cpu_clock(cpu);
> +	trace_bkl_acquire(&trace);
> +}
> +
> +static void unlock_kernel_trace(void)
> +{
> +	struct bkl_trace_release trace;
> +	trace.release_time = cpu_clock(raw_smp_processor_id());
> +	trace_bkl_release(&trace);
> +	__unlock_kernel();
> +}
> +
> +#else
> +
> +#define lock_kernel_trace() __lock_kernel()
> +#define unlock_kernel_trace() __unlock_kernel()
> +
> +#endif

hm, this looks a bit ugly.

are you aware of the tip/kill-the-BKL branch? It's an old-ish but 
otherwise sane branch that needs some refreshing (hence it's not part 
of tip/master).

Once we have that "kill the BKL by turning it into a mutex" feature 
alive, and have fixed the places that rely on odd properties of the 
BKL, the BKL becomes just an ordinary mutex and we could trace its 
latencies via the existing lockdep/lockstat callbacks.

and we could trace all the other mutexes as well.

	Ingo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ