All of lore.kernel.org
 help / color / mirror / Atom feed
From: Will Deacon <will@kernel.org>
To: Qais Yousef <qais.yousef@arm.com>
Cc: linux-arm-kernel@lists.infradead.org, linux-arch@vger.kernel.org,
	linux-kernel@vger.kernel.org,
	Catalin Marinas <catalin.marinas@arm.com>,
	Marc Zyngier <maz@kernel.org>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	Peter Zijlstra <peterz@infradead.org>,
	Morten Rasmussen <morten.rasmussen@arm.com>,
	Suren Baghdasaryan <surenb@google.com>,
	Quentin Perret <qperret@google.com>, Tejun Heo <tj@kernel.org>,
	Li Zefan <lizefan@huawei.com>,
	Johannes Weiner <hannes@cmpxchg.org>,
	Ingo Molnar <mingo@redhat.com>,
	Juri Lelli <juri.lelli@redhat.com>,
	Vincent Guittot <vincent.guittot@linaro.org>,
	"Rafael J. Wysocki" <rjw@rjwysocki.net>,
	kernel-team@android.com
Subject: Re: [PATCH v6 12/21] sched: Allow task CPU affinity to be restricted on asymmetric systems
Date: Mon, 24 May 2021 22:43:49 +0100	[thread overview]
Message-ID: <20210524214348.GH15545@willie-the-truck> (raw)
In-Reply-To: <20210521171132.ev56j4isuxtf2zqa@e107158-lin.cambridge.arm.com>

On Fri, May 21, 2021 at 06:11:32PM +0100, Qais Yousef wrote:
> On 05/18/21 10:47, Will Deacon wrote:
> > +static int __set_cpus_allowed_ptr_locked(struct task_struct *p,
> > +					 const struct cpumask *new_mask,
> > +					 u32 flags,
> > +					 struct rq *rq,
> > +					 struct rq_flags *rf)
> > +	__releases(rq->lock)
> > +	__releases(p->pi_lock)
> >  {
> >  	const struct cpumask *cpu_valid_mask = cpu_active_mask;
> >  	const struct cpumask *cpu_allowed_mask = task_cpu_possible_mask(p);
> >  	unsigned int dest_cpu;
> > -	struct rq_flags rf;
> > -	struct rq *rq;
> >  	int ret = 0;
> >  
> > -	rq = task_rq_lock(p, &rf);
> >  	update_rq_clock(rq);
> >  
> >  	if (p->flags & PF_KTHREAD || is_migration_disabled(p)) {
> > @@ -2430,20 +2425,158 @@ static int __set_cpus_allowed_ptr(struct task_struct *p,
> >  
> >  	__do_set_cpus_allowed(p, new_mask, flags);
> >  
> > -	return affine_move_task(rq, p, &rf, dest_cpu, flags);
> > +	if (flags & SCA_USER)
> > +		release_user_cpus_ptr(p);
> 
> Why do we need to release the pointer here?
> 
> Doesn't this mean if a 32bit task requests to change its affinity, then we'll
> lose this info and a subsequent execve() to a 64bit application means we won't
> be able to restore the original mask?
> 
> ie:
> 
> 	p0-64bit
> 	  execve(32bit_app)
> 	    // p1-32bit created
> 	    p1-32bit.change_affinity()
> 	      relase_user_cpus_ptr()
> 	    execve(64bit_app)           // lost info about p0 affinity?
> 
> Hmm I think this helped me to get the answer. p1 changed its affinity, then
> there's nothing to be inherited by a new execve(), so yes we no longer need
> this info.

Yup, you got it.

> > +static int restrict_cpus_allowed_ptr(struct task_struct *p,
> > +				     struct cpumask *new_mask,
> > +				     const struct cpumask *subset_mask)
> > +{
> > +	struct rq_flags rf;
> > +	struct rq *rq;
> > +	int err;
> > +	struct cpumask *user_mask = NULL;
> > +
> > +	if (!p->user_cpus_ptr)
> > +		user_mask = kmalloc(cpumask_size(), GFP_KERNEL);
> > +
> > +	rq = task_rq_lock(p, &rf);
> > +
> > +	/*
> > +	 * We're about to butcher the task affinity, so keep track of what
> > +	 * the user asked for in case we're able to restore it later on.
> > +	 */
> > +	if (user_mask) {
> > +		cpumask_copy(user_mask, p->cpus_ptr);
> > +		p->user_cpus_ptr = user_mask;
> > +	}
> > +
> > +	/*
> > +	 * Forcefully restricting the affinity of a deadline task is
> > +	 * likely to cause problems, so fail and noisily override the
> > +	 * mask entirely.
> > +	 */
> > +	if (task_has_dl_policy(p) && dl_bandwidth_enabled()) {
> > +		err = -EPERM;
> > +		goto err_unlock;
> 
> free(user_mark) first?
> 
> > +	}
> > +
> > +	if (!cpumask_and(new_mask, &p->cpus_mask, subset_mask)) {
> > +		err = -EINVAL;
> > +		goto err_unlock;
> 
> ditto

We free the mask when the task exits so we don't actually need to clean up
here. I left it like this on the assumption that failing here means that
it's very likely that either the task will exit or retry very soon.

However I agree that it would be clearer to free the thing anyway, so I'll
rejig the code to do that.

Will

WARNING: multiple messages have this Message-ID (diff)
From: Will Deacon <will@kernel.org>
To: Qais Yousef <qais.yousef@arm.com>
Cc: linux-arm-kernel@lists.infradead.org, linux-arch@vger.kernel.org,
	linux-kernel@vger.kernel.org,
	Catalin Marinas <catalin.marinas@arm.com>,
	Marc Zyngier <maz@kernel.org>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	Peter Zijlstra <peterz@infradead.org>,
	Morten Rasmussen <morten.rasmussen@arm.com>,
	Suren Baghdasaryan <surenb@google.com>,
	Quentin Perret <qperret@google.com>, Tejun Heo <tj@kernel.org>,
	Li Zefan <lizefan@huawei.com>,
	Johannes Weiner <hannes@cmpxchg.org>,
	Ingo Molnar <mingo@redhat.com>,
	Juri Lelli <juri.lelli@redhat.com>,
	Vincent Guittot <vincent.guittot@linaro.org>,
	"Rafael J. Wysocki" <rjw@rjwysocki.net>,
	kernel-team@android.com
Subject: Re: [PATCH v6 12/21] sched: Allow task CPU affinity to be restricted on asymmetric systems
Date: Mon, 24 May 2021 22:43:49 +0100	[thread overview]
Message-ID: <20210524214348.GH15545@willie-the-truck> (raw)
In-Reply-To: <20210521171132.ev56j4isuxtf2zqa@e107158-lin.cambridge.arm.com>

On Fri, May 21, 2021 at 06:11:32PM +0100, Qais Yousef wrote:
> On 05/18/21 10:47, Will Deacon wrote:
> > +static int __set_cpus_allowed_ptr_locked(struct task_struct *p,
> > +					 const struct cpumask *new_mask,
> > +					 u32 flags,
> > +					 struct rq *rq,
> > +					 struct rq_flags *rf)
> > +	__releases(rq->lock)
> > +	__releases(p->pi_lock)
> >  {
> >  	const struct cpumask *cpu_valid_mask = cpu_active_mask;
> >  	const struct cpumask *cpu_allowed_mask = task_cpu_possible_mask(p);
> >  	unsigned int dest_cpu;
> > -	struct rq_flags rf;
> > -	struct rq *rq;
> >  	int ret = 0;
> >  
> > -	rq = task_rq_lock(p, &rf);
> >  	update_rq_clock(rq);
> >  
> >  	if (p->flags & PF_KTHREAD || is_migration_disabled(p)) {
> > @@ -2430,20 +2425,158 @@ static int __set_cpus_allowed_ptr(struct task_struct *p,
> >  
> >  	__do_set_cpus_allowed(p, new_mask, flags);
> >  
> > -	return affine_move_task(rq, p, &rf, dest_cpu, flags);
> > +	if (flags & SCA_USER)
> > +		release_user_cpus_ptr(p);
> 
> Why do we need to release the pointer here?
> 
> Doesn't this mean if a 32bit task requests to change its affinity, then we'll
> lose this info and a subsequent execve() to a 64bit application means we won't
> be able to restore the original mask?
> 
> ie:
> 
> 	p0-64bit
> 	  execve(32bit_app)
> 	    // p1-32bit created
> 	    p1-32bit.change_affinity()
> 	      relase_user_cpus_ptr()
> 	    execve(64bit_app)           // lost info about p0 affinity?
> 
> Hmm I think this helped me to get the answer. p1 changed its affinity, then
> there's nothing to be inherited by a new execve(), so yes we no longer need
> this info.

Yup, you got it.

> > +static int restrict_cpus_allowed_ptr(struct task_struct *p,
> > +				     struct cpumask *new_mask,
> > +				     const struct cpumask *subset_mask)
> > +{
> > +	struct rq_flags rf;
> > +	struct rq *rq;
> > +	int err;
> > +	struct cpumask *user_mask = NULL;
> > +
> > +	if (!p->user_cpus_ptr)
> > +		user_mask = kmalloc(cpumask_size(), GFP_KERNEL);
> > +
> > +	rq = task_rq_lock(p, &rf);
> > +
> > +	/*
> > +	 * We're about to butcher the task affinity, so keep track of what
> > +	 * the user asked for in case we're able to restore it later on.
> > +	 */
> > +	if (user_mask) {
> > +		cpumask_copy(user_mask, p->cpus_ptr);
> > +		p->user_cpus_ptr = user_mask;
> > +	}
> > +
> > +	/*
> > +	 * Forcefully restricting the affinity of a deadline task is
> > +	 * likely to cause problems, so fail and noisily override the
> > +	 * mask entirely.
> > +	 */
> > +	if (task_has_dl_policy(p) && dl_bandwidth_enabled()) {
> > +		err = -EPERM;
> > +		goto err_unlock;
> 
> free(user_mark) first?
> 
> > +	}
> > +
> > +	if (!cpumask_and(new_mask, &p->cpus_mask, subset_mask)) {
> > +		err = -EINVAL;
> > +		goto err_unlock;
> 
> ditto

We free the mask when the task exits so we don't actually need to clean up
here. I left it like this on the assumption that failing here means that
it's very likely that either the task will exit or retry very soon.

However I agree that it would be clearer to free the thing anyway, so I'll
rejig the code to do that.

Will

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

  reply	other threads:[~2021-05-24 21:43 UTC|newest]

Thread overview: 166+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-05-18  9:47 [PATCH v6 00/21] Add support for 32-bit tasks on asymmetric AArch32 systems Will Deacon
2021-05-18  9:47 ` Will Deacon
2021-05-18  9:47 ` [PATCH v6 01/21] arm64: cpuinfo: Split AArch32 registers out into a separate struct Will Deacon
2021-05-18  9:47   ` Will Deacon
2021-05-21 10:47   ` Catalin Marinas
2021-05-21 10:47     ` Catalin Marinas
2021-05-18  9:47 ` [PATCH v6 02/21] arm64: Allow mismatched 32-bit EL0 support Will Deacon
2021-05-18  9:47   ` Will Deacon
2021-05-21 10:25   ` Catalin Marinas
2021-05-21 10:25     ` Catalin Marinas
2021-05-24 12:05     ` Will Deacon
2021-05-24 12:05       ` Will Deacon
2021-05-24 13:49       ` Catalin Marinas
2021-05-24 13:49         ` Catalin Marinas
2021-05-21 10:41   ` Catalin Marinas
2021-05-21 10:41     ` Catalin Marinas
2021-05-24 12:09     ` Will Deacon
2021-05-24 12:09       ` Will Deacon
2021-05-24 13:46       ` Catalin Marinas
2021-05-24 13:46         ` Catalin Marinas
2021-05-21 15:22   ` Qais Yousef
2021-05-21 15:22     ` Qais Yousef
2021-05-24 20:21     ` Will Deacon
2021-05-24 20:21       ` Will Deacon
2021-05-18  9:47 ` [PATCH v6 03/21] KVM: arm64: Kill 32-bit vCPUs on systems with mismatched " Will Deacon
2021-05-18  9:47   ` Will Deacon
2021-05-21 10:47   ` Catalin Marinas
2021-05-21 10:47     ` Catalin Marinas
2021-05-18  9:47 ` [PATCH v6 04/21] arm64: Kill 32-bit applications scheduled on 64-bit-only CPUs Will Deacon
2021-05-18  9:47   ` Will Deacon
2021-05-21 10:55   ` Catalin Marinas
2021-05-21 10:55     ` Catalin Marinas
2021-05-18  9:47 ` [PATCH v6 05/21] arm64: Advertise CPUs capable of running 32-bit applications in sysfs Will Deacon
2021-05-18  9:47   ` Will Deacon
2021-05-21 11:00   ` Catalin Marinas
2021-05-21 11:00     ` Catalin Marinas
2021-05-18  9:47 ` [PATCH v6 06/21] sched: Introduce task_cpu_possible_mask() to limit fallback rq selection Will Deacon
2021-05-18  9:47   ` Will Deacon
2021-05-21 16:03   ` Peter Zijlstra
2021-05-21 16:03     ` Peter Zijlstra
2021-05-24 12:17     ` Will Deacon
2021-05-24 12:17       ` Will Deacon
2021-05-18  9:47 ` [PATCH v6 07/21] cpuset: Don't use the cpu_possible_mask as a last resort for cgroup v1 Will Deacon
2021-05-18  9:47   ` Will Deacon
2021-05-21 17:39   ` Qais Yousef
2021-05-21 17:39     ` Qais Yousef
2021-05-24 20:21     ` Will Deacon
2021-05-24 20:21       ` Will Deacon
2021-05-18  9:47 ` [PATCH v6 08/21] cpuset: Honour task_cpu_possible_mask() in guarantee_online_cpus() Will Deacon
2021-05-18  9:47   ` Will Deacon
2021-05-21 16:25   ` Qais Yousef
2021-05-21 16:25     ` Qais Yousef
2021-05-24 21:09     ` Will Deacon
2021-05-24 21:09       ` Will Deacon
2021-05-18  9:47 ` [PATCH v6 09/21] sched: Reject CPU affinity changes based on task_cpu_possible_mask() Will Deacon
2021-05-18  9:47   ` Will Deacon
2021-05-18  9:47 ` [PATCH v6 10/21] sched: Introduce task_struct::user_cpus_ptr to track requested affinity Will Deacon
2021-05-18  9:47   ` Will Deacon
2021-05-18  9:47 ` [PATCH v6 11/21] sched: Split the guts of sched_setaffinity() into a helper function Will Deacon
2021-05-18  9:47   ` Will Deacon
2021-05-21 16:41   ` Qais Yousef
2021-05-21 16:41     ` Qais Yousef
2021-05-24 21:16     ` Will Deacon
2021-05-24 21:16       ` Will Deacon
2021-05-18  9:47 ` [PATCH v6 12/21] sched: Allow task CPU affinity to be restricted on asymmetric systems Will Deacon
2021-05-18  9:47   ` Will Deacon
2021-05-21 17:11   ` Qais Yousef
2021-05-21 17:11     ` Qais Yousef
2021-05-24 21:43     ` Will Deacon [this message]
2021-05-24 21:43       ` Will Deacon
2021-05-18  9:47 ` [PATCH v6 13/21] sched: Admit forcefully-affined tasks into SCHED_DEADLINE Will Deacon
2021-05-18  9:47   ` Will Deacon
2021-05-18 10:20   ` Quentin Perret
2021-05-18 10:20     ` Quentin Perret
2021-05-18 10:28     ` Will Deacon
2021-05-18 10:28       ` Will Deacon
2021-05-18 10:48       ` Quentin Perret
2021-05-18 10:48         ` Quentin Perret
2021-05-18 10:59         ` Will Deacon
2021-05-18 10:59           ` Will Deacon
2021-05-18 13:19           ` Quentin Perret
2021-05-18 13:19             ` Quentin Perret
2021-05-20  9:13             ` Juri Lelli
2021-05-20  9:13               ` Juri Lelli
2021-05-20 10:16               ` Will Deacon
2021-05-20 10:16                 ` Will Deacon
2021-05-20 10:33                 ` Quentin Perret
2021-05-20 10:33                   ` Quentin Perret
2021-05-20 12:38                   ` Juri Lelli
2021-05-20 12:38                     ` Juri Lelli
2021-05-20 12:38                   ` Daniel Bristot de Oliveira
2021-05-20 12:38                     ` Daniel Bristot de Oliveira
2021-05-20 15:06                     ` Dietmar Eggemann
2021-05-20 15:06                       ` Dietmar Eggemann
2021-05-20 16:00                       ` Daniel Bristot de Oliveira
2021-05-20 16:00                         ` Daniel Bristot de Oliveira
2021-05-20 17:55                         ` Dietmar Eggemann
2021-05-20 17:55                           ` Dietmar Eggemann
2021-05-20 18:03                           ` Will Deacon
2021-05-20 18:03                             ` Will Deacon
2021-05-21 11:26                             ` Dietmar Eggemann
2021-05-21 11:26                               ` Dietmar Eggemann
2021-05-20 18:01                     ` Will Deacon
2021-05-20 18:01                       ` Will Deacon
2021-05-21  5:25                       ` Juri Lelli
2021-05-21  5:25                         ` Juri Lelli
2021-05-21  8:15                         ` Quentin Perret
2021-05-21  8:15                           ` Quentin Perret
2021-05-21  8:39                           ` Juri Lelli
2021-05-21  8:39                             ` Juri Lelli
2021-05-21 10:37                             ` Will Deacon
2021-05-21 10:37                               ` Will Deacon
2021-05-21 11:23                               ` Dietmar Eggemann
2021-05-21 11:23                                 ` Dietmar Eggemann
2021-05-21 13:02                                 ` Quentin Perret
2021-05-21 13:02                                   ` Quentin Perret
2021-05-21 14:04                                   ` Juri Lelli
2021-05-21 14:04                                     ` Juri Lelli
2021-05-21 17:47                                     ` Dietmar Eggemann
2021-05-21 17:47                                       ` Dietmar Eggemann
2021-05-21 13:00                               ` Daniel Bristot de Oliveira
2021-05-21 13:00                                 ` Daniel Bristot de Oliveira
2021-05-21 13:12                                 ` Quentin Perret
2021-05-21 13:12                                   ` Quentin Perret
2021-05-24 20:47                                 ` Will Deacon
2021-05-24 20:47                                   ` Will Deacon
2021-05-18  9:47 ` [PATCH v6 14/21] freezer: Add frozen_or_skipped() helper function Will Deacon
2021-05-18  9:47   ` Will Deacon
2021-05-18  9:47 ` [PATCH v6 15/21] sched: Defer wakeup in ttwu() for unschedulable frozen tasks Will Deacon
2021-05-18  9:47   ` Will Deacon
2021-05-18  9:47 ` [PATCH v6 16/21] arm64: Implement task_cpu_possible_mask() Will Deacon
2021-05-18  9:47   ` Will Deacon
2021-05-24 14:57   ` Catalin Marinas
2021-05-24 14:57     ` Catalin Marinas
2021-05-18  9:47 ` [PATCH v6 17/21] arm64: exec: Adjust affinity for compat tasks with mismatched 32-bit EL0 Will Deacon
2021-05-18  9:47   ` Will Deacon
2021-05-24 15:02   ` Catalin Marinas
2021-05-24 15:02     ` Catalin Marinas
2021-05-18  9:47 ` [PATCH v6 18/21] arm64: Prevent offlining first CPU with 32-bit EL0 on mismatched system Will Deacon
2021-05-18  9:47   ` Will Deacon
2021-05-24 15:46   ` Catalin Marinas
2021-05-24 15:46     ` Catalin Marinas
2021-05-24 20:32     ` Will Deacon
2021-05-24 20:32       ` Will Deacon
2021-05-25  9:43       ` Catalin Marinas
2021-05-25  9:43         ` Catalin Marinas
2021-05-18  9:47 ` [PATCH v6 19/21] arm64: Hook up cmdline parameter to allow mismatched 32-bit EL0 Will Deacon
2021-05-18  9:47   ` Will Deacon
2021-05-24 15:47   ` Catalin Marinas
2021-05-24 15:47     ` Catalin Marinas
2021-05-18  9:47 ` [PATCH v6 20/21] arm64: Remove logic to kill 32-bit tasks on 64-bit-only cores Will Deacon
2021-05-18  9:47   ` Will Deacon
2021-05-24 15:47   ` Catalin Marinas
2021-05-24 15:47     ` Catalin Marinas
2021-05-18  9:47 ` [PATCH v6 21/21] Documentation: arm64: describe asymmetric 32-bit support Will Deacon
2021-05-18  9:47   ` Will Deacon
2021-05-21 17:37   ` Qais Yousef
2021-05-21 17:37     ` Qais Yousef
2021-05-24 21:46     ` Will Deacon
2021-05-24 21:46       ` Will Deacon
2021-05-24 16:22   ` Catalin Marinas
2021-05-24 16:22     ` Catalin Marinas
2021-05-21 17:45 ` [PATCH v6 00/21] Add support for 32-bit tasks on asymmetric AArch32 systems Qais Yousef
2021-05-21 17:45   ` Qais Yousef
2021-05-24 22:08   ` Will Deacon
2021-05-24 22:08     ` Will Deacon

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=20210524214348.GH15545@willie-the-truck \
    --to=will@kernel.org \
    --cc=catalin.marinas@arm.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=hannes@cmpxchg.org \
    --cc=juri.lelli@redhat.com \
    --cc=kernel-team@android.com \
    --cc=linux-arch@vger.kernel.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=lizefan@huawei.com \
    --cc=maz@kernel.org \
    --cc=mingo@redhat.com \
    --cc=morten.rasmussen@arm.com \
    --cc=peterz@infradead.org \
    --cc=qais.yousef@arm.com \
    --cc=qperret@google.com \
    --cc=rjw@rjwysocki.net \
    --cc=surenb@google.com \
    --cc=tj@kernel.org \
    --cc=vincent.guittot@linaro.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.