linux-kernel - RE: [PATCH v2] Fix EDAC sdram_scrub

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: <987664A83D2D224EAE907B061CE93D5301EAB8A5C8@orsmsx505.amr.corp.intel.com>
Date:	Mon, 19 Sep 2011 13:23:35 -0700
From:	"Luck, Tony" <tony.luck@...el.com>
To:	Borislav Petkov <bp@...64.org>, Han Pingtian <phan@...hat.com>
CC:	"mchehab@...hat.com" <mchehab@...hat.com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	edac-devel <linux-edac@...r.kernel.org>
Subject: RE: [PATCH v2] Fix EDAC sdram_scrub_rate read/write failure

> @Tony, do you think the above makes sense? Anything against changing
> that part of the EDAC API to say:

> Sdram memory scrubbing rate:

>     If configuration fails or memory scrubbing is not implemented,
>	the access to that attribute from userspace will fail.

Ideally we'd not have the file there at all if memory scrubbing isn't
implemented.

I like having the write fail if the driver cannot set the chosen
scrub rate ... though there seems to be some wiggle room ... scrub
rates aren't exact, the user can try to set one and then read back
to find out what the rate was actually rounded to. If you have to
read back anyway, then reading back to find out if you failed doesn't
look quite so odd (still odd, but with some sort of logic).

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