Hi Himanshu, Could you please take a look at the series and anwser if we should stop doing BA_RJT as a response on ABTS when there's no session? Thank you, Roman On Thu, Sep 12, 2019 at 01:53:03PM +0000, Himanshu Madhani wrote: > Adding Correct Quinn. Please use "qutran@xxxxxxxxxx" > > We'll take a look at the series > > On 9/12/19, 8:49 AM, "linux-scsi-owner@xxxxxxxxxxxxxxx on behalf of Roman Bolshakov" <linux-scsi-owner@xxxxxxxxxxxxxxx on behalf of r.bolshakov@xxxxxxxxx> wrote: > > On Thu, Sep 12, 2019 at 06:37:22AM +0100, Bart Van Assche wrote: > > On 9/12/19 1:39 AM, Roman Bolshakov wrote: > > > This series has a few bug fixes for the driver. > > > > > > Note, #1 only fixes the crash in the kernel. The complete fix for clean > > > ACL deletion from initiator side is in works and requires a discussion. > > > > > > As of now initiator is not aware that target no longer wants talking to > > > it, that implies unneeded timeout. It might be fixed by making LOGO > > > explicit on session deletion but it's an issue I want to raise first > > > before making the change. Whether we need implicit LOGO in qla2xxx, > > > explicit or use both. > > > > > > Also, an unsolicited ABTS from a port without session would still result > > > in BA_RJT response instead of frame discard and LOGO ELS, as specified > > > in FCP (12.3.3 Target FCP_Port response to Exchange termination): > > > > > > When an ABTS-LS is received at the target FCP_Port, it shall abort > > > the designated Exchange and return one of the following responses: > > > > > > a) the target FCP_Port shall discard the ABTS-LS and transmit a LOGO > > > ELS if the Nx_Port issuing the ABTS-LS is not currently logged in > > > (i.e., no N_Port Login exists); > > > > > > FWIW, the target driver can receive ABTS as part of ABORT TASK/LUN > > > RESET/CLEAR TASK SET TMFs and in case of failed sequence retransmission > > > requests, exchange or sequence errors. IIRC, some initiators requeue > > > SCSI commands if BA_RJT is received. Therefore, a timely LOGO will > > > prevent a perceived session freeze on the initiators. > > > > Hi Roman, > > > > Has this patch series been prepared against Linus' master branch, > > against Martin's 5.3/scsi-fixes or against Martin's 5.4/scsi-queue > > branch? I'm asking this because some patches in this series look similar > > to patches that are already present in the 5.4/scsi-queue branch. > > > > Thanks, > > > > Bart. > > > > Hi Bart, > > To be honest it was prepared against next-20190904 but it applies to > 5.4/scsi-queue cleanly. The fixes made two weeks ago look promising but > are related to stuck PRLI and unhandled RSCN while #4 is related to > stuck PLOGI after qla_post_els_plogi_work. > > Thank you, > Roman > >