From: Robert Love <robert.w.love@intel.com>
To: James.Bottomley@suse.de, linux-scsi@vger.kernel.org
Cc: Yi Zou <yi.zou@intel.com>
Subject: [PATCH 02/27] libfc: fix NULL pointer dereference bug in fc_fcp_pkt_release
Date: Tue, 30 Nov 2010 16:18:07 -0800 [thread overview]
Message-ID: <20101201001807.18369.99723.stgit@localhost.localdomain> (raw)
In-Reply-To: <20101201001756.18369.7107.stgit@localhost.localdomain>
From: Yi Zou <yi.zou@intel.com>
This happens when then tearing down the fcoe interface with active I/O.
The back trace shows dead000000200200 in RAX, i.e., LIST_POISON2, indicating
that the fsp is already being dequeued, which is probably why no complaining
was seen in fc_fcp_destroy() about outstanding fsp not freed, since we dequeue
it in the end of fc_io_compl() before releasing it. The bug is due to the
fact that we have already destroyed lport's scsi_pkt_pool while on-going i/o
is still accessing it through fc_fcp_pkt_release(), like this trace or the
similar code path from scsi-ml to fc_eh_abort, etc. This is fixed by moving
the fc_fcp_destroy() after lport is detached from scsi-ml since fc_fcp_destroy
is supposed to called only once where no lport lock is taken, otherwise the
fc_fcp_pkt_release() would have to grab the lport lock.
BUG: unable to handle kernel NULL pointer dereference at (null)
.......
RIP: 0010:[<0000000000000000>]
[<(null)>] (null)
RSP: 0018:ffff8803270f7b88 EFLAGS: 00010282
RAX: dead000000200200 RBX: ffff880197d2fbc0 RCX: 0000000000005908
RDX: ffff880195ea6d08 RSI: 0000000000000282 RDI: ffff880180f4fec0
RBP: ffff8803270f7bc0 R08: ffff880197d2fbe0 R09: 0000000000000000
R10: ffff88032867f090 R11: 0000000000000000 R12: ffff880195ea6d08
R13: 0000000000000282 R14: ffff880180f4fec0 R15: 0000000000000000
FS: 0000000000000000(0000) GS:ffff8801b5820000(0000) knlGS:0000000000000000
CS: 0010 DS: 0018 ES: 0018 CR0: 000000008005003b
CR2: 0000000000000000 CR3: 00000001a6eae000 CR4: 00000000000006e0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
Process fc_rport_eq (pid: 5278, threadinfo ffff8803270f6000, task ffff880326254ab0)
Stack:
ffffffffa02c39ca ffff8803270f7ba0 ffff88019331cbc0 ffff880197d2fbc0
0000000000000000 ffff8801a8c895e0 ffff8801a8c895e0 ffff8803270f7c10
ffffffffa02c4962 ffff8803270f7be0 ffffffff814c94ab ffff8803270f7c10
Call Trace:
[<ffffffffa02c39ca>] ? fc_io_compl+0x10a/0x530 [libfc]
[<ffffffffa02c4962>] fc_fcp_complete_locked+0x72/0x150 [libfc]
[<ffffffff814c94ab>] ? _spin_unlock_bh+0x1b/0x20
[<ffffffffa02b98ff>] ? fc_exch_done+0x3f/0x60 [libfc]
[<ffffffffa02c4a8f>] fc_fcp_retry_cmd+0x4f/0x60 [libfc]
[<ffffffffa02c6150>] fc_fcp_recv+0x9b0/0xc30 [libfc]
[<ffffffff8106ba7a>] ? _call_console_drivers+0x4a/0x80
[<ffffffff8107d5ec>] ? lock_timer_base+0x3c/0x70
[<ffffffff8107e06b>] ? try_to_del_timer_sync+0x7b/0xe0
[<ffffffffa02b9dcf>] fc_exch_mgr_reset+0x1df/0x250 [libfc]
[<ffffffffa02c57a0>] ? fc_fcp_recv+0x0/0xc30 [libfc]
[<ffffffffa02c1042>] fc_rport_work+0xf2/0x4e0 [libfc]
[<ffffffff8109203e>] ? prepare_to_wait+0x4e/0x80
[<ffffffffa02c0f50>] ? fc_rport_work+0x0/0x4e0 [libfc]
[<ffffffff8108c6c0>] worker_thread+0x170/0x2a0
[<ffffffff81091d50>] ? autoremove_wake_function+0x0/0x40
[<ffffffff8108c550>] ? worker_thread+0x0/0x2a0
[<ffffffff810919e6>] kthread+0x96/0xa0
[<ffffffff810141ca>] child_rip+0xa/0x20
[<ffffffff81091950>] ? kthread+0x0/0xa0
[<ffffffff810141c0>] ? child_rip+0x0/0x20
Code:
Bad RIP value.
RIP
[<(null)>] (null)
RSP <ffff8803270f7b88>
CR2: 0000000000000000
Signed-off-by: Yi Zou <yi.zou@intel.com>
Signed-off-by: Robert Love <robert.w.love@intel.com>
---
drivers/scsi/fcoe/fcoe.c | 4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/drivers/scsi/fcoe/fcoe.c b/drivers/scsi/fcoe/fcoe.c
index d23a538..9f9600b 100644
--- a/drivers/scsi/fcoe/fcoe.c
+++ b/drivers/scsi/fcoe/fcoe.c
@@ -854,7 +854,6 @@ static void fcoe_if_destroy(struct fc_lport *lport)
/* Cleanup the fc_lport */
fc_lport_destroy(lport);
- fc_fcp_destroy(lport);
/* Stop the transmit retry timer */
del_timer_sync(&port->timer);
@@ -876,6 +875,9 @@ static void fcoe_if_destroy(struct fc_lport *lport)
fc_remove_host(lport->host);
scsi_remove_host(lport->host);
+ /* Destroy lport scsi_priv */
+ fc_fcp_destroy(lport);
+
/* There are no more rports or I/O, free the EM */
fc_exch_mgr_free(lport);
next prev parent reply other threads:[~2010-12-01 0:18 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-12-01 0:17 [PATCH 00/27] libfc, libfcoe and fcoe updates for 2.6.38 Robert Love
2010-12-01 0:18 ` [PATCH 01/27] libfc: remove define of fc_seq_exch in fc_exch.c Robert Love
2010-12-01 0:18 ` Robert Love [this message]
2010-12-01 0:18 ` [PATCH 03/27] libfc: fix mem leak in fc_exch_recv_seq_resp() Robert Love
2010-12-01 0:18 ` [PATCH 04/27] libfc: tune fc_exch_em_alloc() to be O(2) Robert Love
2010-12-01 0:18 ` [PATCH 05/27] libfc: Fix incorrect locking and unlocking in FCP Robert Love
2010-12-01 0:18 ` [PATCH 06/27] libfc: fix mem leak in fc_seq_assign() Robert Love
2010-12-01 0:18 ` [PATCH 07/27] libfc: fix stats computation in fc_queuecommand() Robert Love
2010-12-01 0:18 ` [PATCH 08/27] libfc: incorrect scsi host byte codes returned to scsi-ml Robert Love
2010-12-01 0:18 ` [PATCH 09/27] libfc: use rport timeout values for fcp recovery Robert Love
2010-12-01 0:18 ` [PATCH 10/27] libfc: remove tgt_flags from fc_fcp_pkt struct Robert Love
2010-12-01 0:18 ` [PATCH 11/27] libfc: fix memory leakage in local port Robert Love
2010-12-01 0:18 ` [PATCH 12/27] " Robert Love
2010-12-01 0:19 ` [PATCH 13/27] libfc: fix memory leakage in remote port Robert Love
2010-12-01 0:19 ` [PATCH 14/27] drivers/scsi/fcoe: Update WARN uses Robert Love
2010-12-01 0:19 ` [PATCH 15/27] libfc: add print of exchange id for debugging fc_fcp Robert Love
2010-12-01 0:19 ` [PATCH 16/27] libfc: do not fc_io_compl on fsp w/o any scsi_cmnd associated Robert Love
2010-12-01 0:19 ` [PATCH 17/27] libfc: fix exchange being deleted when the abort itself is timed out Robert Love
2010-12-01 0:19 ` [PATCH 18/27] libfc: the timeout for the REC itself is 2 * R_A_TOV_els Robert Love
2010-12-01 0:19 ` [PATCH 19/27] libfc: fix fc_tm_done not freeing the allocated fsp pkt Robert Love
2010-12-01 0:19 ` [PATCH 20/27] libfcoe: update FIP FCF announcements Robert Love
2010-12-01 0:19 ` [PATCH 21/27] libfcoe: move some timer code to make it reusable Robert Love
2010-12-01 0:19 ` [PATCH 22/27] libfcoe: fix checking of conflicting fabrics in fcoe_ctlr_select() Robert Love
2010-12-01 0:19 ` [PATCH 23/27] libfcoe: retry rejected FLOGI to another FCF if possible Robert Love
2010-12-01 0:20 ` [PATCH 24/27] libfcoe: add debug message for FCF destination MAC Robert Love
2010-12-01 0:20 ` [PATCH 25/27] libfcoe: reorder FCF list to put latest advertiser first Robert Love
2010-12-01 0:20 ` [PATCH 26/27] libfcoe: change fip_select to return new FCF Robert Love
2010-12-01 0:20 ` [PATCH 27/27] libfc: fix statistics for FCP input/output megabytes Robert Love
2010-12-01 19:04 ` [PATCH] scsi: fix libfc sparse warnings Randy Dunlap
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20101201001807.18369.99723.stgit@localhost.localdomain \
--to=robert.w.love@intel.com \
--cc=James.Bottomley@suse.de \
--cc=linux-scsi@vger.kernel.org \
--cc=yi.zou@intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.