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=-9.0 required=3.0 tests=DKIM_ADSP_CUSTOM_MED, DKIM_SIGNED,DKIM_VALID,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,MENTIONS_GIT_HOSTING, SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED,USER_AGENT_GIT autolearn=unavailable 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 0E58FC433E2 for ; Wed, 24 Jun 2020 08:35:26 +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 CC6B520899 for ; Wed, 24 Jun 2020 08:35:25 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="RZA/o4L+"; dkim=fail reason="signature verification failed" (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="HnUmvbVR" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org CC6B520899 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:MIME-Version:Cc:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:Message-Id:Date:Subject:To:From:Reply-To:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:In-Reply-To:References:List-Owner; bh=MCBcMJOwfOdZlJWjqkJO93nbe0vdnl3M2pN0/Gm8cuE=; b=RZA/o4L+L7IX7pZgNFCE5+nhHT smKtCP1MslVU6ojppKm6gHi6gIVnzYTLHuLQZdrpNA/oqMQZJ29VdMS9pIy5K5vWSIL0f9/GytsNv UUh2miWcWhTDO6NfiUWc5A+sTSuzZQHzCpbv09Fi0WQv9el4RBSD0iz3jEKqSszZFHjd7i/x9FOZx SX4qQPOqbLcG1w7zTm1PqabHaPBQ6YioXEwkANcPDdD6xyLvdRAoLW9xCg66970H4vyKwYnOtBWp7 nl4j2Y1npXZBVuH23/rxCe/LEubpSFsM92zjECmTSAfFKCoSD0zUUV3OfmCjf8K2v+1GapOthzDK1 qy5g8//Q==; Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1jo0qa-0008Gh-Qr; Wed, 24 Jun 2020 08:33:32 +0000 Received: from mail-pf1-x442.google.com ([2607:f8b0:4864:20::442]) by merlin.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1jo0qV-0008ES-Bq for linux-arm-kernel@lists.infradead.org; Wed, 24 Jun 2020 08:33:29 +0000 Received: by mail-pf1-x442.google.com with SMTP id f9so863970pfn.0 for ; Wed, 24 Jun 2020 01:33:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:subject:date:message-id; bh=3fO9Mu+HuWEWm+fvcMx22Y5exUaMbO9Z/LIyBW6OgqY=; b=HnUmvbVRCsgkvVykV2zyqGjs1Z1LBqIhrCu4OcR/Bijk7f1Oz5AvumKsTxNUb2JkWp pGntsl0IIa/v5KdzuCrstomRYRAtJBkW+qYubLlC7qO5EKYuNR5L7HKGFvyDpaK2bt0C XI9LpZJ+1tAsKEUQdDcBfstwe8D9wBUhsKKeWW6SsxcoNCh0GStCa1k3goNAsTp4boR1 VIZmK+vE6UUqziLYmu3DCF7AawwjR9PSnxlPnn4EGwO0MfKH1LyjJPLreeo8No7IizsJ dd/vSUr3oPTgQOjjtHHa4mm8rMCYqYGHaLfTBgBV/5xpxfUSbaIlnuSeBaBrCsICMFiI BtYQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id; bh=3fO9Mu+HuWEWm+fvcMx22Y5exUaMbO9Z/LIyBW6OgqY=; b=Goljp50lM+Fp0TgAF5x4LsSBBzUQiQM6zTPaj+XTDs+gbIpdPSCxARCi0Nmoq66E+9 0xmChIO7JIVx9awuPzCrkX45ol7g4BiR428wsLwAc2duF9/8tCQokSLOXBxLBxN8ngqa ioVwLPjT0xyoI6AUcL7Z7TioNl7aoNTisyVShhUsRR2sJZjyKwZ+pxGtWViytJTzehwC e9z/UGR6ilJwxhdMO1gvwlhUCsggOB3Z8+1spEgMRje/Y2FbWVZ7G7GUiyrnfj0u6QZa 8rY04BWVFmj04LV4RvPa3X2e9nHZhnaH7Oa6aQr3U5gHBmP6fb2XXl9JUubAB3FfWdu4 owWg== X-Gm-Message-State: AOAM530Dj/Itbh6EoSJjH1WohREw3iqNf1JJflMKGMzsfcB4A3spJQWt MbuVtV5CCPPM91i9pnguPZE= X-Google-Smtp-Source: ABdhPJx/c9g5gjqL+l6D+vxa9t+FUQFuiTBv0BGCgsREQX6XZXPfHJfjokjLMvL8f+xhERlq42GXzw== X-Received: by 2002:aa7:8b4b:: with SMTP id i11mr1127212pfd.123.1592987603594; Wed, 24 Jun 2020 01:33:23 -0700 (PDT) Received: from laptop.hsd1.wa.comcast.net ([2601:600:9b7f:872e:a655:30fb:7373:c762]) by smtp.gmail.com with ESMTPSA id g17sm4558614pju.11.2020.06.24.01.33.22 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 24 Jun 2020 01:33:22 -0700 (PDT) From: Andrei Vagin To: Catalin Marinas , Will Deacon , Mark Rutland Subject: [PATCH v5 0/6] arm64: add the time namespace support Date: Wed, 24 Jun 2020 01:33:15 -0700 Message-Id: <20200624083321.144975-1-avagin@gmail.com> X-Mailer: git-send-email 2.17.2 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: Dmitry Safonov , linux-kernel@vger.kernel.org, Andrei Vagin , Thomas Gleixner , Vincenzo Frascino , Christian Brauner , linux-arm-kernel@lists.infradead.org MIME-Version: 1.0 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 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 Cc: Thomas Gleixner Cc: Dmitry Safonov v5 on github (if someone prefers `git pull` to `git am`): https://github.com/avagin/linux-task-diag/tree/arm64/timens-v5 Andrei Vagin (6): arm64/vdso: use the fault callback to map vvar pages arm64/vdso: Zap vvar pages when switching to a time namespace arm64/vdso: Add time namespace page arm64/vdso: Handle faults on timens page arm64/vdso: Restrict splitting VVAR VMA arm64: enable time namespace support -- 2.24.1 _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel