From owner-svn-src-all@FreeBSD.ORG Thu Sep 27 16:19:13 2012 Return-Path: Delivered-To: svn-src-all@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E3F98106566B; Thu, 27 Sep 2012 16:19:13 +0000 (UTC) (envelope-from yanegomi@gmail.com) Received: from mail-ob0-f182.google.com (mail-ob0-f182.google.com [209.85.214.182]) by mx1.freebsd.org (Postfix) with ESMTP id 3B05D8FC0A; Thu, 27 Sep 2012 16:19:13 +0000 (UTC) Received: by obbwc20 with SMTP id wc20so1295776obb.13 for ; Thu, 27 Sep 2012 09:19:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=PjphAvBYE3at/8/iMDMLQ78wej+dVYUdD9CO/1fZOTA=; b=UL6gdLK/Q00FZwKFN2j/rGmxBHtAK7Cw8ZDVdC5nl4YpJBJfKoRNn3onpAPCKMUTT2 FwSB4XV2FHW6keahyGoDhr7VqZ/yRdwTYMjA/djCYCMNoyDeOsMhAp80uUOBlDPchdyc ISGZ6o+k0VO8nqIHrzc1oOvLU3+EIDxAz5FzrTddTSnsrqJEPrKBrI43g9eng2jBg7gq oCx44ywf8rK9a+dywzNfgRKN4bd1NoiAcwQIxzy/KjkBWg2iA5R/wsBJRcLkOd35sW2D ZpGr40SWPRLpqDvPjvXWF1uIzJycqr+AUcs2y1QwGC07hfvwsWg4+9S1EaJY1vp2gaBm BSiw== MIME-Version: 1.0 Received: by 10.60.171.134 with SMTP id au6mr3533608oec.69.1348762752732; Thu, 27 Sep 2012 09:19:12 -0700 (PDT) Received: by 10.76.142.201 with HTTP; Thu, 27 Sep 2012 09:19:12 -0700 (PDT) In-Reply-To: References: <201209271051.q8RApcmq002950@svn.freebsd.org> <20120927131810.GA54552@FreeBSD.org> Date: Thu, 27 Sep 2012 09:19:12 -0700 Message-ID: From: Garrett Cooper To: Adrian Chadd Content-Type: text/plain; charset=ISO-8859-1 Cc: svn-src-head@freebsd.org, Alexey Dokuchaev , src-committers@freebsd.org, Edward Tomasz Napierala , svn-src-all@freebsd.org Subject: Re: svn commit: r240993 - head/sys/cam/ctl X-BeenThere: svn-src-all@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SVN commit messages for the entire src tree \(except for " user" and " projects" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Sep 2012 16:19:14 -0000 On Thu, Sep 27, 2012 at 8:50 AM, Adrian Chadd wrote: > .. I thought that malloc(.. , M_WAITOK) can return NULL. Wasn't there > a discussion about this on IRC? Shouldn't -- else it would break the API contract: M_WAITOK Indicates that it is OK to wait for resources. If the request cannot be immediately fulfilled, the current process is put to sleep to wait for resources to be released by other processes. The malloc(), realloc(), and reallocf() functions cannot return NULL if M_WAITOK is specified. There was some discussion a little while ago IIRC about there being a bug where it could return NULL, but that bug should really be quashed, not disguised. Thanks, -Garrett