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: <20090501115047.GA24706@elte.hu>
Date:	Fri, 1 May 2009 13:50:47 +0200
From:	Ingo Molnar <mingo@...e.hu>
To:	Steven Rostedt <rostedt@...dmis.org>
Cc:	linux-kernel@...r.kernel.org,
	Andrew Morton <akpm@...ux-foundation.org>,
	Frederic Weisbecker <fweisbec@...il.com>
Subject: Re: [PATCH 3/3] ring-buffer: make cpu buffer entries counter atomic


* Steven Rostedt <rostedt@...dmis.org> wrote:

> From: Steven Rostedt <srostedt@...hat.com>
> 
> The entries counter in cpu buffer is not atomic. Although it only 
> gets updated by a single CPU, interrupts may come in and update 
> the counter too. This would cause missing entries to be added.

> -	unsigned long			entries;
> +	atomic_t			entries;

Hm, that's not really good as atomics can be rather expensive and 
this is the fastpath.

This is the upteenth time or so that the fact that we do not disable 
irqs while generating trace entries bites us in one way or another. 
IRQs can come in and confuse function trace output, etc. etc.

Please lets do what i suggested a long time ago: disable irqs _once_ 
in any trace point and run atomically from that point on, and enable 
them once, at the end.

The cost is very small and it turns into a win immediately by 
elimination of a _single_ atomic instruction. (even on Nehalem they 
cost 20 cycles. More on older CPUs.) We can drop the preempt-count 
disable/enable as well and a lot of racy code as well. Please.

	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