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 mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 28CE3C433F5 for ; Fri, 15 Oct 2021 16:39:57 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id B6C5760C41 for ; Fri, 15 Oct 2021 16:39:56 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org B6C5760C41 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=redhat.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=kvack.org Received: by kanga.kvack.org (Postfix) id 4A3B66B0072; Fri, 15 Oct 2021 12:39:56 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 42CDD6B0073; Fri, 15 Oct 2021 12:39:56 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 2A575900002; Fri, 15 Oct 2021 12:39:56 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0063.hostedemail.com [216.40.44.63]) by kanga.kvack.org (Postfix) with ESMTP id 1B4D86B0072 for ; Fri, 15 Oct 2021 12:39:56 -0400 (EDT) Received: from smtpin29.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay04.hostedemail.com (Postfix) with ESMTP id B2600348D8 for ; Fri, 15 Oct 2021 16:39:55 +0000 (UTC) X-FDA: 78699233550.29.7C27851 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [216.205.24.124]) by imf29.hostedemail.com (Postfix) with ESMTP id D0A5D9000094 for ; Fri, 15 Oct 2021 16:39:53 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1634315994; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=E4LKFDRNGrYewkIQEu16Zm63HJjl+j0dZzAICvUOLVM=; b=CBjO6tr8fYwuZhZFO0HMUscuN+Os6YFooRl+XbVGo1YwhMnqK4qyd/tBdoBeT5Vz/liFGw 3UCz8CnXIKKK4000l1v0BtZkJ47ClqUk8RHlRFpMXGbIjH+C/BuEsFhHKSDRGiCfZxv5P4 D9sQ6E8QbDiU1PvFVi2gFIrsJL7wl7U= Received: from mail-wr1-f72.google.com (mail-wr1-f72.google.com [209.85.221.72]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-461-t61-O_fOMO-7uZSk-iPY_Q-1; Fri, 15 Oct 2021 12:39:53 -0400 X-MC-Unique: t61-O_fOMO-7uZSk-iPY_Q-1 Received: by mail-wr1-f72.google.com with SMTP id 41-20020adf812c000000b00160dfbfe1a2so6183447wrm.3 for ; Fri, 15 Oct 2021 09:39:53 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:message-id:date:mime-version:user-agent:subject :content-language:to:cc:references:from:organization:in-reply-to :content-transfer-encoding; bh=E4LKFDRNGrYewkIQEu16Zm63HJjl+j0dZzAICvUOLVM=; b=GVrCTB/g4WLAL8rd5FC+NaNURBXxqeqquFgNd/3mlYhcNxOBr+DzcuJvofjX54eoeD llozUgPe1cGd3c8ZwaHmA+SGCcKrX5bz6S/HAGBChkuG792uiJvgbdDqRjFMbALGnHUB xxryX49MB/DHk+UoERrNN6YtrtDk+89BAcqNsfleiiuzdfueOnW66Hz0bStiepeXcnMl D1jrGa/7pLshLTGRHeEhDR3Rf56cvleiKZF7N0fVjYh+Hvc+XIyEvH8juBkhKbI0SEur XINphtqv0MEkNY4FjB+EeDKqkQVqMma4OVbjVvqT58V/n7RT1GwH7tZoHvvziVN5JyCK bX8A== X-Gm-Message-State: AOAM532VtqgMtBPR1qeg8HBMw8MsYkF1BPuVNrAB9yWAoANT1BNnSrdG W/GoE66d029ayCQ5xfVBbG06O0V7zaa/5YLYj2XB5+69EG5kxZXT5kfp1w6il3JGx86+kkR8vcD rF0o8Qy0keqs= X-Received: by 2002:a1c:2b85:: with SMTP id r127mr27224272wmr.134.1634315992125; Fri, 15 Oct 2021 09:39:52 -0700 (PDT) X-Google-Smtp-Source: ABdhPJyu+oFauM+GGmdwcOZ7EltiO+NPKXOxlX3q1W1CdIvB6o2LNj90pM8GL+iApDfNPPofqFTTsA== X-Received: by 2002:a1c:2b85:: with SMTP id r127mr27224197wmr.134.1634315991799; Fri, 15 Oct 2021 09:39:51 -0700 (PDT) Received: from [192.168.3.132] (p5b0c6a01.dip0.t-ipconnect.de. [91.12.106.1]) by smtp.gmail.com with ESMTPSA id y8sm4956776wmi.43.2021.10.15.09.39.49 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 15 Oct 2021 09:39:51 -0700 (PDT) Message-ID: <3563a3e8-b971-b604-7388-766ecfce4634@redhat.com> Date: Fri, 15 Oct 2021 18:39:49 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.1.0 Subject: Re: [PATCH v10 3/3] mm: add anonymous vma name refcounting To: Suren Baghdasaryan Cc: Michal Hocko , Kees Cook , Pavel Machek , Rasmus Villemoes , John Hubbard , Andrew Morton , Colin Cross , Sumit Semwal , Dave Hansen , 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, 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 , Peter Collingbourne , "Eric W. Biederman" , Jens Axboe , legion@kernel.org, Rolf Eike Beer , Cyrill Gorcunov , Muchun Song , Viresh Kumar , Thomas Cedeno , sashal@kernel.org, cxfcosmos@gmail.com, LKML , linux-fsdevel@vger.kernel.org, linux-doc@vger.kernel.org, linux-mm , kernel-team References: <92cbfe3b-f3d1-a8e1-7eb9-bab735e782f6@rasmusvillemoes.dk> <20211007101527.GA26288@duo.ucw.cz> <202110071111.DF87B4EE3@keescook> <202110081344.FE6A7A82@keescook> <26f9db1e-69e9-1a54-6d49-45c0c180067c@redhat.com> From: David Hildenbrand Organization: Red Hat In-Reply-To: X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Language: en-US Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Rspamd-Server: rspam03 X-Rspamd-Queue-Id: D0A5D9000094 X-Stat-Signature: srupt8q37cwjuamwn51mjccsgy5uwfan Authentication-Results: imf29.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=CBjO6tr8; dmarc=pass (policy=none) header.from=redhat.com; spf=none (imf29.hostedemail.com: domain of david@redhat.com has no SPF policy when checking 216.205.24.124) smtp.mailfrom=david@redhat.com X-HE-Tag: 1634315993-360678 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: >>> >>> 1. Forking a process with anonymous vmas named using memfd is 5-15% >>> slower than with prctl (depends on the number of VMAs in the process >>> being forked). Profiling shows that i_mmap_lock_write() dominates >>> dup_mmap(). Exit path is also slower by roughly 9% with >>> free_pgtables() and fput() dominating exit_mmap(). Fork performance is >>> important for Android because almost all processes are forked from >>> zygote, therefore this limitation already makes this approach >>> prohibitive. >> >> Interesting, naturally I wonder if that can be optimized. > > Maybe but it looks like we simply do additional things for file-backed > memory, which seems natural. The call to i_mmap_lock_write() is from > here: https://elixir.bootlin.com/linux/latest/source/kernel/fork.c#L565 > >> >>> >>> 2. mremap() usage to grow the mapping has an issue when used with memfds: >>> >>> fd = memfd_create(name, MFD_ALLOW_SEALING); >>> ftruncate(fd, size_bytes); >>> ptr = mmap(NULL, size_bytes, prot, MAP_PRIVATE, fd, 0); >>> close(fd); >>> ptr = mremap(ptr, size_bytes, size_bytes * 2, MREMAP_MAYMOVE); >>> touch_mem(ptr, size_bytes * 2); >>> >>> This would generate a SIGBUS in touch_mem(). I believe it's because >>> ftruncate() specified the size to be size_bytes and we are accessing >>> more than that after remapping. prctl() does not have this limitation >>> and we do have a usecase for growing a named VMA. >> >> Can't you simply size the memfd much larger? I mean, it doesn't really >> cost much, does it? > > If we know beforehand what the max size it can reach then that would > be possible. I would really hate to miscalculate here and cause a > simple memory access to generate signals. Tracking such corner cases > in the field is not an easy task and I would rather avoid the > possibility of it. The question would be if you cannot simply add some extremely large number, because the file size itself doesn't really matter for memfd IIRC. Having that said, without trying it out, I wouldn't know from the top of my head if memremap would work that way on an already closed fd that ahs a sufficient size :/ If you have the example still somewhere, I would be interested if that would work in general. [...] >> >>> >>> 4. There is a usecase in the Android userspace where vma naming >>> happens after memory was allocated. Bionic linker does in-memory >>> relocations and then names some relocated sections. >> >> Would renaming a memfd be an option or is that "too late" ? > > My understanding is that linker allocates space to load and relocate > the code, performs the relocations in that space and then names some > of the regions after that. Whether it can be redesigned to allocate > multiple named regions and perform the relocation between them I did > not really try since it would be a project by itself. > > TBH, at some point I just look at the amount of required changes (both > kernel and userspace) and new limitations that userspace has to adhere > to for fitting memfds to my usecase, and I feel that it's just not > worth it. In the end we end up using the same refcounted strings with > vma->vm_file->f_count as the refcount and name stored in > vma->vm_file->f_path->dentry but with more overhead. Yes, but it's glued to files which naturally have names :) Again, I appreciate that you looked into alternatives! I can see the late renaming could be the biggest blocker if user space cannot be adjusted easily to be compatible with that using memfds. -- Thanks, David / dhildenb