Received: by 2002:a05:6358:3188:b0:123:57c1:9b43 with SMTP id q8csp1569272rwd; Tue, 16 May 2023 20:34:38 -0700 (PDT) X-Google-Smtp-Source: ACHHUZ4xF3oySEfHCOBuKrhxhjowL3tjLIzny4wxnkzv0S59bK0x4VQhxwgbSZx9jRwYb9NdR0fH X-Received: by 2002:a17:902:b946:b0:1a9:9a18:3458 with SMTP id h6-20020a170902b94600b001a99a183458mr39642485pls.31.1684294477903; Tue, 16 May 2023 20:34:37 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1684294477; cv=none; d=google.com; s=arc-20160816; b=JlrAGSIZZyfPVMdS/1/GwzmXGYH9Fyi8Juvs3xNB6sYHYwXx6Kh8ruoaYgVY9fsaS2 zAAcqEETs4aMZRS5Xm1HJadL2xVa9PJetTdDP2HqSJYoWfUBKky85+Pjnt4uId6OMguT HZ1vAboRqmCGmIOVWFZNMsOnbMrbEmA6MwULU3qG/DbGo0ue4PGY7dVmyAeKXsN4u4d7 cZHXr16/AQcmOlyra+v2E7SJTcd3C0aQfkEKVXjH0nWS+kY26yXY0BKCz62nc/cuxDbM VYEkoa6WVdqhRld4/qTfAblWP1WrxsdFAWMBhWOqEZx6dXLCtBMD5GoACgbRnqMnRQRg r87A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:message-id:date:subject:cc:to:from; bh=cbHjEM0uvTOpmhD+T6iVZpjjfvxBZPHntccz3W8/AxA=; b=a97kIJkihFvHVcsEVYhrM64QMd3mbZJAXaIgQSK65wkUkxoxbaZ+zofQj72GPamX57 yZpVe3mxxwtvnDFcGRI+erG3XPhcNYDUp6W7t6JR6M5SCXAGgEm31joB1L+P25VG8Gmw HYGtP+anSZ0zSCzkHCPfovVqZSIK5mTpeyz/QR7fcFkd6NEKB9m8v7v5fb6SZLUcsfzQ yhzjfOvNoQu2l7sP3NMLPtWVMric5Gmx92U6haoNmij2Na05AzgjLX6/e+tyLAkElfvA PMGMoOCXSGKlh8vjbogadKunjmUYpnyIWGvQJR3CKFwKOpi52Ggdyr8VecRNUn6sPV95 KJdw== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id i1-20020a170902c94100b001ac47a1578asi21669199pla.232.2023.05.16.20.34.22; Tue, 16 May 2023 20:34:37 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232303AbjEQDEV (ORCPT + 99 others); Tue, 16 May 2023 23:04:21 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:42580 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232353AbjEQDDz (ORCPT ); Tue, 16 May 2023 23:03:55 -0400 Received: from loongson.cn (mail.loongson.cn [114.242.206.163]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id 68EE946B6 for ; Tue, 16 May 2023 20:03:10 -0700 (PDT) Received: from loongson.cn (unknown [113.200.148.30]) by gateway (Coremail) with SMTP id _____8Ax3ertQ2Rkr14JAA--.16416S3; Wed, 17 May 2023 11:03:09 +0800 (CST) Received: from linux.localdomain (unknown [113.200.148.30]) by localhost.localdomain (Coremail) with SMTP id AQAAf8Dx_8vrQ2RkyvNkAA--.41740S2; Wed, 17 May 2023 11:03:08 +0800 (CST) From: Tiezhu Yang To: Huacai Chen , WANG Xuerui , Christian Brauner , Andy Lutomirski , Thomas Gleixner , Vincenzo Frascino Cc: loongarch@lists.linux.dev, linux-kernel@vger.kernel.org, loongson-kernel@lists.loongnix.cn Subject: [PATCH] LoongArch: Add support to clone a time namespace Date: Wed, 17 May 2023 11:03:00 +0800 Message-Id: <1684292580-2455-1-git-send-email-yangtiezhu@loongson.cn> X-Mailer: git-send-email 2.1.0 X-CM-TRANSID: AQAAf8Dx_8vrQ2RkyvNkAA--.41740S2 X-CM-SenderInfo: p1dqw3xlh2x3gn0dqz5rrqw2lrqou0/ X-Coremail-Antispam: 1Uk129KBjvJXoWxGr1DJFWfCryxXr1UCr13twb_yoWrCF1rpF Z2krsrJw4UWryfKFWaq3sxurn8Grn7Ww42qF4I93yfAF1IgryDZr1vyrykZF45t3ykC34I gFWfWw4Y9F4UX3DanT9S1TB71UUUUjUqnTZGkaVYY2UrUUUUj1kv1TuYvTs0mT0YCTnIWj qI5I8CrVACY4xI64kE6c02F40Ex7xfYxn0WfASr-VFAUDa7-sFnT9fnUUIcSsGvfJTRUUU bS8YFVCjjxCrM7AC8VAFwI0_Jr0_Gr1l1xkIjI8I6I8E6xAIw20EY4v20xvaj40_Wr0E3s 1l1IIY67AEw4v_Jrv_JF1l8cAvFVAK0II2c7xJM28CjxkF64kEwVA0rcxSw2x7M28EF7xv wVC0I7IYx2IY67AKxVW8JVW5JwA2z4x0Y4vE2Ix0cI8IcVCY1x0267AKxVW8JVWxJwA2z4 x0Y4vEx4A2jsIE14v26r4UJVWxJr1l84ACjcxK6I8E87Iv6xkF7I0E14v26r4UJVWxJr1l n4kS14v26r1Y6r17M2AIxVAIcxkEcVAq07x20xvEncxIr21l57IF6xkI12xvs2x26I8E6x ACxx1l5I8CrVACY4xI64kE6c02F40Ex7xfMcIj6xIIjxv20xvE14v26r126r1DMcIj6I8E 87Iv67AKxVWUJVW8JwAm72CE4IkC6x0Yz7v_Jr0_Gr1lF7xvr2IYc2Ij64vIr41lc7CjxV Aaw2AFwI0_JF0_Jw1l42xK82IYc2Ij64vIr41l4I8I3I0E4IkC6x0Yz7v_Jr0_Gr1l4IxY O2xFxVAFwI0_Jrv_JF1lx2IqxVAqx4xG67AKxVWUJVWUGwC20s026x8GjcxK67AKxVWUGV WUWwC2zVAF1VAY17CE14v26r1q6r43MIIYrxkI7VAKI48JMIIF0xvE2Ix0cI8IcVAFwI0_ Jr0_JF4lIxAIcVC0I7IYx2IY6xkF7I0E14v26r1j6r4UMIIF0xvE42xK8VAvwI8IcIk0rV WUJVWUCwCI42IY6I8E87Iv67AKxVWUJVW8JwCI42IY6I8E87Iv6xkF7I0E14v26r1j6r4U YxBIdaVFxhVjvjDU0xZFpf9x07jOiSdUUUUU= X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,SPF_HELO_PASS, SPF_PASS,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org When execute the following command to test clone3 on LoongArch: # cd tools/testing/selftests/clone3 && make && ./clone3 we can see the following error info: # [5719] Trying clone3() with flags 0x80 (size 0) # Invalid argument - Failed to create new process # [5719] clone3() with flags says: -22 expected 0 not ok 18 [5719] Result (-22) is different than expected (0) This is because if CONFIG_TIME_NS is not set, but the flag CLONE_NEWTIME (0x80) is used to clone a time namespace, it will return -EINVAL in copy_time_ns(). Here is the related code in include/linux/time_namespace.h: #ifdef CONFIG_TIME_NS ... struct time_namespace *copy_time_ns(unsigned long flags, struct user_namespace *user_ns, struct time_namespace *old_ns); ... #else ... static inline struct time_namespace *copy_time_ns(unsigned long flags, struct user_namespace *user_ns, struct time_namespace *old_ns) { if (flags & CLONE_NEWTIME) return ERR_PTR(-EINVAL); return old_ns; } ... #endif Here is the complete call stack: clone3() kernel_clone() copy_process() copy_namespaces() create_new_namespaces() copy_time_ns() clone_time_ns() Because CONFIG_TIME_NS depends on GENERIC_VDSO_TIME_NS, select GENERIC_VDSO_TIME_NS to enable CONFIG_TIME_NS to build the real implementation of copy_time_ns() in kernel/time/namespace.c. Additionally, it needs to define some arch dependent functions such as __arch_get_timens_vdso_data(), arch_get_vdso_data() and vdso_join_timens(), then the failed test can be fixed. Signed-off-by: Tiezhu Yang --- This is based on 6.4-rc2 arch/loongarch/Kconfig | 1 + arch/loongarch/include/asm/vdso/gettimeofday.h | 7 ++++++ arch/loongarch/kernel/vdso.c | 32 ++++++++++++++++++++++++++ 3 files changed, 40 insertions(+) diff --git a/arch/loongarch/Kconfig b/arch/loongarch/Kconfig index d38b066..93b167f 100644 --- a/arch/loongarch/Kconfig +++ b/arch/loongarch/Kconfig @@ -80,6 +80,7 @@ config LOONGARCH select GENERIC_SCHED_CLOCK select GENERIC_SMP_IDLE_THREAD select GENERIC_TIME_VSYSCALL + select GENERIC_VDSO_TIME_NS select GPIOLIB select HAS_IOPORT select HAVE_ARCH_AUDITSYSCALL diff --git a/arch/loongarch/include/asm/vdso/gettimeofday.h b/arch/loongarch/include/asm/vdso/gettimeofday.h index 7b2cd37..1af88ac 100644 --- a/arch/loongarch/include/asm/vdso/gettimeofday.h +++ b/arch/loongarch/include/asm/vdso/gettimeofday.h @@ -94,6 +94,13 @@ static __always_inline const struct vdso_data *__arch_get_vdso_data(void) return get_vdso_data(); } +#ifdef CONFIG_TIME_NS +static __always_inline +const struct vdso_data *__arch_get_timens_vdso_data(const struct vdso_data *vd) +{ + return get_vdso_data() + PAGE_SIZE; +} +#endif #endif /* !__ASSEMBLY__ */ #endif /* __ASM_VDSO_GETTIMEOFDAY_H */ diff --git a/arch/loongarch/kernel/vdso.c b/arch/loongarch/kernel/vdso.c index eaebd2e..cf62103 100644 --- a/arch/loongarch/kernel/vdso.c +++ b/arch/loongarch/kernel/vdso.c @@ -14,6 +14,7 @@ #include #include #include +#include #include #include @@ -73,6 +74,37 @@ static int __init init_vdso(void) } subsys_initcall(init_vdso); +#ifdef CONFIG_TIME_NS +struct vdso_data *arch_get_vdso_data(void *vvar_page) +{ + return (struct vdso_data *)(vvar_page); +} + +/* + * 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; + + VMA_ITERATOR(vmi, mm, 0); + + mmap_read_lock(mm); + for_each_vma(vmi, vma) { + if (vma_is_special_mapping(vma, &vdso_info.data_mapping)) + zap_vma_pages(vma); + } + mmap_read_unlock(mm); + + return 0; +} +#endif + static unsigned long vdso_base(void) { unsigned long base = STACK_TOP; -- 2.1.0