From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 0CCEBC433EF for ; Wed, 23 Feb 2022 03:02:21 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 27A268D0002; Tue, 22 Feb 2022 22:02:21 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 201E78D0001; Tue, 22 Feb 2022 22:02:21 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 055388D0002; Tue, 22 Feb 2022 22:02:20 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0069.hostedemail.com [216.40.44.69]) by kanga.kvack.org (Postfix) with ESMTP id E2E518D0001 for ; Tue, 22 Feb 2022 22:02:20 -0500 (EST) Received: from smtpin19.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay05.hostedemail.com (Postfix) with ESMTP id A2649181CC1DD for ; Wed, 23 Feb 2022 03:02:20 +0000 (UTC) X-FDA: 79172546040.19.9E1317C Received: from mail-yb1-f182.google.com (mail-yb1-f182.google.com [209.85.219.182]) by imf22.hostedemail.com (Postfix) with ESMTP id 31F8AC0009 for ; Wed, 23 Feb 2022 03:02:20 +0000 (UTC) Received: by mail-yb1-f182.google.com with SMTP id e140so45161327ybh.9 for ; Tue, 22 Feb 2022 19:02:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=m3dhHi9t8HBjtBlHg2OtAeNoMJdDzLs31EyU7LsN2Xo=; b=YkhxkNc1YtwscsTW86DVOSr9MuvVovvaRIQhTfomX0gsLgtKjkM2QEdVmQ2N3ZWTpg YCaaaijoQZsOPxYSC33IovBSRfFWapVKkgsCuYVEF8jre0tGThGtCCryN2MDNTNQ9qxM ZXe2Y0+zI1NLB6d4v6tDAK3CbjNJJtD3A/OwQkHa8G3AvqIHBXFssOEXjNJVRkNXOW8I IUG+wTH6awpg9Ecej60wlLM5NvukbQGh3CyCSboGE//onpkTEQF6YrthfTah6tjBs0t5 pjVR3gjA695MnDaYtgnI+GWBlCDrf3ohf/auzYmPalpbGfJWoM7ms6NuO13hux5jDlIw 0hvg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=m3dhHi9t8HBjtBlHg2OtAeNoMJdDzLs31EyU7LsN2Xo=; b=KLnlOTosqorfb8VaqnE3Bp8YodWUemXAnT4UoweVzMkGU7KepjGl3lDcz/+3/2AQFB TQcpT82uAJHjHmpgqMsKjC6Y/fDsxyAzzeIGDIPXT0VDkMcvNbtuBpceHlUKgKV1yPPi yn1Gm3mfouUt/6i2ivE5OHaG5eCdqScbgt08cOCwQRuVI8w7BQKMDaHVOhM5i6OOA3G0 S5BdNvuU0oLrxz98JZ977SaUYB2NZF6b2RLeeay554pffpsE8+jVRl5EYum1YEqrMgdk VOTcTwiJric2G4ADRLcb5u42y4GpjOcU0VPov8OOrjBirQ/2DIDmStNsuN6aPngbhO0H Dy0w== X-Gm-Message-State: AOAM533GreiNcVTtL+Z7E38WPLzH6KpSl+jfUPNrZB0GXjgr5Zdo2bVM qeM767k3VtUTh5qeqqbGLEUUymATgtpoMQBYZIl/gg== X-Google-Smtp-Source: ABdhPJyrRtAgfBrnIRae0Z5tJg6jdr50fW+RSI2quI4+iL7VhCHvyOFfeexPvlHR6geAie0W3sT9W7CH8Ob/QjY+oUM= X-Received: by 2002:a25:da47:0:b0:61d:9af4:c834 with SMTP id n68-20020a25da47000000b0061d9af4c834mr26964665ybf.441.1645585339250; Tue, 22 Feb 2022 19:02:19 -0800 (PST) MIME-Version: 1.0 References: <20220222054025.3412898-1-surenb@google.com> <20220222054025.3412898-2-surenb@google.com> In-Reply-To: From: Suren Baghdasaryan Date: Tue, 22 Feb 2022 19:02:08 -0800 Message-ID: Subject: Re: [PATCH 2/3] mm: prevent vm_area_struct::anon_name refcount saturation To: Michal Hocko 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 Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: 31F8AC0009 X-Stat-Signature: i3zydg85cxg1qt5ebgeuim35qgf7n1a7 X-Rspam-User: Authentication-Results: imf22.hostedemail.com; dkim=pass header.d=google.com header.s=20210112 header.b=YkhxkNc1; spf=pass (imf22.hostedemail.com: domain of surenb@google.com designates 209.85.219.182 as permitted sender) smtp.mailfrom=surenb@google.com; dmarc=pass (policy=reject) header.from=google.com X-Rspamd-Server: rspam05 X-HE-Tag: 1645585340-438408 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Tue, Feb 22, 2022 at 7:56 AM Suren Baghdasaryan wrote: > > On Tue, Feb 22, 2022 at 1:17 AM Michal Hocko 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? > > > > > > kref > > > refcounting interface used in anon_vma_name structure will detect > > > a counter overflow when it reaches REFCOUNT_SATURATED value but will > > > only generate a warning about broken refcounting. > > > To ensure anon_vma_name refcount does not overflow, stop anon_vma_name > > > sharing when the refcount reaches INT_MAX, which still leaves INT_MAX/2 > > > values before the counter reaches REFCOUNT_SATURATED. This should provide > > > enough headroom for raising the refcounts temporarily. > > > > > > Suggested-by: Michal Hocko > > > Signed-off-by: Suren Baghdasaryan > > > --- > > > include/linux/mm_inline.h | 18 ++++++++++++++---- > > > mm/madvise.c | 3 +-- > > > 2 files changed, 15 insertions(+), 6 deletions(-) > > > > > > diff --git a/include/linux/mm_inline.h b/include/linux/mm_inline.h > > > index 70b619442d56..b189e2638843 100644 > > > --- a/include/linux/mm_inline.h > > > +++ b/include/linux/mm_inline.h > > > @@ -156,15 +156,25 @@ static inline void anon_vma_name_get(struct anon_vma_name *anon_name) > > > > > > extern void anon_vma_name_put(struct anon_vma_name *anon_name); > > > > > > +static inline > > > +struct anon_vma_name *anon_vma_name_reuse(struct anon_vma_name *anon_name) > > > +{ > > > + /* Prevent anon_name refcount saturation early on */ > > > + if (kref_read(&anon_name->kref) < INT_MAX) { > > > > REFCOUNT_MAX seems to be defined by the kref framework. > > Ah, indeed. I missed that. Will change to use it. > > > > > Other than that looks good to me. > > Thanks for the review! > > > > > > + anon_vma_name_get(anon_name); > > > + return anon_name; > > > + > > > + } > > > + return anon_vma_name_alloc(anon_name->name); > > > +} > > > + > > > static inline void dup_vma_anon_name(struct vm_area_struct *orig_vma, > > > struct vm_area_struct *new_vma) > > > { > > > struct anon_vma_name *anon_name = vma_anon_name(orig_vma); > > > > > > - if (anon_name) { > > > - anon_vma_name_get(anon_name); > > > - new_vma->anon_name = anon_name; > > > - } > > > + if (anon_name) > > > + new_vma->anon_name = anon_vma_name_reuse(anon_name); > > > } > > > > > > static inline void free_vma_anon_name(struct vm_area_struct *vma) > > > diff --git a/mm/madvise.c b/mm/madvise.c > > > index f81d62d8ce9b..a395884aeecb 100644 > > > --- a/mm/madvise.c > > > +++ b/mm/madvise.c > > > @@ -122,8 +122,7 @@ static int replace_vma_anon_name(struct vm_area_struct *vma, > > > if (anon_vma_name_eq(orig_name, anon_name)) > > > return 0; > > > > > > - anon_vma_name_get(anon_name); > > > - vma->anon_name = anon_name; > > > + vma->anon_name = anon_vma_name_reuse(anon_name); > > > anon_vma_name_put(orig_name); > > > > > > return 0; > > > -- > > > 2.35.1.473.g83b2b277ed-goog > > > > -- > > Michal Hocko > > SUSE Labs