On Tue, 2015-05-26 at 13:08 +0200, Bart Van Assche wrote: > If fc_invoke_resp() returns false then it has already freed *fp. > Do not call lport_recv() with a dangling frame pointer. This > patch fixes the following crash: > > general protection fault: 0000 [#3] PREEMPT SMP > RIP: fc_lport_recv_req+0x72/0x280 [libfc] > Call Trace: > fc_exch_recv+0x642/0xde0 [libfc] > fcoe_percpu_receive_thread+0x46a/0x5ed [fcoe] > kthread+0x10a/0x120 > ret_from_fork+0x42/0x70 > > Signed-off-by: Bart Van Assche <bart.vanassche@xxxxxxxxxxx> > Cc: stable <stable@xxxxxxxxxxxxxxx> > --- > drivers/scsi/libfc/fc_exch.c | 5 +---- > 1 file changed, 1 insertion(+), 4 deletions(-) > > diff --git a/drivers/scsi/libfc/fc_exch.c b/drivers/scsi/libfc/fc_exch.c > index fb4cc5e..73127af 100644 > --- a/drivers/scsi/libfc/fc_exch.c > +++ b/drivers/scsi/libfc/fc_exch.c > @@ -1503,11 +1503,8 @@ static void fc_exch_recv_req(struct fc_lport *lport, struct fc_exch_mgr *mp, > * sequence after this. > * > * The frame will be freed by the receive function. > - * If new exch resp handler is valid then call that > - * first. > */ > - if (!fc_invoke_resp(ep, sp, fp)) > - lport->tt.lport_recv(lport, fp); I'm trying to look back but may be you can help me why we added lport_recv() along adding of fc_invoke_resp() by you in commit 7030fd62. I'm digging at history since it has been while since you added fc_invoke_resp() logic. Looks like you had lport_recv() called only when fc_invoke_resp() was not done calling upper later fcp handler but then you added fp free there and thats where this bug got introduced but not sure lport_recv() calling was for a reason which you had it left along adding fc_invoke_resp(). Thanks, Vasu > + fc_invoke_resp(ep, sp, fp); > fc_exch_release(ep); /* release from lookup */ > } else { > FC_LPORT_DBG(lport, "exch/seq lookup failed: reject %x\n", -- To unsubscribe from this list: send the line "unsubscribe target-devel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html