From owner-freebsd-scsi@FreeBSD.ORG Mon Apr 15 08:00:01 2013 Return-Path: Delivered-To: freebsd-scsi@smarthost.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 4AB9A487 for ; Mon, 15 Apr 2013 08:00:01 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by mx1.freebsd.org (Postfix) with ESMTP id 3DEE5ACC for ; Mon, 15 Apr 2013 08:00:01 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.6/8.14.6) with ESMTP id r3F801Nw077438 for ; Mon, 15 Apr 2013 08:00:01 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.6/8.14.6/Submit) id r3F801oa077437; Mon, 15 Apr 2013 08:00:01 GMT (envelope-from gnats) Date: Mon, 15 Apr 2013 08:00:01 GMT Message-Id: <201304150800.r3F801oa077437@freefall.freebsd.org> To: freebsd-scsi@FreeBSD.org Cc: From: Alexander Motin Subject: Re: kern/165740: [cam] SCSI code must drain callbacks before free X-BeenThere: freebsd-scsi@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: Alexander Motin List-Id: SCSI subsystem List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Apr 2013 08:00:01 -0000 The following reply was made to PR kern/165740; it has been noted by GNATS. From: Alexander Motin To: Hans Petter Selasky Cc: sbruno@freebsd.org, bug-followup@FreeBSD.org Subject: Re: kern/165740: [cam] SCSI code must drain callbacks before free Date: Mon, 15 Apr 2013 10:58:32 +0300 On 15.04.2013 08:58, Hans Petter Selasky wrote: > On 04/14/13 21:25, Sean Bruno wrote: >> Can you regenerate this patch? It looks like it got garbled by gnats. >> Or this is a copy/paste from an annotated version of a web page? > > Can you check the commit logs? I wonder if Alexander has fixed this issue. No, I haven't, but I've noticed it also myself. I think that the code around these callouts is historically not exactly correct and needs some more attention then just dropping the lock and draining. BTW one way to avoid dropping lock there could be in taking extra reference to device before arming it. That would keep device from destruction until callout actually fire. -- Alexander Motin