* Re: questions on struct sigcontext
From: David Daney @ 2007-12-13 0:06 UTC (permalink / raw)
To: Chris Friesen; +Cc: Daniel Jacobowitz, linux-mips, ralf
In-Reply-To: <47607327.5090709@nortel.com>
Chris Friesen wrote:
> Daniel Jacobowitz wrote:
>
>> There used to be slots for badvaddr and cause. You'll have to ask
>> Ralf why he decided to clobber them for DSP state, I don't remember
>> :-) I suspect they may never have held useful information for you;
>> we don't context switch them for userspace, so an intervening fault
>> in kernel space or in another thread could change them.
>
> I'm a bit confused as to how they would never have held useful
> information--did you mean the registers themselves, or the entries in
> struct sigcontext?
The entries in the sigcontext. As Ralf said, they never held valid values.
>
> If the cause/badvaddr entries in struct sigcontext were filled in by the
> exception handler in the kernel,
It would appear that they are not.
> wouldn't the values in that struct be
> completely valid even if the registers themselves were changed before
> userspace could handle the signal?
>
> If this is not the case then it seems like si_addr/si_code wouldn't be
> trustworthy either.
This I am not sure about :(, However knowing the values of all registers
(and perhaps /proc/self/maps) and $pc you can easily derive what happened.
David Daney
^ permalink raw reply
* Re: questions on struct sigcontext
From: Chris Friesen @ 2007-12-12 23:47 UTC (permalink / raw)
To: Daniel Jacobowitz; +Cc: linux-mips, ralf
In-Reply-To: <20071212190032.GA30506@caradoc.them.org>
Daniel Jacobowitz wrote:
> There used to be slots for badvaddr and cause. You'll have to ask
> Ralf why he decided to clobber them for DSP state, I don't remember
> :-) I suspect they may never have held useful information for you;
> we don't context switch them for userspace, so an intervening fault
> in kernel space or in another thread could change them.
I'm a bit confused as to how they would never have held useful
information--did you mean the registers themselves, or the entries in
struct sigcontext?
If the cause/badvaddr entries in struct sigcontext were filled in by the
exception handler in the kernel, wouldn't the values in that struct be
completely valid even if the registers themselves were changed before
userspace could handle the signal?
If this is not the case then it seems like si_addr/si_code wouldn't be
trustworthy either.
Chris
^ permalink raw reply
* Re: questions on struct sigcontext
From: Ralf Baechle @ 2007-12-12 19:04 UTC (permalink / raw)
To: Daniel Jacobowitz; +Cc: Chris Friesen, linux-mips
In-Reply-To: <20071212190032.GA30506@caradoc.them.org>
On Wed, Dec 12, 2007 at 02:00:32PM -0500, Daniel Jacobowitz wrote:
> There used to be slots for badvaddr and cause. You'll have to ask
> Ralf why he decided to clobber them for DSP state, I don't remember
> :-) I suspect they may never have held useful information for you;
> we don't context switch them for userspace, so an intervening fault
> in kernel space or in another thread could change them.
Correct, we never filled badvaddr and cause, so it was easy to recycle
those fields.
Ralf
^ permalink raw reply
* Re: questions on struct sigcontext
From: Daniel Jacobowitz @ 2007-12-12 19:00 UTC (permalink / raw)
To: Chris Friesen; +Cc: linux-mips, ralf
In-Reply-To: <47601DEE.4090200@nortel.com>
On Wed, Dec 12, 2007 at 11:44:14AM -0600, Chris Friesen wrote:
>
> Hi all,
>
> First, I'm not subscribed to the list so I'd appreciate being cc'd on any
> replies.
>
> We have a project getting started with MIPS, and one of the things that
> we're trying to bring in is some exception-handling code that logs
> various information about the ways that apps fail.
>
> In particular, the guys working on this have asked for the STATUS, CAUSE,
> BADVADDR, and FPC_EIR registers to be made available as part of struct
> sigcontext so that they can determine exactly why the app is failing.
>
> Looking at include/asm-mips/sigcontext.h I can see that these registers
> appear to be in the struct, but are either marked as "unused" or now have
> different names.
>
> Am I correct that these registers are not currently exported to userspace
> on a fault? If this is the case, why not? Does anyone have a patch to
> enable this export?
There used to be slots for badvaddr and cause. You'll have to ask
Ralf why he decided to clobber them for DSP state, I don't remember
:-) I suspect they may never have held useful information for you;
we don't context switch them for userspace, so an intervening fault
in kernel space or in another thread could change them.
FPC_EIR is, unless I misremember, constant and read only. You can
just read it.
--
Daniel Jacobowitz
CodeSourcery
^ permalink raw reply
* Re: questions on struct sigcontext
From: Ralf Baechle @ 2007-12-12 18:57 UTC (permalink / raw)
To: Chris Friesen; +Cc: linux-mips
In-Reply-To: <47601DEE.4090200@nortel.com>
On Wed, Dec 12, 2007 at 11:44:14AM -0600, Chris Friesen wrote:
> First, I'm not subscribed to the list so I'd appreciate being cc'd on any
> replies.
>
> We have a project getting started with MIPS, and one of the things that
> we're trying to bring in is some exception-handling code that logs various
> information about the ways that apps fail.
>
> In particular, the guys working on this have asked for the STATUS, CAUSE,
> BADVADDR, and FPC_EIR registers to be made available as part of struct
> sigcontext so that they can determine exactly why the app is failing.
The status register doesn't provide useful information about application
problems since it almost exclusivly affects kernel level operation. So
its not exported to userspace.
Cause I agree could occasionally be interesting. Historically the
Linux/MIPS stackframe is derived from the IRIX stackframe. But Linux/MIPS
did never populate the sc_cause field - no debugger or anything was using it.
So eventually the field got recycled for the DSP ASE. The hard part here
is finding place in the stackframe without breaking compatibility - and
there are other users competing ...
C0_badvaddr is available in the si_addr field of struct siginfo.
The FIR register is the "FP Implementation and Revision register" which is
read-only so the same for all processes. A debugger can access it at any
time and there is no need to waste space in the stack frame on it.
> Looking at include/asm-mips/sigcontext.h I can see that these registers
> appear to be in the struct, but are either marked as "unused" or now have
> different names.
>
> Am I correct that these registers are not currently exported to userspace
> on a fault? If this is the case, why not? Does anyone have a patch to
> enable this export?
Be very, very, very careful if you're changing struct siginfo. Applications
know about it. Iow if you change it the wrong way you break binary or
even source compatibility and usually that's in very subtle ways.
(Honestly, I hate our stackframe, especially the 32-bit one which is hell
of overbloated. I *wish* I could just scrap it but its one of those holy
cows - and I don't feel carnivorous enough yet to butcher it ;-)
Ralf
^ permalink raw reply
* Re: questions on struct sigcontext
From: David Daney @ 2007-12-12 18:44 UTC (permalink / raw)
To: Chris Friesen; +Cc: linux-mips
In-Reply-To: <476029AB.80702@nortel.com>
Chris Friesen wrote:
> David Daney wrote:
>
>> Most of the information is available. The si_addr and si_code of the
>> sigcontext are populated as well as the ucontext at the fault.
>
> I assume this should be siginfo rather than sigcontext?
Yes. In the three parameter form of the signal handler the second and
third parameters are pointers to the siginfo and ucontext.
>
>> Given all this and the code at $pc when the fault occurred, it is a
>> simple matter to determine what happened.
>
> Okay. I'll pass that information on and see if it's sufficient.
>
> Thanks,
>
> Chris
^ permalink raw reply
* Re: questions on struct sigcontext
From: Chris Friesen @ 2007-12-12 18:34 UTC (permalink / raw)
To: David Daney; +Cc: linux-mips
In-Reply-To: <47602471.9080706@avtrex.com>
David Daney wrote:
> Most of the information is available. The si_addr and si_code of the
> sigcontext are populated as well as the ucontext at the fault.
I assume this should be siginfo rather than sigcontext?
> Given all this and the code at $pc when the fault occurred, it is a
> simple matter to determine what happened.
Okay. I'll pass that information on and see if it's sufficient.
Thanks,
Chris
^ permalink raw reply
* Re: [UPDATED PATCH] IP28 support
From: Richard Sandiford @ 2007-12-12 18:22 UTC (permalink / raw)
To: peter fuerst; +Cc: Ralf Baechle, Thomas Bogendoerfer, Kumba, linux-mips
In-Reply-To: <87hcinlr8k.fsf@firetop.home>
Richard Sandiford <rsandifo@nildram.co.uk> writes:
> through KSEG2 or an uncached XKPHYS address, is it not also physically
er, I meant KSEG1 of course. Same mistake later.
Richard
^ permalink raw reply
* Re: questions on struct sigcontext
From: David Daney @ 2007-12-12 18:12 UTC (permalink / raw)
To: Chris Friesen; +Cc: linux-mips
In-Reply-To: <47601DEE.4090200@nortel.com>
Chris Friesen wrote:
>
> Hi all,
>
> First, I'm not subscribed to the list so I'd appreciate being cc'd on
> any replies.
>
> We have a project getting started with MIPS, and one of the things that
> we're trying to bring in is some exception-handling code that logs
> various information about the ways that apps fail.
>
> In particular, the guys working on this have asked for the STATUS,
> CAUSE, BADVADDR, and FPC_EIR registers to be made available as part of
> struct sigcontext so that they can determine exactly why the app is
> failing.
>
> Looking at include/asm-mips/sigcontext.h I can see that these registers
> appear to be in the struct, but are either marked as "unused" or now
> have different names.
>
> Am I correct that these registers are not currently exported to
> userspace on a fault?
No.
Most of the information is available. The si_addr and si_code of the
sigcontext are populated as well as the ucontext at the fault.
Given all this and the code at $pc when the fault occurred, it is a
simple matter to determine what happened.
I have seen some kernels patched so that an OOPS type dump was created
in the trap handler, but this doesn't really add anything to the
information that is already available in user space.
David Daney
^ permalink raw reply
* Re: [UPDATED PATCH] IP28 support
From: Richard Sandiford @ 2007-12-12 18:09 UTC (permalink / raw)
To: peter fuerst; +Cc: Ralf Baechle, Thomas Bogendoerfer, Kumba, linux-mips
In-Reply-To: <Pine.LNX.3.96.1071211004847.199A@PCD-4H>
peter fuerst <pf@pfrst.de> writes:
>> Ralf Baechle <ralf@linux-mips.org> writes:
>> >> Then there's the language-lawyerly code I gave to Peter on gcc-patches@:
>> >>
>> >> void foo (int x)
>> >> {
>> >> int array[1];
>> >> if (x)
>> >> bar (array[0x1fff]);
>> >> }
>> >>
>
> A strange method to pass data... Of course, cooking up such an "ABI",
> where local variables are accessed with a const offset that is not known at
> compile-time to be valid, would subvert the test for $sp-based accesses...
Well, as I said when I gave that example originally, it's unlikely that
the example would be written in that form. But hide the constants and
checks in configurable macros, and the general idea becomes a little
more feasible.
>> FWIW, my first cut at the option restrictions were based on what
>> the patch exempts (and doesn't exempt). We could instead get gcc
>> to only exempt accesses that it can prove are either to the current
>> function's stack frame or to its stack arguments. I.e. rather than
>> consider every $sp-based access to be safe, we'd instead do some
>
> "every $sp-based access" (set(mem(plus(sp)(const_int)))) is restricted
> to local variables too, with the constant offset being either
> - compiler-generated or
> - deliberately put in the source (however including the above example)
That's not literally true. SP+INT addresses can be used to access
stack arguments too, and 4.x can optimise some varargs accesses to
compile-time base+offset addresses. And as I said, the compiler is
free to make up accesses that aren't in fact valid for cases where
the access isn't made. E.g. if you had a loop with a stride of 128,
the compiler could unroll the loop as many times as it likes. Some
of the unrolled iterations might access areas outside the stack frame.
(You would hope that the compiler would be intelligent enough to crop
the iteration count in such cases, because the extra iterations should
never be used in valid code. But that isn't the point. The compiler
doesn't _need_ to crop the iteration count for correctness, and we're
talking about something we _do_ need for correctness.)
>> bounds checking on the value.
> Fine, if that is possible.
FWIW, the frame info is available in cfun->machine->frame at the time
your code runs.
>> (We could also use MEM_ATTRS to
>> pick up cases where a stack variable is acceesed via something
>> other than the stack or frame pointers, as happens for large frames.)
>
> Aren't these always accesses with non-constant offset, where a CB can't be
> avoided, even if they are recognized as being actually relative to $sp ?
The MEM_ATTRS I meant were MEM_EXPR + MEM_OFFSET, which only apply where
there is a known constant offset.
>> > In case of a hypothetic multi-platform kernel of which at least one needs
>> > the R10000 workarounds, all code would be uniformly compiled with the
>> > magic -mr10k-cache-barrier option and all source level workaround would
>> > be enabled.
>>
>> Hmm. This probably shows I am misunderstanding the problem, but I was
>> thinking about the IO-mapped case. I thought one of the problems was
>> that if you had a cached speculative load or store to an access-sensitive
>> IO-mapped address, the IO-mapped device might "see" that access even if it
>> doesn't take place. Could you not have a situation where a KSEG0 or
>> XKSEG0 access is access-sensitive on one machine and not another?
>> The patch won't insert countermeasures before symbolic and constant
>> addresses, because it believes all such addresses to be safe.
>>
>
> The threat to IO-addresses comes from the addressing register in the speculated
> mem-instruction (set(mem(plus(reg)...), containing one of the addresses as
> "garbage".
>
> Symbolic addresses are well defined from link-time on, no matter what history
> before the access. They either point (set(mem(plus(symbol_ref)...) to
> - some variable in the cached area, what is harmless (unless DMA-related),
> or to
> - IO-devices, accessed uncached, i.e. non-speculative,
> unless there is a programming-error ;)
> The same holds for const_int used as address.
I think you're missing my point. If you access an I/O-mapped device
through KSEG2 or an uncached XKPHYS address, is it not also physically
possible (though clearly unwise) to access it through KSEG0 or a cached
XKPHYS address too? So can you guarantee that every const_int cached
address in a multi-platform kernel is not I/O-mapped on any of the r10k
platforms? Or can you guarantee that the compiler will not manufacture
such an address from an otherwise harmless address? Again, the key thing
is to think about what the compiler can validly do on non-r10k platforms,
however silly it might seem, and then make sure the workarounds cope
with it.
>> I'm also a little worried that the compiler is free to make up accesses
>> that didn't exist in the original program, provided that those accesses
> The cache-barrier itself ?
No, in general. Optimisers (particularly loop optimisers) can invent
accesses that didn't exist in the original source code. Normally they
would only be executed in correct circumstances, but with this
speculative execution, that might not be true.
>> are never actually performed in cases where they'd be wrong. So how about:
>>
>> -mr10k-cache-barrier=load-store
>> Insert a cache barrier at the beginning of any sequentially-executed
>> series of instructions that contains a load or store. For the purposes
>> of this option, GCC can ignore loads and stores that it can prove
>> are an in-range access to:
>>
>> (a) the current function's stack frame;
>> (b) an incoming stack argument;
>> (b) an object with a link-time-constant address; or
>> (c) a block of uncached memory
> Can we recognize uncached memory in the instruction ?
Well, I was just thinking about teaching the compiler about KSEG2,
the always-uncached XKPHYS addresses, etc. (Sorry for messing up
the bullet letters there!) The idea is that we have a correlation
between symbolic constants and C objects, so we can check whether
an offset in a symbolic constant is within the object. We already
have code to do this in other situations. But there is no correlation
between const_int addresses and C objects, and we cannot be sure that
a given const_int address existed in the original source code, so
I think the only safe thing is to check its uncached properties instead.
I know all this must be frustrating. I'm sure your patches work great
as they are with current and past kernels, and current and past compilers.
The problem is that, if it becomes a mainline gcc feature, it needs to be
defined from first principles. And we need to do that without assuming
that the accesses we're looking at existed in the original source code.
FWIW, I'm happy to help update the patch once we've agreed on an
option spec.
Richard
^ permalink raw reply
* questions on struct sigcontext
From: Chris Friesen @ 2007-12-12 17:44 UTC (permalink / raw)
To: linux-mips, ralf
Hi all,
First, I'm not subscribed to the list so I'd appreciate being cc'd on
any replies.
We have a project getting started with MIPS, and one of the things that
we're trying to bring in is some exception-handling code that logs
various information about the ways that apps fail.
In particular, the guys working on this have asked for the STATUS,
CAUSE, BADVADDR, and FPC_EIR registers to be made available as part of
struct sigcontext so that they can determine exactly why the app is failing.
Looking at include/asm-mips/sigcontext.h I can see that these registers
appear to be in the struct, but are either marked as "unused" or now
have different names.
Am I correct that these registers are not currently exported to
userspace on a fault? If this is the case, why not? Does anyone have a
patch to enable this export?
It seems odd that mips app designers wouldn't want this information to
be made available.
Any information you can provide would be useful.
Chris
^ permalink raw reply
* Re: 2.6.24-rc2 crash in kmap_coherent
From: Giuseppe Sacco @ 2007-12-12 17:25 UTC (permalink / raw)
To: Ralf Baechle; +Cc: Florian Lohoff, linux-mips, David Daney
In-Reply-To: <1197479471.25499.48.camel@scarafaggio>
Il giorno mer, 12/12/2007 alle 18.11 +0100, Giuseppe Sacco ha scritto:
> Hi Ralf,
> the change you proposed here give an error since "page" is onlt
> available on function copy_user_highpage() while there is not such
> variable (nor parameter) in function copy_to_user_page().
[...]
Sorry, I meant the variable "from", not "page".
^ permalink raw reply
* Re: 2.6.24-rc2 crash in kmap_coherent
From: Giuseppe Sacco @ 2007-12-12 17:11 UTC (permalink / raw)
To: Ralf Baechle; +Cc: Florian Lohoff, linux-mips, David Daney
In-Reply-To: <20071212153218.GA30291@linux-mips.org>
Hi Ralf,
the change you proposed here give an error since "page" is onlt
available on function copy_user_highpage() while there is not such
variable (nor parameter) in function copy_to_user_page().
I am actually recompiling everything using only the first part of your
patch, but I think it will not be enough.
Bye,
Giuseppe
Il giorno mer, 12/12/2007 alle 15.32 +0000, Ralf Baechle ha scritto:
[...]
> Totally untested because I have other stuff to do but something along the
> lines of below patch, I think.
>
> Ralf
>
> diff --git a/arch/mips/mm/init.c b/arch/mips/mm/init.c
> index 480dec0..db5d608 100644
> --- a/arch/mips/mm/init.c
> +++ b/arch/mips/mm/init.c
> @@ -211,7 +211,8 @@ void copy_user_highpage(struct page *to, struct page *from,
> void *vfrom, *vto;
>
> vto = kmap_atomic(to, KM_USER1);
> - if (cpu_has_dc_aliases && page_mapped(from)) {
> + if (cpu_has_dc_aliases &&
> + page_mapped(from) && !Page_dcache_dirty(from)) {
> vfrom = kmap_coherent(from, vaddr);
> copy_page(vto, vfrom);
> kunmap_coherent();
> @@ -234,7 +235,8 @@ void copy_to_user_page(struct vm_area_struct *vma,
> struct page *page, unsigned long vaddr, void *dst, const void *src,
> unsigned long len)
> {
> - if (cpu_has_dc_aliases && page_mapped(page)) {
> + if (cpu_has_dc_aliases &&
> + page_mapped(page) && !Page_dcache_dirty(from)) {
> void *vto = kmap_coherent(page, vaddr) + (vaddr & ~PAGE_MASK);
> memcpy(vto, src, len);
> kunmap_coherent();
> @@ -253,7 +255,8 @@ void copy_from_user_page(struct vm_area_struct *vma,
> struct page *page, unsigned long vaddr, void *dst, const void *src,
> unsigned long len)
> {
> - if (cpu_has_dc_aliases && page_mapped(page)) {
> + if (cpu_has_dc_aliases &&
> + page_mapped(page) && !Page_dcache_dirty(page)) {
> void *vfrom = kmap_coherent(page, vaddr) + (vaddr & ~PAGE_MASK);
> memcpy(dst, vfrom, len);
> kunmap_coherent();
>
>
^ permalink raw reply
* Re: 2.6.24-rc2 crash in kmap_coherent
From: Ralf Baechle @ 2007-12-12 15:32 UTC (permalink / raw)
To: Florian Lohoff; +Cc: linux-mips, David Daney
In-Reply-To: <20071212120610.GB28868@linux-mips.org>
On Wed, Dec 12, 2007 at 12:06:10PM +0000, Ralf Baechle wrote:
> > Call Trace:
> > [<ffffffff8801bcf0>] kmap_coherent+0x10/0x130
> > [<ffffffff8801c010>] copy_from_user_page+0x40/0xb0
> > [<ffffffff88079d10>] access_process_vm+0x168/0x1d8
> > [<ffffffff880d9014>] proc_pid_cmdline+0xac/0x140
> > [<ffffffff880db188>] proc_info_read+0x108/0x150
> > [<ffffffff8808fbdc>] vfs_read+0xec/0x178
> > [<ffffffff88090060>] sys_read+0x50/0x98
> > [<ffffffff88019718>] handle_sys+0x118/0x134
> >
> >
> > Code: 0002127a 00021000 30420001 <00028036> 8f820024 3c038843 24420001 af820024 dc62f390
>
> Hmm... This suggests that 283abbaef425c1bf817ecbb456c413cab08b1434 is
> not quite right. It is making the assumption that a mapped page never has
> PG_dcache_dirty set.
Totally untested because I have other stuff to do but something along the
lines of below patch, I think.
Ralf
diff --git a/arch/mips/mm/init.c b/arch/mips/mm/init.c
index 480dec0..db5d608 100644
--- a/arch/mips/mm/init.c
+++ b/arch/mips/mm/init.c
@@ -211,7 +211,8 @@ void copy_user_highpage(struct page *to, struct page *from,
void *vfrom, *vto;
vto = kmap_atomic(to, KM_USER1);
- if (cpu_has_dc_aliases && page_mapped(from)) {
+ if (cpu_has_dc_aliases &&
+ page_mapped(from) && !Page_dcache_dirty(from)) {
vfrom = kmap_coherent(from, vaddr);
copy_page(vto, vfrom);
kunmap_coherent();
@@ -234,7 +235,8 @@ void copy_to_user_page(struct vm_area_struct *vma,
struct page *page, unsigned long vaddr, void *dst, const void *src,
unsigned long len)
{
- if (cpu_has_dc_aliases && page_mapped(page)) {
+ if (cpu_has_dc_aliases &&
+ page_mapped(page) && !Page_dcache_dirty(from)) {
void *vto = kmap_coherent(page, vaddr) + (vaddr & ~PAGE_MASK);
memcpy(vto, src, len);
kunmap_coherent();
@@ -253,7 +255,8 @@ void copy_from_user_page(struct vm_area_struct *vma,
struct page *page, unsigned long vaddr, void *dst, const void *src,
unsigned long len)
{
- if (cpu_has_dc_aliases && page_mapped(page)) {
+ if (cpu_has_dc_aliases &&
+ page_mapped(page) && !Page_dcache_dirty(page)) {
void *vfrom = kmap_coherent(page, vaddr) + (vaddr & ~PAGE_MASK);
memcpy(dst, vfrom, len);
kunmap_coherent();
^ permalink raw reply related
* Re: [UPDATED PATCH] IP28 support
From: peter fuerst @ 2007-12-12 15:26 UTC (permalink / raw)
To: Richard Sandiford; +Cc: Ralf Baechle, Thomas Bogendoerfer, Kumba, linux-mips
In-Reply-To: <871w9u24rd.fsf@firetop.home>
On Mon, 10 Dec 2007, Richard Sandiford wrote:
> Ralf Baechle <ralf@linux-mips.org> writes:
> >> Then there's the language-lawyerly code I gave to Peter on gcc-patches@:
> >>
> >> void foo (int x)
> >> {
> >> int array[1];
> >> if (x)
> >> bar (array[0x1fff]);
> >> }
> >>
A strange method to pass data... Of course, cooking up such an "ABI",
where local variables are accessed with a const offset that is not known at
compile-time to be valid, would subvert the test for $sp-based accesses...
> >> This function is valid if x is never true, so we cannot assume that all
> >> accesses off the stack and frame pointers are actually in-frame. You're
> >> assuming either (i) the kernel doesn't use code like that or (ii) that
> >> "garbage" addresses in the range [$sp - 0x8000, $sp + 0x7fff] will not
> >> trigger the problem. I imagine both are reasonable assumptions, and I'm
> >> perfectly happy for us to make them. But they're the kind of assumption
> >> we need to state explicitly.
> >
> > Interesting test case. I've been thinking about it myself but in the end
> > decieded to believe Peter's analysis since he's banged the head for longer
> > to the wall about this problem that I have ;-) I'm quite but not absolutely
> > certain that this case cannot happen for realworld code, so I'd rather
> > err on the side of caution.
> >
> > Peter & Thomas - we could make the stack thing bullet proof by vmallocing
> > stacks and ensuring a sufficient virtual address gap exists around the stack
> > such that the stack is the only addressable thing in the range of
> > $sp +0x7fff / -0x8000?
...but having an address-gap, virtual or by unused memory, should make it save
even with such code.
Typical "realworld" examples for speculative access to stack-variables are
void foo (int x) void foo ()
{ {
int array[N]; int array[N], i;
if (x < N) for (i = 0; i < N; i++)
bar (array[x]); array[i] = 0;
} }
i.e. accesses with non-const offsets, i.e. no longer $sp-based, which always
will trigger a CB.
>
> FWIW, my first cut at the option restrictions were based on what
> the patch exempts (and doesn't exempt). We could instead get gcc
> to only exempt accesses that it can prove are either to the current
> function's stack frame or to its stack arguments. I.e. rather than
> consider every $sp-based access to be safe, we'd instead do some
"every $sp-based access" (set(mem(plus(sp)(const_int)))) is restricted
to local variables too, with the constant offset being either
- compiler-generated or
- deliberately put in the source (however including the above example)
> bounds checking on the value.
Fine, if that is possible.
> (We could also use MEM_ATTRS to
> pick up cases where a stack variable is acceesed via something
> other than the stack or frame pointers, as happens for large frames.)
Aren't these always accesses with non-constant offset, where a CB can't be
avoided, even if they are recognized as being actually relative to $sp ?
>
> >> Peter's patch also treated accesses to constant integer and symbolic
> >> addresses as safe. Again, this involves making assumptions about how
> >> constant integer and symbolic addresses are used, and this is a much
> >> less obvious assumption than the stack one.
> >
> > The latter assumption is also needed for -msym32 kernels, so it's well
> > proven to be valid. The former hold, too.
> >
> >> Again, I understand that
> >> it's a reasonable assumption to make in the linux context, but it's one
> >> we need to pin down. E.g. there must be no run-time guarding of
> >> target-specific constant integer IO-mapped addresses in cases where
> >> those addresses might trigger the problem on other systems that the
> >> same kernel image supports.
> >
> > In case of a hypothetic multi-platform kernel of which at least one needs
> > the R10000 workarounds, all code would be uniformly compiled with the
> > magic -mr10k-cache-barrier option and all source level workaround would
> > be enabled.
>
> Hmm. This probably shows I am misunderstanding the problem, but I was
> thinking about the IO-mapped case. I thought one of the problems was
> that if you had a cached speculative load or store to an access-sensitive
> IO-mapped address, the IO-mapped device might "see" that access even if it
> doesn't take place. Could you not have a situation where a KSEG0 or
> XKSEG0 access is access-sensitive on one machine and not another?
> The patch won't insert countermeasures before symbolic and constant
> addresses, because it believes all such addresses to be safe.
>
The threat to IO-addresses comes from the addressing register in the speculated
mem-instruction (set(mem(plus(reg)...), containing one of the addresses as
"garbage".
Symbolic addresses are well defined from link-time on, no matter what history
before the access. They either point (set(mem(plus(symbol_ref)...) to
- some variable in the cached area, what is harmless (unless DMA-related),
or to
- IO-devices, accessed uncached, i.e. non-speculative,
unless there is a programming-error ;)
The same holds for const_int used as address.
If used for DMA and also directly accessed, symbolic addresses could be
problematic though:
extern char big_fat_dma_buffer[N];
if (!dma_running)
*big_fat_dma_buffer = 0;
else
...
(However, as soon as accessed with non-constant offset - e.g. in a loop,... -
the symbol_ref disappears from the mem-instruction which will trigger a CB)
Btw. with 4.x symbolic addresses are practically (without backtrace analysis)
not exempted from CBs, since they no longer show up in the mem-instruction
and (set(mem(lo_sum(reg)... is seen instead.
> I'm also a little worried that the compiler is free to make up accesses
> that didn't exist in the original program, provided that those accesses
The cache-barrier itself ?
> are never actually performed in cases where they'd be wrong. So how about:
>
> -mr10k-cache-barrier=load-store
> Insert a cache barrier at the beginning of any sequentially-executed
> series of instructions that contains a load or store. For the purposes
> of this option, GCC can ignore loads and stores that it can prove
> are an in-range access to:
>
> (a) the current function's stack frame;
> (b) an incoming stack argument;
> (b) an object with a link-time-constant address; or
> (c) a block of uncached memory
Can we recognize uncached memory in the instruction ?
>
> It can also ignore sequences that are always immediately preceded by
> an untaken branch-likely instruction.
Fine!
>
> Here, a ``sequentially-executed series'' is one in which calls,
> jumps and branches occur only as the last instruction.
>
> -mr10k-cache-barrier=store
> Like -mr10k-cache-barrier=load-store, but ignore all loads.
>
> -mr10k-cache-barrier=none
> ...
>
> Richard
>
>
>
kind regards
peter
^ permalink raw reply
* [PATCH][MIPS] move the eXcite local config to excitedirectory
From: Yoichi Yuasa @ 2007-12-12 13:39 UTC (permalink / raw)
To: Ralf Baechle; +Cc: yoichi_yuasa, linux-mips
Moved the eXcite local config to excite directory.
Signed-off-by: Yoichi Yuasa <yoichi_yuasa@tripeaks.co.jp>
diff -pruN -X mips/Documentation/dontdiff mips-orig/arch/mips/Kconfig mips/arch/mips/Kconfig
--- mips-orig/arch/mips/Kconfig 2007-12-12 00:06:19.245069500 +0900
+++ mips/arch/mips/Kconfig 2007-12-12 00:09:53.974489250 +0900
@@ -37,16 +37,6 @@ config BASLER_EXCITE
The eXcite is a smart camera platform manufactured by
Basler Vision Technologies AG.
-config BASLER_EXCITE_PROTOTYPE
- bool "Support for pre-release units"
- depends on BASLER_EXCITE
- default n
- help
- Pre-series (prototype) units are different from later ones in
- some ways. Select this option if you have one of these. Please
- note that a kernel built with this option selected will not be
- able to run on normal units.
-
config BCM47XX
bool "BCM47XX based boards"
select CEVT_R4K
@@ -688,6 +678,7 @@ config WR_PPMC
endchoice
source "arch/mips/au1000/Kconfig"
+source "arch/mips/basler/excite/Kconfig"
source "arch/mips/jazz/Kconfig"
source "arch/mips/lasat/Kconfig"
source "arch/mips/pmc-sierra/Kconfig"
diff -pruN -X mips/Documentation/dontdiff mips-orig/arch/mips/basler/excite/Kconfig mips/arch/mips/basler/excite/Kconfig
--- mips-orig/arch/mips/basler/excite/Kconfig 1970-01-01 09:00:00.000000000 +0900
+++ mips/arch/mips/basler/excite/Kconfig 2007-12-12 00:09:53.974489250 +0900
@@ -0,0 +1,9 @@
+config BASLER_EXCITE_PROTOTYPE
+ bool "Support for pre-release units"
+ depends on BASLER_EXCITE
+ default n
+ help
+ Pre-series (prototype) units are different from later ones in
+ some ways. Select this option if you have one of these. Please
+ note that a kernel built with this option selected will not be
+ able to run on normal units.
^ permalink raw reply
* [PATCH][2/2][MIPS] add cpu_wait() to machine_halt()
From: Yoichi Yuasa @ 2007-12-12 13:23 UTC (permalink / raw)
To: Ralf Baechle; +Cc: yoichi_yuasa, linux-mips
In-Reply-To: <20071212222019.9ab7b2ed.yoichi_yuasa@tripeaks.co.jp>
Added cpu_wait() to machine_halt().
For the power reduction in halt.
Signed-off-by: Yoichi Yuasa <yoichi_yuasa@tripeaks.co.jp>
diff -pruN -X mips/Documentation/dontdiff mips-orig/arch/mips/cobalt/reset.c mips/arch/mips/cobalt/reset.c
--- mips-orig/arch/mips/cobalt/reset.c 2007-10-22 09:32:10.074729000 +0900
+++ mips/arch/mips/cobalt/reset.c 2007-10-22 09:59:23.092786250 +0900
@@ -12,6 +12,8 @@
#include <linux/io.h>
#include <linux/leds.h>
+#include <asm/processor.h>
+
#include <cobalt.h>
#define RESET_PORT ((void __iomem *)CKSEG1ADDR(0x1c000000))
@@ -35,7 +37,10 @@ void cobalt_machine_halt(void)
local_irq_disable();
printk(KERN_INFO "You can switch the machine off now.\n");
- while (1) ;
+ while (1) {
+ if (cpu_wait)
+ cpu_wait();
+ }
}
void cobalt_machine_restart(char *command)
^ permalink raw reply
* [PATCH][1/2][MIPS] remove unneeded button check for reset
From: Yoichi Yuasa @ 2007-12-12 13:20 UTC (permalink / raw)
To: Ralf Baechle; +Cc: yoichi_yuasa, linux-mips
Removed unneeded button check for reset.
Because, the Cobalt has power switch.
Signed-off-by: Yoichi Yuasa <yoichi_yuasa@tripeaks.co.jp>
diff -pruN -X mips/Documentation/dontdiff mips-orig/arch/mips/cobalt/reset.c mips/arch/mips/cobalt/reset.c
--- mips-orig/arch/mips/cobalt/reset.c 2007-10-22 08:37:03.176567500 +0900
+++ mips/arch/mips/cobalt/reset.c 2007-10-22 09:28:23.004538000 +0900
@@ -10,7 +10,6 @@
*/
#include <linux/init.h>
#include <linux/io.h>
-#include <linux/jiffies.h>
#include <linux/leds.h>
#include <cobalt.h>
@@ -29,29 +28,14 @@ device_initcall(ledtrig_power_off_init);
void cobalt_machine_halt(void)
{
- int state, last, diff;
- unsigned long mark;
-
/*
* turn on power off LED on RaQ
- *
- * restart if ENTER and SELECT are pressed
*/
-
- last = COBALT_KEY_PORT;
-
led_trigger_event(power_off_led_trigger, LED_FULL);
- for (state = 0;;) {
- diff = COBALT_KEY_PORT ^ last;
- last ^= diff;
-
- if((diff & (COBALT_KEY_ENTER | COBALT_KEY_SELECT)) && !(~last & (COBALT_KEY_ENTER | COBALT_KEY_SELECT)))
- writeb(RESET, RESET_PORT);
-
- for (mark = jiffies; jiffies - mark < HZ;)
- ;
- }
+ local_irq_disable();
+ printk(KERN_INFO "You can switch the machine off now.\n");
+ while (1) ;
}
void cobalt_machine_restart(char *command)
diff -pruN -X mips/Documentation/dontdiff mips-orig/include/asm-mips/mach-cobalt/cobalt.h mips/include/asm-mips/mach-cobalt/cobalt.h
--- mips-orig/include/asm-mips/mach-cobalt/cobalt.h 2007-10-22 08:40:46.866547250 +0900
+++ mips/include/asm-mips/mach-cobalt/cobalt.h 2007-10-22 09:27:42.101981750 +0900
@@ -1,5 +1,5 @@
/*
- * Lowlevel hardware stuff for the MIPS based Cobalt microservers.
+ * The Cobalt board ID information.
*
* This file is subject to the terms and conditions of the GNU General Public
* License. See the file "COPYING" in the main directory of this archive
@@ -12,9 +12,6 @@
#ifndef __ASM_COBALT_H
#define __ASM_COBALT_H
-/*
- * The Cobalt board ID information.
- */
extern int cobalt_board_id;
#define COBALT_BRD_ID_QUBE1 0x3
@@ -22,14 +19,4 @@ extern int cobalt_board_id;
#define COBALT_BRD_ID_QUBE2 0x5
#define COBALT_BRD_ID_RAQ2 0x6
-#define COBALT_KEY_PORT ((~*(volatile unsigned int *) CKSEG1ADDR(0x1d000000) >> 24) & COBALT_KEY_MASK)
-# define COBALT_KEY_CLEAR (1 << 1)
-# define COBALT_KEY_LEFT (1 << 2)
-# define COBALT_KEY_UP (1 << 3)
-# define COBALT_KEY_DOWN (1 << 4)
-# define COBALT_KEY_RIGHT (1 << 5)
-# define COBALT_KEY_ENTER (1 << 6)
-# define COBALT_KEY_SELECT (1 << 7)
-# define COBALT_KEY_MASK 0xfe
-
#endif /* __ASM_COBALT_H */
^ permalink raw reply
* [PATCH][MIPS] move vr41xx_calculate_clock_frequency() to plat_time_init()
From: Yoichi Yuasa @ 2007-12-12 13:11 UTC (permalink / raw)
To: Ralf Baechle; +Cc: yoichi_yuasa, linux-mips
Moved vr41xx_calculate_clock_frequency() to plat_time_init().
This function relates to the timer function.
Signed-off-by: Yoichi Yuasa <yoichi_yuasa@tripeaks.co.jp>
diff -pruN -X mips/Documentation/dontdiff mips-orig/arch/mips/vr41xx/common/init.c mips/arch/mips/vr41xx/common/init.c
--- mips-orig/arch/mips/vr41xx/common/init.c 2007-10-25 07:34:48.001908250 +0900
+++ mips/arch/mips/vr41xx/common/init.c 2007-10-25 07:49:57.538750750 +0900
@@ -40,6 +40,8 @@ void __init plat_time_init(void)
{
unsigned long tclock;
+ vr41xx_calculate_clock_frequency();
+
tclock = vr41xx_get_tclock_frequency();
if (current_cpu_data.processor_id == PRID_VR4131_REV2_0 ||
current_cpu_data.processor_id == PRID_VR4131_REV2_1)
@@ -50,8 +52,6 @@ void __init plat_time_init(void)
void __init plat_mem_setup(void)
{
- vr41xx_calculate_clock_frequency();
-
iomem_resource_init();
}
^ permalink raw reply
* Re: 2.6.24-rc2 crash in kmap_coherent
From: Ralf Baechle @ 2007-12-12 12:06 UTC (permalink / raw)
To: Florian Lohoff; +Cc: linux-mips, David Daney
In-Reply-To: <20071211221327.GB2150@paradigm.rfc822.org>
On Tue, Dec 11, 2007 at 11:13:27PM +0100, Florian Lohoff wrote:
> Call Trace:
> [<ffffffff8801bcf0>] kmap_coherent+0x10/0x130
> [<ffffffff8801c010>] copy_from_user_page+0x40/0xb0
> [<ffffffff88079d10>] access_process_vm+0x168/0x1d8
> [<ffffffff880d9014>] proc_pid_cmdline+0xac/0x140
> [<ffffffff880db188>] proc_info_read+0x108/0x150
> [<ffffffff8808fbdc>] vfs_read+0xec/0x178
> [<ffffffff88090060>] sys_read+0x50/0x98
> [<ffffffff88019718>] handle_sys+0x118/0x134
>
>
> Code: 0002127a 00021000 30420001 <00028036> 8f820024 3c038843 24420001 af820024 dc62f390
Hmm... This suggests that 283abbaef425c1bf817ecbb456c413cab08b1434 is
not quite right. It is making the assumption that a mapped page never has
PG_dcache_dirty set.
Ralf
^ permalink raw reply
* Re: Cobalt fixes
From: Ralf Baechle @ 2007-12-12 11:23 UTC (permalink / raw)
To: Yoichi Yuasa; +Cc: linux-mips
In-Reply-To: <20071212075309.5172da92.yoichi_yuasa@tripeaks.co.jp>
On Wed, Dec 12, 2007 at 07:53:09AM +0900, Yoichi Yuasa wrote:
> > > > for non-subscribers. Linus has reverted the offending patch
> > > > fd6e732186ab522c812ab19c2c5e5befb8ec8115 in question so now the PCI and
> > > > I/O port code needs to be fixed up to be able to handle such a setup.
> > >
> > > It can be fixed my fix PCI resource patch.
> > >
> > > http://www.linux-mips.org/archives/linux-mips/2007-01/msg00049.html
> >
> > Modulo a codying style issue that one is the same as the pci.c segment of
> > the patch I've just posted.
>
> This is a fix proposed before fd6e732186ab522c812ab19c2c5e5befb8ec8115.
> This patch is still effective.
Ah, I had already applied the identical patch yesterday. Thanks anyway!
But it should be considered temporary. For some configurations there is
no chance for this to work and the patch will probably get in my way for
the planned rewrite of the resource allocation.
Ralf
^ permalink raw reply
* Re: 2.6.24-rc2 crash in kmap_coherent
From: David Daney @ 2007-12-12 6:40 UTC (permalink / raw)
To: linux-mips; +Cc: Florian Lohoff
In-Reply-To: <475F13F1.2050109@avtrex.com>
David Daney wrote:
> Florian Lohoff wrote:
>> Hi,
>> i just discovered that my native gcc build on one of my Indys stopped. I
>> found this in the dmesg ;)
>>
>> Its a 2.6.24-rc2 on an R5k Indy 64M:
>>
>> Kernel bug detected[#1]:
>> Cpu 0
>> $ 0 : 0000000000000000 ffffffff9000cce0 0000000000000001
>> ffffffff80000000
>> $ 4 : ffffffff8921f910 000000007fda0f05 000000007fda0f05
>> ffffffff8b8ea000
>> $ 8 : ffffffff89b4ef05 000000000000000e ffffffff8921f910
>> 0000000000000f05
>> $12 : 0000000000000000 ffffffff80000008 ffffffff88090010
>> 00000000004038b4
>> $16 : ffffffff8921f910 000000007fda0f05 ffffffff8b8ea000
>> 000000000000000e
>> $20 : ffffffff8bdfb920 0000000000000000 ffffffff8bd88cc0
>> ffffffff8893fd58
>> $24 : 0000000000000006
>> ffffffff8801df00 $28 :
>> ffffffff8893c000 ffffffff8893fd20 ffffffff88430000 ffffffff8801c010
>> Hi : 000000000001d1ea
>> Lo : 0000000000009b4e
>> epc : ffffffff8801bcf0 kmap_coherent+0x10/0x130 Not tainted
>> ra : ffffffff8801c010 copy_from_user_page+0x40/0xb0
>> Status: 9000cce3 KX SX UX KERNEL EXL IE Cause : 00000034
>> PrId : 00002321 (R5000)
>> Modules linked in: dm_snapshot dm_mirror dm_mod ipv6
>> Process cat (pid: 14553, threadinfo=ffffffff8893c000,
>> task=ffffffff88a52660)
>> Stack : 000000000000000e 000000007fda0f05 ffffffff8b8ea000
>> 0000000000000000
>> ffffffff88079d10 ffffffff88079cc4 ffffffff8bfbd528
>> ffffffff8921f910
>> ffffffff8bdfb980 ffffffff8b8ea000 ffffffff8bdfb920
>> 0000000000000000
>> ffffffff8b8ea000 000000000000000e ffffffff8bd88cc0
>> ffffffff8893fe78
>> 0000000000447000 000000000052c7d8 0000000000000000
>> ffffffff880d9014
>> ffffffff8bd88cc0 ffffffff8b8ea000 fffffffffffffff4
>> ffffffff8b863248
>> 0000000000000400 ffffffff8893fe78 0000000000447000
>> ffffffff880db188
>> ffffffff8be6f6e0 0000000000000400 0000000000447000
>> ffffffff8893fe78
>> 0000000000447000 0000000000000003 0000000000000016
>> ffffffff8808fbdc
>> ffffffff8be6f6e0 0000000000000400 0000000000447000
>> fffffffffffffff7
>> ...
>> Call Trace:
>> [<ffffffff8801bcf0>] kmap_coherent+0x10/0x130
>> [<ffffffff8801c010>] copy_from_user_page+0x40/0xb0
>> [<ffffffff88079d10>] access_process_vm+0x168/0x1d8
>> [<ffffffff880d9014>] proc_pid_cmdline+0xac/0x140
>> [<ffffffff880db188>] proc_info_read+0x108/0x150
>> [<ffffffff8808fbdc>] vfs_read+0xec/0x178
>> [<ffffffff88090060>] sys_read+0x50/0x98
>> [<ffffffff88019718>] handle_sys+0x118/0x134
>>
>>
>> Code: 0002127a 00021000 30420001 <00028036> 8f820024 3c038843
>> 24420001 af820024 dc62f390
>
> FWIW I get something very similar reading /proc/1/cmdline on
> 2.6.23-1/ip32 w/ R5000 and there have been other similar postings here
> recently.
>
> Maybe one day I will look into it, but it probably will not be real
> soon...
>
Here is some further data:
# cat /proc/version
Linux version 2.6.23.1-DD_Patched (daney@silver64.hq2.avtrex.com) (gcc
version 4.2.3 20071029 (prerelease)) #7 Sun Oct 28 23:40:58 PDT 2007
# cat /proc/cpuinfo
system type : SGI O2
processor : 0
cpu model : R5000 V2.1 FPU V1.0
BogoMIPS : 199.68
wait instruction : yes
microsecond timers : yes
tlb_entries : 48
extra interrupt vector : no
hardware watchpoint : no
ASEs implemented :
VCED exceptions : not available
VCEI exceptions : not available
Kernel bug detected[#3]:
Cpu 0
$ 0 : 0000000000000000 ffffffff80450000 0000000000000001 0000000000002ee4
$ 4 : 980000000116f2f8 000000007ffc3ee4 00000000068e9603 0000000000100177
$ 8 : 000000007ffc3ee4 000000000000000e 0000000000000000 9800000005e7bd60
$12 : 0000000000000000 ffffffff80000008 ffffffff800a4958 00000000004038b4
$16 : 980000000116f2f8 000000000000000e 980000000d9a02a8 000000007ffc3ee4
$20 : 980000000bba2ce8 980000000b402cc0 9800000005e7bd60 9800000005e7bd68
$24 : 0000000000000006 000000002ab9d1f4
$28 : 9800000005e78000 9800000005e7bcc0 0000000000000000 ffffffff8001db68
Hi : 0000000000013abb
Lo : 00000000000068e9
epc : ffffffff8001f370 kmap_coherent+0x10/0x128 Tainted: G D
ra : ffffffff8001db68 __flush_anon_page+0x90/0xc0
Status: b001fce3 KX SX UX KERNEL EXL IE
Cause : 00000034
PrId : 00002321
Modules linked in: ipv6 dm_snapshot dm_mirror dm_mod sg evdev
Process cat (pid: 2851, threadinfo=9800000005e78000, task=980000000bd08cc8)
Stack : ffffffff8008a4a0 ffffffff8008a0c0 0000000000000001 0000000000000000
9800000005e7bd68 9800000005e7bd60 0000000000000010 0000000000000006
000000000000000e 0000000000000044 980000000b402cc0 980000000978d000
0000000000000012 000000007ffc3ee4 980000000978d000 0000000000000012
980000000b402cc0 0000000000000000 980000000bba2ce8 ffffffff8008a650
0000000000000000 980000000116f2f8 980000000b402d20 980000000978d000
980000000b402cc0 980000000978d000 0000000000000012 0000000000000000
980000000bba2ce8 0000000000448000 0000000000001000 0000000000530328
0000000000000000 ffffffff800f8c20 980000000978d000 980000000bba2ce8
9800000009a49920 0000000000000400 9800000005e7be88 0000000000448000
...
Call Trace:
[<ffffffff8001f370>] kmap_coherent+0x10/0x128
[<ffffffff8001db68>] __flush_anon_page+0x90/0xc0
[<ffffffff8008a4a0>] get_user_pages+0x478/0x4f8
[<ffffffff8008a650>] access_process_vm+0x130/0x230
[<ffffffff800f8c20>] proc_pid_cmdline+0xa8/0x170
[<ffffffff800fb368>] proc_info_read+0x120/0x190
[<ffffffff800a44b8>] vfs_read+0xc0/0x160
[<ffffffff800a49a0>] sys_read+0x48/0xb0
[<ffffffff8001c7b4>] handle_sys+0x134/0x150
Code: 0002127a 00021000 30420001 <00028036> 8f820024 00052b3a
24420001 af820024 3c0236db
This is the result of doing: cat /proc/2818/cmdline
2818 is sshd, but I think that does not really matter. Before any pages
had been swapped out I was able to get the command line. Then I did
some work (run gdb on a very large program) that caused some pages to be
swapped out. After that the cat fails with a SIGSEGV in sys_read and
the above trace is produced.
My theory is that if the page containing the command line is present,
all is OK, but if it has been swapped out this happens. However if I
turn off the swap device after the first occurrence of the problem, it
does not seem to correct itself, so I don't really know what is causing it.
The fault is caused by a 'tne' instruction in the first statement of
kmap_coherent in arch/mips/mm/init.c:
BUG_ON(Page_dcache_dirty(page));
There seems to be a bit of a logic error here:
void __flush_anon_page(struct page *page, unsigned long vmaddr)
{
if (pages_do_alias((unsigned long)page_address(page), vmaddr)) {
void *kaddr;
kaddr = kmap_coherent(page, vmaddr);
flush_data_cache_page((unsigned long)kaddr);
kunmap_coherent();
}
}
We are calling kmap_coherent so that we can flush the cache for the
page, but the first thing kmap_coherent does is BUG_ON if the cache is
dirty...
^ permalink raw reply
* Re: Cobalt fixes
From: Yoichi Yuasa @ 2007-12-11 22:53 UTC (permalink / raw)
To: Ralf Baechle; +Cc: yoichi_yuasa, linux-mips
In-Reply-To: <20071211153522.GB15843@linux-mips.org>
On Tue, 11 Dec 2007 15:35:22 +0000
Ralf Baechle <ralf@linux-mips.org> wrote:
> On Tue, Dec 11, 2007 at 11:50:01PM +0900, Yoichi Yuasa wrote:
>
> > > for non-subscribers. Linus has reverted the offending patch
> > > fd6e732186ab522c812ab19c2c5e5befb8ec8115 in question so now the PCI and
> > > I/O port code needs to be fixed up to be able to handle such a setup.
> >
> > It can be fixed my fix PCI resource patch.
> >
> > http://www.linux-mips.org/archives/linux-mips/2007-01/msg00049.html
>
> Modulo a codying style issue that one is the same as the pci.c segment of
> the patch I've just posted.
This is a fix proposed before fd6e732186ab522c812ab19c2c5e5befb8ec8115.
This patch is still effective.
Fixed line offset and coding style.
Signed-off-by: Yoichi Yuasa <yoichi_yuasa@tripeaks.co.jp>
diff -pruN -X mips/Documentation/dontdiff mips-orig/arch/mips/pci/pci.c mips/arch/mips/pci/pci.c
--- mips-orig/arch/mips/pci/pci.c 2007-12-12 06:48:44.282421000 +0900
+++ mips/arch/mips/pci/pci.c 2007-12-12 06:54:51.041342000 +0900
@@ -242,6 +242,8 @@ static void pcibios_fixup_device_resourc
for (i = 0; i < PCI_NUM_RESOURCES; i++) {
if (!dev->resource[i].start)
continue;
+ if (dev->resource[i].flags & IORESOURCE_PCI_FIXED)
+ continue;
if (dev->resource[i].flags & IORESOURCE_IO)
offset = hose->io_offset;
else if (dev->resource[i].flags & IORESOURCE_MEM)
^ permalink raw reply
* Re: 2.6.24-rc2 crash in kmap_coherent
From: David Daney @ 2007-12-11 22:49 UTC (permalink / raw)
To: Florian Lohoff; +Cc: linux-mips
In-Reply-To: <20071211221327.GB2150@paradigm.rfc822.org>
Florian Lohoff wrote:
> Hi,
> i just discovered that my native gcc build on one of my Indys stopped. I
> found this in the dmesg ;)
>
> Its a 2.6.24-rc2 on an R5k Indy 64M:
>
> Kernel bug detected[#1]:
> Cpu 0
> $ 0 : 0000000000000000 ffffffff9000cce0 0000000000000001 ffffffff80000000
> $ 4 : ffffffff8921f910 000000007fda0f05 000000007fda0f05 ffffffff8b8ea000
> $ 8 : ffffffff89b4ef05 000000000000000e ffffffff8921f910 0000000000000f05
> $12 : 0000000000000000 ffffffff80000008 ffffffff88090010 00000000004038b4
> $16 : ffffffff8921f910 000000007fda0f05 ffffffff8b8ea000 000000000000000e
> $20 : ffffffff8bdfb920 0000000000000000 ffffffff8bd88cc0 ffffffff8893fd58
> $24 : 0000000000000006 ffffffff8801df00
> $28 : ffffffff8893c000 ffffffff8893fd20 ffffffff88430000 ffffffff8801c010
> Hi : 000000000001d1ea
> Lo : 0000000000009b4e
> epc : ffffffff8801bcf0 kmap_coherent+0x10/0x130 Not tainted
> ra : ffffffff8801c010 copy_from_user_page+0x40/0xb0
> Status: 9000cce3 KX SX UX KERNEL EXL IE
> Cause : 00000034
> PrId : 00002321 (R5000)
> Modules linked in: dm_snapshot dm_mirror dm_mod ipv6
> Process cat (pid: 14553, threadinfo=ffffffff8893c000, task=ffffffff88a52660)
> Stack : 000000000000000e 000000007fda0f05 ffffffff8b8ea000 0000000000000000
> ffffffff88079d10 ffffffff88079cc4 ffffffff8bfbd528 ffffffff8921f910
> ffffffff8bdfb980 ffffffff8b8ea000 ffffffff8bdfb920 0000000000000000
> ffffffff8b8ea000 000000000000000e ffffffff8bd88cc0 ffffffff8893fe78
> 0000000000447000 000000000052c7d8 0000000000000000 ffffffff880d9014
> ffffffff8bd88cc0 ffffffff8b8ea000 fffffffffffffff4 ffffffff8b863248
> 0000000000000400 ffffffff8893fe78 0000000000447000 ffffffff880db188
> ffffffff8be6f6e0 0000000000000400 0000000000447000 ffffffff8893fe78
> 0000000000447000 0000000000000003 0000000000000016 ffffffff8808fbdc
> ffffffff8be6f6e0 0000000000000400 0000000000447000 fffffffffffffff7
> ...
> Call Trace:
> [<ffffffff8801bcf0>] kmap_coherent+0x10/0x130
> [<ffffffff8801c010>] copy_from_user_page+0x40/0xb0
> [<ffffffff88079d10>] access_process_vm+0x168/0x1d8
> [<ffffffff880d9014>] proc_pid_cmdline+0xac/0x140
> [<ffffffff880db188>] proc_info_read+0x108/0x150
> [<ffffffff8808fbdc>] vfs_read+0xec/0x178
> [<ffffffff88090060>] sys_read+0x50/0x98
> [<ffffffff88019718>] handle_sys+0x118/0x134
>
>
> Code: 0002127a 00021000 30420001 <00028036> 8f820024 3c038843 24420001 af820024 dc62f390
>
FWIW I get something very similar reading /proc/1/cmdline on
2.6.23-1/ip32 w/ R5000 and there have been other similar postings here
recently.
Maybe one day I will look into it, but it probably will not be real soon...
David Daney
^ permalink raw reply
* 2.6.24-rc2 crash in kmap_coherent
From: Florian Lohoff @ 2007-12-11 22:13 UTC (permalink / raw)
To: linux-mips
[-- Attachment #1: Type: text/plain, Size: 2683 bytes --]
Hi,
i just discovered that my native gcc build on one of my Indys stopped. I
found this in the dmesg ;)
Its a 2.6.24-rc2 on an R5k Indy 64M:
Kernel bug detected[#1]:
Cpu 0
$ 0 : 0000000000000000 ffffffff9000cce0 0000000000000001 ffffffff80000000
$ 4 : ffffffff8921f910 000000007fda0f05 000000007fda0f05 ffffffff8b8ea000
$ 8 : ffffffff89b4ef05 000000000000000e ffffffff8921f910 0000000000000f05
$12 : 0000000000000000 ffffffff80000008 ffffffff88090010 00000000004038b4
$16 : ffffffff8921f910 000000007fda0f05 ffffffff8b8ea000 000000000000000e
$20 : ffffffff8bdfb920 0000000000000000 ffffffff8bd88cc0 ffffffff8893fd58
$24 : 0000000000000006 ffffffff8801df00
$28 : ffffffff8893c000 ffffffff8893fd20 ffffffff88430000 ffffffff8801c010
Hi : 000000000001d1ea
Lo : 0000000000009b4e
epc : ffffffff8801bcf0 kmap_coherent+0x10/0x130 Not tainted
ra : ffffffff8801c010 copy_from_user_page+0x40/0xb0
Status: 9000cce3 KX SX UX KERNEL EXL IE
Cause : 00000034
PrId : 00002321 (R5000)
Modules linked in: dm_snapshot dm_mirror dm_mod ipv6
Process cat (pid: 14553, threadinfo=ffffffff8893c000, task=ffffffff88a52660)
Stack : 000000000000000e 000000007fda0f05 ffffffff8b8ea000 0000000000000000
ffffffff88079d10 ffffffff88079cc4 ffffffff8bfbd528 ffffffff8921f910
ffffffff8bdfb980 ffffffff8b8ea000 ffffffff8bdfb920 0000000000000000
ffffffff8b8ea000 000000000000000e ffffffff8bd88cc0 ffffffff8893fe78
0000000000447000 000000000052c7d8 0000000000000000 ffffffff880d9014
ffffffff8bd88cc0 ffffffff8b8ea000 fffffffffffffff4 ffffffff8b863248
0000000000000400 ffffffff8893fe78 0000000000447000 ffffffff880db188
ffffffff8be6f6e0 0000000000000400 0000000000447000 ffffffff8893fe78
0000000000447000 0000000000000003 0000000000000016 ffffffff8808fbdc
ffffffff8be6f6e0 0000000000000400 0000000000447000 fffffffffffffff7
...
Call Trace:
[<ffffffff8801bcf0>] kmap_coherent+0x10/0x130
[<ffffffff8801c010>] copy_from_user_page+0x40/0xb0
[<ffffffff88079d10>] access_process_vm+0x168/0x1d8
[<ffffffff880d9014>] proc_pid_cmdline+0xac/0x140
[<ffffffff880db188>] proc_info_read+0x108/0x150
[<ffffffff8808fbdc>] vfs_read+0xec/0x178
[<ffffffff88090060>] sys_read+0x50/0x98
[<ffffffff88019718>] handle_sys+0x118/0x134
Code: 0002127a 00021000 30420001 <00028036> 8f820024 3c038843 24420001 af820024 dc62f390
Flo
--
Florian Lohoff flo@rfc822.org +49-171-2280134
Those who would give up a little freedom to get a little
security shall soon have neither - Benjamin Franklin
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ 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