* Re: [PATCH] Introduce __fill_user() and kill __bzero() [take #2]
From: Geert Uytterhoeven @ 2007-11-15 22:09 UTC (permalink / raw)
To: Franck Bui-Huu; +Cc: Ralf Baechle, Thiemo Seufer, linux-mips
In-Reply-To: <473CB727.8010106@gmail.com>
On Thu, 15 Nov 2007, Franck Bui-Huu wrote:
> Geert Uytterhoeven wrote:
> > On Thu, 15 Nov 2007, Franck Bui-Huu wrote:
> >> I put the out of line version of memset in kernel/mips_ksym.c. I
> >> haven't found a better place. But if you really think we should
> >> create a lib/memset.c and rename lib/memset.S into lib/fill_user.S, I
> >> can change it.
> >
> > kernel/mips_ksym.c is not a good place.
>
> Sigh... thanks for spotting this.
>
> So since I've no idea where I could put this function I'll follow
> Thiemo's suggestion but instead of calling the new file lib/memset.c,
> I'll use lib/string.c since we could move or implement other stuffs in
> it.
>
> Is it ok ?
lib/string.c sounds fine to me. That's where m68k and s390 implement it
as well.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* Re: [PATCH] Introduce __fill_user() and kill __bzero() [take #2]
From: Franck Bui-Huu @ 2007-11-15 21:16 UTC (permalink / raw)
To: Geert Uytterhoeven; +Cc: Ralf Baechle, Thiemo Seufer, linux-mips
In-Reply-To: <Pine.LNX.4.64.0711151744580.31039@anakin>
Geert Uytterhoeven wrote:
> On Thu, 15 Nov 2007, Franck Bui-Huu wrote:
>> I put the out of line version of memset in kernel/mips_ksym.c. I
>> haven't found a better place. But if you really think we should
>> create a lib/memset.c and rename lib/memset.S into lib/fill_user.S, I
>> can change it.
>
> kernel/mips_ksym.c is not a good place.
Sigh... thanks for spotting this.
So since I've no idea where I could put this function I'll follow
Thiemo's suggestion but instead of calling the new file lib/memset.c,
I'll use lib/string.c since we could move or implement other stuffs in
it.
Is it ok ?
Franck
^ permalink raw reply
* RE: "exportfs -a" -> stale NFS filehandle
From: Kaz Kylheku @ 2007-11-15 20:15 UTC (permalink / raw)
To: Ralf Baechle; +Cc: linux-mips
In-Reply-To: <20071115194548.GA30481@linux-mips.org>
Ralf Baechle wrote:
> On Thu, Nov 15, 2007 at 11:26:06AM -0800, Kaz Kylheku wrote:
>
>> After backing out the nfsutils patch, the diskless node does boot.
>>
>> However, the original "exportfs -a" problem comes back!
>>
>> So this problem is not resolved simply by using the correct compat
>> routine; it's deeper.
>>
>> Sigh.
>
> Thanks for testing anyway!
I'm continuing to dig into the problem.
The export logic doesn't even go through nfsctl() anyway, which is why I
originally hadn't even suspected that syscall.
The nfsexport() function in nfsutils first tries opening
"/proc/net/rpc/nfsd.fh./channel". If that works, it uses that, via a
text-based protocol. Only if that interface doesn't exist does it fall
back on the nfsctl(NFSCTL_EXPORT, ...) interface.
^ permalink raw reply
* RE: "exportfs -a" -> stale NFS filehandle
From: Kaz Kylheku @ 2007-11-15 20:15 UTC (permalink / raw)
To: Ralf Baechle; +Cc: linux-mips
In-Reply-To: <20071115194548.GA30481@linux-mips.org>
Ralf Baechle wrote:
> On Thu, Nov 15, 2007 at 11:26:06AM -0800, Kaz Kylheku wrote:
>
>> After backing out the nfsutils patch, the diskless node does boot.
>>
>> However, the original "exportfs -a" problem comes back!
>>
>> So this problem is not resolved simply by using the correct compat
>> routine; it's deeper.
>>
>> Sigh.
>
> Thanks for testing anyway!
I'm continuing to dig into the problem.
The export logic doesn't even go through nfsctl() anyway, which is why I
originally hadn't even suspected that syscall.
The nfsexport() function in nfsutils first tries opening
"/proc/net/rpc/nfsd.fh./channel". If that works, it uses that, via a
text-based protocol. Only if that interface doesn't exist does it fall
back on the nfsctl(NFSCTL_EXPORT, ...) interface.
^ permalink raw reply
* Re: "exportfs -a" -> stale NFS filehandle
From: Ralf Baechle @ 2007-11-15 19:45 UTC (permalink / raw)
To: Kaz Kylheku; +Cc: linux-mips
In-Reply-To: <DDFD17CC94A9BD49A82147DDF7D545C54DC8C7@exchange.ZeugmaSystems.local>
On Thu, Nov 15, 2007 at 11:26:06AM -0800, Kaz Kylheku wrote:
> After backing out the nfsutils patch, the diskless node does boot.
>
> However, the original "exportfs -a" problem comes back!
>
> So this problem is not resolved simply by using the correct compat
> routine; it's deeper.
>
> Sigh.
Thanks for testing anyway!
Ralf
^ permalink raw reply
* Re: gdb chokes on core from 64-bit kernel (patch)
From: Andrew Sharp @ 2007-11-15 19:40 UTC (permalink / raw)
To: Ralf Baechle; +Cc: linux-mips@linux-mips.org
In-Reply-To: <20071109090757.GA12469@linux-mips.org>
On Fri, 9 Nov 2007 09:07:57 +0000 Ralf Baechle <ralf@linux-mips.org>
wrote:
> On Thu, Nov 08, 2007 at 02:03:22PM -0800, Andrew Sharp wrote:
>
> > The gdb from debian etch (6.4.90-debian) doesn't like core files
> > produced by 64-bit kernel it seems. I've got this patch which seems
> > to do the job, but I'm unclear on what other implications it might
> > have, if any.
>
> > diff --git a/arch/mips/kernel/binfmt_elfo32.c
> > b/arch/mips/kernel/binfmt_elfo32.c index 993f7ec..58533dc 100644
> > --- a/arch/mips/kernel/binfmt_elfo32.c
> > +++ b/arch/mips/kernel/binfmt_elfo32.c
> > @@ -54,9 +54,13 @@ typedef elf_fpreg_t elf_fpregset_t[ELF_NFPREG];
> >
> > #include <asm/processor.h>
> > #include <linux/module.h>
> > -#include <linux/elfcore.h>
> > #include <linux/compat.h>
> >
> > +void elf32_core_copy_regs(elf_gregset_t grp, struct pt_regs *regs);
> > +#undef ELF_CORE_COPY_REGS
> > +#define ELF_CORE_COPY_REGS(_dest,_regs)
> > elf32_core_copy_regs(_dest,_regs); +#include <linux/elfcore.h>
> > +
> > #define elf_prstatus elf_prstatus32
> > struct elf_prstatus32
> > {
> > @@ -109,9 +113,6 @@ jiffies_to_compat_timeval(unsigned long
> > jiffies, struct comp value->tv_usec = rem / NSEC_PER_USEC;
> > }
> >
> > -#undef ELF_CORE_COPY_REGS
> > -#define ELF_CORE_COPY_REGS(_dest,_regs)
> > elf32_core_copy_regs(_dest,_regs); -
> > void elf32_core_copy_regs(elf_gregset_t grp, struct pt_regs *regs)
> > {
> > int i;
>
> Looks like it's a larger change than needed.
Which change? Both files?
> > diff --git a/include/asm-mips/reg.h b/include/asm-mips/reg.h
> > index 634b55d..b44b308 100644
> > --- a/include/asm-mips/reg.h
> > +++ b/include/asm-mips/reg.h
> > @@ -12,7 +12,7 @@
> > #ifndef __ASM_MIPS_REG_H
> > #define __ASM_MIPS_REG_H
> >
> > -
> > +#define WANT_COMPAT_REG_H
> > #if defined(CONFIG_32BIT) || defined(WANT_COMPAT_REG_H)
> >
> > #define EF_R0 6
> > @@ -69,7 +69,7 @@
> >
> > #endif
> >
> > -#ifdef CONFIG_64BIT
> > +#if defined(CONFIG_64BIT) && !defined(WANT_COMPAT_REG_H)
> >
> > #define EF_R0 0
> > #define EF_R1 1
>
> This change breaks the native 64-bit and N32 ptrace and core dumpers.
>
> I suggest something more minimal like the below patch. Does that one
> do the trick for you?
>
> Ralf
>
> Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
>
> arch/mips/kernel/ptrace32.c | 3 +++
> 1 files changed, 3 insertions(+), 0 deletions(-)
>
> diff --git a/arch/mips/kernel/ptrace32.c b/arch/mips/kernel/ptrace32.c
> index 76818be..44109fb 100644
> --- a/arch/mips/kernel/ptrace32.c
> +++ b/arch/mips/kernel/ptrace32.c
> @@ -14,6 +14,9 @@
> * At this time Linux/MIPS64 only supports syscall tracing, even for
> 32-bit
> * binaries.
> */
> +
> +#define WANT_COMPAT_REG_H
> +
> #include <linux/compiler.h>
> #include <linux/kernel.h>
> #include <linux/sched.h>
Without the change to reg.h, this change causes a bunch of
warning: "EF_R0" redefined
type messages when compiling ptrace32.c. I tried a combination of mine
and yours, well, really mine except I moved the define for
WANT_COMPAT_REG_H to ptrace32.c, and that did not produce an comprehensible
core file.
Any suggestions?
Cheers,
a
^ permalink raw reply
* RE: "exportfs -a" -> stale NFS filehandle
From: Kaz Kylheku @ 2007-11-15 19:26 UTC (permalink / raw)
To: Ralf Baechle; +Cc: linux-mips
In-Reply-To: <DDFD17CC94A9BD49A82147DDF7D545C54DC88F@exchange.ZeugmaSystems.local>
linux-mips-bounce@linux-mips.org wrote:
> Ralf Baechle wrote:
>> Can you test below patch?
>>
>> Ralf
>
> [ snip ]
>
>> - PTR sys_nfsservctl
>> + PTR compat_sys_nfsservctl
>
> That's damn funny!
... but it doesn't work. Now the slave systems won't even boot at all.
Looking up port of RPC 100003/2 on 127.3.0.1
Root-NFS: Unable to get nfsd port number from server, using default
Looking up port of RPC 100005/1 on 127.3.0.1
Root-NFS: Server returned error -13 while mounting /cf2
Ah, but the reason for /that/ is that I have an n32 patch against
nfsutils in user space already, which has to be backed out.
After backing out the nfsutils patch, the diskless node does boot.
However, the original "exportfs -a" problem comes back!
So this problem is not resolved simply by using the correct compat
routine; it's deeper.
Sigh.
^ permalink raw reply
* RE: "exportfs -a" -> stale NFS filehandle
From: Kaz Kylheku @ 2007-11-15 19:26 UTC (permalink / raw)
To: Ralf Baechle; +Cc: linux-mips
In-Reply-To: <DDFD17CC94A9BD49A82147DDF7D545C54DC88F@exchange.ZeugmaSystems.local>
linux-mips-bounce@linux-mips.org wrote:
> Ralf Baechle wrote:
>> Can you test below patch?
>>
>> Ralf
>
> [ snip ]
>
>> - PTR sys_nfsservctl
>> + PTR compat_sys_nfsservctl
>
> That's damn funny!
... but it doesn't work. Now the slave systems won't even boot at all.
Looking up port of RPC 100003/2 on 127.3.0.1
Root-NFS: Unable to get nfsd port number from server, using default
Looking up port of RPC 100005/1 on 127.3.0.1
Root-NFS: Server returned error -13 while mounting /cf2
Ah, but the reason for /that/ is that I have an n32 patch against
nfsutils in user space already, which has to be backed out.
After backing out the nfsutils patch, the diskless node does boot.
However, the original "exportfs -a" problem comes back!
So this problem is not resolved simply by using the correct compat
routine; it's deeper.
Sigh.
^ permalink raw reply
* RE: "exportfs -a" -> stale NFS filehandle
From: Kaz Kylheku @ 2007-11-15 18:38 UTC (permalink / raw)
To: Ralf Baechle; +Cc: linux-mips
In-Reply-To: <20071115004821.GA32332@linux-mips.org>
Ralf Baechle wrote:
> Can you test below patch?
>
> Ralf
[ snip ]
> - PTR sys_nfsservctl
> + PTR compat_sys_nfsservctl
That's damn funny!
I checked for replies this morning, but your e-mail went to my inbox
rather than my linux-mips folder, so I didn't see it.
I just made that change just moments ago.
As I'm compiling it, a coworker says, ``Kaz, did you see Ralph's
reply?''. :)
Nope!
^ permalink raw reply
* RE: "exportfs -a" -> stale NFS filehandle
From: Kaz Kylheku @ 2007-11-15 18:38 UTC (permalink / raw)
To: Ralf Baechle; +Cc: linux-mips
In-Reply-To: <20071115004821.GA32332@linux-mips.org>
Ralf Baechle wrote:
> Can you test below patch?
>
> Ralf
[ snip ]
> - PTR sys_nfsservctl
> + PTR compat_sys_nfsservctl
That's damn funny!
I checked for replies this morning, but your e-mail went to my inbox
rather than my linux-mips folder, so I didn't see it.
I just made that change just moments ago.
As I'm compiling it, a coworker says, ``Kaz, did you see Ralph's
reply?''. :)
Nope!
^ permalink raw reply
* Re: Cannot unwind through MIPS signal frames with ICACHE_REFILLS_WORKAROUND_WAR
From: David Daney @ 2007-11-15 17:21 UTC (permalink / raw)
To: Ralf Baechle; +Cc: Franck Bui-Huu, linux-mips
In-Reply-To: <20071115115351.GA4973@linux-mips.org>
Ralf Baechle wrote:
> On Thu, Nov 15, 2007 at 09:46:25AM +0100, Franck Bui-Huu wrote:
>
>> Ralf Baechle wrote:
>>> Another reason is to get rid of the classic trampoline the kernel installs
>>> on the stack. On some multiprocessor systems it requires a cacheflush
>> BTW, could we get rid of the trampoline so easily ? I mean won't we have
>> to keep it for backward compatibility reasons ?
There has to be some way for user code to unwind the call stack through
signal handler frames. For Linux/MIPS systems that use GCC as their
system compiler, this is done by code in libgcc which is part of the GCC
runtime.
Currently the unwinder examines the code at the signal handler return
address and if it detects one of the several know trampoline code
sequences, it makes assumptions about the way the kernel lays out the
stack. In particular, it assumes that there is a struct sigcontext at a
well known offset from the stack pointer at entry to the signal handler.
The code that handles this is in gcc/config/mips/linux-unwind.h
As of GCC-4.3 the location of the trampoline is unimportant, but the
location of the sigcontext relative to the value in $sp is important and
should not be changed unless there really is no other choice.
>
> The trampolines are an implementation detail. Little software needs to
> know about it, so while I expect some slight colateral damage from getting
> rid of trampolines it's not going to be painful. GDB is the primary piece
> of software that will need to change.
And any user code that uses SIGSEGV to detect and handle dereferencing
null pointers.
>
> Some of the other architectures have an sa_restorer field in struct
> sigaction but we don't have that on MIPS.
>
> One way to deal with this would be to do a similar as IRIX where the
> sigaction(2) takes a 4th argument which takes the role of sa_restorer.
> For backward compatibility an SA_RESTORER field. So if the SA_RESTORER
> is clear we'd be using a classic trampoline, if it's set the value of
> the 4th argument.
>
> Or slightly crazier, put a kernel address into the $ra register of the
> invoked signal handler. So the signal handler will cause an address
> error exception which then can be trapped. Additional advantage - some of
> the "Don't let your children do this ..." sections of code can go away ;-)
I am liking the idea of putting the trampoline code in the (as of yet
non-existent vdso). This eliminates the need to flush the icache, but
maintains the ability of user code to unwind through signal frames.
Putting a .eh_frame section in the vdso would be even better as that
would eliminate the need for libgcc to do code reading and let the
kernel use any means desired to return from signal handlers.
David Daney
^ permalink raw reply
* Re: [PATCH] Introduce __fill_user() and kill __bzero() [take #2]
From: Geert Uytterhoeven @ 2007-11-15 16:46 UTC (permalink / raw)
To: Franck Bui-Huu; +Cc: Ralf Baechle, Thiemo Seufer, linux-mips
In-Reply-To: <473C720B.7000100@gmail.com>
On Thu, 15 Nov 2007, Franck Bui-Huu wrote:
> I put the out of line version of memset in kernel/mips_ksym.c. I
> haven't found a better place. But if you really think we should
> create a lib/memset.c and rename lib/memset.S into lib/fill_user.S, I
> can change it.
kernel/mips_ksym.c is not a good place. Adrian `trivial' Bunk is
scanning arch/ for *_ksym.c files and moving the EXPORT_SYMBOL()s to the
source files they belong to.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* [PATCH] Introduce __fill_user() and kill __bzero() [take #2]
From: Franck Bui-Huu @ 2007-11-15 16:21 UTC (permalink / raw)
To: Ralf Baechle; +Cc: Thiemo Seufer, linux-mips
Currently memset() is used to fill a user space area (clear_user) or
kernel one (memset). These two functions don't have the same
prototype, the former returning the number of bytes not copied and the
latter returning the start address of the area to clear. This forces
memset() to actually returns two values in an unconventional way ie
the number of bytes not copied is given by $a2. Therefore clear_user()
needs to call memset() using inline assembly.
Instead this patch creates __fill_user() which is the same as memset()
except it always returns the number of bytes not copied. This simplify
clear_user() and makes its definition saner.
Also an out of line version of memset is given because gcc generates
some calls to it since builtin functions have been disabled. It allows
assembly code to call it too.
Eventually __bzero() has been removed because it's not part of the
Linux uaccess API. And the nano-optimization it brings is not
worthing.
Signed-off-by: Franck Bui-Huu <fbuihuu@gmail.com>
---
Thimeo,
I put the out of line version of memset in kernel/mips_ksym.c. I
haven't found a better place. But if you really think we should
create a lib/memset.c and rename lib/memset.S into lib/fill_user.S, I
can change it.
Thanks,
Franck
arch/mips/kernel/mips_ksyms.c | 13 +++++++++++--
arch/mips/lib/csum_partial.S | 2 +-
arch/mips/lib/memcpy.S | 2 +-
arch/mips/lib/memset.S | 34 +++++++++++++++++-----------------
include/asm-mips/string.h | 7 ++++++-
include/asm-mips/uaccess.h | 17 +++--------------
6 files changed, 39 insertions(+), 36 deletions(-)
diff --git a/arch/mips/kernel/mips_ksyms.c b/arch/mips/kernel/mips_ksyms.c
index 225755d..091275e 100644
--- a/arch/mips/kernel/mips_ksyms.c
+++ b/arch/mips/kernel/mips_ksyms.c
@@ -14,7 +14,6 @@
#include <asm/pgtable.h>
#include <asm/uaccess.h>
-extern void *__bzero(void *__s, size_t __count);
extern long __strncpy_from_user_nocheck_asm(char *__to,
const char *__from, long __len);
extern long __strncpy_from_user_asm(char *__to, const char *__from,
@@ -36,9 +35,9 @@ EXPORT_SYMBOL(kernel_thread);
/*
* Userspace access stuff.
*/
+EXPORT_SYMBOL(__fill_user);
EXPORT_SYMBOL(__copy_user);
EXPORT_SYMBOL(__copy_user_inatomic);
-EXPORT_SYMBOL(__bzero);
EXPORT_SYMBOL(__strncpy_from_user_nocheck_asm);
EXPORT_SYMBOL(__strncpy_from_user_asm);
EXPORT_SYMBOL(__strlen_user_nocheck_asm);
@@ -51,3 +50,13 @@ EXPORT_SYMBOL(csum_partial_copy_nocheck);
EXPORT_SYMBOL(__csum_partial_copy_user);
EXPORT_SYMBOL(invalid_pte_table);
+
+/*
+ * An outline version of memset, which should be used either by gcc or
+ * by assembly code.
+ */
+void *memset(void *s, int c, __kernel_size_t len)
+{
+ __fill_user(s, c, len);
+ return s;
+}
diff --git a/arch/mips/lib/csum_partial.S b/arch/mips/lib/csum_partial.S
index c0a77fe..8d3fa1e 100644
--- a/arch/mips/lib/csum_partial.S
+++ b/arch/mips/lib/csum_partial.S
@@ -694,7 +694,7 @@ l_exc:
ADD dst, t0 # compute start address in a1
SUB dst, src
/*
- * Clear len bytes starting at dst. Can't call __bzero because it
+ * Clear len bytes starting at dst. Can't call memset because it
* might modify len. An inefficient loop for these rare times...
*/
beqz len, done
diff --git a/arch/mips/lib/memcpy.S b/arch/mips/lib/memcpy.S
index a526c62..425f2c3 100644
--- a/arch/mips/lib/memcpy.S
+++ b/arch/mips/lib/memcpy.S
@@ -443,7 +443,7 @@ l_exc:
ADD dst, t0 # compute start address in a1
SUB dst, src
/*
- * Clear len bytes starting at dst. Can't call __bzero because it
+ * Clear len bytes starting at dst. Can't call memset because it
* might modify len. An inefficient loop for these rare times...
*/
beqz len, done
diff --git a/arch/mips/lib/memset.S b/arch/mips/lib/memset.S
index 3f8b8b3..4329811 100644
--- a/arch/mips/lib/memset.S
+++ b/arch/mips/lib/memset.S
@@ -46,17 +46,19 @@
.endm
/*
- * memset(void *s, int c, size_t n)
+ * __kernel_size_t __fill_user(void __user *s, long c, __kernel_size_t n)
*
* a0: start of area to clear
* a1: char to fill with
* a2: size of area to clear
+ *
+ * Returns the number of bytes NOT set or 0 on success.
*/
.set noreorder
.align 5
-LEAF(memset)
+LEAF(__fill_user)
beqz a1, 1f
- move v0, a0 /* result */
+ move v0, zero /* result */
andi a1, 0xff /* spread fillword */
LONG_SLL t1, a1, 8
@@ -68,8 +70,6 @@ LEAF(memset)
#endif
or a1, t1
1:
-
-FEXPORT(__bzero)
sltiu t0, a2, LONGSIZE /* very small region? */
bnez t0, small_memset
andi t0, a0, LONGMASK /* aligned? */
@@ -127,7 +127,7 @@ memset_partial:
EX(LONG_S_L, a1, -1(a0), last_fixup)
#endif
1: jr ra
- move a2, zero
+ nop
small_memset:
beqz a2, 2f
@@ -138,29 +138,29 @@ small_memset:
sb a1, -1(a0)
2: jr ra /* done */
- move a2, zero
- END(memset)
+ nop
+END(__fill_user)
first_fixup:
- jr ra
- nop
+ jr ra
+ move v0, a2
fwd_fixup:
PTR_L t0, TI_TASK($28)
LONG_L t0, THREAD_BUADDR(t0)
- andi a2, 0x3f
- LONG_ADDU a2, t1
+ andi v0, a2, 0x3f
+ LONG_ADDU v0, t1
jr ra
- LONG_SUBU a2, t0
+ LONG_SUBU v0, t0
partial_fixup:
PTR_L t0, TI_TASK($28)
LONG_L t0, THREAD_BUADDR(t0)
- andi a2, LONGMASK
- LONG_ADDU a2, t1
+ andi v0, a2, LONGMASK
+ LONG_ADDU v0, t1
jr ra
- LONG_SUBU a2, t0
+ LONG_SUBU v0, t0
last_fixup:
jr ra
- andi v1, a2, LONGMASK
+ andi v0, a2, LONGMASK
diff --git a/include/asm-mips/string.h b/include/asm-mips/string.h
index 436e3ad..2bba927 100644
--- a/include/asm-mips/string.h
+++ b/include/asm-mips/string.h
@@ -10,6 +10,7 @@
#ifndef _ASM_STRING_H
#define _ASM_STRING_H
+#include <asm/uaccess.h> /* __fill_user() */
/*
* Most of the inline functions are rather naive implementations so I just
@@ -132,7 +133,11 @@ strncmp(__const__ char *__cs, __const__ char *__ct, size_t __count)
#endif /* CONFIG_32BIT */
#define __HAVE_ARCH_MEMSET
-extern void *memset(void *__s, int __c, size_t __count);
+extern inline void *memset(void *s, int c, size_t count)
+{
+ __fill_user(s, c, count);
+ return s;
+}
#define __HAVE_ARCH_MEMCPY
extern void *memcpy(void *__to, __const__ void *__from, size_t __n);
diff --git a/include/asm-mips/uaccess.h b/include/asm-mips/uaccess.h
index c30c718..8c0d226 100644
--- a/include/asm-mips/uaccess.h
+++ b/include/asm-mips/uaccess.h
@@ -11,7 +11,6 @@
#include <linux/kernel.h>
#include <linux/errno.h>
-#include <linux/thread_info.h>
#include <asm-generic/uaccess.h>
/*
@@ -633,23 +632,13 @@ extern size_t __copy_user_inatomic(void *__to, const void *__from, size_t __n);
* Returns number of bytes that could not be cleared.
* On success, this will be zero.
*/
+extern __kernel_size_t __fill_user(void __user *s, long c, __kernel_size_t n);
+
static inline __kernel_size_t
__clear_user(void __user *addr, __kernel_size_t size)
{
- __kernel_size_t res;
-
might_sleep();
- __asm__ __volatile__(
- "move\t$4, %1\n\t"
- "move\t$5, $0\n\t"
- "move\t$6, %2\n\t"
- __MODULE_JAL(__bzero)
- "move\t%0, $6"
- : "=r" (res)
- : "r" (addr), "r" (size)
- : "$4", "$5", "$6", __UA_t0, __UA_t1, "$31");
-
- return res;
+ return __fill_user(addr, 0, size);
}
#define clear_user(addr,n) \
^ permalink raw reply related
* Re: Cannot unwind through MIPS signal frames with ICACHE_REFILLS_WORKAROUND_WAR
From: Ralf Baechle @ 2007-11-15 11:53 UTC (permalink / raw)
To: Franck Bui-Huu; +Cc: linux-mips
In-Reply-To: <473C0761.1040205@gmail.com>
On Thu, Nov 15, 2007 at 09:46:25AM +0100, Franck Bui-Huu wrote:
> Ralf Baechle wrote:
> > Another reason is to get rid of the classic trampoline the kernel installs
> > on the stack. On some multiprocessor systems it requires a cacheflush
>
> BTW, could we get rid of the trampoline so easily ? I mean won't we have
> to keep it for backward compatibility reasons ?
The trampolines are an implementation detail. Little software needs to
know about it, so while I expect some slight colateral damage from getting
rid of trampolines it's not going to be painful. GDB is the primary piece
of software that will need to change.
Some of the other architectures have an sa_restorer field in struct
sigaction but we don't have that on MIPS.
One way to deal with this would be to do a similar as IRIX where the
sigaction(2) takes a 4th argument which takes the role of sa_restorer.
For backward compatibility an SA_RESTORER field. So if the SA_RESTORER
is clear we'd be using a classic trampoline, if it's set the value of
the 4th argument.
Or slightly crazier, put a kernel address into the $ra register of the
invoked signal handler. So the signal handler will cause an address
error exception which then can be trapped. Additional advantage - some of
the "Don't let your children do this ..." sections of code can go away ;-)
Ralf
^ permalink raw reply
* RE: smp8634 add memory at dram1
From: Gustafsson Marcus-MGU001 @ 2007-11-15 10:49 UTC (permalink / raw)
To: linux-mips
In-Reply-To: <473B1DD0.2090903@avtrex.com>
David Daney wrote
> I think your understanding of the 8634 is at least close to correct.
>
> It may be possible (but I have not tried it yet) to use the
> remapping registers to move dram1 into the first 512MB of the
> memory space. If it is possible, you would then have to
> modify the gbus access functions accordingly. Also the 8634
> media drivers would probably have to be changed as well. I
> am not sure about the microcode for the media DSPs, but if it
> is dependent on the mapping of the DRAM, then you would
> probably have to get the vendor's help.
>
> Let me know if you are successful.
AFAIK the memory bandwith available is not enough for supporting video
decoding and Linux usage at the same dram controller.
/Marcus Gustafsson
^ permalink raw reply
* RE: smp8634 add memory at dram1
From: Gustafsson Marcus-MGU001 @ 2007-11-15 10:49 UTC (permalink / raw)
To: linux-mips
In-Reply-To: <473B1DD0.2090903@avtrex.com>
David Daney wrote
> I think your understanding of the 8634 is at least close to correct.
>
> It may be possible (but I have not tried it yet) to use the
> remapping registers to move dram1 into the first 512MB of the
> memory space. If it is possible, you would then have to
> modify the gbus access functions accordingly. Also the 8634
> media drivers would probably have to be changed as well. I
> am not sure about the microcode for the media DSPs, but if it
> is dependent on the mapping of the DRAM, then you would
> probably have to get the vendor's help.
>
> Let me know if you are successful.
AFAIK the memory bandwith available is not enough for supporting video
decoding and Linux usage at the same dram controller.
/Marcus Gustafsson
^ permalink raw reply
* Re: Cannot unwind through MIPS signal frames with ICACHE_REFILLS_WORKAROUND_WAR
From: Franck Bui-Huu @ 2007-11-15 8:46 UTC (permalink / raw)
To: Ralf Baechle; +Cc: linux-mips
In-Reply-To: <20071113121036.GA6582@linux-mips.org>
Ralf Baechle wrote:
> Another reason is to get rid of the classic trampoline the kernel installs
> on the stack. On some multiprocessor systems it requires a cacheflush
BTW, could we get rid of the trampoline so easily ? I mean won't we have
to keep it for backward compatibility reasons ?
Franck
^ permalink raw reply
* Re: "exportfs -a" -> stale NFS filehandle
From: Ralf Baechle @ 2007-11-15 0:48 UTC (permalink / raw)
To: Kaz Kylheku; +Cc: linux-mips
In-Reply-To: <DDFD17CC94A9BD49A82147DDF7D545C547AF5B@exchange.ZeugmaSystems.local>
On Wed, Nov 14, 2007 at 03:19:43PM -0800, Kaz Kylheku wrote:
> I have an NFS problem on a multi-node MIPS system running kernel
> 2.6.17.7. NFS utils is 1.1.0. ABI is n32.
>
> One node (call it primary) exports a directory which is mounted by
> several others (the secondaries) as their root filesystem.
>
> If I run "exportfs -a" on the primary, the secondary nodes lose their
> root filesystem and so everything stops working.
>
> I turned on all NFS debugging on a secondary node (sysctl -w
> sunrpc.nfs_debug=65535). What is happening is that NFS operations
> suddenly start returning error -151 (stale NFS filehandle).
>
> I don't see exportfs causing this problem on other systems. If I run
> "exportfs -a" on a big NFS server (Fedora Core 5, i686) which has lots
> of diskless clients, nothing bad happens. (And some of those diskless
> clients are MIPS systems just like this one!)
>
> I'm pretty sure that exportfs -a shouldn't screw up the existing mounted
> clients.
>
> Could there be some ABI problem that corrupts up the effect of the
> re-exporting operation on the server?
Can you test below patch?
Ralf
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
diff --git a/arch/mips/kernel/scall64-n32.S b/arch/mips/kernel/scall64-n32.S
index 118be24..01993ec 100644
--- a/arch/mips/kernel/scall64-n32.S
+++ b/arch/mips/kernel/scall64-n32.S
@@ -293,7 +293,7 @@ EXPORT(sysn32_call_table)
PTR sys_ni_syscall /* 6170, was get_kernel_syms */
PTR sys_ni_syscall /* was query_module */
PTR sys_quotactl
- PTR sys_nfsservctl
+ PTR compat_sys_nfsservctl
PTR sys_ni_syscall /* res. for getpmsg */
PTR sys_ni_syscall /* 6175 for putpmsg */
PTR sys_ni_syscall /* res. for afs_syscall */
^ permalink raw reply related
* "exportfs -a" -> stale NFS filehandle
From: Kaz Kylheku @ 2007-11-14 23:19 UTC (permalink / raw)
To: linux-mips
Hi all,
I have an NFS problem on a multi-node MIPS system running kernel
2.6.17.7. NFS utils is 1.1.0. ABI is n32.
One node (call it primary) exports a directory which is mounted by
several others (the secondaries) as their root filesystem.
If I run "exportfs -a" on the primary, the secondary nodes lose their
root filesystem and so everything stops working.
I turned on all NFS debugging on a secondary node (sysctl -w
sunrpc.nfs_debug=65535). What is happening is that NFS operations
suddenly start returning error -151 (stale NFS filehandle).
I don't see exportfs causing this problem on other systems. If I run
"exportfs -a" on a big NFS server (Fedora Core 5, i686) which has lots
of diskless clients, nothing bad happens. (And some of those diskless
clients are MIPS systems just like this one!)
I'm pretty sure that exportfs -a shouldn't screw up the existing mounted
clients.
Could there be some ABI problem that corrupts up the effect of the
re-exporting operation on the server?
(This issure reproduces always. Something which reproduces rarely is a
kernel crash on a secondary node, inside the nfsd process, also
apparently in response to the "exportfs -a". I don't yet have enough
information about that one, such as a call trace, etc. That one I can
drill into, if I have a program counter and call stack.)
^ permalink raw reply
* "exportfs -a" -> stale NFS filehandle
From: Kaz Kylheku @ 2007-11-14 23:19 UTC (permalink / raw)
To: linux-mips
Hi all,
I have an NFS problem on a multi-node MIPS system running kernel
2.6.17.7. NFS utils is 1.1.0. ABI is n32.
One node (call it primary) exports a directory which is mounted by
several others (the secondaries) as their root filesystem.
If I run "exportfs -a" on the primary, the secondary nodes lose their
root filesystem and so everything stops working.
I turned on all NFS debugging on a secondary node (sysctl -w
sunrpc.nfs_debug=65535). What is happening is that NFS operations
suddenly start returning error -151 (stale NFS filehandle).
I don't see exportfs causing this problem on other systems. If I run
"exportfs -a" on a big NFS server (Fedora Core 5, i686) which has lots
of diskless clients, nothing bad happens. (And some of those diskless
clients are MIPS systems just like this one!)
I'm pretty sure that exportfs -a shouldn't screw up the existing mounted
clients.
Could there be some ABI problem that corrupts up the effect of the
re-exporting operation on the server?
(This issure reproduces always. Something which reproduces rarely is a
kernel crash on a secondary node, inside the nfsd process, also
apparently in response to the "exportfs -a". I don't yet have enough
information about that one, such as a call trace, etc. That one I can
drill into, if I have a program counter and call stack.)
^ permalink raw reply
* Re: MIPS assembly directives in GCC
From: Jiju George T @ 2007-11-14 20:37 UTC (permalink / raw)
To: linux-mips
In-Reply-To: <dd7dc2bc0711010536l18f9f2f6gbda4e9ef1158da61@mail.gmail.com>
See Chapter 8 of
http://www.cs.unibo.it/~solmi/teaching/arch_2002-2003/AssemblyLanguageProgDoc.pdf
Regards,
Jiju
Hyon Lim wrote:
>
> I investigated kernel assembly source code in my kernel (2.6.10).
> I found that there are a lot of assembly directives (e.g., .align, .set
> reorder, .cpload, .frame etc.).
> Is there any documents which explains those directives? (not only I
> described above. All of directives)
>
> --
> Hyon Lim (임현)
> Mobile. 010-8212-1240 (Intl' Call : +82-10-8212-1240)
> Fax. 032-232-0578 (Intl' Available)
> Homepage : http://www.alexlab.net
> Blog : http://www.alexlab.net/blog
>
>
--
View this message in context: http://www.nabble.com/MIPS-assembly-directives-in-GCC-tf4731041.html#a13755803
Sent from the linux-mips main mailing list archive at Nabble.com.
^ permalink raw reply
* Re: smp8634 add memory at dram1
From: David Daney @ 2007-11-14 16:09 UTC (permalink / raw)
To: David Kuk; +Cc: linux-mips
In-Reply-To: <473AB56B.2070107@entone.com>
David Kuk wrote:
> After study about the memory configuration of sigma smp8634, i found
> some difficult to accomplish the task.
>
> so my question is if have two 128MB ram separately under dram0 and
> dram1 controller, where dram0 for linux and dram1 for video decoding.
> Now the situation is the memory for linux is not enough and video
> decoding can not use all of it's 128MB at dram1, what we plan to do is
> to share 64MB at dram1 to the linux kernel as high memory, and only
> reserved 64MB at dram1 for the video decoding.
>
> first, in MIPS architecture, we found that the kseg0 and kseg1 are
> mapped to 0x00000000-0x20000000, which include only dram0 controller,
> so we wish to add the dram1 memory manually to the kernel using
> function add_memory_region at setup.c , after booting up result the
> warning that the memory larger than 512 need to configured the kernel
> support high memory.
>
> then when we configure the kernel to support high memory at menu
> configure, the kernel when booting up will remind us our CPU do not
> support high memory due to cache aliases.
>
> Both way will lead the linux can not boot up normally, so what should
> we do, is there any mis-understanding about the hardware
> implementation or MIPS design?
I think your understanding of the 8634 is at least close to correct.
It may be possible (but I have not tried it yet) to use the remapping
registers to move dram1 into the first 512MB of the memory space. If it
is possible, you would then have to modify the gbus access functions
accordingly. Also the 8634 media drivers would probably have to be
changed as well. I am not sure about the microcode for the media DSPs,
but if it is dependent on the mapping of the DRAM, then you would
probably have to get the vendor's help.
Let me know if you are successful.
Thanks,
David Daney
^ permalink raw reply
* Re: [PATCH] Introduce __fill_user() and kill __bzero()
From: Franck Bui-Huu @ 2007-11-14 15:13 UTC (permalink / raw)
To: Thiemo Seufer; +Cc: Ralf Baechle, linux-mips
In-Reply-To: <20071114134840.GN8363@networkno.de>
On Nov 14, 2007 2:48 PM, Thiemo Seufer <ths@networkno.de> wrote:
> What about using memset.c and fill_user.S ?
>
Quite frankly, I don't know if we could create memset.c and put inside
a function of 2 lines. And I don't think we're going to add some stuff in
it later.
What about implementing fill_user() in C ?
--
Franck
^ permalink raw reply
* Re: [PATCH] Introduce __fill_user() and kill __bzero()
From: Thiemo Seufer @ 2007-11-14 13:48 UTC (permalink / raw)
To: Franck Bui-Huu; +Cc: Ralf Baechle, linux-mips
In-Reply-To: <473AEB52.40501@gmail.com>
Franck Bui-Huu wrote:
> Thiemo Seufer wrote:
> > In general we do (think of stack unwinding etc.). I believe this
> > implementation should move to C, as it doesn't need an assembler
> > implementation:
> >
> > void *memset (void *s, int c, kernel_size_t n)
> > {
> > __fill_user(s, c, n);
> > return s;
> > }
> >
> > It looks much nicer that way. :-)
> >
>
> Sure but memset.S was a really good place to implement memset(), wasn't
> it ?
What about using memset.c and fill_user.S ?
> And since the implementation should have been trivial,
As you found out now, nothing is trivial in assembler. :-)
> I thought it was ok to implement in assembly.
As a general rule, assembly should only be used when C doesn't cut it.
Thiemo
^ permalink raw reply
* Re: smp8634 add memory at dram1
From: david @ 2007-11-14 12:36 UTC (permalink / raw)
To: Ralf Baechle; +Cc: David Kuk, linux-mips
In-Reply-To: <20071114110426.GA19693@linux-mips.org>
Quoting Ralf Baechle <ralf@linux-mips.org>:
>
> I don't know what processor core Sigma is using in this SOC. In case its a
> 64-bit core, don't waste even a nanosecond on highmem, just go for a 64-bit
> kernel, it's much less painful than highmem.
>
> Ralf
>
>
It is a MIPS 4KEc core.
^ permalink raw reply
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