Re: [PATCH 2/3] mm: prevent vm_area_struct::anon_name refcount saturation

[Michal Hocko]

On Tue 22-02-22 19:02:08, Suren Baghdasaryan wrote:
> On Tue, Feb 22, 2022 at 7:56 AM Suren Baghdasaryan <surenb@xxxxxxxxxx> wrote:
> >
> > On Tue, Feb 22, 2022 at 1:17 AM Michal Hocko <mhocko@xxxxxxxx> wrote:
> > >
> > > On Mon 21-02-22 21:40:24, Suren Baghdasaryan wrote:
> > > > A deep process chain with many vmas could grow really high.
> > >
> > > This would really benefit from some numbers. With default
> > > sysctl_max_map_count (64k) and default pid_max (32k) the INT_MAX could
> > > be theoretically reached but I find it impractical because not all vmas
> > > can be anonymous same as all available pids can be consumed for a
> > > theoretical attack (if my counting is proper).
> > > On the other hand any non-default configuration with any of the values
> > > increased could hit this theoretically.
> >
> > re: This would really benefit from some numbers
> > Should I just add the details you provided above into the description?
> > Would that suffice?
> 
> Hmm. According to the defaults you posted, with max number of
> processes being 32k and max number of vmas per process 64k, the max
> number of vmas in the system is 2147450880. That's 32767 less than
> REFCOUNT_MAX=INT_MAX (2147483647) and 1073774592 less than
> REFCOUNT_SATURATED (3221225472). So with those defaults we should
> never hit these limits. Are we adding this protection for systems that
> set non-default higher limits or am I miscalculating something?

Yeah, I guess this should be the message the changelog should be
sending.
-- 
Michal Hocko
SUSE Labs