Re: Panic when rebooting target server testing srp on 5.0.0-rc2

[Laurence Oberman <loberman@redhat.com>]

On Wed, 2019-04-03 at 08:09 -0700, Bart Van Assche wrote:
> On Wed, 2019-04-03 at 10:53 -0400, Laurence Oberman wrote:
> > Update on this issue
> > 
> > If I reset the SRP target server and do not reboot it I do not see
> > the
> > block-mq race with the SRP initiator.
> > Just resetting the SRP target array and not runing the reboot
> > avoids
> > the shutdown scripts of ib_srpt and seems somehow to prevent the
> > race
> > with the initiator code.
> > 
> > Given that I see very little churn and activity with LIO lately I
> > dont
> > know if its worth spending more time on trying to isolate this.
> > 
> > If anybody has an SRP native array (like DDN) and can reboot it
> > with
> > 5.x plus, that would be a good test.
> > 
> > I will reach out to DDN and ask if they can test it.
> 
> Hi Laurence,
> 
> If the initiator side crashes it means there is a bug in the kernel
> at the
> initiator side. It's not clear to me why you are commenting on the
> target
> side in this e-mail thread?
> 
> Thanks,
> 
> Bart.

Hello Bart

It does indeed seem to be an initiator issue but related to something
when the target reboots. Resetting the target, the initiator survives.
I did not know this until today. 
Until today was rebooting the targetserver to reproduce the race on the
initiator side.
Today I started testing the same way as I was when I repriduced the
Qlogic lock recursion, and In noticed I could not longer reproduce it.

In other words rebooting the target closes the SRP target ports in such
a way that the initiator gets into the block-mq issue race.
Using echo b or power reset the array just dissapears and tyhe
initiator is fine.

Apologies if I was not clear.

Regards
Laurence