linux-kernel - Re: [PATCH] Fix WARN_ON / WARN_ON

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] [day] [month] [year] [list]

Message-Id: <200610061211.30184.ajwade@cpe001346162bf9-cm0011ae8cd564.cpe.net.cable.rogers.com>
Date:	Fri, 6 Oct 2006 12:11:27 -0400
From:	Andrew James Wade <andrew.j.wade@...il.com>
To:	Andrew Morton <akpm@...l.org>
Cc:	"Ananiev, Leonid I" <leonid.i.ananiev@...el.com>,
	tim.c.chen@...ux.intel.com,
	"Jeremy Fitzhardinge" <jeremy@...p.org>,
	herbert@...dor.apana.org.au, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] Fix WARN_ON / WARN_ON_ONCE regression

On Thursday 05 October 2006 17:37, Andrew Morton wrote:
> 
> So how's this look?
> 
> I worry a bit that someone's hardware might go and prefetch that static
> variable even when we didn't ask it to.  Can that happen?

     Branch mispredictions might cause spurious fetches. But the
unlikely() should take care of that for the (presumably common)
!__warned case.

> ...
> 
> It would seem logical to mark the static variable as __read_mostly too. But  
> it would be wrong, because that would put it back into the vmlinux image, and
> the kernel will never read from this variable in normal operation anyway. 

And if that's the case they should probably be in amongst write-hot
variables so as to reduce cache-line ping-ponging. __read_mostly should
probably be called __read_hot_write_cold, see
http://lkml.org/lkml/2006/6/26/290 .

> Unless the compiler or hardware go and do some prefetching on us?

The compiler doesn't, at least not GCC 4. I wouldn't expect it to
hoist loads out of non-loop blocks.

> For some reason this patch shrinks softirq.o text by 40 bytes.

The compiler optimizes out __ret_warn_once; it didn't do that before.

The patch looks good to me, though I am still baffled as to why the
cache misses were occurring.

Andrew Wade
-
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/