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: <9929d2390901071023s590f439fre15696786f098b81@mail.gmail.com>
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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ