<feed xmlns='http://www.w3.org/2005/Atom'>
<title>linux.git/arch/mips, branch v4.2-rc6</title>
<subtitle>Linux kernel source tree</subtitle>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/'/>
<entry>
<title>Merge branch 'upstream' of git://git.linux-mips.org/pub/scm/ralf/upstream-linus</title>
<updated>2015-08-09T02:59:21+00:00</updated>
<author>
<name>Linus Torvalds</name>
<email>torvalds@linux-foundation.org</email>
</author>
<published>2015-08-09T02:59:21+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=3fbdc379567aef1c43b4be110179b541d68afdf6'/>
<id>3fbdc379567aef1c43b4be110179b541d68afdf6</id>
<content type='text'>
Pull MIPS fixes from Ralf Baechle:
 "Another round of MIPS fixes for 4.2.  No area does particularly stand
  out but we have a two unpleasant ones:

   - Kernel ptes are marked with a global bit which allows the kernel to
     share kernel TLB entries between all processes.  For this to work
     both entries of an adjacent even/odd pte pair need to have the
     global bit set.  There has been a subtle race in setting the other
     entry's global bit since ~ 2000 but it take particularly
     pathological workloads that essentially do mostly vmalloc/vfree to
     trigger this.

     This pull request fixes the 64-bit case but leaves the case of 32
     bit CPUs with 64 bit ptes unsolved for now.  The unfixed cases
     affect hardware that is not available in the field yet.

   - Instruction emulation requires loading instructions from user space
     but the current fast but simplistic approach will fail on pages
     that are PROT_EXEC but !PROT_READ.  For this reason we temporarily
     do not permit this permission and will map pages with PROT_EXEC |
     PROT_READ.

  The remainder of this pull request is more or less across the field
  and the short log explains them well"

* 'upstream' of git://git.linux-mips.org/pub/scm/ralf/upstream-linus:
  MIPS: Make set_pte() SMP safe.
  MIPS: Replace add and sub instructions in relocate_kernel.S with addiu
  MIPS: Flush RPS on kernel entry with EVA
  Revert "MIPS: BCM63xx: Provide a plat_post_dma_flush hook"
  MIPS: BMIPS: Delete unused Kconfig symbol
  MIPS: Export get_c0_perfcount_int()
  MIPS: show_stack: Fix stack trace with EVA
  MIPS: do_mcheck: Fix kernel code dump with EVA
  MIPS: SMP: Don't increment irq_count multiple times for call function IPIs
  MIPS: Partially disable RIXI support.
  MIPS: Handle page faults of executable but unreadable pages correctly.
  MIPS: Malta: Don't reinitialise RTC
  MIPS: unaligned: Fix build error on big endian R6 kernels
  MIPS: Fix sched_getaffinity with MT FPAFF enabled
  MIPS: Fix build with CONFIG_OF=y for non OF-enabled targets
  CPUFREQ: Loongson2: Fix broken build due to incorrect include.
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Pull MIPS fixes from Ralf Baechle:
 "Another round of MIPS fixes for 4.2.  No area does particularly stand
  out but we have a two unpleasant ones:

   - Kernel ptes are marked with a global bit which allows the kernel to
     share kernel TLB entries between all processes.  For this to work
     both entries of an adjacent even/odd pte pair need to have the
     global bit set.  There has been a subtle race in setting the other
     entry's global bit since ~ 2000 but it take particularly
     pathological workloads that essentially do mostly vmalloc/vfree to
     trigger this.

     This pull request fixes the 64-bit case but leaves the case of 32
     bit CPUs with 64 bit ptes unsolved for now.  The unfixed cases
     affect hardware that is not available in the field yet.

   - Instruction emulation requires loading instructions from user space
     but the current fast but simplistic approach will fail on pages
     that are PROT_EXEC but !PROT_READ.  For this reason we temporarily
     do not permit this permission and will map pages with PROT_EXEC |
     PROT_READ.

  The remainder of this pull request is more or less across the field
  and the short log explains them well"

* 'upstream' of git://git.linux-mips.org/pub/scm/ralf/upstream-linus:
  MIPS: Make set_pte() SMP safe.
  MIPS: Replace add and sub instructions in relocate_kernel.S with addiu
  MIPS: Flush RPS on kernel entry with EVA
  Revert "MIPS: BCM63xx: Provide a plat_post_dma_flush hook"
  MIPS: BMIPS: Delete unused Kconfig symbol
  MIPS: Export get_c0_perfcount_int()
  MIPS: show_stack: Fix stack trace with EVA
  MIPS: do_mcheck: Fix kernel code dump with EVA
  MIPS: SMP: Don't increment irq_count multiple times for call function IPIs
  MIPS: Partially disable RIXI support.
  MIPS: Handle page faults of executable but unreadable pages correctly.
  MIPS: Malta: Don't reinitialise RTC
  MIPS: unaligned: Fix build error on big endian R6 kernels
  MIPS: Fix sched_getaffinity with MT FPAFF enabled
  MIPS: Fix build with CONFIG_OF=y for non OF-enabled targets
  CPUFREQ: Loongson2: Fix broken build due to incorrect include.
</pre>
</div>
</content>
</entry>
<entry>
<title>signal: fix information leak in copy_siginfo_from_user32</title>
<updated>2015-08-07T01:39:40+00:00</updated>
<author>
<name>Amanieu d'Antras</name>
<email>amanieu@gmail.com</email>
</author>
<published>2015-08-06T22:46:26+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=3c00cb5e68dc719f2fc73a33b1b230aadfcb1309'/>
<id>3c00cb5e68dc719f2fc73a33b1b230aadfcb1309</id>
<content type='text'>
This function can leak kernel stack data when the user siginfo_t has a
positive si_code value.  The top 16 bits of si_code descibe which fields
in the siginfo_t union are active, but they are treated inconsistently
between copy_siginfo_from_user32, copy_siginfo_to_user32 and
copy_siginfo_to_user.

copy_siginfo_from_user32 is called from rt_sigqueueinfo and
rt_tgsigqueueinfo in which the user has full control overthe top 16 bits
of si_code.

This fixes the following information leaks:
x86:   8 bytes leaked when sending a signal from a 32-bit process to
       itself. This leak grows to 16 bytes if the process uses x32.
       (si_code = __SI_CHLD)
x86:   100 bytes leaked when sending a signal from a 32-bit process to
       a 64-bit process. (si_code = -1)
sparc: 4 bytes leaked when sending a signal from a 32-bit process to a
       64-bit process. (si_code = any)

parsic and s390 have similar bugs, but they are not vulnerable because
rt_[tg]sigqueueinfo have checks that prevent sending a positive si_code
to a different process.  These bugs are also fixed for consistency.

Signed-off-by: Amanieu d'Antras &lt;amanieu@gmail.com&gt;
Cc: Oleg Nesterov &lt;oleg@redhat.com&gt;
Cc: Ingo Molnar &lt;mingo@kernel.org&gt;
Cc: Russell King &lt;rmk@arm.linux.org.uk&gt;
Cc: Ralf Baechle &lt;ralf@linux-mips.org&gt;
Cc: Benjamin Herrenschmidt &lt;benh@kernel.crashing.org&gt;
Cc: Chris Metcalf &lt;cmetcalf@ezchip.com&gt;
Cc: Paul Mackerras &lt;paulus@samba.org&gt;
Cc: Michael Ellerman &lt;mpe@ellerman.id.au&gt;
Signed-off-by: Andrew Morton &lt;akpm@linux-foundation.org&gt;
Signed-off-by: Linus Torvalds &lt;torvalds@linux-foundation.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
This function can leak kernel stack data when the user siginfo_t has a
positive si_code value.  The top 16 bits of si_code descibe which fields
in the siginfo_t union are active, but they are treated inconsistently
between copy_siginfo_from_user32, copy_siginfo_to_user32 and
copy_siginfo_to_user.

copy_siginfo_from_user32 is called from rt_sigqueueinfo and
rt_tgsigqueueinfo in which the user has full control overthe top 16 bits
of si_code.

This fixes the following information leaks:
x86:   8 bytes leaked when sending a signal from a 32-bit process to
       itself. This leak grows to 16 bytes if the process uses x32.
       (si_code = __SI_CHLD)
x86:   100 bytes leaked when sending a signal from a 32-bit process to
       a 64-bit process. (si_code = -1)
sparc: 4 bytes leaked when sending a signal from a 32-bit process to a
       64-bit process. (si_code = any)

parsic and s390 have similar bugs, but they are not vulnerable because
rt_[tg]sigqueueinfo have checks that prevent sending a positive si_code
to a different process.  These bugs are also fixed for consistency.

Signed-off-by: Amanieu d'Antras &lt;amanieu@gmail.com&gt;
Cc: Oleg Nesterov &lt;oleg@redhat.com&gt;
Cc: Ingo Molnar &lt;mingo@kernel.org&gt;
Cc: Russell King &lt;rmk@arm.linux.org.uk&gt;
Cc: Ralf Baechle &lt;ralf@linux-mips.org&gt;
Cc: Benjamin Herrenschmidt &lt;benh@kernel.crashing.org&gt;
Cc: Chris Metcalf &lt;cmetcalf@ezchip.com&gt;
Cc: Paul Mackerras &lt;paulus@samba.org&gt;
Cc: Michael Ellerman &lt;mpe@ellerman.id.au&gt;
Signed-off-by: Andrew Morton &lt;akpm@linux-foundation.org&gt;
Signed-off-by: Linus Torvalds &lt;torvalds@linux-foundation.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>MIPS: Make set_pte() SMP safe.</title>
<updated>2015-08-05T09:11:10+00:00</updated>
<author>
<name>David Daney</name>
<email>david.daney@cavium.com</email>
</author>
<published>2015-08-04T00:48:43+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=46011e6ea39235e4aca656673c500eac81a07a17'/>
<id>46011e6ea39235e4aca656673c500eac81a07a17</id>
<content type='text'>
On MIPS the GLOBAL bit of the PTE must have the same value in any
aligned pair of PTEs.  These pairs of PTEs are referred to as
"buddies".  In a SMP system is is possible for two CPUs to be calling
set_pte() on adjacent PTEs at the same time.  There is a race between
setting the PTE and a different CPU setting the GLOBAL bit in its
buddy PTE.

This race can be observed when multiple CPUs are executing
vmap()/vfree() at the same time.

Make setting the buddy PTE's GLOBAL bit an atomic operation to close
the race condition.

The case of CONFIG_64BIT_PHYS_ADDR &amp;&amp; CONFIG_CPU_MIPS32 is *not*
handled.

Signed-off-by: David Daney &lt;david.daney@cavium.com&gt;
Cc: &lt;stable@vger.kernel.org&gt;
Cc: linux-mips@linux-mips.org
Patchwork: https://patchwork.linux-mips.org/patch/10835/
Signed-off-by: Ralf Baechle &lt;ralf@linux-mips.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
On MIPS the GLOBAL bit of the PTE must have the same value in any
aligned pair of PTEs.  These pairs of PTEs are referred to as
"buddies".  In a SMP system is is possible for two CPUs to be calling
set_pte() on adjacent PTEs at the same time.  There is a race between
setting the PTE and a different CPU setting the GLOBAL bit in its
buddy PTE.

This race can be observed when multiple CPUs are executing
vmap()/vfree() at the same time.

Make setting the buddy PTE's GLOBAL bit an atomic operation to close
the race condition.

The case of CONFIG_64BIT_PHYS_ADDR &amp;&amp; CONFIG_CPU_MIPS32 is *not*
handled.

Signed-off-by: David Daney &lt;david.daney@cavium.com&gt;
Cc: &lt;stable@vger.kernel.org&gt;
Cc: linux-mips@linux-mips.org
Patchwork: https://patchwork.linux-mips.org/patch/10835/
Signed-off-by: Ralf Baechle &lt;ralf@linux-mips.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>MIPS: Replace add and sub instructions in relocate_kernel.S with addiu</title>
<updated>2015-08-03T13:26:30+00:00</updated>
<author>
<name>James Cowgill</name>
<email>James.Cowgill@imgtec.com</email>
</author>
<published>2015-06-17T16:12:50+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=a4504755e7dc8d43ed2a934397032691cd03adf7'/>
<id>a4504755e7dc8d43ed2a934397032691cd03adf7</id>
<content type='text'>
Fixes the assembler errors generated when compiling a MIPS R6 kernel with
CONFIG_KEXEC on, by replacing the offending add and sub instructions with
addiu instructions.

Build errors:
arch/mips/kernel/relocate_kernel.S: Assembler messages:
arch/mips/kernel/relocate_kernel.S:27: Error: invalid operands `dadd $16,$16,8'
arch/mips/kernel/relocate_kernel.S:64: Error: invalid operands `dadd $20,$20,8'
arch/mips/kernel/relocate_kernel.S:65: Error: invalid operands `dadd $18,$18,8'
arch/mips/kernel/relocate_kernel.S:66: Error: invalid operands `dsub $22,$22,1'
scripts/Makefile.build:294: recipe for target 'arch/mips/kernel/relocate_kernel.o' failed

Signed-off-by: James Cowgill &lt;James.Cowgill@imgtec.com&gt;
Cc: &lt;stable@vger.kernel.org&gt; # 4.0+
Cc: linux-mips@linux-mips.org
Patchwork: https://patchwork.linux-mips.org/patch/10558/
Signed-off-by: Ralf Baechle &lt;ralf@linux-mips.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Fixes the assembler errors generated when compiling a MIPS R6 kernel with
CONFIG_KEXEC on, by replacing the offending add and sub instructions with
addiu instructions.

Build errors:
arch/mips/kernel/relocate_kernel.S: Assembler messages:
arch/mips/kernel/relocate_kernel.S:27: Error: invalid operands `dadd $16,$16,8'
arch/mips/kernel/relocate_kernel.S:64: Error: invalid operands `dadd $20,$20,8'
arch/mips/kernel/relocate_kernel.S:65: Error: invalid operands `dadd $18,$18,8'
arch/mips/kernel/relocate_kernel.S:66: Error: invalid operands `dsub $22,$22,1'
scripts/Makefile.build:294: recipe for target 'arch/mips/kernel/relocate_kernel.o' failed

Signed-off-by: James Cowgill &lt;James.Cowgill@imgtec.com&gt;
Cc: &lt;stable@vger.kernel.org&gt; # 4.0+
Cc: linux-mips@linux-mips.org
Patchwork: https://patchwork.linux-mips.org/patch/10558/
Signed-off-by: Ralf Baechle &lt;ralf@linux-mips.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>MIPS: Flush RPS on kernel entry with EVA</title>
<updated>2015-08-03T08:29:11+00:00</updated>
<author>
<name>James Hogan</name>
<email>james.hogan@imgtec.com</email>
</author>
<published>2015-07-31T15:29:38+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=3aff47c062b944a5e1f9af56a37a23f5295628fc'/>
<id>3aff47c062b944a5e1f9af56a37a23f5295628fc</id>
<content type='text'>
When EVA is enabled, flush the Return Prediction Stack (RPS) present on
some MIPS cores on entry to the kernel from user mode.

This is important specifically for interAptiv with EVA enabled,
otherwise kernel mode RPS mispredicts may trigger speculative fetches of
user return addresses, which may be sensitive in the kernel address
space due to EVA's overlapping user/kernel address spaces.

Signed-off-by: James Hogan &lt;james.hogan@imgtec.com&gt;
Cc: Ralf Baechle &lt;ralf@linux-mips.org&gt;
Cc: Markos Chandras &lt;markos.chandras@imgtec.com&gt;
Cc: Leonid Yegoshin &lt;leonid.yegoshin@imgtec.com&gt;
Cc: linux-mips@linux-mips.org
Cc: &lt;stable@vger.kernel.org&gt; # 3.15.x-
Patchwork: https://patchwork.linux-mips.org/patch/10812/
Signed-off-by: Ralf Baechle &lt;ralf@linux-mips.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
When EVA is enabled, flush the Return Prediction Stack (RPS) present on
some MIPS cores on entry to the kernel from user mode.

This is important specifically for interAptiv with EVA enabled,
otherwise kernel mode RPS mispredicts may trigger speculative fetches of
user return addresses, which may be sensitive in the kernel address
space due to EVA's overlapping user/kernel address spaces.

Signed-off-by: James Hogan &lt;james.hogan@imgtec.com&gt;
Cc: Ralf Baechle &lt;ralf@linux-mips.org&gt;
Cc: Markos Chandras &lt;markos.chandras@imgtec.com&gt;
Cc: Leonid Yegoshin &lt;leonid.yegoshin@imgtec.com&gt;
Cc: linux-mips@linux-mips.org
Cc: &lt;stable@vger.kernel.org&gt; # 3.15.x-
Patchwork: https://patchwork.linux-mips.org/patch/10812/
Signed-off-by: Ralf Baechle &lt;ralf@linux-mips.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>Revert "MIPS: BCM63xx: Provide a plat_post_dma_flush hook"</title>
<updated>2015-08-03T08:19:22+00:00</updated>
<author>
<name>Florian Fainelli</name>
<email>f.fainelli@gmail.com</email>
</author>
<published>2015-07-29T02:24:24+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=247bfb65d731350093f5d1a0a8b3d65e49c17baa'/>
<id>247bfb65d731350093f5d1a0a8b3d65e49c17baa</id>
<content type='text'>
This reverts commit 3cf29543413207d3ab1c3f62a88c09bb46f2264e ("MIPS:
BCM63xx: Provide a plat_post_dma_flush hook") since this commit was
found to prevent BCM6358 (early BMIPS4350 cores) and some BCM6368
(BMIPS4380 cores) from booting reliably.

Alvaro was able to track this down to an issue specifically located to
devices that use the second thread (TP1) when booting. Since BCM63xx did
not have a need for plat_post_dma_flush() hook before, let's just keep
things the way they were.

Reported-by: Álvaro Fernández Rojas &lt;noltari@gmail.com&gt;
Reported-by: Jonas Gorski &lt;jogo@openwrt.org&gt;
Signed-off-by: Florian Fainelli &lt;f.fainelli@gmail.com&gt;
Cc: stable@vger.kernel.org
Cc: Kevin Cernekee &lt;cernekee@gmail.com&gt;
Cc: Nicolas Schichan &lt;nschichan@freebox.fr&gt;
Cc: linux-mips@linux-mips.org
Cc: blogic@openwrt.org
Cc: noltari@gmail.com
Cc: jogo@openwrt.org
Cc: Florian Fainelli &lt;f.fainelli@gmail.com&gt;
Cc: stable@vger.kernel.org
Patchwork: https://patchwork.linux-mips.org/patch/10804/
Signed-off-by: Ralf Baechle &lt;ralf@linux-mips.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
This reverts commit 3cf29543413207d3ab1c3f62a88c09bb46f2264e ("MIPS:
BCM63xx: Provide a plat_post_dma_flush hook") since this commit was
found to prevent BCM6358 (early BMIPS4350 cores) and some BCM6368
(BMIPS4380 cores) from booting reliably.

Alvaro was able to track this down to an issue specifically located to
devices that use the second thread (TP1) when booting. Since BCM63xx did
not have a need for plat_post_dma_flush() hook before, let's just keep
things the way they were.

Reported-by: Álvaro Fernández Rojas &lt;noltari@gmail.com&gt;
Reported-by: Jonas Gorski &lt;jogo@openwrt.org&gt;
Signed-off-by: Florian Fainelli &lt;f.fainelli@gmail.com&gt;
Cc: stable@vger.kernel.org
Cc: Kevin Cernekee &lt;cernekee@gmail.com&gt;
Cc: Nicolas Schichan &lt;nschichan@freebox.fr&gt;
Cc: linux-mips@linux-mips.org
Cc: blogic@openwrt.org
Cc: noltari@gmail.com
Cc: jogo@openwrt.org
Cc: Florian Fainelli &lt;f.fainelli@gmail.com&gt;
Cc: stable@vger.kernel.org
Patchwork: https://patchwork.linux-mips.org/patch/10804/
Signed-off-by: Ralf Baechle &lt;ralf@linux-mips.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>MIPS: BMIPS: Delete unused Kconfig symbol</title>
<updated>2015-08-03T08:11:14+00:00</updated>
<author>
<name>Kevin Cernekee</name>
<email>cernekee@chromium.org</email>
</author>
<published>2015-04-28T17:52:50+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=3592bb08fb2da21157bc2837c4c9a951b84d0c7a'/>
<id>3592bb08fb2da21157bc2837c4c9a951b84d0c7a</id>
<content type='text'>
This was left over from an earlier iteration of the BMIPS irqchip changes.
It doesn't actually have an effect, so let's nuke it.

Reported-by: Valentin Rothberg &lt;valentinrothberg@gmail.com&gt;
Signed-off-by: Kevin Cernekee &lt;cernekee@chromium.org&gt;
Acked-by: Florian Fainelli &lt;f.fainelli@gmail.com&gt;
Cc: stable@vger.kernel.org # v4.1+
Cc: linux-mips@linux-mips.org
Cc: linux-kernel@vger.kernel.org
Patchwork: https://patchwork.linux-mips.org/patch/9910/
Signed-off-by: Ralf Baechle &lt;ralf@linux-mips.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
This was left over from an earlier iteration of the BMIPS irqchip changes.
It doesn't actually have an effect, so let's nuke it.

Reported-by: Valentin Rothberg &lt;valentinrothberg@gmail.com&gt;
Signed-off-by: Kevin Cernekee &lt;cernekee@chromium.org&gt;
Acked-by: Florian Fainelli &lt;f.fainelli@gmail.com&gt;
Cc: stable@vger.kernel.org # v4.1+
Cc: linux-mips@linux-mips.org
Cc: linux-kernel@vger.kernel.org
Patchwork: https://patchwork.linux-mips.org/patch/9910/
Signed-off-by: Ralf Baechle &lt;ralf@linux-mips.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>MIPS: Export get_c0_perfcount_int()</title>
<updated>2015-08-03T07:25:18+00:00</updated>
<author>
<name>Felix Fietkau</name>
<email>nbd@openwrt.org</email>
</author>
<published>2015-07-23T16:59:52+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=0cb0985f57783c2f3c6c8ffe7e7665e80c56bd92'/>
<id>0cb0985f57783c2f3c6c8ffe7e7665e80c56bd92</id>
<content type='text'>
get_c0_perfcount_int is tested from oprofile code. If oprofile is
compiled as module, get_c0_perfcount_int needs to be exported, otherwise
it cannot be resolved.

Fixes: a669efc4a3b4 ("MIPS: Add hook to get C0 performance counter interrupt")
Cc: stable@vger.kernel.org # v3.19+
Signed-off-by: Felix Fietkau &lt;nbd@openwrt.org&gt;
Cc: linux-mips@linux-mips.org
Cc: abrestic@chromium.org
Patchwork: https://patchwork.linux-mips.org/patch/10763/
Signed-off-by: Ralf Baechle &lt;ralf@linux-mips.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
get_c0_perfcount_int is tested from oprofile code. If oprofile is
compiled as module, get_c0_perfcount_int needs to be exported, otherwise
it cannot be resolved.

Fixes: a669efc4a3b4 ("MIPS: Add hook to get C0 performance counter interrupt")
Cc: stable@vger.kernel.org # v3.19+
Signed-off-by: Felix Fietkau &lt;nbd@openwrt.org&gt;
Cc: linux-mips@linux-mips.org
Cc: abrestic@chromium.org
Patchwork: https://patchwork.linux-mips.org/patch/10763/
Signed-off-by: Ralf Baechle &lt;ralf@linux-mips.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>MIPS: show_stack: Fix stack trace with EVA</title>
<updated>2015-08-03T07:25:17+00:00</updated>
<author>
<name>James Hogan</name>
<email>james.hogan@imgtec.com</email>
</author>
<published>2015-07-27T12:50:22+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=1e77863a51698c4319587df34171bd823691a66a'/>
<id>1e77863a51698c4319587df34171bd823691a66a</id>
<content type='text'>
The show_stack() function deals exclusively with kernel contexts, but if
it gets called in user context with EVA enabled, show_stacktrace() will
attempt to access the stack using EVA accesses, which will either read
other user mapped data, or more likely cause an exception which will be
handled by __get_user().

This is easily reproduced using SysRq t to show all task states, which
results in the following stack dump output:

 Stack : (Bad stack address)

Fix by setting the current user access mode to kernel around the call to
show_stacktrace(). This causes __get_user() to use normal loads to read
the kernel stack.

Now we get the correct output, like this:

 Stack : 00000000 80168960 00000000 004a0000 00000000 00000000 8060016c 1f3abd0c
           1f172cd8 8056f09c 7ff1e450 8014fc3c 00000001 806dd0b0 0000001d 00000002
           1f17c6a0 1f17c804 1f17c6a0 8066f6e0 00000000 0000000a 00000000 00000000
           00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
           00000000 00000000 00000000 00000000 00000000 0110e800 1f3abd6c 1f17c6a0
           ...

Signed-off-by: James Hogan &lt;james.hogan@imgtec.com&gt;
Cc: Markos Chandras &lt;markos.chandras@imgtec.com&gt;
Cc: Leonid Yegoshin &lt;leonid.yegoshin@imgtec.com&gt;
Cc: linux-mips@linux-mips.org
Cc: &lt;stable@vger.kernel.org&gt; # 3.15+
Patchwork: https://patchwork.linux-mips.org/patch/10778/
Signed-off-by: Ralf Baechle &lt;ralf@linux-mips.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
The show_stack() function deals exclusively with kernel contexts, but if
it gets called in user context with EVA enabled, show_stacktrace() will
attempt to access the stack using EVA accesses, which will either read
other user mapped data, or more likely cause an exception which will be
handled by __get_user().

This is easily reproduced using SysRq t to show all task states, which
results in the following stack dump output:

 Stack : (Bad stack address)

Fix by setting the current user access mode to kernel around the call to
show_stacktrace(). This causes __get_user() to use normal loads to read
the kernel stack.

Now we get the correct output, like this:

 Stack : 00000000 80168960 00000000 004a0000 00000000 00000000 8060016c 1f3abd0c
           1f172cd8 8056f09c 7ff1e450 8014fc3c 00000001 806dd0b0 0000001d 00000002
           1f17c6a0 1f17c804 1f17c6a0 8066f6e0 00000000 0000000a 00000000 00000000
           00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
           00000000 00000000 00000000 00000000 00000000 0110e800 1f3abd6c 1f17c6a0
           ...

Signed-off-by: James Hogan &lt;james.hogan@imgtec.com&gt;
Cc: Markos Chandras &lt;markos.chandras@imgtec.com&gt;
Cc: Leonid Yegoshin &lt;leonid.yegoshin@imgtec.com&gt;
Cc: linux-mips@linux-mips.org
Cc: &lt;stable@vger.kernel.org&gt; # 3.15+
Patchwork: https://patchwork.linux-mips.org/patch/10778/
Signed-off-by: Ralf Baechle &lt;ralf@linux-mips.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>MIPS: do_mcheck: Fix kernel code dump with EVA</title>
<updated>2015-08-03T07:25:14+00:00</updated>
<author>
<name>James Hogan</name>
<email>james.hogan@imgtec.com</email>
</author>
<published>2015-07-27T12:50:21+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=55c723e181ccec30fb5c672397fe69ec35967d97'/>
<id>55c723e181ccec30fb5c672397fe69ec35967d97</id>
<content type='text'>
If a machine check exception is raised in kernel mode, user context,
with EVA enabled, then the do_mcheck handler will attempt to read the
code around the EPC using EVA load instructions, i.e. as if the reads
were from user mode. This will either read random user data if the
process has anything mapped at the same address, or it will cause an
exception which is handled by __get_user, resulting in this output:

 Code: (Bad address in epc)

Fix by setting the current user access mode to kernel if the saved
register context indicates the exception was taken in kernel mode. This
causes __get_user to use normal loads to read the kernel code.

Signed-off-by: James Hogan &lt;james.hogan@imgtec.com&gt;
Cc: Markos Chandras &lt;markos.chandras@imgtec.com&gt;
Cc: Leonid Yegoshin &lt;leonid.yegoshin@imgtec.com&gt;
Cc: linux-mips@linux-mips.org
Cc: &lt;stable@vger.kernel.org&gt; # 3.15+
Patchwork: https://patchwork.linux-mips.org/patch/10777/
Signed-off-by: Ralf Baechle &lt;ralf@linux-mips.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
If a machine check exception is raised in kernel mode, user context,
with EVA enabled, then the do_mcheck handler will attempt to read the
code around the EPC using EVA load instructions, i.e. as if the reads
were from user mode. This will either read random user data if the
process has anything mapped at the same address, or it will cause an
exception which is handled by __get_user, resulting in this output:

 Code: (Bad address in epc)

Fix by setting the current user access mode to kernel if the saved
register context indicates the exception was taken in kernel mode. This
causes __get_user to use normal loads to read the kernel code.

Signed-off-by: James Hogan &lt;james.hogan@imgtec.com&gt;
Cc: Markos Chandras &lt;markos.chandras@imgtec.com&gt;
Cc: Leonid Yegoshin &lt;leonid.yegoshin@imgtec.com&gt;
Cc: linux-mips@linux-mips.org
Cc: &lt;stable@vger.kernel.org&gt; # 3.15+
Patchwork: https://patchwork.linux-mips.org/patch/10777/
Signed-off-by: Ralf Baechle &lt;ralf@linux-mips.org&gt;
</pre>
</div>
</content>
</entry>
</feed>
