panic in mptsas refhash
|Assignee:||Keith Wesolowski||% Done:|
|Category:||driver - device drivers|
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.
#1 Updated by Keith Wesolowski almost 5 years ago
- Tags deleted (
- % 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.
#3 Updated by Electric Monk almost 5 years ago
Author: Keith M Wesolowski <email@example.com> 4682 panic in mptsas refhash Reviewed by: Dan McDonald <firstname.lastname@example.org> Reviewed by: Hans Rosenfeld <email@example.com> Reviewed by: Josef 'Jeff' Sipek <firstname.lastname@example.org> Approved by: Albert Lee <email@example.com>
Also available in: Atom