Questionable code in pci_sal_read

Questionable code in pci_sal_read

[Andreas Schwab]

These are the first few lines in pci_sal_read:

	if ((seg > 255) || (bus > 255) || (devfn > 255) || (reg > 4095))
		return -EINVAL;

	if ((seg | reg) <= 255) {

When seg <= 255 then ((seg | reg) <= 255) is equivalent to (reg <= 255).
But pci_sal_write only rejects (seg > 65535).

The lines come from this changeset:

http://linux.bkbits.net:8080/linux-2.6/cset%40407c8325V8ZAIQkFDRCUNpu5AXqG1g

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: Questionable code in pci_sal_read

[Matthew Wilcox]

On Tue, Jan 25, 2005 at 04:21:45PM +0100, Andreas Schwab wrote:
> These are the first few lines in pci_sal_read:
> 
> 	if ((seg > 255) || (bus > 255) || (devfn > 255) || (reg > 4095))
> 		return -EINVAL;

This line is incorrect, the check should be against (seg > 65535).
Good catch.

> 	if ((seg | reg) <= 255) {
> 
> When seg <= 255 then ((seg | reg) <= 255) is equivalent to (reg <= 255).
> But pci_sal_write only rejects (seg > 65535).
> 
> The lines come from this changeset:
> 
> http://linux.bkbits.net:8080/linux-2.6/cset%40407c8325V8ZAIQkFDRCUNpu5AXqG1g
> 
> Andreas.
> 
> -- 
> Andreas Schwab, SuSE Labs, schwab@suse.de
> SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
> Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
> "And now for something completely different."
> -
> To unsubscribe from this list: send the line "unsubscribe linux-ia64" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

-- 
"Next the statesmen will invent cheap lies, putting the blame upon 
the nation that is attacked, and every man will be glad of those
conscience-soothing falsities, and will diligently study them, and refuse
to examine any refutations of them; and thus he will by and by convince 
himself that the war is just, and will thank God for the better sleep 
he enjoys after this process of grotesque self-deception." -- Mark Twain

Re: Questionable code in pci_sal_read

[David Mosberger]

>>>>> On Tue, 25 Jan 2005 16:21:45 +0100, Andreas Schwab <schwab@suse.de> said:

  Andreas> These are the first few lines in pci_sal_read:
  Andreas> if ((seg > 255) || (bus > 255) || (devfn > 255) || (reg > 4095))
  Andreas> return -EINVAL;

  Andreas> if ((seg | reg) <= 255) {

  Andreas> When seg <= 255 then ((seg | reg) <= 255) is equivalent to
  Andreas> (reg <= 255).  But pci_sal_write only rejects (seg >
  Andreas> 65535).

  Andreas> The lines come from this changeset:

  Andreas> http://linux.bkbits.net:8080/linux-2.6/cset%40407c8325V8ZAIQkFDRCUNpu5AXqG1g

Ah, yes, that looks wrong.  Looks like the check for (seg > 255) came
from the original pci_sal_read().  The original pci_sal_ext_read() did
check for (seg > 65535).  My bad.

Thanks for catching this.

	--david

RE: Questionable code in pci_sal_read

[Luck, Tony]

>Ah, yes, that looks wrong.  Looks like the check for (seg > 255) came
>from the original pci_sal_read().  The original pci_sal_ext_read() did
>check for (seg > 65535).  My bad.
>
>Thanks for catching this.


So you (and Matthew Wilcox) are advocating this change?

=== arch/ia64/pci/pci.c 1.66 vs edited ==--- 1.66/arch/ia64/pci/pci.c	2005-01-22 14:42:51 -08:00
+++ edited/arch/ia64/pci/pci.c	2005-01-25 12:42:49 -08:00
@@ -71,7 +71,7 @@
 	u64 addr, mode, data = 0;
 	int result = 0;
 
-	if ((seg > 255) || (bus > 255) || (devfn > 255) || (reg > 4095))
+	if ((seg > 65535) || (bus > 255) || (devfn > 255) || (reg > 4095))
 		return -EINVAL;
 
 	if ((seg | reg) <= 255) {

"seg", "bus", etc. are all "int" ... should we be extra paranoid
and check for negative values (or change the definitions to unsigned),
or is that over the top?

-Tony

Re: Questionable code in pci_sal_read

[Matthew Wilcox]

On Tue, Jan 25, 2005 at 12:47:03PM -0800, Luck, Tony wrote:
> So you (and Matthew Wilcox) are advocating this change?
>  
> -	if ((seg > 255) || (bus > 255) || (devfn > 255) || (reg > 4095))
> +	if ((seg > 65535) || (bus > 255) || (devfn > 255) || (reg > 4095))

Yes.

> "seg", "bus", etc. are all "int" ... should we be extra paranoid
> and check for negative values (or change the definitions to unsigned),
> or is that over the top?

I believe Bjorn has a patch to change the pci_raw_ops to use unsigned int.
Best to send that separately though.

-- 
"Next the statesmen will invent cheap lies, putting the blame upon 
the nation that is attacked, and every man will be glad of those
conscience-soothing falsities, and will diligently study them, and refuse
to examine any refutations of them; and thus he will by and by convince 
himself that the war is just, and will thank God for the better sleep 
he enjoys after this process of grotesque self-deception." -- Mark Twain

RE: Questionable code in pci_sal_read

[Bjorn Helgaas]

On Tue, 2005-01-25 at 12:47 -0800, Luck, Tony wrote:
> >Ah, yes, that looks wrong.  Looks like the check for (seg > 255) came
> >from the original pci_sal_read().  The original pci_sal_ext_read() did
> >check for (seg > 65535).  My bad.
> >
> >Thanks for catching this.
> 
> 
> So you (and Matthew Wilcox) are advocating this change?
> 
> === arch/ia64/pci/pci.c 1.66 vs edited ==> --- 1.66/arch/ia64/pci/pci.c	2005-01-22 14:42:51 -08:00
> +++ edited/arch/ia64/pci/pci.c	2005-01-25 12:42:49 -08:00
> @@ -71,7 +71,7 @@
>  	u64 addr, mode, data = 0;
>  	int result = 0;
>  
> -	if ((seg > 255) || (bus > 255) || (devfn > 255) || (reg > 4095))
> +	if ((seg > 65535) || (bus > 255) || (devfn > 255) || (reg > 4095))
>  		return -EINVAL;
>  
>  	if ((seg | reg) <= 255) {
> 
> "seg", "bus", etc. are all "int" ... should we be extra paranoid
> and check for negative values (or change the definitions to unsigned),
> or is that over the top?

We should definitely change them to unsigned; it's a real problem
that has bitten us already.  In fact, I wonder if Andreas was
looking at this code as a result of the bug I opened yesterday ;-)

I'm testing a patch right now, and it includes the "seg > 65535"
change as well.