Date: Fri, 01 Dec 2023 01:14:33 +0000 From: bugzilla-noreply@freebsd.org To: bugs@FreeBSD.org Subject: [Bug 275436] tmpfs does not honor memory limits on writes Message-ID: <bug-275436-227-EOiVL5K0WR@https.bugs.freebsd.org/bugzilla/> In-Reply-To: <bug-275436-227@https.bugs.freebsd.org/bugzilla/> References: <bug-275436-227@https.bugs.freebsd.org/bugzilla/>
next in thread | previous in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D275436 --- Comment #3 from Konstantin Belousov <kib@FreeBSD.org> --- tmpfs_setattr()->tmpfs_chsize()->tmpfs_truncate()->tmpfs_reg_resize() The free target has nothing to do with the availability of the (managed AKA swappable) memory for usermode. If it is used, it would cause transient 'no memory' errors, mostly due to pagedaemon not able to cope with working set changes in timely manner. This is same as requirement to not return transi= ent ENOMEMs to userspace from malloc(M_NOWAIT) in the top-level syscall code. By default, system allows most consumers to eat as much memory as they want and can. For instance, you can mmap(MAP_ANON) insanely large region, and fault physical pages on demand (recent Chrome does exactly this, it mmaps 1Tb for heap). Or you could create posix shm memory segment of that size. Or you can write a file on tmpfs. In each case, if the facility could be mis-used to exhaust memory (not phys= ical RAM but pageable storage) then specific limit should be applied. For insta= nce, for tmpfs the 'size' mount option should be used to limits its total use. The thing that is unclear to me, are you reporting that mount -o size=3D<li= mit> does not work? So that you can create and fill file larger than the limit? --=20 You are receiving this mail because: You are the assignee for the bug.=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-275436-227-EOiVL5K0WR>