linux-next.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* Re: [PATCH] random: fix a compilation error on arm64
       [not found] ` <4edcf552-ef82-cdd2-3fda-38d42ebfecc7@roeck-us.net>
@ 2020-08-06 22:43   ` Qian Cai
  2020-08-07  0:19     ` Guenter Roeck
  0 siblings, 1 reply; 2+ messages in thread
From: Qian Cai @ 2020-08-06 22:43 UTC (permalink / raw)
  To: Guenter Roeck
  Cc: torvalds, daniel.diaz, tytso, catalin.marinas, will,
	linux-arm-kernel, linux-kernel, sfr, linux-next

On Thu, Aug 06, 2020 at 07:50:23AM -0700, Guenter Roeck wrote:
> On 8/6/20 6:58 AM, Qian Cai wrote:
> > linux-next failed to compile using this .config,
> > https://gitlab.com/cailca/linux-mm/-/blob/master/arm64.config
> > 
> > arch/arm64/kernel/kaslr.c: In function 'kaslr_early_init':
> > arch/arm64/kernel/kaslr.c:128:6: error: implicit declaration of function
> > '__early_cpu_has_rndr'; did you mean '__early_pfn_to_nid'?
> > [-Werror=implicit-function-declaration]
> >   if (__early_cpu_has_rndr()) {
> >       ^~~~~~~~~~~~~~~~~~~~
> >       __early_pfn_to_nid
> > arch/arm64/kernel/kaslr.c:131:7: error: implicit declaration of function
> > '__arm64_rndr' [-Werror=implicit-function-declaration]
> >    if (__arm64_rndr(&raw))
> >        ^~~~~~~~~~~~
> > cc1: some warnings being treated as errors
> > 
> 
> This happens because ARCH_RANDOM is disabled. May be I am wrong, but I
> would argue that __arm64_rndr() should not be called directly in the
> first place. arch_get_random_seed_long_early() should be called instead.

I am not sure about if that would cure possible ARCH_RANDOM=n compiling
failures on all arches. Since my patch would not compile on mips etc, an
alternative is to revert the buggy commit 585524081ecd for now. Any thought?

> 
> Thanks,
> Guenter
> 
> > Fixes: 585524081ecd ("random: random.h should include archrandom.h, not the other way around")
> > Signed-off-by: Qian Cai <cai@lca.pw>
> > ---
> >  include/linux/random.h | 2 ++
> >  1 file changed, 2 insertions(+)
> > 
> > diff --git a/include/linux/random.h b/include/linux/random.h
> > index f45b8be3e3c4..da782c16c20c 100644
> > --- a/include/linux/random.h
> > +++ b/include/linux/random.h
> > @@ -12,6 +12,8 @@
> >  #include <linux/list.h>
> >  #include <linux/once.h>
> >  
> > +#include <asm/archrandom.h>
> > +
> >  #include <uapi/linux/random.h>
> >  
> >  struct random_ready_callback {
> > 
> 

^ permalink raw reply	[flat|nested] 2+ messages in thread

* Re: [PATCH] random: fix a compilation error on arm64
  2020-08-06 22:43   ` [PATCH] random: fix a compilation error on arm64 Qian Cai
@ 2020-08-07  0:19     ` Guenter Roeck
  0 siblings, 0 replies; 2+ messages in thread
From: Guenter Roeck @ 2020-08-07  0:19 UTC (permalink / raw)
  To: Qian Cai
  Cc: torvalds, daniel.diaz, tytso, catalin.marinas, will,
	linux-arm-kernel, linux-kernel, sfr, linux-next

On Thu, Aug 06, 2020 at 06:43:14PM -0400, Qian Cai wrote:
> On Thu, Aug 06, 2020 at 07:50:23AM -0700, Guenter Roeck wrote:
> > On 8/6/20 6:58 AM, Qian Cai wrote:
> > > linux-next failed to compile using this .config,
> > > https://gitlab.com/cailca/linux-mm/-/blob/master/arm64.config
> > > 
> > > arch/arm64/kernel/kaslr.c: In function 'kaslr_early_init':
> > > arch/arm64/kernel/kaslr.c:128:6: error: implicit declaration of function
> > > '__early_cpu_has_rndr'; did you mean '__early_pfn_to_nid'?
> > > [-Werror=implicit-function-declaration]
> > >   if (__early_cpu_has_rndr()) {
> > >       ^~~~~~~~~~~~~~~~~~~~
> > >       __early_pfn_to_nid
> > > arch/arm64/kernel/kaslr.c:131:7: error: implicit declaration of function
> > > '__arm64_rndr' [-Werror=implicit-function-declaration]
> > >    if (__arm64_rndr(&raw))
> > >        ^~~~~~~~~~~~
> > > cc1: some warnings being treated as errors
> > > 
> > 
> > This happens because ARCH_RANDOM is disabled. May be I am wrong, but I
> > would argue that __arm64_rndr() should not be called directly in the
> > first place. arch_get_random_seed_long_early() should be called instead.
> 
> I am not sure about if that would cure possible ARCH_RANDOM=n compiling
> failures on all arches. Since my patch would not compile on mips etc, an
> alternative is to revert the buggy commit 585524081ecd for now. Any thought?
> 
It is quite unlikely that any other architecture would attempt to compile
any arm64 code (which is the only code touched by commit 585524081ecd).
Also, commit 585524081ecd fixes a different problem caused by the
recursive inclusion of asm/archrandom.h. On top of that, I think using
arch_get_random_seed_long_early() would be much cleaner than the current
code since it doesn't override/bypass ARCH_RANDOM.

Let's do it this way: I'll submit an alternate patch using
arch_get_random_seed_long_early(). This way Linus can decide how to
proceed, and we don't have to go back and forth.

Thanks,
Guenter

> > 
> > Thanks,
> > Guenter
> > 
> > > Fixes: 585524081ecd ("random: random.h should include archrandom.h, not the other way around")
> > > Signed-off-by: Qian Cai <cai@lca.pw>
> > > ---
> > >  include/linux/random.h | 2 ++
> > >  1 file changed, 2 insertions(+)
> > > 
> > > diff --git a/include/linux/random.h b/include/linux/random.h
> > > index f45b8be3e3c4..da782c16c20c 100644
> > > --- a/include/linux/random.h
> > > +++ b/include/linux/random.h
> > > @@ -12,6 +12,8 @@
> > >  #include <linux/list.h>
> > >  #include <linux/once.h>
> > >  
> > > +#include <asm/archrandom.h>
> > > +
> > >  #include <uapi/linux/random.h>
> > >  
> > >  struct random_ready_callback {
> > > 
> > 

^ permalink raw reply	[flat|nested] 2+ messages in thread

end of thread, other threads:[~2020-08-07  0:19 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
     [not found] <20200806135836.31736-1-cai@lca.pw>
     [not found] ` <4edcf552-ef82-cdd2-3fda-38d42ebfecc7@roeck-us.net>
2020-08-06 22:43   ` [PATCH] random: fix a compilation error on arm64 Qian Cai
2020-08-07  0:19     ` Guenter Roeck

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).