linux-kernel - Re: [PATCH] igb: fix kexec with igb

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:	Sat, 07 Mar 2009 10:20:42 -0800
From:	ebiederm@...ssion.com (Eric W. Biederman)
To:	Yinghai Lu <yinghai@...nel.org>
Cc:	Jesse Brandeburg <jesse.brandeburg@...il.com>,
	David Miller <davem@...emloft.net>,
	"Rafael J. Wysocki" <rjw@...k.pl>, Ingo Molnar <mingo@...e.hu>,
	Andrew Morton <akpm@...ux-foundation.org>,
	"linux-kernel\@vger.kernel.org" <linux-kernel@...r.kernel.org>,
	NetDev <netdev@...r.kernel.org>
Subject: Re: [PATCH] igb: fix kexec with igb

Yinghai Lu <yinghai@...nel.org> writes:

> On Fri, Mar 6, 2009 at 11:18 PM, Jesse Brandeburg
> <jesse.brandeburg@...il.com> wrote:
>> On Fri, Mar 6, 2009 at 8:33 PM, Yinghai Lu <yinghai@...nel.org> wrote:
>>>
>>> Impact: could probe igb
>>>
>>> Found one system with 82575EB, in the kernel that is kexeced, probe igb
>>> failed with -2.
>>>
>>> it looks like the same behavior happened on forcedeth.
>>>
>>> try to check system_state to make sure if put it on D3
>>>
>>> Signed-off-by: Yinghai Lu <yinghai@...nel.org>
>>>
>>> ---
>>>  drivers/net/igb/igb_main.c |   19 ++++++++++++++-----
>>>  1 file changed, 14 insertions(+), 5 deletions(-)
>>
>> I see the point of the patch, but I know for a fact that ixgbe when
>> enabled for MSI-X also doesn't work with kexec.
>>
>> so my questions are:
>> are you going to change every driver?
>
> i tend to only change driver that i have related HW.
>
>> why can't this be fixed in core kernel code instead?
> will check it.
>
>> Shouldn't pci_enable_device take it out of D3?
>> Or maybe it should be taken out of D3 immediately if someone tries to
>> ioremap any of the BARx registers?
>
>
> looks like second kernel can not detect the state any more.

I know this has historically been a problem with the e1000 NICs.
Placing the hardware in a state they can not get them out of on
the reboot path.

Last I heard (a couple of weeks ago?) we had code to bring devices out
of a low power state that was working for the e1000 driver.

YH can you look and see if you can find that code and if it works?

<rant>
Frankly I don't understand why anyone would want to power down a device
when they are rebooting or shutting down a computer.  That is a
system state change.  But it seems to be bleed over from the confusion
that has been the power management code.
</rant>

If we can teach the kernel to handle this case with the proper enables
and disables that would be great.  Otherwise let's look at getting the
responsibilities of the various methods sorted out so we can at least
say with certainty what the various methods are supposed to do and
not do.

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