Bug 244563
| Summary: | vmstat -m show improbable values | ||||||
|---|---|---|---|---|---|---|---|
| Product: | Base System | Reporter: | Steve Wills <swills> | ||||
| Component: | kern | Assignee: | Mark Johnston <markj> | ||||
| Status: | Closed FIXED | ||||||
| Severity: | Affects Some People | CC: | markj | ||||
| Priority: | --- | ||||||
| Version: | CURRENT | ||||||
| Hardware: | Any | ||||||
| OS: | Any | ||||||
| Attachments: |
|
||||||
Can you show full vmstat -m output? Created attachment 212106 [details]
full vmstat -m output
See attached
-18446744073709551525 % (1 << 63) is ~24,000. Looking at the other mallocs, I see shmfd is pretty close to that. sys_shm_unlink() calls free(path, M_TEMP), which is wrong since shm_copyin_path() allocates the path buffer with M_SHMFD. Looks like it was introduced in r354808.
diff --git a/sys/kern/uipc_shm.c b/sys/kern/uipc_shm.c
index b97e75c0e417..886a0bad8746 100644
--- a/sys/kern/uipc_shm.c
+++ b/sys/kern/uipc_shm.c
@@ -961,7 +961,7 @@ sys_shm_unlink(struct thread *td, struct shm_unlink_args *uap)
sx_xlock(&shm_dict_lock);
error = shm_remove(path, fnv, td->td_ucred);
sx_xunlock(&shm_dict_lock);
- free(path, M_TEMP);
+ free(path, M_SHMFD);
return (error);
}
(In reply to Mark Johnston from comment #3) Oops, I meant 18446744073709527361, the value from the attached file. A commit references this bug: Author: markj Date: Tue Mar 3 00:28:38 UTC 2020 New revision: 358563 URL: https://svnweb.freebsd.org/changeset/base/358563 Log: Fix the malloc type used in sys_shm_unlink() after r354808. PR: 244563 Reported by: swills Changes: head/sys/kern/uipc_shm.c |
Using r358506, when I run vmstat -m, I see: vmstat -m | head -n 1 ; vmstat -m | grep temp Type InUse MemUse HighUse Requests Size(s) temp 18446744073709551525 18014398509481813K - 80059557 16,32,64,128,256,512,1024,2048,4096,8192,16384,32768,65536 I see this on both my workstation and on the package builders (those are on r356856), but only while poudriere is building packages. Perhaps it's related to tmpfs usage? Not sure, but the values here look wrong.