[PATCH 0/3] mm-only patches

[PATCH 0/3] mm-only patches

[Paolo 'Blaisorblade' Giarrusso]

Patch-arounds for mm-only compile errors/warnings, got on 2.6.21-rc5-mm2, still
apply on 2.6.21-rc5-mm3.
-- 
Inform me of my mistakes, so I can add them to my list!
Paolo Giarrusso, aka Blaisorblade
http://www.user-mode-linux.org/~blaisorblade

[PATCH 1/3] utrace - uml: make UML compile with utrace enabled

[Paolo 'Blaisorblade' Giarrusso]

* The prototype of arch_ptrace doesn't match the one in include/linux/ptrace.h.
* utrace_um_native is referred to by utrace_native_view but never defined.

Cc: Jeff Dike <jdike@addtoit.com>
Cc: Roland McGrath <roland@redhat.com>
Signed-off-by: Paolo 'Blaisorblade' Giarrusso <blaisorblade@yahoo.it>
---

 arch/um/kernel/ptrace.c |    7 ++++++-
 1 files changed, 6 insertions(+), 1 deletions(-)

diff --git a/arch/um/kernel/ptrace.c b/arch/um/kernel/ptrace.c
index f66d01c..a42caf3 100644
--- a/arch/um/kernel/ptrace.c
+++ b/arch/um/kernel/ptrace.c
@@ -16,7 +16,12 @@ void ptrace_disable(struct task_struct *child)
 { 
 }
 
-long arch_ptrace(struct task_struct *child, long request, long addr, long data)
+const struct utrace_regset_view utrace_um_native;
+
+int arch_ptrace(long *request, struct task_struct *child,
+		       struct utrace_attached_engine *engine,
+		       unsigned long addr, unsigned long data,
+		       long *retval)
 {
 	return -ENOSYS;
 }

Re: [PATCH 1/3] utrace - uml: make UML compile with utrace enabled

[Roland McGrath]

Technically those two symbols should not be touched in
utrace-tracehook-um.patch at all, and patches are still entirely missing
for the CONFIG_PTRACE=y build to work.  I refrained from excising them from
the patch just to be anal since I didn't have Jeff's sign-off on that.
What I'd prefer is to remove utrace_native_view from the current patch and
leave it out until there is a utrace-reget-um.patch to define it for real.

I will change utrace-tracehook.patch so it does not call arch_ptrace.
Then there will be no need to leave a definition behind when it's an empty
stub like in utrace-tracehook-um.patch.  (The only reason I left
arch_ptrace code around after utrace-trachook.patch on the arch's ported
before was that it contained historical code that was not fully replaced
until the utrace-ptrace-compat.patch code, so it's a bit clearer when
reading one patch at a time.)

Here is what I'll merge into utrace-tracehook.patch now:

--- a/kernel/ptrace.c
+++ b/kernel/ptrace.c
@@ -239,7 +239,8 @@ asmlinkage long sys_ptrace(long request,
 	if (ret < 0)
 		goto out_put_task_struct;
 
-	ret = arch_ptrace(child, request, addr, data);
+	/*ret = arch_ptrace(child, request, addr, data);*/
+	ret = -ENOSYS;
 	if (ret < 0)
 		goto out_put_task_struct;
 

Here is what I'd merge into utrace-tracehook-um.patch given Jeff's sign-off:

diff --git a/arch/um/kernel/ptrace.c b/arch/um/kernel/ptrace.c
index f66d01c..0000000 100644  
--- a/arch/um/kernel/ptrace.c
+++ b/arch/um/kernel/ptrace.c
@@ -16,11 +16,6 @@ void ptrace_disable(struct task_struct *
 { 
 }
 
-long arch_ptrace(struct task_struct *child, long request, long addr, long data)
-{
-	return -ENOSYS;
-}
-
 static void send_sigtrap(struct task_struct *tsk, struct pt_regs *regs,
 			 int error_code)
 {
diff --git a/include/asm-um/tracehook.h b/include/asm-um/tracehook.h
index 5fc0d1a..0000000 100644  
--- a/include/asm-um/tracehook.h
+++ b/include/asm-um/tracehook.h
@@ -53,12 +53,5 @@ static inline void tracehook_abort_sysca
 	PT_REGS_SYSCALL_NR(regs) = -1;
 }
 
-extern const struct utrace_regset_view utrace_um_native;
-static inline const struct utrace_regset_view *
-utrace_native_view(struct task_struct *tsk)
-{
-	return &utrace_um_native;
-}
-
 
 #endif



Thanks,
Roland

[PATCH 2/3] sys_futex64-allows-64bit-futexes-workaround for uml

[Paolo 'Blaisorblade' Giarrusso]

Copy sys_futex64-allows-64bit-futexes-workaround.patch to UML (to unbreak the
UML build). Note however that in include/asm-generic/futex.h we have:

static inline int
futex_atomic_cmpxchg_inatomic(int __user *uaddr, int oldval, int newval)
{
	return -ENOSYS;
}

Which is a better solution. Pierre Peiffer, please consider that.

Cc: Pierre Peiffer <pierre.peiffer@bull.net>
Signed-off-by: Paolo 'Blaisorblade' Giarrusso <blaisorblade@yahoo.it>
---

 include/asm-um/futex.h |   13 +++++++++++++
 1 files changed, 13 insertions(+), 0 deletions(-)

diff --git a/include/asm-um/futex.h b/include/asm-um/futex.h
index 6a332a9..e875d3e 100644
--- a/include/asm-um/futex.h
+++ b/include/asm-um/futex.h
@@ -3,4 +3,17 @@
 
 #include <asm-generic/futex.h>
 
+static inline u64
+futex_atomic_cmpxchg_inatomic64(u64 __user *uaddr, u64 oldval, u64 newval)
+{
+	return 0;
+}
+
+static inline int
+futex_atomic_op_inuser64 (int encoded_op, u64 __user *uaddr)
+{
+	return 0;
+}
+
+
 #endif

[PATCH 3/3] slab: avoid __initdata warning (may be a bogus one)

[Paolo 'Blaisorblade' Giarrusso]

set_up_list3s is not __init and references initkmem_list3.

Also, kmem_cache_create calls setup_cpu_cache which calls set_up_list3s. The
state machine _may_ prevent the code from accessing this data after freeing
initdata (it makes sure it's used only up to boot), so this warning may be a
false positive.

Signed-off-by: Paolo 'Blaisorblade' Giarrusso <blaisorblade@yahoo.it>
---

 mm/slab.c |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/mm/slab.c b/mm/slab.c
index 0934f8d..0772faf 100644
--- a/mm/slab.c
+++ b/mm/slab.c
@@ -305,7 +305,7 @@ struct kmem_list3 {
  * Need this for bootstrapping a per node allocator.
  */
 #define NUM_INIT_LISTS (2 * MAX_NUMNODES + 1)
-struct kmem_list3 __initdata initkmem_list3[NUM_INIT_LISTS];
+struct kmem_list3 initkmem_list3[NUM_INIT_LISTS];
 #define	CACHE_CACHE 0
 #define	SIZE_AC 1
 #define	SIZE_L3 (1 + MAX_NUMNODES)

Re: [PATCH 3/3] slab: avoid __initdata warning (may be a bogus one)

[Andrew Morton]

On Sat, 31 Mar 2007 01:08:14 +0200 "Paolo 'Blaisorblade' Giarrusso" <blaisorblade@yahoo.it> wrote:

> set_up_list3s is not __init and references initkmem_list3.
> 
> Also, kmem_cache_create calls setup_cpu_cache which calls set_up_list3s. The
> state machine _may_ prevent the code from accessing this data after freeing
> initdata (it makes sure it's used only up to boot), so this warning may be a
> false positive.
> 
> Signed-off-by: Paolo 'Blaisorblade' Giarrusso <blaisorblade@yahoo.it>
> ---
> 
>  mm/slab.c |    2 +-
>  1 files changed, 1 insertions(+), 1 deletions(-)
> 
> diff --git a/mm/slab.c b/mm/slab.c
> index 0934f8d..0772faf 100644
> --- a/mm/slab.c
> +++ b/mm/slab.c
> @@ -305,7 +305,7 @@ struct kmem_list3 {
>   * Need this for bootstrapping a per node allocator.
>   */
>  #define NUM_INIT_LISTS (2 * MAX_NUMNODES + 1)
> -struct kmem_list3 __initdata initkmem_list3[NUM_INIT_LISTS];
> +struct kmem_list3 initkmem_list3[NUM_INIT_LISTS];
>  #define	CACHE_CACHE 0
>  #define	SIZE_AC 1
>  #define	SIZE_L3 (1 + MAX_NUMNODES)

Yes, I think this is a flase positive - we'll never touch initkmem_list3[]
after free_initmem() because of the transitions of g_cpucache_up.

(In which case set_up_list3s() shoud be __init, too?)

Christoph, I think you looked at this previously?

Re: [PATCH 3/3] slab: avoid __initdata warning (may be a bogus one)

[Christoph Lameter]

On Sat, 31 Mar 2007, Andrew Morton wrote:

> Yes, I think this is a flase positive - we'll never touch initkmem_list3[]
> after free_initmem() because of the transitions of g_cpucache_up.

Correct.
 
> (In which case set_up_list3s() shoud be __init, too?)

Correct. Its only called during slab bootstrap.

> Christoph, I think you looked at this previously?

If you change set_up_list3s to __init then we have the same issue with 
setup_cpu_cache right?

Re: [PATCH 3/3] slab: avoid __initdata warning (may be a bogus one)

[Andrew Morton]

On Sun, 1 Apr 2007 00:15:06 -0700 (PDT) Christoph Lameter <clameter@sgi.com> wrote:

> On Sat, 31 Mar 2007, Andrew Morton wrote:
> 
> > Yes, I think this is a flase positive - we'll never touch initkmem_list3[]
> > after free_initmem() because of the transitions of g_cpucache_up.
> 
> Correct.
>  
> > (In which case set_up_list3s() shoud be __init, too?)
> 
> Correct. Its only called during slab bootstrap.
> 
> > Christoph, I think you looked at this previously?
> 
> If you change set_up_list3s to __init then we have the same issue with 
> setup_cpu_cache right?

yup.

I wonder if there's a general way in which we can suppress such false
positives.  Say, create a new section called, umm, __nowarn and
__nowarndata and then we can tag functions or data with those tags tag and teach
the checker tools to ignore them?