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 F343DC52D71 for ; Thu, 8 Aug 2024 18:52:49 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 88F746B0089; Thu, 8 Aug 2024 14:52:49 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 818B46B008A; Thu, 8 Aug 2024 14:52:49 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 692CB6B009C; Thu, 8 Aug 2024 14:52:49 -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 415BC6B0089 for ; Thu, 8 Aug 2024 14:52:49 -0400 (EDT) Received: from smtpin24.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay09.hostedemail.com (Postfix) with ESMTP id E18AF814FD for ; Thu, 8 Aug 2024 18:52:48 +0000 (UTC) X-FDA: 82429974816.24.7893418 Received: from mail-ed1-f45.google.com (mail-ed1-f45.google.com [209.85.208.45]) by imf02.hostedemail.com (Postfix) with ESMTP id 206E880020 for ; Thu, 8 Aug 2024 18:52:46 +0000 (UTC) Authentication-Results: imf02.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=mHbYDpwO; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf02.hostedemail.com: domain of jeffxu@google.com designates 209.85.208.45 as permitted sender) smtp.mailfrom=jeffxu@google.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1723143119; a=rsa-sha256; cv=none; b=YW80KQOhEiCfGVgofvmrpf8lvrO3dUExC8imrvZ73BjTNchDQJ6bUcNSsRL685Hz4ZJFeg rukUyi3i2t1d8TkMLvK7Is/f9oz9tiiigzBfD4HEBTMvvTTINO0kPpHdXUc9HPmEx3/gRp 5bQCftUMViGvLi0yOWyVyc5Ub88ReFs= ARC-Authentication-Results: i=1; imf02.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=mHbYDpwO; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf02.hostedemail.com: domain of jeffxu@google.com designates 209.85.208.45 as permitted sender) smtp.mailfrom=jeffxu@google.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1723143119; 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=DTr7QPxZOv6ZANTvHJnD7itspZcoPGqbySruN9g+g4c=; b=c00jrKQCcSH0Nh2mm88RG61VCEWampuD7uoZdknCTdFAbWEsDNXMMRr4iRhZjgVIzfPzfH Olm5EzzX9iaxlLvM9sd48g+d5tmJOSD4OGQqra9AHB0OdMSFOpp0+Ok9OP1YSCOkr9yTiQ rJvRXS/22vdgaD+Wq8hREtYPqfW/laU= Received: by mail-ed1-f45.google.com with SMTP id 4fb4d7f45d1cf-5a1b073d7cdso783a12.0 for ; Thu, 08 Aug 2024 11:52:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1723143165; x=1723747965; darn=kvack.org; h=content-transfer-encoding:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=DTr7QPxZOv6ZANTvHJnD7itspZcoPGqbySruN9g+g4c=; b=mHbYDpwOLx+H0SIWNWpM4GqxZa1ONY1l8uy6lTRdRh0OGZ4k8aOuo63peNm+62MJ8/ iS/N7EAHnF5b9QwXjI7Hl9PRBtaP7HgjSQkd2XlG7pAWDdAIO4v78NlUEJ7g7yYSZWKu E/psAZazKyNJS1Q2anVV5MN/YNLuw4YdCJbtU8KwxmkdeHutXBxyHMachtzQI+O+zj8X tPcA2bMtMoEYF7UGF518U+jDYD7V591cOHaYviiBcZfdNYJ/7DmkuNp+pCc9lXyiaMQR KaTT69+aoQ96ArYk/uRg+FsSidC8awLyPoO4kkImy3fJJJsukK/Tl+fnbPhME2pP4sDo R4NQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1723143165; x=1723747965; h=content-transfer-encoding:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=DTr7QPxZOv6ZANTvHJnD7itspZcoPGqbySruN9g+g4c=; b=C4xcjWcMDDFLRAVubNOUHiOr5TctjKvybO+q5d1qNSMoisMmhgvIjU4kd/m5F+5JzT 9wSDeb+HnVE94KBr/KwMB6hvqYeYVxhLGRrBsmlHm77IDFcVi0mHQYmbpFkb7C0ALseJ UWLf40ps4o7g25couU+zGTkzNxzPuW/ygBhzFVqTmLthnURu/fL6VvmFzorIwbrxpqWj mMl6G9c/G5tODQVoYNiqzmlSwvAMZS6pNGCY8peTmvIJJHxZYauUYimXZG9n1PYiR6jR Z2zbiwRFrYD1+g6yDz8qYBPQ07j7DSd+8w31upErkIzFE1aRUozx2CaM/Aft0kp/0HRF RdMg== X-Forwarded-Encrypted: i=1; AJvYcCVQxnnv+iA5xziztTa+i+F7C4d3/b4CY4cHAFI6PoxdS4fDT9+28IFUXvnmcI4oUP1An58pxtgGWqnHSIdPnGwprpY= X-Gm-Message-State: AOJu0Yzy9KBecfmHcxCs8x7g6002KC2yqmbKN5EqLr9Ds9/0jiZyUORS zqBb0cggIe8kqKEM7oi2vFR9oq6Z8pwgPjY2/HWbTDdXl0AMJLSrqz26lHP86WU2U2lDS78MOYl ADi4JwIkJqXE7Ot6lxVpzXECJzpCZQ52Lge9Y X-Google-Smtp-Source: AGHT+IFCgJzX0rsSfextMUWKoTY+8ON0bM39EuVj+wqU5VsofAbRLMRUfcqJbeBCecOmrdKT/V+64+NhNCnphbPoezs= X-Received: by 2002:a05:6402:268f:b0:58b:93:b624 with SMTP id 4fb4d7f45d1cf-5bbbc7c62c2mr22073a12.1.1723143165252; Thu, 08 Aug 2024 11:52:45 -0700 (PDT) MIME-Version: 1.0 References: <6i3f5bvcppm4bkpphcb7sxsopmeani5mg5irytc3nr464p24ka@jpno77j7cgyd> In-Reply-To: From: Jeff Xu Date: Thu, 8 Aug 2024 11:52:07 -0700 Message-ID: Subject: Re: [PATCH 2/4] powerpc/mm: Handle VDSO unmapping via close() rather than arch_unmap() To: "Liam R. Howlett" , Jeff Xu , Linus Torvalds , Michael Ellerman , linux-mm@kvack.org, linuxppc-dev@lists.ozlabs.org, akpm@linux-foundation.org, christophe.leroy@csgroup.eu, jeffxu@chromium.org, linux-kernel@vger.kernel.org, npiggin@gmail.com, oliver.sang@intel.com, pedro.falcato@gmail.com, Kees Cook Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: 206E880020 X-Rspam-User: X-Rspamd-Server: rspam05 X-Stat-Signature: 1m5w84qu45budhdu9ske9zbimdwxgkfh X-HE-Tag: 1723143166-685362 X-HE-Meta: U2FsdGVkX1/1UTlc/NsqWdWgYo08rjhcvVTpPAN7zUWHtwxEf4SPvJ3iCgL03plzOaS2itHS6P/aJpF96l2PrPCM/3216nfJvgT+tszJDYEqeWcU9CSOqT/l9TLRVkiApfikGmCAhOskyu9gguqJeoA1ohMX5CgnmYuQvTb91LH8g7MRnYZzX1elLmaYdooj7D+lSVLvstPolTMh9qGh3ZtL41JcY1uqYdg4QCfEkpOpUe0FVuHi2/P2RoKye0Czm7AtPQ2RSddxzcsBuXXYLrE99RSJdBmnDKLwCrI3TlVlCh+QAzeR3JIi5PYfT3az+M3M9ym987RBYD5vdryDlcn+HULN0V4ktiO1xqnc9z342xpAVppYujC6uoXrWmo5LJ8uM13grmLHoSn94/7B2HUGOREBGib5PdTvVgSqYqvRq4kYYzsiq1AsYVlbHgjt4Ar/xIBaERmza5z8CR3Zsylqr/eNHuBKZDQngBCuEHWhg+KMCBjBbZ48Tsn98oCX1ZXC1GPC6nYwNrwPq5LWaBjTLy+oZ+2VLqstJNZIeQ5fd7NEMRKH4tdupHyg7AikNtwPyM7URQ6vCeCgAVCrtBq7benps44pmYZSWLotxy8gVuQ/27Ag8k9lGVkqsxxnpkbPhORROWPDSrOH9bVY1GXjL3+0Omx663EFOY1wfxxq+PeVwdx24uSJDqP/2ffQJTySGOHCMOr5dtdTbcxJBoE6dn8cxB6UEP/nvccOj/XTYC1Se3c7Ekumjf+lcXu/DYIksGrc8GsIIQF9eh5C677dx7bQMtebR+rTt6EcsXbSRxHiW0cruq8mOXg2dj0F8pxZ0M9ohR5aB+YLEsBh+oW7KpzsRGwIcUZAQzQMc7+QjADlxfuDNAbNYlqxCc6tBrVGqECUg+f6Hkb341WJdDjUPfLxA2fyiabH1ofB5fAdUSWZ43EvzTOITnGx4Ced7+SeXRKxSkW+qw2he9C BpPMFU2Y 4xwruvqrmExDJdxIv/K35DToNFuRlBigBUxPrrYauanEk6dhrpqapZqUrCe8X6RW8G1thd6eFjb8+DbOHu2zztbBnMnBWvDFcxWsXAOaZRaDMfcoWETJRcd0is+UmbHeE4nGAx0LGMWiMSqRb9aDwN047oUTComO5QD0ppIW8g6zRl7VzQf/UAX57wlbrWqqtYjLd5ThW7Izttrq5SQTR1PuttN6lHo33psV2MekLldVg+H8EcInTC/3EMLEiJnKYP1yQ+F9pNb6MV/ReW54zzpWcuAEisDutWnPf3Hc4W1UuWAfr5TjwP1COTbeF1P7WfPlGt2DcTDtk0ZDT2Y5S+YUC+moBTfRNmolTIk212PPwQhHZbP6WLqNntBloEBjvtUiLINif5PI53VA= 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: List-Subscribe: List-Unsubscribe: On Thu, Aug 8, 2024 at 11:46=E2=80=AFAM Liam R. Howlett wrote: > > * Jeff Xu [240808 14:37]: > > On Thu, Aug 8, 2024 at 11:08=E2=80=AFAM Liam R. Howlett wrote: > > > > > > * Jeff Xu [240807 23:37]: > > > > On Wed, Aug 7, 2024 at 8:21=E2=80=AFPM Linus Torvalds > > > > wrote: > > > > > > > > > > On Wed, 7 Aug 2024 at 16:20, Liam R. Howlett wrote: > > > > > > > > > > > > Okay, I'm going to try one more time here. You are suggesting = to have a > > > > > > conf flag to leave the vdso pointer unchanged when it is unmapp= ed. > > > > > > Having the close behind the conf option will not prevent it fro= m being > > > > > > unmapped or mapped over, so what you are suggesting is have a > > > > > > configuration option that leaves a pointer, mm->context.vdso, t= o be > > > > > > unsafe if it is unmapped if you disable checkpoint restore. > > > > > > > > > This is a new point that I didn't realize before, if we are going t= o handle > > > > unmap vdso safely, yes, this is a bugfix that should be applied eve= rywhere > > > > for all arch, without CHECKPOINT_RESTORE config. > > > > > > > > Do we need to worry about mmap(fixed) ? which can have the same eff= ect > > > > as mremap. > > > > > > Yes, but it should be handled by vm_ops->close() when MAP_FIXED unmap= s > > > the vdso. Note that you cannot MAP_FIXED over half of the vma as the > > > vm_ops->may_split() is special_mapping_split(), which just returns > > > -EINVAL. > > > > > The may_split() failure logic is specific to vm_special_mapping, right = ? > > Not really, it's just what exists for these vmas vm_ops struct. It's > called on every vma for every split in __split_vma(). > > > > > Do we still need to keep vm_special_mapping struct , if we are going to > > treat special vma as normal vma ? > > No, just set the vm_ops may_split to something that returns -EINVAL. > OK, that makes sense. Thanks