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 84802CCFA0A for ; Thu, 26 Sep 2024 00:38:14 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 0125B8D0001; Wed, 25 Sep 2024 20:38:14 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id F04C96B00AD; Wed, 25 Sep 2024 20:38:13 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id DCCD58D0001; Wed, 25 Sep 2024 20:38:13 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0015.hostedemail.com [216.40.44.15]) by kanga.kvack.org (Postfix) with ESMTP id BD1B06B00AC for ; Wed, 25 Sep 2024 20:38:13 -0400 (EDT) Received: from smtpin28.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id 66E7BC0725 for ; Thu, 26 Sep 2024 00:38:13 +0000 (UTC) X-FDA: 82605027666.28.185AAEF Received: from meesny.iki.fi (meesny.iki.fi [195.140.195.201]) by imf12.hostedemail.com (Postfix) with ESMTP id 6752E40005 for ; Thu, 26 Sep 2024 00:38:11 +0000 (UTC) Authentication-Results: imf12.hostedemail.com; dkim=pass header.d=iki.fi header.s=meesny header.b=nrwRp1Ww; arc=pass ("iki.fi:s=meesny:i=1"); spf=pass (imf12.hostedemail.com: domain of jarkko.sakkinen@iki.fi designates 195.140.195.201 as permitted sender) smtp.mailfrom=jarkko.sakkinen@iki.fi; dmarc=none ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1727310971; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=QsCHVO2sdikPdrjkdbqgFfDhRwJoUJgXeqhcwKCUfQ0=; b=IbhjwlQLqZSwpzM/8VESr5qA3+vHtdkQwAraGnGYQEnYvR78t3Wcvo1R06L9ItUGWemdow AcEmbzg/nrrh+5/N3MZxpbla5euLBqCpOS6jLRuwk21ym+fJuKwJw+nlaie8rWftYE9FLz jr2f9M3dZGZOwibffJtQZFDtpOqc33M= ARC-Seal: i=2; s=arc-20220608; d=hostedemail.com; t=1727310971; a=rsa-sha256; cv=pass; b=x0R8luGWrZ1fx675IUndebAkNhICGESxxF3QgSfm0YEWWx+HvLOpQpgsb2KzD3YmaVbaEA 0gt20opWYxBFUM3hBSccV//weW2NvzCrwZl88Rpgx5DvvBv5giORiBD7B/YApTw55ZyvAW j31VQpUKt45+NN9mhRRxWrWd244gNJ8= ARC-Authentication-Results: i=2; imf12.hostedemail.com; dkim=pass header.d=iki.fi header.s=meesny header.b=nrwRp1Ww; arc=pass ("iki.fi:s=meesny:i=1"); spf=pass (imf12.hostedemail.com: domain of jarkko.sakkinen@iki.fi designates 195.140.195.201 as permitted sender) smtp.mailfrom=jarkko.sakkinen@iki.fi; dmarc=none Received: from localhost (83-245-197-106.elisa-laajakaista.fi [83.245.197.106]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) (Authenticated sender: sakkinen) by meesny.iki.fi (Postfix) with ESMTPSA id 4XDZSx3RlKzyS6; Thu, 26 Sep 2024 03:38:09 +0300 (EEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=iki.fi; s=meesny; t=1727311089; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=QsCHVO2sdikPdrjkdbqgFfDhRwJoUJgXeqhcwKCUfQ0=; b=nrwRp1WwIUGjHjMuw7Y+z8Hj4NRjBywl7F9XVBVAm8ThEZaEhtPztoPjKsf1L51AKddweX sBaYHyRm642lJeYzQBBQp1hWDQ3LtLJZbGZN7d41dxjF5fTixGbAZlmCmVbhHexSp10fBa BITklOS1vHQcb0qhmhOdzz1iTCMZr60= ARC-Seal: i=1; s=meesny; d=iki.fi; t=1727311089; a=rsa-sha256; cv=none; b=X8YGEy9GwmqgwkQBccqhtCzFUR3VJNQBgWafNVo5IxZuBkT93D/aOL62j6Sym/wkgqvnPV qrwPCNEGsw+mx+nhjeaY0nMmRLLgF7BgwxyVDFJvStjBfk20KoY6+qs4UQEUbeWjF4w7Aw 7fE9JJzEMvb0s0IgGct1W3Apo4I7iS0= ARC-Authentication-Results: i=1; ORIGINATING; auth=pass smtp.auth=sakkinen smtp.mailfrom=jarkko.sakkinen@iki.fi ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=iki.fi; s=meesny; t=1727311089; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=QsCHVO2sdikPdrjkdbqgFfDhRwJoUJgXeqhcwKCUfQ0=; b=BIYSaLJQp5aAliUc6beEU5/dzWTF2eVn0qXq5zFpHsG681wS9QGhNwnc2108EBdpr3DX5C gzdhnyC7/nAXLF3O28wAAfNQb6TebdHMjcpFHc6qKa3QVrxjbeQlJ9jtl8ZSr3OfxuwhzS 87MH/pcPgnz0iGjyv16kLiPH/g/kv8I= Mime-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=UTF-8 Date: Thu, 26 Sep 2024 03:38:08 +0300 Message-Id: Subject: Re: VMA merging updateds? From: "Jarkko Sakkinen" To: "Jarkko Sakkinen" , "Huang, Kai" , "Jarkko Sakkinen" , , X-Mailer: aerc 0.18.2 References: <51631b6d-5138-4195-8722-651d9ea79dc1@intel.com> In-Reply-To: X-Rspamd-Queue-Id: 6752E40005 X-Stat-Signature: yz4z7nsfosgi7zco1deyqs3a5iuzydbo X-Rspamd-Server: rspam09 X-Rspam-User: X-HE-Tag: 1727311091-772141 X-HE-Meta: U2FsdGVkX180NGO6+AN9dSadLRYjntcp7I/8+jfz3JGfK0ot0QdzM8OElM21X2hSIRlJMnw/js0nCXfNaSHrdPhAsVlzlgxcox3LVNacssmfGHMszZymOi7EzunMLUiH1A5AysELT1sp20YxwhwsHBSf3F3RstuL/iQ4yqNfuAQp0c+PDv3vMLSUk8bJ3CfAy3NXUEH9OuHwrbm8hzPAhG+ZdzEY+DolabNSvzMpUsBWLHGa5e0Q5LmzKspV5BHqbI5Cj0KzIWJnfKb8zBzGUvrBO7nF8bDn5cqdWUVkLQKvdEdJHOtaIelOjeddzEN49x20jR+XRoA2JHZgkeoXsSAzbRnqxRuE4COu5y05K9G4ZOXQy5N0WvJuuoYFqeraa91NAa40PMTbW1n/BTxJ6iL12o3iUgp7xgJLkhOJtqqmybRYGLs4/DKLt3BWGPFSqfBUz+IVD/54e0UacENbLgsK1PvaaMrvtO4EQmUYWMthvgcF98id8H+n5mnLBN5SRWez2UW4jW4EIanS6W5qNOEC7BEp+y4h8bYP+ogVtxeYnr8bEuAt+4JAup9XzkUD2UN77AgBnjCAYIFKSRZ+1YD0dt2gOxQsu1kGGdHYwvibjcqGfj3ZzNyWUcgkuKHOwh0GSAK8VcLcl828XMrn82qBU7eQbvg4XhvZbuDbIydBmj7mUuRK3XF+dm7CMER9Zrd/tYP13Zpdu+ofhy/5wzXLGv1GO4JxzssODVNezvxX6/xRlz9hoykOyRczqeyxX+2LwmrjwoWywX8SFcYzUT3bfEsFYHMtD2Ty9+/Vj3GjThn2IM7nTWw00Uz9HV0G29ZBYmeriCxhAAln/0KNScqK159R7f4y9omcMVWh4u9VBnh1kmff9hLSzLaesxLzw1mk7Ldp9WAqp9dzE2DewE/D0Movk+DjAqMNmbdL2Bzj8Zrbcl13kMOzj7JOeqlKFQ0chryQAw28VCmo+Hk uMBPNvsT URGtq8IFNVDzuoZqgHSqYEA7wdCREf2QpNRBY/HSLhywPMI6iPRWtGYU3xgQEXT93kNmZ+LtLSR3sUwnEJOz0lGTE3tCvLk+w22daGe++RtLu9C/ZbSvC+FCT0daWrqoiBgIQtbEgyF8WnsiXT7U4b8MeXxnH5RfKdFVOsh9OUs162CGF6j+/2B/Mw4Jftstd6AxhMH5O195TsRJCwAFTAsMMEtE8LRbK9maSVDlzavu09DQJHo0gV077nHHetnlSd9IORNN77cD/FgL7VoYz8TTsCGSUoGPTU2Y7UZQgOkSNj9mL33Vgvr/4l7tlcOgYMOzAbNGxQosMzM2qUOA1EEz53A== X-Bogosity: Ham, tests=bogofilter, spamicity=0.000269, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: List-Subscribe: List-Unsubscribe: qn Thu Sep 26, 2024 at 3:33 AM EEST, Jarkko Sakkinen wrote: > On Thu Sep 26, 2024 at 3:07 AM EEST, Kai Huang wrote: > > > > > > On 23/09/2024 7:48 pm, Jarkko Sakkinen wrote: > > > On Sun Sep 22, 2024 at 7:57 PM EEST, Jarkko Sakkinen wrote: > > >>> On Sun Sep 22, 2024 at 7:27 PM EEST, Jarkko Sakkinen wrote: > > >>>> Hi > > >>>> > > >>>> I started to look into this old issue with mm subsystem and SGX, i= .e. > > >>>> can we make SGX VMA's to merge together? > > >>>> > > >>>> This demonstrates the problem pretty well: > > >>>> > > >>>> https://lore.kernel.org/linux-sgx/884c7ea454cf2eb0ba2e95f7c25bd420= 18824f97.camel@kernel.org/ > > >>>> > > >>>> It was result of brk() syscall being applied a few times. > > >> > > >> Briging some context here. This can be fixed in the run-time by book > > >> keeping the ranges and doing unmapping/mapping. I guess this goes > > >> beyond what mm should support? > > >> > > >> I thought to plain check this as it has been two years since my last > > >> query on topic (if we could improve either the driver or mm somehow)= . > > >=20 > > > In the past I've substituted kernel's mm merge code with user space > > > replacement: > > >=20 > > > https://github.com/enarx/mmledger/blob/main/src/lib.rs > > >=20 > > > It's essentially a reimplementation of al stuff that goes into > > > mm/mmap.c's vma_merge(). I cannot recall anymore whether merges > > > which map over existing ranges were working correctly, i.e. was > > > the issue only concerning adjacent VMA's. > > >=20 > > > What I'm looking here is that can we make some cosntraints that > > > if satisfied by the pfnmap code, it could leverage the code from > > > vma_merge(). Perhaps by making explicit call to vma_merge()? > > > I get that implicit use moves too much responsibility to the mm > > > subsystem. > > >=20 > > > > Hi Jarkko, > > > > Just want to understand more on the background: > > > > Are you seeing any real problem due to needing a lot of mmap()s to the= =20 > > same enclave, or it is just a problem that doesn't look nice and you=20 > > want to resolve? > > > > I mean, this problem doesn't seem to be SGX-specific but a common one= =20 > > for VMAs with VM_PFNMAP (any bit in VM_SPECIAL), e.g., from random=20 > > device drivers with mmap() support. We will need a good justification= =20 > > if we want to make any core-mm change, if any, for this. > > It requires essentially replicating core mm in user space. > > It's a manageable problem but feels silly since logic in merging > is mostly 1:1. It's not a problem for me personally as I'm not > making any money from SGX (more so to Intel). I.e. in the case when you want do a syscall shim. You fix it up by maintaining reflected version of the VMA database in the user space and remapping everything based on that for every possible mm-call. I've implemented such feature in the past for Enarx so it is entirely possible. BR, Jarkko