Date: Sat, 30 May 2009 23:54:47 -0700 From: Kip Macy <kmacy@freebsd.org> To: Richard Todd <rmtodd@ichotolot.servalan.com> Cc: freebsd-current@freebsd.org Subject: Re: Bug in recent large_alloc changes to the ZFS zio code? Message-ID: <3c1674c90905302354i34ffb56by44019edc1b12dd59@mail.gmail.com> In-Reply-To: <20090531064517.EB9ADCC9@mx1.synetsystems.com> References: <20090531064517.EB9ADCC9@mx1.synetsystems.com>
next in thread | previous in thread | raw e-mail | index | archive | help
http://svn.freebsd.org/changeset/base/192360 On Sat, May 30, 2009 at 11:20 PM, Richard Todd <rmtodd@ichotolot.servalan.com> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3c1674c90905302354i34ffb56by44019edc1b12dd59>