linux-kernel - Re: [RFC PATCH 12/13] driver core: firmware loader: use small timeout for cache device firmware

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: <20120727103551.GC14445@aftab.osrc.amd.com>
Date:	Fri, 27 Jul 2012 12:35:51 +0200
From:	Borislav Petkov <bp@...64.org>
To:	Ming Lei <ming.lei@...onical.com>
Cc:	Linus Torvalds <torvalds@...ux-foundation.org>,
	Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
	"Rafael J. Wysocki" <rjw@...k.pl>, linux-kernel@...r.kernel.org
Subject: Re: [RFC PATCH 12/13] driver core: firmware loader: use small
 timeout for cache device firmware

On Fri, Jul 27, 2012 at 09:54:25AM +0800, Ming Lei wrote:
> On Fri, Jul 27, 2012 at 1:54 AM, Borislav Petkov <bp@...64.org> wrote:
> 
> >> No, it is not what I was saying.
> 
> I just mean the point is not mentioned in my commit log, but I admit it should
> be a appropriate cause.
> 
> >
> > Ok, maybe I'm not understanding this then. So explain to me this: why
> > do you need that timeout value of 10, how did we decide it to be 10
> 
> If one firmware image was loaded successfully before, the probability of
> loading it successfully at this time should be much higher than the 1st time
> because something crazy(for example, the firmware is deleted) happens
> with low probability.

Believe it or not, I'm addressing exactly the possibility of the
firmware disappearing from under us in the AMD microcode driver
currently :) (and some other annoyances, of course).

> Choosing 10 secs is just a estimation for loading time because the maximum
> size of firmware in current distributions is about 2M bytes, since we know
> it has been loaded successfully before.

This is exactly the comment we want over the code to explain to others
why we're choosing 10 secs. Simply add that sentence above the 10s
assignment and we're perfect! :-)

> > (and not 20 or 30 or whatever)? Generally, why do we need to reprogram
> > the timer to a smaller timeout instead of simply doing the completion
> > without a timeout?
> 
> No, it should be crazy without a timeout, and it can be triggered in init call
> easily.

Ok.

Thanks.

-- 
Regards/Gruss,
Boris.

Advanced Micro Devices GmbH
Einsteinring 24, 85609 Dornach
GM: Alberto Bozzo
Reg: Dornach, Landkreis Muenchen
HRB Nr. 43632 WEEE Registernr: 129 19551
--
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/