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
