From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-2.1 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, USER_AGENT_SANE_1 autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 46F4AC83000 for ; Tue, 28 Apr 2020 10:51:42 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id EBBEA206A1 for ; Tue, 28 Apr 2020 10:51:41 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="u5lpQTUI" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org EBBEA206A1 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=gmail.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 783BE8E0005; Tue, 28 Apr 2020 06:51:41 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 75BDB8E0001; Tue, 28 Apr 2020 06:51:41 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 6714C8E0005; Tue, 28 Apr 2020 06:51:41 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0166.hostedemail.com [216.40.44.166]) by kanga.kvack.org (Postfix) with ESMTP id 509388E0001 for ; Tue, 28 Apr 2020 06:51:41 -0400 (EDT) Received: from smtpin08.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay05.hostedemail.com (Postfix) with ESMTP id 091D3181AEF09 for ; Tue, 28 Apr 2020 10:51:41 +0000 (UTC) X-FDA: 76756948002.08.egg71_ea9391e53015 X-HE-Tag: egg71_ea9391e53015 X-Filterd-Recvd-Size: 6313 Received: from mail-lf1-f66.google.com (mail-lf1-f66.google.com [209.85.167.66]) by imf11.hostedemail.com (Postfix) with ESMTP for ; Tue, 28 Apr 2020 10:51:40 +0000 (UTC) Received: by mail-lf1-f66.google.com with SMTP id j14so16496296lfg.9 for ; Tue, 28 Apr 2020 03:51:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=fyYeeWY+3KvD6+gxdmJCJR9Iruv6EYpQ2fEeFolUcGg=; b=u5lpQTUIvgmN81zrUepO+wYo7eV87ksEBO0BUv5H59B5dSLD6SHbgak1YTF42m/vQ5 q+L8zWe0Hh6aVi/sZbm8PrdH4kY6vUVIYuMWZSZl9SfqShZf7IzkEWz43g14BZOc+MGM OJ/otx38+7HLo1MaNJ+arsIiGpuwSj3X019rqwz64T9L5YcpyoWeHrImrtihUoqjDH6F z/objCD+yfR/FL3jpX7k+cKYYEn0kw1IETssECPafuLQ6LEBHp13zF6q/oASc2O9SWt0 V1y88yEyngsWFS8/CG05HjnGLZzR2QzNdlsGWRw/CXogtgq4cHByi9iztZR2iVdYMJzy 43uA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=fyYeeWY+3KvD6+gxdmJCJR9Iruv6EYpQ2fEeFolUcGg=; b=bkKyKGSP838cUKNB2g0+H7jjHISPbJ5zDqplDi1AMbCwOL4o13IHytR+u1QHSRTHpx WJ4lEuLjZcnW8mfvh2B8FWI1FhOT/y9lwds+KbOlP3sCnVN1oSBoFPsHn/TKE0QPaptK AI9Ml8yIvYNVadCQveN/CtLm7bGiAn3t1lHxC+VEagfXCyM2WRVpFbb+vJ0oyE0iTIjX RESQJeIQHd1TuXRBRERMAz2I/zXTNZQGjvsCdXr1VEyzn61NxjZfTHds5lyqjuThN7eu jtEoinc0BCwXI12wB+APqTfA0Ke/Cc+rJlgPXyhawjUhV2Ys7rFFEO05pl3btEczB3T+ bDzw== X-Gm-Message-State: AGi0PubJmkg5NKnrXDo8+KetNfJTLs0Pz8gzgmorABvl8m6rpHlyZYNo lds5DIFMLdqWnEt/C3V1U+Fm6pgT X-Google-Smtp-Source: APiQypK3JM3ltm2kEkdn+ehdP5qHNkDMZq6yWKu5GhiMurT1KtR5st94nHb47JH3CM7jTHBxbsUXYA== X-Received: by 2002:a19:c607:: with SMTP id w7mr18656693lff.32.1588071098620; Tue, 28 Apr 2020 03:51:38 -0700 (PDT) Received: from [192.168.1.38] (88-114-211-119.elisa-laajakaista.fi. [88.114.211.119]) by smtp.gmail.com with ESMTPSA id t16sm1107473lff.72.2020.04.28.03.51.37 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 28 Apr 2020 03:51:37 -0700 (PDT) Subject: Re: Tmpfs size accounting misses memory allocations To: Hugh Dickins Cc: Helge Deller , Pete Zaitcev , linux-mm@kvack.org References: <63ab63bd-d6c6-a96a-9667-bbe8edb7cedb@gmail.com> From: Topi Miettinen Message-ID: <38759fbe-77a1-f105-ccde-9529170bd9a0@gmail.com> Date: Tue, 28 Apr 2020 13:51:36 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On 28.4.2020 4.34, Hugh Dickins wrote: > On Sat, 25 Apr 2020, Topi Miettinen wrote: >> Hi, >> >> It seems that tmpfs does not count memory which is allocated for short >> symlinks or xattrs towards size= limit. > > Yes, you are right. And that is why tmpfs does not (so far) support > user xattrs, because the unprivileged user could take up too much > memory that way. > >> I guess the fix would be to change >> shmem_sb_info->{used_blocks,max_blocks} to use bytes as units (instead of >> blocks) and then add accounting and checks to shmem_symlink() and >> shmem_initxattrs(). Would a patch for that be acceptable? > > Thank you for offering, but I don't think a patch for exactly that would > be acceptable. Because "size=" has just been another way of expressing > "nr_blocks=" ever since it was added in 2.4.4, and tmpfs has never > counted the kernel metadata towards its data blocks limit. > > You could certainly argue that it should have done from the start; but > in order to keep the accounting suitably simple (pages rather than bytes) > it never did. And I believe there are many users who expect a tmpfs of a > certain size to be able to accommodate data of that size, who would not > care to have to change their scripts or apps to meet a lower limitation. > >> >> Another issue is that inodes aren't counted towards size= limit either, but >> perhaps that's intentional because there's nr_inodes= mount option for >> exactly that. > > Yes, tmpfs lets the nr_inodes limit be used to constrain the kernel > metadata (and tmpfs has a peculiarity, that it actually counts hard > links out of nr_inodes, in order to limit the memory spent on dentries). > > I doubt the nr_inodes limit is depended upon so critically as the > nr_blocks, and I think we might extend it (say, consider each 1 of > nr_inodes to grant approximately 1kB of unswappable lowmem metadata) > to enable limited user xattrs: a patch along those lines might well > be acceptable. I'm interested in restricting the amount of memory allocated to tmpfs mounts in the system rather than granting more. I've seen a system lock up because tmpfs mounts consumed the entire memory. Possible contributing factors could be use of LVM and encryption for the swap. Perhaps there should be a single system limit (sysctl) for total memory consumed by all {dev,}tmpfs mounts? Setting this to for example 75% could be life saving. Then also the compatibility issues would not matter and all memory allocations could be counted. >> If these are not bugs but intentional features, I think the manual page >> tmpfs(5) should be clearer in this respect. > > Nobody has asked for that before, it seems to have met expectations as is. > But a sentence could be added to the manpage: do you have wording in mind? For example addition to the size option: NB: Only the contents (blocks) of regular files are counted towards the size limit. To limit RAM consumption also by the inodes of the directories, symbolic links or device special files, option nr_inodes must be used. -Topi