<feed xmlns='http://www.w3.org/2005/Atom'>
<title>linux-dev/arch/riscv, branch master</title>
<subtitle>Linux kernel development work - see feature branches</subtitle>
<id>https://git.zx2c4.com/linux-dev/atom/arch/riscv?h=master</id>
<link rel='self' href='https://git.zx2c4.com/linux-dev/atom/arch/riscv?h=master'/>
<link rel='alternate' type='text/html' href='https://git.zx2c4.com/linux-dev/'/>
<updated>2022-11-11T17:40:19Z</updated>
<entry>
<title>Merge tag 'riscv-for-linus-6.1-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/riscv/linux</title>
<updated>2022-11-11T17:40:19Z</updated>
<author>
<name>Linus Torvalds</name>
<email>torvalds@linux-foundation.org</email>
</author>
<published>2022-11-11T17:40:19Z</published>
<link rel='alternate' type='text/html' href='https://git.zx2c4.com/linux-dev/commit/?id=991f173cd23cea2b4102cb78f779a7a43c29e76f'/>
<id>urn:sha1:991f173cd23cea2b4102cb78f779a7a43c29e76f</id>
<content type='text'>
Pull RISC-V fixes from Palmer Dabbelt:

 - A fix to add the missing PWM LEDs into the SiFive HiFive Unleashed
   device tree.

 - A fix to fully clear a task's registers on creation, as they end up
   in userspace and thus leak kernel memory.

 - A pair of VDSO-related build fixes that manifest on recent LLVM-based
   toolchains.

 - A fix to our early init to ensure the DT is adequately processed
   before reserved memory nodes are processed.

* tag 'riscv-for-linus-6.1-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/riscv/linux:
  RISC-V: vdso: Do not add missing symbols to version section in linker script
  riscv: fix reserved memory setup
  riscv: vdso: fix build with llvm
  riscv: process: fix kernel info leakage
  riscv: dts: sifive unleashed: Add PWM controlled LEDs
</content>
</entry>
<entry>
<title>RISC-V: vdso: Do not add missing symbols to version section in linker script</title>
<updated>2022-11-10T23:06:14Z</updated>
<author>
<name>Nathan Chancellor</name>
<email>nathan@kernel.org</email>
</author>
<published>2022-11-08T17:13:23Z</published>
<link rel='alternate' type='text/html' href='https://git.zx2c4.com/linux-dev/commit/?id=fcae44fd36d052e956e69a64642fc03820968d78'/>
<id>urn:sha1:fcae44fd36d052e956e69a64642fc03820968d78</id>
<content type='text'>
Recently, ld.lld moved from '--undefined-version' to
'--no-undefined-version' as the default, which breaks the compat vDSO
build:

  ld.lld: error: version script assignment of 'LINUX_4.15' to symbol '__vdso_gettimeofday' failed: symbol not defined
  ld.lld: error: version script assignment of 'LINUX_4.15' to symbol '__vdso_clock_gettime' failed: symbol not defined
  ld.lld: error: version script assignment of 'LINUX_4.15' to symbol '__vdso_clock_getres' failed: symbol not defined

These symbols are not present in the compat vDSO or the regular vDSO for
32-bit but they are unconditionally included in the version section of
the linker script, which is prohibited with '--no-undefined-version'.

Fix this issue by only including the symbols that are actually exported
in the version section of the linker script.

Link: https://github.com/ClangBuiltLinux/linux/issues/1756
Signed-off-by: Nathan Chancellor &lt;nathan@kernel.org&gt;
Tested-by: Conor Dooley &lt;conor.dooley@microchip.com&gt;
Link: https://lore.kernel.org/r/20221108171324.3377226-1-nathan@kernel.org/
Signed-off-by: Palmer Dabbelt &lt;palmer@rivosinc.com&gt;
</content>
</entry>
<entry>
<title>riscv: fix reserved memory setup</title>
<updated>2022-11-10T22:46:33Z</updated>
<author>
<name>Conor Dooley</name>
<email>conor.dooley@microchip.com</email>
</author>
<published>2022-11-07T15:15:25Z</published>
<link rel='alternate' type='text/html' href='https://git.zx2c4.com/linux-dev/commit/?id=50e63dd8ed92045eb70a72d7ec725488320fb68b'/>
<id>urn:sha1:50e63dd8ed92045eb70a72d7ec725488320fb68b</id>
<content type='text'>
Currently, RISC-V sets up reserved memory using the "early" copy of the
device tree. As a result, when trying to get a reserved memory region
using of_reserved_mem_lookup(), the pointer to reserved memory regions
is using the early, pre-virtual-memory address which causes a kernel
panic when trying to use the buffer's name:

 Unable to handle kernel paging request at virtual address 00000000401c31ac
 Oops [#1]
 Modules linked in:
 CPU: 0 PID: 0 Comm: swapper Not tainted 6.0.0-rc1-00001-g0d9d6953d834 #1
 Hardware name: Microchip PolarFire-SoC Icicle Kit (DT)
 epc : string+0x4a/0xea
  ra : vsnprintf+0x1e4/0x336
 epc : ffffffff80335ea0 ra : ffffffff80338936 sp : ffffffff81203be0
  gp : ffffffff812e0a98 tp : ffffffff8120de40 t0 : 0000000000000000
  t1 : ffffffff81203e28 t2 : 7265736572203a46 s0 : ffffffff81203c20
  s1 : ffffffff81203e28 a0 : ffffffff81203d22 a1 : 0000000000000000
  a2 : ffffffff81203d08 a3 : 0000000081203d21 a4 : ffffffffffffffff
  a5 : 00000000401c31ac a6 : ffff0a00ffffff04 a7 : ffffffffffffffff
  s2 : ffffffff81203d08 s3 : ffffffff81203d00 s4 : 0000000000000008
  s5 : ffffffff000000ff s6 : 0000000000ffffff s7 : 00000000ffffff00
  s8 : ffffffff80d9821a s9 : ffffffff81203d22 s10: 0000000000000002
  s11: ffffffff80d9821c t3 : ffffffff812f3617 t4 : ffffffff812f3617
  t5 : ffffffff812f3618 t6 : ffffffff81203d08
 status: 0000000200000100 badaddr: 00000000401c31ac cause: 000000000000000d
 [&lt;ffffffff80338936&gt;] vsnprintf+0x1e4/0x336
 [&lt;ffffffff80055ae2&gt;] vprintk_store+0xf6/0x344
 [&lt;ffffffff80055d86&gt;] vprintk_emit+0x56/0x192
 [&lt;ffffffff80055ed8&gt;] vprintk_default+0x16/0x1e
 [&lt;ffffffff800563d2&gt;] vprintk+0x72/0x80
 [&lt;ffffffff806813b2&gt;] _printk+0x36/0x50
 [&lt;ffffffff8068af48&gt;] print_reserved_mem+0x1c/0x24
 [&lt;ffffffff808057ec&gt;] paging_init+0x528/0x5bc
 [&lt;ffffffff808031ae&gt;] setup_arch+0xd0/0x592
 [&lt;ffffffff8080070e&gt;] start_kernel+0x82/0x73c

early_init_fdt_scan_reserved_mem() takes no arguments as it operates on
initial_boot_params, which is populated by early_init_dt_verify(). On
RISC-V, early_init_dt_verify() is called twice. Once, directly, in
setup_arch() if CONFIG_BUILTIN_DTB is not enabled and once indirectly,
very early in the boot process, by parse_dtb() when it calls
early_init_dt_scan_nodes().

This first call uses dtb_early_va to set initial_boot_params, which is
not usable later in the boot process when
early_init_fdt_scan_reserved_mem() is called. On arm64 for example, the
corresponding call to early_init_dt_scan_nodes() uses fixmap addresses
and doesn't suffer the same fate.

Move early_init_fdt_scan_reserved_mem() further along the boot sequence,
after the direct call to early_init_dt_verify() in setup_arch() so that
the names use the correct virtual memory addresses. The above supposed
that CONFIG_BUILTIN_DTB was not set, but should work equally in the case
where it is - unflatted_and_copy_device_tree() also updates
initial_boot_params.

Reported-by: Valentina Fernandez &lt;valentina.fernandezalanis@microchip.com&gt;
Reported-by: Evgenii Shatokhin &lt;e.shatokhin@yadro.com&gt;
Link: https://lore.kernel.org/linux-riscv/f8e67f82-103d-156c-deb0-d6d6e2756f5e@microchip.com/
Fixes: 922b0375fc93 ("riscv: Fix memblock reservation for device tree blob")
Signed-off-by: Conor Dooley &lt;conor.dooley@microchip.com&gt;
Tested-by: Evgenii Shatokhin &lt;e.shatokhin@yadro.com&gt;
Link: https://lore.kernel.org/r/20221107151524.3941467-1-conor.dooley@microchip.com
Signed-off-by: Palmer Dabbelt &lt;palmer@rivosinc.com&gt;
</content>
</entry>
<entry>
<title>riscv: vdso: fix build with llvm</title>
<updated>2022-11-10T21:58:36Z</updated>
<author>
<name>Jisheng Zhang</name>
<email>jszhang@kernel.org</email>
</author>
<published>2022-10-31T18:29:43Z</published>
<link rel='alternate' type='text/html' href='https://git.zx2c4.com/linux-dev/commit/?id=50f4dd657a0fcf90aa8da8dc2794a8100ff4c37c'/>
<id>urn:sha1:50f4dd657a0fcf90aa8da8dc2794a8100ff4c37c</id>
<content type='text'>
Even after commit 89fd4a1df829 ("riscv: jump_label: mark arguments as
const to satisfy asm constraints"), building with CC_OPTIMIZE_FOR_SIZE
+ LLVM=1 can reproduce below build error:

  CC      arch/riscv/kernel/vdso/vgettimeofday.o
In file included from &lt;built-in&gt;:4:
In file included from lib/vdso/gettimeofday.c:5:
In file included from include/vdso/datapage.h:17:
In file included from include/vdso/processor.h:10:
In file included from arch/riscv/include/asm/vdso/processor.h:7:
In file included from include/linux/jump_label.h:112:
arch/riscv/include/asm/jump_label.h:42:3: error:
invalid operand for inline asm constraint 'i'
                "       .option push                            \n\t"
                ^
1 error generated.

I think the problem is when "-Os" is passed as CFLAGS, it's removed by
"CFLAGS_REMOVE_vgettimeofday.o = $(CC_FLAGS_FTRACE) -Os" which is
introduced in commit e05d57dcb8c7 ("riscv: Fixup __vdso_gettimeofday
broke dynamic ftrace"), thus no optimization at all for vgettimeofday.c
arm64 does remove "-Os" as well, but it forces "-O2" after removing
"-Os".

I compared the generated vgettimeofday.o with "-O2" and "-Os",
I think no big performance difference. So let's tell the kbuild not
to remove "-Os" rather than follow arm64 style.

vdso related performance can be improved a lot when building kernel with
CC_OPTIMIZE_FOR_SIZE after this commit, ("-Os" VS no optimization)

Fixes: e05d57dcb8c7 ("riscv: Fixup __vdso_gettimeofday broke dynamic ftrace")
Signed-off-by: Jisheng Zhang &lt;jszhang@kernel.org&gt;
Tested-by: Conor Dooley &lt;conor.dooley@microchip.com&gt;
Link: https://lore.kernel.org/r/20221031182943.2453-1-jszhang@kernel.org
Signed-off-by: Palmer Dabbelt &lt;palmer@rivosinc.com&gt;
</content>
</entry>
<entry>
<title>riscv: process: fix kernel info leakage</title>
<updated>2022-11-10T21:43:15Z</updated>
<author>
<name>Jisheng Zhang</name>
<email>jszhang@kernel.org</email>
</author>
<published>2022-10-29T11:34:50Z</published>
<link rel='alternate' type='text/html' href='https://git.zx2c4.com/linux-dev/commit/?id=6510c78490c490a6636e48b61eeaa6fb65981f4b'/>
<id>urn:sha1:6510c78490c490a6636e48b61eeaa6fb65981f4b</id>
<content type='text'>
thread_struct's s[12] may contain random kernel memory content, which
may be finally leaked to userspace. This is a security hole. Fix it
by clearing the s[12] array in thread_struct when fork.

As for kthread case, it's better to clear the s[12] array as well.

Fixes: 7db91e57a0ac ("RISC-V: Task implementation")
Signed-off-by: Jisheng Zhang &lt;jszhang@kernel.org&gt;
Tested-by: Guo Ren &lt;guoren@kernel.org&gt;
Link: https://lore.kernel.org/r/20221029113450.4027-1-jszhang@kernel.org
Reviewed-by: Guo Ren &lt;guoren@kernel.org&gt;
Link: https://lore.kernel.org/r/CAJF2gTSdVyAaM12T%2B7kXAdRPGS4VyuO08X1c7paE-n4Fr8OtRA@mail.gmail.com/
Signed-off-by: Palmer Dabbelt &lt;palmer@rivosinc.com&gt;
</content>
</entry>
<entry>
<title>Merge tag 'riscv-for-linus-6.1-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/riscv/linux</title>
<updated>2022-10-29T00:03:00Z</updated>
<author>
<name>Linus Torvalds</name>
<email>torvalds@linux-foundation.org</email>
</author>
<published>2022-10-29T00:03:00Z</published>
<link rel='alternate' type='text/html' href='https://git.zx2c4.com/linux-dev/commit/?id=283f13d43bb4187bad3479f96ce7b4582ef4ed17'/>
<id>urn:sha1:283f13d43bb4187bad3479f96ce7b4582ef4ed17</id>
<content type='text'>
Pull RISC-V fixes from Palmer Dabbelt:

 - A fix for a build warning in the jump_label code

 - One of the git://github -&gt; https://github cleanups, for the SiFive
   drivers

 - A fix for the kasan initialization code, this still likely warrants
   some cleanups but that's a bigger problem and at least this fixes the
   crashes in the short term

 - A pair of fixes for extension support detection on mixed LLVM/GNU
   toolchains

 - A fix for a runtime warning in the /proc/cpuinfo code

* tag 'riscv-for-linus-6.1-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/riscv/linux:
  RISC-V: Fix /proc/cpuinfo cpumask warning
  riscv: fix detection of toolchain Zihintpause support
  riscv: fix detection of toolchain Zicbom support
  riscv: mm: add missing memcpy in kasan_init
  MAINTAINERS: git://github.com -&gt; https://github.com for sifive
  riscv: jump_label: mark arguments as const to satisfy asm constraints
</content>
</entry>
<entry>
<title>riscv: dts: sifive unleashed: Add PWM controlled LEDs</title>
<updated>2022-10-28T22:27:42Z</updated>
<author>
<name>Emil Renner Berthing</name>
<email>emil.renner.berthing@canonical.com</email>
</author>
<published>2022-10-12T11:09:28Z</published>
<link rel='alternate' type='text/html' href='https://git.zx2c4.com/linux-dev/commit/?id=8bc8824d30193eb7755043d5bb65fa7f0d11a595'/>
<id>urn:sha1:8bc8824d30193eb7755043d5bb65fa7f0d11a595</id>
<content type='text'>
This adds the 4 PWM controlled green LEDs to the HiFive Unleashed device
tree. The schematic doesn't specify any special function for the LEDs,
so they're added here without any default triggers and named d1, d2, d3
and d4 just like in the schematic.

Signed-off-by: Emil Renner Berthing &lt;emil.renner.berthing@canonical.com&gt;
Reviewed-by: Conor Dooley &lt;conor.dooley@microchip.com&gt;
Tested-by: Conor Dooley &lt;conor.dooley@microchip.com&gt;
Link: https://lore.kernel.org/r/20221012110928.352910-1-emil.renner.berthing@canonical.com
Signed-off-by: Palmer Dabbelt &lt;palmer@rivosinc.com&gt;
</content>
</entry>
<entry>
<title>RISC-V: Fix /proc/cpuinfo cpumask warning</title>
<updated>2022-10-27T22:23:19Z</updated>
<author>
<name>Andrew Jones</name>
<email>ajones@ventanamicro.com</email>
</author>
<published>2022-10-14T15:58:44Z</published>
<link rel='alternate' type='text/html' href='https://git.zx2c4.com/linux-dev/commit/?id=d14e99bf95510fa2d6affc371ad68161afc1dc8e'/>
<id>urn:sha1:d14e99bf95510fa2d6affc371ad68161afc1dc8e</id>
<content type='text'>
Commit 78e5a3399421 ("cpumask: fix checking valid cpu range") has
started issuing warnings[*] when cpu indices equal to nr_cpu_ids - 1
are passed to cpumask_next* functions. seq_read_iter() and cpuinfo's
start and next seq operations implement a pattern like

  n = cpumask_next(n - 1, mask);
  show(n);
  while (1) {
      ++n;
      n = cpumask_next(n - 1, mask);
      if (n &gt;= nr_cpu_ids)
          break;
      show(n);
  }

which will issue the warning when reading /proc/cpuinfo. Ensure no
warning is generated by validating the cpu index before calling
cpumask_next().

[*] Warnings will only appear with DEBUG_PER_CPU_MAPS enabled.

Signed-off-by: Andrew Jones &lt;ajones@ventanamicro.com&gt;
Reviewed-by: Anup Patel &lt;anup@brainfault.org&gt;
Reviewed-by: Conor Dooley &lt;conor.dooley@microchip.com&gt;
Tested-by: Conor Dooley &lt;conor.dooley@microchip.com&gt;
Acked-by: Yury Norov &lt;yury.norov@gmail.com&gt;
Link: https://lore.kernel.org/r/20221014155845.1986223-2-ajones@ventanamicro.com/
Fixes: 78e5a3399421 ("cpumask: fix checking valid cpu range")
Cc: stable@vger.kernel.org
Signed-off-by: Palmer Dabbelt &lt;palmer@rivosinc.com&gt;
</content>
</entry>
<entry>
<title>Merge patch series "Fix RISC-V toolchain extension support detection"</title>
<updated>2022-10-27T22:14:07Z</updated>
<author>
<name>Palmer Dabbelt</name>
<email>palmer@rivosinc.com</email>
</author>
<published>2022-10-27T22:09:50Z</published>
<link rel='alternate' type='text/html' href='https://git.zx2c4.com/linux-dev/commit/?id=952b64d6665c8b6fdd13ba63be7adc3be51641d7'/>
<id>urn:sha1:952b64d6665c8b6fdd13ba63be7adc3be51641d7</id>
<content type='text'>
Conor Dooley &lt;conor@kernel.org&gt; says:

From: Conor Dooley &lt;conor.dooley@microchip.com&gt;

This came up due to a report from Kevin @ kernel-ci, who had been
running a mixed configuration of GNU binutils and clang. Their compiler
was relatively recent &amp; supports Zicbom but binutils @ 2.35.2 did not.

Our current checks for extension support only cover the compiler, but it
appears to me that we need to check both the compiler &amp; linker support
in case of "pot-luck" configurations that mix different versions of
LD,AS,CC etc.

Linker support does not seem possible to actually check, since the ISA
string is emitted into the object files - so I put in version checks for
that. The checks have gotten a bit ugly since 32 &amp; 64 bit support need
to be checked independently but ahh well.

As I was going, I fell into the trap of there being duplicated checks
for CC support in both the Makefile and Kconfig, so as part of renaming
the Kconfig symbol to TOOLCHAIN_HAS_FOO, I dropped the extra checks in
the Makefile. This has the added advantage of the TOOLCHAIN_HAS_FOO
symbol for Zihintpause appearing in .config.

I pushed out a version of this that specificly checked for assember
support for LKP to test &amp; it looked /okay/ - but I did some more testing
today and realised that this is redudant &amp; have since dropped the as
check.

I tested locally with a fair few different combinations, to try and
cover each of AS, LD, CC missing support for the extension.

* b4-shazam-merge:
  riscv: fix detection of toolchain Zihintpause support
  riscv: fix detection of toolchain Zicbom support

Link: https://lore.kernel.org/r/20221006173520.1785507-1-conor@kernel.org
Signed-off-by: Palmer Dabbelt &lt;palmer@rivosinc.com&gt;
</content>
</entry>
<entry>
<title>riscv: fix detection of toolchain Zihintpause support</title>
<updated>2022-10-27T22:13:06Z</updated>
<author>
<name>Conor Dooley</name>
<email>conor.dooley@microchip.com</email>
</author>
<published>2022-10-06T17:35:21Z</published>
<link rel='alternate' type='text/html' href='https://git.zx2c4.com/linux-dev/commit/?id=aae538cd03bc8fc35979653d9180922d146da0ca'/>
<id>urn:sha1:aae538cd03bc8fc35979653d9180922d146da0ca</id>
<content type='text'>
It is not sufficient to check if a toolchain supports a particular
extension without checking if the linker supports that extension
too. For example, Clang 15 supports Zihintpause but GNU bintutils
2.35.2 does not, leading build errors like so:

riscv64-linux-gnu-ld: -march=rv64i2p0_m2p0_a2p0_c2p0_zihintpause2p0: Invalid or unknown z ISA extension: 'zihintpause'

Add a TOOLCHAIN_HAS_ZIHINTPAUSE which checks if each of the compiler,
assembler and linker support the extension. Replace the ifdef in the
vdso with one depending on this new symbol.

Fixes: 8eb060e10185 ("arch/riscv: add Zihintpause support")
Signed-off-by: Conor Dooley &lt;conor.dooley@microchip.com&gt;
Reviewed-by: Heiko Stuebner &lt;heiko@sntech.de&gt;
Reviewed-by: Nathan Chancellor &lt;nathan@kernel.org&gt;
Link: https://lore.kernel.org/r/20221006173520.1785507-3-conor@kernel.org
Signed-off-by: Palmer Dabbelt &lt;palmer@rivosinc.com&gt;
</content>
</entry>
</feed>
