Skip site navigation (1)Skip section navigation (2)
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/>
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 #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=3D<=
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 f=
ound
the reason why, it's in tmpfs_can_alloc_page().  I tried adding a test ther=
e,
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 necess=
ary
to sleep for memory sometimes.  But it is not unexpected for a write to ret=
urn
ENOSPC on a nearly-full file system.  And I think tmpfs is over-promising in
this case.

--=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-wDdiFXTLAx>