Commit 69922fcd534cfc82e2d44374fa219e7c3b27c492

Authored by Yi Zou
Committed by James Bottomley
1 parent 9c8cce8e41

[SCSI] libfcoe: clean up netdev mapping properly when the transport goes away

When rmmoving the underlying fcoe transport driver module by force when
it's attached and in use, the correspoding netdev mapping should be
cleaned up properly as well, otherwise the lookup for a given netdev
for the transport would still return non NULL pointer, causing "unable
to handle paging request" bug.

Signed-off-by: Yi Zou <yi.zou@intel.com>
Tested-by: Ross Brattain <ross.b.brattain@intel.com>
Signed-off-by: Robert Love <robert.w.love@intel.com>
Signed-off-by: James Bottomley <James.Bottomley@suse.de>

Showing 1 changed file with 14 additions and 0 deletions Side-by-side Diff

drivers/scsi/fcoe/fcoe_transport.c
... ... @@ -343,6 +343,7 @@
343 343 int fcoe_transport_detach(struct fcoe_transport *ft)
344 344 {
345 345 int rc = 0;
  346 + struct fcoe_netdev_mapping *nm = NULL, *tmp;
346 347  
347 348 mutex_lock(&ft_mutex);
348 349 if (!ft->attached) {
... ... @@ -351,6 +352,19 @@
351 352 rc = -ENODEV;
352 353 goto out_attach;
353 354 }
  355 +
  356 + /* remove netdev mapping for this transport as it is going away */
  357 + mutex_lock(&fn_mutex);
  358 + list_for_each_entry_safe(nm, tmp, &fcoe_netdevs, list) {
  359 + if (nm->ft == ft) {
  360 + LIBFCOE_TRANSPORT_DBG("transport %s going away, "
  361 + "remove its netdev mapping for %s\n",
  362 + ft->name, nm->netdev->name);
  363 + list_del(&nm->list);
  364 + kfree(nm);
  365 + }
  366 + }
  367 + mutex_unlock(&fn_mutex);
354 368  
355 369 list_del(&ft->list);
356 370 ft->attached = false;