Date: Tue, 3 Dec 2019 12:43:13 -0800 From: Gleb Smirnoff <glebius@freebsd.org> To: Ryan Libby <rlibby@freebsd.org> Cc: src-committers@freebsd.org, svn-src-all@freebsd.org, svn-src-head@freebsd.org Subject: Re: svn commit: r355137 - head/sys/vm Message-ID: <20191203204313.GB2706@FreeBSD.org> In-Reply-To: <201911271949.xARJnuFl084178@repo.freebsd.org> References: <201911271949.xARJnuFl084178@repo.freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Ryan, On Wed, Nov 27, 2019 at 07:49:56PM +0000, Ryan Libby wrote: R> Author: rlibby R> Date: Wed Nov 27 19:49:55 2019 R> New Revision: 355137 R> URL: https://svnweb.freebsd.org/changeset/base/355137 R> R> Log: R> uma: trash memory when ctor/dtor supplied too R> R> On INVARIANTS kernels, UMA has a use-after-free detection mechanism. R> This mechanism previously required that all of the ctor/dtor/uminit/fini R> arguments to uma_zcreate() be NULL in order to function. Now, it only R> requires that uminit and fini be NULL; now, the trash ctor and dtor will R> be called in addition to any supplied ctor or dtor. R> R> Also do a little refactoring for readability of the resulting logic. R> R> This enables use-after-free detection for more zones, and will allow for R> simplification of some callers that worked around the previous R> restriction (see kern_mbuf.c). R> R> Reviewed by: jeff, markj R> Sponsored by: Dell EMC Isilon R> Differential Revision: https://reviews.freebsd.org/D20722 If I understand the change correct, now items from UMA_ZONE_NOFREE zones will be trashed, too. That would undermine purpose of UMA_ZONE_NOFREE. Of course the flag is a hack, but some systems rely on it working. -- Gleb Smirnoff
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20191203204313.GB2706>