Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Date:   Wed, 23 Feb 2022 09:26:02 +0100
From:   Michal Hocko <mhocko@suse.com>
To:     Suren Baghdasaryan <surenb@google.com>
Cc:     akpm@linux-foundation.org, ccross@google.com,
        sumit.semwal@linaro.org, dave.hansen@intel.com,
        keescook@chromium.org, willy@infradead.org,
        kirill.shutemov@linux.intel.com, vbabka@suse.cz,
        hannes@cmpxchg.org, ebiederm@xmission.com, brauner@kernel.org,
        legion@kernel.org, ran.xiaokai@zte.com.cn, sashal@kernel.org,
        chris.hyser@oracle.com, dave@stgolabs.net, pcc@google.com,
        caoxiaofeng@yulong.com, david@redhat.com, gorcunov@gmail.com,
        linux-mm@kvack.org, linux-kernel@vger.kernel.org,
        kernel-team@android.com
Subject: Re: [PATCH 2/3] mm: prevent vm_area_struct::anon_name refcount
 saturation
Message-ID: <YhXvmhIjwScN9SNj@dhcp22.suse.cz>
References: <20220222054025.3412898-1-surenb@google.com>
 <20220222054025.3412898-2-surenb@google.com>
 <YhSqDvSTN7nbz4C9@dhcp22.suse.cz>
 <CAJuCfpHr78By6p5sMhJZ3UohKXXSeA7Dxm_q-OA4y6KYL0L_pQ@mail.gmail.com>
 <CAJuCfpFkwZAw-qcD6E5SchHNXf8MmzyWtuWaHOpFhid3m5bg8A@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <CAJuCfpFkwZAw-qcD6E5SchHNXf8MmzyWtuWaHOpFhid3m5bg8A@mail.gmail.com>
Precedence: bulk

On Tue 22-02-22 19:02:08, Suren Baghdasaryan wrote:
> On Tue, Feb 22, 2022 at 7:56 AM Suren Baghdasaryan <surenb@google.com> wrote:
> >
> > On Tue, Feb 22, 2022 at 1:17 AM Michal Hocko <mhocko@suse.com> 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