Skip to contentSkip to conversation

x86, xsave: fix non-lazy allocation of the xsave area

PATCH In review Hans Rosenfeld 3 participants 7 messages Apr 27, 2011 – May 2, 2011 1 message not in the archive

Subsystems (6)
x86 VFS MM core Scheduler +2 more subsystems
lore
Share & tools
lore

A message that is not in the archive (sent off-list or not yet received): [email protected]

#1 lore raw

PATCH 1/2 x86, xsave: fix non-lazy allocation of the xsave area

A single static xsave area just for init is not enough, since there are more user processes that are directly executed by kernel threads. Add a call to a new arch-specific function to flush_old_exec(), which will in turn call fpu_alloc() to allocate a xsave area if necessary.

---
 arch/x86/include/asm/i387.h        |    6 ------
 arch/x86/include/asm/thread_info.h |    2 ++
 arch/x86/kernel/process.c          |    7 +++++++
 fs/exec.c                          |    8 ++++++++
 4 files changed, 17 insertions(+), 6 deletions(-)
arch/x86/include/asm/i387.h +0 -6
index 989c0ac..0448f45 100644
@@ -329,15 +329,9 @@ static inline void fpu_copy(struct fpu *dst, struct fpu *src)
 }
 
 extern void fpu_finit(struct fpu *fpu);
-static union thread_xstate __init_xstate, *init_xstate = &__init_xstate;
 
 static inline void fpu_clear(struct fpu *fpu)
 {
-	if (!fpu_allocated(fpu)) {
-		BUG_ON(init_xstate == NULL);
-		fpu->state = init_xstate;
-		init_xstate = NULL;
-	}
 	memset(fpu->state, 0, xstate_size);
 	fpu_finit(fpu);
 	set_used_math();
arch/x86/include/asm/thread_info.h +2 -0
index 0e691c6..07c8cfe 100644
@@ -265,6 +265,8 @@ static inline void set_restore_sigmask(void)
 extern void arch_task_cache_init(void);
 extern void free_thread_info(struct thread_info *ti);
 extern int arch_dup_task_struct(struct task_struct *dst, struct task_struct *src);
+extern int arch_prealloc_fpu(struct task_struct *tsk);
+#define arch_prealloc_fpu arch_prealloc_fpu
 #define arch_task_cache_init arch_task_cache_init
 #endif
 #endif /* _ASM_X86_THREAD_INFO_H */
arch/x86/kernel/process.c +7 -0
index 0382f98..3edfbf2 100644
@@ -26,6 +26,13 @@
 struct kmem_cache *task_xstate_cachep;
 EXPORT_SYMBOL_GPL(task_xstate_cachep);
 
+int arch_prealloc_fpu(struct task_struct *tsk)
+{
+	if (!fpu_allocated(&tsk->thread.fpu))
+		return fpu_alloc(&tsk->thread.fpu);
+	return 0;
+}
+
 int arch_dup_task_struct(struct task_struct *dst, struct task_struct *src)
 {
 	int ret;
fs/exec.c +8 -0
index 5e62d26..932b9ad 100644
@@ -1022,10 +1022,18 @@ void set_task_comm(struct task_struct *tsk, char *buf)
 	perf_event_comm(tsk);
 }
 
+#if !defined(arch_prealloc_fpu)
+#define arch_prealloc_fpu(tsk) (0)
+#endif
+
 int flush_old_exec(struct linux_binprm * bprm)
 {
 	int retval;
 
+	retval = arch_prealloc_fpu(current);
+	if (retval)
+		goto out;
+
 	/*
 	 * Make sure we have a private signal table and that
 	 * we are unassociated from the previous thread group.
Signature · 1 line
1.5.6.5
#2 lore raw
Commit-ID:  300c6120b4653043e8a80b24e0483c0d223c5aac
Gitweb:     http://git.kernel.org/tip/300c6120b4653043e8a80b24e0483c0d223c5aac
Author:     Hans Rosenfeld <[email protected]>
AuthorDate: Wed, 27 Apr 2011 16:26:34 +0200
Committer:  H. Peter Anvin <[email protected]>
CommitDate: Wed, 27 Apr 2011 18:03:45 -0700

x86, xsave: fix non-lazy allocation of the xsave area

A single static xsave area just for init is not enough, since there are more user processes that are directly executed by kernel threads. Add a call to a new arch-specific function to flush_old_exec(), which will in turn call fpu_alloc() to allocate a xsave area if necessary.

---
 arch/x86/include/asm/i387.h        |    6 ------
 arch/x86/include/asm/thread_info.h |    2 ++
 arch/x86/kernel/process.c          |    7 +++++++
 fs/exec.c                          |    8 ++++++++
 4 files changed, 17 insertions(+), 6 deletions(-)
arch/x86/include/asm/i387.h +0 -6
index f410d16..41f1d7e 100644
@@ -327,15 +327,9 @@ static inline void fpu_copy(struct fpu *dst, struct fpu *src)
 }
 
 extern void fpu_finit(struct fpu *fpu);
-static union thread_xstate __init_xstate, *init_xstate = &__init_xstate;
 
 static inline void fpu_clear(struct fpu *fpu)
 {
-	if (!fpu_allocated(fpu)) {
-		BUG_ON(init_xstate == NULL);
-		fpu->state = init_xstate;
-		init_xstate = NULL;
-	}
 	memset(fpu->state, 0, xstate_size);
 	fpu_finit(fpu);
 	set_used_math();
arch/x86/include/asm/thread_info.h +2 -0
index 0e691c6..07c8cfe 100644
@@ -265,6 +265,8 @@ static inline void set_restore_sigmask(void)
 extern void arch_task_cache_init(void);
 extern void free_thread_info(struct thread_info *ti);
 extern int arch_dup_task_struct(struct task_struct *dst, struct task_struct *src);
+extern int arch_prealloc_fpu(struct task_struct *tsk);
+#define arch_prealloc_fpu arch_prealloc_fpu
 #define arch_task_cache_init arch_task_cache_init
 #endif
 #endif /* _ASM_X86_THREAD_INFO_H */
arch/x86/kernel/process.c +7 -0
index d46cbe4..a70f620 100644
@@ -26,6 +26,13 @@
 struct kmem_cache *task_xstate_cachep;
 EXPORT_SYMBOL_GPL(task_xstate_cachep);
 
+int arch_prealloc_fpu(struct task_struct *tsk)
+{
+	if (!fpu_allocated(&tsk->thread.fpu))
+		return fpu_alloc(&tsk->thread.fpu);
+	return 0;
+}
+
 int arch_dup_task_struct(struct task_struct *dst, struct task_struct *src)
 {
 	int ret;
fs/exec.c +8 -0
index 5e62d26..932b9ad 100644
@@ -1022,10 +1022,18 @@ void set_task_comm(struct task_struct *tsk, char *buf)
 	perf_event_comm(tsk);
 }
 
+#if !defined(arch_prealloc_fpu)
+#define arch_prealloc_fpu(tsk) (0)
+#endif
+
 int flush_old_exec(struct linux_binprm * bprm)
 {
 	int retval;
 
+	retval = arch_prealloc_fpu(current);
+	if (retval)
+		goto out;
+
 	/*
 	 * Make sure we have a private signal table and that
 	 * we are unassociated from the previous thread group.
#3 lore raw

PATCH 2/2 fork: avoid weak function arch_dup_task_struct

In reply to a message not in the archive

Avoid potential gcc bug by not using a weak function for arch_dup_task_struct. Use an #ifdef'ed static function for archs that don't have a special arch_dup_task_struct implementation.

---
 arch/sh/include/asm/thread_info.h  |    1 +
 arch/x86/include/asm/thread_info.h |    1 +
 kernel/fork.c                      |    5 +++--
 3 files changed, 5 insertions(+), 2 deletions(-)
arch/sh/include/asm/thread_info.h +1 -0
index ea2d508..2d27e1c 100644
@@ -100,6 +100,7 @@ extern void free_thread_info(struct thread_info *ti);
 extern void arch_task_cache_init(void);
 #define arch_task_cache_init arch_task_cache_init
 extern int arch_dup_task_struct(struct task_struct *dst, struct task_struct *src);
+#define arch_dup_task_struct arch_dup_task_struct
 extern void init_thread_xstate(void);
 
 #define __HAVE_ARCH_THREAD_INFO_ALLOCATOR
arch/x86/include/asm/thread_info.h +1 -0
index 07c8cfe..ce97947 100644
@@ -266,6 +266,7 @@ extern void arch_task_cache_init(void);
 extern void free_thread_info(struct thread_info *ti);
 extern int arch_dup_task_struct(struct task_struct *dst, struct task_struct *src);
 extern int arch_prealloc_fpu(struct task_struct *tsk);
+#define arch_dup_task_struct arch_dup_task_struct
 #define arch_prealloc_fpu arch_prealloc_fpu
 #define arch_task_cache_init arch_task_cache_init
 #endif
kernel/fork.c +3 -2
index e7548de..6d929d0 100644
@@ -243,12 +243,13 @@ void __init fork_init(unsigned long mempages)
 		init_task.signal->rlim[RLIMIT_NPROC];
 }
 
-int __attribute__((weak)) arch_dup_task_struct(struct task_struct *dst,
-					       struct task_struct *src)
+#ifndef arch_dup_task_struct
+static int arch_dup_task_struct(struct task_struct *dst, struct task_struct *src)
 {
 	*dst = *src;
 	return 0;
 }
+#endif
 
 static struct task_struct *dup_task_struct(struct task_struct *orig)
 {
Signature · 1 line
1.5.6.5
maintainer
#4 lore raw

Re: [PATCH 2/2] fork: avoid weak function arch_dup_task_struct

Quoted 3 lines · On Wed, 27 Apr 2011 16:26:35 +0200 Hans Rosenfeld <[email protected]>…

Avoid potential gcc bug by not using a weak function for arch_dup_task_struct. Use an #ifdef'ed static function for archs that don't have a special arch_dup_task_struct implementation.

The patch is unreviewable (and hence unusable) if you don't describe this "potential gcc bug".

#5 lore raw

Re: [PATCH 2/2] fork: avoid weak function arch_dup_task_struct

Quoted 9 lines · Andrew Morton
Quoted 3 lines · On Wed, 27 Apr 2011 16:26:35 +0200 Hans Rosenfeld <[email protected]>…

Avoid potential gcc bug by not using a weak function for arch_dup_task_struct. Use an #ifdef'ed static function for archs that don't have a special arch_dup_task_struct implementation.

The patch is unreviewable (and hence unusable) if you don't describe this "potential gcc bug".

http://lkml.indiana.edu/hypermail/linux/kernel/0804.3/3202.html

-hpa

Signature · 2 lines
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel.  I don't speak on their behalf.
maintainer
#6 lore raw

Re: [PATCH 2/2] fork: avoid weak function arch_dup_task_struct

Quoted 7 lines · On Sun, 01 May 2011 15:59:12 -0700 "H. Peter Anvin" <[email protected]> wrote:
Quoted 6 lines · Andrew Morton
Quoted 3 lines · On Wed, 27 Apr 2011 16:26:35 +0200 Hans Rosenfeld <[email protected]>…

Avoid potential gcc bug by not using a weak function for arch_dup_task_struct. Use an #ifdef'ed static function for archs that don't have a special arch_dup_task_struct implementation.

Quoted 6 lines
Quoted 3 lines

The patch is unreviewable (and hence unusable) if you don't describe this "potential gcc bug".

http://lkml.indiana.edu/hypermail/linux/kernel/0804.3/3202.html

gcc-4.1.0 and 4.1.1 were explicitly banned via a test in include/linux/compiler-gcc4.h for this reason.

#7 lore raw

Re: [PATCH 2/2] fork: avoid weak function arch_dup_task_struct

Quoted 9 lines · Andrew Morton
Quoted 7 lines · On Sun, 01 May 2011 15:59:12 -0700 "H. Peter Anvin"<[email protected]> wrote:
Quoted 6 lines · Andrew Morton
Quoted 3 lines · On Wed, 27 Apr 2011 16:26:35 +0200 Hans Rosenfeld<[email protected]>…

Avoid potential gcc bug by not using a weak function for arch_dup_task_struct. Use an #ifdef'ed static function for archs that don't have a special arch_dup_task_struct implementation.

Quoted 9 lines
Quoted 5 lines
Quoted 2 lines

The patch is unreviewable (and hence unusable) if you don't describe this "potential gcc bug".

http://lkml.indiana.edu/hypermail/linux/kernel/0804.3/3202.html

gcc-4.1.0 and 4.1.1 were explicitly banned via a test in include/linux/compiler-gcc4.h for this reason.

OK, no issue then. Sorry for the noise.

-hpa