[bug report] staging: wilc1000: added support to dynamically add/remove interfaces

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



[ When we renamed the files, then all the old warnings showed up as
  new warnings again.  - dan ]

Hello Ajay Singh,

The patch 9bc061e88054: "staging: wilc1000: added support to
dynamically add/remove interfaces" from Jun 26, 2019, leads to the
following static checker warning:

	drivers/staging/wilc1000/wlan.c:497 wilc_wlan_handle_txq()
	warn: missing error code here? 'wilc_wlan_txq_get_first()' failed.

drivers/staging/wilc1000/wlan.c
   474  int wilc_wlan_handle_txq(struct wilc *wilc, u32 *txq_count)
   475  {
   476          int i, entries = 0;
   477          u32 sum;
   478          u32 reg;
   479          u32 offset = 0;
   480          int vmm_sz = 0;
   481          struct txq_entry_t *tqe;
   482          int ret = 0;
   483          int counter;
   484          int timeout;
   485          u32 vmm_table[WILC_VMM_TBL_SIZE];
   486          const struct wilc_hif_func *func;
   487          u8 *txb = wilc->tx_buffer;
   488          struct net_device *dev;
   489          struct wilc_vif *vif;
   490  
   491          if (wilc->quit)
   492                  goto out;
                        ^^^^^^^^

One of my coding hints is that "goto out;" is always wrong.  In the
best case the name is too ambiguous so it doesn't tell what the goto
does.  But quite often the goto does too much.  For example, it could do
kfree(foo->bar); where foo is NULL so it's a NULL dereference.  Always
always distrust code which does a goto out.

In this case we are unlocking a lock but we aren't holding the lock.
Is this a success path?  That's complicated to say and becomes even
more complicated when we review the rest of this function.  It appears
that this function returns -ENOBUFS or random meaningless nonsense.

   493  
   494          mutex_lock(&wilc->txq_add_to_head_cs);
                ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Lock.

   495          tqe = wilc_wlan_txq_get_first(wilc);
   496          if (!tqe)
   497                  goto out;
                        ^^^^^^^^^
In this case, Smatch complains that maybe the error code is wrong.
Are we setting "*txq_count" to the correct value?  It's hard to say.

   498          dev = tqe->vif->ndev;
   499          wilc_wlan_txq_filter_dup_tcp_ack(dev);
   500          i = 0;
   501          sum = 0;
   502          do {
   503                  if (tqe && (i < (WILC_VMM_TBL_SIZE - 1))) {
   504                          if (tqe->type == WILC_CFG_PKT)
   505                                  vmm_sz = ETH_CONFIG_PKT_HDR_OFFSET;
   506  
   507                          else if (tqe->type == WILC_NET_PKT)
   508                                  vmm_sz = ETH_ETHERNET_HDR_OFFSET;

[ snip ]

   666          ret = func->hif_clear_int_ext(wilc, ENABLE_TX_VMM);
   667          if (!ret)
   668                  goto out_release_bus;
                        ^^^^^^^^^^^^^^^^^^^^
These functions return 1 on success and 0 on failure.  We should set the
error code here.  There are several other similar places in this
function where we return zero on error.

   669  
   670          ret = func->hif_block_tx_ext(wilc, 0, txb, offset);
   671  
   672  out_release_bus:
   673          release_bus(wilc, WILC_BUS_RELEASE_ALLOW_SLEEP);
   674  
   675  out:
   676          mutex_unlock(&wilc->txq_add_to_head_cs);
   677  
   678          *txq_count = wilc->txq_entries;
   679          return ret;
   680  }

regards,
dan carpenter
_______________________________________________
devel mailing list
devel@xxxxxxxxxxxxxxxxxxxxxx
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel



[Index of Archives]     [Linux Driver Backports]     [DMA Engine]     [Linux GPIO]     [Linux SPI]     [Video for Linux]     [Linux USB Devel]     [Linux Coverity]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [Yosemite Backpacking]
  Powered by Linux