RANDOMIZE_BASE currently selects RELOCATABLE even though RELOCATABLE
is visible to users. Some other architectures, like x86, use 'depends on'
for RELOCATABLE in their definition of RANDOMIZE_BASE, so let's do the same
here.

This select-visible Kconfig misusage was detected by Kconfirm, a static
analysis tool for Kconfig.

Signed-off-by: Julian Braha <julianbraha@gmail.com>
---
 arch/riscv/Kconfig | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/riscv/Kconfig b/arch/riscv/Kconfig
index d32309846fa3..da26559a0893 100644
--- a/arch/riscv/Kconfig
+++ b/arch/riscv/Kconfig
@@ -1143,7 +1143,7 @@ config RELOCATABLE
 
 config RANDOMIZE_BASE
         bool "Randomize the address of the kernel image"
-        select RELOCATABLE
+        depends on RELOCATABLE
         depends on MMU && 64BIT
         help
           Randomizes the virtual address at which the kernel image is
-- 
2.53.0

On Sun, 3 May 2026, Julian Braha wrote:

> RANDOMIZE_BASE currently selects RELOCATABLE even though RELOCATABLE
> is visible to users. Some other architectures, like x86, use 'depends on'
> for RELOCATABLE in their definition of RANDOMIZE_BASE, so let's do the same
> here.
> 
> This select-visible Kconfig misusage was detected by Kconfirm, a static
> analysis tool for Kconfig.
> 
> Signed-off-by: Julian Braha <julianbraha@gmail.com>

Thanks, queued for v7.2.


- Paul

Hi Paul,

On Sat, 23 May 2026 at 01:48, Paul Walmsley <pjw@kernel.org> wrote:
> On Sun, 3 May 2026, Julian Braha wrote:
> > RANDOMIZE_BASE currently selects RELOCATABLE even though RELOCATABLE
> > is visible to users. Some other architectures, like x86, use 'depends on'
> > for RELOCATABLE in their definition of RANDOMIZE_BASE, so let's do the same
> > here.
> >
> > This select-visible Kconfig misusage was detected by Kconfirm, a static
> > analysis tool for Kconfig.
> >
> > Signed-off-by: Julian Braha <julianbraha@gmail.com>
>
> Thanks, queued for v7.2.

This was applied twice to riscv/for-next, in commits 7bce18b7c0835686
and a74483879d1d4769 ("riscv: replace select with dependency for
visible RELOCATABLE").  Apparently, the second commit is empty.

I noticed because it broke my workflow: I use "git cherry -v
linux-next/master master" to check which of my patches were accepted
in linux-next.  Thanks to your empty commit, all my empty separator
commits are now flagged as present in linux-next...

Thanks for fixing! ;-)

Gr{oetje,eeting}s,

                        Geert


--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds