lkml.org 
[lkml]   [2015]   [Apr]   [23]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH v16] sys_membarrier(): system-wide memory barrier (generic, x86)
----- Original Message -----
> On Fri, Apr 17 2015, Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
> wrote:
>
> > + */
> > +SYSCALL_DEFINE2(membarrier, int, cmd, int, flags)
> > +{
> > + switch (cmd) {
> > + case MEMBARRIER_CMD_QUERY:
> > + return MEMBARRIER_CMD_BITMASK;
> > + case MEMBARRIER_CMD_SHARED:
> > + if (num_online_cpus() > 1)
> > + synchronize_sched();
> > + return 0;
> > + default:
> > + return -EINVAL;
> > + }
> > +}
>
> Shouldn't flags be enforced 0, to actually make future extensions
> possible without risk of breaking some sloppy userspace? I think that is
> or should be part of "make sure new syscalls take a flags parameter".

Very good point! I will update the code to check this, and the documentation,
with the wording:

(in membarrier.c:)
"@flags: Currently needs to be 0. For future extensions."
(in man page)
"The flags argument needs to be 0. For future extensions."

>
> > + * If this system call is not implemented, -ENOSYS is returned. If the
> > + * command specified does not exist, or if the command argument is
> > invalid,
> > + * this system call returns -EINVAL. For a given command, this system call
> > + * is guaranteed to always return the same value until reboot.
>
> I like that guarantee, but it may be a bit much to promise for any and
> all possible future flags. So maybe weaken it to 'For a given command
> and flags==0, this ...'.

This makes tons of sense, updating the doc with this too, with the
wording:

"For a given command, with flags argument set to 0, this system call
is guaranteed to always return the same value until reboot."

Thanks!

Mathieu

>
>
> Rasmus
>

--
Mathieu Desnoyers
EfficiOS Inc.
http://www.efficios.com


\
 
 \ /
  Last update: 2015-04-23 16:41    [W:0.122 / U:0.360 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site