* Re: [PATCH 1/2] Implement fchmodat4 syscall
From: Michael Kerrisk @ 2015-05-12 8:48 UTC (permalink / raw)
To: William Orr
Cc: Linux Kernel, Al Viro, Miklos Szeredi, Linux API, Linux-Fsdevel,
Andrew Ayer
In-Reply-To: <1431310042-52247-2-git-send-email-will@worrbase.com>
[expanding CC]
On Mon, May 11, 2015 at 4:07 AM, William Orr <will@worrbase.com> wrote:
> Adds fchmodat4 which more closely matches POSIX by taking 4 arguments,
> including the flags argument. flags are the same as fchownat(2), implementing
> both AT_SYMLINK_NOFOLLOW and AT_EMPTY_PATH
>
> Based heavily off of Andrew Ayer's patch from 2012.
> ---
> fs/open.c | 19 +++++++++++++++++--
> include/linux/syscalls.h | 2 ++
> 2 files changed, 19 insertions(+), 2 deletions(-)
>
> diff --git a/fs/open.c b/fs/open.c
> index 98e5a52..00dd0f7 100644
> --- a/fs/open.c
> +++ b/fs/open.c
> @@ -504,6 +504,9 @@ static int chmod_common(struct path *path, umode_t mode)
> struct iattr newattrs;
> int error;
>
> + if (S_ISLNK(inode->i_mode))
> + return -EOPNOTSUPP;
> +
> error = mnt_want_write(path->mnt);
> if (error)
> return error;
> @@ -541,9 +544,21 @@ SYSCALL_DEFINE2(fchmod, unsigned int, fd, umode_t, mode)
>
> SYSCALL_DEFINE3(fchmodat, int, dfd, const char __user *, filename, umode_t, mode)
> {
> + return sys_fchmodat4(dfd, filename, mode, 0);
> +}
> +
> +SYSCALL_DEFINE4(fchmodat4, int, dfd, const char __user *, filename, umode_t, mode, int, flags)
> +{
> struct path path;
> int error;
> - unsigned int lookup_flags = LOOKUP_FOLLOW;
> + unsigned int lookup_flags;
> +
> + if (flags & ~(AT_SYMLINK_NOFOLLOW | AT_EMPTY_PATH))
> + return -EINVAL;
> +
> + lookup_flags = (flags & AT_SYMLINK_NOFOLLOW) ? 0 : LOOKUP_FOLLOW;
> + if (flags & AT_EMPTY_PATH)
> + lookup_flags |= LOOKUP_EMPTY;
> retry:
> error = user_path_at(dfd, filename, lookup_flags, &path);
> if (!error) {
> @@ -559,7 +574,7 @@ retry:
>
> SYSCALL_DEFINE2(chmod, const char __user *, filename, umode_t, mode)
> {
> - return sys_fchmodat(AT_FDCWD, filename, mode);
> + return sys_fchmodat4(AT_FDCWD, filename, mode, 0);
> }
>
> static int chown_common(struct path *path, uid_t user, gid_t group)
> diff --git a/include/linux/syscalls.h b/include/linux/syscalls.h
> index 76d1e38..d6e9602 100644
> --- a/include/linux/syscalls.h
> +++ b/include/linux/syscalls.h
> @@ -769,6 +769,8 @@ asmlinkage long sys_futimesat(int dfd, const char __user *filename,
> asmlinkage long sys_faccessat(int dfd, const char __user *filename, int mode);
> asmlinkage long sys_fchmodat(int dfd, const char __user * filename,
> umode_t mode);
> +asmlinkage long sys_fchmodat4(int dfd, const char __user * filename,
> + umode_t mode, int flags);
> asmlinkage long sys_fchownat(int dfd, const char __user *filename, uid_t user,
> gid_t group, int flag);
> asmlinkage long sys_openat(int dfd, const char __user *filename, int flags,
> --
> 2.1.0
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
--
Michael Kerrisk Linux man-pages maintainer;
http://www.kernel.org/doc/man-pages/
Author of "The Linux Programming Interface", http://blog.man7.org/
^ permalink raw reply
* Re: [PATCH] Implement fchmodat4 system call
From: Michael Kerrisk @ 2015-05-12 8:48 UTC (permalink / raw)
To: William Orr
Cc: Linux Kernel, Andrew Ayer, Al Viro, Linux-Fsdevel, Linux API,
Miklos Szeredi
In-Reply-To: <1431310042-52247-1-git-send-email-will-o9VNkMWGZsBWk0Htik3J/w@public.gmane.org>
[CC += linux-api-u79uwXL29TY76Z2rM5mHXA@public.gmane.org]
Hello William,
Since this is a kernel-user-space API change, please CC linux-api@.
The kernel source file Documentation/SubmitChecklist notes that all
Linux kernel patches that change userspace interfaces should be CCed
to linux-api-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, so that the various parties who are
interested in API changes are informed. For further information, see
https://www.kernel.org/doc/man-pages/linux-api-ml.html
Aside from that, I've added a few other people/lists to CC that seem
likely to be relevant. Some additional comments below.
On Mon, May 11, 2015 at 4:07 AM, William Orr <will-o9VNkMWGZsBWk0Htik3J/w@public.gmane.org> wrote:
> Hey,
>
> Currently, Linux's fchmodat(2) doesn't honor the flags argument. To bring it
> more in-line with POSIX and other implementations, this patch adds fchmodat4,
> which honors the flags argument, and implements the same flags as fchownat(2).
>
> This makes it possible to chmod a file without following symlinks, without
> having to call open(2) on a file with O_NOFOLLOW. This is heavily based off
> of Andrew Ayer's work in 2012, and is sent with his permission. Let me know
> if this can be applied.
>
> Please CC me, since I'm not subscribed to this list.
This seems an obviously sensible addition, and it was an obvious
mistake not to have a 'flags' argument in the original system call
(https://lwn.net/Articles/585415/). As well as getting us a proper
POSIX compliant API (and one that is consistent with other
implementations, such as FreeBSD), it allows for future behavior
expansion via the 'flags' argument.
Cheers,
Michael
--
Michael Kerrisk Linux man-pages maintainer;
http://www.kernel.org/doc/man-pages/
Author of "The Linux Programming Interface", http://blog.man7.org/
^ permalink raw reply
* Re: [PATCH 1/2] clone: Support passing tls argument via C rather than pt_regs magic
From: Ingo Molnar @ 2015-05-12 8:17 UTC (permalink / raw)
To: Josh Triplett, Andrew Morton
Cc: Thomas Gleixner, Andy Lutomirski, Ingo Molnar, H. Peter Anvin,
Peter Zijlstra, Linus Torvalds, linux-api-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, x86-DgEjT+Ai2ygdnm+yROfE0A
In-Reply-To: <20150511193050.GA11002@jtriplet-mobl1>
* Josh Triplett <josh-iaAMLnmF4UmaiuxdJuQwMA@public.gmane.org> wrote:
> > Looks good to me, but I have not looked very deeply ...
>
> I sent out a v2 with the co-author information moved from the
> signoffs to the commit message. If it looks reasonable to you, can
> you take it through the tip tree please?
So since this is multi-arch, and changes kernel/fork.c, I'd say -mm is
a more appropriate home for it? (Assuming Linus does not object.)
Thanks,
Ingo
^ permalink raw reply
* Re: [PATCH 1/2] clone: Support passing tls argument via C rather than pt_regs magic
From: Josh Triplett @ 2015-05-12 7:07 UTC (permalink / raw)
To: Vineet Gupta
Cc: Andy Lutomirski, Ingo Molnar, H. Peter Anvin, Peter Zijlstra,
Thomas Gleixner, Linus Torvalds,
linux-api-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
x86-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org, Arnd Bergmann,
Al Viro, linux-arch-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
In-Reply-To: <55518112.9040808-HKixBCOQz3hWk0Htik3J/w@public.gmane.org>
On Tue, May 12, 2015 at 09:56:58AM +0530, Vineet Gupta wrote:
> On Monday 11 May 2015 08:17 PM, Josh Triplett wrote:
> > On Mon, May 11, 2015 at 02:31:39PM +0000, Vineet Gupta wrote:
> >> On Tuesday 21 April 2015 11:17 PM, Josh Triplett wrote:
> >>> clone with CLONE_SETTLS accepts an argument to set the thread-local
> >>> storage area for the new thread. sys_clone declares an int argument
> >>> tls_val in the appropriate point in the argument list (based on the
> >>> various CLONE_BACKWARDS variants), but doesn't actually use or pass
> >>> along that argument. Instead, sys_clone calls do_fork, which calls
> >>> copy_process, which calls the arch-specific copy_thread, and copy_thread
> >>> pulls the corresponding syscall argument out of the pt_regs captured at
> >>> kernel entry (knowing what argument of clone that architecture passes
> >>> tls in).
> >>>
> >>> Apart from being awful and inscrutable, that also only works because
> >>> only one code path into copy_thread can pass the CLONE_SETTLS flag, and
> >>> that code path comes from sys_clone with its architecture-specific
> >>> argument-passing order. This prevents introducing a new version of the
> >>> clone system call without propagating the same architecture-specific
> >>> position of the tls argument.
> >>>
> >>> However, there's no reason to pull the argument out of pt_regs when
> >>> sys_clone could just pass it down via C function call arguments.
> >>>
> >>> Introduce a new CONFIG_HAVE_COPY_THREAD_TLS for architectures to opt
> >>> into, and a new copy_thread_tls that accepts the tls parameter as an
> >>> additional unsigned long (syscall-argument-sized) argument.
> >>> Change sys_clone's tls argument to an unsigned long (which does
> >>> not change the ABI), and pass that down to copy_thread_tls.
> >>>
> >>> Architectures that don't opt into copy_thread_tls will continue to
> >>> ignore the C argument to sys_clone in favor of the pt_regs captured at
> >>> kernel entry, and thus will be unable to introduce new versions of the
> >>> clone syscall.
> >>>
> >>> Signed-off-by: Josh Triplett <josh-iaAMLnmF4UmaiuxdJuQwMA@public.gmane.org>
> >>> Signed-off-by: Thiago Macieira <thiago.macieira-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
> >>> Acked-by: Andy Lutomirski <luto-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
> >>> ---
> >>> arch/Kconfig | 7 ++++++
> >>> include/linux/sched.h | 14 ++++++++++++
> >>> include/linux/syscalls.h | 6 +++---
> >>> kernel/fork.c | 55 +++++++++++++++++++++++++++++++-----------------
> >>> 4 files changed, 60 insertions(+), 22 deletions(-)
> >>>
> >>> diff --git a/arch/Kconfig b/arch/Kconfig
> >>> index 05d7a8a..4834a58 100644
> >>> --- a/arch/Kconfig
> >>> +++ b/arch/Kconfig
> >>> @@ -484,6 +484,13 @@ config HAVE_IRQ_EXIT_ON_IRQ_STACK
> >>> This spares a stack switch and improves cache usage on softirq
> >>> processing.
> >>>
> >>> +config HAVE_COPY_THREAD_TLS
> >>> + bool
> >>> + help
> >>> + Architecture provides copy_thread_tls to accept tls argument via
> >>> + normal C parameter passing, rather than extracting the syscall
> >>> + argument from pt_regs.
> >>> +
> >>> #
> >>> # ABI hall of shame
> >>> #
> >>> diff --git a/include/linux/sched.h b/include/linux/sched.h
> >>> index a419b65..2cc88c6 100644
> >>> --- a/include/linux/sched.h
> >>> +++ b/include/linux/sched.h
> >>> @@ -2480,8 +2480,22 @@ extern struct mm_struct *mm_access(struct task_struct *task, unsigned int mode);
> >>> /* Remove the current tasks stale references to the old mm_struct */
> >>> extern void mm_release(struct task_struct *, struct mm_struct *);
> >>>
> >>> +#ifdef CONFIG_HAVE_COPY_THREAD_TLS
> >>> +extern int copy_thread_tls(unsigned long, unsigned long, unsigned long,
> >>> + struct task_struct *, unsigned long);
> >>> +#else
> >>> extern int copy_thread(unsigned long, unsigned long, unsigned long,
> >>> struct task_struct *);
> >>> +
> >>> +/* Architectures that haven't opted into copy_thread_tls get the tls argument
> >>> + * via pt_regs, so ignore the tls argument passed via C. */
> >>> +static inline int copy_thread_tls(
> >>> + unsigned long clone_flags, unsigned long sp, unsigned long arg,
> >>> + struct task_struct *p, unsigned long tls)
> >>> +{
> >>> + return copy_thread(clone_flags, sp, arg, p);
> >>> +}
> >>> +#endif
> >>
> >> Is this detour really needed. Can we not update copy_thread() of all arches in one
> >> go and add the tls arg, w/o using it.
> >>
> >> And then arch maintainers can micro-optimize their code to use that arg vs.
> >> pt_regs->rxx version at their own leisure. The only downside I see with that is
> >> bigger churn (touches all arches), and a interim unused arg warning ?
> >
> > In addition to the cleanup and simplification, the purpose of this patch
> > is specifically to make sure that any architecture opting into
> > HAVE_COPY_THREAD_TLS does *not* care how tls is passed in, and in
> > particular doesn't depend on it arriving in a specific syscall argument.
>
> Sorry for sounding dense, but as I see here, in the end even for non opting
> arches, copy_thread_tls() calling convention expects tls arg passed to it from
> sys_clone call stack, but simply drops it. So that arg is always available, has to
> be, otherwise even the pt_regs approach won't get to it.
That just avoids the need for preprocessor conditionals in the middle of
copy_process, and allows copy_process to start accepting the tls
argument from sys_clone. The version passed to sys_clone via C is not
actually used unless the architecture opts into HAVE_COPY_THREAD_TLS.
> The opt in approach simply avoids touching all arches in one go, to pass @tls
> unconditionally to copy_thread().
That's not the only change every arch would need; they'd need to
actually pass it correctly from their arch-specific syscall entry point
into sys_clone, which not all architectures do. (x86, for instance, did
not.)
> I think latter has simpler unified calling convention and avoids proliferating
> another Kconfig option across arches, which actually any sane arch will opt into
> in the end - there's no reason not to.
All architectures should, eventually, but just as many architectures
don't wire up new syscalls right away, not all architectures will opt in
at the same time. And you're already suggesting that architectures
won't actually convert right away:
> Note that passing the arg doesn't mean arch needs to be converted right away in
> terms of how it references the orig syscall @tls param. It can do it as maintainer
> deems fit and in fact the build warning will pester them to do that sooner than later.
I don't like to introduce new warnings. And without the new Kconfig
symbol, there's nothing to depend on to ensure that the target
architecture has fixed this. CONFIG_CLONE4 needs to depend on
CONFIG_HAVE_COPY_THREAD_TLS, for instance, because it'll be broken
otherwise.
> > I have patches in flight (for CLONE_FD and clone4) that depend on that
> > assumption, by introducing additional syscalls (with tls passed
> > differently) that call down through these same code paths.
>
> But that is different from copy_thread() vs, copy_thread_tls() aspect of the
> story. Perhaps if u could point me to your in works git branch or some such I'd be
> able to comprehend this better.
They're on LKML in the clone4 thread; see
http://thread.gmane.org/gmane.linux.kernel.api/9171 .
- Josh Triplett
^ permalink raw reply
* Re: [PATCHv2 0/2] clone: Support passing tls argument via C rather than pt_regs magic
From: Ingo Molnar @ 2015-05-12 7:02 UTC (permalink / raw)
To: Josh Triplett
Cc: Andy Lutomirski, Ingo Molnar, H. Peter Anvin, Peter Zijlstra,
Thomas Gleixner, Linus Torvalds, linux-api-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, x86-DgEjT+Ai2ygdnm+yROfE0A
In-Reply-To: <20150511192810.GA11328@jtriplet-mobl1>
* Josh Triplett <josh-iaAMLnmF4UmaiuxdJuQwMA@public.gmane.org> wrote:
> clone has some of the quirkiest syscall handling in the kernel, with
> a pile of special cases, historical curiosities, and
> architecture-specific calling conventions. In particular, clone
> with CLONE_SETTLS accepts a parameter "tls" that the C entry point
> completely ignores and some assembly entry points overwrite;
> instead, the low-level arch-specific code pulls the tls parameter
> out of the arch-specific register captured as part of pt_regs on
> entry to the kernel. That's a massive hack, and it makes the
> arch-specific code only work when called via the specific existing
> syscall entry points; because of this hack, any new clone-like
> system call would have to accept an identical tls argument in
> exactly the same arch-specific position, rather than providing a
> unified system call entry point across architectures.
>
> The first patch allows architectures to handle the tls argument via
> normal C parameter passing, if they opt in by selecting
> HAVE_COPY_THREAD_TLS. The second patch makes 32-bit and 64-bit x86
> opt into this.
>
> These two patches came out of the clone4 series, which isn't ready
> for this merge window, but these first two cleanup patches were
> entirely uncontroversial and have acks. I'd like to go ahead and
> submit these two so that other architectures can begin building on
> top of this and opting into HAVE_COPY_THREAD_TLS. However, I'm also
> happy to wait and send these through the next merge window (along
> with v3 of clone4) if anyone would prefer that.
>
> v2: Move co-author from signoffs to a note in the commit message, as
> required by Ingo Molnar.
>
> Josh Triplett (2):
> clone: Support passing tls argument via C rather than pt_regs magic
> x86: Opt into HAVE_COPY_THREAD_TLS, for both 32-bit and 64-bit
>
> arch/Kconfig | 7 ++++++
> arch/x86/Kconfig | 1 +
> arch/x86/ia32/ia32entry.S | 2 +-
> arch/x86/kernel/process_32.c | 6 ++---
> arch/x86/kernel/process_64.c | 8 +++----
> include/linux/sched.h | 14 +++++++++++
> include/linux/syscalls.h | 6 ++---
> kernel/fork.c | 55 +++++++++++++++++++++++++++++---------------
> 8 files changed, 69 insertions(+), 30 deletions(-)
So I have no objections if Linus doesn't see a cleaner/better
approach.
Thanks,
Ingo
^ permalink raw reply
* Re: [PATCH RFC] vfs: add a O_NOMTIME flag
From: Kevin Easton @ 2015-05-12 5:08 UTC (permalink / raw)
To: Theodore Ts'o
Cc: Sage Weil, Trond Myklebust, Dave Chinner, Zach Brown,
Alexander Viro, Linux FS-devel Mailing List,
Linux Kernel Mailing List, Linux API Mailing List
In-Reply-To: <20150511231021.GC14088@thunk.org>
On Mon, May 11, 2015 at 07:10:21PM -0400, Theodore Ts'o wrote:
> On Mon, May 11, 2015 at 09:24:09AM -0700, Sage Weil wrote:
> > > Let me re-ask the question that I asked last week (and was apparently
> > > ignored). Why not trying to use the lazytime feature instead of
> > > pointing a head straight at the application's --- and system
> > > administrators' --- heads?
> >
> > Sorry Ted, I thought I responded already.
> >
> > The goal is to avoid inode writeout entirely when we can, and
> > as I understand it lazytime will still force writeout before the inode
> > is dropped from the cache. In systems like Ceph in particular, the
> > IOs can be spread across lots of files, so simply deferring writeout
> > doesn't always help.
>
> Sure, but it would reduce the writeout by orders of magnitude. I can
> understand if you want to reduce it further, but it might be good
> enough for your purposes.
>
> I considered doing the equivalent of O_NOMTIME for our purposes at
> $WORK, and our use case is actually not that different from Ceph's
> (i.e., using a local disk file system to support a cluster file
> system), and lazytime was (a) something I figured was something I
> could upstream in good conscience, and (b) was more than good enough
> for us.
A safer alternative might be a chattr file attribute that if set, the
mtime is not updated on writes, and stat() on the file always shows the
mtime as "right now". At least that way, the file won't accidentally
get left out of backups that rely on the mtime.
(If the file attribute is unset, you immediately update the mtime then
too, and from then on the file is back to normal).
- Kevin
^ permalink raw reply
* Re: [PATCH 0/6] support "dataplane" mode for nohz_full
From: Mike Galbraith @ 2015-05-12 4:35 UTC (permalink / raw)
To: Chris Metcalf
Cc: Frederic Weisbecker, Steven Rostedt, Ingo Molnar, Andrew Morton,
Gilad Ben Yossef, Ingo Molnar, Peter Zijlstra, Rik van Riel,
Tejun Heo, Thomas Gleixner, Paul E. McKenney, Christoph Lameter,
Srivatsa S. Bhat, linux-doc, linux-api, linux-kernel
In-Reply-To: <1431395275.3195.19.camel@gmail.com>
On Tue, 2015-05-12 at 03:47 +0200, Mike Galbraith wrote:
> On Mon, 2015-05-11 at 15:25 -0400, Chris Metcalf wrote:
> > On 05/11/2015 03:19 PM, Mike Galbraith wrote:
> > > I really shouldn't have acked nohz_full -> isolcpus. Beside the fact
> > > that old static isolcpus was_supposed_ to crawl off and die, I know
> > > beyond doubt that having isolated a cpu as well as you can definitely
> > > does NOT imply that said cpu should become tickless.
> >
> > True, at a high level, I agree that it would be better to have a
> > top-level concept like Frederic's proposed ISOLATION that includes
> > isolcpus and nohz_cpu (and other stuff as needed).
> >
> > That said, what you wrote above is wrong; even with the patch you
> > acked, setting isolcpus does not automatically turn on nohz_full for
> > a given cpu. The patch made it true the other way around: when
> > you say nohz_full, you automatically get isolcpus on that cpu too.
> > That does, at least, make sense for the semantics of nohz_full.
>
> I didn't write that, I wrote nohz_full implies (spelled '->') isolcpus.
> Yes, with nohz_full currently being static, the old allegedly dying but
> also static isolcpus scheduler off switch is a convenient thing to wire
> the nohz_full CPU SET (<- hint;) property to.
BTW, another facet of this: Rik wants to make isolcpus immune to
cpusets, which makes some sense, user did say isolcpus=, but that also
makes isolcpus truly static. If the user now says nohz_full=, they lose
the ability to deactivate CPU isolation, making the set fairly useless
for anything other than HPC. Currently, the user can flip the isolation
switch as he sees fit. He takes a size extra large performance hit for
having said nohz_full=, but he doesn't lose generic utility.
-Mike
^ permalink raw reply
* Re: [PATCH 1/2] clone: Support passing tls argument via C rather than pt_regs magic
From: Vineet Gupta @ 2015-05-12 4:26 UTC (permalink / raw)
To: Josh Triplett, Vineet Gupta
Cc: Andy Lutomirski, Ingo Molnar, H. Peter Anvin, Peter Zijlstra,
Thomas Gleixner, Linus Torvalds,
linux-api-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
x86-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org, Arnd Bergmann,
Al Viro, linux-arch-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
In-Reply-To: <20150511144717.GC6130@x>
+CC Arnd, Al, linux-arch
On Monday 11 May 2015 08:17 PM, Josh Triplett wrote:
> On Mon, May 11, 2015 at 02:31:39PM +0000, Vineet Gupta wrote:
>> On Tuesday 21 April 2015 11:17 PM, Josh Triplett wrote:
>>> clone with CLONE_SETTLS accepts an argument to set the thread-local
>>> storage area for the new thread. sys_clone declares an int argument
>>> tls_val in the appropriate point in the argument list (based on the
>>> various CLONE_BACKWARDS variants), but doesn't actually use or pass
>>> along that argument. Instead, sys_clone calls do_fork, which calls
>>> copy_process, which calls the arch-specific copy_thread, and copy_thread
>>> pulls the corresponding syscall argument out of the pt_regs captured at
>>> kernel entry (knowing what argument of clone that architecture passes
>>> tls in).
>>>
>>> Apart from being awful and inscrutable, that also only works because
>>> only one code path into copy_thread can pass the CLONE_SETTLS flag, and
>>> that code path comes from sys_clone with its architecture-specific
>>> argument-passing order. This prevents introducing a new version of the
>>> clone system call without propagating the same architecture-specific
>>> position of the tls argument.
>>>
>>> However, there's no reason to pull the argument out of pt_regs when
>>> sys_clone could just pass it down via C function call arguments.
>>>
>>> Introduce a new CONFIG_HAVE_COPY_THREAD_TLS for architectures to opt
>>> into, and a new copy_thread_tls that accepts the tls parameter as an
>>> additional unsigned long (syscall-argument-sized) argument.
>>> Change sys_clone's tls argument to an unsigned long (which does
>>> not change the ABI), and pass that down to copy_thread_tls.
>>>
>>> Architectures that don't opt into copy_thread_tls will continue to
>>> ignore the C argument to sys_clone in favor of the pt_regs captured at
>>> kernel entry, and thus will be unable to introduce new versions of the
>>> clone syscall.
>>>
>>> Signed-off-by: Josh Triplett <josh-iaAMLnmF4UmaiuxdJuQwMA@public.gmane.org>
>>> Signed-off-by: Thiago Macieira <thiago.macieira-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
>>> Acked-by: Andy Lutomirski <luto-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
>>> ---
>>> arch/Kconfig | 7 ++++++
>>> include/linux/sched.h | 14 ++++++++++++
>>> include/linux/syscalls.h | 6 +++---
>>> kernel/fork.c | 55 +++++++++++++++++++++++++++++++-----------------
>>> 4 files changed, 60 insertions(+), 22 deletions(-)
>>>
>>> diff --git a/arch/Kconfig b/arch/Kconfig
>>> index 05d7a8a..4834a58 100644
>>> --- a/arch/Kconfig
>>> +++ b/arch/Kconfig
>>> @@ -484,6 +484,13 @@ config HAVE_IRQ_EXIT_ON_IRQ_STACK
>>> This spares a stack switch and improves cache usage on softirq
>>> processing.
>>>
>>> +config HAVE_COPY_THREAD_TLS
>>> + bool
>>> + help
>>> + Architecture provides copy_thread_tls to accept tls argument via
>>> + normal C parameter passing, rather than extracting the syscall
>>> + argument from pt_regs.
>>> +
>>> #
>>> # ABI hall of shame
>>> #
>>> diff --git a/include/linux/sched.h b/include/linux/sched.h
>>> index a419b65..2cc88c6 100644
>>> --- a/include/linux/sched.h
>>> +++ b/include/linux/sched.h
>>> @@ -2480,8 +2480,22 @@ extern struct mm_struct *mm_access(struct task_struct *task, unsigned int mode);
>>> /* Remove the current tasks stale references to the old mm_struct */
>>> extern void mm_release(struct task_struct *, struct mm_struct *);
>>>
>>> +#ifdef CONFIG_HAVE_COPY_THREAD_TLS
>>> +extern int copy_thread_tls(unsigned long, unsigned long, unsigned long,
>>> + struct task_struct *, unsigned long);
>>> +#else
>>> extern int copy_thread(unsigned long, unsigned long, unsigned long,
>>> struct task_struct *);
>>> +
>>> +/* Architectures that haven't opted into copy_thread_tls get the tls argument
>>> + * via pt_regs, so ignore the tls argument passed via C. */
>>> +static inline int copy_thread_tls(
>>> + unsigned long clone_flags, unsigned long sp, unsigned long arg,
>>> + struct task_struct *p, unsigned long tls)
>>> +{
>>> + return copy_thread(clone_flags, sp, arg, p);
>>> +}
>>> +#endif
>>
>> Is this detour really needed. Can we not update copy_thread() of all arches in one
>> go and add the tls arg, w/o using it.
>>
>> And then arch maintainers can micro-optimize their code to use that arg vs.
>> pt_regs->rxx version at their own leisure. The only downside I see with that is
>> bigger churn (touches all arches), and a interim unused arg warning ?
>
> In addition to the cleanup and simplification, the purpose of this patch
> is specifically to make sure that any architecture opting into
> HAVE_COPY_THREAD_TLS does *not* care how tls is passed in, and in
> particular doesn't depend on it arriving in a specific syscall argument.
Sorry for sounding dense, but as I see here, in the end even for non opting
arches, copy_thread_tls() calling convention expects tls arg passed to it from
sys_clone call stack, but simply drops it. So that arg is always available, has to
be, otherwise even the pt_regs approach won't get to it.
The opt in approach simply avoids touching all arches in one go, to pass @tls
unconditionally to copy_thread().
I think latter has simpler unified calling convention and avoids proliferating
another Kconfig option across arches, which actually any sane arch will opt into
in the end - there's no reason not to.
Note that passing the arg doesn't mean arch needs to be converted right away in
terms of how it references the orig syscall @tls param. It can do it as maintainer
deems fit and in fact the build warning will pester them to do that sooner than later.
> I have patches in flight (for CLONE_FD and clone4) that depend on that
> assumption, by introducing additional syscalls (with tls passed
> differently) that call down through these same code paths.
But that is different from copy_thread() vs, copy_thread_tls() aspect of the
story. Perhaps if u could point me to your in works git branch or some such I'd be
able to comprehend this better.
Thx,
-Vineet
^ permalink raw reply
* Re: [PATCH 0/6] support "dataplane" mode for nohz_full
From: Mike Galbraith @ 2015-05-12 1:47 UTC (permalink / raw)
To: Chris Metcalf
Cc: Frederic Weisbecker, Steven Rostedt, Ingo Molnar, Andrew Morton,
Gilad Ben Yossef, Ingo Molnar, Peter Zijlstra, Rik van Riel,
Tejun Heo, Thomas Gleixner, Paul E. McKenney, Christoph Lameter,
Srivatsa S. Bhat, linux-doc, linux-api, linux-kernel
In-Reply-To: <55510218.9090104@ezchip.com>
On Mon, 2015-05-11 at 15:25 -0400, Chris Metcalf wrote:
> On 05/11/2015 03:19 PM, Mike Galbraith wrote:
> > I really shouldn't have acked nohz_full -> isolcpus. Beside the fact
> > that old static isolcpus was_supposed_ to crawl off and die, I know
> > beyond doubt that having isolated a cpu as well as you can definitely
> > does NOT imply that said cpu should become tickless.
>
> True, at a high level, I agree that it would be better to have a
> top-level concept like Frederic's proposed ISOLATION that includes
> isolcpus and nohz_cpu (and other stuff as needed).
>
> That said, what you wrote above is wrong; even with the patch you
> acked, setting isolcpus does not automatically turn on nohz_full for
> a given cpu. The patch made it true the other way around: when
> you say nohz_full, you automatically get isolcpus on that cpu too.
> That does, at least, make sense for the semantics of nohz_full.
I didn't write that, I wrote nohz_full implies (spelled '->') isolcpus.
Yes, with nohz_full currently being static, the old allegedly dying but
also static isolcpus scheduler off switch is a convenient thing to wire
the nohz_full CPU SET (<- hint;) property to.
-Mike
^ permalink raw reply
* Re: [PATCH RFC] vfs: add a O_NOMTIME flag
From: Dave Chinner @ 2015-05-12 1:21 UTC (permalink / raw)
To: Sage Weil
Cc: Trond Myklebust, Zach Brown, Alexander Viro,
Linux FS-devel Mailing List, Linux Kernel Mailing List,
Linux API Mailing List
In-Reply-To: <alpine.DEB.2.00.1505111020120.28239@cobra.newdream.net>
On Mon, May 11, 2015 at 10:30:58AM -0700, Sage Weil wrote:
> On Mon, 11 May 2015, Trond Myklebust wrote:
> > On Mon, May 11, 2015 at 12:39 PM, Sage Weil <sage@newdream.net> wrote:
> > > On Mon, 11 May 2015, Dave Chinner wrote:
> > >> On Sun, May 10, 2015 at 07:13:24PM -0400, Trond Myklebust wrote:
> > >> > On Fri, May 8, 2015 at 6:24 PM, Sage Weil <sage@newdream.net> wrote:
> > >> > > I'm sure you realize what we're try to achieve is the same "invisible IO"
> > >> > > that the XFS open by handle ioctls do by default. Would you be more
> > >> > > comfortable if this option where only available to the generic
> > >> > > open_by_handle syscall, and not to open(2)?
> > >> >
> > >> > It should be an ioctl(). It has no business being part of
> > >> > open_by_handle either, since that is another generic interface.
> > >
> > > Our use-case doesn't make sense on network file systems, but it does on
> > > any reasonably featureful local filesystem, and the goal is to be generic
> > > there. If mtime is critical to a network file system's consistency it
> > > seems pretty reasonable to disallow/ignore it for just that file system
> > > (e.g., by masking off the flag at open time), as others won't have that
> > > same problem (cephfs doesn't, for example).
> > >
> > > Perhaps making each fs opt-in instead of handling it in a generic path
> > > would alleviate this concern?
> >
> > The issue isn't whether or not you have a network file system, it's
> > whether or not you want users to be able to manage data. mtime isn't
> > useful for the application (which knows whether or not it has changed
> > the file) or for the filesystem (ditto). It exists, rather, in order
> > to enable data management by users and other applications, letting
> > them know whether or not the data contents of the file have changed,
> > and when that change occurred.
>
> Agreed.
>
> > If you are able to guarantee that your users don't care about that,
> > then fine, but that would be a very special case that doesn't fit the
> > way that most data centres are run. Backups are one case where mtime
> > matters, tiering and archiving is another.
>
> This is true, although I argue it is becoming increasingly common for the
> data management (including backups and so forth) to be layered not on top
> of the POSIX file system but on something higher up in the stack. This is
In the cloud storage world, yes. In the rest of the world, no.
It's the rest of the world we are worried about here. :/
> > Neither of these examples
> > cases are under the control of the application that calls
> > open(O_NOMTIME).
>
> Wouldn't a mount option (e.g., allow_nomtime) address this concern? Only
> nodes provisioned explicitly to run these systems would be enable this
> option.
Back to my Joe Speedracer comments.....
I'm not sure what the right answer is - mount options are simply too
easy to add without understanding the full implications of them.
e.g. we didn't merge FALLOC_FL_NO_HIDE_STALE simply because it was
too dangerous for unsuspecting users. This isn't at that same level
or concern, but it's still a landmine we want to avoid users from
arming without realising it...
> > >> I'm happy for it to be an ioctl interface - even an XFS specific
> > >> interface if you want to go that route, Sage - and it probably
> > >> should emit a warning to syslog first time it is used so there is
> > >> trace for bug triage purposes. i.e. we know the app is not using
> > >> mtime updates, so bug reports that are the result of mtime
> > >> mishandling don't result in large amounts of wasted developer time
> > >> trying to understand them...
> > >
> > > A warning on using the interface (or when mounting with user_nomtime)
> > > sounds reasonable.
> > >
> > > I'd rather not make this XFS specific as other local filesystmes (ext4,
> > > f2fs, possibly btrfs) would similarly benefit. (And if we want to target
> > > XFS specifically the existing XFS open-by-handle ioctl is sufficient as it
> > > already does O_NOMTIME unconditionally.)
> >
> > Lack of a namespace, doesn't imply that you don't want to manage the
> > data. The whole point of using object storage instead of plain old
> > block storage is to be able to provide whatever metadata you still
> > need in order to manage the object.
>
> Yeah, agreed--this is presumably why open_by_handle(2) (which is what we'd
> like to use) doesn't assume O_NOMTIME.
Right - the XFS ioctls were designed specifically for applications
that interacted directly with the structure of XFS filesystems and
so needed invisible IO (e.g. online defragmenter). IOWs, they are
not interfaces intended for general usage. They are also only
available to root, so a typical user application won't be making use
of them, either.
Cheers,
Dave.
--
Dave Chinner
david@fromorbit.com
^ permalink raw reply
* Re: [PATCH 1/5] selftests: Add futex functional tests
From: John Stultz @ 2015-05-11 23:23 UTC (permalink / raw)
To: Darren Hart
Cc: Shuah Khan, Linux API, Linux Kernel Mailing List, Ingo Molnar,
Peter Zijlstra, Thomas Gleixner, Davidlohr Bueso, KOSAKI Motohiro
In-Reply-To: <D1767EA1.CC3DA%dvhart-VuQAYsv1563Yd54FQh9/CA@public.gmane.org>
On Mon, May 11, 2015 at 4:07 PM, Darren Hart <dvhart-VuQAYsv1563Yd54FQh9/CA@public.gmane.org> wrote:
> On 5/11/15, 3:21 PM, "Shuah Khan" <shuahkh-JPH+aEBZ4P+UEJcrhfAQsw@public.gmane.org> wrote:
>
>>>>>No need for a new pull request. Have you seen these errors before:
>>>>>
>>>>>make[2]: Entering directory
>>>>>'/mnt/data/lkml/linux-kselftest/tools/testing/selftests/futex'
>>>>>for DIR in functional; do make -C $DIR all ; done
>>>>>make[3]: Entering directory
>>>>>'/mnt/data/lkml/linux-kselftest/tools/testing/selftests/futex/functiona
>>>>>l'
>>>>>gcc -g -O2 -Wall -D_GNU_SOURCE -I../include -I../../ -lpthread -lrt
>>>>>futex_requeue_pi.c ../include/futextest.h -o futex_requeue_pi
>>>>>/tmp/cc2UgUVs.o: In function `create_rt_thread':
>>>>>/mnt/data/lkml/linux-kselftest/tools/testing/selftests/futex/functional
>>>>>/fu
>>>>>tex_requeue_pi.c:102:
>>>>>undefined reference to `pthread_create'
>>>>>/tmp/cc2UgUVs.o: In function `unit_test':
>>>>>/mnt/data/lkml/linux-kselftest/tools/testing/selftests/futex/functional
>>>>>/fu
>>>>>tex_requeue_pi.c:342:
>>>>>undefined reference to `pthread_join'
>>>>>/mnt/data/lkml/linux-kselftest/tools/testing/selftests/futex/functional
>>>>>/fu
>>>>>tex_requeue_pi.c:347:
>>>>>undefined reference to `pthread_join'
>>>>>/mnt/data/lkml/linux-kselftest/tools/testing/selftests/futex/functional
>>>>>/fu
>>>>>tex_requeue_pi.c:346:
>>>>>undefined reference to `pthread_join'
>>>>>collect2: error: ld returned 1 exit status
>>>>><builtin>: recipe for target 'futex_requeue_pi' failed
>>>>>make[3]: *** [futex_requeue_pi] Error 1
>>>>>make[3]: Leaving directory
>>>>>'/mnt/data/lkml/linux-kselftest/tools/testing/selftests/futex/functiona
>>>>>l'
>>>>>Makefile:7: recipe for target 'all' failed
>>>>>
>>>>>I am running make kselftest target when I saw the above build failures.
>>>>>kselftest run doesn't fail which is good, however futex tests won't
>>>>>run with this failure.
>>>>
>>>>I have not seen these errors whilst developing with futextest for the
>>>>kernel. That looks like you may be missing the pthread development
>>>>headers
>>>>from your build machine.
>>>>
>>>>Those are provided by libc6-dev on my Debian systems.
>>>>
>>>I do have lib6-dev installed. timers uses pthread compiles fine.
>>>So does mqueue. I am not sure what is going on with futex tests
>>>though. I am guessing it has to do with library link order.
>>>The following fixed it for me:
>>>-LDFLAGS := $(LDFLAGS) -lpthread -lrt
>>>+LDFLAGS := $(LDFLAGS) -pthread -lrt
>>>Could you please make this change and resend the patch series.
>>>I prefer patch series over pull request.
>>>thanks,
>>>-- Shuah
>>
>>Sorry full diff:
>>
>>
>>diff --git a/tools/testing/selftests/futex/functional/Makefile
>>b/tools/testing/selftests/futex/functional/Makefile
>>index e64d43b..b8a2e9b 100644
>>--- a/tools/testing/selftests/futex/functional/Makefile
>>+++ b/tools/testing/selftests/futex/functional/Makefile
>>@@ -1,6 +1,6 @@
>>INCLUDES := -I../include -I../../
>>CFLAGS := $(CFLAGS) -g -O2 -Wall -D_GNU_SOURCE $(INCLUDES)
>>-LDFLAGS := $(LDFLAGS) -lpthread -lrt
>>+LDFLAGS := $(LDFLAGS) -pthread -lrt
>
>
> I'm happy to do that, but I would like to make sure I'm doing the right
> thing.
>
> I'm building with:
> $ gcc --version
> gcc (Debian 4.9.2-10) 4.9.2
>
>
> What's there now works for me:
> LDFLAGS := $(LDFLAGS) -lpthread -lrt
>
>
> What you propose also works for me:
> LDFLAGS := $(LDFLAGS) -pthread -lrt
>
>
> I notice that most other test cases list -lrt first, including timers:
> LDFLAGS += -lrt -lpthread
>
> Which works for me for timers - does that work for you? I assume so. It
> also works for futexes for me. I've found references out there suggesting
> -lrt should always come before -lpthread.
>
> I suspect you are correct as -pthread provides flags for both the
> preprocessor and the linker, however, I'm still concerned about the
> ordering.
>
> John - did you deliberately choose to use "-lrt -lpthread" ?
Ooof. Possibly, but I can't say I really recall at this point.
I do remember somewhere around gcc 4.6 I had to change things around
since the linker arguments had to be at the end of the gcc string
(where as before I was throwing them in w/ the CFLAGS). I think it
was then I added the "-Wl,-no-as-needed" bit after googling around.
You might look at that as well?
Sorry I'm not of much help.
-john
^ permalink raw reply
* Re: [PATCH RFC] vfs: add a O_NOMTIME flag
From: Theodore Ts'o @ 2015-05-11 23:10 UTC (permalink / raw)
To: Sage Weil
Cc: Trond Myklebust, Dave Chinner, Zach Brown, Alexander Viro,
Linux FS-devel Mailing List, Linux Kernel Mailing List,
Linux API Mailing List
In-Reply-To: <alpine.DEB.2.00.1505110920520.28239-vIokxiIdD2AQNTJnQDzGJqxOck334EZe@public.gmane.org>
On Mon, May 11, 2015 at 09:24:09AM -0700, Sage Weil wrote:
> > Let me re-ask the question that I asked last week (and was apparently
> > ignored). Why not trying to use the lazytime feature instead of
> > pointing a head straight at the application's --- and system
> > administrators' --- heads?
>
> Sorry Ted, I thought I responded already.
>
> The goal is to avoid inode writeout entirely when we can, and
> as I understand it lazytime will still force writeout before the inode
> is dropped from the cache. In systems like Ceph in particular, the
> IOs can be spread across lots of files, so simply deferring writeout
> doesn't always help.
Sure, but it would reduce the writeout by orders of magnitude. I can
understand if you want to reduce it further, but it might be good
enough for your purposes.
I considered doing the equivalent of O_NOMTIME for our purposes at
$WORK, and our use case is actually not that different from Ceph's
(i.e., using a local disk file system to support a cluster file
system), and lazytime was (a) something I figured was something I
could upstream in good conscience, and (b) was more than good enough
for us.
Cheers,
- Ted
P.S. I do agree that if we do need this upstream, requiring a mount
option to enable the feature is probably a good compromise.
^ permalink raw reply
* Re: [PATCH 1/5] selftests: Add futex functional tests
From: Darren Hart @ 2015-05-11 23:07 UTC (permalink / raw)
To: Shuah Khan, linux-api-u79uwXL29TY76Z2rM5mHXA,
Linux Kernel Mailing List, John Stultz
Cc: Ingo Molnar, Peter Zijlstra, Thomas Gleixner, Davidlohr Bueso,
KOSAKI Motohiro
In-Reply-To: <55512B86.2040900-JPH+aEBZ4P+UEJcrhfAQsw@public.gmane.org>
On 5/11/15, 3:21 PM, "Shuah Khan" <shuahkh-JPH+aEBZ4P+UEJcrhfAQsw@public.gmane.org> wrote:
>>>>No need for a new pull request. Have you seen these errors before:
>>>>
>>>>make[2]: Entering directory
>>>>'/mnt/data/lkml/linux-kselftest/tools/testing/selftests/futex'
>>>>for DIR in functional; do make -C $DIR all ; done
>>>>make[3]: Entering directory
>>>>'/mnt/data/lkml/linux-kselftest/tools/testing/selftests/futex/functiona
>>>>l'
>>>>gcc -g -O2 -Wall -D_GNU_SOURCE -I../include -I../../ -lpthread -lrt
>>>>futex_requeue_pi.c ../include/futextest.h -o futex_requeue_pi
>>>>/tmp/cc2UgUVs.o: In function `create_rt_thread':
>>>>/mnt/data/lkml/linux-kselftest/tools/testing/selftests/futex/functional
>>>>/fu
>>>>tex_requeue_pi.c:102:
>>>>undefined reference to `pthread_create'
>>>>/tmp/cc2UgUVs.o: In function `unit_test':
>>>>/mnt/data/lkml/linux-kselftest/tools/testing/selftests/futex/functional
>>>>/fu
>>>>tex_requeue_pi.c:342:
>>>>undefined reference to `pthread_join'
>>>>/mnt/data/lkml/linux-kselftest/tools/testing/selftests/futex/functional
>>>>/fu
>>>>tex_requeue_pi.c:347:
>>>>undefined reference to `pthread_join'
>>>>/mnt/data/lkml/linux-kselftest/tools/testing/selftests/futex/functional
>>>>/fu
>>>>tex_requeue_pi.c:346:
>>>>undefined reference to `pthread_join'
>>>>collect2: error: ld returned 1 exit status
>>>><builtin>: recipe for target 'futex_requeue_pi' failed
>>>>make[3]: *** [futex_requeue_pi] Error 1
>>>>make[3]: Leaving directory
>>>>'/mnt/data/lkml/linux-kselftest/tools/testing/selftests/futex/functiona
>>>>l'
>>>>Makefile:7: recipe for target 'all' failed
>>>>
>>>>I am running make kselftest target when I saw the above build failures.
>>>>kselftest run doesn't fail which is good, however futex tests won't
>>>>run with this failure.
>>>
>>>I have not seen these errors whilst developing with futextest for the
>>>kernel. That looks like you may be missing the pthread development
>>>headers
>>>from your build machine.
>>>
>>>Those are provided by libc6-dev on my Debian systems.
>>>
>>I do have lib6-dev installed. timers uses pthread compiles fine.
>>So does mqueue. I am not sure what is going on with futex tests
>>though. I am guessing it has to do with library link order.
>>The following fixed it for me:
>>-LDFLAGS := $(LDFLAGS) -lpthread -lrt
>>+LDFLAGS := $(LDFLAGS) -pthread -lrt
>>Could you please make this change and resend the patch series.
>>I prefer patch series over pull request.
>>thanks,
>>-- Shuah
>
>Sorry full diff:
>
>
>diff --git a/tools/testing/selftests/futex/functional/Makefile
>b/tools/testing/selftests/futex/functional/Makefile
>index e64d43b..b8a2e9b 100644
>--- a/tools/testing/selftests/futex/functional/Makefile
>+++ b/tools/testing/selftests/futex/functional/Makefile
>@@ -1,6 +1,6 @@
>INCLUDES := -I../include -I../../
>CFLAGS := $(CFLAGS) -g -O2 -Wall -D_GNU_SOURCE $(INCLUDES)
>-LDFLAGS := $(LDFLAGS) -lpthread -lrt
>+LDFLAGS := $(LDFLAGS) -pthread -lrt
I'm happy to do that, but I would like to make sure I'm doing the right
thing.
I'm building with:
$ gcc --version
gcc (Debian 4.9.2-10) 4.9.2
What's there now works for me:
LDFLAGS := $(LDFLAGS) -lpthread -lrt
What you propose also works for me:
LDFLAGS := $(LDFLAGS) -pthread -lrt
I notice that most other test cases list -lrt first, including timers:
LDFLAGS += -lrt -lpthread
Which works for me for timers - does that work for you? I assume so. It
also works for futexes for me. I've found references out there suggesting
-lrt should always come before -lpthread.
I suspect you are correct as -pthread provides flags for both the
preprocessor and the linker, however, I'm still concerned about the
ordering.
John - did you deliberately choose to use "-lrt -lpthread" ?
If ordering matters and -pthread is preferred over -lpthread, then perhaps
the "right way" is:
LDFLAGS += -lrt -pthread
Since -pthread also impacts the pre-processor, it seems that if used, it
should be present in both LDFLAGS as well as CFLAGS. However, I've also
read that -pthread is a non-standard compiler option and is best avoided.
If so, and if the reversed order works for you, "-lrt -lpthread", perhaps
that would be the "right fix".
I'd like to answer this once and for all for all tests we add to selftest.
--
Darren Hart
Intel Open Source Technology Center
^ permalink raw reply
* Re: [PATCH 5/6] nohz: support PR_DATAPLANE_STRICT mode
From: Andy Lutomirski @ 2015-05-11 22:28 UTC (permalink / raw)
To: Chris Metcalf, Peter Zijlstra
Cc: Paul E. McKenney, Frederic Weisbecker, Ingo Molnar, Rik van Riel,
linux-doc@vger.kernel.org, Andrew Morton,
linux-kernel@vger.kernel.org, Thomas Gleixner, Tejun Heo,
Steven Rostedt, Christoph Lameter, Gilad Ben Yossef, Linux API
In-Reply-To: <5550FF63.1030107@ezchip.com>
[add peterz due to perf stuff]
On Mon, May 11, 2015 at 12:13 PM, Chris Metcalf <cmetcalf@ezchip.com> wrote:
> On 05/09/2015 03:28 AM, Andy Lutomirski wrote:
>>
>> On May 8, 2015 11:44 PM, "Chris Metcalf" <cmetcalf@ezchip.com> wrote:
>>>
>>> With QUIESCE mode, the task is in principle guaranteed not to be
>>> interrupted by the kernel, but only if it behaves. In particular,
>>> if it enters the kernel via system call, page fault, or any of
>>> a number of other synchronous traps, it may be unexpectedly
>>> exposed to long latencies. Add a simple flag that puts the process
>>> into a state where any such kernel entry is fatal.
>>>
>>> To allow the state to be entered and exited, we add an internal
>>> bit to current->dataplane_flags that is set when prctl() sets the
>>> flags. That way, when we are exiting the kernel after calling
>>> prctl() to forbid future kernel exits, we don't get immediately
>>> killed.
>>
>> Is there any reason this can't already be addressed in userspace using
>> /proc/interrupts or perf_events? ISTM the real goal here is to detect
>> when we screw up and fail to avoid an interrupt, and killing the task
>> seems like overkill to me.
>
>
> Patch 6/6 proposes a mechanism to track down times when the
> kernel screws up and delivers an IRQ to a userspace-only task.
> Here, we're just trying to identify the times when an application
> screws itself up out of cluelessness, and provide a mechanism
> that allows the developer to easily figure out why and fix it.
>
> In particular, /proc/interrupts won't show syscalls or page faults,
> which are two easy ways applications can screw themselves
> when they think they're in userspace-only mode. Also, they don't
> provide sufficient precision to make it clear what part of the
> application caused the undesired kernel entry.
Perf does, though, complete with context.
>
> In this case, killing the task is appropriate, since that's exactly
> the semantics that have been asked for - it's like on architectures
> that don't natively support unaligned accesses, but fake it relatively
> slowly in the kernel, and in development you just say "give me a
> SIGBUS when that happens" and in production you might say
> "fix it up and let's try to keep going".
I think more control is needed. I also think that, if we go this
route, we should distinguish syscalls, synchronous non-syscall
entries, and asynchronous non-syscall entries. They're quite
different.
>
> You can argue that this is something that can be done by ftrace,
> but certainly you'd want to have a way to programmatically
> turn on ftrace at the moment when you're entering userspace-only
> mode, so we'd want some API around that anyway. And honestly,
> it's so easy to test a task state bit in a couple of places and
> generate the failurel on the spot, vs. the relative complexity
> of setting up and understanding ftrace, that I think it merits
> inclusion on that basis alone.
perf_event, not ftrace.
>
>> Also, can we please stop further torturing the exit paths? We have a
>> disaster of assembly code that calls into syscall_trace_leave and
>> do_notify_resume. Those functions, in turn, *both* call user_enter
>> (WTF?), and on very brief inspection user_enter makes it into the nohz
>> code through multiple levels of indirection, which, with these
>> patches, has yet another conditionally enabled helper, which does this
>> new stuff. It's getting to be impossible to tell what happens when we
>> exit to user space any more.
>>
>> Also, I think your code is buggy. There's no particular guarantee
>> that user_enter is only called once between sys_prctl and the final
>> exit to user mode (see the above WTF), so you might spuriously kill
>> the process.
>
>
> This is a good point; I also find the x86 kernel entry and exit
> paths confusing, although I've reviewed them a bunch of times.
> The tile architecture paths are a little easier to understand.
>
> That said, I think the answer here is avoid non-idempotent
> actions in the dataplane code, such as clearing a syscall bit.
>
> A better implementation, I think, is to put the tests for "you
> screwed up and synchronously entered the kernel" in
> the syscall_trace_enter() code, which TIF_NOHZ already
> gets us into;
No, not unless you're planning on using that to distinguish syscalls
from other stuff *and* people think that's justified.
It's far to easy to just make a tiny change to the entry code. Add a
tiny trivial change here, a few lines of asm (that's you, audit!)
there, some weird written-in-asm scheduling code over here, and you
end up with the truly awful mess that we currently have.
If it really makes sense for this stuff to go with context tracking,
then fine, but we should *fix* the context tracking first rather than
kludging around it. I already have a prototype patch for the relevant
part of that.
> there, we can test if the dataplane "strict" bit is
> set and the syscall is not prctl(), then we generate the error.
> (We'd exclude exit and exit_group here too, since we don't
> need to shoot down a task that's just trying to kill itself.)
> This needs a bit of platform-specific code for each platform,
> but that doesn't seem like too big a problem.
I'd rather avoid that, too. This feature isn't really arch-specific,
so let's avoid the arch stuff if at all possible.
>
> Likewise we can test in exception_enter() since that's only
> called for all the synchronous user entries like page faults.
Let's try to generalize a bit. There's also irq_entry and ist_enter,
and some of the exception_enter cases are for synchronous entries
while (IIRC -- could be wrong) others aren't always like that.
>
>> Also, I think that most users will be quite surprised if "strict
>> dataplane" code causes any machine check on the system to kill your
>> dataplane task.
>
>
> Fair point, and avoided by testing as described above instead.
> (Though presumably in development it's not such a big deal,
> and as I said you'd likely turn it off in production.)
Until you forget to turn it off in production because it worked so
nicely in development.
What if we added a mode to perf where delivery of a sample
synchronously (or semi-synchronously by catching it on the next exit
to userspace) freezes the delivering task? It would be like debugger
support via perf.
peterz, do you think this would be a sensible thing to add to perf?
It would only make sense for some types of events (tracepoints and
hw_breakpoints mostly, I think).
>> So, I don't know if it is a practical suggestion or not, but would it
>> better/easier to mark a pending signal on kernel entry for this case?
>> The upsides I see is that the user gets her notification (killing the task
>> or just logging the event in a signal handler) and hopefully since return to
>> userspace with a pending signal is already handled we don't need new code in
>> the exit path?
>
>
> We could certainly do this now that I'm planning to do the
> test at kernel entry rather than super-late in kernel exit.
> Rather than just do_group_exit(SIGKILL), we should raise
> a proper SIGKILL signal via send_sig(SIGKILL, current, 1),
> and then we could catch it in the debugger; the pc should
> help identify if it was a syscall, page fault, or other trap.
>
> I'm not sure there's an argument to be made for the user
> process being able to catch the signal itself; presumably in
> production you don't turn this mode on anyway, and in
> development, assuming a debugger is probably fine.
>
> But if you want to argue for another signal (SIGILL?) please
> do; I'm curious to hear if you think it would make more sense.
Make it configurable as part of the prctl.
--Andy
^ permalink raw reply
* Re: [PATCH 1/5] selftests: Add futex functional tests
From: Shuah Khan @ 2015-05-11 22:21 UTC (permalink / raw)
To: Darren Hart, linux-api-u79uwXL29TY76Z2rM5mHXA,
Linux Kernel Mailing List
Cc: Ingo Molnar, Peter Zijlstra, Thomas Gleixner, Davidlohr Bueso,
KOSAKI Motohiro, Shuah Khan
In-Reply-To: <55512B54.50304-JPH+aEBZ4P+UEJcrhfAQsw@public.gmane.org>
On 05/11/2015 04:21 PM, Shuah Khan wrote:
> On 05/11/2015 03:50 PM, Darren Hart wrote:
>> On 5/11/15, 1:51 PM, "Shuah Khan" <shuahkh-JPH+aEBZ4P+UEJcrhfAQsw@public.gmane.org> wrote:
>>
>>> On 05/11/2015 01:47 PM, Darren Hart wrote:
>>>> On 5/11/15, 11:55 AM, "Shuah Khan" <shuahkh-JPH+aEBZ4P+UEJcrhfAQsw@public.gmane.org> wrote:
>>>>
>>>>> On 05/11/2015 12:22 PM, Darren Hart wrote:
>>>>>> On 5/11/15, 11:06 AM, "Shuah Khan" <shuahkh-JPH+aEBZ4P+UEJcrhfAQsw@public.gmane.org> wrote:
>>>>>>
>>>>>>> On 05/08/2015 04:09 PM, Darren Hart wrote:
>>>>>>>> The futextest testsuite [1] provides functional, stress, and
>>>>>>>> performance tests for the various futex op codes. Those tests will
>>>>>>>> be
>>>>>>>> of
>>>>>>>> more use to futex developers if they are included with the kernel
>>>>>>>> source.
>>>>>>>>
>>>>>>>> Copy the core infrastructure and the functional tests into
>>>>>>>> selftests,
>>>>>>>> but adapt them for inclusion in the kernel:
>>>>>>>>
>>>>>>>> - Update the Makefile to include the run_tests target, remove
>>>>>>>> reference
>>>>>>>> to the performance and stress tests from the contributed sources.
>>>>>>>> - Replace my dead IBM email address with my current Intel email
>>>>>>>> address.
>>>>>>>> - Remove the warrantee and write-to paragraphs from the license
>>>>>>>> blurbs.
>>>>>>>> - Remove the NAME section as the filename is easily determined. ;-)
>>>>>>>> - Make the whitespace usage consistent in a couple of places.
>>>>>>>> - Cleanup various CodingStyle violations.
>>>>>>>>
>>>>>>>> A future effort will explore moving the performance and stress tests
>>>>>>>> into the kernel.
>>>>>>>>
>>>>>>>> 1. http://git.kernel.org/cgit/linux/kernel/git/dvhart/futextest.git
>>>>>>>>
>>>>>>>> Cc: Shuah Khan <shuahkh-JPH+aEBZ4P+UEJcrhfAQsw@public.gmane.org>
>>>>>>>> Cc: linux-api-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
>>>>>>>> Cc: Ingo Molnar <mingo-X9Un+BFzKDI@public.gmane.org>
>>>>>>>> Cc: Peter Zijlstra <peterz-wEGCiKHe2LqWVfeAwA7xHQ@public.gmane.org>
>>>>>>>> Cc: Thomas Gleixner <tglx-hfZtesqFncYOwBW4kG4KsQ@public.gmane.org>
>>>>>>>> Cc: Davidlohr Bueso <dave-h16yJtLeMjHk1uMJSBkQmQ@public.gmane.org>
>>>>>>>> Cc: KOSAKI Motohiro <kosaki.motohiro-+CUm20s59erQFUHtdCDX3A@public.gmane.org>
>>>>>>>> Signed-off-by: Darren Hart <dvhart-VuQAYsv1563Yd54FQh9/CA@public.gmane.org>
>>>>>>>> ---
>>>>>>>
>>>>>>> Daren,
>>>>>>>
>>>>>>> I am seeing
>>>>>>>
>>>>>>> fatal: cannot convert from y to UTF-8
>>>>>>>
>>>>>>> when I try to apply the patch. Did you use git send-email?
>>>>>>
>>>>>> Hi Shuah,
>>>>>>
>>>>>> I've seen that from one of my contributors earlier this month as
>>>>>> well. I
>>>>>> dropped the Content... Header and it applied without problems.
>>>>>>
>>>>>> I created the patch using git format-patch and then sent them using
>>>>>> git
>>>>>> send-email - via a script I've been using for years now...
>>>>>>
>>>>>> Checking the files locally:
>>>>>> $ file *
>>>>>> 0000-cover-letter.patch: ASCII
>>>>>> text
>>>>>> 0001-selftests-Add-futex-functional-tests.patch:
>>>>>> unified
>>>>>> diff output, UTF-8 Unicode text
>>>>>> 0002-selftest-futex-Update-Makefile-to-use-lib.mk.patch:
>>>>>> unified
>>>>>> diff output, ASCII text
>>>>>> 0003-selftest-futex-Increment-ksft-pass-and-fail-counters.patch:
>>>>>> unified
>>>>>> diff output, ASCII text
>>>>>> 0004-selftest-Add-futex-tests-to-the-top-level-Makefile.patch:
>>>>>> unified
>>>>>> diff output, ASCII text
>>>>>> 0005-kselftest-Add-exit-code-defines.patch:
>>>>>> unified
>>>>>> diff output, ASCII text
>>>>>>
>>>>>>
>>>>>> This shows that only the first in UTF-8 and the rest are ASCII. I
>>>>>> presume
>>>>>> this is due to the Copyright notices in the original files:
>>>>>>
>>>>>> Copyright © International Business Machines Corp., 2006-2008
>>>>>>
>>>>>> Which use © instead of (C). I just checked and there are 545 instances
>>>>>> of
>>>>>> © in the kernel itself, so this should not present a problem.
>>>>>>
>>>>>> I apologize for the glitch in applying. If you use the pull request I
>>>>>> included that will avoid the mail transport issues, and I will be sure
>>>>>> to
>>>>>> fix my scripts to avoid the issue in the future.
>>>>>>
>>>>>> If you want to use the patches directly, please have a look at 1 of 5
>>>>>> and
>>>>>> just remove the "Content..." header, and I think you'll find "git am"
>>>>>> will
>>>>>> apply it without complaint.
>>>>>>
>>>>>
>>>>> Hi Daren,
>>>>>
>>>>> Removing the Content header got me past the utf error. However, git am
>>>>> complains:
>>>>>
>>>>> git am --signoff
>>>>>
>>>>> ../4.2_patches/futex_tests/PATCH_1_5selftestsAddfutexfunctionaltests.mbo
>>>>> x
>>>>> Applying: selftests: Add futex functional tests
>>>>> /mnt/data/lkml/linux-kselftest/.git/rebase-apply/patch:1457: new blank
>>>>> line at EOF.
>>>>> +
>>>>> warning: 1 line adds whitespace errors.
>>>>>
>>>>> Could you look into these. Rest of the patches applied fine.
>>>>
>>>> Hi Shuah,
>>>>
>>>> This was due to a newline at the end of:
>>>> tools/testing/selftests/futex/functional/run.sh
>>>>
>>>> Which unfortunately checkpatch.pl doesn't catch. My fault for not
>>>> applying
>>>> the series from the generated patches first. Sorry for the hassle.
>>>>
>>>> I have corrected this in the first patch and pushed v3 of the series to:
>>>>
>>>> git://git.infradead.org/users/dvhart/linux.git futextest-v3
>>>>
>>>>
>>>> $ git diff infradead/futextest-v2 infradead/futextest-v3
>>>> diff --git a/tools/testing/selftests/futex/functional/run.sh
>>>> b/tools/testing/selftests/futex/functional/run.sh
>>>> index 46827a8..e87dbe2 100755
>>>> --- a/tools/testing/selftests/futex/functional/run.sh
>>>> +++ b/tools/testing/selftests/futex/functional/run.sh
>>>> @@ -77,4 +77,3 @@ echo
>>>> echo
>>>> ./futex_wait_uninitialized_heap $COLOR
>>>> ./futex_wait_private_mapped_file $COLOR
>>>> -
>>>>
>>>>
>>>
>>> No need for a new pull request. Have you seen these errors before:
>>>
>>> make[2]: Entering directory
>>> '/mnt/data/lkml/linux-kselftest/tools/testing/selftests/futex'
>>> for DIR in functional; do make -C $DIR all ; done
>>> make[3]: Entering directory
>>> '/mnt/data/lkml/linux-kselftest/tools/testing/selftests/futex/functional'
>>> gcc -g -O2 -Wall -D_GNU_SOURCE -I../include -I../../ -lpthread -lrt
>>> futex_requeue_pi.c ../include/futextest.h -o futex_requeue_pi
>>> /tmp/cc2UgUVs.o: In function `create_rt_thread':
>>> /mnt/data/lkml/linux-kselftest/tools/testing/selftests/futex/functional/fu
>>> tex_requeue_pi.c:102:
>>> undefined reference to `pthread_create'
>>> /tmp/cc2UgUVs.o: In function `unit_test':
>>> /mnt/data/lkml/linux-kselftest/tools/testing/selftests/futex/functional/fu
>>> tex_requeue_pi.c:342:
>>> undefined reference to `pthread_join'
>>> /mnt/data/lkml/linux-kselftest/tools/testing/selftests/futex/functional/fu
>>> tex_requeue_pi.c:347:
>>> undefined reference to `pthread_join'
>>> /mnt/data/lkml/linux-kselftest/tools/testing/selftests/futex/functional/fu
>>> tex_requeue_pi.c:346:
>>> undefined reference to `pthread_join'
>>> collect2: error: ld returned 1 exit status
>>> <builtin>: recipe for target 'futex_requeue_pi' failed
>>> make[3]: *** [futex_requeue_pi] Error 1
>>> make[3]: Leaving directory
>>> '/mnt/data/lkml/linux-kselftest/tools/testing/selftests/futex/functional'
>>> Makefile:7: recipe for target 'all' failed
>>>
>>> I am running make kselftest target when I saw the above build failures.
>>> kselftest run doesn't fail which is good, however futex tests won't
>>> run with this failure.
>>
>> I have not seen these errors whilst developing with futextest for the
>> kernel. That looks like you may be missing the pthread development headers
>> from your build machine.
>>
>> Those are provided by libc6-dev on my Debian systems.
>>
>
> I do have lib6-dev installed. timers uses pthread compiles fine.
> So does mqueue. I am not sure what is going on with futex tests
> though. I am guessing it has to do with library link order.
>
> The following fixed it for me:
>
> -LDFLAGS := $(LDFLAGS) -lpthread -lrt
> +LDFLAGS := $(LDFLAGS) -pthread -lrt
>
> Could you please make this change and resend the patch series.
> I prefer patch series over pull request.
>
> thanks,
> -- Shuah
>
Sorry full diff:
diff --git a/tools/testing/selftests/futex/functional/Makefile
b/tools/testing/selftests/futex/functional/Makefile
index e64d43b..b8a2e9b 100644
--- a/tools/testing/selftests/futex/functional/Makefile
+++ b/tools/testing/selftests/futex/functional/Makefile
@@ -1,6 +1,6 @@
INCLUDES := -I../include -I../../
CFLAGS := $(CFLAGS) -g -O2 -Wall -D_GNU_SOURCE $(INCLUDES)
-LDFLAGS := $(LDFLAGS) -lpthread -lrt
+LDFLAGS := $(LDFLAGS) -pthread -lrt
-- Shuah
--
Shuah Khan
Sr. Linux Kernel Developer
Open Source Innovation Group
Samsung Research America (Silicon Valley)
shuahkh-JPH+aEBZ4P+UEJcrhfAQsw@public.gmane.org | (970) 217-8978
^ permalink raw reply related
* Re: [PATCH 1/5] selftests: Add futex functional tests
From: Shuah Khan @ 2015-05-11 22:21 UTC (permalink / raw)
To: Darren Hart, linux-api-u79uwXL29TY76Z2rM5mHXA,
Linux Kernel Mailing List
Cc: Ingo Molnar, Peter Zijlstra, Thomas Gleixner, Davidlohr Bueso,
KOSAKI Motohiro, Shuah Khan
In-Reply-To: <D17670E1.CC354%dvhart-VuQAYsv1563Yd54FQh9/CA@public.gmane.org>
On 05/11/2015 03:50 PM, Darren Hart wrote:
> On 5/11/15, 1:51 PM, "Shuah Khan" <shuahkh-JPH+aEBZ4P+UEJcrhfAQsw@public.gmane.org> wrote:
>
>> On 05/11/2015 01:47 PM, Darren Hart wrote:
>>> On 5/11/15, 11:55 AM, "Shuah Khan" <shuahkh-JPH+aEBZ4P+UEJcrhfAQsw@public.gmane.org> wrote:
>>>
>>>> On 05/11/2015 12:22 PM, Darren Hart wrote:
>>>>> On 5/11/15, 11:06 AM, "Shuah Khan" <shuahkh-JPH+aEBZ4P+UEJcrhfAQsw@public.gmane.org> wrote:
>>>>>
>>>>>> On 05/08/2015 04:09 PM, Darren Hart wrote:
>>>>>>> The futextest testsuite [1] provides functional, stress, and
>>>>>>> performance tests for the various futex op codes. Those tests will
>>>>>>> be
>>>>>>> of
>>>>>>> more use to futex developers if they are included with the kernel
>>>>>>> source.
>>>>>>>
>>>>>>> Copy the core infrastructure and the functional tests into
>>>>>>> selftests,
>>>>>>> but adapt them for inclusion in the kernel:
>>>>>>>
>>>>>>> - Update the Makefile to include the run_tests target, remove
>>>>>>> reference
>>>>>>> to the performance and stress tests from the contributed sources.
>>>>>>> - Replace my dead IBM email address with my current Intel email
>>>>>>> address.
>>>>>>> - Remove the warrantee and write-to paragraphs from the license
>>>>>>> blurbs.
>>>>>>> - Remove the NAME section as the filename is easily determined. ;-)
>>>>>>> - Make the whitespace usage consistent in a couple of places.
>>>>>>> - Cleanup various CodingStyle violations.
>>>>>>>
>>>>>>> A future effort will explore moving the performance and stress tests
>>>>>>> into the kernel.
>>>>>>>
>>>>>>> 1. http://git.kernel.org/cgit/linux/kernel/git/dvhart/futextest.git
>>>>>>>
>>>>>>> Cc: Shuah Khan <shuahkh-JPH+aEBZ4P+UEJcrhfAQsw@public.gmane.org>
>>>>>>> Cc: linux-api-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
>>>>>>> Cc: Ingo Molnar <mingo-X9Un+BFzKDI@public.gmane.org>
>>>>>>> Cc: Peter Zijlstra <peterz-wEGCiKHe2LqWVfeAwA7xHQ@public.gmane.org>
>>>>>>> Cc: Thomas Gleixner <tglx-hfZtesqFncYOwBW4kG4KsQ@public.gmane.org>
>>>>>>> Cc: Davidlohr Bueso <dave-h16yJtLeMjHk1uMJSBkQmQ@public.gmane.org>
>>>>>>> Cc: KOSAKI Motohiro <kosaki.motohiro-+CUm20s59erQFUHtdCDX3A@public.gmane.org>
>>>>>>> Signed-off-by: Darren Hart <dvhart-VuQAYsv1563Yd54FQh9/CA@public.gmane.org>
>>>>>>> ---
>>>>>>
>>>>>> Daren,
>>>>>>
>>>>>> I am seeing
>>>>>>
>>>>>> fatal: cannot convert from y to UTF-8
>>>>>>
>>>>>> when I try to apply the patch. Did you use git send-email?
>>>>>
>>>>> Hi Shuah,
>>>>>
>>>>> I've seen that from one of my contributors earlier this month as
>>>>> well. I
>>>>> dropped the Content... Header and it applied without problems.
>>>>>
>>>>> I created the patch using git format-patch and then sent them using
>>>>> git
>>>>> send-email - via a script I've been using for years now...
>>>>>
>>>>> Checking the files locally:
>>>>> $ file *
>>>>> 0000-cover-letter.patch: ASCII
>>>>> text
>>>>> 0001-selftests-Add-futex-functional-tests.patch:
>>>>> unified
>>>>> diff output, UTF-8 Unicode text
>>>>> 0002-selftest-futex-Update-Makefile-to-use-lib.mk.patch:
>>>>> unified
>>>>> diff output, ASCII text
>>>>> 0003-selftest-futex-Increment-ksft-pass-and-fail-counters.patch:
>>>>> unified
>>>>> diff output, ASCII text
>>>>> 0004-selftest-Add-futex-tests-to-the-top-level-Makefile.patch:
>>>>> unified
>>>>> diff output, ASCII text
>>>>> 0005-kselftest-Add-exit-code-defines.patch:
>>>>> unified
>>>>> diff output, ASCII text
>>>>>
>>>>>
>>>>> This shows that only the first in UTF-8 and the rest are ASCII. I
>>>>> presume
>>>>> this is due to the Copyright notices in the original files:
>>>>>
>>>>> Copyright © International Business Machines Corp., 2006-2008
>>>>>
>>>>> Which use © instead of (C). I just checked and there are 545 instances
>>>>> of
>>>>> © in the kernel itself, so this should not present a problem.
>>>>>
>>>>> I apologize for the glitch in applying. If you use the pull request I
>>>>> included that will avoid the mail transport issues, and I will be sure
>>>>> to
>>>>> fix my scripts to avoid the issue in the future.
>>>>>
>>>>> If you want to use the patches directly, please have a look at 1 of 5
>>>>> and
>>>>> just remove the "Content..." header, and I think you'll find "git am"
>>>>> will
>>>>> apply it without complaint.
>>>>>
>>>>
>>>> Hi Daren,
>>>>
>>>> Removing the Content header got me past the utf error. However, git am
>>>> complains:
>>>>
>>>> git am --signoff
>>>>
>>>> ../4.2_patches/futex_tests/PATCH_1_5selftestsAddfutexfunctionaltests.mbo
>>>> x
>>>> Applying: selftests: Add futex functional tests
>>>> /mnt/data/lkml/linux-kselftest/.git/rebase-apply/patch:1457: new blank
>>>> line at EOF.
>>>> +
>>>> warning: 1 line adds whitespace errors.
>>>>
>>>> Could you look into these. Rest of the patches applied fine.
>>>
>>> Hi Shuah,
>>>
>>> This was due to a newline at the end of:
>>> tools/testing/selftests/futex/functional/run.sh
>>>
>>> Which unfortunately checkpatch.pl doesn't catch. My fault for not
>>> applying
>>> the series from the generated patches first. Sorry for the hassle.
>>>
>>> I have corrected this in the first patch and pushed v3 of the series to:
>>>
>>> git://git.infradead.org/users/dvhart/linux.git futextest-v3
>>>
>>>
>>> $ git diff infradead/futextest-v2 infradead/futextest-v3
>>> diff --git a/tools/testing/selftests/futex/functional/run.sh
>>> b/tools/testing/selftests/futex/functional/run.sh
>>> index 46827a8..e87dbe2 100755
>>> --- a/tools/testing/selftests/futex/functional/run.sh
>>> +++ b/tools/testing/selftests/futex/functional/run.sh
>>> @@ -77,4 +77,3 @@ echo
>>> echo
>>> ./futex_wait_uninitialized_heap $COLOR
>>> ./futex_wait_private_mapped_file $COLOR
>>> -
>>>
>>>
>>
>> No need for a new pull request. Have you seen these errors before:
>>
>> make[2]: Entering directory
>> '/mnt/data/lkml/linux-kselftest/tools/testing/selftests/futex'
>> for DIR in functional; do make -C $DIR all ; done
>> make[3]: Entering directory
>> '/mnt/data/lkml/linux-kselftest/tools/testing/selftests/futex/functional'
>> gcc -g -O2 -Wall -D_GNU_SOURCE -I../include -I../../ -lpthread -lrt
>> futex_requeue_pi.c ../include/futextest.h -o futex_requeue_pi
>> /tmp/cc2UgUVs.o: In function `create_rt_thread':
>> /mnt/data/lkml/linux-kselftest/tools/testing/selftests/futex/functional/fu
>> tex_requeue_pi.c:102:
>> undefined reference to `pthread_create'
>> /tmp/cc2UgUVs.o: In function `unit_test':
>> /mnt/data/lkml/linux-kselftest/tools/testing/selftests/futex/functional/fu
>> tex_requeue_pi.c:342:
>> undefined reference to `pthread_join'
>> /mnt/data/lkml/linux-kselftest/tools/testing/selftests/futex/functional/fu
>> tex_requeue_pi.c:347:
>> undefined reference to `pthread_join'
>> /mnt/data/lkml/linux-kselftest/tools/testing/selftests/futex/functional/fu
>> tex_requeue_pi.c:346:
>> undefined reference to `pthread_join'
>> collect2: error: ld returned 1 exit status
>> <builtin>: recipe for target 'futex_requeue_pi' failed
>> make[3]: *** [futex_requeue_pi] Error 1
>> make[3]: Leaving directory
>> '/mnt/data/lkml/linux-kselftest/tools/testing/selftests/futex/functional'
>> Makefile:7: recipe for target 'all' failed
>>
>> I am running make kselftest target when I saw the above build failures.
>> kselftest run doesn't fail which is good, however futex tests won't
>> run with this failure.
>
> I have not seen these errors whilst developing with futextest for the
> kernel. That looks like you may be missing the pthread development headers
> from your build machine.
>
> Those are provided by libc6-dev on my Debian systems.
>
I do have lib6-dev installed. timers uses pthread compiles fine.
So does mqueue. I am not sure what is going on with futex tests
though. I am guessing it has to do with library link order.
The following fixed it for me:
-LDFLAGS := $(LDFLAGS) -lpthread -lrt
+LDFLAGS := $(LDFLAGS) -pthread -lrt
Could you please make this change and resend the patch series.
I prefer patch series over pull request.
thanks,
-- Shuah
thanks,
-- Shuah
--
Shuah Khan
Sr. Linux Kernel Developer
Open Source Innovation Group
Samsung Research America (Silicon Valley)
shuahkh-JPH+aEBZ4P+UEJcrhfAQsw@public.gmane.org | (970) 217-8978
^ permalink raw reply
* Re: [PATCH 0/6] support "dataplane" mode for nohz_full
From: Andy Lutomirski @ 2015-05-11 22:15 UTC (permalink / raw)
To: Chris Metcalf
Cc: Paul E. McKenney, Frederic Weisbecker,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
Rik van Riel, Andrew Morton, Linux API, Thomas Gleixner,
Tejun Heo, Peter Zijlstra, Steven Rostedt,
linux-doc-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
Christoph Lameter, Gilad Ben Yossef, Ingo Molnar
In-Reply-To: <555108FC.3060200-d5a29ZRxExrQT0dZR+AlfA@public.gmane.org>
On May 12, 2015 4:54 AM, "Chris Metcalf" <cmetcalf-d5a29ZRxExrQT0dZR+AlfA@public.gmane.org> wrote:
>
> (Oops, resending and forcing html off.)
>
>
> On 05/09/2015 03:19 AM, Andy Lutomirski wrote:
>>
>> Naming aside, I don't think this should be a per-task flag at all. We
>> already have way too much overhead per syscall in nohz mode, and it
>> would be nice to get the per-syscall overhead as low as possible. We
>> should strive, for all tasks, to keep syscall overhead down*and*
>> avoid as many interrupts as possible.
>>
>> That being said, I do see a legitimate use for a way to tell the
>> kernel "I'm going to run in userspace for a long time; stay away".
>> But shouldn't that be a single operation, not an ongoing flag? IOW, I
>> think that we should have a new syscall quiesce() or something rather
>> than a prctl.
>
>
> Yes, if all you are concerned about is quiescing the tick, we could
> probably do it as a new syscall.
>
> I do note that you'd want to try to actually do the quiesce as late as
> possible - in particular, if you just did it in the usual syscall, you
> might miss out on a timer that is set by softirq, or even something
> that happened when you called schedule() on the syscall exit path.
> Doing it as late as we are doing helps to ensure that that doesn't
> happen. We could still arrange for this semantics by having a new
> quiesce() syscall set a temporary task bit that was cleared on
> return to userspace, but as you pointed out in a different email,
> that gets tricky if you end up doing multiple user_exit() calls on
> your way back to userspace.
We should fix that, then. A quiesce() syscall can certainly arrange
to clean up on final exit.
>
> More to the point, I think it's actually important to know when an
> application believes it's in userspace-only mode as an actual state
> bit, rather than just during its transitional moment.
We can do that, too, with a new flag that's cleared on the next entry.
> If an
> application calls the kernel at an unexpected time (third-party code
> is the usual culprit for our customers, whether it's syscalls, page
> faults, or other things) we would prefer to have the "quiesce"
> semantics stay in force and cause the third-party code to be
> visibly very slow, rather than cause a totally unexpected and
> hard-to-diagnose interrupt show up later as we are still going
> around the loop that we thought was safely userspace-only.
I'm not really convinced that we should design this feature around
ease of debugging userspace screwups. There are already plenty of
ways to do that part. Userspace getting an interrupt because
userspace accidentally did a syscall is very different from userspace
getting interrupted due to an IPI.
>
> And, for debugging the kernel, it's crazy helpful to have that state
> bit in place: see patch 6/6 in the series for how we can diagnose
> things like "a different core just queued an IPI that will hit a
> dataplane core unexpectedly". Having that state bit makes this sort
> of thing a trivial check in the kernel and relatively easy to debug.
As above, this can be done with a one-time operation, too.
>
> Finally, I proposed a "strict" mode in patch 5/6 where we kill the
> process if it voluntarily enters the kernel by mistake after saying it
> wasn't going to any more. To do this requires a state bit, so
> carrying another state bit for "quiesce on user entry" seems pretty
> reasonable.
I still dislike that in the form you chose. It's too deadly to be
useful for anyone but the hardest RT users.
I think I'd be okay with variants, though: let a suitably privileged
process ask for a signal on inadvertent kernel entry or rig up an fd
to be notified when one of these bad entries happens. Queueing
something to a pollable fd would work, too.
See that thread for more comments.
--Andy
^ permalink raw reply
* Re: [PATCH 1/5] selftests: Add futex functional tests
From: Darren Hart @ 2015-05-11 21:50 UTC (permalink / raw)
To: Shuah Khan, linux-api-u79uwXL29TY76Z2rM5mHXA,
Linux Kernel Mailing List
Cc: Ingo Molnar, Peter Zijlstra, Thomas Gleixner, Davidlohr Bueso,
KOSAKI Motohiro
In-Reply-To: <5551164E.5080409-JPH+aEBZ4P+UEJcrhfAQsw@public.gmane.org>
On 5/11/15, 1:51 PM, "Shuah Khan" <shuahkh-JPH+aEBZ4P+UEJcrhfAQsw@public.gmane.org> wrote:
>On 05/11/2015 01:47 PM, Darren Hart wrote:
>> On 5/11/15, 11:55 AM, "Shuah Khan" <shuahkh-JPH+aEBZ4P+UEJcrhfAQsw@public.gmane.org> wrote:
>>
>>> On 05/11/2015 12:22 PM, Darren Hart wrote:
>>>> On 5/11/15, 11:06 AM, "Shuah Khan" <shuahkh-JPH+aEBZ4P+UEJcrhfAQsw@public.gmane.org> wrote:
>>>>
>>>>> On 05/08/2015 04:09 PM, Darren Hart wrote:
>>>>>> The futextest testsuite [1] provides functional, stress, and
>>>>>> performance tests for the various futex op codes. Those tests will
>>>>>>be
>>>>>> of
>>>>>> more use to futex developers if they are included with the kernel
>>>>>> source.
>>>>>>
>>>>>> Copy the core infrastructure and the functional tests into
>>>>>>selftests,
>>>>>> but adapt them for inclusion in the kernel:
>>>>>>
>>>>>> - Update the Makefile to include the run_tests target, remove
>>>>>> reference
>>>>>> to the performance and stress tests from the contributed sources.
>>>>>> - Replace my dead IBM email address with my current Intel email
>>>>>> address.
>>>>>> - Remove the warrantee and write-to paragraphs from the license
>>>>>> blurbs.
>>>>>> - Remove the NAME section as the filename is easily determined. ;-)
>>>>>> - Make the whitespace usage consistent in a couple of places.
>>>>>> - Cleanup various CodingStyle violations.
>>>>>>
>>>>>> A future effort will explore moving the performance and stress tests
>>>>>> into the kernel.
>>>>>>
>>>>>> 1. http://git.kernel.org/cgit/linux/kernel/git/dvhart/futextest.git
>>>>>>
>>>>>> Cc: Shuah Khan <shuahkh-JPH+aEBZ4P+UEJcrhfAQsw@public.gmane.org>
>>>>>> Cc: linux-api-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
>>>>>> Cc: Ingo Molnar <mingo-X9Un+BFzKDI@public.gmane.org>
>>>>>> Cc: Peter Zijlstra <peterz-wEGCiKHe2LqWVfeAwA7xHQ@public.gmane.org>
>>>>>> Cc: Thomas Gleixner <tglx-hfZtesqFncYOwBW4kG4KsQ@public.gmane.org>
>>>>>> Cc: Davidlohr Bueso <dave-h16yJtLeMjHk1uMJSBkQmQ@public.gmane.org>
>>>>>> Cc: KOSAKI Motohiro <kosaki.motohiro-+CUm20s59erQFUHtdCDX3A@public.gmane.org>
>>>>>> Signed-off-by: Darren Hart <dvhart-VuQAYsv1563Yd54FQh9/CA@public.gmane.org>
>>>>>> ---
>>>>>
>>>>> Daren,
>>>>>
>>>>> I am seeing
>>>>>
>>>>> fatal: cannot convert from y to UTF-8
>>>>>
>>>>> when I try to apply the patch. Did you use git send-email?
>>>>
>>>> Hi Shuah,
>>>>
>>>> I've seen that from one of my contributors earlier this month as
>>>>well. I
>>>> dropped the Content... Header and it applied without problems.
>>>>
>>>> I created the patch using git format-patch and then sent them using
>>>>git
>>>> send-email - via a script I've been using for years now...
>>>>
>>>> Checking the files locally:
>>>> $ file *
>>>> 0000-cover-letter.patch: ASCII
>>>> text
>>>> 0001-selftests-Add-futex-functional-tests.patch:
>>>>unified
>>>> diff output, UTF-8 Unicode text
>>>> 0002-selftest-futex-Update-Makefile-to-use-lib.mk.patch:
>>>>unified
>>>> diff output, ASCII text
>>>> 0003-selftest-futex-Increment-ksft-pass-and-fail-counters.patch:
>>>>unified
>>>> diff output, ASCII text
>>>> 0004-selftest-Add-futex-tests-to-the-top-level-Makefile.patch:
>>>>unified
>>>> diff output, ASCII text
>>>> 0005-kselftest-Add-exit-code-defines.patch:
>>>>unified
>>>> diff output, ASCII text
>>>>
>>>>
>>>> This shows that only the first in UTF-8 and the rest are ASCII. I
>>>> presume
>>>> this is due to the Copyright notices in the original files:
>>>>
>>>> Copyright © International Business Machines Corp., 2006-2008
>>>>
>>>> Which use © instead of (C). I just checked and there are 545 instances
>>>> of
>>>> © in the kernel itself, so this should not present a problem.
>>>>
>>>> I apologize for the glitch in applying. If you use the pull request I
>>>> included that will avoid the mail transport issues, and I will be sure
>>>> to
>>>> fix my scripts to avoid the issue in the future.
>>>>
>>>> If you want to use the patches directly, please have a look at 1 of 5
>>>> and
>>>> just remove the "Content..." header, and I think you'll find "git am"
>>>> will
>>>> apply it without complaint.
>>>>
>>>
>>> Hi Daren,
>>>
>>> Removing the Content header got me past the utf error. However, git am
>>> complains:
>>>
>>> git am --signoff
>>>
>>>../4.2_patches/futex_tests/PATCH_1_5selftestsAddfutexfunctionaltests.mbo
>>>x
>>> Applying: selftests: Add futex functional tests
>>> /mnt/data/lkml/linux-kselftest/.git/rebase-apply/patch:1457: new blank
>>> line at EOF.
>>> +
>>> warning: 1 line adds whitespace errors.
>>>
>>> Could you look into these. Rest of the patches applied fine.
>>
>> Hi Shuah,
>>
>> This was due to a newline at the end of:
>> tools/testing/selftests/futex/functional/run.sh
>>
>> Which unfortunately checkpatch.pl doesn't catch. My fault for not
>>applying
>> the series from the generated patches first. Sorry for the hassle.
>>
>> I have corrected this in the first patch and pushed v3 of the series to:
>>
>> git://git.infradead.org/users/dvhart/linux.git futextest-v3
>>
>>
>> $ git diff infradead/futextest-v2 infradead/futextest-v3
>> diff --git a/tools/testing/selftests/futex/functional/run.sh
>> b/tools/testing/selftests/futex/functional/run.sh
>> index 46827a8..e87dbe2 100755
>> --- a/tools/testing/selftests/futex/functional/run.sh
>> +++ b/tools/testing/selftests/futex/functional/run.sh
>> @@ -77,4 +77,3 @@ echo
>> echo
>> ./futex_wait_uninitialized_heap $COLOR
>> ./futex_wait_private_mapped_file $COLOR
>> -
>>
>>
>
>No need for a new pull request. Have you seen these errors before:
>
>make[2]: Entering directory
>'/mnt/data/lkml/linux-kselftest/tools/testing/selftests/futex'
>for DIR in functional; do make -C $DIR all ; done
>make[3]: Entering directory
>'/mnt/data/lkml/linux-kselftest/tools/testing/selftests/futex/functional'
>gcc -g -O2 -Wall -D_GNU_SOURCE -I../include -I../../ -lpthread -lrt
>futex_requeue_pi.c ../include/futextest.h -o futex_requeue_pi
>/tmp/cc2UgUVs.o: In function `create_rt_thread':
>/mnt/data/lkml/linux-kselftest/tools/testing/selftests/futex/functional/fu
>tex_requeue_pi.c:102:
>undefined reference to `pthread_create'
>/tmp/cc2UgUVs.o: In function `unit_test':
>/mnt/data/lkml/linux-kselftest/tools/testing/selftests/futex/functional/fu
>tex_requeue_pi.c:342:
>undefined reference to `pthread_join'
>/mnt/data/lkml/linux-kselftest/tools/testing/selftests/futex/functional/fu
>tex_requeue_pi.c:347:
>undefined reference to `pthread_join'
>/mnt/data/lkml/linux-kselftest/tools/testing/selftests/futex/functional/fu
>tex_requeue_pi.c:346:
>undefined reference to `pthread_join'
>collect2: error: ld returned 1 exit status
><builtin>: recipe for target 'futex_requeue_pi' failed
>make[3]: *** [futex_requeue_pi] Error 1
>make[3]: Leaving directory
>'/mnt/data/lkml/linux-kselftest/tools/testing/selftests/futex/functional'
>Makefile:7: recipe for target 'all' failed
>
>I am running make kselftest target when I saw the above build failures.
>kselftest run doesn't fail which is good, however futex tests won't
>run with this failure.
I have not seen these errors whilst developing with futextest for the
kernel. That looks like you may be missing the pthread development headers
from your build machine.
Those are provided by libc6-dev on my Debian systems.
--
Darren Hart
Intel Open Source Technology Center
^ permalink raw reply
* Re: [PATCH 0/3] Allow user to request memory to be locked on page fault
From: Eric B Munson @ 2015-05-11 21:05 UTC (permalink / raw)
To: Andrew Morton
Cc: Shuah Khan, linux-alpha, linux-kernel, linux-mips, linux-parisc,
linuxppc-dev, sparclinux, linux-xtensa, linux-mm, linux-arch,
linux-api
In-Reply-To: <20150511121204.2af73429ad3c29b6d67f1345@linux-foundation.org>
[-- Attachment #1: Type: text/plain, Size: 2059 bytes --]
On Mon, 11 May 2015, Andrew Morton wrote:
> On Mon, 11 May 2015 10:36:18 -0400 Eric B Munson <emunson@akamai.com> wrote:
>
> > On Fri, 08 May 2015, Andrew Morton wrote:
> > ...
> >
> > >
> > > Why can't the application mmap only those parts of the file which it
> > > wants and mlock those?
> >
> > There are a number of problems with this approach. The first is it
> > presumes the program will know what portions are needed a head of time.
> > In many cases this is simply not true. The second problem is the number
> > of syscalls required. With my patches, a single mmap() or mlockall()
> > call is needed to setup the required locking. Without it, a separate
> > mmap call must be made for each piece of data that is needed. This also
> > opens up problems for data that is arranged assuming it is contiguous in
> > memory. With the single mmap call, the user gets a contiguous VMA
> > without having to know about it. mmap() with MAP_FIXED could address
> > the problem, but this introduces a new failure mode of your map
> > colliding with another that was placed by the kernel.
> >
> > Another use case for the LOCKONFAULT flag is the security use of
> > mlock(). If an application will be using data that cannot be written
> > to swap, but the exact size is unknown until run time (all we have a
> > build time is the maximum size the buffer can be). The LOCKONFAULT flag
> > allows the developer to create the buffer and guarantee that the
> > contents are never written to swap without ever consuming more memory
> > than is actually needed.
>
> What application(s) or class of applications are we talking about here?
>
> IOW, how generally applicable is this? It sounds rather specialized.
>
For the example of a large file, this is the usage pattern for a large
statical language model (probably applies to other statical or graphical
models as well). For the security example, any application transacting
in data that cannot be swapped out (credit card data, medical records,
etc).
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* Re: [PATCH 1/5] selftests: Add futex functional tests
From: Shuah Khan @ 2015-05-11 20:51 UTC (permalink / raw)
To: Darren Hart, linux-api-u79uwXL29TY76Z2rM5mHXA,
Linux Kernel Mailing List
Cc: Ingo Molnar, Peter Zijlstra, Thomas Gleixner, Davidlohr Bueso,
KOSAKI Motohiro, Shuah Khan
In-Reply-To: <D17653E0.CC29F%dvhart-VuQAYsv1563Yd54FQh9/CA@public.gmane.org>
On 05/11/2015 01:47 PM, Darren Hart wrote:
> On 5/11/15, 11:55 AM, "Shuah Khan" <shuahkh-JPH+aEBZ4P+UEJcrhfAQsw@public.gmane.org> wrote:
>
>> On 05/11/2015 12:22 PM, Darren Hart wrote:
>>> On 5/11/15, 11:06 AM, "Shuah Khan" <shuahkh-JPH+aEBZ4P+UEJcrhfAQsw@public.gmane.org> wrote:
>>>
>>>> On 05/08/2015 04:09 PM, Darren Hart wrote:
>>>>> The futextest testsuite [1] provides functional, stress, and
>>>>> performance tests for the various futex op codes. Those tests will be
>>>>> of
>>>>> more use to futex developers if they are included with the kernel
>>>>> source.
>>>>>
>>>>> Copy the core infrastructure and the functional tests into selftests,
>>>>> but adapt them for inclusion in the kernel:
>>>>>
>>>>> - Update the Makefile to include the run_tests target, remove
>>>>> reference
>>>>> to the performance and stress tests from the contributed sources.
>>>>> - Replace my dead IBM email address with my current Intel email
>>>>> address.
>>>>> - Remove the warrantee and write-to paragraphs from the license
>>>>> blurbs.
>>>>> - Remove the NAME section as the filename is easily determined. ;-)
>>>>> - Make the whitespace usage consistent in a couple of places.
>>>>> - Cleanup various CodingStyle violations.
>>>>>
>>>>> A future effort will explore moving the performance and stress tests
>>>>> into the kernel.
>>>>>
>>>>> 1. http://git.kernel.org/cgit/linux/kernel/git/dvhart/futextest.git
>>>>>
>>>>> Cc: Shuah Khan <shuahkh-JPH+aEBZ4P+UEJcrhfAQsw@public.gmane.org>
>>>>> Cc: linux-api-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
>>>>> Cc: Ingo Molnar <mingo-X9Un+BFzKDI@public.gmane.org>
>>>>> Cc: Peter Zijlstra <peterz-wEGCiKHe2LqWVfeAwA7xHQ@public.gmane.org>
>>>>> Cc: Thomas Gleixner <tglx-hfZtesqFncYOwBW4kG4KsQ@public.gmane.org>
>>>>> Cc: Davidlohr Bueso <dave-h16yJtLeMjHk1uMJSBkQmQ@public.gmane.org>
>>>>> Cc: KOSAKI Motohiro <kosaki.motohiro-+CUm20s59erQFUHtdCDX3A@public.gmane.org>
>>>>> Signed-off-by: Darren Hart <dvhart-VuQAYsv1563Yd54FQh9/CA@public.gmane.org>
>>>>> ---
>>>>
>>>> Daren,
>>>>
>>>> I am seeing
>>>>
>>>> fatal: cannot convert from y to UTF-8
>>>>
>>>> when I try to apply the patch. Did you use git send-email?
>>>
>>> Hi Shuah,
>>>
>>> I've seen that from one of my contributors earlier this month as well. I
>>> dropped the Content... Header and it applied without problems.
>>>
>>> I created the patch using git format-patch and then sent them using git
>>> send-email - via a script I've been using for years now...
>>>
>>> Checking the files locally:
>>> $ file *
>>> 0000-cover-letter.patch: ASCII
>>> text
>>> 0001-selftests-Add-futex-functional-tests.patch: unified
>>> diff output, UTF-8 Unicode text
>>> 0002-selftest-futex-Update-Makefile-to-use-lib.mk.patch: unified
>>> diff output, ASCII text
>>> 0003-selftest-futex-Increment-ksft-pass-and-fail-counters.patch: unified
>>> diff output, ASCII text
>>> 0004-selftest-Add-futex-tests-to-the-top-level-Makefile.patch: unified
>>> diff output, ASCII text
>>> 0005-kselftest-Add-exit-code-defines.patch: unified
>>> diff output, ASCII text
>>>
>>>
>>> This shows that only the first in UTF-8 and the rest are ASCII. I
>>> presume
>>> this is due to the Copyright notices in the original files:
>>>
>>> Copyright © International Business Machines Corp., 2006-2008
>>>
>>> Which use © instead of (C). I just checked and there are 545 instances
>>> of
>>> © in the kernel itself, so this should not present a problem.
>>>
>>> I apologize for the glitch in applying. If you use the pull request I
>>> included that will avoid the mail transport issues, and I will be sure
>>> to
>>> fix my scripts to avoid the issue in the future.
>>>
>>> If you want to use the patches directly, please have a look at 1 of 5
>>> and
>>> just remove the "Content..." header, and I think you'll find "git am"
>>> will
>>> apply it without complaint.
>>>
>>
>> Hi Daren,
>>
>> Removing the Content header got me past the utf error. However, git am
>> complains:
>>
>> git am --signoff
>> ../4.2_patches/futex_tests/PATCH_1_5selftestsAddfutexfunctionaltests.mbox
>> Applying: selftests: Add futex functional tests
>> /mnt/data/lkml/linux-kselftest/.git/rebase-apply/patch:1457: new blank
>> line at EOF.
>> +
>> warning: 1 line adds whitespace errors.
>>
>> Could you look into these. Rest of the patches applied fine.
>
> Hi Shuah,
>
> This was due to a newline at the end of:
> tools/testing/selftests/futex/functional/run.sh
>
> Which unfortunately checkpatch.pl doesn't catch. My fault for not applying
> the series from the generated patches first. Sorry for the hassle.
>
> I have corrected this in the first patch and pushed v3 of the series to:
>
> git://git.infradead.org/users/dvhart/linux.git futextest-v3
>
>
> $ git diff infradead/futextest-v2 infradead/futextest-v3
> diff --git a/tools/testing/selftests/futex/functional/run.sh
> b/tools/testing/selftests/futex/functional/run.sh
> index 46827a8..e87dbe2 100755
> --- a/tools/testing/selftests/futex/functional/run.sh
> +++ b/tools/testing/selftests/futex/functional/run.sh
> @@ -77,4 +77,3 @@ echo
> echo
> ./futex_wait_uninitialized_heap $COLOR
> ./futex_wait_private_mapped_file $COLOR
> -
>
>
No need for a new pull request. Have you seen these errors before:
make[2]: Entering directory
'/mnt/data/lkml/linux-kselftest/tools/testing/selftests/futex'
for DIR in functional; do make -C $DIR all ; done
make[3]: Entering directory
'/mnt/data/lkml/linux-kselftest/tools/testing/selftests/futex/functional'
gcc -g -O2 -Wall -D_GNU_SOURCE -I../include -I../../ -lpthread -lrt
futex_requeue_pi.c ../include/futextest.h -o futex_requeue_pi
/tmp/cc2UgUVs.o: In function `create_rt_thread':
/mnt/data/lkml/linux-kselftest/tools/testing/selftests/futex/functional/futex_requeue_pi.c:102:
undefined reference to `pthread_create'
/tmp/cc2UgUVs.o: In function `unit_test':
/mnt/data/lkml/linux-kselftest/tools/testing/selftests/futex/functional/futex_requeue_pi.c:342:
undefined reference to `pthread_join'
/mnt/data/lkml/linux-kselftest/tools/testing/selftests/futex/functional/futex_requeue_pi.c:347:
undefined reference to `pthread_join'
/mnt/data/lkml/linux-kselftest/tools/testing/selftests/futex/functional/futex_requeue_pi.c:346:
undefined reference to `pthread_join'
collect2: error: ld returned 1 exit status
<builtin>: recipe for target 'futex_requeue_pi' failed
make[3]: *** [futex_requeue_pi] Error 1
make[3]: Leaving directory
'/mnt/data/lkml/linux-kselftest/tools/testing/selftests/futex/functional'
Makefile:7: recipe for target 'all' failed
I am running make kselftest target when I saw the above build failures.
kselftest run doesn't fail which is good, however futex tests won't
run with this failure.
thanks,
-- Shuah
--
Shuah Khan
Sr. Linux Kernel Developer
Open Source Innovation Group
Samsung Research America (Silicon Valley)
shuahkh-JPH+aEBZ4P+UEJcrhfAQsw@public.gmane.org | (970) 217-8978
^ permalink raw reply
* Re: [PATCH RFC] vfs: add a O_NOMTIME flag
From: J. Bruce Fields @ 2015-05-11 20:36 UTC (permalink / raw)
To: Eric Sandeen
Cc: Andy Lutomirski, Dave Chinner, Al Viro, Sage Weil, Linux API,
Linux FS Devel, linux-kernel@vger.kernel.org, Zach Brown
In-Reply-To: <554CCBC9.3070706@sandeen.net>
On Fri, May 08, 2015 at 09:44:25AM -0500, Eric Sandeen wrote:
> On 5/7/15 10:24 PM, Andy Lutomirski wrote:
> > On May 8, 2015 8:11 AM, "Dave Chinner" <david@fromorbit.com> wrote:
> >>
> >> On Thu, May 07, 2015 at 10:20:53AM -0700, Zach Brown wrote:
> >>> On Thu, May 07, 2015 at 10:26:17AM +1000, Dave Chinner wrote:
> >>>> On Wed, May 06, 2015 at 03:00:12PM -0700, Zach Brown wrote:
> >>>>> Add the O_NOMTIME flag which prevents mtime from being updated which can
> >>>>> greatly reduce the IO overhead of writes to allocated and initialized
> >>>>> regions of files.
> >>>>
> >>>> Hmmm. How do backup programs now work out if the file has changed
> >>>> and hence needs copying again? ie. applications using this will
> >>>> break other critical infrastructure in subtle ways.
> >>>
> >>> By using backup infrastructure that doesn't use cmtime. Like btrfs
> >>> send/recv. Or application level backups that know how to do
> >>> incrementals from metadata in giant database files, say, without
> >>> walking, comparing, and copying the entire thing.
> >>
> >> "Use magical thing that doesn't exist"? Really?
> >>
> >> e.g. you can't do incremental backups with tools like xfsdump if
> >> mtime is not being updated. The last thing an admin wants when
> >> doing disaster recovery is to find out that the app started using
> >> O_NOMTIME as a result of the upgrade they did 6 months ago. Hence
> >> the last 6 months of production data isn't in the backups despite
> >> the backup procedure having been extensively tested and verified
> >> when it was first put in place.
> >>
> >>>>> The criteria for using O_NOMTIME is the same as for using O_NOATIME:
> >>>>> owning the file or having the CAP_FOWNER capability. If we're not
> >>>>> comfortable allowing owners to prevent mtime/ctime updates then we
> >>>>> should add a tunable to allow O_NOMTIME. Maybe a mount option?
> >>>>
> >>>> I dislike "turn off safety for performance" options because Joe
> >>>> SpeedRacer will always select performance over safety.
> >>>
> >>> Well, for ceph there's no safety concern. They never use cmtime in
> >>> these files.
> >>
> >> Understood.
> >>
> >>> So are you suggesting not implementing this
> >>
> >> No.
> >>
> >>> Or are we talking about adding some speed bumps
> >>> that ceph can flip on that might give Joe Speedracer pause?
> >>
> >> Yes, but not just Joe Speedracer - if it can be turned on silently
> >> by apps then it's a great big landmine that most users and sysadmins
> >> will not know about until it is too late.
> >
> > What about programs like tar that explicitly override mtime? No admin
> > buy-in is required for that. Admittedly, that doesn't affect ctime,
> > nor is it as likely to bite unexpectedly as a nomtime flag.
> >
> > I think it would be reasonably safe if a mount option had to be set to
> > allow O_NOCMTIME or such.
>
> I was going to suggest the same. Make infrastructure available for an app
> to request O_NOMTIME, but a mount option must be set to allow it, so the
> administrator doesn't get an unhappy surprise at backup-restore time.
>
> (Not a big fan of more twiddly knobs, but that seems to put the control
> in all the right places).
It seems more like a permanent feature of the filesystem than a
per-mount option: once you've turned off mtime updates you lose
information that can't be regained after remounting. A mkfs option
might make more sense? But I guess those aren't very generic.
(I do hope we can get an O_NOMTIME flag, it will make me smile every
time I see it....)
--b.
^ permalink raw reply
* Re: [PATCH 0/6] support "dataplane" mode for nohz_full
From: Chris Metcalf @ 2015-05-11 19:54 UTC (permalink / raw)
To: Andy Lutomirski, Ingo Molnar
Cc: Andrew Morton, Steven Rostedt, Gilad Ben Yossef, Peter Zijlstra,
Rik van Riel, Tejun Heo, Frederic Weisbecker, Thomas Gleixner,
Paul E. McKenney, Christoph Lameter,
linux-doc-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Linux API,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
In-Reply-To: <CALCETrXavog018+xLacXeBLaMLjWtqk0bMU5fUzZ+pkwgu7Y3A-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
(Oops, resending and forcing html off.)
On 05/09/2015 03:19 AM, Andy Lutomirski wrote:
> Naming aside, I don't think this should be a per-task flag at all. We
> already have way too much overhead per syscall in nohz mode, and it
> would be nice to get the per-syscall overhead as low as possible. We
> should strive, for all tasks, to keep syscall overhead down*and*
> avoid as many interrupts as possible.
>
> That being said, I do see a legitimate use for a way to tell the
> kernel "I'm going to run in userspace for a long time; stay away".
> But shouldn't that be a single operation, not an ongoing flag? IOW, I
> think that we should have a new syscall quiesce() or something rather
> than a prctl.
Yes, if all you are concerned about is quiescing the tick, we could
probably do it as a new syscall.
I do note that you'd want to try to actually do the quiesce as late as
possible - in particular, if you just did it in the usual syscall, you
might miss out on a timer that is set by softirq, or even something
that happened when you called schedule() on the syscall exit path.
Doing it as late as we are doing helps to ensure that that doesn't
happen. We could still arrange for this semantics by having a new
quiesce() syscall set a temporary task bit that was cleared on
return to userspace, but as you pointed out in a different email,
that gets tricky if you end up doing multiple user_exit() calls on
your way back to userspace.
More to the point, I think it's actually important to know when an
application believes it's in userspace-only mode as an actual state
bit, rather than just during its transitional moment. If an
application calls the kernel at an unexpected time (third-party code
is the usual culprit for our customers, whether it's syscalls, page
faults, or other things) we would prefer to have the "quiesce"
semantics stay in force and cause the third-party code to be
visibly very slow, rather than cause a totally unexpected and
hard-to-diagnose interrupt show up later as we are still going
around the loop that we thought was safely userspace-only.
And, for debugging the kernel, it's crazy helpful to have that state
bit in place: see patch 6/6 in the series for how we can diagnose
things like "a different core just queued an IPI that will hit a
dataplane core unexpectedly". Having that state bit makes this sort
of thing a trivial check in the kernel and relatively easy to debug.
Finally, I proposed a "strict" mode in patch 5/6 where we kill the
process if it voluntarily enters the kernel by mistake after saying it
wasn't going to any more. To do this requires a state bit, so
carrying another state bit for "quiesce on user entry" seems pretty
reasonable.
--
Chris Metcalf, EZChip Semiconductor
http://www.ezchip.com
^ permalink raw reply
* Re: [PATCH 1/5] selftests: Add futex functional tests
From: Darren Hart @ 2015-05-11 19:47 UTC (permalink / raw)
To: Shuah Khan, linux-api-u79uwXL29TY76Z2rM5mHXA,
Linux Kernel Mailing List
Cc: Ingo Molnar, Peter Zijlstra, Thomas Gleixner, Davidlohr Bueso,
KOSAKI Motohiro
In-Reply-To: <5550FB2C.1000403-JPH+aEBZ4P+UEJcrhfAQsw@public.gmane.org>
On 5/11/15, 11:55 AM, "Shuah Khan" <shuahkh-JPH+aEBZ4P+UEJcrhfAQsw@public.gmane.org> wrote:
>On 05/11/2015 12:22 PM, Darren Hart wrote:
>> On 5/11/15, 11:06 AM, "Shuah Khan" <shuahkh-JPH+aEBZ4P+UEJcrhfAQsw@public.gmane.org> wrote:
>>
>>> On 05/08/2015 04:09 PM, Darren Hart wrote:
>>>> The futextest testsuite [1] provides functional, stress, and
>>>> performance tests for the various futex op codes. Those tests will be
>>>>of
>>>> more use to futex developers if they are included with the kernel
>>>> source.
>>>>
>>>> Copy the core infrastructure and the functional tests into selftests,
>>>> but adapt them for inclusion in the kernel:
>>>>
>>>> - Update the Makefile to include the run_tests target, remove
>>>>reference
>>>> to the performance and stress tests from the contributed sources.
>>>> - Replace my dead IBM email address with my current Intel email
>>>>address.
>>>> - Remove the warrantee and write-to paragraphs from the license
>>>>blurbs.
>>>> - Remove the NAME section as the filename is easily determined. ;-)
>>>> - Make the whitespace usage consistent in a couple of places.
>>>> - Cleanup various CodingStyle violations.
>>>>
>>>> A future effort will explore moving the performance and stress tests
>>>> into the kernel.
>>>>
>>>> 1. http://git.kernel.org/cgit/linux/kernel/git/dvhart/futextest.git
>>>>
>>>> Cc: Shuah Khan <shuahkh-JPH+aEBZ4P+UEJcrhfAQsw@public.gmane.org>
>>>> Cc: linux-api-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
>>>> Cc: Ingo Molnar <mingo-X9Un+BFzKDI@public.gmane.org>
>>>> Cc: Peter Zijlstra <peterz-wEGCiKHe2LqWVfeAwA7xHQ@public.gmane.org>
>>>> Cc: Thomas Gleixner <tglx-hfZtesqFncYOwBW4kG4KsQ@public.gmane.org>
>>>> Cc: Davidlohr Bueso <dave-h16yJtLeMjHk1uMJSBkQmQ@public.gmane.org>
>>>> Cc: KOSAKI Motohiro <kosaki.motohiro-+CUm20s59erQFUHtdCDX3A@public.gmane.org>
>>>> Signed-off-by: Darren Hart <dvhart-VuQAYsv1563Yd54FQh9/CA@public.gmane.org>
>>>> ---
>>>
>>> Daren,
>>>
>>> I am seeing
>>>
>>> fatal: cannot convert from y to UTF-8
>>>
>>> when I try to apply the patch. Did you use git send-email?
>>
>> Hi Shuah,
>>
>> I've seen that from one of my contributors earlier this month as well. I
>> dropped the Content... Header and it applied without problems.
>>
>> I created the patch using git format-patch and then sent them using git
>> send-email - via a script I've been using for years now...
>>
>> Checking the files locally:
>> $ file *
>> 0000-cover-letter.patch: ASCII
>>text
>> 0001-selftests-Add-futex-functional-tests.patch: unified
>> diff output, UTF-8 Unicode text
>> 0002-selftest-futex-Update-Makefile-to-use-lib.mk.patch: unified
>> diff output, ASCII text
>> 0003-selftest-futex-Increment-ksft-pass-and-fail-counters.patch: unified
>> diff output, ASCII text
>> 0004-selftest-Add-futex-tests-to-the-top-level-Makefile.patch: unified
>> diff output, ASCII text
>> 0005-kselftest-Add-exit-code-defines.patch: unified
>> diff output, ASCII text
>>
>>
>> This shows that only the first in UTF-8 and the rest are ASCII. I
>>presume
>> this is due to the Copyright notices in the original files:
>>
>> Copyright © International Business Machines Corp., 2006-2008
>>
>> Which use © instead of (C). I just checked and there are 545 instances
>>of
>> © in the kernel itself, so this should not present a problem.
>>
>> I apologize for the glitch in applying. If you use the pull request I
>> included that will avoid the mail transport issues, and I will be sure
>>to
>> fix my scripts to avoid the issue in the future.
>>
>> If you want to use the patches directly, please have a look at 1 of 5
>>and
>> just remove the "Content..." header, and I think you'll find "git am"
>>will
>> apply it without complaint.
>>
>
>Hi Daren,
>
>Removing the Content header got me past the utf error. However, git am
>complains:
>
>git am --signoff
>../4.2_patches/futex_tests/PATCH_1_5selftestsAddfutexfunctionaltests.mbox
>Applying: selftests: Add futex functional tests
>/mnt/data/lkml/linux-kselftest/.git/rebase-apply/patch:1457: new blank
>line at EOF.
>+
>warning: 1 line adds whitespace errors.
>
>Could you look into these. Rest of the patches applied fine.
Hi Shuah,
This was due to a newline at the end of:
tools/testing/selftests/futex/functional/run.sh
Which unfortunately checkpatch.pl doesn't catch. My fault for not applying
the series from the generated patches first. Sorry for the hassle.
I have corrected this in the first patch and pushed v3 of the series to:
git://git.infradead.org/users/dvhart/linux.git futextest-v3
$ git diff infradead/futextest-v2 infradead/futextest-v3
diff --git a/tools/testing/selftests/futex/functional/run.sh
b/tools/testing/selftests/futex/functional/run.sh
index 46827a8..e87dbe2 100755
--- a/tools/testing/selftests/futex/functional/run.sh
+++ b/tools/testing/selftests/futex/functional/run.sh
@@ -77,4 +77,3 @@ echo
echo
./futex_wait_uninitialized_heap $COLOR
./futex_wait_private_mapped_file $COLOR
-
Is this sufficient or do would you prefer a new pull request?
Thanks,
--
Darren Hart
Intel Open Source Technology Center
^ permalink raw reply related
* Re: [PATCH 1/2] clone: Support passing tls argument via C rather than pt_regs magic
From: Josh Triplett @ 2015-05-11 19:30 UTC (permalink / raw)
To: Ingo Molnar
Cc: Thomas Gleixner, Andy Lutomirski, Ingo Molnar, H. Peter Anvin,
Peter Zijlstra, Linus Torvalds, linux-api, linux-kernel, x86
In-Reply-To: <20150511140043.GB5354@gmail.com>
On Mon, May 11, 2015 at 04:00:43PM +0200, Ingo Molnar wrote:
>
> * Josh Triplett <josh@joshtriplett.org> wrote:
>
> > On Mon, May 11, 2015 at 12:13:13PM +0200, Ingo Molnar wrote:
> > >
> > > * josh@joshtriplett.org <josh@joshtriplett.org> wrote:
> > >
> > > > On Tue, May 05, 2015 at 08:53:03PM +0200, Thomas Gleixner wrote:
> > > > > On Tue, 21 Apr 2015, Josh Triplett wrote:
> > > > > >
> > > > > > Signed-off-by: Josh Triplett <josh@joshtriplett.org>
> > > > > > Signed-off-by: Thiago Macieira <thiago.macieira@intel.com>
> > > > >
> > > > > Can you please clarify that SOB chain? It does not make any sense.
> > > >
> > > > Co-authored patch. We both worked on it together, and sadly git
> > > > doesn't support a commit with multiple authors, so this is the next
> > > > best thing.
> > >
> > > No, this is not a valid SOB chain.
> > >
> > > For 'co authored' patches you can add credits either to the file,
> > > as two copyright lines, or via the changelog, no need to mess up
> > > the SOB chain for that.
> >
> > Fine, I'll write it another way.
> >
> > Do you see any other issues with the patch other than the signoffs?
>
> Looks good to me, but I have not looked very deeply ...
I sent out a v2 with the co-author information moved from the signoffs
to the commit message. If it looks reasonable to you, can you take it
through the tip tree please?
- Josh Triplett
^ permalink raw reply
* [PATCHv2 2/2] x86: Opt into HAVE_COPY_THREAD_TLS, for both 32-bit and 64-bit
From: Josh Triplett @ 2015-05-11 19:30 UTC (permalink / raw)
To: Andy Lutomirski, Ingo Molnar, H. Peter Anvin, Peter Zijlstra,
Thomas Gleixner, Linus Torvalds, linux-api-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, x86-DgEjT+Ai2ygdnm+yROfE0A
For 32-bit userspace on a 64-bit kernel, this requires modifying
stub32_clone to actually swap the appropriate arguments to match
CONFIG_CLONE_BACKWARDS, rather than just leaving the C argument for tls
broken.
Patch co-authored by Josh Triplett and Thiago Macieira.
Signed-off-by: Josh Triplett <josh-iaAMLnmF4UmaiuxdJuQwMA@public.gmane.org>
Acked-by: Andy Lutomirski <luto-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
---
arch/x86/Kconfig | 1 +
arch/x86/ia32/ia32entry.S | 2 +-
arch/x86/kernel/process_32.c | 6 +++---
arch/x86/kernel/process_64.c | 8 ++++----
4 files changed, 9 insertions(+), 8 deletions(-)
diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index b7d31ca..4960b0d 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -124,6 +124,7 @@ config X86
select MODULES_USE_ELF_REL if X86_32
select MODULES_USE_ELF_RELA if X86_64
select CLONE_BACKWARDS if X86_32
+ select HAVE_COPY_THREAD_TLS
select ARCH_USE_BUILTIN_BSWAP
select ARCH_USE_QUEUE_RWLOCK
select OLD_SIGSUSPEND3 if X86_32 || IA32_EMULATION
diff --git a/arch/x86/ia32/ia32entry.S b/arch/x86/ia32/ia32entry.S
index 156ebca..0286735 100644
--- a/arch/x86/ia32/ia32entry.S
+++ b/arch/x86/ia32/ia32entry.S
@@ -487,7 +487,7 @@ GLOBAL(\label)
ALIGN
GLOBAL(stub32_clone)
leaq sys_clone(%rip),%rax
- mov %r8, %rcx
+ xchg %r8, %rcx
jmp ia32_ptregs_common
ALIGN
diff --git a/arch/x86/kernel/process_32.c b/arch/x86/kernel/process_32.c
index 603c4f9..ead28ff 100644
--- a/arch/x86/kernel/process_32.c
+++ b/arch/x86/kernel/process_32.c
@@ -129,8 +129,8 @@ void release_thread(struct task_struct *dead_task)
release_vm86_irqs(dead_task);
}
-int copy_thread(unsigned long clone_flags, unsigned long sp,
- unsigned long arg, struct task_struct *p)
+int copy_thread_tls(unsigned long clone_flags, unsigned long sp,
+ unsigned long arg, struct task_struct *p, unsigned long tls)
{
struct pt_regs *childregs = task_pt_regs(p);
struct task_struct *tsk;
@@ -185,7 +185,7 @@ int copy_thread(unsigned long clone_flags, unsigned long sp,
*/
if (clone_flags & CLONE_SETTLS)
err = do_set_thread_area(p, -1,
- (struct user_desc __user *)childregs->si, 0);
+ (struct user_desc __user *)tls, 0);
if (err && p->thread.io_bitmap_ptr) {
kfree(p->thread.io_bitmap_ptr);
diff --git a/arch/x86/kernel/process_64.c b/arch/x86/kernel/process_64.c
index 67fcc43..c69cabc 100644
--- a/arch/x86/kernel/process_64.c
+++ b/arch/x86/kernel/process_64.c
@@ -151,8 +151,8 @@ static inline u32 read_32bit_tls(struct task_struct *t, int tls)
return get_desc_base(&t->thread.tls_array[tls]);
}
-int copy_thread(unsigned long clone_flags, unsigned long sp,
- unsigned long arg, struct task_struct *p)
+int copy_thread_tls(unsigned long clone_flags, unsigned long sp,
+ unsigned long arg, struct task_struct *p, unsigned long tls)
{
int err;
struct pt_regs *childregs;
@@ -209,10 +209,10 @@ int copy_thread(unsigned long clone_flags, unsigned long sp,
#ifdef CONFIG_IA32_EMULATION
if (test_thread_flag(TIF_IA32))
err = do_set_thread_area(p, -1,
- (struct user_desc __user *)childregs->si, 0);
+ (struct user_desc __user *)tls, 0);
else
#endif
- err = do_arch_prctl(p, ARCH_SET_FS, childregs->r8);
+ err = do_arch_prctl(p, ARCH_SET_FS, tls);
if (err)
goto out;
}
--
2.1.4
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox