On Thu, 2015-03-05 at 00:44 +0000, Praveen Murali wrote: > ________________________________________ > From: James Bottomley <James.Bottomley@xxxxxxxxxxxxxxxxxxxxx> > Sent: Wednesday, March 4, 2015 4:18 PM > To: Praveen Murali > Cc: linux-scsi@xxxxxxxxxxxxxxx; dan.j.williams@xxxxxxxxx > Subject: Re: [libsas] Kernel Crash in smp_execute_task > > On Wed, 2015-03-04 at 23:29 +0000, Praveen Murali wrote: > >> On second thoughts, should we even let smp commands/requests thru for > >> sas end devices (dev->dev_type == SAS_END_DEV) ? if so, wont the > >> following patch more sense? (also, in my last mail the kernel logs > >> were all messed up; sorry dint realize that when I sent the mail. > >> Trying to fix it here) > > >I think the bug is deeper than this: we shouldn't be trying expander > >revalidation on non-expander devices. If the device changes from end to > >expander via hotplug, we'll see the remove and add (via the identify > >frame) so the device type should be correct by the time we do the > >revalidation. > > >Does this fix the problem? > > Yes, that fixes the issue. So if my understanding is correct, what you > are saying is we need to do something like [the patch] > instead of putting the exclusion in smp_execute_task; is that right? Right. There's more than just the SMP problem that will happen if you try to discover an end device as an expander. The expander discovery routines are going to try to cast to a non-existent expander device and do all sorts of unfortunate things with what it thinks are a list of expander phys. Effectively revalidation only needs to probe expanders because all the other devices were fully discovered via the IDENTIFY frames they already sent. The code is slighly obscure and it does look like the intent was to call sas_ex_discover with any device type since SMP to a device that doesn't have an SMP port will just fail. However, it's safer just not to do it because half the code assumes that any device passed into the sas_ex_.. routines can be treated as an expander. James -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
