netdev - Re: [PATCH] e1000: Fix msi enable leak on error, don't print error message, cleanup

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, 16 May 2007 15:16:10 -0400
From:	Jeff Garzik <jeff@...zik.org>
To:	Rick Jones <rick.jones2@...com>
CC:	"H. Peter Anvin" <hpa@...or.com>,
	Auke Kok <auke-jan.h.kok@...el.com>, netdev@...r.kernel.org,
	e1000-devel@...ts.sourceforge.net
Subject: Re: [PATCH] e1000: Fix msi enable leak on error, don't print error
 message,	cleanup

Rick Jones wrote:
> But that is rather incidental isn't it?  Would some sort of system 
> health monitor be likely to be checking that for interrupt flavors?  And 

Well, that's where the information is exported in a standard way.  I 
hope you're not suggesting that a system health monitor should be 
parsing random, driver-specific printk messages to obtain the same 
information?

> just looking at /proc/interrupts, while it tells you what sort of 
> interrupt is being used, it doesn't (IIRC) say anything about what sort 
> of interrupt the driver _tried_ to use.

True.

In the context of this thread, it could be any number of reasons:  MSI 
isn't compiled in.  MSI was disabled at runtime via kernel command line. 
  MSI was disabled by BIOS quirk.  MSI enable was attempted, but failed 
for some reason.

None of those reasons are really driver-specific, or need 
driver-specific complaint messages.

	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