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 <[email protected]>
> Cc: stable <[email protected]>
> ---
> 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",
_______________________________________________
fcoe-devel mailing list
[email protected]
http://lists.open-fcoe.org/mailman/listinfo/fcoe-devel
