From nobody Fri Dec 01 02:19:11 2023 X-Original-To: bugs@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4ShGvz1Kxkz537L7 for ; Fri, 1 Dec 2023 02:19:11 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.nyi.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4ShGvy6lWsz4b52 for ; Fri, 1 Dec 2023 02:19:10 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1701397150; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=r2zdzrB38owI0Prp9PZlq7TaDQCQwIJQlqLMGxtAQdY=; b=VKZt02XJ+7k4CRdbWSL4AkdhY4Vntt3EMAqEYl66R2mmY3fb+8YLZy4PapYOgGGTr8c9R+ C0oz8hQXUPlt77asdassJe/5Vsp/NbIf3dxUVOpU/Uv4wXj2nHGrzlE7MXFt424hciDtyz omuP0QxoI9/580rWgUgkY+0/4fg6GUI885Nn+A4TaDvTIIv2b/wy6x5BlU+M0YBC81xvvp Iip8hVrODHF3ddNoxFYuYhbtThgAObgqcekXYWUu8V4EZC14cPaGTBr0CKgccvEydy/Tj+ v657QmAfwMWzdcDzupzibU7rn8Iw/vCtaJN4Xq4bQMmnVryXXWdxdHJUQbxo/Q== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1701397150; a=rsa-sha256; cv=none; b=pmia+n64grWsOzpArpd32N7WkpwOD3sAI+ysdj7oAnYHfa4HSKmXAHiFhTq8ZEcOUdWHn9 d/txdycc2cFnp/Dl9wfSn8jp1CPkFJovEB7XUV/O5vcKa6E8iNtFnKe5kaRDfjnd5GuVKz x5TO7DpNAJb3KSX0xQQzinikTSuH4xKndmHauae3qEJNTZays5ZY5QkbYZgSDXh9uEWMtF 41m6E3/rBGX96qqYxfF9993lbFUT0yU0jWDStNm7Tj+Woia1p1Y3h/Ni1jMGYnXQUyVc64 5HGRpGSSmlmPV/hoOiHIPMscEovqkus7GJNWXNsf1FtmTHNlUqHC6AxIhlZcRQ== Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2610:1c1:1:606c::50:1d]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id 4ShGvy5q6LzlK for ; Fri, 1 Dec 2023 02:19:10 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.5]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id 3B12JARA008405 for ; Fri, 1 Dec 2023 02:19:10 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 3B12JAZS008404 for bugs@FreeBSD.org; Fri, 1 Dec 2023 02:19:10 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: bugs@FreeBSD.org Subject: [Bug 275436] tmpfs does not honor memory limits on writes Date: Fri, 01 Dec 2023 02:19:11 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 15.0-CURRENT X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: karels@freebsd.org X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: bugs@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated List-Id: Bug reports List-Archive: https://lists.freebsd.org/archives/freebsd-bugs List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-bugs@freebsd.org MIME-Version: 1.0 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D275436 --- Comment #4 from Mike Karels --- (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.=