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=-9.9 required=3.0 tests=DKIMWL_WL_MED,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_1,USER_IN_DEF_DKIM_WL 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 1B787C83002 for ; Tue, 28 Apr 2020 01:35:04 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id A632B206D9 for ; Tue, 28 Apr 2020 01:35:03 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b="sJPvYWNq" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org A632B206D9 Authentication-Results: mail.kernel.org; dmarc=fail (p=reject dis=none) header.from=google.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 0E6E48E0005; Mon, 27 Apr 2020 21:35:03 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 071408E0001; Mon, 27 Apr 2020 21:35:03 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id E7B368E0005; Mon, 27 Apr 2020 21:35:02 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0135.hostedemail.com [216.40.44.135]) by kanga.kvack.org (Postfix) with ESMTP id C884A8E0001 for ; Mon, 27 Apr 2020 21:35:02 -0400 (EDT) Received: from smtpin23.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay03.hostedemail.com (Postfix) with ESMTP id 7B7158248047 for ; Tue, 28 Apr 2020 01:35:02 +0000 (UTC) X-FDA: 76755545244.23.waves42_662cedf189e25 X-HE-Tag: waves42_662cedf189e25 X-Filterd-Recvd-Size: 5211 Received: from mail-ot1-f41.google.com (mail-ot1-f41.google.com [209.85.210.41]) by imf29.hostedemail.com (Postfix) with ESMTP for ; Tue, 28 Apr 2020 01:35:02 +0000 (UTC) Received: by mail-ot1-f41.google.com with SMTP id i27so29885344ota.7 for ; Mon, 27 Apr 2020 18:35:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=date:from:to:cc:subject:in-reply-to:message-id:references :user-agent:mime-version; bh=43kTD4dGzw1ZG2rjaMsAINPlgS315U5jiQshuwJGBo8=; b=sJPvYWNqR1S/vJ1ABhRnLPQDFeMEnkopJcJZ/0gvZ2fIgHZ9DZTyqLWjW07e05AvV5 Pe8xguuWcNaKLi+TRviChp9tU4hFIg6bY9EVfg9uRQ1b8TO8804Z0N/YuZM9co9DD8D5 46Zly4T3yZDqa0DT+yJotyDb5OpycvHDD3Bd8GojL0EOIAhIFWcQD68QHxJ92w+/LymN m47yBtN8BDqmUpWaixQPR8gemk8C2wzF/llM7SRPktX05oXAfnPMhwOQQnE9nDG2LS0F K6EaRnp8G4v1SjAFo2uPMTkj1fVTlzzpG1bLDOkFv+AtLiZuA29rDkvpSxn14PGyCGrB JIcw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:in-reply-to:message-id :references:user-agent:mime-version; bh=43kTD4dGzw1ZG2rjaMsAINPlgS315U5jiQshuwJGBo8=; b=DfrYGQ2kLsOnUYXE/RdgzsizD5Tgx4MCEfKSM933r6+X3aDpvTdRLbC9VNJ+H73Bd2 cTw9J2eMD4KjU/Y3wTMnGBRDsz0pYRtxwQBh4wT3C9dn0qcZhvy607jjPJlRfLj1otcE A2T+MvGAvq3/NLl0H5GyjqiQFX6usQniW9VBf50lU2GWgeZDXrBOS0/v+FOxmdSFhCmm fyN/34AyztqR5bGmZvfIU0iKyMvOGpRtB6LP8EOzLKVpn0IYv6xgKPzPBckGerFHobR+ ktzL/vzOsDCJql6Anw3E9YoHDbgnj6cXWzB6vOGTb9dU5asms6bzmVSo3KEYnZnkjuWk WljA== X-Gm-Message-State: AGi0PuZ6rYLS93kwDOG4kaaH97XBZj8OKWOUzBlIRSbw45dObxCfUFJG i9k7iIvkj302t9B2LYxkvtI7Lw== X-Google-Smtp-Source: APiQypJT/F2slp1rlUPRyyB/YbhHVjllB2S5YHkDea0wXPTU4jY/4BV81py1mgqPy1nT3l1khk2SDg== X-Received: by 2002:a9d:730b:: with SMTP id e11mr22022917otk.9.1588037701098; Mon, 27 Apr 2020 18:35:01 -0700 (PDT) Received: from eggly.attlocal.net (172-10-233-147.lightspeed.sntcca.sbcglobal.net. [172.10.233.147]) by smtp.gmail.com with ESMTPSA id g190sm886100oib.42.2020.04.27.18.34.59 (version=TLS1 cipher=ECDHE-ECDSA-AES128-SHA bits=128/128); Mon, 27 Apr 2020 18:35:00 -0700 (PDT) Date: Mon, 27 Apr 2020 18:34:36 -0700 (PDT) From: Hugh Dickins X-X-Sender: hugh@eggly.anvils To: Topi Miettinen cc: Hugh Dickins , Helge Deller , Pete Zaitcev , linux-mm@kvack.org Subject: Re: Tmpfs size accounting misses memory allocations In-Reply-To: <63ab63bd-d6c6-a96a-9667-bbe8edb7cedb@gmail.com> Message-ID: References: <63ab63bd-d6c6-a96a-9667-bbe8edb7cedb@gmail.com> User-Agent: Alpine 2.11 (LSU 23 2013-08-11) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII 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 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. > > 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? Thanks, Hugh