netdev - Re: [RFC PATCH 2/2] igb/ixgbe: add code to trigger function reset if reset

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:	Sun, 01 Aug 2010 01:15:16 -0700 (PDT)
From:	David Miller <davem@...emloft.net>
To:	jeffrey.t.kirsher@...el.com
Cc:	jbarnes@...tuousgeek.org, netdev@...r.kernel.org,
	linux-pci@...r.kernel.org, alexander.h.duyck@...el.com
Subject: Re: [RFC PATCH 2/2] igb/ixgbe: add code to trigger function reset
 if reset_devices is set

From: Jeff Kirsher <jeffrey.t.kirsher@...el.com>
Date: Fri, 30 Jul 2010 17:59:12 -0700

> From: Alexander Duyck <alexander.h.duyck@...el.com>
> 
> This change makes it so that both igb and ixgbe can trigger a full pcie
> function reset if the reset_devices kernel parameter is defined.  The main
> reason for adding this is that kdump can cause serious issues when the
> kdump kernel resets the IOMMU while DMA transactions are still occurring.
> 
> Signed-off-by: Alexander Duyck <alexander.h.duyck@...el.com>
> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@...el.com>

I tend to disagree with the essence of this change.

Which is that we should add workaround after workaround for things
that aren't functioning properly in kdump and kexec.

They should have a pass that shuts devices down properly, so that this
kind of stuff doesn't need to happen in the kernel we then boot into.

What happens on non-PCIE systems then?  Do they just lose when this
happens?

No, you dun goof'd.  :-) Find another way to fix this please.

Thanks.
--
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