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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox