Re: Tmpfs size accounting misses memory allocations

[Topi Miettinen <toiwoton@gmail.com>]

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