From owner-freebsd-scsi@FreeBSD.ORG Sat Mar 3 11:10:31 2012 Return-Path: Delivered-To: freebsd-scsi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C5DE4106566C; Sat, 3 Mar 2012 11:10:31 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe09.c2i.net [212.247.155.2]) by mx1.freebsd.org (Postfix) with ESMTP id C6A9A8FC0C; Sat, 3 Mar 2012 11:10:30 +0000 (UTC) X-T2-Spam-Status: No, hits=-1.0 required=5.0 tests=ALL_TRUSTED Received: from [176.74.212.201] (account mc467741@c2i.net HELO laptop002.hselasky.homeunix.org) by mailfe09.swip.net (CommuniGate Pro SMTP 5.4.2) with ESMTPA id 72226834; Sat, 03 Mar 2012 12:10:28 +0100 From: Hans Petter Selasky To: freebsd-scsi@freebsd.org, Alexander Motin , gibbs@freebsd.org, freebsd-current@freebsd.org Date: Sat, 3 Mar 2012 12:08:48 +0100 User-Agent: KMail/1.13.5 (FreeBSD/8.3-PRERELEASE; KDE/4.4.5; amd64; ; ) X-Face: 'mmZ:T{)),Oru^0c+/}w'`gU1$ubmG?lp!=R4Wy\ELYo2)@'UZ24N@d2+AyewRX}mAm; Yp |U[@, _z/([?1bCfM{_"B<.J>mICJCHAzzGHI{y7{%JVz%R~yJHIji`y>Y}k1C4TfysrsUI -%GU9V5]iUZF&nRn9mJ'?&>O MIME-Version: 1.0 Content-Type: Text/Plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Message-Id: <201203031208.48514.hselasky@c2i.net> Cc: Subject: CAM detach races with USB memory sticks X-BeenThere: freebsd-scsi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SCSI subsystem List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Mar 2012 11:10:31 -0000 Hi, I've started looking into some attach/detach stress tests for USB mass storage devices. During my bughunting I've found the following issue: In /sys/cam/cam_xpt.c: 4569 void 4570 xpt_release_device(struct cam_ed *device) 4571 { 4572 4573 mjacob 224806 if (device->refcount == 1) { 4574 gibbs 39212 struct cam_devq *devq; 4575 4576 gibbs 44500 if (device->alloc_ccb_entry.pinfo.index != CAM_UNQUEUED_INDEX 4577 || device->send_ccb_entry.pinfo.index != CAM_UNQUEUED_INDEX) 4578 panic("Removing device while still queued for ccbs"); 4579 gibbs 49927 4580 if ((device->flags & CAM_DEV_REL_TIMEOUT_PENDING) != 0) XXXX HERE XXXX 4581 mjacob 224806 callout_stop(&device->callout); 4583 mav 198748 TAILQ_REMOVE(&device->target->ed_entries, device,links); 4584 device->target->generation++; 4585 device->target->bus->sim->max_ccbs -= device->ccbq.devq_openings; 4586 trasz 186184 /* Release our slot in the devq */ 4587 mav 198748 devq = device->target->bus->sim->devq; 4588 trasz 186184 cam_devq_resize(devq, devq->alloc_queue.array_size - 1); 4589 avatar 147571 camq_fini(&device->drvq); 4590 mav 198377 cam_ccbq_fini(&device->ccbq); 4591 ken 230590 /* 4592 * Free allocated memory. free(9) does nothing if the 4593 * supplied pointer is NULL, so it is safe to call without 4594 * checking. 4595 */ 4596 free(device->supported_vpds, M_CAMXPT); 4597 free(device->device_id, M_CAMXPT); 4598 free(device->physpath, M_CAMXPT); 4599 free(device->rcap_buf, M_CAMXPT); 4600 free(device->serial_num, M_CAMXPT); 4601 4602 mav 198748 xpt_release_target(device->target); 4603 avatar 147723 free(device, M_CAMXPT); Remember our OS is SMP now, so callout_drain() must be used on all callouts before the structure where they are located are freed. Above I only see callout_stop(). The problem is that xpt_release_device() appears to be called locked and callout_drain() requires unlocked context! How do we solve this? I don't know so much about the CAM layer and I hope that someone who does can give a hand here. --HPS