linux-stable.git/arch/xtensa, branch linux-5.17.y

xtensa/simdisk: fix proc_read_simdisk()

2022-06-09T08:26:28+00:00

commit b011946d039d66bbc7102137e98cc67e1356aa87 upstream.

The commit a69755b18774 ("xtensa simdisk: switch to proc_create_data()")
split read operation into two parts, first retrieving the path when it's
non-null and second retrieving the trailing '\n'. However when the path
is non-null the first simple_read_from_buffer updates ppos, and the
second simple_read_from_buffer returns 0 if ppos is greater than 1 (i.e.
almost always). As a result reading from that proc file is almost always
empty.

Fix it by making a temporary copy of the path with the trailing '\n' and
using simple_read_from_buffer on that copy.

Cc: stable@vger.kernel.org
Fixes: a69755b18774 ("xtensa simdisk: switch to proc_create_data()")
Signed-off-by: Yi Yang 
Signed-off-by: Max Filippov 
Signed-off-by: Greg Kroah-Hartman

xtensa: move trace_hardirqs_off call back to entry.S

2022-06-09T08:25:23+00:00

[ Upstream commit de4415d0bac91192ee9c74e849bc61429efa9b42 ]

Context tracking call must be done after hardirq tracking call,
otherwise lockdep_assert_irqs_disabled called from rcu_eqs_exit gives
a warning. To avoid context tracking logic duplication for IRQ/exception
entry paths move trace_hardirqs_off call back to common entry code.

Signed-off-by: Max Filippov 
Signed-off-by: Sasha Levin

ptrace/xtensa: Replace PT_SINGLESTEP with TIF_SINGLESTEP

2022-06-09T08:25:16+00:00

commit 4a3d2717d140401df7501a95e454180831a0c5af upstream.

xtensa is the last user of the PT_SINGLESTEP flag.  Changing tsk->ptrace in
user_enable_single_step and user_disable_single_step without locking could
potentiallly cause problems.

So use a thread info flag instead of a flag in tsk->ptrace.  Use TIF_SINGLESTEP
that xtensa already had defined but unused.

Remove the definitions of PT_SINGLESTEP and PT_BLOCKSTEP as they have no more users.

Cc: stable@vger.kernel.org
Acked-by: Max Filippov 
Tested-by: Kees Cook 
Reviewed-by: Oleg Nesterov 
Link: https://lkml.kernel.org/r/20220505182645.497868-4-ebiederm@xmission.com
Signed-off-by: "Eric W. Biederman" 
Signed-off-by: Greg Kroah-Hartman

xtensa: use fallback for random_get_entropy() instead of zero

2022-05-30T07:27:15+00:00

commit e10e2f58030c5c211d49042a8c2a1b93d40b2ffb upstream.

In the event that random_get_entropy() can't access a cycle counter or
similar, falling back to returning 0 is really not the best we can do.
Instead, at least calling random_get_entropy_fallback() would be
preferable, because that always needs to return _something_, even
falling back to jiffies eventually. It's not as though
random_get_entropy_fallback() is super high precision or guaranteed to
be entropic, but basically anything that's not zero all the time is
better than returning zero all the time.

This is accomplished by just including the asm-generic code like on
other architectures, which means we can get rid of the empty stub
function here.

Cc: Thomas Gleixner 
Cc: Arnd Bergmann 
Acked-by: Max Filippov 
Signed-off-by: Jason A. Donenfeld 
Signed-off-by: Greg Kroah-Hartman

arch: xtensa: platforms: Fix deadlock in rs_close()

2022-05-09T07:16:27+00:00

[ Upstream commit eb5adc70754d26a260f8b42d39db42da0d0af500 ]

There is a deadlock in rs_close(), which is shown
below:

   (Thread 1)              |      (Thread 2)
                           | rs_open()
rs_close()                 |  mod_timer()
 spin_lock_bh() //(1)      |  (wait a time)
 ...                       | rs_poll()
 del_timer_sync()          |  spin_lock() //(2)
 (wait timer to stop)      |  ...

We hold timer_lock in position (1) of thread 1 and
use del_timer_sync() to wait timer to stop, but timer handler
also need timer_lock in position (2) of thread 2.
As a result, rs_close() will block forever.

This patch deletes the redundant timer_lock in order to
prevent the deadlock. Because there is no race condition
between rs_close, rs_open and rs_poll.

Signed-off-by: Duoming Zhou 
Message-Id: <20220407154430.22387-1-duoming@zju.edu.cn>
Signed-off-by: Max Filippov 
Signed-off-by: Sasha Levin

xtensa: fix a7 clobbering in coprocessor context load/store

2022-04-27T12:41:14+00:00

commit 839769c35477d4acc2369e45000ca7b0b6af39a7 upstream.

Fast coprocessor exception handler saves a3..a6, but coprocessor context
load/store code uses a4..a7 as temporaries, potentially clobbering a7.
'Potentially' because coprocessor state load/store macros may not use
all four temporary registers (and neither FPU nor HiFi macros do).
Use a3..a6 as intended.

Cc: stable@vger.kernel.org
Fixes: c658eac628aa ("[XTENSA] Add support for configurable registers and coprocessors")
Signed-off-by: Max Filippov 
Signed-off-by: Greg Kroah-Hartman

xtensa: patch_text: Fixup last cpu should be master

2022-04-27T12:41:14+00:00

commit ee69d4be8fd064cd08270b4808d2dfece3614ee0 upstream.

These patch_text implementations are using stop_machine_cpuslocked
infrastructure with atomic cpu_count. The original idea: When the
master CPU patch_text, the others should wait for it. But current
implementation is using the first CPU as master, which couldn't
guarantee the remaining CPUs are waiting. This patch changes the
last CPU as the master to solve the potential risk.

Fixes: 64711f9a47d4 ("xtensa: implement jump_label support")
Signed-off-by: Guo Ren 
Signed-off-by: Guo Ren 
Reviewed-by: Max Filippov 
Reviewed-by: Masami Hiramatsu 
Cc: 
Message-Id: <20220407073323.743224-4-guoren@kernel.org>
Signed-off-by: Max Filippov 
Signed-off-by: Greg Kroah-Hartman

xtensa: fix DTC warning unit_address_format

2022-04-13T17:27:22+00:00

[ Upstream commit e85d29ba4b24f68e7a78cb85c55e754362eeb2de ]

DTC issues the following warnings when building xtfpga device trees:

 /soc/flash@00000000/partition@0x0: unit name should not have leading "0x"
 /soc/flash@00000000/partition@0x6000000: unit name should not have leading "0x"
 /soc/flash@00000000/partition@0x6800000: unit name should not have leading "0x"
 /soc/flash@00000000/partition@0x7fe0000: unit name should not have leading "0x"

Drop leading 0x from flash partition unit names.

Signed-off-by: Max Filippov 
Signed-off-by: Sasha Levin

xtensa: add missing XCHAL_HAVE_WINDOWED check

2022-04-08T11:58:17+00:00

[ Upstream commit 8c9ab55c0fbdc76cb876140c2dad75a610bb23ef ]

Add missing preprocessor conditions to secondary reset vector code.

Fixes: 09af39f649da ("xtensa: use register window specific opcodes only when present")
Signed-off-by: Max Filippov 
Signed-off-by: Sasha Levin

xtensa: fix xtensa_wsr always writing 0

2022-04-08T11:57:30+00:00

commit a3d0245c58f962ee99d4440ea0eaf45fb7f5a5cc upstream.

The commit cad6fade6e78 ("xtensa: clean up WSR*/RSR*/get_sr/set_sr")
replaced 'WSR' macro in the function xtensa_wsr with 'xtensa_set_sr',
but variable 'v' in the xtensa_set_sr body shadowed the argument 'v'
passed to it, resulting in wrong value written to debug registers.

Fix that by removing intermediate variable from the xtensa_set_sr
macro body.

Cc: stable@vger.kernel.org
Fixes: cad6fade6e78 ("xtensa: clean up WSR*/RSR*/get_sr/set_sr")
Signed-off-by: Max Filippov 
Signed-off-by: Greg Kroah-Hartman