From owner-freebsd-hackers@FreeBSD.ORG Sun Jan 18 11:57:18 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id ADC6D16A4CE; Sun, 18 Jan 2004 11:57:18 -0800 (PST) Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7FB8B43D2D; Sun, 18 Jan 2004 11:57:17 -0800 (PST) (envelope-from dillon@apollo.backplane.com) Received: from apollo.backplane.com (localhost [127.0.0.1]) i0IJvF82096884; Sun, 18 Jan 2004 11:57:15 -0800 (PST) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.12.9p2/8.12.9/Submit) id i0IJvFTe096883; Sun, 18 Jan 2004 11:57:15 -0800 (PST) (envelope-from dillon) Date: Sun, 18 Jan 2004 11:57:15 -0800 (PST) From: Matthew Dillon Message-Id: <200401181957.i0IJvFTe096883@apollo.backplane.com> To: Scott Long References: <20040118160802.GC32115@FreeBSD.org.ua> <200401181844.i0IIivlQ096389@apollo.backplane.com> <400AE3AB.1070102@freebsd.org> cc: freebsd-hackers@freebsd.org cc: Paul Twohey cc: scsi@freebsd.org Subject: Re: [CHECKER] bugs in FreeBSD X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Jan 2004 19:57:18 -0000 : :Matthew Dillon wrote: :> These cam_sim_alloc() calls seem to be fairly critical to the operation :> of DPT and friends, why is it even possible for them to return NULL :> in the first place and what would be the effect of a (properly handled) :> NULL return if it did occur at this point? :> :> -Matt :> Matthew Dillon :> : : :cam_sim_alloc() is vital to the operation of any CAM driver. However, :cam_sim_alloc() mallocs it's data structures with the M_NOWAIT flag, so :it is possible for it to fail and have to return NULL. The reason it :uses the M_NOWAIT flag is because there is no restrictions on when :driver attach events happen, though they all happen in normal process :or kthread context these days (except at boot, but if you have to sleep :for memory during boot, you have a lot of other problems). : :Scott So, the question becomes: If one were to use M_WAITOK is it possible for a cam_sim_alloc() call for driver A to stall an I/O operation occuring on driver B ? It's the I/O stalls that cause memory deadlocks. Allocations that do not cause I/O stalls on unrelated devices (e.g. your swap) will not cause memory allocation deadlocks. I know cam uses some helper threads so I am not entirely sure about the context the cam_sim_alloc() calls are being made in, but if they do not create I/O stalls for already-operational SCSI devices then I am inclined (in DFly anyway) to simply make the malloc in cam_sim_alloc() M_WAITOK. -Matt Matthew Dillon