[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <cc45475e-3d87-efa5-1c3a-c2c70d6aca94@loongson.cn>
Date: Sat, 3 Jun 2023 10:07:50 +0800
From: Youling Tang <tangyouling@...ngson.cn>
To: Tiezhu Yang <yangtiezhu@...ngson.cn>
Cc: Thomas Gleixner <tglx@...utronix.de>,
Huacai Chen <chenhuacai@...nel.org>,
WANG Xuerui <kernel@...0n.name>,
Christian Brauner <brauner@...nel.org>,
Andy Lutomirski <luto@...nel.org>,
Vincenzo Frascino <vincenzo.frascino@....com>,
loongarch@...ts.linux.dev, linux-kernel@...r.kernel.org,
loongson-kernel@...ts.loongnix.cn
Subject: Re: [PATCH v3] LoongArch: Add support to clone a time namespace
Hi, Tiezhu
On 05/31/2023 06:04 PM, Tiezhu Yang wrote:
>
>
> On 05/31/2023 05:21 PM, Thomas Gleixner wrote:
>> On Wed, May 31 2023 at 15:56, Tiezhu Yang wrote:
>>> 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().
>>
>> Which means that test case is broken.
>>
>>> With this patch, the following failed test can be fixed too:
>>
>> You cannot fix a broken test case by enabling functionality which
>> is not guaranteed to be available on all platforms.
>>
>> Adding time name spaces on loongarch is a completely separate issue and
>> has absolutely nothing to do with broken test cases.
>>
>> They are still broken when CONFIG_TIME_NS is disabled in Kconfig, no?
>>
>> So this wants to be two separate things:
>>
>> 1) Fix the broken test cases so they handle CONFIG_TIME_NS=n
>> situations correctly
>>
>> 2) Add support for TIME_NS to loongarch
>>
With this patch, we should also modify the stack_top() implementation,
because the vvar size is not PAGE_SIZE at this time.
'maps' before the patch,
# sudo cat /proc/1/maps
...
7ffffbec8000-7ffffbeec000 rw-p 00000000 00:00 0
[stack]
7ffffc7d8000-7ffffc7dc000 r--p 00000000 00:00 0
[vvar]
7ffffc7dc000-7ffffc7e0000 r-xp 00000000 00:00 0
[vdso]
STACK_TOP = TASK_SIZE - PAGE_ALIGN(current->thread.vdso->size) - VVAR_SIZE
Thanks,
Youling.
>
>
> Thanks for your reply and detailed suggestions,
> I will do it in the next version.
>
> Thanks,
> Tiezhu
>
Powered by blists - more mailing lists