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:	Tue, 12 Dec 2006 15:35:42 -0600
From:	linas@...tin.ibm.com (Linas Vepstas)
To:	Greg KH <gregkh@...e.de>
Cc:	akpm@...l.org, linux-kernel@...r.kernel.org,
	linux-pci@...ey.karlin.mff.cuni.cz
Subject: Re: [PATCH 1/2]: Renumber PCI error enums to start at zero

On Tue, Dec 12, 2006 at 12:35:43PM -0800, Greg KH wrote:
> On Tue, Dec 12, 2006 at 01:55:24PM -0600, Linas Vepstas wrote:
> > 
> > Subject: [PATCH 1/2]: Renumber PCI error enums to start at zero
> > 
> > Renumber the PCI error enums to start at zero for "normal/online".
> > This allows un-initialized pci channel state (which defaults to zero)
> > to be interpreted as "normal".  Add very simple routine to check
> > state, just in case this ever has to be fiddled with again.
> 
> No, as you have a specific type for this state, never test it against
> "zero".  That just defeats the whole issue of having a special type for
> this state.

Yes, well, I guess that was my initial thinking, which is why it got
coded that way. But "in real life", the value in the struct isn't
initialized (thus taking a value of zero). Its not initialized 
in deference to the traditional idea that "just saying bzero() 
should be enough".  

However, that turned the test for error into a dorky double test:
if(pdev->error_state && pdev->error_state != pci_channel_io_normal)
which struck me as lame. 

So, I'll ask: is it better to test for (state!=0 && state!=1) or,
to initialize pdev->error_state = pci_channel_io_normal; in the driver 
probe code?

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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ