Date: Fri, 01 Dec 2023 02:19:11 +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-wDdiFXTLAx@https.bugs.freebsd.org/bugzilla/> In-Reply-To: <bug-275436-227@https.bugs.freebsd.org/bugzilla/>
index | next in thread | previous in thread | raw e-mail
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=275436 --- Comment #4 from Mike Karels <karels@freebsd.org> --- (In reply to Konstantin Belousov from comment #3) > tmpfs_setattr()->tmpfs_chsize()->tmpfs_truncate()->tmpfs_reg_resize() Sorry, I missed that, not sure how. In any case, a proper fix would account only for page additions. > The thing that is unclear to me, are you reporting that mount -o size=<limit> does not work? So that you can create and fill file larger than the limit? No, that case works. The broken case is when size is omitted/default. I found the reason why, it's in tmpfs_can_alloc_page(). I tried adding a test there, and that works too, but not in time to keep the system from killing off processes. I'll have to think about the memory competition issues. Unlike large user mappings, you can't kill tmpfs if it gets too greedy. And if it is /tmp, or otherwise writable by unprivileged users, such users can cause processes to be killed off and even to hang the system (I just did it). Maybe it is necessary to sleep for memory sometimes. But it is not unexpected for a write to return ENOSPC on a nearly-full file system. And I think tmpfs is over-promising in this case. -- You are receiving this mail because: You are the assignee for the bug.home | help
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-275436-227-wDdiFXTLAx>