Bug #4682

panic in mptsas refhash

Added by Hans Rosenfeld over 3 years ago. Updated over 3 years ago.

Status:ResolvedStart date:2014-03-12
Priority:NormalDue date:
Assignee:Keith Wesolowski% Done:

100%

Category:driver - device drivers
Target version:-
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 over 3 years ago

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

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 over 3 years ago

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

#3 Updated by Electric Monk over 3 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