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 610F7CCFA0A for ; Thu, 26 Sep 2024 00:33:27 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id D56C76B00AC; Wed, 25 Sep 2024 20:33:26 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id D06236B00AD; Wed, 25 Sep 2024 20:33:26 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id BA7966B00AE; Wed, 25 Sep 2024 20:33:26 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0010.hostedemail.com [216.40.44.10]) by kanga.kvack.org (Postfix) with ESMTP id 9AFFE6B00AC for ; Wed, 25 Sep 2024 20:33:26 -0400 (EDT) Received: from smtpin22.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay03.hostedemail.com (Postfix) with ESMTP id 40347A070B for ; Thu, 26 Sep 2024 00:33:26 +0000 (UTC) X-FDA: 82605015612.22.FEDFC52 Received: from meesny.iki.fi (meesny.iki.fi [195.140.195.201]) by imf07.hostedemail.com (Postfix) with ESMTP id EFCA240003 for ; Thu, 26 Sep 2024 00:33:23 +0000 (UTC) Authentication-Results: imf07.hostedemail.com; dkim=pass header.d=iki.fi header.s=meesny header.b=QdF24qaV; spf=pass (imf07.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=pass ("iki.fi:s=meesny:i=1") ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1727310644; 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=V2m6BH2Lp4BBXI2ofu//Tlvq/CWXxU59kt760E/Zgyw=; b=Hf7mGRZ2MOFBRTPwAYGCiXjFv/wruGeK0ZUxa83e7YFFN0aHdU10quWXHeOjqIvuxFrKkb 8ay+q8jrGUZVlJHNvC2RYTeI5xOs2MpSPNKa2xpKUphSl1aoMfmm2DlrQ5qRTSRa54VUdL rteMzRHlEBlllQiunWUKloGXRtm1L78= ARC-Authentication-Results: i=2; imf07.hostedemail.com; dkim=pass header.d=iki.fi header.s=meesny header.b=QdF24qaV; spf=pass (imf07.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=pass ("iki.fi:s=meesny:i=1") ARC-Seal: i=2; s=arc-20220608; d=hostedemail.com; t=1727310644; a=rsa-sha256; cv=pass; b=v8OyU5UOOvablObKJXEkp13sknETyjlhxwuv8sKIvQLgc4Y8iemDE8/ENe0wmCu/vMtKV5 QWHCLZiYqF6iyCMthSXKevVH4DjQFakiiJyfvjAA1OwxJ45fDdyyeLVbdJLl/GSw0bVvba h5i47tColep/7iB3y2hu5EgM1qWbsXY= 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 4XDZMN4tMBzyS6; Thu, 26 Sep 2024 03:33:20 +0300 (EEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=iki.fi; s=meesny; t=1727310801; 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=V2m6BH2Lp4BBXI2ofu//Tlvq/CWXxU59kt760E/Zgyw=; b=QdF24qaVCExP8u0PvoL/C/ldShiJm4OrHakCtP+1eHyossSi/o0mxAo7T1cKPT2kB4wfgg GW8zpG0nAmemWJMoY6OG06N0dKXW/3qzcWVwzsdzA9n1P+nX2kcf5YSSVLsTWxXs62ZNsI 54UARJBY2kes9GCKd+j4duXQ0YgtNzg= ARC-Seal: i=1; s=meesny; d=iki.fi; t=1727310801; a=rsa-sha256; cv=none; b=zGOD6m7IEU2ds9ufy+o6TMxwCqV2+hXURULRaNwb90IjV2pE1S9NmHqdvzuHUYPtoA95EN HosaxLm3nFAw8eQfe/Ch720DEKxP5eTUpRu4ov3t8WS6UUSsCit3vsOjniNeHpdX6K6itI Yk5itTwDmiws+0wX66iUqGortApJqKA= 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=1727310800; 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=V2m6BH2Lp4BBXI2ofu//Tlvq/CWXxU59kt760E/Zgyw=; b=j+s9fAklxpFaRT7cP35+FYbJJVz5NqZVlJdpbd1YQx/4Hk4rs/z7nwg36yK05r4A5EeBiI Rzib+DuROVmYSENa8xFr8f+JQE2j0AjjyYbJDAknxyWmVg8QapunWl3CSGjimHVqpBnieq V2lMVsGoqeo/Anj3Ng+3ZDTDxw3H4MM= Mime-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=UTF-8 Date: Thu, 26 Sep 2024 03:33:19 +0300 Message-Id: Subject: Re: VMA merging updateds? From: "Jarkko Sakkinen" To: "Huang, Kai" , "Jarkko Sakkinen" , , X-Mailer: aerc 0.18.2 References: <51631b6d-5138-4195-8722-651d9ea79dc1@intel.com> In-Reply-To: <51631b6d-5138-4195-8722-651d9ea79dc1@intel.com> X-Rspamd-Server: rspam06 X-Rspamd-Queue-Id: EFCA240003 X-Stat-Signature: 8c9f7aoxqznyxo6riccjnbntasn755qz X-Rspam-User: X-HE-Tag: 1727310803-456756 X-HE-Meta: U2FsdGVkX18mN9wQYfUE3g3tL4K78nNrKzqS5lldD5Z3Hy+bGxauRZ6+O7l8vTIT1vml0KT02I7idTh8efoaqux4e9nhdRzzh8NpHDuIALv4IEqyP2T+FFTPnfJ8J0IUB2iSNNdNgX7GjM2tqGqbr/l2vEFS/qPWbp+E6WrSbR2cqbTr6NNfYG8bah6DV7oPX8vRqLPU2jABXSIa/ikK+3W6IzuZzkxkjwvjVvAPayfZg7VMm9mf/plPbHy3aatM24IgWF736JsgMfk/BHRCQnjTxu5YZVPstfmNoKiR3CecyqtU3l9EPxGY2tulBFr834Zr7ioa1jvUHKYc0flZOMjb+Jxrx8trLlfNfXYqMNt002F8OdZldfwM3XR1v4iqzFCW0ZX0Imqit98g9lDmgZ/ETnq3QBOZAUTHlpxPYM+cCSoGKPnv78eoJZ/ZY9Jda8fPaix7WBp8wqBbHC+zpxYJvAZQezxCKStWnY8qZsq9dKy2elPUZXZNg7bI/l8eCpyYDpvVd9gfpDklyqJpcJa/ZSlny9N8E+DRBaEDSRh29AHPg5aY/hC4YjDvzF+WZMaOXDmrqhs8VF4ygt2ZCeQymcrA7ed2vMC+9WQUbRQMHuD9Jmp00jvB9Iap76Hzi1wn1VNH4y1EPbuhq9J6k1TbSI2/Eu7AmYYHJjwU2hHhWRrWDDV3Y1gVjbAaQaUL2cP1T3ASwZPGAa6X4c/iynk2LpJegLQTNwhUbm5MtlFZX6kff/KlB4NWJQCHNQVN4pgMJLGcrlF1Z/y0VAOjI2v5TeiYPOW/4a7jSDr8wZZ3c6eNPhZgKSr3STgd7TO29e/hdXFKOXhjdD4DNCdxqVlH+O0T432WTRlJiUoFr320abr6+dz8hVnm4Cq7djszK0XUJ/5hV3Bp0kt139SxszKKY3fngmIyoh3nJkZ5vrUxHOEDh5S3oBThoirLKmo77J2W2XZM59qZx+d9Wur 7otz2ojS AzZnb4Y/Qpb6iwXZBbKr52lGhzqNyY95aDjrJ13KxRZZdWa6k+DbRv/fA1oUoNVhgMTZj1Mi6vTOQ4bc3xU5EMzFF6At4aJbsyLXqq1Z/JgrYcxSqbzSuGmdirnwgyIzqBWqPBCXafyBVZGIOwAVcN0Kd+wxSFzI0J6ZTdG3wLmRMj2X8hic7/dF5H4G+bdsf0AFF2mBWLKN/1o4RUD6YtLc9WNLeJ23ab+qSAIYBwLKK5jrEEA5366au3PAgusOqtepqiP+mLWiFpWYZUtJQvDmfYAf+eZ44+20kfz7xtVrdMdeoosjz8NdT/ppIgHG+e2mJ6brc2ukuN+OsnXI5yv7x5Hni78VV18zo X-Bogosity: Ham, tests=bogofilter, spamicity=0.002583, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: List-Subscribe: List-Unsubscribe: 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/884c7ea454cf2eb0ba2e95f7c25bd42018= 824f97.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). BR, Jarkko