Skip to contentSkip to conversation

iwlwifi: testing the wrong variable

PATCH In review Dan Carpenter 3 participants 4 messages Feb 18, 2010 – Feb 19, 2010

Subsystems (4)
lore
Share & tools
lore
#0 lore raw

PATCH 1/1 iwlwifi: testing the wrong variable

The first one fixes a smatch false positive and the second one fixes a potential bug.

drivers/net/wireless/iwlwifi/iwl-5000.c +786 iwl5000_txq_update_byte_cnt_tbl(37) error: buffer overflow '(scd_bc_tbl+txq_id)->tfd_offset' 320 <= 512
drivers/net/wireless/iwlwifi/iwl-5000.c +808 iwl5000_txq_inval_byte_cnt_tbl(19) error: buffer overflow '(scd_bc_tbl+txq_id)->tfd_offset' 320 <= 512

---
I don't have the hardware to test this change.

drivers/net/wireless/iwlwifi/iwl-5000.c +2 -2
index de45f30..b45150d 100644
@@ -781,7 +781,7 @@ void iwl5000_txq_update_byte_cnt_tbl(struct iwl_priv *priv,
 
 	scd_bc_tbl[txq_id].tfd_offset[write_ptr] = bc_ent;
 
-	if (txq->q.write_ptr < TFD_QUEUE_SIZE_BC_DUP)
+	if (write_ptr < TFD_QUEUE_SIZE_BC_DUP)
 		scd_bc_tbl[txq_id].
 			tfd_offset[TFD_QUEUE_SIZE_MAX + write_ptr] = bc_ent;
 }
@@ -803,7 +803,7 @@ void iwl5000_txq_inval_byte_cnt_tbl(struct iwl_priv *priv,
 	bc_ent =  cpu_to_le16(1 | (sta_id << 12));
 	scd_bc_tbl[txq_id].tfd_offset[read_ptr] = bc_ent;
 
-	if (txq->q.write_ptr < TFD_QUEUE_SIZE_BC_DUP)
+	if (read_ptr < TFD_QUEUE_SIZE_BC_DUP)
 		scd_bc_tbl[txq_id].
 			tfd_offset[TFD_QUEUE_SIZE_MAX + read_ptr] =  bc_ent;
 }
#1 lore raw
Quoted 11 lines · Dan Carpenter

The first one fixes a smatch false positive and the second one fixes a potential bug.

drivers/net/wireless/iwlwifi/iwl-5000.c +786 iwl5000_txq_update_byte_cnt_tbl(37) error: buffer overflow '(scd_bc_tbl+txq_id)->tfd_offset' 320 <= 512
drivers/net/wireless/iwlwifi/iwl-5000.c +808 iwl5000_txq_inval_byte_cnt_tbl(19) error: buffer overflow '(scd_bc_tbl+txq_id)->tfd_offset' 320 <= 512

---

This has already been fixed by patch below (taken from wireless-next-2.6). John and Greg, could you please pick this one up for 2.6.33 and stable instead?

commit 8ce1ef4a914aef8b9b90a2a2c670494168a2cca9

Author: Wey-Yi Guy <[email protected]>
Date:   Fri Jan 8 10:04:44 2010 -0800

iwlwifi: fix bug in tx byte count table

When setting invalid byte count in txq byte count table, read
pointer
should be used instead of write pointer.

Reinette

#2 lore raw
Quoted 27 lines · reinette chatre
Quoted 11 lines · Dan Carpenter

The first one fixes a smatch false positive and the second one fixes a potential bug.

drivers/net/wireless/iwlwifi/iwl-5000.c +786 iwl5000_txq_update_byte_cnt_tbl(37) error: buffer overflow '(scd_bc_tbl+txq_id)->tfd_offset' 320 <= 512
drivers/net/wireless/iwlwifi/iwl-5000.c +808 iwl5000_txq_inval_byte_cnt_tbl(19) error: buffer overflow '(scd_bc_tbl+txq_id)->tfd_offset' 320 <= 512

---

This has already been fixed by patch below (taken from wireless-next-2.6). John and Greg, could you please pick this one up for 2.6.33 and stable instead?

commit 8ce1ef4a914aef8b9b90a2a2c670494168a2cca9

Author: Wey-Yi Guy <[email protected]>
Date:   Fri Jan 8 10:04:44 2010 -0800

iwlwifi: fix bug in tx byte count table

When setting invalid byte count in txq byte count table, read
pointer
should be used instead of write pointer.

Quoted 5 lines

So for the record, that patch is basically identical to Dan's patch but with some whitespace fixups in some nearby lines as well.

How important is this patch? Is there an actual bug report? Is it a regression?

It is very late in the 2.6.33 cycle and it isn't obvious to me that this is worth pushing for 2.6.33 at this point...?

John

Signature · 2 lines
John W. Linville		Someday the world will need a hero, and you
[email protected]			might be all we have.  Be ready.
#3 lore raw
Quoted 8 lines · John W. Linville

So for the record, that patch is basically identical to Dan's patch but with some whitespace fixups in some nearby lines as well.

How important is this patch? Is there an actual bug report? Is it a regression?

It is very late in the 2.6.33 cycle and it isn't obvious to me that this is worth pushing for 2.6.33 at this point...?

This is exactly the reason why we did not post the patch to 2.6.33 or stable when we submitted it upstream since there was no regression or bug tied to it at that time. It surely is a problem that needs fixing, which we did in the current release. I just highlighted that if there is a request for this to be fixed in stable then we already have the patch available. I'm ok with this one only going into 2.6.34.

Reinette