Date: Sun, 18 Jan 2004 12:51:07 -0700 From: Scott Long <scottl@freebsd.org> To: Matthew Dillon <dillon@apollo.backplane.com> Cc: scsi@freebsd.org Subject: Re: [CHECKER] bugs in FreeBSD Message-ID: <400AE3AB.1070102@freebsd.org> In-Reply-To: <200401181844.i0IIivlQ096389@apollo.backplane.com> References: <Pine.LNX.4.44.0401161607260.26554-100000@Xenon.Stanford.EDU> <20040118160802.GC32115@FreeBSD.org.ua> <200401181844.i0IIivlQ096389@apollo.backplane.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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 > <dillon@backplane.com> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?400AE3AB.1070102>