linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Hugh Dickins <hughd@google.com>
To: Topi Miettinen <toiwoton@gmail.com>
Cc: Hugh Dickins <hughd@google.com>, Helge Deller <deller@gmx.de>,
	 Pete Zaitcev <zaitcev@redhat.com>,
	linux-mm@kvack.org
Subject: Re: Tmpfs size accounting misses memory allocations
Date: Mon, 27 Apr 2020 18:34:36 -0700 (PDT)	[thread overview]
Message-ID: <alpine.LSU.2.11.2004271728100.4718@eggly.anvils> (raw)
In-Reply-To: <63ab63bd-d6c6-a96a-9667-bbe8edb7cedb@gmail.com>

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


  reply	other threads:[~2020-04-28  1:35 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-04-25 12:33 Topi Miettinen
2020-04-28  1:34 ` Hugh Dickins [this message]
2020-04-28 10:51   ` Topi Miettinen
2020-05-01  3:14     ` Hugh Dickins
2020-05-01  7:29       ` Topi Miettinen
2020-05-01 19:05       ` Topi Miettinen
2020-05-03 19:58       ` Topi Miettinen

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=alpine.LSU.2.11.2004271728100.4718@eggly.anvils \
    --to=hughd@google.com \
    --cc=deller@gmx.de \
    --cc=linux-mm@kvack.org \
    --cc=toiwoton@gmail.com \
    --cc=zaitcev@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox