linux-kernel - Re: [PATCHv3 3/3] edac: altera: Add EDAC support for Altera SDRAM

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]

Date:	Fri, 9 May 2014 15:52:59 +0200
From:	Borislav Petkov <bp@...en8.de>
To:	Thor Thayer <tthayer.linux@...il.com>
Cc:	Thor Thayer <tthayer@...era.com>,
	Rob Herring <robherring2@...il.com>, pawel.moll@....com,
	mark.rutland@....com, ijc+devicetree@...lion.org.uk,
	Kumar Gala <galak@...eaurora.org>,
	Rob Landley <rob@...dley.net>, linux@....linux.org.uk,
	Dinh Nguyen <dinguyen@...era.com>, dougthompson@...ssion.com,
	Grant Likely <grant.likely@...aro.org>,
	devicetree@...r.kernel.org, linux-doc@...r.kernel.org,
	linux-edac@...r.kernel.org, linux-kernel@...r.kernel.org,
	linux-arm-kernel@...ts.infradead.org
Subject: Re: [PATCHv3 3/3] edac: altera: Add EDAC support for Altera SDRAM

On Thu, May 08, 2014 at 03:37:19PM -0500, Thor Thayer wrote:
> Yes. Their reasoning is that they want to retain the rights and
> warranty language with the file (just in case the COPYING file
> changes).

Ok, thanks for checking up on this.

> Yes. I tested using edac_core.edac_mc_panic_on_ue=1 from the command
> line and it worked fine. I'll add a comment to clarify. BTW, thanks
> for your help on that.

Sure, but the question still remains: do you want to panic on
uncorrectable errors by default or want the user to decide? I guess this
is something you can answer for your hardware...

> I considered using "volatile" variables, but decided against it after
> I read Documentation/volatile-considered-harmful.txt and my situation
> doesn't fit into the exemptions. Is there a better way to handle this?

Off the top of my head, I'd first look at compiler asm output to
check what my compiler does with those writes and then take a look at
employing the ACCESS_ONCE macro or something similar where we use the
asm volatile() as an optimization stop for the compiler, among others.

And then I'll look at asm again to make sure it does what it is supposed
to do. Something to that effect, in any case...

HTH.

-- 
Regards/Gruss,
    Boris.

Sent from a fat crate under my desk. Formatting is fine.
--
--
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/