From owner-freebsd-current@FreeBSD.ORG Sun May 31 06:54:47 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D73AE106564A for ; Sun, 31 May 2009 06:54:47 +0000 (UTC) (envelope-from mat.macy@gmail.com) Received: from an-out-0708.google.com (an-out-0708.google.com [209.85.132.246]) by mx1.freebsd.org (Postfix) with ESMTP id 8F7508FC13 for ; Sun, 31 May 2009 06:54:47 +0000 (UTC) (envelope-from mat.macy@gmail.com) Received: by an-out-0708.google.com with SMTP id c3so3692474ana.13 for ; Sat, 30 May 2009 23:54:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to:cc :content-type:content-transfer-encoding; bh=/jq+x5HVCLMDsiwYsKBuZDsENJMR0oEFQ7tsuXzExcg=; b=N86E6gRx1EwJkLWWdYhI9LPcFVwICLnaU/IP9rWm3biF6R8+w/RGZTrRIx630KFjfb rJvubA5yWzIR9PdN5KdKjvBuA0B76m0X88KAu7rmeoyTxQGcqWQcYfAiRjnCmHsb02Jg CUPM17atYlGJ4DvFFp6qWohHZjfcLgzWuwSaU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=nYUCUVCutvyGMjsqxQvh20sACfYn3sjqkKkUEguyrsZIkio1VCXHabJCl42RC5OmKQ lPCBBmP/kBfB0zib9evgoXJxBuW2VA3230GLdqyMjTVM97lThXjmdeZeAGD00UbVE9BI eFF9Zw7JDkjDtxnD80tztvEwlyQ8rWyCNUesk= MIME-Version: 1.0 Sender: mat.macy@gmail.com Received: by 10.100.105.15 with SMTP id d15mr5577460anc.140.1243752887036; Sat, 30 May 2009 23:54:47 -0700 (PDT) In-Reply-To: <20090531064517.EB9ADCC9@mx1.synetsystems.com> References: <20090531064517.EB9ADCC9@mx1.synetsystems.com> Date: Sat, 30 May 2009 23:54:47 -0700 X-Google-Sender-Auth: 6bdf777d2fb698aa Message-ID: <3c1674c90905302354i34ffb56by44019edc1b12dd59@mail.gmail.com> From: Kip Macy To: Richard Todd Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-current@freebsd.org Subject: Re: Bug in recent large_alloc changes to the ZFS zio code? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 31 May 2009 06:54:48 -0000 http://svn.freebsd.org/changeset/base/192360 On Sat, May 30, 2009 at 11:20 PM, Richard Todd wrote: > Okay, I'm looking at the recent changes in the ZFS zio code to change how > data buffers are allocated (svn r192207). =A0The old code for > zio_data_buf_alloc just called kmem_alloc (the Solaris compatibility > one), which in turn called malloc() with M_WAITOK, so it would always > be guaranteed of getting a valid, non-null pointer. =A0Fair enough. > The new code has an alternate code path, where in "arc_large_memory_enabl= ed" > mode, it calls the new function zio_large_malloc instead. =A0zio_large_ma= lloc > in turn tries a few times to allocate the required pages using > vm_phys_alloc_contig, but if that fails goes ahead and returns NULL. > > Here's the problem. =A0As near as I can tell, none of the code that calls > zio_data_buf_alloc appears to check for the possibility that the > returned pointer could be NULL, which I guess is reasonable as the origin= al > code never could return NULL. =A0However, the new large malloc code *can*= return > NULL, which causes the obvious problem. =A0The other day I mentioned here= a > panic I saw where under sufficiently heavy load the GEOM code was > complaining that it had been given a NULL data pointer. =A0It seems to me= that > that was likely because zio had tried to allocate a data buffer and gotte= n > a NULL pointer instead. > > > > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org= " > --=20 When bad men combine, the good must associate; else they will fall one by one, an unpitied sacrifice in a contemptible struggle. Edmund Burke