[PATCH] applicom: Prevent unsigned wrap in ac_interrupt()

[PATCH] applicom: Prevent unsigned wrap in ac_interrupt()

[Roel Kluin]

unsigned i wraps if this occurs in the first iteration.

Signed-off-by: Roel Kluin <roel.kluin@gmail.com>
---
Or do we know this can't happen?

diff --git a/drivers/char/applicom.c b/drivers/char/applicom.c
index 73a0765..0df3e12 100644
--- a/drivers/char/applicom.c
+++ b/drivers/char/applicom.c
@@ -670,7 +670,7 @@ static irqreturn_t ac_interrupt(int vec, void *dev_instance)
 			}
 			Dummy = readb(apbs[i].RamIO + VERS);
 
-			if(readb(apbs[i].RamIO + RAM_IT_TO_PC)) {
+			if(i && readb(apbs[i].RamIO + RAM_IT_TO_PC)) {
 				/* There's another int waiting on this card */
 				spin_unlock(&apbs[i].mutex);
 				i--;

Re: [PATCH] applicom: Prevent unsigned wrap in ac_interrupt()

[Jiri Slaby]

On 08/08/2009 05:13 PM, Roel Kluin wrote:
> unsigned i wraps if this occurs in the first iteration.

Could you elaborate? I don't quite understand the point.

> Signed-off-by: Roel Kluin <roel.kluin@gmail.com>
> ---
> Or do we know this can't happen?

You mean the i--? It's followed by i++ in the for loop 3rd expression. Or?

> 
> diff --git a/drivers/char/applicom.c b/drivers/char/applicom.c
> index 73a0765..0df3e12 100644
> --- a/drivers/char/applicom.c
> +++ b/drivers/char/applicom.c
> @@ -670,7 +670,7 @@ static irqreturn_t ac_interrupt(int vec, void *dev_instance)
>  			}
>  			Dummy = readb(apbs[i].RamIO + VERS);
>  
> -			if(readb(apbs[i].RamIO + RAM_IT_TO_PC)) {
> +			if(i && readb(apbs[i].RamIO + RAM_IT_TO_PC)) {
>  				/* There's another int waiting on this card */
>  				spin_unlock(&apbs[i].mutex);
>  				i--;

Re: [PATCH] applicom: Prevent unsigned wrap in ac_interrupt()

[roel kluin]

>> unsigned i wraps if this occurs in the first iteration.
>
> Could you elaborate? I don't quite understand the point.

`i' is unsigned. The last test in the loop is:

if(readb(apbs[i].RamIO + RAM_IT_TO_PC)) {
        /* There's another int waiting on this card */
        spin_unlock(&apbs[i].mutex);
        i--;
} else {
        spin_unlock(&apbs[i].mutex);
}

In the first iteration `i' is 0, so if this condition evaluates to true
then `i' becomes 0xffffffff (since it's unsigned), the for loop test
fails and the i++ never occurs.

>> Or do we know this can't happen?
>
> You mean the i--? It's followed by i++ in the for loop 3rd expression. Or?

No, I meant: do we know the test can't evaluate to true in the first iteration?

Thanks,

Roel

Re: [PATCH] applicom: Prevent unsigned wrap in ac_interrupt()

[Jiri Slaby]

On 08/11/2009 10:54 AM, roel kluin wrote:
>>> unsigned i wraps if this occurs in the first iteration.
>>
>> Could you elaborate? I don't quite understand the point.
> 
> `i' is unsigned. The last test in the loop is:
> 
> if(readb(apbs[i].RamIO + RAM_IT_TO_PC)) {
>         /* There's another int waiting on this card */
>         spin_unlock(&apbs[i].mutex);
>         i--;
> } else {
>         spin_unlock(&apbs[i].mutex);
> }
> 
> In the first iteration `i' is 0, so if this condition evaluates to true
> then `i' becomes 0xffffffff (since it's unsigned), the for loop test
> fails and the i++ never occurs.

Hmm, no. This is not how three `for' expressions are evaluated. The CFG
of "for (a; b; c) d;" is "a->(b->d->c)*". Read 6.8.5.3 of ANSI C99.

I.e. 0xff increments back to 0.

Am I still missing something?