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]

Message-ID: <CAF03EBeKbXr-7+qeARkBRXjystMjs4yEWnmw7q8tgJv9-SPgXA@mail.gmail.com>
Date:	Fri, 9 May 2014 15:31:53 -0500
From:	Thor Thayer <tthayer.linux@...il.com>
To:	Borislav Petkov <bp@...en8.de>
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 Fri, May 9, 2014 at 8:52 AM, Borislav Petkov <bp@...en8.de> wrote:
> 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...

Yes, good point. Our hardware can't recover from Double Bit Errors so
I'll go back to the panic() in that path. I like the flexibility of
the command line parameter though...

>
>> 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.

The reads aren't optimized out now but I'd like to protect against
future optimization changes. I implemented ACCESS_ONCE and checked the
resulting asm output - it looks clean. Thanks.

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