Date: Thu, 9 Jan 2020 11:12:28 +0100 From: Hans Petter Selasky <hps@selasky.org> To: Poul-Henning Kamp <phk@phk.freebsd.dk>, current@freebsd.org Subject: Re: M_TEMP trouble in 13.0-CURRENT #0 r355131M Message-ID: <4e52b23e-32ed-6556-a74e-22c809a17fe0@selasky.org> In-Reply-To: <4164.1578563950@critter.freebsd.dk> References: <4164.1578563950@critter.freebsd.dk>
next in thread | previous in thread | raw e-mail | index | archive | help
On 2020-01-09 10:59, Poul-Henning Kamp wrote: > I noticed yesterday that M_TEMP stats are screwed up, and rebooted my > laptop for reasons of safety. > > However, it's back again now: > > critter phk> vmstat -m | grep temp > temp 18446744073709546036 18014398509476380K - 963239 16,32,64,128,256,512,1024,2048,4096,8192,16384,32768,65536 > > FreeBSD critter.freebsd.dk 13.0-CURRENT FreeBSD 13.0-CURRENT #0 r355131M: Wed Nov 27 16:44:48 UTC 2019 root@critter.freebsd.dk:/usr/obj/freebsd/src/amd64.amd64/sys/GENERIC-NODEBUG amd64 > > I mentioned this on IRC yesterday and noted I had a "disk full" on > a tmpfs mount, but that can now be disregarded as a false lead. > > On this kernel I have had an instance where X got killed for > out-of-swap, at a time where that certainly should not have been > the case. > > Am I the only one seeing this ? > Hi, 2**64 - 18446744073709546036 ans = 6144 Someone likely freed to M_TEMP which were not supposed to free there. You could use dtrace to narrow this down and you can also add a kdb_backtrace() for the first couple of users of free() when the stats is negative. Else: grep -r M_TEMP /usr/src/sys And do an audit. --HPS
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4e52b23e-32ed-6556-a74e-22c809a17fe0>