Re: [PATCH] Fix: disable sys_membarrier when nohz_full is enabled

["Paul E. McKenney" <paulmck@linux.vnet.ibm.com>]

On Thu, Nov 17, 2016 at 02:51:26PM +0800, Lai Jiangshan wrote:
> On Fri, Nov 4, 2016 at 12:29 AM, Mathieu Desnoyers
> <mathieu.desnoyers@efficios.com> wrote:
> > Userspace applications should be allowed to expect the membarrier system
> > call with MEMBARRIER_CMD_SHARED command to issue memory barriers on
> > nohz_full CPUs, but synchronize_sched() does not take those into
> > account.
> >
> > Given that we do not want unrelated processes to be able to affect
> > real-time sensitive nohz_full CPUs, simply return ENOSYS when membarrier
> > is invoked on a kernel with enabled nohz_full CPUs.
> >
> > Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
> > CC: "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
> > CC: Josh Triplett <josh@joshtriplett.org>
> > CC: Steven Rostedt <rostedt@goodmis.org>
> > CC: Lai Jiangshan <jiangshanlai@gmail.com>
> > CC: <stable@vger.kernel.org>    [3.10+]
> > ---
> >  kernel/membarrier.c | 4 ++++
> >  1 file changed, 4 insertions(+)
> >
> > diff --git a/kernel/membarrier.c b/kernel/membarrier.c
> > index 536c727..9f9284f 100644
> > --- a/kernel/membarrier.c
> > +++ b/kernel/membarrier.c
> > @@ -16,6 +16,7 @@
> >
> >  #include <linux/syscalls.h>
> >  #include <linux/membarrier.h>
> > +#include <linux/tick.h>
> >
> >  /*
> >   * Bitmask made from a "or" of all commands within enum membarrier_cmd,
> > @@ -51,6 +52,9 @@
> >   */
> >  SYSCALL_DEFINE2(membarrier, int, cmd, int, flags)
> >  {
> > +       /* MEMBARRIER_CMD_SHARED is not compatible with nohz_full. */
> > +       if (tick_nohz_full_enabled())
> > +               return -ENOSYS;
> 
> I guess this code needs to be moved down into the branch of
> "case MEMBARRIER_CMD_SHARED" to match its comment.
> 
> Acked-by: Lai Jiangshan <jiangshanlai@gmail.com>

Added, thank you!

> But I'm afraid, in the future, tick_nohz_full will become a default y
> feature. thus it makes sys_membarrier() always disabled. we might
> need a new MEMBARRIER_CMD_XXX to handle it?

Makes a lot of sense to me!

							Thanx, Paul