Re: [PATCH v9 2/3] mm: add a field to store names for private anonymous memory

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Thu, Sep 30, 2021 at 11:56:12AM -0700, Suren Baghdasaryan wrote:
> I thought more about these alternative suggestions for userspace to
> record allocations but that would introduce considerable complexity
> into userspace. Userspace would have to collect and consolidate this
> data by some daemon, all users would have to query it for the data
> (IPC or something similar), in case this daemon crashes the data would
> need to be somehow recovered. So, in short, it's possible but makes
> things much more complex compared to proposed in-kernel
> implementation.

Agreed: this is something for the kernel to manage.

> OTOH, the only downside of the current implementation is the
> additional memory required to store anon vma names. I checked the
> memory consumption on the latest Android with these patches and
> because we share vma names during fork, the actual memory required to
> store vma names is no more than 600kB. Even on older phones like Pixel
> 3 with 4GB RAM, this is less than 0.015% of total memory. IMHO, this
> is an acceptable price to pay.

I think that's entirely fine. We don't end up with any GUP games, and
everything is refcounted.

I think a v10 with the various nits fixed would be a good next step
here. What do you think Matthew?

-- 
Kees Cook



[Index of Archives]     [Linux Ext4 Filesystem]     [Union Filesystem]     [Filesystem Testing]     [Ceph Users]     [Ecryptfs]     [NTFS 3]     [AutoFS]     [Kernel Newbies]     [Share Photos]     [Security]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux Cachefs]     [Reiser Filesystem]     [Linux RAID]     [NTFS 3]     [Samba]     [Device Mapper]     [CEPH Development]

  Powered by Linux