From: Nikos Nikoleris <nikos.nikoleris@arm.com>
To: Alexandru Elisei <alexandru.elisei@arm.com>, kvm@vger.kernel.org
Cc: drjones@redhat.com
Subject: Re: [kvm-unit-tests PATCH 3/4] arm/arm64: Track whether thread_info has been initialized
Date: Mon, 22 Mar 2021 10:59:31 +0000 [thread overview]
Message-ID: <80c2632b-4a04-f9b0-9ff9-8403ca1e9451@arm.com> (raw)
In-Reply-To: <9325d09d-aa0b-0715-f013-8926de3673cb@arm.com>
Hi Alex,
On 22/03/2021 10:34, Alexandru Elisei wrote:
> Hi Nikos,
>
> On 3/19/21 12:24 PM, Nikos Nikoleris wrote:
>> Introduce a new flag in the thread_info to track whether a thread_info
>> struct is initialized yet or not.
>
> There's no explanation why this is needed. The flag checked only by is_user(), and
> before thread_info is initialized, flags is zero, so is_user() would return false,
> right? Or am I missing something?
>
I am still not sure what's the right approach here. I didn't like and I
still don't like the fact that we rely on implicit 0 initialization to
get the right behavior. This will break once we add support for EFI. I
think we should explicitly initialize thread_info to 0. I was thinking
of adding a thread_info_alloc() function to do this.
By having this flag I think we can guard accesses to the thread_info in
general. I didn't want to turn the define smp_processor_id to a function
here but I think we should and assert that the thread_info is valid and
avoid reading current_thread_info()->cpu.
Having said that, this would still work without the patch and I am happy
to drop it if the above doesn't makes sense.
Thanks,
Nikos
> Thanks,
>
> Alex
>
>>
>> Signed-off-by: Nikos Nikoleris <nikos.nikoleris@arm.com>
>> ---
>> lib/arm/asm/thread_info.h | 1 +
>> lib/arm/processor.c | 5 +++--
>> lib/arm64/processor.c | 5 +++--
>> 3 files changed, 7 insertions(+), 4 deletions(-)
>>
>> diff --git a/lib/arm/asm/thread_info.h b/lib/arm/asm/thread_info.h
>> index eaa7258..926c2a3 100644
>> --- a/lib/arm/asm/thread_info.h
>> +++ b/lib/arm/asm/thread_info.h
>> @@ -45,6 +45,7 @@ static inline void *thread_stack_alloc(void)
>> }
>>
>> #define TIF_USER_MODE (1U << 0)
>> +#define TIF_VALID (1U << 1)
>>
>> struct thread_info {
>> int cpu;
>> diff --git a/lib/arm/processor.c b/lib/arm/processor.c
>> index a2d39a4..702fbc3 100644
>> --- a/lib/arm/processor.c
>> +++ b/lib/arm/processor.c
>> @@ -119,7 +119,7 @@ void thread_info_init(struct thread_info *ti, unsigned int flags)
>> {
>> memset(ti, 0, sizeof(struct thread_info));
>> ti->cpu = mpidr_to_cpu(get_mpidr());
>> - ti->flags = flags;
>> + ti->flags = flags | TIF_VALID;
>> }
>>
>> void start_usr(void (*func)(void *arg), void *arg, unsigned long sp_usr)
>> @@ -143,7 +143,8 @@ void start_usr(void (*func)(void *arg), void *arg, unsigned long sp_usr)
>>
>> bool is_user(void)
>> {
>> - return current_thread_info()->flags & TIF_USER_MODE;
>> + struct thread_info *ti = current_thread_info();
>> + return (ti->flags & TIF_VALID) && (ti->flags & TIF_USER_MODE);
>> }
>>
>> bool __mmu_enabled(void)
>> diff --git a/lib/arm64/processor.c b/lib/arm64/processor.c
>> index ef55862..231d71e 100644
>> --- a/lib/arm64/processor.c
>> +++ b/lib/arm64/processor.c
>> @@ -227,7 +227,7 @@ static void __thread_info_init(struct thread_info *ti, unsigned int flags)
>> {
>> memset(ti, 0, sizeof(struct thread_info));
>> ti->cpu = mpidr_to_cpu(get_mpidr());
>> - ti->flags = flags;
>> + ti->flags = flags | TIF_VALID;
>> }
>>
>> void thread_info_init(struct thread_info *ti, unsigned int flags)
>> @@ -255,7 +255,8 @@ void start_usr(void (*func)(void *arg), void *arg, unsigned long sp_usr)
>>
>> bool is_user(void)
>> {
>> - return current_thread_info()->flags & TIF_USER_MODE;
>> + struct thread_info *ti = current_thread_info();
>> + return (ti->flags & TIF_VALID) && (ti->flags & TIF_USER_MODE);
>> }
>>
>> bool __mmu_enabled(void)
next prev parent reply other threads:[~2021-03-22 11:00 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-03-19 12:24 [kvm-unit-tests PATCH 0/4] RFC: Minor arm/arm64 MMU fixes and checks Nikos Nikoleris
2021-03-19 12:24 ` [kvm-unit-tests PATCH 1/4] arm/arm64: Avoid calling cpumask_test_cpu for CPUs above nr_cpu Nikos Nikoleris
2021-03-22 9:31 ` Andrew Jones
2021-03-22 9:45 ` Nikos Nikoleris
2021-03-22 10:12 ` Andrew Jones
2021-03-22 10:40 ` Nikos Nikoleris
2021-03-22 10:53 ` Andrew Jones
2021-03-19 12:24 ` [kvm-unit-tests PATCH 2/4] arm/arm64: Read system registers to get the state of the MMU Nikos Nikoleris
2021-03-22 10:30 ` Alexandru Elisei
2021-03-22 11:14 ` Nikos Nikoleris
2021-03-22 15:25 ` Alexandru Elisei
2021-03-19 12:24 ` [kvm-unit-tests PATCH 3/4] arm/arm64: Track whether thread_info has been initialized Nikos Nikoleris
2021-03-22 10:34 ` Alexandru Elisei
2021-03-22 10:59 ` Nikos Nikoleris [this message]
2021-03-22 12:11 ` Andrew Jones
2021-03-19 12:24 ` [kvm-unit-tests PATCH 4/4] arm/arm64: Add sanity checks to the cpumask API Nikos Nikoleris
2021-03-23 11:24 ` [kvm-unit-tests PATCH 0/4] RFC: Minor arm/arm64 MMU fixes and checks Andrew Jones
2021-03-23 11:40 ` Alexandru Elisei
2021-03-23 11:51 ` Andrew Jones
2021-03-23 12:15 ` Nikos Nikoleris
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=80c2632b-4a04-f9b0-9ff9-8403ca1e9451@arm.com \
--to=nikos.nikoleris@arm.com \
--cc=alexandru.elisei@arm.com \
--cc=drjones@redhat.com \
--cc=kvm@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).