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 9EABFEB64D8 for ; Wed, 14 Jun 2023 12:58:11 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 1861C8E0003; Wed, 14 Jun 2023 08:58:11 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 135B68E0002; Wed, 14 Jun 2023 08:58:11 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 024338E0003; Wed, 14 Jun 2023 08:58:10 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0012.hostedemail.com [216.40.44.12]) by kanga.kvack.org (Postfix) with ESMTP id E6A6F8E0002 for ; Wed, 14 Jun 2023 08:58:10 -0400 (EDT) Received: from smtpin23.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id A1E35140640 for ; Wed, 14 Jun 2023 12:58:10 +0000 (UTC) X-FDA: 80901356340.23.7AF4067 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by imf29.hostedemail.com (Postfix) with ESMTP id E4800120023 for ; Wed, 14 Jun 2023 12:58:08 +0000 (UTC) Authentication-Results: imf29.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=RtC5+Nub; spf=pass (imf29.hostedemail.com: domain of rppt@kernel.org designates 139.178.84.217 as permitted sender) smtp.mailfrom=rppt@kernel.org; dmarc=pass (policy=none) header.from=kernel.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1686747489; a=rsa-sha256; cv=none; b=x6Ue4lGZLZHUb+AMgXVJdcEH10URcLQ0pH/F6aY9dHN8cBsnXfEqjsnE/4E3m0Rydm7Tc3 HVlX2U92A608bvD1RAZCQ7y8pCIez0XExETMbSlRpyZW8kSlGGAE2bjpuL8akldQl87wRJ n9Y6NR6S3+JLuzPxZ4vXwE+4gjFizO0= ARC-Authentication-Results: i=1; imf29.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=RtC5+Nub; spf=pass (imf29.hostedemail.com: domain of rppt@kernel.org designates 139.178.84.217 as permitted sender) smtp.mailfrom=rppt@kernel.org; dmarc=pass (policy=none) header.from=kernel.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1686747489; 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=BzXCXx7cBwPSI39tbZPTep8QaXvgiwztYhs8Ny3g/Ys=; b=w/v0WcwMJ33wZGRvDMRZAqRmcV7eQVIFCk5vQlepGLS9lj85YkLoEXLumlA1mA8h+6wOIk 5K3R9uTzCRYJ8AbIXkawkHmlCyN7dPxjMcFqEaxb59BqLCKx3l5Nu6tyr8//bKdnqfXh4u haHxfAI+qGPhExGmXSABcJwGn/01ctQ= Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id C5DE160E71; Wed, 14 Jun 2023 12:58:07 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 3A4C3C433C0; Wed, 14 Jun 2023 12:58:01 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1686747487; bh=ARyKFKyAQ4+Tskav+UjOL70NYKP30fjk7d+NNv9YBkE=; h=Date:From:To:Subject:References:In-Reply-To:From; b=RtC5+NubFNMCdMH9tY/glGMEhV2jEw6VdetqDTjN6fBVqaTKKAYY8Z99AoZ1O9khI WzEIAcbLOiGR+RwsiceFy0MmKFHY2hoouOjM2qSmnW7QPGZ8rVbx90eUpg8hR0soVX k/PwK3/JYXunSo/l1FgBr8OsRQDlqoB5PhoKdADRACYO/KaO//IC5Y1l3oVo5ypfcN zfAkdLJcLDwIAm+TiMyDcmNlKxwySYx9we3s8u9e/NAeF0BmQQDwhoFGuPymRdnnwT C4nTBDSj1oYD8Euis/wyz0VjrYa+meJGa7psExl42Tm+4JztGvp0orscg4S6VKlA5h faqv2TaFPhS3A== Date: Wed, 14 Jun 2023 15:57:31 +0300 From: Mike Rapoport To: "Liam R. Howlett" , Jeff Xu , Peter Xu , linux-mm@kvack.org, linux-hardening@vger.kernel.org, zhangpeng.00@bytedance.com, akpm@linux-foundation.org, koct9i@gmail.com, david@redhat.com, ak@linux.intel.com, hughd@google.com, emunson@akamai.com, rppt@linux.ibm.com, aarcange@redhat.com, linux-kernel@vger.kernel.org, Lorenzo Stoakes Subject: Re: inconsistence in mprotect_fixup mlock_fixup madvise_update_vma Message-ID: <20230614125731.GY52412@kernel.org> References: <20230614011814.sz2l6z6wbaubabk2@revolver> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20230614011814.sz2l6z6wbaubabk2@revolver> X-Rspamd-Server: rspam08 X-Rspamd-Queue-Id: E4800120023 X-Stat-Signature: fw34rbmmpzayd8oypcm4spccony996as X-Rspam-User: X-HE-Tag: 1686747488-270 X-HE-Meta: U2FsdGVkX189V3Fwy9c9946UkVj/1BkMJ2hY963cGxt/lS7z300Fpa1b/WqseeAqOifCnNiRuaGeFhbB2txp5Ve4T07gO1EwPs3bAVVcACFM9ilohppjqAk8vGew3/LrSRCFIoqxTqB1zOYo5hVoObJYEoXNeGzclJ1MBmDuQhhMhdi4OTrLwju+XYV+KbETiUh/5uQ5KADGt0mr1by0tpHYk0OdtO6rrPRYJR9B9mpr6NcQKac3nQy3d1tG0vQp/3cfTjQiw6qPtymGN0gpPnpcvurYIImUVtDM4cT7PX0BglnZaWCNMpN2/Fwyg4DtSHSAG2yO2dO6hZQv6AhIAzSZ3dNiYqPkFXU/cCd2t87Vec0xe42ZOwF30zBfxIsSZhbNPV74eOajXAZUV9Gc6HCPIqlslZTV9gaNAUCRcYsvgE8tCGyNLM0ZM6kDI+sBmPUZhaf3yZdUwt6JRFGOmYODCYTEp+2piY0AV/aVxPsqDwKf79VcmRoyu6N+JqdO3g4ZWOS35IyGq8g3jNmiBjc+dT0DbMO4G1ou2Jt0/3d4NyzEniR2by934lgYavmnKHDrHBlSRlqXbL2Bm6nlvFQQ5nASzzg5rTvuDDgjDQJZLPYfyAuPW2FOjLHdT03CU9Ar3jz3/EvjdkMLqT7hw4LvscSXEQZfKGJjdfRqB9ar0kcGQEKE2FcSwcb0OvIVxeM5e90ZTniYIoommVEgLJ1AzbBJV47cgFGXz4IZfSrMsKD/myZbE+Ce6M/A9Lgq7I6wGisn1PlRA/eBmgh9TM1OlpXXW8plgP9SlGbNNhcxmTrN6kHG6IkfJS4gKv9nfx80bn6qHoHnZRUDlGi1jamhPQjfJoNj1XelbqcJFzPkhBOsUlOtOOEhv47q/Bqa6wQh9pK7URqQQxhkFO16rVX6VKM4ZrdzE+sXVwtXYMyb4Wf619uZZkcDGc6BKzJgDuVU0lFpJogEUtOwLXh SLZ5fBJP fANsHWqm6mdSccey4RFVfkLkzrC/da00mgoysRfzCtaEAl8rolrc5sJwZ5vyzlOa/W299ceEVCycovsoqxVoFvCuWjCEWgrsB4zXzslWqDfT1B8ASINWD6akJC3HRpcmVpZmzlOV6WfZ3fK8e7aQfDEMA7sT/flX9VCc5rDV6XmDmjljVmv1yQHUQslhkre718uG0/mk8q61RPrYUu3gUax0KSpUW1b7S+MLsCQfRNHWOIJ6+XRihJMZ/u68Y9JibvczEJGe4p7rWzZ7zvHI3BE2qMerPcU5cKtNVzyEAKf5OXxAfP7/4S97iBUqbZWNNOY/UuJ51w1BMhphp41amtkLx7F0unRQWIO+vYcItcfPo0aS0Zr5QCL7TXlDLaVlByi+shroocHr5gMZ4kfUJel9uuE/06VZ4MbEYEBDBrBgpQVM= 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 Tue, Jun 13, 2023 at 09:18:14PM -0400, Liam R. Howlett wrote: > * Jeff Xu [230613 17:29]: > > Hello Peter, > > > > Thanks for responding. > > > > On Tue, Jun 13, 2023 at 1:16 PM Peter Xu wrote: > > > > > > Hi, Jeff, > > > > > > On Tue, Jun 13, 2023 at 08:26:26AM -0700, Jeff Xu wrote: > > > > + more ppl to the list. > > > > > > > > On Mon, Jun 12, 2023 at 6:04 PM Jeff Xu wrote: > > > > > > > > > > Hello, > > > > > > > > > > There seems to be inconsistency in different VMA fixup > > > > > implementations, for example: > > > > > mlock_fixup will skip VMA that is hugettlb, etc, but those checks do > > > > > not exist in mprotect_fixup and madvise_update_vma. Wouldn't this be a > > > > > problem? the merge/split skipped by mlock_fixup, might get acted on in > > > > > the madvice/mprotect case. > > > > > > > > > > mlock_fixup currently check for > > > > > if (newflags == oldflags || > > newflags == oldflags, then we don't need to do anything here, it's > already at the desired mlock. mprotect does this, madvise does this.. > probably.. it's ugly. > > > > > > (oldflags & VM_SPECIAL) || > > It's special, merging will fail always. I don't know about splitting, > but I guess we don't want to alter the mlock state on special mappings. > > > > > > is_vm_hugetlb_page(vma) || vma == get_gate_vma(current->mm) || > > > > > vma_is_dax(vma) || vma_is_secretmem(vma)) > > > > > > The special handling you mentioned in mlock_fixup mostly makes sense to me. > > > > > > E.g., I think we can just ignore mlock a hugetlb page if it won't be > > > swapped anyway. > > > > > > Do you encounter any issue with above? > > > > > > > > Should there be a common function to handle VMA merge/split ? > > > > > > IMHO vma_merge() and split_vma() are the "common functions". Copy Lorenzo > > > as I think he has plan to look into the interface to make it even easier to > > > use. > > > > > The mprotect_fixup doesn't have the same check as mlock_fixup. When > > userspace calls mlock(), two VMAs might not merge or split because of > > vma_is_secretmem check, However, when user space calls mprotect() with > > the same address range, it will merge/split. If mlock() is doing the > > right thing to merge/split the VMAs, then mprotect() is not ? > > It looks like secretmem is mlock'ed to begin with so they don't want it > to be touched. So, I think they will be treated differently and I think > it is correct. Right, they don't :) secretmem VMAs are always mlocked, they cannot be munlocked and there is no point trying to mlock them again. The mprotect for secretmem is Ok though, so e.g. if we (unlikely) have two adjacent secretmem VMAs in a range passed to mprotect, it's fine to merge them. > Although, it would have been nice to have the comment above the function > kept up to date on why certain VMAs are filtered out. > > > > > Also skipping merge of VMA might be OK, but skipping split doesn't, > > wouldn't that cause inconsistent between vma->vm_flags and what is > > provisioned in the page ? > > I don't quite follow what you mean. It seems like the mlock_fixup() is > skipped when we don't want the flag to be altered on a particular VMA. > Where do they get out of sync? > > -- Sincerely yours, Mike.