kvm.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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)

  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).