<feed xmlns='http://www.w3.org/2005/Atom'>
<title>linux-stable.git/arch/mips/include, branch v5.4.26</title>
<subtitle>Linux kernel stable tree</subtitle>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/'/>
<entry>
<title>mips: Fix gettimeofday() in the vdso library</title>
<updated>2020-01-17T18:49:04+00:00</updated>
<author>
<name>Vincenzo Frascino</name>
<email>vincenzo.frascino@arm.com</email>
</author>
<published>2019-11-29T14:36:58+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=520e3bd3dee4266603b97ad5f5cedb88736a09c5'/>
<id>520e3bd3dee4266603b97ad5f5cedb88736a09c5</id>
<content type='text'>
[ Upstream commit 7d2aa4bb90f5f6f1b8de8848c26042403f2d7bf9 ]

The libc provides a discovery mechanism for vDSO library and its
symbols. When a symbol is not exposed by the vDSOs the libc falls back
on the system calls.

With the introduction of the unified vDSO library on mips this behavior
is not honored anymore by the kernel in the case of gettimeofday().

The issue has been noticed and reported due to a dhclient failure on the
CI20 board:

root@letux:~# dhclient
../../../../lib/isc/unix/time.c:200: Operation not permitted
root@letux:~#

Restore the original behavior fixing gettimeofday() in the vDSO library.

Reported-by: H. Nikolaus Schaller &lt;hns@goldelico.com&gt;
Tested-by: H. Nikolaus Schaller &lt;hns@goldelico.com&gt; # CI20 with JZ4780
Signed-off-by: Vincenzo Frascino &lt;vincenzo.frascino@arm.com&gt;
Signed-off-by: Paul Burton &lt;paulburton@kernel.org&gt;
Cc: mips-creator-ci20-dev@googlegroups.com
Cc: letux-kernel@openphoenux.org
Cc: linux-mips@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
[ Upstream commit 7d2aa4bb90f5f6f1b8de8848c26042403f2d7bf9 ]

The libc provides a discovery mechanism for vDSO library and its
symbols. When a symbol is not exposed by the vDSOs the libc falls back
on the system calls.

With the introduction of the unified vDSO library on mips this behavior
is not honored anymore by the kernel in the case of gettimeofday().

The issue has been noticed and reported due to a dhclient failure on the
CI20 board:

root@letux:~# dhclient
../../../../lib/isc/unix/time.c:200: Operation not permitted
root@letux:~#

Restore the original behavior fixing gettimeofday() in the vDSO library.

Reported-by: H. Nikolaus Schaller &lt;hns@goldelico.com&gt;
Tested-by: H. Nikolaus Schaller &lt;hns@goldelico.com&gt; # CI20 with JZ4780
Signed-off-by: Vincenzo Frascino &lt;vincenzo.frascino@arm.com&gt;
Signed-off-by: Paul Burton &lt;paulburton@kernel.org&gt;
Cc: mips-creator-ci20-dev@googlegroups.com
Cc: letux-kernel@openphoenux.org
Cc: linux-mips@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>MIPS: Avoid VDSO ABI breakage due to global register variable</title>
<updated>2020-01-09T09:19:56+00:00</updated>
<author>
<name>Paul Burton</name>
<email>paulburton@kernel.org</email>
</author>
<published>2020-01-02T04:50:38+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=5b004a238460113276319536534928c58d95e599'/>
<id>5b004a238460113276319536534928c58d95e599</id>
<content type='text'>
commit bbcc5672b0063b0e9d65dc8787a4f09c3b5bb5cc upstream.

Declaring __current_thread_info as a global register variable has the
effect of preventing GCC from saving &amp; restoring its value in cases
where the ABI would typically do so.

To quote GCC documentation:

&gt; If the register is a call-saved register, call ABI is affected: the
&gt; register will not be restored in function epilogue sequences after the
&gt; variable has been assigned. Therefore, functions cannot safely return
&gt; to callers that assume standard ABI.

When our position independent VDSO is built for the n32 or n64 ABIs all
functions it exposes should be preserving the value of $gp/$28 for their
caller, but in the presence of the __current_thread_info global register
variable GCC stops doing so &amp; simply clobbers $gp/$28 when calculating
the address of the GOT.

In cases where the VDSO returns success this problem will typically be
masked by the caller in libc returning &amp; restoring $gp/$28 itself, but
that is by no means guaranteed. In cases where the VDSO returns an error
libc will typically contain a fallback path which will now fail
(typically with a bad memory access) if it attempts anything which
relies upon the value of $gp/$28 - eg. accessing anything via the GOT.

One fix for this would be to move the declaration of
__current_thread_info inside the current_thread_info() function,
demoting it from global register variable to local register variable &amp;
avoiding inadvertently creating a non-standard calling ABI for the VDSO.
Unfortunately this causes issues for clang, which doesn't support local
register variables as pointed out by commit fe92da0f355e ("MIPS: Changed
current_thread_info() to an equivalent supported by both clang and GCC")
which introduced the global register variable before we had a VDSO to
worry about.

Instead, fix this by continuing to use the global register variable for
the kernel proper but declare __current_thread_info as a simple extern
variable when building the VDSO. It should never be referenced, and will
cause a link error if it is. This resolves the calling convention issue
for the VDSO without having any impact upon the build of the kernel
itself for either clang or gcc.

Signed-off-by: Paul Burton &lt;paulburton@kernel.org&gt;
Fixes: ebb5e78cc634 ("MIPS: Initial implementation of a VDSO")
Reported-by: Jason A. Donenfeld &lt;Jason@zx2c4.com&gt;
Reviewed-by: Jason A. Donenfeld &lt;Jason@zx2c4.com&gt;
Tested-by: Jason A. Donenfeld &lt;Jason@zx2c4.com&gt;
Cc: Arnd Bergmann &lt;arnd@arndb.de&gt;
Cc: Christian Brauner &lt;christian.brauner@canonical.com&gt;
Cc: Vincenzo Frascino &lt;vincenzo.frascino@arm.com&gt;
Cc: &lt;stable@vger.kernel.org&gt; # v4.4+
Cc: linux-mips@vger.kernel.org
Cc: linux-kernel@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 bbcc5672b0063b0e9d65dc8787a4f09c3b5bb5cc upstream.

Declaring __current_thread_info as a global register variable has the
effect of preventing GCC from saving &amp; restoring its value in cases
where the ABI would typically do so.

To quote GCC documentation:

&gt; If the register is a call-saved register, call ABI is affected: the
&gt; register will not be restored in function epilogue sequences after the
&gt; variable has been assigned. Therefore, functions cannot safely return
&gt; to callers that assume standard ABI.

When our position independent VDSO is built for the n32 or n64 ABIs all
functions it exposes should be preserving the value of $gp/$28 for their
caller, but in the presence of the __current_thread_info global register
variable GCC stops doing so &amp; simply clobbers $gp/$28 when calculating
the address of the GOT.

In cases where the VDSO returns success this problem will typically be
masked by the caller in libc returning &amp; restoring $gp/$28 itself, but
that is by no means guaranteed. In cases where the VDSO returns an error
libc will typically contain a fallback path which will now fail
(typically with a bad memory access) if it attempts anything which
relies upon the value of $gp/$28 - eg. accessing anything via the GOT.

One fix for this would be to move the declaration of
__current_thread_info inside the current_thread_info() function,
demoting it from global register variable to local register variable &amp;
avoiding inadvertently creating a non-standard calling ABI for the VDSO.
Unfortunately this causes issues for clang, which doesn't support local
register variables as pointed out by commit fe92da0f355e ("MIPS: Changed
current_thread_info() to an equivalent supported by both clang and GCC")
which introduced the global register variable before we had a VDSO to
worry about.

Instead, fix this by continuing to use the global register variable for
the kernel proper but declare __current_thread_info as a simple extern
variable when building the VDSO. It should never be referenced, and will
cause a link error if it is. This resolves the calling convention issue
for the VDSO without having any impact upon the build of the kernel
itself for either clang or gcc.

Signed-off-by: Paul Burton &lt;paulburton@kernel.org&gt;
Fixes: ebb5e78cc634 ("MIPS: Initial implementation of a VDSO")
Reported-by: Jason A. Donenfeld &lt;Jason@zx2c4.com&gt;
Reviewed-by: Jason A. Donenfeld &lt;Jason@zx2c4.com&gt;
Tested-by: Jason A. Donenfeld &lt;Jason@zx2c4.com&gt;
Cc: Arnd Bergmann &lt;arnd@arndb.de&gt;
Cc: Christian Brauner &lt;christian.brauner@canonical.com&gt;
Cc: Vincenzo Frascino &lt;vincenzo.frascino@arm.com&gt;
Cc: &lt;stable@vger.kernel.org&gt; # v4.4+
Cc: linux-mips@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>Revert "MIPS: futex: Emit Loongson3 sync workarounds within asm"</title>
<updated>2020-01-04T18:16:21+00:00</updated>
<author>
<name>Greg Kroah-Hartman</name>
<email>gregkh@linuxfoundation.org</email>
</author>
<published>2019-12-31T17:08:46+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=ffe485232df06b3cbb933d02aeb8965fd1ddca61'/>
<id>ffe485232df06b3cbb933d02aeb8965fd1ddca61</id>
<content type='text'>
This reverts commit d754a529a8be55f009c6679d772c472c1632cd5b which was
commit 3c1d3f0979721a39dd2980c97466127ce65aa130 upstream.

This breaks the build and should be reverted.

Cc: Guenter Roeck &lt;linux@roeck-us.net&gt;
Cc: Paul Burton &lt;paul.burton@mips.com&gt;
Cc: linux-mips@vger.kernel.org
Cc: Huacai Chen &lt;chenhc@lemote.com&gt;
Cc: Jiaxun Yang &lt;jiaxun.yang@flygoat.com&gt;
Cc: linux-kernel@vger.kernel.org
Cc: Sasha Levin &lt;sashal@kernel.org&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>
This reverts commit d754a529a8be55f009c6679d772c472c1632cd5b which was
commit 3c1d3f0979721a39dd2980c97466127ce65aa130 upstream.

This breaks the build and should be reverted.

Cc: Guenter Roeck &lt;linux@roeck-us.net&gt;
Cc: Paul Burton &lt;paul.burton@mips.com&gt;
Cc: linux-mips@vger.kernel.org
Cc: Huacai Chen &lt;chenhc@lemote.com&gt;
Cc: Jiaxun Yang &lt;jiaxun.yang@flygoat.com&gt;
Cc: linux-kernel@vger.kernel.org
Cc: Sasha Levin &lt;sashal@kernel.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>Revert "MIPS: futex: Restore \n after sync instructions"</title>
<updated>2020-01-04T18:16:20+00:00</updated>
<author>
<name>Greg Kroah-Hartman</name>
<email>gregkh@linuxfoundation.org</email>
</author>
<published>2019-12-31T17:04:17+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=03ad5d55bea1fb58735eff1a9a0aaa34c230f357'/>
<id>03ad5d55bea1fb58735eff1a9a0aaa34c230f357</id>
<content type='text'>
This reverts commit dc9d0a75ce9af74612d6a4d052e4df2bddfe8ed4 which is
commit fd7710cb491f900eb63d2ce5aac0e682003e84e9 upstream.

This, and the follow-on patch, breaks the mips build so it needs to be
reverted.

Reported-by: Guenter Roeck &lt;linux@roeck-us.net&gt;
Cc: Paul Burton &lt;paul.burton@mips.com&gt;
Cc: Sasha Levin &lt;sashal@kernel.org&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>
This reverts commit dc9d0a75ce9af74612d6a4d052e4df2bddfe8ed4 which is
commit fd7710cb491f900eb63d2ce5aac0e682003e84e9 upstream.

This, and the follow-on patch, breaks the mips build so it needs to be
reverted.

Reported-by: Guenter Roeck &lt;linux@roeck-us.net&gt;
Cc: Paul Burton &lt;paul.burton@mips.com&gt;
Cc: Sasha Levin &lt;sashal@kernel.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>MIPS: futex: Restore \n after sync instructions</title>
<updated>2019-12-31T15:45:49+00:00</updated>
<author>
<name>Paul Burton</name>
<email>paul.burton@mips.com</email>
</author>
<published>2019-10-07T19:58:44+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=dc9d0a75ce9af74612d6a4d052e4df2bddfe8ed4'/>
<id>dc9d0a75ce9af74612d6a4d052e4df2bddfe8ed4</id>
<content type='text'>
[ Upstream commit fd7710cb491f900eb63d2ce5aac0e682003e84e9 ]

Commit 3c1d3f097972 ("MIPS: futex: Emit Loongson3 sync workarounds
within asm") inadvertently removed the newlines following
__WEAK_LLSC_MB, which causes build failures for configurations in which
__WEAK_LLSC_MB expands to a sync instruction:

  {standard input}: Assembler messages:
  {standard input}:9346: Error: symbol `sync3' is already defined
  {standard input}:9380: Error: symbol `sync3' is already defined
  ...

Fix this by restoring the newlines to separate the sync instruction from
anything following it (such as the 3: label), preventing inadvertent
concatenation.

Signed-off-by: Paul Burton &lt;paul.burton@mips.com&gt;
Fixes: 3c1d3f097972 ("MIPS: futex: Emit Loongson3 sync workarounds within asm")
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
[ Upstream commit fd7710cb491f900eb63d2ce5aac0e682003e84e9 ]

Commit 3c1d3f097972 ("MIPS: futex: Emit Loongson3 sync workarounds
within asm") inadvertently removed the newlines following
__WEAK_LLSC_MB, which causes build failures for configurations in which
__WEAK_LLSC_MB expands to a sync instruction:

  {standard input}: Assembler messages:
  {standard input}:9346: Error: symbol `sync3' is already defined
  {standard input}:9380: Error: symbol `sync3' is already defined
  ...

Fix this by restoring the newlines to separate the sync instruction from
anything following it (such as the 3: label), preventing inadvertent
concatenation.

Signed-off-by: Paul Burton &lt;paul.burton@mips.com&gt;
Fixes: 3c1d3f097972 ("MIPS: futex: Emit Loongson3 sync workarounds within asm")
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>mips: fix build when "48 bits virtual memory" is enabled</title>
<updated>2019-12-31T15:45:45+00:00</updated>
<author>
<name>Mike Rapoport</name>
<email>rppt@linux.ibm.com</email>
</author>
<published>2019-11-21T16:21:31+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=6d98463304f4a23ee6e63e3a7a07f88762f6eaf6'/>
<id>6d98463304f4a23ee6e63e3a7a07f88762f6eaf6</id>
<content type='text'>
[ Upstream commit 3ed6751bb8fa89c3014399bb0414348499ee202a ]

With CONFIG_MIPS_VA_BITS_48=y the build fails miserably:

  CC      arch/mips/kernel/asm-offsets.s
In file included from arch/mips/include/asm/pgtable.h:644,
                 from include/linux/mm.h:99,
                 from arch/mips/kernel/asm-offsets.c:15:
include/asm-generic/pgtable.h:16:2: error: #error CONFIG_PGTABLE_LEVELS is not consistent with __PAGETABLE_{P4D,PUD,PMD}_FOLDED
 #error CONFIG_PGTABLE_LEVELS is not consistent with __PAGETABLE_{P4D,PUD,PMD}_FOLDED
  ^~~~~
include/asm-generic/pgtable.h:390:28: error: unknown type name 'p4d_t'; did you mean 'pmd_t'?
 static inline int p4d_same(p4d_t p4d_a, p4d_t p4d_b)
                            ^~~~~
                            pmd_t

[ ... more such errors ... ]

scripts/Makefile.build:99: recipe for target 'arch/mips/kernel/asm-offsets.s' failed
make[2]: *** [arch/mips/kernel/asm-offsets.s] Error 1

This happens because when CONFIG_MIPS_VA_BITS_48 enables 4th level of the
page tables, but neither pgtable-nop4d.h nor 5level-fixup.h are included to
cope with the 5th level.

Replace #ifdef conditions around includes of the pgtable-nop{m,u}d.h with
explicit CONFIG_PGTABLE_LEVELS and add include of 5level-fixup.h for the
case when CONFIG_PGTABLE_LEVELS==4

Signed-off-by: Mike Rapoport &lt;rppt@linux.ibm.com&gt;
Signed-off-by: Paul Burton &lt;paulburton@kernel.org&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: linux-kernel@vger.kernel.org
Cc: linux-mm@kvack.org
Cc: Mike Rapoport &lt;rppt@kernel.org&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
[ Upstream commit 3ed6751bb8fa89c3014399bb0414348499ee202a ]

With CONFIG_MIPS_VA_BITS_48=y the build fails miserably:

  CC      arch/mips/kernel/asm-offsets.s
In file included from arch/mips/include/asm/pgtable.h:644,
                 from include/linux/mm.h:99,
                 from arch/mips/kernel/asm-offsets.c:15:
include/asm-generic/pgtable.h:16:2: error: #error CONFIG_PGTABLE_LEVELS is not consistent with __PAGETABLE_{P4D,PUD,PMD}_FOLDED
 #error CONFIG_PGTABLE_LEVELS is not consistent with __PAGETABLE_{P4D,PUD,PMD}_FOLDED
  ^~~~~
include/asm-generic/pgtable.h:390:28: error: unknown type name 'p4d_t'; did you mean 'pmd_t'?
 static inline int p4d_same(p4d_t p4d_a, p4d_t p4d_b)
                            ^~~~~
                            pmd_t

[ ... more such errors ... ]

scripts/Makefile.build:99: recipe for target 'arch/mips/kernel/asm-offsets.s' failed
make[2]: *** [arch/mips/kernel/asm-offsets.s] Error 1

This happens because when CONFIG_MIPS_VA_BITS_48 enables 4th level of the
page tables, but neither pgtable-nop4d.h nor 5level-fixup.h are included to
cope with the 5th level.

Replace #ifdef conditions around includes of the pgtable-nop{m,u}d.h with
explicit CONFIG_PGTABLE_LEVELS and add include of 5level-fixup.h for the
case when CONFIG_PGTABLE_LEVELS==4

Signed-off-by: Mike Rapoport &lt;rppt@linux.ibm.com&gt;
Signed-off-by: Paul Burton &lt;paulburton@kernel.org&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: linux-kernel@vger.kernel.org
Cc: linux-mm@kvack.org
Cc: Mike Rapoport &lt;rppt@kernel.org&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>MIPS: futex: Emit Loongson3 sync workarounds within asm</title>
<updated>2019-12-31T15:43:48+00:00</updated>
<author>
<name>Paul Burton</name>
<email>paul.burton@mips.com</email>
</author>
<published>2019-10-01T21:53:38+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=d754a529a8be55f009c6679d772c472c1632cd5b'/>
<id>d754a529a8be55f009c6679d772c472c1632cd5b</id>
<content type='text'>
[ Upstream commit 3c1d3f0979721a39dd2980c97466127ce65aa130 ]

Generate the sync instructions required to workaround Loongson3 LL/SC
errata within inline asm blocks, which feels a little safer than doing
it from C where strictly speaking the compiler would be well within its
rights to insert a memory access between the separate asm statements we
previously had, containing sync &amp; ll instructions respectively.

Signed-off-by: Paul Burton &lt;paul.burton@mips.com&gt;
Cc: linux-mips@vger.kernel.org
Cc: Huacai Chen &lt;chenhc@lemote.com&gt;
Cc: Jiaxun Yang &lt;jiaxun.yang@flygoat.com&gt;
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
[ Upstream commit 3c1d3f0979721a39dd2980c97466127ce65aa130 ]

Generate the sync instructions required to workaround Loongson3 LL/SC
errata within inline asm blocks, which feels a little safer than doing
it from C where strictly speaking the compiler would be well within its
rights to insert a memory access between the separate asm statements we
previously had, containing sync &amp; ll instructions respectively.

Signed-off-by: Paul Burton &lt;paul.burton@mips.com&gt;
Cc: linux-mips@vger.kernel.org
Cc: Huacai Chen &lt;chenhc@lemote.com&gt;
Cc: Jiaxun Yang &lt;jiaxun.yang@flygoat.com&gt;
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>timekeeping/vsyscall: Update VDSO data unconditionally</title>
<updated>2019-11-04T22:02:53+00:00</updated>
<author>
<name>Huacai Chen</name>
<email>chenhc@lemote.com</email>
</author>
<published>2019-10-24T03:28:29+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=52338415cf4d4064ae6b8dd972dadbda841da4fa'/>
<id>52338415cf4d4064ae6b8dd972dadbda841da4fa</id>
<content type='text'>
The update of the VDSO data is depending on __arch_use_vsyscall() returning
True. This is a leftover from the attempt to map the features of various
architectures 1:1 into generic code.

The usage of __arch_use_vsyscall() in the actual vsyscall implementations
got dropped and replaced by the requirement for the architecture code to
return U64_MAX if the global clocksource is not usable in the VDSO.

But the __arch_use_vsyscall() check in the update code stayed which causes
the VDSO data to be stale or invalid when an architecture actually
implements that function and returns False when the current clocksource is
not usable in the VDSO.

As a consequence the VDSO implementations of clock_getres(), time(),
clock_gettime(CLOCK_.*_COARSE) operate on invalid data and return bogus
information.

Remove the __arch_use_vsyscall() check from the VDSO update function and
update the VDSO data unconditionally.

[ tglx: Massaged changelog and removed the now useless implementations in
  	asm-generic/ARM64/MIPS ]

Fixes: 44f57d788e7deecb50 ("timekeeping: Provide a generic update_vsyscall() implementation")
Signed-off-by: Huacai Chen &lt;chenhc@lemote.com&gt;
Signed-off-by: Thomas Gleixner &lt;tglx@linutronix.de&gt;
Cc: Andy Lutomirski &lt;luto@kernel.org&gt;
Cc: Vincenzo Frascino &lt;vincenzo.frascino@arm.com&gt;
Cc: Arnd Bergmann &lt;arnd@arndb.de&gt;
Cc: Paul Burton &lt;paul.burton@mips.com&gt;
Cc: linux-mips@vger.kernel.org
Cc: linux-arm-kernel@lists.infradead.org
Cc: stable@vger.kernel.org
Link: https://lkml.kernel.org/r/1571887709-11447-1-git-send-email-chenhc@lemote.com
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
The update of the VDSO data is depending on __arch_use_vsyscall() returning
True. This is a leftover from the attempt to map the features of various
architectures 1:1 into generic code.

The usage of __arch_use_vsyscall() in the actual vsyscall implementations
got dropped and replaced by the requirement for the architecture code to
return U64_MAX if the global clocksource is not usable in the VDSO.

But the __arch_use_vsyscall() check in the update code stayed which causes
the VDSO data to be stale or invalid when an architecture actually
implements that function and returns False when the current clocksource is
not usable in the VDSO.

As a consequence the VDSO implementations of clock_getres(), time(),
clock_gettime(CLOCK_.*_COARSE) operate on invalid data and return bogus
information.

Remove the __arch_use_vsyscall() check from the VDSO update function and
update the VDSO data unconditionally.

[ tglx: Massaged changelog and removed the now useless implementations in
  	asm-generic/ARM64/MIPS ]

Fixes: 44f57d788e7deecb50 ("timekeeping: Provide a generic update_vsyscall() implementation")
Signed-off-by: Huacai Chen &lt;chenhc@lemote.com&gt;
Signed-off-by: Thomas Gleixner &lt;tglx@linutronix.de&gt;
Cc: Andy Lutomirski &lt;luto@kernel.org&gt;
Cc: Vincenzo Frascino &lt;vincenzo.frascino@arm.com&gt;
Cc: Arnd Bergmann &lt;arnd@arndb.de&gt;
Cc: Paul Burton &lt;paul.burton@mips.com&gt;
Cc: linux-mips@vger.kernel.org
Cc: linux-arm-kernel@lists.infradead.org
Cc: stable@vger.kernel.org
Link: https://lkml.kernel.org/r/1571887709-11447-1-git-send-email-chenhc@lemote.com
</pre>
</div>
</content>
</entry>
<entry>
<title>MIPS: bmips: mark exception vectors as char arrays</title>
<updated>2019-10-24T04:07:28+00:00</updated>
<author>
<name>Jonas Gorski</name>
<email>jonas.gorski@gmail.com</email>
</author>
<published>2019-10-22T19:11:00+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=e4f5cb1a9b27c0f94ef4f5a0178a3fde2d3d0e9e'/>
<id>e4f5cb1a9b27c0f94ef4f5a0178a3fde2d3d0e9e</id>
<content type='text'>
The vectors span more than one byte, so mark them as arrays.

Fixes the following build error when building when using GCC 8.3:

In file included from ./include/linux/string.h:19,
                 from ./include/linux/bitmap.h:9,
                 from ./include/linux/cpumask.h:12,
                 from ./arch/mips/include/asm/processor.h:15,
                 from ./arch/mips/include/asm/thread_info.h:16,
                 from ./include/linux/thread_info.h:38,
                 from ./include/asm-generic/preempt.h:5,
                 from ./arch/mips/include/generated/asm/preempt.h:1,
                 from ./include/linux/preempt.h:81,
                 from ./include/linux/spinlock.h:51,
                 from ./include/linux/mmzone.h:8,
                 from ./include/linux/bootmem.h:8,
                 from arch/mips/bcm63xx/prom.c:10:
arch/mips/bcm63xx/prom.c: In function 'prom_init':
./arch/mips/include/asm/string.h:162:11: error: '__builtin_memcpy' forming offset [2, 32] is out of the bounds [0, 1] of object 'bmips_smp_movevec' with type 'char' [-Werror=array-bounds]
   __ret = __builtin_memcpy((dst), (src), __len); \
           ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
arch/mips/bcm63xx/prom.c:97:3: note: in expansion of macro 'memcpy'
   memcpy((void *)0xa0000200, &amp;bmips_smp_movevec, 0x20);
   ^~~~~~
In file included from arch/mips/bcm63xx/prom.c:14:
./arch/mips/include/asm/bmips.h:80:13: note: 'bmips_smp_movevec' declared here
 extern char bmips_smp_movevec;

Fixes: 18a1eef92dcd ("MIPS: BMIPS: Introduce bmips.h")
Signed-off-by: Jonas Gorski &lt;jonas.gorski@gmail.com&gt;
Reviewed-by: Florian Fainelli &lt;f.fainelli@gmail.com&gt;
Signed-off-by: Paul Burton &lt;paulburton@kernel.org&gt;
Cc: linux-mips@vger.kernel.org
Cc: Ralf Baechle &lt;ralf@linux-mips.org&gt;
Cc: James Hogan &lt;jhogan@kernel.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
The vectors span more than one byte, so mark them as arrays.

Fixes the following build error when building when using GCC 8.3:

In file included from ./include/linux/string.h:19,
                 from ./include/linux/bitmap.h:9,
                 from ./include/linux/cpumask.h:12,
                 from ./arch/mips/include/asm/processor.h:15,
                 from ./arch/mips/include/asm/thread_info.h:16,
                 from ./include/linux/thread_info.h:38,
                 from ./include/asm-generic/preempt.h:5,
                 from ./arch/mips/include/generated/asm/preempt.h:1,
                 from ./include/linux/preempt.h:81,
                 from ./include/linux/spinlock.h:51,
                 from ./include/linux/mmzone.h:8,
                 from ./include/linux/bootmem.h:8,
                 from arch/mips/bcm63xx/prom.c:10:
arch/mips/bcm63xx/prom.c: In function 'prom_init':
./arch/mips/include/asm/string.h:162:11: error: '__builtin_memcpy' forming offset [2, 32] is out of the bounds [0, 1] of object 'bmips_smp_movevec' with type 'char' [-Werror=array-bounds]
   __ret = __builtin_memcpy((dst), (src), __len); \
           ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
arch/mips/bcm63xx/prom.c:97:3: note: in expansion of macro 'memcpy'
   memcpy((void *)0xa0000200, &amp;bmips_smp_movevec, 0x20);
   ^~~~~~
In file included from arch/mips/bcm63xx/prom.c:14:
./arch/mips/include/asm/bmips.h:80:13: note: 'bmips_smp_movevec' declared here
 extern char bmips_smp_movevec;

Fixes: 18a1eef92dcd ("MIPS: BMIPS: Introduce bmips.h")
Signed-off-by: Jonas Gorski &lt;jonas.gorski@gmail.com&gt;
Reviewed-by: Florian Fainelli &lt;f.fainelli@gmail.com&gt;
Signed-off-by: Paul Burton &lt;paulburton@kernel.org&gt;
Cc: linux-mips@vger.kernel.org
Cc: Ralf Baechle &lt;ralf@linux-mips.org&gt;
Cc: James Hogan &lt;jhogan@kernel.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>mips: vdso: Fix __arch_get_hw_counter()</title>
<updated>2019-10-18T21:29:16+00:00</updated>
<author>
<name>Vincenzo Frascino</name>
<email>vincenzo.frascino@arm.com</email>
</author>
<published>2019-10-16T13:40:24+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=8a1bef4193e81c8afae4d2f107f1c09c8ce89470'/>
<id>8a1bef4193e81c8afae4d2f107f1c09c8ce89470</id>
<content type='text'>
On some MIPS variants (e.g. MIPS r1), vDSO clock_mode is set to
VDSO_CLOCK_NONE.

When VDSO_CLOCK_NONE is set the expected kernel behavior is to fallback
on syscalls. To do that the generic vDSO library expects UULONG_MAX as
return value of __arch_get_hw_counter().

Fix __arch_get_hw_counter() on MIPS defining a __VDSO_USE_SYSCALL case
that addressed the described scenario.

Reported-by: Maxime Bizon &lt;mbizon@freebox.fr&gt;
Signed-off-by: Vincenzo Frascino &lt;vincenzo.frascino@arm.com&gt;
Tested-by: Maxime Bizon &lt;mbizon@freebox.fr&gt;
Signed-off-by: Paul Burton &lt;paulburton@kernel.org&gt;
Cc: linux-mips@vger.kernel.org
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
On some MIPS variants (e.g. MIPS r1), vDSO clock_mode is set to
VDSO_CLOCK_NONE.

When VDSO_CLOCK_NONE is set the expected kernel behavior is to fallback
on syscalls. To do that the generic vDSO library expects UULONG_MAX as
return value of __arch_get_hw_counter().

Fix __arch_get_hw_counter() on MIPS defining a __VDSO_USE_SYSCALL case
that addressed the described scenario.

Reported-by: Maxime Bizon &lt;mbizon@freebox.fr&gt;
Signed-off-by: Vincenzo Frascino &lt;vincenzo.frascino@arm.com&gt;
Tested-by: Maxime Bizon &lt;mbizon@freebox.fr&gt;
Signed-off-by: Paul Burton &lt;paulburton@kernel.org&gt;
Cc: linux-mips@vger.kernel.org
</pre>
</div>
</content>
</entry>
</feed>
