All of lore.kernel.org
 help / color / mirror / Atom feed
From: Frederic Weisbecker <frederic@kernel.org>
To: Alex Belits <abelits@marvell.com>
Cc: Prasun Kapoor <pkapoor@marvell.com>,
	"linux-api@vger.kernel.org" <linux-api@vger.kernel.org>,
	"davem@davemloft.net" <davem@davemloft.net>,
	"trix@redhat.com" <trix@redhat.com>,
	"mingo@kernel.org" <mingo@kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"rostedt@goodmis.org" <rostedt@goodmis.org>,
	"peterx@redhat.com" <peterx@redhat.com>,
	"tglx@linutronix.de" <tglx@linutronix.de>,
	"nitesh@redhat.com" <nitesh@redhat.com>,
	"linux-arch@vger.kernel.org" <linux-arch@vger.kernel.org>,
	"mtosatti@redhat.com" <mtosatti@redhat.com>,
	"will@kernel.org" <will@kernel.org>,
	"peterz@infradead.org" <peterz@infradead.org>,
	"leon@sidebranch.com" <leon@sidebranch.com>,
	"linux-arm-kernel@lists.infradead.org" 
	<linux-arm-kernel@lists.infradead.org>,
	"catalin.marinas@arm.com" <catalin.marinas@arm.com>,
	"pauld@redhat.com" <pauld@redhat.com>,
	"netdev@vger.kernel.org" <netdev@vger.kernel.org>
Subject: Re: [EXT] Re: [PATCH v5 9/9] task_isolation: kick_all_cpus_sync: don't kick isolated cpus
Date: Tue, 24 Nov 2020 00:21:06 +0100	[thread overview]
Message-ID: <20201123232106.GD1751@lothringen> (raw)
In-Reply-To: <c65ac23c1c408614110635c33eaf4ace98da4343.camel@marvell.com>

On Mon, Nov 23, 2020 at 10:39:34PM +0000, Alex Belits wrote:
> 
> On Mon, 2020-11-23 at 23:29 +0100, Frederic Weisbecker wrote:
> > External Email
> > 
> > -------------------------------------------------------------------
> > ---
> > On Mon, Nov 23, 2020 at 05:58:42PM +0000, Alex Belits wrote:
> > > From: Yuri Norov <ynorov@marvell.com>
> > > 
> > > Make sure that kick_all_cpus_sync() does not call CPUs that are
> > > running
> > > isolated tasks.
> > > 
> > > Signed-off-by: Yuri Norov <ynorov@marvell.com>
> > > [abelits@marvell.com: use safe task_isolation_cpumask()
> > > implementation]
> > > Signed-off-by: Alex Belits <abelits@marvell.com>
> > > ---
> > >  kernel/smp.c | 14 +++++++++++++-
> > >  1 file changed, 13 insertions(+), 1 deletion(-)
> > > 
> > > diff --git a/kernel/smp.c b/kernel/smp.c
> > > index 4d17501433be..b2faecf58ed0 100644
> > > --- a/kernel/smp.c
> > > +++ b/kernel/smp.c
> > > @@ -932,9 +932,21 @@ static void do_nothing(void *unused)
> > >   */
> > >  void kick_all_cpus_sync(void)
> > >  {
> > > +	struct cpumask mask;
> > > +
> > >  	/* Make sure the change is visible before we kick the cpus */
> > >  	smp_mb();
> > > -	smp_call_function(do_nothing, NULL, 1);
> > > +
> > > +	preempt_disable();
> > > +#ifdef CONFIG_TASK_ISOLATION
> > > +	cpumask_clear(&mask);
> > > +	task_isolation_cpumask(&mask);
> > > +	cpumask_complement(&mask, &mask);
> > > +#else
> > > +	cpumask_setall(&mask);
> > > +#endif
> > > +	smp_call_function_many(&mask, do_nothing, NULL, 1);
> > > +	preempt_enable();
> > 
> > Same comment about IPIs here.
> 
> This is different from timers. The original design was based on the
> idea that every CPU should be able to enter kernel at any time and run
> kernel code with no additional preparation. Then the only solution is
> to always do full broadcast and require all CPUs to process it.
> 
> What I am trying to introduce is the idea of CPU that is not likely to
> run kernel code any soon, and can afford to go through an additional
> synchronization procedure on the next entry into kernel. The
> synchronization is not skipped, it simply happens later, early in
> kernel entry code.

Ah I see, this is ordered that way:

ll_isol_flags = ISOLATED

         CPU 0                                CPU 1
    ------------------                       -----------------
                                            // kernel entry
    data_to_sync = 1                        ll_isol_flags = ISOLATED_BROKEN
    smp_mb()                                smp_mb()
    if ll_isol_flags(CPU 1) == ISOLATED     READ data_to_sync
         smp_call(CPU 1)

You should document that, ie: explain why what you're doing is safe.

Also Beware though that the data to sync in question doesn't need to be visible
in the entry code before task_isolation_kernel_enter(). You need to audit all
the callers of kick_all_cpus_sync().

WARNING: multiple messages have this Message-ID (diff)
From: Frederic Weisbecker <frederic@kernel.org>
To: Alex Belits <abelits@marvell.com>
Cc: "linux-arch@vger.kernel.org" <linux-arch@vger.kernel.org>,
	"nitesh@redhat.com" <nitesh@redhat.com>,
	"pauld@redhat.com" <pauld@redhat.com>,
	"catalin.marinas@arm.com" <catalin.marinas@arm.com>,
	"peterz@infradead.org" <peterz@infradead.org>,
	Prasun Kapoor <pkapoor@marvell.com>,
	"mtosatti@redhat.com" <mtosatti@redhat.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"rostedt@goodmis.org" <rostedt@goodmis.org>,
	"davem@davemloft.net" <davem@davemloft.net>,
	"leon@sidebranch.com" <leon@sidebranch.com>,
	"netdev@vger.kernel.org" <netdev@vger.kernel.org>,
	"peterx@redhat.com" <peterx@redhat.com>,
	"trix@redhat.com" <trix@redhat.com>,
	"tglx@linutronix.de" <tglx@linutronix.de>,
	"linux-api@vger.kernel.org" <linux-api@vger.kernel.org>,
	"will@kernel.org" <will@kernel.org>,
	"mingo@kernel.org" <mingo@kernel.org>,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>
Subject: Re: [EXT] Re: [PATCH v5 9/9] task_isolation: kick_all_cpus_sync: don't kick isolated cpus
Date: Tue, 24 Nov 2020 00:21:06 +0100	[thread overview]
Message-ID: <20201123232106.GD1751@lothringen> (raw)
In-Reply-To: <c65ac23c1c408614110635c33eaf4ace98da4343.camel@marvell.com>

On Mon, Nov 23, 2020 at 10:39:34PM +0000, Alex Belits wrote:
> 
> On Mon, 2020-11-23 at 23:29 +0100, Frederic Weisbecker wrote:
> > External Email
> > 
> > -------------------------------------------------------------------
> > ---
> > On Mon, Nov 23, 2020 at 05:58:42PM +0000, Alex Belits wrote:
> > > From: Yuri Norov <ynorov@marvell.com>
> > > 
> > > Make sure that kick_all_cpus_sync() does not call CPUs that are
> > > running
> > > isolated tasks.
> > > 
> > > Signed-off-by: Yuri Norov <ynorov@marvell.com>
> > > [abelits@marvell.com: use safe task_isolation_cpumask()
> > > implementation]
> > > Signed-off-by: Alex Belits <abelits@marvell.com>
> > > ---
> > >  kernel/smp.c | 14 +++++++++++++-
> > >  1 file changed, 13 insertions(+), 1 deletion(-)
> > > 
> > > diff --git a/kernel/smp.c b/kernel/smp.c
> > > index 4d17501433be..b2faecf58ed0 100644
> > > --- a/kernel/smp.c
> > > +++ b/kernel/smp.c
> > > @@ -932,9 +932,21 @@ static void do_nothing(void *unused)
> > >   */
> > >  void kick_all_cpus_sync(void)
> > >  {
> > > +	struct cpumask mask;
> > > +
> > >  	/* Make sure the change is visible before we kick the cpus */
> > >  	smp_mb();
> > > -	smp_call_function(do_nothing, NULL, 1);
> > > +
> > > +	preempt_disable();
> > > +#ifdef CONFIG_TASK_ISOLATION
> > > +	cpumask_clear(&mask);
> > > +	task_isolation_cpumask(&mask);
> > > +	cpumask_complement(&mask, &mask);
> > > +#else
> > > +	cpumask_setall(&mask);
> > > +#endif
> > > +	smp_call_function_many(&mask, do_nothing, NULL, 1);
> > > +	preempt_enable();
> > 
> > Same comment about IPIs here.
> 
> This is different from timers. The original design was based on the
> idea that every CPU should be able to enter kernel at any time and run
> kernel code with no additional preparation. Then the only solution is
> to always do full broadcast and require all CPUs to process it.
> 
> What I am trying to introduce is the idea of CPU that is not likely to
> run kernel code any soon, and can afford to go through an additional
> synchronization procedure on the next entry into kernel. The
> synchronization is not skipped, it simply happens later, early in
> kernel entry code.

Ah I see, this is ordered that way:

ll_isol_flags = ISOLATED

         CPU 0                                CPU 1
    ------------------                       -----------------
                                            // kernel entry
    data_to_sync = 1                        ll_isol_flags = ISOLATED_BROKEN
    smp_mb()                                smp_mb()
    if ll_isol_flags(CPU 1) == ISOLATED     READ data_to_sync
         smp_call(CPU 1)

You should document that, ie: explain why what you're doing is safe.

Also Beware though that the data to sync in question doesn't need to be visible
in the entry code before task_isolation_kernel_enter(). You need to audit all
the callers of kick_all_cpus_sync().

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

  reply	other threads:[~2020-11-23 23:21 UTC|newest]

Thread overview: 74+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-11-23 17:42 [PATCH v5 0/9] "Task_isolation" mode Alex Belits
2020-11-23 17:42 ` Alex Belits
2020-11-23 17:56 ` [PATCH v5 1/9] task_isolation: vmstat: add quiet_vmstat_sync function Alex Belits
2020-11-23 17:56   ` Alex Belits
2020-11-23 21:48   ` Thomas Gleixner
2020-11-23 21:48     ` Thomas Gleixner
2020-11-23 17:56 ` [PATCH v5 2/9] task_isolation: vmstat: add vmstat_idle function Alex Belits
2020-11-23 17:56   ` Alex Belits
2020-11-23 21:49   ` Thomas Gleixner
2020-11-23 21:49     ` Thomas Gleixner
2020-11-23 17:56 ` [PATCH v5 3/9] task_isolation: userspace hard isolation from kernel Alex Belits
2020-11-23 17:56   ` Alex Belits
2020-11-23 22:01   ` Thomas Gleixner
2020-11-23 22:01     ` Thomas Gleixner
2020-11-23 17:57 ` [PATCH v5 4/9] task_isolation: Add task isolation hooks to arch-independent code Alex Belits
2020-11-23 17:57   ` Alex Belits
2020-11-23 22:31   ` Thomas Gleixner
2020-11-23 22:31     ` Thomas Gleixner
2020-11-23 17:57 ` [PATCH v5 5/9] task_isolation: Add driver-specific hooks Alex Belits
2020-11-23 17:57   ` Alex Belits
2020-12-02 14:18   ` Mark Rutland
2020-12-02 14:18     ` Mark Rutland
2020-12-04  0:43     ` [EXT] " Alex Belits
2020-12-04  0:43       ` Alex Belits
2020-11-23 17:58 ` [PATCH v5 6/9] task_isolation: arch/arm64: enable task isolation functionality Alex Belits
2020-11-23 17:58   ` Alex Belits
2020-12-02 13:59   ` Mark Rutland
2020-12-02 13:59     ` Mark Rutland
2020-12-04  0:37     ` [EXT] " Alex Belits
2020-12-04  0:37       ` Alex Belits
2020-12-07 11:57       ` Mark Rutland
2020-12-07 11:57         ` Mark Rutland
2020-11-23 17:58 ` [PATCH v5 7/9] task_isolation: don't interrupt CPUs with tick_nohz_full_kick_cpu() Alex Belits
2020-11-23 17:58   ` Alex Belits
2020-11-23 22:13   ` Frederic Weisbecker
2020-11-23 22:13     ` Frederic Weisbecker
2020-11-23 22:35     ` Alex Belits
2020-11-23 22:35       ` Alex Belits
2020-11-23 22:36   ` Thomas Gleixner
2020-11-23 22:36     ` Thomas Gleixner
2020-12-02 14:20   ` Mark Rutland
2020-12-02 14:20     ` Mark Rutland
2020-12-04  0:54     ` [EXT] " Alex Belits
2020-12-04  0:54       ` Alex Belits
2020-12-07 11:58       ` Mark Rutland
2020-12-07 11:58         ` Mark Rutland
2020-11-23 17:58 ` [PATCH v5 8/9] task_isolation: ringbuffer: don't interrupt CPUs running isolated tasks on buffer resize Alex Belits
2020-11-23 17:58   ` Alex Belits
2020-11-23 17:58 ` [PATCH v5 9/9] task_isolation: kick_all_cpus_sync: don't kick isolated cpus Alex Belits
2020-11-23 17:58   ` Alex Belits
2020-11-23 22:29   ` Frederic Weisbecker
2020-11-23 22:29     ` Frederic Weisbecker
2020-11-23 22:39     ` [EXT] " Alex Belits
2020-11-23 22:39       ` Alex Belits
2020-11-23 23:21       ` Frederic Weisbecker [this message]
2020-11-23 23:21         ` Frederic Weisbecker
2020-11-25  3:20         ` Alex Belits
2020-11-25  3:20           ` Alex Belits
2021-01-22 15:00         ` Marcelo Tosatti
2021-01-22 15:00           ` Marcelo Tosatti
2020-11-24 16:36 ` [PATCH v5 0/9] "Task_isolation" mode Tom Rix
2020-11-24 16:36   ` Tom Rix
2020-11-24 17:40   ` [EXT] " Alex Belits
2020-11-24 17:40     ` Alex Belits
2020-12-02 14:02     ` Mark Rutland
2020-12-02 14:02       ` Mark Rutland
2020-12-04  0:39       ` Alex Belits
2020-12-04  0:39         ` Alex Belits
2020-12-05 20:40 ` Pavel Machek
2020-12-05 20:40   ` Pavel Machek
2020-12-05 23:25   ` Thomas Gleixner
2020-12-05 23:25     ` Thomas Gleixner
2020-12-11 18:08     ` Yury Norov
2020-12-11 18:08       ` Yury Norov

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=20201123232106.GD1751@lothringen \
    --to=frederic@kernel.org \
    --cc=abelits@marvell.com \
    --cc=catalin.marinas@arm.com \
    --cc=davem@davemloft.net \
    --cc=leon@sidebranch.com \
    --cc=linux-api@vger.kernel.org \
    --cc=linux-arch@vger.kernel.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@kernel.org \
    --cc=mtosatti@redhat.com \
    --cc=netdev@vger.kernel.org \
    --cc=nitesh@redhat.com \
    --cc=pauld@redhat.com \
    --cc=peterx@redhat.com \
    --cc=peterz@infradead.org \
    --cc=pkapoor@marvell.com \
    --cc=rostedt@goodmis.org \
    --cc=tglx@linutronix.de \
    --cc=trix@redhat.com \
    --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.