netdev - Re: [PATCH -net-next 1/4] firmware: convert e100 driver to request

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]

Date:	Wed, 7 Jan 2009 10:23:44 -0800
From:	"Jeff Kirsher" <jeffrey.t.kirsher@...el.com>
To:	"David Miller" <davem@...emloft.net>
Cc:	jaswinder@...radead.org, linux.nics@...el.com,
	e1000-devel@...ts.sourceforge.net, netdev@...r.kernel.org,
	linux-kernel@...r.kernel.org, linux-next@...r.kernel.org
Subject: Re: [PATCH -net-next 1/4] firmware: convert e100 driver to request_firmware()

On Sun, Jan 4, 2009 at 9:34 PM, David Miller <davem@...emloft.net> wrote:
> From: "Jeff Kirsher" <jeffrey.t.kirsher@...el.com>
> Date: Sun, 4 Jan 2009 18:20:24 -0800
>
>> On Sun, Jan 4, 2009 at 4:06 PM, David Miller <davem@...emloft.net> wrote:
>> > From: "Jeff Kirsher" <jeffrey.t.kirsher@...el.com>
>> > Date: Tue, 30 Dec 2008 14:33:36 -0800
>> >
>> >> Please hold off on committing, until we have had ample time to do some
>> >> regression testing.  While this patch may have been in linux-next,
>> >> this is the first we have seen of it.
>> >>
>> >> I am concerned that IPMI traffic will be adversely affected by this patch.
>> >
>> > Status please?
>> > --
>>
>> The only testing left to do is to make sure that ICH devices still
>> work and to make sure the IPMI traffic is not affected by this patch.
>> All other testing looks good.  I am sorry that I have been slow to
>> give status, the holiday's have put a strain on available resources.
>
> Ok, thanks for the update.
> --
>

So here is the latest testing update...

The only testing that we were not able to do was the IPMI testing,
because of the lack of resources.  All other testing passed.

While all other testing passed, I am concerned about not being able to
test whether or not this change affects the ability to pass IPMI
traffic.  I am not sure if the "gain" of using request_firmware() out
weighs the potential risk that IPMI traffic may be broken with this
patch.  I guess I wondering what the gain is in using the
request_firmware() function?

>From past experience with IPMI traffic and the e100, the loading of
the microcode in the correct manner greatly affected whether IPMI
traffic would pass or not.

-- 
Cheers,
Jeff
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html