linux-kernel - Re: linux-next: build failure after merge of the akpm tree

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <20130925132612.d1685bc8fb72558eef6fb09d@linux-foundation.org>
Date:	Wed, 25 Sep 2013 13:26:12 -0700
From:	Andrew Morton <akpm@...ux-foundation.org>
To:	Stephen Rothwell <sfr@...b.auug.org.au>
Cc:	linux-next@...r.kernel.org, linux-kernel@...r.kernel.org,
	Sergei Trofimovich <slyfox@...too.org>,
	Timur Tabi <timur@...escale.com>, Greg KH <greg@...ah.com>,
	ppc-dev <linuxppc-dev@...ts.ozlabs.org>
Subject: Re: linux-next: build failure after merge of the akpm tree

On Wed, 25 Sep 2013 11:06:43 +1000 Stephen Rothwell <sfr@...b.auug.org.au> wrote:

> Hi Andrew,
> 
> After merging the akpm tree, linux-next builds (powerpc allmodconfig)
> fail like this:

I can't get powerpc to build at all at present:

  CHK     include/config/kernel.release
  CHK     include/generated/uapi/linux/version.h
  CHK     include/generated/utsrelease.h
  CC      arch/powerpc/kernel/asm-offsets.s
In file included from include/linux/vtime.h:6,
                 from include/linux/hardirq.h:7,
                 from include/linux/memcontrol.h:24,
                 from include/linux/swap.h:8,
                 from include/linux/suspend.h:4,
                 from arch/powerpc/kernel/asm-offsets.c:24:
arch/powerpc/include/generated/asm/vtime.h:1:31: error: asm-generic/vtime.h: No such file or directory

> drivers/tty/ehv_bytechan.c:362:1: error: type defaults to 'int' in declaration of 'console_initcall' [-Werror=implicit-int]
> 
> Caused by commit 0f01cf96c2d4 ("./Makefile: enable -Werror=implicit-int
> and -Werror=strict-prototypes by default") which has bee in linux-next
> since Aug 16.  This commit exposed that fact that
> drivers/tty/ehv_bytechan.c can be built as a module, but has a
> console_initcall (which is not available to modules).  This was
> originally introduced in commit dcd83aaff1c8 ("tty/powerpc: introduce the
> ePAPR embedded hypervisor byte channel driver") in v3.2.
> 
> Anyone got a good solution?

console_initcall() is a macro defined in init.h.  But we forgot to
provide a version for #ifdef MODULE.

At include/linux/init.h line 284 we see:

/* Don't use these in loadable modules, but some people do... */
#define early_initcall(fn)		module_init(fn)
#define core_initcall(fn)		module_init(fn)
...

So we *could* add console_initcall() there.  But the problem is that it
won't work as desired - when the driver is loaded as a module,
ehv_bc_console_init() will be called at modprobe time, which is far far
later than console_initcall-time.

So the ehv_bytechan.c developers need to work out what they want to do
here.  Do we disallow building that driver as a module?  Or do we
permit that, and run ehv_bc_console_init() at modprobe time (needs
testing!).

If the latter then I'd be reluctant to add a modular version of
console_initcall() because the thing's very presence is misleading. 
otoh, drivers which use such a console_initcall() _might_ work, and
everyone tests their drivers both built-in and as modules, don't they? 
Don't they?
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/