linux-arch.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Morten Rasmussen <morten.rasmussen@arm.com>
To: Peter Zijlstra <peterz@infradead.org>
Cc: Qais Yousef <qais.yousef@arm.com>,
	linux-arch@vger.kernel.org, Marc Zyngier <maz@kernel.org>,
	Will Deacon <will@kernel.org>,
	Catalin Marinas <catalin.marinas@arm.com>,
	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:13:12 +0200	[thread overview]
Message-ID: <20201009081312.GA8004@e123083-lin> (raw)
In-Reply-To: <20201009072943.GD2628@hirez.programming.kicks-ass.net>

On Fri, Oct 09, 2020 at 09:29:43AM +0200, Peter Zijlstra wrote:
> On Thu, Oct 08, 2020 at 07:16:41PM +0100, Qais Yousef wrote:
> > diff --git a/arch/arm64/kernel/signal.c b/arch/arm64/kernel/signal.c
> > index cf94cc248fbe..7e97f1589f33 100644
> > --- a/arch/arm64/kernel/signal.c
> > +++ b/arch/arm64/kernel/signal.c
> > @@ -908,13 +908,28 @@ static void do_signal(struct pt_regs *regs)
> >  	restore_saved_sigmask();
> >  }
> >  
> > +static void set_32bit_cpus_allowed(void)
> >  {
> > +	cpumask_var_t cpus_allowed;
> > +	int ret = 0;
> > +
> > +	if (cpumask_subset(current->cpus_ptr, &aarch32_el0_mask))
> > +		return;
> > +
> >  	/*
> > +	 * On asym aarch32 systems, if the task has invalid cpus in its mask,
> > +	 * we try to fix it by removing the invalid ones.
> >  	 */
> > +	if (!alloc_cpumask_var(&cpus_allowed, GFP_ATOMIC)) {
> > +		ret = -ENOMEM;
> > +	} else {
> > +		cpumask_and(cpus_allowed, current->cpus_ptr, &aarch32_el0_mask);
> > +		ret = set_cpus_allowed_ptr(current, cpus_allowed);
> > +		free_cpumask_var(cpus_allowed);
> > +	}
> > +
> > +	if (ret) {
> > +		pr_warn_once("Failed to fixup affinity of running 32-bit task\n");
> >  		force_sig(SIGKILL);
> >  	}
> >  }
> 
> Yeah, no. Not going to happen.
> 
> 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, ...).

Like the above tweak, this won't help if the intersection mask is empty,
task will still get killed but it will allow tasks to survive
user-space masks including some non-compatible CPUs. If we want to
prevent task killing in all cases (ignoring hotplug) it gets more ugly
as we would have to ignore the user-space mask in some cases.

Morten

  reply	other threads:[~2020-10-09  8:13 UTC|newest]

Thread overview: 33+ 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 ` [RFC PATCH 1/3] arm64: kvm: Handle " Qais Yousef
2020-10-09  8:12   ` Marc Zyngier
2020-10-09  9:58     ` Qais Yousef
2020-10-09 12:34       ` Marc Zyngier
2020-10-09 12:48         ` Qais Yousef
2020-10-12 15:32           ` James Morse
2020-10-13 10:32             ` Marc Zyngier
2020-10-13 11:51               ` James Morse
2020-10-13 11:59                 ` Qais Yousef
2020-10-13 12:09                   ` Marc Zyngier
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:22   ` Randy Dunlap
2020-10-12 10:22     ` Qais Yousef
2020-10-09  6:13   ` Greg Kroah-Hartman
2020-10-09  8:40     ` Will Deacon
2020-10-09  8:50     ` Catalin Marinas
2020-10-09  9:39   ` Catalin Marinas
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-09  7:29   ` Peter Zijlstra
2020-10-09  8:13     ` Morten Rasmussen [this message]
2020-10-09  8:31       ` Will Deacon
2020-10-09  8:50         ` Morten Rasmussen
2020-10-09  9:33         ` Catalin Marinas
2020-10-09  9:42           ` Greg Kroah-Hartman
2020-10-09 11:31           ` Qais Yousef
2020-10-09 12:40             ` Catalin Marinas
2020-10-13 14:23               ` Qais Yousef
2020-10-09  9:25       ` Peter Zijlstra
2020-10-09  9:39         ` Qais Yousef
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=20201009081312.GA8004@e123083-lin \
    --to=morten.rasmussen@arm.com \
    --cc=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=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 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).