Project

General

Profile

Bug #4682

panic in mptsas refhash

Added by Hans Rosenfeld about 5 years ago. Updated about 5 years ago.

Status:
Resolved
Priority:
Normal
Category:
driver - device drivers
Start date:
2014-03-12
Due date:
% Done:

100%

Estimated time:
Difficulty:
Medium
Tags:

Description

We observed a panic in the new refhash code in mptsas when plugging in a JBOD after boot:

BAD TRAP: type=d (#gp General protection) rp=ffffff002e12b880 addr=ffffff0739510020

refhash_next+0x40(ffffff0731bcc698, ffffff0759b50318)
mptsas_config_all+0xa4(ffffff07321b1618)
mptsas_bus_config+0x140(ffffff07321b1618, 4004048, 2, ffffffff, 0)
scsi_hba_bus_config+0x8b(ffffff07321b1618, 4004048, 2, ffffffff, 0)
devi_config_common+0xa5(ffffff07321b1618, 4004048, ffffffff)
mt_config_thread+0x70(ffffff0771383540)
thread_start+8()

This seems to be caused by the corruption of a mptsas_smp_t structure that was inserted into the refhash immediately prior to the panic.

History

#1

Updated by Keith Wesolowski about 5 years ago

  • % Done changed from 0 to 60
  • Tags deleted (needs-triage)

This appears to be caused by mptsas_smp_alloc(). In the case where we are updating an existing SMP target's handles (i.e., a matching address is already in the hash), this code simply copies whatever structure was passed in over the top of the existing one. That's not safe to do, because the target structure we've been given is just a template; it does not have any sensible hash link structure inside it.

Instead, we should just update the handles. We don't need to worry about the address because that's already been matched as it's the hash key.

#2

Updated by Robert Mustacchi about 5 years ago

  • Category set to driver - device drivers
  • Status changed from New to Resolved
  • % Done changed from 60 to 100
#3

Updated by Electric Monk about 5 years ago

git commit a92ef4b03ff951f27904ba300cef72e8d3430035

Author: Keith M Wesolowski <wesolows@foobazco.org>

4682 panic in mptsas refhash
Reviewed by: Dan McDonald <danmcd@omniti.com>
Reviewed by: Hans Rosenfeld <hans.rosenfeld@nexenta.com>
Reviewed by: Josef 'Jeff' Sipek <josef.sipek@nexenta.com>
Approved by: Albert Lee <trisk@nexenta.com>

Also available in: Atom PDF