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 X-Spam-Level: X-Spam-Status: No, score=-4.0 required=3.0 tests=BAYES_00,DKIM_ADSP_CUSTOM_MED, DKIM_SIGNED,DKIM_VALID,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, URIBL_BLOCKED autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id D5A41C433E1 for ; Thu, 23 Jul 2020 17:43:11 +0000 (UTC) Received: from merlin.infradead.org (merlin.infradead.org [205.233.59.134]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id A81C3207BB for ; Thu, 23 Jul 2020 17:43:11 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="XT2WRvPv"; dkim=fail reason="signature verification failed" (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="g8CE5vqb" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org A81C3207BB Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=gmail.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=merlin.20170209; h=Sender:Content-Transfer-Encoding: Content-Type:Cc:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References:Message-ID: Subject:To:From:Date:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=14s5bdAEtL2UaDNtzLY8e73TdIOzFRRBj3U84WKgeqc=; b=XT2WRvPvfSPPIWQXCTGppv90n HOdAkqWqksmZgL4AutqayfXKAU73msL3bqReSO1gLxicPuVIjENUdKvatijnTecGASXxOVV1p+OyF pGbeG0xShV5bwsx2E/Wuy1gy9vHR+novnTBWMQlV1bVIIap9KIjc43lEIcdl5bFUDPnUOrIjz9smz G27ookySO9xMONjSqjAXOq+k7m56Uq7Ccq8VYNPkb4BOWOlWR9a6M8XGJ/o4/5YnoFqAbcb3BBqFh wAd09pxnW2W5aU1+juTDJMzL6IIBCNTWrtCGvilWHYEGYu144XWZByEjrZ1c7Ejsq2i//T6d2sX9t fJUrVKc8A==; Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1jyfE5-00013s-R5; Thu, 23 Jul 2020 17:41:49 +0000 Received: from mail-pj1-x1044.google.com ([2607:f8b0:4864:20::1044]) by merlin.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1jyfE3-00012u-2y for linux-arm-kernel@lists.infradead.org; Thu, 23 Jul 2020 17:41:48 +0000 Received: by mail-pj1-x1044.google.com with SMTP id cv18so4594927pjb.1 for ; Thu, 23 Jul 2020 10:41:45 -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=+RJZw0EUjRyZGrBL+JOJ2S5jetRR1oKhR6Zvd1RgJh8=; b=g8CE5vqbzx8+q8gvwPCQVVlTu/4DoCklRjtBzfdi3iZDNiYEAw5sE9gpie8nmZ3+cP NCxicK2Ve2qHMNwrV7A3g5V8ZuBwUT1zGg6+a4OzxescH3EfZreFvywl4Nl2hLIFyiB7 tTbEk/HhGativgJefsiLNJXQW/tcS6QBJgFsKyAG22KPmh/GswkNrIZPHLVsBDOkocLq 9WkIlAdXcjlzDROyl+n+H+gmKyXruyfu4joQJ+GiprjYCXZ4t50jY/4qyvMkaj1z4gxl 9AviwBse/t1C7/1KG54XxoijhcC1AwFlI0QhTxITwqg7eFTO2hUY0EOpKtMFU8NvLvei aYPg== 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=+RJZw0EUjRyZGrBL+JOJ2S5jetRR1oKhR6Zvd1RgJh8=; b=McQvr1xiHQhZjKG3Vl4NiLzcXbuAWyaBIhc+FuytO10D+tyxpITCWogKMZMRWuTwKv c8Lo/uGBz+8urAVEREB692u0y4ZLZE/qkYIG/cvgD7s0OqakJYhNOS4jy6FTJnPwgVWe 61jVk59Rx5UqRt1YQ/njd+fMVevtVpybqMqmA768gvgBglk0TkFCYGyoNRjJO3np3cpm 7+CJuwDsS+r0YKHzJigAosxF/NU8fo+Gms64f5zXSVWu7+3HG9SVetSDvn1nGAEsKWJ0 n/LpVJb61zj8OuYJ5CWlIdE33eDgKX0cA0faazLRa84SWWqpJWtTXkIykBj2Fx89mi42 ieLA== X-Gm-Message-State: AOAM532QH4pV0DoJLG3cPqI/KPF5b2aaA4UzAvfF5qYTntOas56PvFG7 MgjZYPayEzCGbqhxI8gXQJo= X-Google-Smtp-Source: ABdhPJxoBkIy9VJSu6/9RLSZ5Nl/QUfE4CzVFNPVZsaPQiEv1+cvwyDb5XSdajla+/0XQPb2x8jfUg== X-Received: by 2002:a17:902:654e:: with SMTP id d14mr4913612pln.60.1595526103417; Thu, 23 Jul 2020 10:41:43 -0700 (PDT) Received: from gmail.com ([2601:600:9b7f:872e:a655:30fb:7373:c762]) by smtp.gmail.com with ESMTPSA id n25sm3757021pff.51.2020.07.23.10.41.42 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 23 Jul 2020 10:41:42 -0700 (PDT) Date: Thu, 23 Jul 2020 10:41:40 -0700 From: Andrei Vagin To: Catalin Marinas Subject: Re: [PATCH v5 0/6] arm64: add the time namespace support Message-ID: <20200723174140.GA3991167@gmail.com> References: <20200624083321.144975-1-avagin@gmail.com> <20200705064055.GA28894@gmail.com> <20200714015743.GA843937@gmail.com> <20200722181506.GA4517@gaia> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20200722181506.GA4517@gaia> X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20200723_134147_172090_72751491 X-CRM114-Status: GOOD ( 33.60 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Mark Rutland , Dmitry Safonov , linux-kernel@vger.kernel.org, Thomas Gleixner , Vincenzo Frascino , Will Deacon , Christian Brauner , linux-arm-kernel@lists.infradead.org Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Wed, Jul 22, 2020 at 07:15:06PM +0100, Catalin Marinas wrote: > On Mon, Jul 13, 2020 at 06:57:43PM -0700, Andrei Vagin wrote: > > On Sat, Jul 04, 2020 at 11:40:55PM -0700, Andrei Vagin wrote: > > > On Wed, Jun 24, 2020 at 01:33:15AM -0700, Andrei Vagin wrote: > > > > Allocate the time namespace page among VVAR pages and add the logic > > > > to handle faults on VVAR properly. > > > > > > > > If a task belongs to a time namespace then the VVAR page which contains > > > > the system wide VDSO data is replaced with a namespace specific page > > > > which has the same layout as the VVAR page. That page has vdso_data->seq > > > > set to 1 to enforce the slow path and vdso_data->clock_mode set to > > > > VCLOCK_TIMENS to enforce the time namespace handling path. > > > > > > > > The extra check in the case that vdso_data->seq is odd, e.g. a concurrent > > > > update of the VDSO data is in progress, is not really affecting regular > > > > tasks which are not part of a time namespace as the task is spin waiting > > > > for the update to finish and vdso_data->seq to become even again. > > > > > > > > If a time namespace task hits that code path, it invokes the corresponding > > > > time getter function which retrieves the real VVAR page, reads host time > > > > and then adds the offset for the requested clock which is stored in the > > > > special VVAR page. > > > > > > > > > > > v2: Code cleanups suggested by Vincenzo. > > > > v3: add a comment in __arch_get_timens_vdso_data. > > > > v4: - fix an issue reported by the lkp robot. > > > > - vvar has the same size with/without CONFIG_TIME_NAMESPACE, but the > > > > timens page isn't allocated on !CONFIG_TIME_NAMESPACE. This > > > > simplifies criu/vdso migration between different kernel configs. > > > > v5: - Code cleanups suggested by Mark Rutland. > > > > - In vdso_join_timens, mmap_write_lock is downgraded to > > > > mmap_read_lock. The VMA list isn't changed there, zap_page_range > > > > doesn't require mmap_write_lock. > > > > > > > > Reviewed-by: Vincenzo Frascino > > > > Reviewed-by: Dmitry Safonov > > > > > > Hello Will and Catalin, > > > > > > Have you had a chance to look at this patch set? I think it is ready to be > > > merged. Let me know if you have any questions. > > > > *friendly ping* > > > > If I am doing something wrong, let me know. > > Not really, just haven't got around to looking into it. Mark Rutland > raised a concern (in private) about the safety of multithreaded apps > but I think you already replied that timens_install() checks for this > already [1]. > > Maybe a similar atomicity issue to the one raised by Mark but for > single-threaded processes: the thread is executing vdso code, gets > interrupted and a signal handler invokes setns(). Would resuming the > execution in the vdso code on sigreturn cause any issues? It will not cause any issues in the kernel. In the userspace, clock_gettime() can return a clock value with an inconsistent offset, if a process switches between two non-root namespaces. And it can triggers SIGSEGV if it switches from a non-root to the root time namespace, because a time namespace isn't mapped in the root time namespace. I don't think that we need to handle this case in the kernel. Users must understand what they are doing and have to write code so that avoid these sort of situations. In general, I would say that in most cases it is a bad idea to call setns from a signal handler. Thanks, Andrei > > [1] https://lore.kernel.org/linux-arm-kernel/d16b5cd1-bdb1-5667-fbda-c622cc795389@arista.com/ > > -- > Catalin _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel