<feed xmlns='http://www.w3.org/2005/Atom'>
<title>linux-toradex.git/arch/mips, branch v3.2.63</title>
<subtitle>Linux kernel for Apalis and Colibri modules</subtitle>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/'/>
<entry>
<title>MIPS: Fix accessing to per-cpu data when flushing the cache</title>
<updated>2014-09-13T22:41:48+00:00</updated>
<author>
<name>Ralf Baechle</name>
<email>ralf@linux-mips.org</email>
</author>
<published>2013-09-17T10:44:31+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=2ce277620ead681c615c46b89de352893f3d3dd5'/>
<id>2ce277620ead681c615c46b89de352893f3d3dd5</id>
<content type='text'>
commit ff522058bd717506b2fa066fa564657f2b86477e upstream.

This fixes the following issue

BUG: using smp_processor_id() in preemptible [00000000] code: kjournald/1761
caller is blast_dcache32+0x30/0x254
Call Trace:
[&lt;8047f02c&gt;] dump_stack+0x8/0x34
[&lt;802e7e40&gt;] debug_smp_processor_id+0xe0/0xf0
[&lt;80114d94&gt;] blast_dcache32+0x30/0x254
[&lt;80118484&gt;] r4k_dma_cache_wback_inv+0x200/0x288
[&lt;80110ff0&gt;] mips_dma_map_sg+0x108/0x180
[&lt;80355098&gt;] ide_dma_prepare+0xf0/0x1b8
[&lt;8034eaa4&gt;] do_rw_taskfile+0x1e8/0x33c
[&lt;8035951c&gt;] ide_do_rw_disk+0x298/0x3e4
[&lt;8034a3c4&gt;] do_ide_request+0x2e0/0x704
[&lt;802bb0dc&gt;] __blk_run_queue+0x44/0x64
[&lt;802be000&gt;] queue_unplugged.isra.36+0x1c/0x54
[&lt;802beb94&gt;] blk_flush_plug_list+0x18c/0x24c
[&lt;802bec6c&gt;] blk_finish_plug+0x18/0x48
[&lt;8026554c&gt;] journal_commit_transaction+0x3b8/0x151c
[&lt;80269648&gt;] kjournald+0xec/0x238
[&lt;8014ac00&gt;] kthread+0xb8/0xc0
[&lt;8010268c&gt;] ret_from_kernel_thread+0x14/0x1c

Caches in most systems are identical - but not always, so we can't avoid
the use of smp_call_function() by just looking at the boot CPU's data,
have to fiddle with preemption instead.

Signed-off-by: Ralf Baechle &lt;ralf@linux-mips.org&gt;
Cc: Markos Chandras &lt;markos.chandras@imgtec.com&gt;
Cc: linux-mips@linux-mips.org
Patchwork: https://patchwork.linux-mips.org/patch/5835
Signed-off-by: Ben Hutchings &lt;ben@decadent.org.uk&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit ff522058bd717506b2fa066fa564657f2b86477e upstream.

This fixes the following issue

BUG: using smp_processor_id() in preemptible [00000000] code: kjournald/1761
caller is blast_dcache32+0x30/0x254
Call Trace:
[&lt;8047f02c&gt;] dump_stack+0x8/0x34
[&lt;802e7e40&gt;] debug_smp_processor_id+0xe0/0xf0
[&lt;80114d94&gt;] blast_dcache32+0x30/0x254
[&lt;80118484&gt;] r4k_dma_cache_wback_inv+0x200/0x288
[&lt;80110ff0&gt;] mips_dma_map_sg+0x108/0x180
[&lt;80355098&gt;] ide_dma_prepare+0xf0/0x1b8
[&lt;8034eaa4&gt;] do_rw_taskfile+0x1e8/0x33c
[&lt;8035951c&gt;] ide_do_rw_disk+0x298/0x3e4
[&lt;8034a3c4&gt;] do_ide_request+0x2e0/0x704
[&lt;802bb0dc&gt;] __blk_run_queue+0x44/0x64
[&lt;802be000&gt;] queue_unplugged.isra.36+0x1c/0x54
[&lt;802beb94&gt;] blk_flush_plug_list+0x18c/0x24c
[&lt;802bec6c&gt;] blk_finish_plug+0x18/0x48
[&lt;8026554c&gt;] journal_commit_transaction+0x3b8/0x151c
[&lt;80269648&gt;] kjournald+0xec/0x238
[&lt;8014ac00&gt;] kthread+0xb8/0xc0
[&lt;8010268c&gt;] ret_from_kernel_thread+0x14/0x1c

Caches in most systems are identical - but not always, so we can't avoid
the use of smp_call_function() by just looking at the boot CPU's data,
have to fiddle with preemption instead.

Signed-off-by: Ralf Baechle &lt;ralf@linux-mips.org&gt;
Cc: Markos Chandras &lt;markos.chandras@imgtec.com&gt;
Cc: linux-mips@linux-mips.org
Patchwork: https://patchwork.linux-mips.org/patch/5835
Signed-off-by: Ben Hutchings &lt;ben@decadent.org.uk&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>MIPS: perf: Fix build error caused by unused counters_per_cpu_to_total()</title>
<updated>2014-09-13T22:41:48+00:00</updated>
<author>
<name>Florian Fainelli</name>
<email>florian@openwrt.org</email>
</author>
<published>2012-07-19T07:13:52+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=588ca81b421339a30b3328e8f7e8f00fd0c9afdf'/>
<id>588ca81b421339a30b3328e8f7e8f00fd0c9afdf</id>
<content type='text'>
commit 6c37c9580409af7dc664bb6af0a85d540d63aeea upstream.

cc1: warnings being treated as errors
arch/mips/kernel/perf_event_mipsxx.c:166: error: 'counters_per_cpu_to_total' defined but not used
make[2]: *** [arch/mips/kernel/perf_event_mipsxx.o] Error 1
make[2]: *** Waiting for unfinished jobs....

It was first introduced by 82091564cfd7ab8def42777a9c662dbf655c5d25 [MIPS:
perf: Add support for 64-bit perf counters.] in 3.2.

Signed-off-by: Florian Fainelli &lt;florian@openwrt.org&gt;
Cc: linux-mips@linux-mips.org
Cc: david.daney@cavium.com
Patchwork: https://patchwork.linux-mips.org/patch/3357/
Signed-off-by: Ralf Baechle &lt;ralf@linux-mips.org&gt;
Signed-off-by: Ben Hutchings &lt;ben@decadent.org.uk&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit 6c37c9580409af7dc664bb6af0a85d540d63aeea upstream.

cc1: warnings being treated as errors
arch/mips/kernel/perf_event_mipsxx.c:166: error: 'counters_per_cpu_to_total' defined but not used
make[2]: *** [arch/mips/kernel/perf_event_mipsxx.o] Error 1
make[2]: *** Waiting for unfinished jobs....

It was first introduced by 82091564cfd7ab8def42777a9c662dbf655c5d25 [MIPS:
perf: Add support for 64-bit perf counters.] in 3.2.

Signed-off-by: Florian Fainelli &lt;florian@openwrt.org&gt;
Cc: linux-mips@linux-mips.org
Cc: david.daney@cavium.com
Patchwork: https://patchwork.linux-mips.org/patch/3357/
Signed-off-by: Ralf Baechle &lt;ralf@linux-mips.org&gt;
Signed-off-by: Ben Hutchings &lt;ben@decadent.org.uk&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>MIPS: OCTEON: make get_system_type() thread-safe</title>
<updated>2014-09-13T22:41:46+00:00</updated>
<author>
<name>Aaro Koskinen</name>
<email>aaro.koskinen@nsn.com</email>
</author>
<published>2014-07-22T11:51:08+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=a17245332e650651e3d70aa94013d806d61a40cb'/>
<id>a17245332e650651e3d70aa94013d806d61a40cb</id>
<content type='text'>
commit 608308682addfdc7b8e2aee88f0e028331d88e4d upstream.

get_system_type() is not thread-safe on OCTEON. It uses static data,
also more dangerous issue is that it's calling cvmx_fuse_read_byte()
every time without any synchronization. Currently it's possible to get
processes stuck looping forever in kernel simply by launching multiple
readers of /proc/cpuinfo:

	(while true; do cat /proc/cpuinfo &gt; /dev/null; done) &amp;
	(while true; do cat /proc/cpuinfo &gt; /dev/null; done) &amp;
	...

Fix by initializing the system type string only once during the early
boot.

Signed-off-by: Aaro Koskinen &lt;aaro.koskinen@nsn.com&gt;
Reviewed-by: Markos Chandras &lt;markos.chandras@imgtec.com&gt;
Patchwork: http://patchwork.linux-mips.org/patch/7437/
Signed-off-by: James Hogan &lt;james.hogan@imgtec.com&gt;
Signed-off-by: Ben Hutchings &lt;ben@decadent.org.uk&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit 608308682addfdc7b8e2aee88f0e028331d88e4d upstream.

get_system_type() is not thread-safe on OCTEON. It uses static data,
also more dangerous issue is that it's calling cvmx_fuse_read_byte()
every time without any synchronization. Currently it's possible to get
processes stuck looping forever in kernel simply by launching multiple
readers of /proc/cpuinfo:

	(while true; do cat /proc/cpuinfo &gt; /dev/null; done) &amp;
	(while true; do cat /proc/cpuinfo &gt; /dev/null; done) &amp;
	...

Fix by initializing the system type string only once during the early
boot.

Signed-off-by: Aaro Koskinen &lt;aaro.koskinen@nsn.com&gt;
Reviewed-by: Markos Chandras &lt;markos.chandras@imgtec.com&gt;
Patchwork: http://patchwork.linux-mips.org/patch/7437/
Signed-off-by: James Hogan &lt;james.hogan@imgtec.com&gt;
Signed-off-by: Ben Hutchings &lt;ben@decadent.org.uk&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>MIPS: GIC: Prevent array overrun</title>
<updated>2014-09-13T22:41:41+00:00</updated>
<author>
<name>Jeffrey Deans</name>
<email>jeffrey.deans@imgtec.com</email>
</author>
<published>2014-07-17T08:20:56+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=43b781e0e4426c91f5b14b1ffe1cbecacfcb7b1c'/>
<id>43b781e0e4426c91f5b14b1ffe1cbecacfcb7b1c</id>
<content type='text'>
commit ffc8415afab20bd97754efae6aad1f67b531132b upstream.

A GIC interrupt which is declared as having a GIC_MAP_TO_NMI_MSK
mapping causes the cpu parameter to gic_setup_intr() to be increased
to 32, causing memory corruption when pcpu_masks[] is written to again
later in the function.

Signed-off-by: Jeffrey Deans &lt;jeffrey.deans@imgtec.com&gt;
Signed-off-by: Markos Chandras &lt;markos.chandras@imgtec.com&gt;
Cc: linux-mips@linux-mips.org
Patchwork: https://patchwork.linux-mips.org/patch/7375/
Signed-off-by: Ralf Baechle &lt;ralf@linux-mips.org&gt;
Signed-off-by: Ben Hutchings &lt;ben@decadent.org.uk&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit ffc8415afab20bd97754efae6aad1f67b531132b upstream.

A GIC interrupt which is declared as having a GIC_MAP_TO_NMI_MSK
mapping causes the cpu parameter to gic_setup_intr() to be increased
to 32, causing memory corruption when pcpu_masks[] is written to again
later in the function.

Signed-off-by: Jeffrey Deans &lt;jeffrey.deans@imgtec.com&gt;
Signed-off-by: Markos Chandras &lt;markos.chandras@imgtec.com&gt;
Cc: linux-mips@linux-mips.org
Patchwork: https://patchwork.linux-mips.org/patch/7375/
Signed-off-by: Ralf Baechle &lt;ralf@linux-mips.org&gt;
Signed-off-by: Ben Hutchings &lt;ben@decadent.org.uk&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>MIPS: Prevent user from setting FCSR cause bits</title>
<updated>2014-09-13T22:41:40+00:00</updated>
<author>
<name>Paul Burton</name>
<email>paul.burton@imgtec.com</email>
</author>
<published>2014-07-22T13:21:21+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=5aa0e65c8a3d3d0c8b86d72b6f2906166181f331'/>
<id>5aa0e65c8a3d3d0c8b86d72b6f2906166181f331</id>
<content type='text'>
commit b1442d39fac2fcfbe6a4814979020e993ca59c9e upstream.

If one or more matching FCSR cause &amp; enable bits are set in saved thread
context then when that context is restored the kernel will take an FP
exception. This is of course undesirable and considered an oops, leading
to the kernel writing a backtrace to the console and potentially
rebooting depending upon the configuration. Thus the kernel avoids this
situation by clearing the cause bits of the FCSR register when handling
FP exceptions and after emulating FP instructions.

However the kernel does not prevent userland from setting arbitrary FCSR
cause &amp; enable bits via ptrace, using either the PTRACE_POKEUSR or
PTRACE_SETFPREGS requests. This means userland can trivially cause the
kernel to oops on any system with an FPU. Prevent this from happening
by clearing the cause bits when writing to the saved FCSR context via
ptrace.

This problem appears to exist at least back to the beginning of the git
era in the PTRACE_POKEUSR case.

Signed-off-by: Paul Burton &lt;paul.burton@imgtec.com&gt;
Cc: linux-mips@linux-mips.org
Cc: Paul Burton &lt;paul.burton@imgtec.com&gt;
Patchwork: https://patchwork.linux-mips.org/patch/7438/
Signed-off-by: Ralf Baechle &lt;ralf@linux-mips.org&gt;
Signed-off-by: Ben Hutchings &lt;ben@decadent.org.uk&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit b1442d39fac2fcfbe6a4814979020e993ca59c9e upstream.

If one or more matching FCSR cause &amp; enable bits are set in saved thread
context then when that context is restored the kernel will take an FP
exception. This is of course undesirable and considered an oops, leading
to the kernel writing a backtrace to the console and potentially
rebooting depending upon the configuration. Thus the kernel avoids this
situation by clearing the cause bits of the FCSR register when handling
FP exceptions and after emulating FP instructions.

However the kernel does not prevent userland from setting arbitrary FCSR
cause &amp; enable bits via ptrace, using either the PTRACE_POKEUSR or
PTRACE_SETFPREGS requests. This means userland can trivially cause the
kernel to oops on any system with an FPU. Prevent this from happening
by clearing the cause bits when writing to the saved FCSR context via
ptrace.

This problem appears to exist at least back to the beginning of the git
era in the PTRACE_POKEUSR case.

Signed-off-by: Paul Burton &lt;paul.burton@imgtec.com&gt;
Cc: linux-mips@linux-mips.org
Cc: Paul Burton &lt;paul.burton@imgtec.com&gt;
Patchwork: https://patchwork.linux-mips.org/patch/7438/
Signed-off-by: Ralf Baechle &lt;ralf@linux-mips.org&gt;
Signed-off-by: Ben Hutchings &lt;ben@decadent.org.uk&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>MIPS: tlbex: Fix a missing statement for HUGETLB</title>
<updated>2014-09-13T22:41:40+00:00</updated>
<author>
<name>Huacai Chen</name>
<email>chenhc@lemote.com</email>
</author>
<published>2014-07-29T06:54:40+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=159abeca40f0899cb23205ceda1942783a67eea5'/>
<id>159abeca40f0899cb23205ceda1942783a67eea5</id>
<content type='text'>
commit 8393c524a25609a30129e4a8975cf3b91f6c16a5 upstream.

In commit 2c8c53e28f1 (MIPS: Optimize TLB handlers for Octeon CPUs)
build_r4000_tlb_refill_handler() is modified. But it doesn't compatible
with the original code in HUGETLB case. Because there is a copy &amp; paste
error and one line of code is missing. It is very easy to produce a bug
with LTP's hugemmap05 test.

Signed-off-by: Huacai Chen &lt;chenhc@lemote.com&gt;
Signed-off-by: Binbin Zhou &lt;zhoubb@lemote.com&gt;
Cc: John Crispin &lt;john@phrozen.org&gt;
Cc: Steven J. Hill &lt;Steven.Hill@imgtec.com&gt;
Cc: linux-mips@linux-mips.org
Cc: Fuxin Zhang &lt;zhangfx@lemote.com&gt;
Cc: Zhangjin Wu &lt;wuzhangjin@gmail.com&gt;
Patchwork: https://patchwork.linux-mips.org/patch/7496/
Signed-off-by: Ralf Baechle &lt;ralf@linux-mips.org&gt;
Signed-off-by: Ben Hutchings &lt;ben@decadent.org.uk&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit 8393c524a25609a30129e4a8975cf3b91f6c16a5 upstream.

In commit 2c8c53e28f1 (MIPS: Optimize TLB handlers for Octeon CPUs)
build_r4000_tlb_refill_handler() is modified. But it doesn't compatible
with the original code in HUGETLB case. Because there is a copy &amp; paste
error and one line of code is missing. It is very easy to produce a bug
with LTP's hugemmap05 test.

Signed-off-by: Huacai Chen &lt;chenhc@lemote.com&gt;
Signed-off-by: Binbin Zhou &lt;zhoubb@lemote.com&gt;
Cc: John Crispin &lt;john@phrozen.org&gt;
Cc: Steven J. Hill &lt;Steven.Hill@imgtec.com&gt;
Cc: linux-mips@linux-mips.org
Cc: Fuxin Zhang &lt;zhangfx@lemote.com&gt;
Cc: Zhangjin Wu &lt;wuzhangjin@gmail.com&gt;
Patchwork: https://patchwork.linux-mips.org/patch/7496/
Signed-off-by: Ralf Baechle &lt;ralf@linux-mips.org&gt;
Signed-off-by: Ben Hutchings &lt;ben@decadent.org.uk&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>MIPS: asm: thread_info: Add _TIF_SECCOMP flag</title>
<updated>2014-07-11T12:33:56+00:00</updated>
<author>
<name>Markos Chandras</name>
<email>markos.chandras@imgtec.com</email>
</author>
<published>2014-01-22T14:40:00+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=f50bf61a3282988b2fe46e8cb88c9b8698a2d8d2'/>
<id>f50bf61a3282988b2fe46e8cb88c9b8698a2d8d2</id>
<content type='text'>
commit 137f7df8cead00688524c82360930845396b8a21 upstream.

Add _TIF_SECCOMP flag to _TIF_WORK_SYSCALL_ENTRY to indicate
that the system call needs to be checked against a seccomp filter.

Signed-off-by: Markos Chandras &lt;markos.chandras@imgtec.com&gt;
Reviewed-by: Paul Burton &lt;paul.burton@imgtec.com&gt;
Reviewed-by: James Hogan &lt;james.hogan@imgtec.com&gt;
Cc: linux-mips@linux-mips.org
Patchwork: https://patchwork.linux-mips.org/patch/6405/
Signed-off-by: Ralf Baechle &lt;ralf@linux-mips.org&gt;
[bwh: Backported to 3.2: various other flags are not included in
 _TIF_WORK_SYSCALL_ENTRY]
Signed-off-by: Ben Hutchings &lt;ben@decadent.org.uk&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit 137f7df8cead00688524c82360930845396b8a21 upstream.

Add _TIF_SECCOMP flag to _TIF_WORK_SYSCALL_ENTRY to indicate
that the system call needs to be checked against a seccomp filter.

Signed-off-by: Markos Chandras &lt;markos.chandras@imgtec.com&gt;
Reviewed-by: Paul Burton &lt;paul.burton@imgtec.com&gt;
Reviewed-by: James Hogan &lt;james.hogan@imgtec.com&gt;
Cc: linux-mips@linux-mips.org
Patchwork: https://patchwork.linux-mips.org/patch/6405/
Signed-off-by: Ralf Baechle &lt;ralf@linux-mips.org&gt;
[bwh: Backported to 3.2: various other flags are not included in
 _TIF_WORK_SYSCALL_ENTRY]
Signed-off-by: Ben Hutchings &lt;ben@decadent.org.uk&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>MIPS: Cleanup flags in syscall flags handlers.</title>
<updated>2014-07-11T12:33:56+00:00</updated>
<author>
<name>Ralf Baechle</name>
<email>ralf@linux-mips.org</email>
</author>
<published>2013-05-28T23:02:18+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=70c8d44f427d735d2f813559444713d6bfaed1ab'/>
<id>70c8d44f427d735d2f813559444713d6bfaed1ab</id>
<content type='text'>
commit e7f3b48af7be9f8007a224663a5b91340626fed5 upstream.

This will simplify further modifications.

Signed-off-by: Ralf Baechle &lt;ralf@linux-mips.org&gt;
Signed-off-by: Ben Hutchings &lt;ben@decadent.org.uk&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit e7f3b48af7be9f8007a224663a5b91340626fed5 upstream.

This will simplify further modifications.

Signed-off-by: Ralf Baechle &lt;ralf@linux-mips.org&gt;
Signed-off-by: Ben Hutchings &lt;ben@decadent.org.uk&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>MIPS: MSC: Prevent out-of-bounds writes to MIPS SC ioremap'd region</title>
<updated>2014-07-11T12:33:55+00:00</updated>
<author>
<name>Markos Chandras</name>
<email>markos.chandras@imgtec.com</email>
</author>
<published>2014-06-23T08:48:51+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=167dc42e69226e50b97b44f0777a387ab1a932cc'/>
<id>167dc42e69226e50b97b44f0777a387ab1a932cc</id>
<content type='text'>
commit ab6c15bc6620ebe220970cc040b29bcb2757f373 upstream.

Previously, the lower limit for the MIPS SC initialization loop was
set incorrectly allowing one extra loop leading to writes
beyond the MSC ioremap'd space. More precisely, the value of the 'imp'
in the last loop increased beyond the msc_irqmap_t boundaries and
as a result of which, the 'n' variable was loaded with an incorrect
value. This value was used later on to calculate the offset in the
MSC01_IC_SUP which led to random crashes like the following one:

CPU 0 Unable to handle kernel paging request at virtual address e75c0200,
epc == 8058dba4, ra == 8058db90
[...]
Call Trace:
[&lt;8058dba4&gt;] init_msc_irqs+0x104/0x154
[&lt;8058b5bc&gt;] arch_init_irq+0xd8/0x154
[&lt;805897b0&gt;] start_kernel+0x220/0x36c

Kernel panic - not syncing: Attempted to kill the idle task!

This patch fixes the problem

Signed-off-by: Markos Chandras &lt;markos.chandras@imgtec.com&gt;
Reviewed-by: James Hogan &lt;james.hogan@imgtec.com&gt;
Cc: linux-mips@linux-mips.org
Patchwork: https://patchwork.linux-mips.org/patch/7118/
Signed-off-by: Ralf Baechle &lt;ralf@linux-mips.org&gt;
Signed-off-by: Ben Hutchings &lt;ben@decadent.org.uk&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit ab6c15bc6620ebe220970cc040b29bcb2757f373 upstream.

Previously, the lower limit for the MIPS SC initialization loop was
set incorrectly allowing one extra loop leading to writes
beyond the MSC ioremap'd space. More precisely, the value of the 'imp'
in the last loop increased beyond the msc_irqmap_t boundaries and
as a result of which, the 'n' variable was loaded with an incorrect
value. This value was used later on to calculate the offset in the
MSC01_IC_SUP which led to random crashes like the following one:

CPU 0 Unable to handle kernel paging request at virtual address e75c0200,
epc == 8058dba4, ra == 8058db90
[...]
Call Trace:
[&lt;8058dba4&gt;] init_msc_irqs+0x104/0x154
[&lt;8058b5bc&gt;] arch_init_irq+0xd8/0x154
[&lt;805897b0&gt;] start_kernel+0x220/0x36c

Kernel panic - not syncing: Attempted to kill the idle task!

This patch fixes the problem

Signed-off-by: Markos Chandras &lt;markos.chandras@imgtec.com&gt;
Reviewed-by: James Hogan &lt;james.hogan@imgtec.com&gt;
Cc: linux-mips@linux-mips.org
Patchwork: https://patchwork.linux-mips.org/patch/7118/
Signed-off-by: Ralf Baechle &lt;ralf@linux-mips.org&gt;
Signed-off-by: Ben Hutchings &lt;ben@decadent.org.uk&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>MIPS: Hibernate: Flush TLB entries in swsusp_arch_resume()</title>
<updated>2014-04-30T15:23:24+00:00</updated>
<author>
<name>Huacai Chen</name>
<email>chenhc@lemote.com</email>
</author>
<published>2014-03-22T09:21:44+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=258f96215696a32844bb6ed9da446cb550bd8396'/>
<id>258f96215696a32844bb6ed9da446cb550bd8396</id>
<content type='text'>
commit c14af233fbe279d0e561ecf84f1208b1bae087ef upstream.

The original MIPS hibernate code flushes cache and TLB entries in
swsusp_arch_resume(). But they are removed in Commit 44eeab67416711
(MIPS: Hibernation: Remove SMP TLB and cacheflushing code.). A cross-
CPU flush is surely unnecessary because all but the local CPU have
already been disabled. But a local flush (at least the TLB flush) is
needed. When we do hibernation on Loongson-3 with an E1000E NIC, it is
very easy to produce a kernel panic (kernel page fault, or unaligned
access). The root cause is E1000E driver use vzalloc_node() to allocate
pages, the stale TLB entries of the booting kernel will be misused by
the resumed target kernel.

Signed-off-by: Huacai Chen &lt;chenhc@lemote.com&gt;
Cc: John Crispin &lt;john@phrozen.org&gt;
Cc: Steven J. Hill &lt;Steven.Hill@imgtec.com&gt;
Cc: Aurelien Jarno &lt;aurelien@aurel32.net&gt;
Cc: linux-mips@linux-mips.org
Cc: Fuxin Zhang &lt;zhangfx@lemote.com&gt;
Cc: Zhangjin Wu &lt;wuzhangjin@gmail.com&gt;
Patchwork: https://patchwork.linux-mips.org/patch/6643/
Signed-off-by: Ralf Baechle &lt;ralf@linux-mips.org&gt;
Signed-off-by: Ben Hutchings &lt;ben@decadent.org.uk&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit c14af233fbe279d0e561ecf84f1208b1bae087ef upstream.

The original MIPS hibernate code flushes cache and TLB entries in
swsusp_arch_resume(). But they are removed in Commit 44eeab67416711
(MIPS: Hibernation: Remove SMP TLB and cacheflushing code.). A cross-
CPU flush is surely unnecessary because all but the local CPU have
already been disabled. But a local flush (at least the TLB flush) is
needed. When we do hibernation on Loongson-3 with an E1000E NIC, it is
very easy to produce a kernel panic (kernel page fault, or unaligned
access). The root cause is E1000E driver use vzalloc_node() to allocate
pages, the stale TLB entries of the booting kernel will be misused by
the resumed target kernel.

Signed-off-by: Huacai Chen &lt;chenhc@lemote.com&gt;
Cc: John Crispin &lt;john@phrozen.org&gt;
Cc: Steven J. Hill &lt;Steven.Hill@imgtec.com&gt;
Cc: Aurelien Jarno &lt;aurelien@aurel32.net&gt;
Cc: linux-mips@linux-mips.org
Cc: Fuxin Zhang &lt;zhangfx@lemote.com&gt;
Cc: Zhangjin Wu &lt;wuzhangjin@gmail.com&gt;
Patchwork: https://patchwork.linux-mips.org/patch/6643/
Signed-off-by: Ralf Baechle &lt;ralf@linux-mips.org&gt;
Signed-off-by: Ben Hutchings &lt;ben@decadent.org.uk&gt;
</pre>
</div>
</content>
</entry>
</feed>
