All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andrew Jones <drjones@redhat.com>
To: Nikos Nikoleris <nikos.nikoleris@arm.com>
Cc: Alexandru Elisei <alexandru.elisei@arm.com>, kvm@vger.kernel.org
Subject: Re: [kvm-unit-tests PATCH 3/4] arm/arm64: Track whether thread_info has been initialized
Date: Mon, 22 Mar 2021 13:11:26 +0100	[thread overview]
Message-ID: <20210322121126.l4whxdz5kylmf77q@kamzik.brq.redhat.com> (raw)
In-Reply-To: <80c2632b-4a04-f9b0-9ff9-8403ca1e9451@arm.com>

On Mon, Mar 22, 2021 at 10:59:31AM +0000, Nikos Nikoleris wrote:
> 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 just sent a patch doing this. Let me know what you think.


> I was thinking of adding a
> thread_info_alloc() function to do this.

I'm not sure how this would look. We want the thread-info to live on the
bottom of the stack and the bootcpu's stack is allocated in the linker
script.

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

Hmm, yeah, hopefully we can avoid this flag and adding an assert to
smp_processor_id(). Let's take another look at this after we ensure
that the thread-info is explicitly zeroed at startup.

Thanks,
drew


  reply	other threads:[~2021-03-22 12:12 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
2021-03-22 12:11       ` Andrew Jones [this message]
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=20210322121126.l4whxdz5kylmf77q@kamzik.brq.redhat.com \
    --to=drjones@redhat.com \
    --cc=alexandru.elisei@arm.com \
    --cc=kvm@vger.kernel.org \
    --cc=nikos.nikoleris@arm.com \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.