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 X-Spam-Level: X-Spam-Status: No, score=-13.3 required=3.0 tests=BAYES_00,DKIMWL_WL_MED, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,USER_IN_DEF_DKIM_WL autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 23CA1C432BE for ; Sat, 28 Aug 2021 21:53:34 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id AAFD660462 for ; Sat, 28 Aug 2021 21:53:33 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org AAFD660462 Authentication-Results: mail.kernel.org; dmarc=fail (p=reject dis=none) header.from=google.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=kvack.org Received: by kanga.kvack.org (Postfix) id 468BE8D0001; Sat, 28 Aug 2021 17:53:33 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 3F09E6B0071; Sat, 28 Aug 2021 17:53:33 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 290F48D0001; Sat, 28 Aug 2021 17:53:33 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0136.hostedemail.com [216.40.44.136]) by kanga.kvack.org (Postfix) with ESMTP id 155776B006C for ; Sat, 28 Aug 2021 17:53:33 -0400 (EDT) Received: from smtpin22.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay02.hostedemail.com (Postfix) with ESMTP id BDB5D269B1 for ; Sat, 28 Aug 2021 21:53:32 +0000 (UTC) X-FDA: 78525841464.22.E547EFD Received: from mail-yb1-f175.google.com (mail-yb1-f175.google.com [209.85.219.175]) by imf22.hostedemail.com (Postfix) with ESMTP id 66B281901 for ; Sat, 28 Aug 2021 21:53:32 +0000 (UTC) Received: by mail-yb1-f175.google.com with SMTP id z18so19847592ybg.8 for ; Sat, 28 Aug 2021 14:53:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=3ZLoRc8zgP/v6fBuiK/r7V3fCb7OpEy1oLfRJgXAgFE=; b=iNAUMJ1E+h3PcgTBuph6t34O4/GYB/x8t0AN3XLJYkzHXbSc+tcQQ+H6MHV4sZPerj Q5mSmXK7+qv3SX0wC+Z685Um9F5pgv/lIEZp511W1EZlAkLDGSnm2NFnsGYifzyyVj3k Jc2mIcY1g6wXGKMPg5v9NThOG24wc18zFxjqxaEul8Ody4x2qxR/y4CWpsADRayNckfJ DpxlTyHyTneIHkDURMtCvfp9/ofDgt+0KHIl/dwBauup9r4BEbGEQfWFDXMbNUgp8MB3 aUKRlenZuGE/uEWidqXa/rS9Q6tcRXasRykFO0mGYSEsWITy9kxk+EONJAwoV/XdoFmF cNPQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=3ZLoRc8zgP/v6fBuiK/r7V3fCb7OpEy1oLfRJgXAgFE=; b=WL5pgW5g3jQNca+0zm5+KF7dfWLgVfgQVd27NVDMFIyxTbD9GHYCO5EjPmQqaObHJa 26XnBrmHCgJ32DrFFzi7um5J7moxgHhnkpa5pWRfFu099ohGc9aiOn8pPudW+r/MnQj2 T4akjbTeSYxtKFhcF3XwbVkKwvc704Re5kmi3GTXzTcXmqQ464dd/n5hO4pZppL1MIDE z96yJ4pe+MkFUYkPioN0HfnD1G25xDA7yOUqV5SGmA+c32qGgOuztpNpxWyqfoSNpWmb k9r+CV0G23ZT9SZcpOa5XKtJwG8qRUR6OzRKdN1aM8FBqUz5/UQKK0zaRUCR56emjZ9B b+Yw== X-Gm-Message-State: AOAM532lho1aJ2gJQ8PDKYFw+xDg8LXwqhksNbXasnpMEYrpT0rGr5YR eNeEh0PJ8DyjwV6r2Cbi5btxSLXiqjwEutXXLspDfg== X-Google-Smtp-Source: ABdhPJwj1EM/du+54jmqkuXBOkV1QaQYiv7WXfuRvRGstLf/QXfLboXB4RNTPVw7h240QWLn4XdvgYE2TJv1Qj7tquw= X-Received: by 2002:a25:21c5:: with SMTP id h188mr13130824ybh.23.1630187611436; Sat, 28 Aug 2021 14:53:31 -0700 (PDT) MIME-Version: 1.0 References: <20210827191858.2037087-1-surenb@google.com> <20210827191858.2037087-3-surenb@google.com> In-Reply-To: From: Suren Baghdasaryan Date: Sat, 28 Aug 2021 14:53:20 -0700 Message-ID: Subject: Re: [PATCH v8 2/3] mm: add a field to store names for private anonymous memory To: Cyrill Gorcunov Cc: Andrew Morton , Colin Cross , Sumit Semwal , Michal Hocko , Dave Hansen , Kees Cook , Matthew Wilcox , "Kirill A . Shutemov" , Vlastimil Babka , Johannes Weiner , Jonathan Corbet , Al Viro , Randy Dunlap , Kalesh Singh , Peter Xu , rppt@kernel.org, Peter Zijlstra , Catalin Marinas , vincenzo.frascino@arm.com, =?UTF-8?B?Q2hpbndlbiBDaGFuZyAo5by16Yym5paHKQ==?= , Axel Rasmussen , Andrea Arcangeli , Jann Horn , apopple@nvidia.com, John Hubbard , Yu Zhao , Will Deacon , fenghua.yu@intel.com, thunder.leizhen@huawei.com, Hugh Dickins , feng.tang@intel.com, Jason Gunthorpe , Roman Gushchin , Thomas Gleixner , krisman@collabora.com, chris.hyser@oracle.com, Peter Collingbourne , "Eric W. Biederman" , Jens Axboe , legion@kernel.org, eb@emlix.com, Muchun Song , Viresh Kumar , thomascedeno@google.com, sashal@kernel.org, cxfcosmos@gmail.com, linux@rasmusvillemoes.dk, LKML , linux-fsdevel@vger.kernel.org, linux-doc@vger.kernel.org, linux-mm , kernel-team Content-Type: text/plain; charset="UTF-8" Authentication-Results: imf22.hostedemail.com; dkim=pass header.d=google.com header.s=20161025 header.b=iNAUMJ1E; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf22.hostedemail.com: domain of surenb@google.com designates 209.85.219.175 as permitted sender) smtp.mailfrom=surenb@google.com X-Rspamd-Server: rspam06 X-Rspamd-Queue-Id: 66B281901 X-Stat-Signature: f6bd4p8gs68gtaaqbjdefwzn5w5sj7jy X-HE-Tag: 1630187612-975740 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 Sat, Aug 28, 2021 at 2:28 PM Cyrill Gorcunov wrote: > > On Fri, Aug 27, 2021 at 12:18:57PM -0700, Suren Baghdasaryan wrote: > > > > The name is stored in a pointer in the shared union in vm_area_struct > > that points to a null terminated string. Anonymous vmas with the same > > name (equivalent strings) and are otherwise mergeable will be merged. > > The name pointers are not shared between vmas even if they contain the > > same name. The name pointer is stored in a union with fields that are > > only used on file-backed mappings, so it does not increase memory usage. > > > > The patch is based on the original patch developed by Colin Cross, more > > specifically on its latest version [1] posted upstream by Sumit Semwal. > > It used a userspace pointer to store vma names. In that design, name > > pointers could be shared between vmas. However during the last upstreaming > > attempt, Kees Cook raised concerns [2] about this approach and suggested > > to copy the name into kernel memory space, perform validity checks [3] > > and store as a string referenced from vm_area_struct. > > One big concern is about fork() performance which would need to strdup > > anonymous vma names. Dave Hansen suggested experimenting with worst-case > > scenario of forking a process with 64k vmas having longest possible names > > [4]. I ran this experiment on an ARM64 Android device and recorded a > > worst-case regression of almost 40% when forking such a process. This > > regression is addressed in the followup patch which replaces the pointer > > to a name with a refcounted structure that allows sharing the name pointer > > between vmas of the same name. Instead of duplicating the string during > > fork() or when splitting a vma it increments the refcount. > > > > [1] https://lore.kernel.org/linux-mm/20200901161459.11772-4-sumit.semwal@linaro.org/ > > [2] https://lore.kernel.org/linux-mm/202009031031.D32EF57ED@keescook/ > > [3] https://lore.kernel.org/linux-mm/202009031022.3834F692@keescook/ > > [4] https://lore.kernel.org/linux-mm/5d0358ab-8c47-2f5f-8e43-23b89d6a8e95@intel.com/ > ... > > + > > +/* mmap_lock should be read-locked */ > > +static inline bool is_same_vma_anon_name(struct vm_area_struct *vma, > > + const char *name) > > +{ > > + const char *vma_name = vma_anon_name(vma); > > + > > + if (likely(!vma_name)) > > + return name == NULL; > > + > > + return name && !strcmp(name, vma_name); > > +} > > Hi Suren! There is very important moment with this new feature: if > we assign a name to some VMA it won't longer be mergeable even if > near VMA matches by all other attributes such as flags, permissions > and etc. I mean our vma_merge() start considering the vma namings > and names mismatch potentially blocks merging which happens now > without this new feature. Is it known behaviour or I miss something > pretty obvious here? Hi Cyrill, Correct, this is a known drawback of naming an anonymous VMA. I think I'll need to document this in prctl(2) manpage, which I should update to include this new PR_SET_VMA_ANON_NAME option. Thanks for pointing it out! Suren.