Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
Message-ID: <cfee81a4-ef97-deb8-411b-d02c8bf67fed@oracle.com>
Date:   Wed, 26 Jan 2022 10:33:44 -0700
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101
 Thunderbird/91.3.1
Subject: Re: [RFC PATCH 0/6] Add support for shared PTEs across processes
Content-Language: en-US
To:     Mike Rapoport <rppt@kernel.org>,
        "Kirill A. Shutemov" <kirill@shutemov.name>
Cc:     Matthew Wilcox <willy@infradead.org>, akpm@linux-foundation.org,
        longpeng2@huawei.com, arnd@arndb.de, dave.hansen@linux.intel.com,
        david@redhat.com, surenb@google.com, linux-kernel@vger.kernel.org,
        linux-mm@kvack.org
References: <cover.1642526745.git.khalid.aziz@oracle.com>
 <20220125114212.ks2qtncaahi6foan@box.shutemov.name>
 <Ye/5yUyEqO0ws0G5@casper.infradead.org>
 <20220125135917.ezi6itozrchsdcxg@box.shutemov.name>
 <YfAEqzTeBJSIOKcA@casper.infradead.org>
 <20220125185705.wf7p2l77vggipfry@box.shutemov.name>
 <YfBIpmxvc0+mFByf@casper.infradead.org>
 <YfDIYKygRHX4RIri@casper.infradead.org>
 <20220126134247.fadtwbvyknh3ejpe@box.shutemov.name>
 <YfFYUWOieZw9wap7@kernel.org>
From:   Khalid Aziz <khalid.aziz@oracle.com>
In-Reply-To: <YfFYUWOieZw9wap7@kernel.org>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
MIME-Version: 1.0
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?MGxFY05JcVc5bWdkM08yR0ZYZGNaRkxKbnJCZW9FcEJNbWZScHBqa3NBREFl?=
 =?utf-8?B?LzZ0dzBMbmlpY3VwYVdVWW96eENqZWppUG92aGJzcHVDMzI3WGl3ampPWnVZ?=
 =?utf-8?B?ZUtHMW1SV2lnbFlMSnlmVjFFVEFUaXlBWnFrUkZHZWRJbUdpbWlHcVpmNmg1?=
 =?utf-8?B?bjZUZjhIVmFUZEFINjVVRk1DSWdXQ0haSTVCc3ljK1RHaVBjUmptbGNNdEtG?=
 =?utf-8?B?c0RMTUVuWmt6eFY2NGpSL2pabnU4ZEkzL2RaT0lsMnAvU1pVODN3ZkhDeHRR?=
 =?utf-8?B?MVN6cUF6RVpOL3drbDJhOThadmNDbXVkVFBZMTh5VlJRaENoL1cvSEF4SWtp?=
 =?utf-8?B?eXQ2NE82cVk2TEdJeVErQ1Vtemt2NFVSSXpmWGZUSGl0SkpRSUJpaXJOL1ht?=
 =?utf-8?B?VCtxdEhQdlJSZjY2cU9icjU4MVFxN3NEbTc0cU16NDdsS01jbVV0d1BtTUhJ?=
 =?utf-8?B?TitKWVFaVHZVTjV1QUJqTmdvN3NKM0M0bkNWQkMwZ2FmSTBoaTNGU0V3cldp?=
 =?utf-8?B?OXQybFhHMmlubUtYbklPM2pHdlZBTHFBT3JpNG96c0pPZmVTMHJ6djdKSTVu?=
 =?utf-8?B?K0ljeENJaHh0cktjYkVSQUlrQVhLYzJFZXZlU3owY3JXUlZxc1FZQTZlN3pw?=
 =?utf-8?B?aDdEUUxYbEtuZlgrdlgyelR4VjVmMGlISlZRYkZ1VjRIbGRKSWRHQ0lzSlpr?=
 =?utf-8?B?eXBKL3k0cFB1VythWVdmNzMvR3VSVmFDSGZ4S0JaZzFwN3h6dzRjbXBLTzRk?=
 =?utf-8?B?eEVJZVllNkxIamdrcEp1SVkwc3dHM1IzRlFsODN2M2NGTTJBNzNSMytTc1NI?=
 =?utf-8?B?K2l5K2pzZGZGWDBuNklaNzhMVWRuM1JsRk9UZm1uU2RSMDFWNCtBSS93bmhS?=
 =?utf-8?B?L1JSaHRNMnkvaSszUGx4eHkyTjhZOU5vQ3h2aUdlNnF2TWJCT1RPd3ozS3Bk?=
 =?utf-8?B?TVIxcWp6ZkI3MXNCektOZzhPcDdpSVYzNUNYcVlob3BKNjNKNVJmdTh2aEsx?=
 =?utf-8?B?bjFsNEJpRjQwemhMVEw2SFlDMHh4d293N1VMbEVHY0s2M25BbCtYeVYxTnZZ?=
 =?utf-8?B?eXJXTmt6cWdaMzVWT2E2d3dNc1RjejNkQldyOW91M3picnFYb2ZMTUVpYzc1?=
 =?utf-8?B?SDFJNkFxMWlpWXc0WkZkRFlwZDIvTk50REl3ekxnc1dobk9uZE9nNzJoTEVx?=
 =?utf-8?B?d2I0WG5QdEp3ci9ES1FuQlRDMG1QejNWNWFZL25vWWpxQnM5MHp2SFdYalJk?=
 =?utf-8?B?ZFBnaHdjNXVTK3oxN3BXZ0lzYTNFUE84UWtPdVgzWTlnam9QdUpOYkJpVy9S?=
 =?utf-8?B?WDR3MjNtenFzNzhIaGYvNUN3Wko4M3dHYXBoTjk4SzVwbG5XRGhCV3pSWHJ3?=
 =?utf-8?B?cmI3ekJXQnlhUEdNekFkeTFTZG1iTnI5ZmdwZ0N4L0lBNDlXbUxyRC92Y2hF?=
 =?utf-8?B?ODJoNS9MV2Y1L1hXaDhyejFGWVFNVFRaaVh1aDJyMEUzcjlwcllUV3REYXpW?=
 =?utf-8?B?blMvcEVXN29CbU84QWtwM3JmTHFxVlNGTzdUdFFtbG1WRVMvck83aXJweGxW?=
 =?utf-8?B?cDdqRVpXWU9GdUVpUFQ4ZHBtWmdFaUZIaXl5bTd0UFlJZDlBTEpPM3JlbmVS?=
 =?utf-8?B?Tjg1bHVQMlY2NE0zelZSZlQxOUdzMkF3OS8zZ1g5SGhDcG9yd25sS0hJSmJ5?=
 =?utf-8?B?L1dWUFJnM0ZtaWtaQTk0UDQ2Tmk3blJrL0VBby9pNmxlM2tLUVc5SXlYMkhZ?=
 =?utf-8?B?M05VdXFCeHp4UG1oVE9maHJUSko0OC9VMk9oZHdGN0Frbzhja1NzejRwTU1M?=
 =?utf-8?B?TjFFeVNrUnVDNTRId0Z0MUVHNnhybFhGU3lXTVYxUjFDeHhKMjJiNDBGTDRx?=
 =?utf-8?B?WUtmeVdYYzBSUGhUb29tV3QrL0ZKSmFFTEw0YXNaUXFHVkJpOVppakdLUFFn?=
 =?utf-8?B?RndIc3YrQjdZU3hyNjZmM2w0eU1UVmVoRzRtNGw2VURCUWZsdXhic0p3akNG?=
 =?utf-8?B?UGh2c0ZqNUhrYXFQNmlvQjA5QU1XMVQvQWtrYkFUaDNxdW16bEc3cGRZcGZJ?=
 =?utf-8?B?V1FGQi80M3hVQXRRYk5jdTlaek5ZSkdaU3Z2Yk81bncrZDQwTTN4b2dWZGlK?=
 =?utf-8?B?OGNMSFZueG9UWWNYejVoY3hEUWNCZjlRNHZhTXpxUlc3ZkNsQzQyUTVmejFH?=
 =?utf-8?Q?1a6/7S6eaBBLQWufUuIhQCgo7oBwmPKcfIkViNrOLF9I?=
X-OriginatorOrg: oracle.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 44d0bf27-307f-4c6f-530c-08d9e0f2034b
X-MS-Exchange-CrossTenant-AuthSource: BN8PR10MB3220.namprd10.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 26 Jan 2022 17:33:49.3642
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 4e2c6054-71cb-48f1-bd6c-3a9705aca71b
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: 1EuaEOcnqEULDpttNz8omsju7Ssz34DlV9G3vtWVQ39E7+0yDkuhPCTcm96GsvjxspVCJZ1dgaH5Kjzz/IJ52Q==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SA1PR10MB5783
X-Proofpoint-Virus-Version: vendor=nai engine=6300 definitions=10239 signatures=668683
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 malwarescore=0 mlxlogscore=999
 adultscore=0 spamscore=0 bulkscore=0 mlxscore=0 phishscore=0
 suspectscore=0 classifier=spam adjust=0 reason=mlx scancount=1
 engine=8.12.0-2201110000 definitions=main-2201260107
X-Proofpoint-GUID: 4L8jOZCO6teyvyFT5Q7aJpjKAFeF6B41
X-Proofpoint-ORIG-GUID: 4L8jOZCO6teyvyFT5Q7aJpjKAFeF6B41
Precedence: bulk
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

On 1/26/22 07:18, Mike Rapoport wrote:
> On Wed, Jan 26, 2022 at 04:42:47PM +0300, Kirill A. Shutemov wrote:
>> On Wed, Jan 26, 2022 at 04:04:48AM +0000, Matthew Wilcox wrote:
>>> On Tue, Jan 25, 2022 at 06:59:50PM +0000, Matthew Wilcox wrote:
>>>> On Tue, Jan 25, 2022 at 09:57:05PM +0300, Kirill A. Shutemov wrote:
>>
>>> So how about something like this ...
>>>
>>> int mcreate(const char *name, int flags, mode_t mode);
>>>
>>> creates a new mm_struct with a refcount of 2.  returns an fd (one
>>> of the two refcounts) and creates a name for it (inside msharefs,
>>> holds the other refcount).
>>>
>>> You can then mmap() that fd to attach it to a chunk of your address
>>> space.  Once attached, you can start to populate it by calling
>>> mmap() and specifying an address inside the attached mm as the first
>>> argument to mmap().
>>
>> That is not what mmap() would normally do to an existing mapping. So it
>> requires special treatment.
>>
>> In general mmap() of a mm_struct scares me. I can't wrap my head around
>> implications.
>>
>> Like how does it work on fork()?
>>
>> How accounting works? What happens on OOM?
>>
>> What prevents creating loops, like mapping a mm_struct inside itself?
>>
>> What mremap()/munmap() do to such mapping? Will it affect mapping of
>> mm_struct or will it target mapping inside the mm_sturct?
>>
>> Maybe it just didn't clicked for me, I donno.
> 
> My understanding was that the new mm_struct would be rather stripped and
> will be used more as an abstraction for the shared page table, maybe I'm
> totally wrong :)

Your understanding is correct for the RFC implementation of mshare(). mcreate() is a different beast that I do not fully 
understand yet. From Matthew's explanation, it sounds like what he has in mind is that mcreate() is a frontend to 
mshare/msharefs, uses mshare to created the shared region and thus allows a user to mprotect a single page inside the 
mmap it creates using the fd returned by mcreate. mshare underneath automagically extends the new page protection to 
every one sharing that page owing to shared PTE.

--
Khalid

>   
>>> Maybe mcreate() is just a library call, and it's really a thin wrapper
>>> around open() that happens to know where msharefs is mounted.
>>
>> -- 
>>   Kirill A. Shutemov
>