Date: Wed, 18 Nov 2020 21:27:13 +0000 From: Jessica Clarke <jrtc27@freebsd.org> To: =?utf-8?Q?Stefan_E=C3=9Fer?= <se@freebsd.org> Cc: src-committers <src-committers@freebsd.org>, svn-src-all <svn-src-all@freebsd.org>, svn-src-head@freebsd.org Subject: Re: svn commit: r367813 - head/lib/libutil Message-ID: <E6A6DAB2-BB3D-497D-AF53-CAF958AD2C5E@freebsd.org> In-Reply-To: <25465269-5497-4981-A1E4-CC1FFAB68CF4@freebsd.org> References: <202011181944.0AIJiUU3003699@repo.freebsd.org> <25465269-5497-4981-A1E4-CC1FFAB68CF4@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On 18 Nov 2020, at 21:15, Jessica Clarke <jrtc27@freebsd.org> wrote: >=20 > On 18 Nov 2020, at 19:44, Stefan E=C3=9Fer <se@freebsd.org> wrote: >> + /* >> + * Check for some other thread already having=20 >> + * set localbase - this should use atomic ops. >> + * The amount of memory allocated above may leak, >> + * if a parallel update in another thread is not >> + * detected and the non-NULL pointer is overwritten. >> + */ >=20 > Why was this committed with a known racy/leaky implementation? >=20 > What happens if I set the value with a sysctl and call this? Notably, you go to all this trouble to have a localbase variable that gets set, but you never actually use it properly as a cache since you do the full lookup and only then realise that you already had a (possibly stale) value cached. Jess
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?E6A6DAB2-BB3D-497D-AF53-CAF958AD2C5E>