Received: by 2002:a05:6902:102b:0:0:0:0 with SMTP id x11csp1299282ybt; Thu, 25 Jun 2020 02:43:17 -0700 (PDT) X-Google-Smtp-Source: ABdhPJz1l3YrSXjMdEGWhc1+TjfQgNLvE/pOwsiuMTfRo1hLiEX4xr2XgY21wS/MUyfbR0RlArTE X-Received: by 2002:a17:907:72ca:: with SMTP id du10mr28451037ejc.78.1593078197569; Thu, 25 Jun 2020 02:43:17 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1593078197; cv=none; d=google.com; s=arc-20160816; b=qW3O7IJUqrJ+OKDk6d7hcg/bFOKNNhzn4npJx2ZdCfj43KbQGWVbFPAZXkzVNz991V 2XE5MfUSJL9Ptq+EaFx0HCPj92knPD6ibn2jllhRwLjkhcENRXRxTxa03Qh38AHbwm7p 6bMBb50oGXa954y/bwuwAOkmhsJOBw8W8QgH6Ytsm7EZZSKIGspLt4+KSwguby6MOTsj JsH032leWj7LmiAyGp/hX4j+cHKB/kYFaVebPvI3KHyd43AmQogVx/KlxyLCrknKg/MP tb4upm++I8hUHTgRh/Um2RvEAvSx95knSjxF3t/t0Xq0/Dy6eLcqu8UWSMvVxso1b6tT 7gKQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:in-reply-to:content-disposition :mime-version:references:message-id:subject:cc:to:from:date :dkim-signature; bh=8shbGUz09vnq5gNf7icF354v58ok08URPqfuPWDFRzQ=; b=YK5Pm9lYYb/WaeFf///QgBS5+Rm/d5IqkSW99Y0GGwdZRApsryTErbzoUWeNFr4gqA kmbTzAr/L7jKGi5XP/p0vfTUXEYY5fka2AHi3kys3WijLm6EjDJCJwaW56cZ8ljHdjik D1PcqgsuQvheFYgYbFYEZYxtNrnfDdtdJvgGtQs/6oHI+vpzfn7sksYQeMfoE3SWkxje FFKq+QI902dv5cEhRb/VhcLuvQMTbrdhNOOlXoRRA8aiZVaBLVk9ijoSRM5+0wFiEV1+ +5YawCspAMQzPzRv2/qgwYTw6BkbvWO3v6VlRmCO1CMSTF96pMM/alg+igrj7lVsvua1 SVSQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b="Rk2maCO/"; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id b12si9786847edq.471.2020.06.25.02.42.54; Thu, 25 Jun 2020 02:43:17 -0700 (PDT) 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; Authentication-Results: mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b="Rk2maCO/"; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2390510AbgFYIZo (ORCPT + 99 others); Thu, 25 Jun 2020 04:25:44 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:47078 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2389522AbgFYIZo (ORCPT ); Thu, 25 Jun 2020 04:25:44 -0400 Received: from mail-pl1-x642.google.com (mail-pl1-x642.google.com [IPv6:2607:f8b0:4864:20::642]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 58032C061573 for ; Thu, 25 Jun 2020 01:25:44 -0700 (PDT) Received: by mail-pl1-x642.google.com with SMTP id 35so2510165ple.0 for ; Thu, 25 Jun 2020 01:25:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=8shbGUz09vnq5gNf7icF354v58ok08URPqfuPWDFRzQ=; b=Rk2maCO/OrlFxHe6vAWk3QLXAgquWZmsSBnIxOP9FJ+AVXIQwa6pF04oh8jTQ7cVl/ 6lX97Y/0y7ushSZ4yOtSup4hfmM3DYEafqBuYWsGZFBh7mvBI4aC/80p0yqkTpKWBXx4 UjJfZt7bM8LR/4d4qRp5G5HalUZKUwaFnb/5dknQJd5OpgqxJBuckmzjf/PLfD7ggjlj ldOJFoVB1AUFL3IGwSROD6+2hXNJMClG3JOm08cFGZgfK8lu6SI6RS5mqbjr2dlxvmaT e+CXrqyjpgIdj0FEeEa53o/0POuPMmA5nzxDcS9LLa0NO4EupAvnbBEhTkN0Wypd7ASK QhFA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=8shbGUz09vnq5gNf7icF354v58ok08URPqfuPWDFRzQ=; b=l+JX9oFysr+hAtJmyntKJuRSlA5RK07kuRqhc6pAJf7P3cmQBvK9ST9NpNLcHLfTkn yQ/OCCf3Nc1x+YqpNP52UxiKZu0MIiRiQ9YlHH61LaXqnkj6PqtH6jcmWDgCKCnxu7DV FYRUYiSHpxkMc33/OcZCQ2jEavDjuBkaST6aDF6FXtCeN5kOCPLSVqht/TsjqhpQ/sl+ 1/FDralObfEqpEEDnuROGHG54Pt7W9kuyeDgnAjANzhmeFa7kvnIXQhcMaPo6h1wnsfA +yx8qTiqPZGkFX0OBPF4DqaxsNXKiBXTHHeom+XE8iDAD2m8heYWoxfQMF7l8DkhWXwG hOtw== X-Gm-Message-State: AOAM530hgkmq2qMKIJuuYUoMP0TV5Wlj2bhthgzxMskAUlBrVLcfuBvA tf9V74qOqkcVWZEKstuwcQg= X-Received: by 2002:a17:90a:a116:: with SMTP id s22mr2001065pjp.202.1593073543656; Thu, 25 Jun 2020 01:25:43 -0700 (PDT) Received: from gmail.com ([2601:600:9b7f:872e:a655:30fb:7373:c762]) by smtp.gmail.com with ESMTPSA id o20sm7359290pjw.19.2020.06.25.01.25.42 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 25 Jun 2020 01:25:43 -0700 (PDT) Date: Thu, 25 Jun 2020 01:25:41 -0700 From: Andrei Vagin To: Christian Brauner Cc: Catalin Marinas , Will Deacon , Mark Rutland , linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, Vincenzo Frascino , Thomas Gleixner , Dmitry Safonov Subject: Re: [PATCH 2/6] arm64/vdso: Zap vvar pages when switching to a time namespace Message-ID: <20200625082541.GA151695@gmail.com> References: <20200624083321.144975-1-avagin@gmail.com> <20200624083321.144975-3-avagin@gmail.com> <20200624151801.y27a5joml3mxeo4o@wittgenstein> MIME-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline In-Reply-To: <20200624151801.y27a5joml3mxeo4o@wittgenstein> Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Jun 24, 2020 at 05:18:01PM +0200, Christian Brauner wrote: > On Wed, Jun 24, 2020 at 01:33:17AM -0700, Andrei Vagin wrote: > > The order of vvar pages depends on whether a task belongs to the root > > time namespace or not. In the root time namespace, a task doesn't have a > > per-namespace page. In a non-root namespace, the VVAR page which contains > > the system-wide VDSO data is replaced with a namespace specific page > > that contains clock offsets. > > > > Whenever a task changes its namespace, the VVAR page tables are cleared > > and then they will be re-faulted with a corresponding layout. > > > > A task can switch its time namespace only if its ->mm isn't shared with > > another task. > > > > Reviewed-by: Vincenzo Frascino > > Reviewed-by: Dmitry Safonov > > Signed-off-by: Andrei Vagin > > --- > > arch/arm64/kernel/vdso.c | 31 +++++++++++++++++++++++++++++++ > > 1 file changed, 31 insertions(+) > > > > diff --git a/arch/arm64/kernel/vdso.c b/arch/arm64/kernel/vdso.c > > index 7c4620451fa5..bdf492a17dff 100644 > > --- a/arch/arm64/kernel/vdso.c > > +++ b/arch/arm64/kernel/vdso.c > > @@ -124,6 +124,37 @@ static int __vdso_init(enum vdso_abi abi) > > return 0; > > } > > > > +#ifdef CONFIG_TIME_NS > > +/* > > + * The vvar mapping contains data for a specific time namespace, so when a task > > + * changes namespace we must unmap its vvar data for the old namespace. > > + * Subsequent faults will map in data for the new namespace. > > + * > > + * For more details see timens_setup_vdso_data(). > > + */ > > +int vdso_join_timens(struct task_struct *task, struct time_namespace *ns) > > +{ > > + struct mm_struct *mm = task->mm; > > + struct vm_area_struct *vma; > > + > > + mmap_read_lock(mm); > > Perfect, thanks! I'll adapt my patches so that my change and this change > don't conflict and can go in together. Once they're landed we can simply > turn int vdso_join_timens() into void vdso_join_timens() everywhere. Yep. Let's do it this way. Thanks! > > Reviewed-by: Christian Brauner > > Thanks! > Christian