From: Catalin Marinas <catalin.marinas@arm.com>
To: Peter Zijlstra <peterz@infradead.org>
Cc: Morten Rasmussen <morten.rasmussen@arm.com>,
Qais Yousef <qais.yousef@arm.com>,
linux-arch@vger.kernel.org, Marc Zyngier <maz@kernel.org>,
Will Deacon <will@kernel.org>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
Linus Torvalds <torvalds@linux-foundation.org>,
linux-arm-kernel@lists.infradead.org
Subject: Re: [RFC PATCH 3/3] arm64: Handle AArch32 tasks running on non AArch32 cpu
Date: Fri, 9 Oct 2020 10:51:12 +0100 [thread overview]
Message-ID: <20201009095112.GE23638@gaia> (raw)
In-Reply-To: <20201009092559.GE2628@hirez.programming.kicks-ass.net>
On Fri, Oct 09, 2020 at 11:25:59AM +0200, Peter Zijlstra wrote:
> On Fri, Oct 09, 2020 at 10:13:12AM +0200, Morten Rasmussen wrote:
> > On Fri, Oct 09, 2020 at 09:29:43AM +0200, Peter Zijlstra wrote:
>
> > > Fundamentally, you're not supposed to change the userspace provided
> > > affinity mask. If we want to do something like this, we'll have to teach
> > > the scheduler about this second mask such that it can compute an
> > > effective mask as the intersection between the 'feature' and user mask.
> >
> > I agree that we shouldn't mess wit the user-space mask directly. Would it
> > be unthinkable to go down the route of maintaining a new mask which is
> > the intersection of the feature mask (controlled and updated by arch
> > code) and the user-space mask?
> >
> > It shouldn't add overhead in the scheduler as it would use the
> > intersection mask instead of the user-space mask, the main complexity
> > would be around making sure the intersection mask is updated correctly
> > (cpusets, hotplug, ...).
>
> IFF we _need_ to go there, then yes that was the plan, compose the
> intersection when either the (arch) feature(set) mask or the userspace
> mask changes.
Another thought: should the arm64 compat_elf_check_arch() and
sys_arm64_personality(PER_LINUX32) validate the user cpumask before
returning success/failure? It won't prevent the user from changing the
affinity at run-time but at least it won't randomly get killed just
because the kernel advertises 32-bit support.
--
Catalin
WARNING: multiple messages have this Message-ID (diff)
From: Catalin Marinas <catalin.marinas@arm.com>
To: Peter Zijlstra <peterz@infradead.org>
Cc: linux-arch@vger.kernel.org, Marc Zyngier <maz@kernel.org>,
Qais Yousef <qais.yousef@arm.com>,
Linus Torvalds <torvalds@linux-foundation.org>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
Will Deacon <will@kernel.org>,
Morten Rasmussen <morten.rasmussen@arm.com>,
linux-arm-kernel@lists.infradead.org
Subject: Re: [RFC PATCH 3/3] arm64: Handle AArch32 tasks running on non AArch32 cpu
Date: Fri, 9 Oct 2020 10:51:12 +0100 [thread overview]
Message-ID: <20201009095112.GE23638@gaia> (raw)
In-Reply-To: <20201009092559.GE2628@hirez.programming.kicks-ass.net>
On Fri, Oct 09, 2020 at 11:25:59AM +0200, Peter Zijlstra wrote:
> On Fri, Oct 09, 2020 at 10:13:12AM +0200, Morten Rasmussen wrote:
> > On Fri, Oct 09, 2020 at 09:29:43AM +0200, Peter Zijlstra wrote:
>
> > > Fundamentally, you're not supposed to change the userspace provided
> > > affinity mask. If we want to do something like this, we'll have to teach
> > > the scheduler about this second mask such that it can compute an
> > > effective mask as the intersection between the 'feature' and user mask.
> >
> > I agree that we shouldn't mess wit the user-space mask directly. Would it
> > be unthinkable to go down the route of maintaining a new mask which is
> > the intersection of the feature mask (controlled and updated by arch
> > code) and the user-space mask?
> >
> > It shouldn't add overhead in the scheduler as it would use the
> > intersection mask instead of the user-space mask, the main complexity
> > would be around making sure the intersection mask is updated correctly
> > (cpusets, hotplug, ...).
>
> IFF we _need_ to go there, then yes that was the plan, compose the
> intersection when either the (arch) feature(set) mask or the userspace
> mask changes.
Another thought: should the arm64 compat_elf_check_arch() and
sys_arm64_personality(PER_LINUX32) validate the user cpumask before
returning success/failure? It won't prevent the user from changing the
affinity at run-time but at least it won't randomly get killed just
because the kernel advertises 32-bit support.
--
Catalin
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2020-10-09 9:51 UTC|newest]
Thread overview: 66+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-10-08 18:16 [RFC PATCH 0/3] Add support for Asymmetric AArch32 systems Qais Yousef
2020-10-08 18:16 ` Qais Yousef
2020-10-08 18:16 ` [RFC PATCH 1/3] arm64: kvm: Handle " Qais Yousef
2020-10-08 18:16 ` Qais Yousef
2020-10-09 8:12 ` Marc Zyngier
2020-10-09 8:12 ` Marc Zyngier
2020-10-09 9:58 ` Qais Yousef
2020-10-09 9:58 ` Qais Yousef
2020-10-09 12:34 ` Marc Zyngier
2020-10-09 12:34 ` Marc Zyngier
2020-10-09 12:48 ` Qais Yousef
2020-10-09 12:48 ` Qais Yousef
2020-10-12 15:32 ` James Morse
2020-10-12 15:32 ` James Morse
2020-10-13 10:32 ` Marc Zyngier
2020-10-13 10:32 ` Marc Zyngier
2020-10-13 11:51 ` James Morse
2020-10-13 11:51 ` James Morse
2020-10-13 11:59 ` Qais Yousef
2020-10-13 11:59 ` Qais Yousef
2020-10-13 12:09 ` Marc Zyngier
2020-10-13 12:09 ` Marc Zyngier
2020-10-13 12:16 ` Qais Yousef
2020-10-13 12:16 ` Qais Yousef
2020-10-08 18:16 ` [RFC PATCH 2/3] arm64: Add support for asymmetric AArch32 EL0 configurations Qais Yousef
2020-10-08 18:16 ` Qais Yousef
2020-10-08 18:22 ` Randy Dunlap
2020-10-08 18:22 ` Randy Dunlap
2020-10-12 10:22 ` Qais Yousef
2020-10-12 10:22 ` Qais Yousef
2020-10-09 6:13 ` Greg Kroah-Hartman
2020-10-09 6:13 ` Greg Kroah-Hartman
2020-10-09 8:40 ` Will Deacon
2020-10-09 8:40 ` Will Deacon
2020-10-09 8:50 ` Catalin Marinas
2020-10-09 8:50 ` Catalin Marinas
2020-10-09 9:39 ` Catalin Marinas
2020-10-09 9:39 ` Catalin Marinas
2020-10-12 12:46 ` Qais Yousef
2020-10-12 12:46 ` Qais Yousef
2020-10-08 18:16 ` [RFC PATCH 3/3] arm64: Handle AArch32 tasks running on non AArch32 cpu Qais Yousef
2020-10-08 18:16 ` Qais Yousef
2020-10-09 7:29 ` Peter Zijlstra
2020-10-09 7:29 ` Peter Zijlstra
2020-10-09 8:13 ` Morten Rasmussen
2020-10-09 8:13 ` Morten Rasmussen
2020-10-09 8:31 ` Will Deacon
2020-10-09 8:31 ` Will Deacon
2020-10-09 8:50 ` Morten Rasmussen
2020-10-09 8:50 ` Morten Rasmussen
2020-10-09 9:33 ` Catalin Marinas
2020-10-09 9:33 ` Catalin Marinas
2020-10-09 9:42 ` Greg Kroah-Hartman
2020-10-09 9:42 ` Greg Kroah-Hartman
2020-10-09 11:31 ` Qais Yousef
2020-10-09 11:31 ` Qais Yousef
2020-10-09 12:40 ` Catalin Marinas
2020-10-09 12:40 ` Catalin Marinas
2020-10-13 14:23 ` Qais Yousef
2020-10-13 14:23 ` Qais Yousef
2020-10-09 9:25 ` Peter Zijlstra
2020-10-09 9:25 ` Peter Zijlstra
2020-10-09 9:39 ` Qais Yousef
2020-10-09 9:39 ` Qais Yousef
2020-10-09 9:51 ` Catalin Marinas [this message]
2020-10-09 9:51 ` Catalin Marinas
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=20201009095112.GE23638@gaia \
--to=catalin.marinas@arm.com \
--cc=gregkh@linuxfoundation.org \
--cc=linux-arch@vger.kernel.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=maz@kernel.org \
--cc=morten.rasmussen@arm.com \
--cc=peterz@infradead.org \
--cc=qais.yousef@arm.com \
--cc=torvalds@linux-foundation.org \
--cc=will@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 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.