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 09:52:31 -0700
From:	Dmitry Torokhov <dmitry.torokhov@...il.com>
To:	Tejun Heo <tj@...nel.org>
Cc:	Borislav Petkov <bp@...en8.de>,
	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 12:33:30PM -0400, Tejun Heo wrote:
> Hello, Borislav.
> 
> On Thu, Mar 19, 2015 at 05:23:02PM +0100, Borislav Petkov wrote:
> > 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.
> 
> You understand that there are technical reasons behind the current
> behavior?  This is not something people just did on a whim.  We used
> to have autounload and all that but over time moved away from it
> because the trade-offs around the behavior shifted.
> 
> I don't get why you don't understand this.  As a general rule, we
> don't go and implement one-off behaviors like this because it's well
> understood that things like this are more costly in the longer term.
> As said multiple times before, if you think this is a class of problem
> worth solving, do so properly.  Please stop shell scripting in your
> ->probe() in kernel.
> 
> > 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.
> 
> Please don't.  Consider it nacked preemptively.  If you want to solve
> this and can justify the added complexity, solve it in a general way -
> teach it to the driver model.

I do not think you can teach it to the driver model in general: there is
no definite point when probing is "done". The drivers and devices come
and go, at random moments in time.

So here the driver just assumes that all devices will be enumerated
before the driver is loaded and acts upon this knowledge. The whole
schema is fragile (I mean can I compile it in the kernel and see
breaking because of  link order changes and driver is now initialized
before PCI devices are scanned? Possibly...).

Thanks.

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