<feed xmlns='http://www.w3.org/2005/Atom'>
<title>linux-stable.git/arch/mips, branch v4.20.2</title>
<subtitle>Linux kernel stable tree</subtitle>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/'/>
<entry>
<title>MIPS: Only include mmzone.h when CONFIG_NEED_MULTIPLE_NODES=y</title>
<updated>2019-01-09T16:46:05+00:00</updated>
<author>
<name>Paul Burton</name>
<email>paul.burton@mips.com</email>
</author>
<published>2018-11-22T03:47:57+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=0b8c26bf92188d81e657a998be9fad58aa03dca2'/>
<id>0b8c26bf92188d81e657a998be9fad58aa03dca2</id>
<content type='text'>
commit 66a4059ba72c23ae74a7c702894ff76c4b7eac1f upstream.

MIPS' asm/mmzone.h includes the machine/platform mmzone.h
unconditionally, but since commit bb53fdf395ee ("MIPS: c-r4k: Add
r4k_blast_scache_node for Loongson-3") is included by asm/rk4cache.h for
all r4k-style configs regardless of CONFIG_NEED_MULTIPLE_NODES.

This is problematic when CONFIG_NEED_MULTIPLE_NODES=n because both the
loongson3 &amp; ip27 mmzone.h headers unconditionally define the NODE_DATA
preprocessor macro which is aready defined by linux/mmzone.h, resulting
in the following build error:

  In file included from ./arch/mips/include/asm/mmzone.h:10,
                   from ./arch/mips/include/asm/r4kcache.h:23,
                   from arch/mips/mm/c-r4k.c:33:
  ./arch/mips/include/asm/mach-loongson64/mmzone.h:48: error: "NODE_DATA" redefined [-Werror]
   #define NODE_DATA(n)  (&amp;__node_data[(n)]-&gt;pglist)

  In file included from ./include/linux/topology.h:32,
                   from ./include/linux/irq.h:19,
                   from ./include/asm-generic/hardirq.h:13,
                   from ./arch/mips/include/asm/hardirq.h:16,
                   from ./include/linux/hardirq.h:9,
                   from arch/mips/mm/c-r4k.c:11:
  ./include/linux/mmzone.h:907: note: this is the location of the previous definition
   #define NODE_DATA(nid)  (&amp;contig_page_data)

Resolve this by only including the machine mmzone.h when
CONFIG_NEED_MULTIPLE_NODES=y, which also removes the need for the empty
mach-generic version of the header which we delete.

Signed-off-by: Paul Burton &lt;paul.burton@mips.com&gt;
Fixes: bb53fdf395ee ("MIPS: c-r4k: Add r4k_blast_scache_node for Loongson-3")
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit 66a4059ba72c23ae74a7c702894ff76c4b7eac1f upstream.

MIPS' asm/mmzone.h includes the machine/platform mmzone.h
unconditionally, but since commit bb53fdf395ee ("MIPS: c-r4k: Add
r4k_blast_scache_node for Loongson-3") is included by asm/rk4cache.h for
all r4k-style configs regardless of CONFIG_NEED_MULTIPLE_NODES.

This is problematic when CONFIG_NEED_MULTIPLE_NODES=n because both the
loongson3 &amp; ip27 mmzone.h headers unconditionally define the NODE_DATA
preprocessor macro which is aready defined by linux/mmzone.h, resulting
in the following build error:

  In file included from ./arch/mips/include/asm/mmzone.h:10,
                   from ./arch/mips/include/asm/r4kcache.h:23,
                   from arch/mips/mm/c-r4k.c:33:
  ./arch/mips/include/asm/mach-loongson64/mmzone.h:48: error: "NODE_DATA" redefined [-Werror]
   #define NODE_DATA(n)  (&amp;__node_data[(n)]-&gt;pglist)

  In file included from ./include/linux/topology.h:32,
                   from ./include/linux/irq.h:19,
                   from ./include/asm-generic/hardirq.h:13,
                   from ./arch/mips/include/asm/hardirq.h:16,
                   from ./include/linux/hardirq.h:9,
                   from arch/mips/mm/c-r4k.c:11:
  ./include/linux/mmzone.h:907: note: this is the location of the previous definition
   #define NODE_DATA(nid)  (&amp;contig_page_data)

Resolve this by only including the machine mmzone.h when
CONFIG_NEED_MULTIPLE_NODES=y, which also removes the need for the empty
mach-generic version of the header which we delete.

Signed-off-by: Paul Burton &lt;paul.burton@mips.com&gt;
Fixes: bb53fdf395ee ("MIPS: c-r4k: Add r4k_blast_scache_node for Loongson-3")
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>MIPS: Fix a R10000_LLSC_WAR logic in atomic.h</title>
<updated>2019-01-09T16:46:03+00:00</updated>
<author>
<name>Huacai Chen</name>
<email>chenhc@lemote.com</email>
</author>
<published>2018-12-25T00:51:01+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=47b27006bb5025091759f11040d3f110ec1f65bb'/>
<id>47b27006bb5025091759f11040d3f110ec1f65bb</id>
<content type='text'>
commit db1ce3f5d01d2d6d5714aefba0159d2cb5167a0b upstream.

Commit 4936084c2ee2 ("MIPS: Cleanup R10000_LLSC_WAR logic in atomic.h")
introduce a mistake in atomic64_fetch_##op##_relaxed(), because it
forget to delete R10000_LLSC_WAR in the if-condition. So fix it.

Fixes: 4936084c2ee2 ("MIPS: Cleanup R10000_LLSC_WAR logic in atomic.h")
Signed-off-by: Huacai Chen &lt;chenhc@lemote.com&gt;
Signed-off-by: Paul Burton &lt;paul.burton@mips.com&gt;
Cc: Joshua Kinard &lt;kumba@gentoo.org&gt;
Cc: Ralf Baechle &lt;ralf@linux-mips.org&gt;
Cc: Steven J . Hill &lt;Steven.Hill@cavium.com&gt;
Cc: Fuxin Zhang &lt;zhangfx@lemote.com&gt;
Cc: Zhangjin Wu &lt;wuzhangjin@gmail.com&gt;
Cc: linux-mips@linux-mips.org
Cc: stable@vger.kernel.org # 4.19+
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit db1ce3f5d01d2d6d5714aefba0159d2cb5167a0b upstream.

Commit 4936084c2ee2 ("MIPS: Cleanup R10000_LLSC_WAR logic in atomic.h")
introduce a mistake in atomic64_fetch_##op##_relaxed(), because it
forget to delete R10000_LLSC_WAR in the if-condition. So fix it.

Fixes: 4936084c2ee2 ("MIPS: Cleanup R10000_LLSC_WAR logic in atomic.h")
Signed-off-by: Huacai Chen &lt;chenhc@lemote.com&gt;
Signed-off-by: Paul Burton &lt;paul.burton@mips.com&gt;
Cc: Joshua Kinard &lt;kumba@gentoo.org&gt;
Cc: Ralf Baechle &lt;ralf@linux-mips.org&gt;
Cc: Steven J . Hill &lt;Steven.Hill@cavium.com&gt;
Cc: Fuxin Zhang &lt;zhangfx@lemote.com&gt;
Cc: Zhangjin Wu &lt;wuzhangjin@gmail.com&gt;
Cc: linux-mips@linux-mips.org
Cc: stable@vger.kernel.org # 4.19+
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>MIPS: OCTEON: mark RGMII interface disabled on OCTEON III</title>
<updated>2019-01-09T16:46:03+00:00</updated>
<author>
<name>Aaro Koskinen</name>
<email>aaro.koskinen@iki.fi</email>
</author>
<published>2019-01-02T18:43:01+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=febb155bc1d2b74c1b0c2c622bf69a84932eb6ba'/>
<id>febb155bc1d2b74c1b0c2c622bf69a84932eb6ba</id>
<content type='text'>
commit edefae94b7b9f10d5efe32dece5a36e9d9ecc29e upstream.

Commit 885872b722b7 ("MIPS: Octeon: Add Octeon III CN7xxx
interface detection") added RGMII interface detection for OCTEON III,
but it results in the following logs:

[    7.165984] ERROR: Unsupported Octeon model in __cvmx_helper_rgmii_probe
[    7.173017] ERROR: Unsupported Octeon model in __cvmx_helper_rgmii_probe

The current RGMII routines are valid only for older OCTEONS that
use GMX/ASX hardware blocks. On later chips AGL should be used,
but support for that is missing in the mainline. Until that is added,
mark the interface as disabled.

Fixes: 885872b722b7 ("MIPS: Octeon: Add Octeon III CN7xxx interface detection")
Signed-off-by: Aaro Koskinen &lt;aaro.koskinen@iki.fi&gt;
Signed-off-by: Paul Burton &lt;paul.burton@mips.com&gt;
Cc: Ralf Baechle &lt;ralf@linux-mips.org&gt;
Cc: James Hogan &lt;jhogan@kernel.org&gt;
Cc: linux-mips@vger.kernel.org
Cc: stable@vger.kernel.org # 4.7+
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit edefae94b7b9f10d5efe32dece5a36e9d9ecc29e upstream.

Commit 885872b722b7 ("MIPS: Octeon: Add Octeon III CN7xxx
interface detection") added RGMII interface detection for OCTEON III,
but it results in the following logs:

[    7.165984] ERROR: Unsupported Octeon model in __cvmx_helper_rgmii_probe
[    7.173017] ERROR: Unsupported Octeon model in __cvmx_helper_rgmii_probe

The current RGMII routines are valid only for older OCTEONS that
use GMX/ASX hardware blocks. On later chips AGL should be used,
but support for that is missing in the mainline. Until that is added,
mark the interface as disabled.

Fixes: 885872b722b7 ("MIPS: Octeon: Add Octeon III CN7xxx interface detection")
Signed-off-by: Aaro Koskinen &lt;aaro.koskinen@iki.fi&gt;
Signed-off-by: Paul Burton &lt;paul.burton@mips.com&gt;
Cc: Ralf Baechle &lt;ralf@linux-mips.org&gt;
Cc: James Hogan &lt;jhogan@kernel.org&gt;
Cc: linux-mips@vger.kernel.org
Cc: stable@vger.kernel.org # 4.7+
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>MIPS: Expand MIPS32 ASIDs to 64 bits</title>
<updated>2019-01-09T16:46:03+00:00</updated>
<author>
<name>Paul Burton</name>
<email>paul.burton@mips.com</email>
</author>
<published>2018-12-04T23:44:12+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=21439032da7c43700d9b1d2377f828acb3b6bdd5'/>
<id>21439032da7c43700d9b1d2377f828acb3b6bdd5</id>
<content type='text'>
commit ff4dd232ec45a0e45ea69f28f069f2ab22b4908a upstream.

ASIDs have always been stored as unsigned longs, ie. 32 bits on MIPS32
kernels. This is problematic because it is feasible for the ASID version
to overflow &amp; wrap around to zero.

We currently attempt to handle this overflow by simply setting the ASID
version to 1, using asid_first_version(), but we make no attempt to
account for the fact that there may be mm_structs with stale ASIDs that
have versions which we now reuse due to the overflow &amp; wrap around.

Encountering this requires that:

  1) A struct mm_struct X is active on CPU A using ASID (V,n).

  2) That mm is not used on CPU A for the length of time that it takes
     for CPU A's asid_cache to overflow &amp; wrap around to the same
     version V that the mm had in step 1. During this time tasks using
     the mm could either be sleeping or only scheduled on other CPUs.

  3) Some other mm Y becomes active on CPU A and is allocated the same
     ASID (V,n).

  4) mm X now becomes active on CPU A again, and now incorrectly has the
     same ASID as mm Y.

Where struct mm_struct ASIDs are represented above in the format
(version, EntryHi.ASID), and on a typical MIPS32 system version will be
24 bits wide &amp; EntryHi.ASID will be 8 bits wide.

The length of time required in step 2 is highly dependent upon the CPU &amp;
workload, but for a hypothetical 2GHz CPU running a workload which
generates a new ASID every 10000 cycles this period is around 248 days.
Due to this long period of time &amp; the fact that tasks need to be
scheduled in just the right (or wrong, depending upon your inclination)
way, this is obviously a difficult bug to encounter but it's entirely
possible as evidenced by reports.

In order to fix this, simply extend ASIDs to 64 bits even on MIPS32
builds. This will extend the period of time required for the
hypothetical system above to encounter the problem from 28 days to
around 3 trillion years, which feels safely outside of the realms of
possibility.

The cost of this is slightly more generated code in some commonly
executed paths, but this is pretty minimal:

                         | Code Size Gain | Percentage
  -----------------------|----------------|-------------
    decstation_defconfig |           +270 | +0.00%
        32r2el_defconfig |           +652 | +0.01%
        32r6el_defconfig |          +1000 | +0.01%

I have been unable to measure any change in performance of the LMbench
lat_ctx or lat_proc tests resulting from the 64b ASIDs on either
32r2el_defconfig+interAptiv or 32r6el_defconfig+I6500 systems.

Signed-off-by: Paul Burton &lt;paul.burton@mips.com&gt;
Suggested-by: James Hogan &lt;jhogan@kernel.org&gt;
References: https://lore.kernel.org/linux-mips/80B78A8B8FEE6145A87579E8435D78C30205D5F3@fzex.ruijie.com.cn/
References: https://lore.kernel.org/linux-mips/1488684260-18867-1-git-send-email-jiwei.sun@windriver.com/
Cc: Jiwei Sun &lt;jiwei.sun@windriver.com&gt;
Cc: Yu Huabing &lt;yhb@ruijie.com.cn&gt;
Cc: stable@vger.kernel.org # 2.6.12+
Cc: linux-mips@vger.kernel.org
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit ff4dd232ec45a0e45ea69f28f069f2ab22b4908a upstream.

ASIDs have always been stored as unsigned longs, ie. 32 bits on MIPS32
kernels. This is problematic because it is feasible for the ASID version
to overflow &amp; wrap around to zero.

We currently attempt to handle this overflow by simply setting the ASID
version to 1, using asid_first_version(), but we make no attempt to
account for the fact that there may be mm_structs with stale ASIDs that
have versions which we now reuse due to the overflow &amp; wrap around.

Encountering this requires that:

  1) A struct mm_struct X is active on CPU A using ASID (V,n).

  2) That mm is not used on CPU A for the length of time that it takes
     for CPU A's asid_cache to overflow &amp; wrap around to the same
     version V that the mm had in step 1. During this time tasks using
     the mm could either be sleeping or only scheduled on other CPUs.

  3) Some other mm Y becomes active on CPU A and is allocated the same
     ASID (V,n).

  4) mm X now becomes active on CPU A again, and now incorrectly has the
     same ASID as mm Y.

Where struct mm_struct ASIDs are represented above in the format
(version, EntryHi.ASID), and on a typical MIPS32 system version will be
24 bits wide &amp; EntryHi.ASID will be 8 bits wide.

The length of time required in step 2 is highly dependent upon the CPU &amp;
workload, but for a hypothetical 2GHz CPU running a workload which
generates a new ASID every 10000 cycles this period is around 248 days.
Due to this long period of time &amp; the fact that tasks need to be
scheduled in just the right (or wrong, depending upon your inclination)
way, this is obviously a difficult bug to encounter but it's entirely
possible as evidenced by reports.

In order to fix this, simply extend ASIDs to 64 bits even on MIPS32
builds. This will extend the period of time required for the
hypothetical system above to encounter the problem from 28 days to
around 3 trillion years, which feels safely outside of the realms of
possibility.

The cost of this is slightly more generated code in some commonly
executed paths, but this is pretty minimal:

                         | Code Size Gain | Percentage
  -----------------------|----------------|-------------
    decstation_defconfig |           +270 | +0.00%
        32r2el_defconfig |           +652 | +0.01%
        32r6el_defconfig |          +1000 | +0.01%

I have been unable to measure any change in performance of the LMbench
lat_ctx or lat_proc tests resulting from the 64b ASIDs on either
32r2el_defconfig+interAptiv or 32r6el_defconfig+I6500 systems.

Signed-off-by: Paul Burton &lt;paul.burton@mips.com&gt;
Suggested-by: James Hogan &lt;jhogan@kernel.org&gt;
References: https://lore.kernel.org/linux-mips/80B78A8B8FEE6145A87579E8435D78C30205D5F3@fzex.ruijie.com.cn/
References: https://lore.kernel.org/linux-mips/1488684260-18867-1-git-send-email-jiwei.sun@windriver.com/
Cc: Jiwei Sun &lt;jiwei.sun@windriver.com&gt;
Cc: Yu Huabing &lt;yhb@ruijie.com.cn&gt;
Cc: stable@vger.kernel.org # 2.6.12+
Cc: linux-mips@vger.kernel.org
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>MIPS: Align kernel load address to 64KB</title>
<updated>2019-01-09T16:46:03+00:00</updated>
<author>
<name>Huacai Chen</name>
<email>chenhc@lemote.com</email>
</author>
<published>2018-11-15T07:53:56+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=6a98e9410b7fdddc1fe093c9da1079364c0a15f9'/>
<id>6a98e9410b7fdddc1fe093c9da1079364c0a15f9</id>
<content type='text'>
commit bec0de4cfad21bd284dbddee016ed1767a5d2823 upstream.

KEXEC needs the new kernel's load address to be aligned on a page
boundary (see sanity_check_segment_list()), but on MIPS the default
vmlinuz load address is only explicitly aligned to 16 bytes.

Since the largest PAGE_SIZE supported by MIPS kernels is 64KB, increase
the alignment calculated by calc_vmlinuz_load_addr to 64KB.

Signed-off-by: Huacai Chen &lt;chenhc@lemote.com&gt;
Signed-off-by: Paul Burton &lt;paul.burton@mips.com&gt;
Patchwork: https://patchwork.linux-mips.org/patch/21131/
Cc: Ralf Baechle &lt;ralf@linux-mips.org&gt;
Cc: James Hogan &lt;james.hogan@mips.com&gt;
Cc: Steven J . Hill &lt;Steven.Hill@cavium.com&gt;
Cc: linux-mips@linux-mips.org
Cc: Fuxin Zhang &lt;zhangfx@lemote.com&gt;
Cc: Zhangjin Wu &lt;wuzhangjin@gmail.com&gt;
Cc: &lt;stable@vger.kernel.org&gt; # 2.6.36+
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit bec0de4cfad21bd284dbddee016ed1767a5d2823 upstream.

KEXEC needs the new kernel's load address to be aligned on a page
boundary (see sanity_check_segment_list()), but on MIPS the default
vmlinuz load address is only explicitly aligned to 16 bytes.

Since the largest PAGE_SIZE supported by MIPS kernels is 64KB, increase
the alignment calculated by calc_vmlinuz_load_addr to 64KB.

Signed-off-by: Huacai Chen &lt;chenhc@lemote.com&gt;
Signed-off-by: Paul Burton &lt;paul.burton@mips.com&gt;
Patchwork: https://patchwork.linux-mips.org/patch/21131/
Cc: Ralf Baechle &lt;ralf@linux-mips.org&gt;
Cc: James Hogan &lt;james.hogan@mips.com&gt;
Cc: Steven J . Hill &lt;Steven.Hill@cavium.com&gt;
Cc: linux-mips@linux-mips.org
Cc: Fuxin Zhang &lt;zhangfx@lemote.com&gt;
Cc: Zhangjin Wu &lt;wuzhangjin@gmail.com&gt;
Cc: &lt;stable@vger.kernel.org&gt; # 2.6.36+
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>MIPS: Ensure pmd_present() returns false after pmd_mknotpresent()</title>
<updated>2019-01-09T16:46:02+00:00</updated>
<author>
<name>Huacai Chen</name>
<email>chenhc@lemote.com</email>
</author>
<published>2018-11-15T07:53:54+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=23213dea867b017af2cc529fea424f5fcff8209c'/>
<id>23213dea867b017af2cc529fea424f5fcff8209c</id>
<content type='text'>
commit 92aa0718c9fa5160ad2f0e7b5bffb52f1ea1e51a upstream.

This patch is borrowed from ARM64 to ensure pmd_present() returns false
after pmd_mknotpresent(). This is needed for THP.

References: 5bb1cc0ff9a6 ("arm64: Ensure pmd_present() returns false after pmd_mknotpresent()")
Reviewed-by: James Hogan &lt;jhogan@kernel.org&gt;
Signed-off-by: Huacai Chen &lt;chenhc@lemote.com&gt;
Signed-off-by: Paul Burton &lt;paul.burton@mips.com&gt;
Patchwork: https://patchwork.linux-mips.org/patch/21135/
Cc: Ralf Baechle &lt;ralf@linux-mips.org&gt;
Cc: James Hogan &lt;james.hogan@mips.com&gt;
Cc: Steven J . Hill &lt;Steven.Hill@cavium.com&gt;
Cc: linux-mips@linux-mips.org
Cc: Fuxin Zhang &lt;zhangfx@lemote.com&gt;
Cc: Zhangjin Wu &lt;wuzhangjin@gmail.com&gt;
Cc: &lt;stable@vger.kernel.org&gt; # 3.8+
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit 92aa0718c9fa5160ad2f0e7b5bffb52f1ea1e51a upstream.

This patch is borrowed from ARM64 to ensure pmd_present() returns false
after pmd_mknotpresent(). This is needed for THP.

References: 5bb1cc0ff9a6 ("arm64: Ensure pmd_present() returns false after pmd_mknotpresent()")
Reviewed-by: James Hogan &lt;jhogan@kernel.org&gt;
Signed-off-by: Huacai Chen &lt;chenhc@lemote.com&gt;
Signed-off-by: Paul Burton &lt;paul.burton@mips.com&gt;
Patchwork: https://patchwork.linux-mips.org/patch/21135/
Cc: Ralf Baechle &lt;ralf@linux-mips.org&gt;
Cc: James Hogan &lt;james.hogan@mips.com&gt;
Cc: Steven J . Hill &lt;Steven.Hill@cavium.com&gt;
Cc: linux-mips@linux-mips.org
Cc: Fuxin Zhang &lt;zhangfx@lemote.com&gt;
Cc: Zhangjin Wu &lt;wuzhangjin@gmail.com&gt;
Cc: &lt;stable@vger.kernel.org&gt; # 3.8+
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>MIPS: c-r4k: Add r4k_blast_scache_node for Loongson-3</title>
<updated>2019-01-09T16:46:02+00:00</updated>
<author>
<name>Huacai Chen</name>
<email>chenhc@lemote.com</email>
</author>
<published>2018-11-15T07:53:53+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=a0c4f99279322356a7292c0197ab54634dcd5cc0'/>
<id>a0c4f99279322356a7292c0197ab54634dcd5cc0</id>
<content type='text'>
commit bb53fdf395eed103f85061bfff3b116cee123895 upstream.

For multi-node Loongson-3 (NUMA configuration), r4k_blast_scache() can
only flush Node-0's scache. So we add r4k_blast_scache_node() by using
(CAC_BASE | (node_id &lt;&lt; NODE_ADDRSPACE_SHIFT)) instead of CKSEG0 as the
start address.

Signed-off-by: Huacai Chen &lt;chenhc@lemote.com&gt;
[paul.burton@mips.com: Include asm/mmzone.h from asm/r4kcache.h for
		       nid_to_addrbase(). Add asm/mach-generic/mmzone.h
		       to allow inclusion for all platforms.]
Signed-off-by: Paul Burton &lt;paul.burton@mips.com&gt;
Patchwork: https://patchwork.linux-mips.org/patch/21129/
Cc: Ralf Baechle &lt;ralf@linux-mips.org&gt;
Cc: James Hogan &lt;james.hogan@mips.com&gt;
Cc: Steven J . Hill &lt;Steven.Hill@cavium.com&gt;
Cc: linux-mips@linux-mips.org
Cc: Fuxin Zhang &lt;zhangfx@lemote.com&gt;
Cc: Zhangjin Wu &lt;wuzhangjin@gmail.com&gt;
Cc: &lt;stable@vger.kernel.org&gt; # 3.15+
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit bb53fdf395eed103f85061bfff3b116cee123895 upstream.

For multi-node Loongson-3 (NUMA configuration), r4k_blast_scache() can
only flush Node-0's scache. So we add r4k_blast_scache_node() by using
(CAC_BASE | (node_id &lt;&lt; NODE_ADDRSPACE_SHIFT)) instead of CKSEG0 as the
start address.

Signed-off-by: Huacai Chen &lt;chenhc@lemote.com&gt;
[paul.burton@mips.com: Include asm/mmzone.h from asm/r4kcache.h for
		       nid_to_addrbase(). Add asm/mach-generic/mmzone.h
		       to allow inclusion for all platforms.]
Signed-off-by: Paul Burton &lt;paul.burton@mips.com&gt;
Patchwork: https://patchwork.linux-mips.org/patch/21129/
Cc: Ralf Baechle &lt;ralf@linux-mips.org&gt;
Cc: James Hogan &lt;james.hogan@mips.com&gt;
Cc: Steven J . Hill &lt;Steven.Hill@cavium.com&gt;
Cc: linux-mips@linux-mips.org
Cc: Fuxin Zhang &lt;zhangfx@lemote.com&gt;
Cc: Zhangjin Wu &lt;wuzhangjin@gmail.com&gt;
Cc: &lt;stable@vger.kernel.org&gt; # 3.15+
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>MIPS: math-emu: Write-protect delay slot emulation pages</title>
<updated>2019-01-09T16:46:02+00:00</updated>
<author>
<name>Paul Burton</name>
<email>paul.burton@mips.com</email>
</author>
<published>2018-12-20T17:45:43+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=72ffe8facf657ec4e66a74699d498663a26405d6'/>
<id>72ffe8facf657ec4e66a74699d498663a26405d6</id>
<content type='text'>
commit adcc81f148d733b7e8e641300c5590a2cdc13bf3 upstream.

Mapping the delay slot emulation page as both writeable &amp; executable
presents a security risk, in that if an exploit can write to &amp; jump into
the page then it can be used as an easy way to execute arbitrary code.

Prevent this by mapping the page read-only for userland, and using
access_process_vm() with the FOLL_FORCE flag to write to it from
mips_dsemul().

This will likely be less efficient due to copy_to_user_page() performing
cache maintenance on a whole page, rather than a single line as in the
previous use of flush_cache_sigtramp(). However this delay slot
emulation code ought not to be running in any performance critical paths
anyway so this isn't really a problem, and we can probably do better in
copy_to_user_page() anyway in future.

A major advantage of this approach is that the fix is small &amp; simple to
backport to stable kernels.

Reported-by: Andy Lutomirski &lt;luto@kernel.org&gt;
Signed-off-by: Paul Burton &lt;paul.burton@mips.com&gt;
Fixes: 432c6bacbd0c ("MIPS: Use per-mm page to execute branch delay slot instructions")
Cc: stable@vger.kernel.org # v4.8+
Cc: linux-mips@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Cc: Rich Felker &lt;dalias@libc.org&gt;
Cc: David Daney &lt;david.daney@cavium.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit adcc81f148d733b7e8e641300c5590a2cdc13bf3 upstream.

Mapping the delay slot emulation page as both writeable &amp; executable
presents a security risk, in that if an exploit can write to &amp; jump into
the page then it can be used as an easy way to execute arbitrary code.

Prevent this by mapping the page read-only for userland, and using
access_process_vm() with the FOLL_FORCE flag to write to it from
mips_dsemul().

This will likely be less efficient due to copy_to_user_page() performing
cache maintenance on a whole page, rather than a single line as in the
previous use of flush_cache_sigtramp(). However this delay slot
emulation code ought not to be running in any performance critical paths
anyway so this isn't really a problem, and we can probably do better in
copy_to_user_page() anyway in future.

A major advantage of this approach is that the fix is small &amp; simple to
backport to stable kernels.

Reported-by: Andy Lutomirski &lt;luto@kernel.org&gt;
Signed-off-by: Paul Burton &lt;paul.burton@mips.com&gt;
Fixes: 432c6bacbd0c ("MIPS: Use per-mm page to execute branch delay slot instructions")
Cc: stable@vger.kernel.org # v4.8+
Cc: linux-mips@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Cc: Rich Felker &lt;dalias@libc.org&gt;
Cc: David Daney &lt;david.daney@cavium.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>Merge tag 'mips_fixes_4.20_4' of git://git.kernel.org/pub/scm/linux/kernel/git/mips/linux</title>
<updated>2018-12-01T02:41:06+00:00</updated>
<author>
<name>Linus Torvalds</name>
<email>torvalds@linux-foundation.org</email>
</author>
<published>2018-12-01T02:41:06+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=6c7954b7eb76578866eba179709c5883f29f747f'/>
<id>6c7954b7eb76578866eba179709c5883f29f747f</id>
<content type='text'>
Pull few more MIPS fixes from Paul Burton:

 - Fix mips_get_syscall_arg() to operate on the task specified when
   detecting o32 tasks running on MIPS64 kernels.

 - Fix some incorrect GPIO pin muxing for the MT7620 SoC.

 - Update the linux-mips mailing list address.

* tag 'mips_fixes_4.20_4' of git://git.kernel.org/pub/scm/linux/kernel/git/mips/linux:
  MAINTAINERS: Update linux-mips mailing list address
  MIPS: ralink: Fix mt7620 nd_sd pinmux
  mips: fix mips_get_syscall_arg o32 check
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Pull few more MIPS fixes from Paul Burton:

 - Fix mips_get_syscall_arg() to operate on the task specified when
   detecting o32 tasks running on MIPS64 kernels.

 - Fix some incorrect GPIO pin muxing for the MT7620 SoC.

 - Update the linux-mips mailing list address.

* tag 'mips_fixes_4.20_4' of git://git.kernel.org/pub/scm/linux/kernel/git/mips/linux:
  MAINTAINERS: Update linux-mips mailing list address
  MIPS: ralink: Fix mt7620 nd_sd pinmux
  mips: fix mips_get_syscall_arg o32 check
</pre>
</div>
</content>
</entry>
<entry>
<title>Merge tag 'trace-v4.20-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/rostedt/linux-trace</title>
<updated>2018-11-30T17:32:34+00:00</updated>
<author>
<name>Linus Torvalds</name>
<email>torvalds@linux-foundation.org</email>
</author>
<published>2018-11-30T17:32:34+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=0f1f692375450338a36af308cbb538ffabd130f9'/>
<id>0f1f692375450338a36af308cbb538ffabd130f9</id>
<content type='text'>
Pull tracing fixes from Steven Rostedt:
 "While rewriting the function graph tracer, I discovered a design flaw
  that was introduced by a patch that tried to fix one bug, but by doing
  so created another bug.

  As both bugs corrupt the output (but they do not crash the kernel), I
  decided to fix the design such that it could have both bugs fixed. The
  original fix, fixed time reporting of the function graph tracer when
  doing a max_depth of one. This was code that can test how much the
  kernel interferes with userspace. But in doing so, it could corrupt
  the time keeping of the function profiler.

  The issue is that the curr_ret_stack variable was being used for two
  different meanings. One was to keep track of the stack pointer on the
  ret_stack (shadow stack used by the function graph tracer), and the
  other use case was the graph call depth. Although, the two may be
  closely related, where they got updated was the issue that lead to the
  two different bugs that required the two use cases to be updated
  differently.

  The big issue with this fix is that it requires changing each
  architecture. The good news is, I was able to remove a lot of code
  that was duplicated within the architectures and place it into a
  single location. Then I could make the fix in one place.

  I pushed this code into linux-next to let it settle over a week, and
  before doing so, I cross compiled all the affected architectures to
  make sure that they built fine.

  In the mean time, I also pulled in a patch that fixes the sched_switch
  previous tasks state output, that was not actually correct"

* tag 'trace-v4.20-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/rostedt/linux-trace:
  sched, trace: Fix prev_state output in sched_switch tracepoint
  function_graph: Have profiler use curr_ret_stack and not depth
  function_graph: Reverse the order of pushing the ret_stack and the callback
  function_graph: Move return callback before update of curr_ret_stack
  function_graph: Use new curr_ret_depth to manage depth instead of curr_ret_stack
  function_graph: Make ftrace_push_return_trace() static
  sparc/function_graph: Simplify with function_graph_enter()
  sh/function_graph: Simplify with function_graph_enter()
  s390/function_graph: Simplify with function_graph_enter()
  riscv/function_graph: Simplify with function_graph_enter()
  powerpc/function_graph: Simplify with function_graph_enter()
  parisc: function_graph: Simplify with function_graph_enter()
  nds32: function_graph: Simplify with function_graph_enter()
  MIPS: function_graph: Simplify with function_graph_enter()
  microblaze: function_graph: Simplify with function_graph_enter()
  arm64: function_graph: Simplify with function_graph_enter()
  ARM: function_graph: Simplify with function_graph_enter()
  x86/function_graph: Simplify with function_graph_enter()
  function_graph: Create function_graph_enter() to consolidate architecture code
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Pull tracing fixes from Steven Rostedt:
 "While rewriting the function graph tracer, I discovered a design flaw
  that was introduced by a patch that tried to fix one bug, but by doing
  so created another bug.

  As both bugs corrupt the output (but they do not crash the kernel), I
  decided to fix the design such that it could have both bugs fixed. The
  original fix, fixed time reporting of the function graph tracer when
  doing a max_depth of one. This was code that can test how much the
  kernel interferes with userspace. But in doing so, it could corrupt
  the time keeping of the function profiler.

  The issue is that the curr_ret_stack variable was being used for two
  different meanings. One was to keep track of the stack pointer on the
  ret_stack (shadow stack used by the function graph tracer), and the
  other use case was the graph call depth. Although, the two may be
  closely related, where they got updated was the issue that lead to the
  two different bugs that required the two use cases to be updated
  differently.

  The big issue with this fix is that it requires changing each
  architecture. The good news is, I was able to remove a lot of code
  that was duplicated within the architectures and place it into a
  single location. Then I could make the fix in one place.

  I pushed this code into linux-next to let it settle over a week, and
  before doing so, I cross compiled all the affected architectures to
  make sure that they built fine.

  In the mean time, I also pulled in a patch that fixes the sched_switch
  previous tasks state output, that was not actually correct"

* tag 'trace-v4.20-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/rostedt/linux-trace:
  sched, trace: Fix prev_state output in sched_switch tracepoint
  function_graph: Have profiler use curr_ret_stack and not depth
  function_graph: Reverse the order of pushing the ret_stack and the callback
  function_graph: Move return callback before update of curr_ret_stack
  function_graph: Use new curr_ret_depth to manage depth instead of curr_ret_stack
  function_graph: Make ftrace_push_return_trace() static
  sparc/function_graph: Simplify with function_graph_enter()
  sh/function_graph: Simplify with function_graph_enter()
  s390/function_graph: Simplify with function_graph_enter()
  riscv/function_graph: Simplify with function_graph_enter()
  powerpc/function_graph: Simplify with function_graph_enter()
  parisc: function_graph: Simplify with function_graph_enter()
  nds32: function_graph: Simplify with function_graph_enter()
  MIPS: function_graph: Simplify with function_graph_enter()
  microblaze: function_graph: Simplify with function_graph_enter()
  arm64: function_graph: Simplify with function_graph_enter()
  ARM: function_graph: Simplify with function_graph_enter()
  x86/function_graph: Simplify with function_graph_enter()
  function_graph: Create function_graph_enter() to consolidate architecture code
</pre>
</div>
</content>
</entry>
</feed>
