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 69B4DC52D71 for ; Thu, 8 Aug 2024 18:36:59 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 046726B008A; Thu, 8 Aug 2024 14:36:59 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id F38AE6B008C; Thu, 8 Aug 2024 14:36:58 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id E00AC6B00A5; Thu, 8 Aug 2024 14:36:58 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0016.hostedemail.com [216.40.44.16]) by kanga.kvack.org (Postfix) with ESMTP id C1DEA6B008A for ; Thu, 8 Aug 2024 14:36:58 -0400 (EDT) Received: from smtpin24.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay03.hostedemail.com (Postfix) with ESMTP id 89E8AA1411 for ; Thu, 8 Aug 2024 18:36:58 +0000 (UTC) X-FDA: 82429934916.24.CFA6C4F Received: from mail-ed1-f45.google.com (mail-ed1-f45.google.com [209.85.208.45]) by imf04.hostedemail.com (Postfix) with ESMTP id C18CC40003 for ; Thu, 8 Aug 2024 18:36:56 +0000 (UTC) Authentication-Results: imf04.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=pjHFZaCo; spf=pass (imf04.hostedemail.com: domain of jeffxu@google.com designates 209.85.208.45 as permitted sender) smtp.mailfrom=jeffxu@google.com; dmarc=pass (policy=reject) header.from=google.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1723142152; 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=AUiHQdGUYRTRZksaVvFbHULoWNzG0269iJwVT5/7aW0=; b=dQEaPt+Fdf/v+t1ekgax0s9H3tuX78cYLwf2quMJHob8f8BNqkLyhVcx1QcTwthw5LL/Fs qLPF9OWW4MgyMY5UF/D7lje2jGcZYddS1oGrTcKuc15pr4enwdm6HwkZMYnBkJD7QqAUc4 U4scNeb9EC5Ttj4b1qV/pzYdf/CtUXs= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1723142152; a=rsa-sha256; cv=none; b=n5UEHn+dsY3ud8ToIiqFvOhKo7LUI9bFz0SLHp17SNuA5/YFgYqz2FtZYrxn3H6ZVvGZkX EynahLxyWVvuBJyB7P+H9JtZ+70JlZFcjjwCrFnart4hjqGAcaEIiT6VOXVFnXS1JyWKQ0 LXj6Sgv4d+1SxNehThFkdMnRGp3OQ5I= ARC-Authentication-Results: i=1; imf04.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=pjHFZaCo; spf=pass (imf04.hostedemail.com: domain of jeffxu@google.com designates 209.85.208.45 as permitted sender) smtp.mailfrom=jeffxu@google.com; dmarc=pass (policy=reject) header.from=google.com Received: by mail-ed1-f45.google.com with SMTP id 4fb4d7f45d1cf-5a1b073d7cdso471a12.0 for ; Thu, 08 Aug 2024 11:36:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1723142215; x=1723747015; 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=AUiHQdGUYRTRZksaVvFbHULoWNzG0269iJwVT5/7aW0=; b=pjHFZaCoV50VfbRRnoeEMX+Tqv1XLybZywypwz8EZJNlEIQPc/HNxvb0AS8AuYT/3S HMgjsV73f0Eh0XoyAV8vMi1YCDaxXQCzIeMzUK6h6u1COTpBCkI3O6A3W2usKBghUT/X xrHo5CYxlPsijFH3VY/xK+pAqLQ1VDSl7obYUW/NrIONpSYl1mDv0Buvrsj4QkfDpgq/ BSG7NYS0ECnFTkmdrbP4CK2fGFWARZK342+qghaMQxxMu/UKUQcDLYCRH4Qg1bpGEe5u 5guHcjxI5TXt0eajanyr+/by0CPvectuW5s4zR7gn8Jd9SQFdPvSc+fBiV/EcHKtiqvi j+OQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1723142215; x=1723747015; 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=AUiHQdGUYRTRZksaVvFbHULoWNzG0269iJwVT5/7aW0=; b=HVHAUgideG5ezTsvFa581u78Uw3iif9OygrN7quL9sXOAxLrOHyyGljvNvJXtrrSp4 xViO7tbNGLlQTEBzCknov5wESdNDDYze7NZ6kKnsBVBgZJ6uEVjo9rcxButhsX+XU1ep C72q4fdQaltlGqKWdS4JmiQBb3QoGdcK2nx5fl2qeTKSbYHfSl6nRhANu9UDfB0lW/2O +hyRxNYgcqyTGVKc8ng56/DKop8R90Vw2CpAfTYeodRKT4KUyV6h/6cxX5JJYDORx5Nf lAEClhtvuDhSO2kmip/4cCXTc1AYAKwLmxRotAKTu3wLxpddp8NwLZmwDwkT+vx2+mG0 PVTQ== X-Forwarded-Encrypted: i=1; AJvYcCUX2dCMe2hCoij3vdZY2dKQMkFJvpv0aaP0Q4uXXnoag49rP9AimGZefV+/hIidNks0OGUOEUJmX2TV0mEQudjBgjs= X-Gm-Message-State: AOJu0YxNIAy4FW9MQr99uEJoklcnsa3HRbNVW15D/2u6P/inVL/zrOv/ MJ6VdmC9gvTb2pNCHEH83G8dsKCuuPr6MpNYGGeN/tdBJB4LvqNEACUJe1lkbGmXoQl65VS4lHo BktteQggOaOef8VgO8QuYOvQQn8e2pBwEbk1ayJz5cvucRW/KSTNl X-Google-Smtp-Source: AGHT+IF76YCRlol+VaBff83BpYeNuFvu+aIiNuVvaKlOiVPlqg9lL9OA9dYb+7cLVxCzSEDJLygo9YoZhUgovQLCQ1E= X-Received: by 2002:a05:6402:27d4:b0:57d:436b:68d6 with SMTP id 4fb4d7f45d1cf-5bbbc8a8c0dmr16476a12.7.1723142214918; Thu, 08 Aug 2024 11:36:54 -0700 (PDT) MIME-Version: 1.0 References: <20240807124103.85644-1-mpe@ellerman.id.au> <20240807124103.85644-2-mpe@ellerman.id.au> <6i3f5bvcppm4bkpphcb7sxsopmeani5mg5irytc3nr464p24ka@jpno77j7cgyd> In-Reply-To: <6i3f5bvcppm4bkpphcb7sxsopmeani5mg5irytc3nr464p24ka@jpno77j7cgyd> From: Jeff Xu Date: Thu, 8 Aug 2024 11:36:16 -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: C18CC40003 X-Stat-Signature: pq3nm3iqq16pyhui53wj7btjjugd73sq X-Rspamd-Server: rspam09 X-Rspam-User: X-HE-Tag: 1723142216-491230 X-HE-Meta: U2FsdGVkX1/bZWce7bNSAzKTqjsN42IbtfAw9b1bu1yy4vQ6fGGacQ//OAEjOzmaA6NolhX+YsW3j3BQqeR/rItF9ONq9MAygG8fELLhns9GY9JPXgPl0tV1JvtmAnr0WtlI/qMFzzsBF+6MJoA8wwgo7tpHVxw+AQWSeKVJxMnj90wvR+ChxvGVpJDPQbmdxnUcOFfuZwB/UCLPhi07QltzeaKIbhl3aKnSkgGwjQsE4YbRqlilBfvqLtQEEoNs+jEt72kXnfh2Q08orxvCZn5KR23wLG3KVV91HHMmK+uJ407P9kARqO0g4NSTKNHhrUHYMuDe6SqCq8EBnw0S2H1xqENrDKOUvZEjMpR3n2yy9jx8UmDuYGguZdo8H4sG64L4ddV2QoxJNKgsfdfWd0YMQwlMRoHxI8j13Z3Ba60sqkl8wWbS8FwVXFISMHuqpTplhjXVrp4ZR+FlEP3iKlDqY9h6Xar8NXfuePzdGy0OK03T+b+V7+mNtBKAt8VLEthN+czlG0nHZqQ/yu9SlEJgP4PGMYSgO4EkGflHuZqIxVpuJeQPPl2cCwGjUc7w16k4J716/HfzMXupfa4ZZOylGcQOKdSioN/QxtT+KDKSDLjdQT9s64wtQkkMwwbKLDV2t5XJsY5DkV0nHTaa9v5HnjMkGjxH0KoaI4yv+OANTAQK26OgsP62ZBGXc8l67tzrF6MRk7RIhpjwUHSMrenwWv3eOosB2xw98fvCRXs4hKzqFLR+A3oV6h4nwGLC3oN16+nytnnWy0EUkRlzMGNJj4C0bU0LJfZ3Rh1D+eA6+1jkIZV8mQrDeQ7Rebde1qncpTl4X4bRV3Bo8nNY4YqVfrLGrf2CNBPCg+7QtU4Hddz8X89Ip4qXeP1g7/Xk40lQZUF/Pu0rUNJTMWh25wQfUvhFJ0da+CbSWTflGAXsMw3nEBnmGMBcCgmnpsfGLsWyv+Xqt+z6JncUOR3 WSojKQCw XZxF4yTtCeaf0pf4MQMUenRLmMhBJMHY5j4mvhobWJUM1Sa1hRDCCsK4kxNnTINIvJgvLiZduODUmzHGfH0Zqa+J3kPGCuGAYQN3iEkrh3gTmrg7U2CPML13iwZG45FjjiRfAU0mvmW3eLu2NOcN4gaVAnL+rXn8+GZDI2lZrfJGb2k32sz5Keopra05fPwy/cWpVAzV5I4KKjijS5AriKy547T7lRCiPtOLHtJKdIGrUwVTx6iha2KBut/naXZ0hQh4kJGLImZqXIWyObr2Uyu3wQnjQWPMMC+B9eklORFzKPe+a9t0IWahS/uYakRZoelN+/GOivjvRjZVsSV+9HRkN+MnxJeNcRwObO1Fo4sPiniYq7IKWxA8WMu4FoINGoQ8kxAgYtwOMhLQ= 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: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 h= ave a > > > > conf flag to leave the vdso pointer unchanged when it is unmapped. > > > > Having the close behind the conf option will not prevent it from be= ing > > > > unmapped or mapped over, so what you are suggesting is have a > > > > configuration option that leaves a pointer, mm->context.vdso, to 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 to ha= ndle > > unmap vdso safely, yes, this is a bugfix that should be applied everywh= ere > > for all arch, without CHECKPOINT_RESTORE config. > > > > Do we need to worry about mmap(fixed) ? which can have the same effect > > as mremap. > > Yes, but it should be handled by vm_ops->close() when MAP_FIXED unmaps > 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 ? Do we still need to keep vm_special_mapping struct , if we are going to treat special vma as normal vma ? > Thanks, > Liam