linux-kernel - Re: [PATCH 3/3] EDAC: amd64_edac: decide if driver can load successfully early.

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Thu, 19 Mar 2015 17:23:02 +0100
From:	Borislav Petkov <bp@...en8.de>
To:	Dmitry Torokhov <dmitry.torokhov@...il.com>,
	Tejun Heo <tj@...nel.org>
Cc:	Doug Thompson <dougthompson@...ssion.com>,
	linux-kernel@...r.kernel.org, linux-edac@...r.kernel.org,
	Mauro Carvalho Chehab <mchehab@....samsung.com>,
	Tetsuo Handa <penguin-kernel@...ove.SAKURA.ne.jp>,
	Olof Johansson <olof@...om.net>,
	Arjan van de Ven <arjan@...ux.intel.com>,
	Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
	"Luis R . Rodriguez" <mcgrof@...e.com>
Subject: Re: [PATCH 3/3] EDAC: amd64_edac: decide if driver can load
 successfully early.

On Thu, Mar 19, 2015 at 09:12:26AM -0700, Dmitry Torokhov wrote:
> By the same token it only makes sense to load e1000e when I have e1000e
> device loaded, but we allow it to load anyway. Or psmouse. Or pretty
> much any other drivers (sans some platform code). The fact is that we
> for long time have separated module loading and driver binding. Loading
> driver even without the devices is standard behavior.

FWIW, I always hated that.

> Does anyone look at the loaded modules to see if functionality is
> available? They should look if any devices are actually bound to the
> driver (in sysfs). I mean, even without the changes I can unbind the
> edac driver from northbridge via sysfs thus disabling error decoding and
> "mislead" people.

Yeah yeah, do people listen to what we say how something should be used
properly and not use it the way they feel like? Of course not!

But enough wasting time fruitlessly, I think I have an idea:

How about I go and iterate over all NBs (northbridges) on the system and
check whether at least one has ECC enabled so that the driver can load?
And do that in the init function.

If I detect at least one NB which is ok, I can then continue and do
pci_register_driver(). If there are no suitable NBs, I return an error
and don't even touch PCI.

Would that be something which would work for what you're trying to
achieve?

If yes, I could give it a try but it won't happen like immediately. For
the time being, we could use the PROBE_FORCE_SYNCHRONOUS thing.

While doing that, I could take a look at Dmitry's cleanups too.

Yes, no?

Thanks.

-- 
Regards/Gruss,
    Boris.

ECO tip #101: Trim your mails when you reply.
--
--
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/