All of lore.kernel.org
 help / color / mirror / Atom feed
From: Al Viro <viro@ZenIV.linux.org.uk>
To: Nicolas Pitre <nicolas.pitre@linaro.org>
Cc: Linus Torvalds <torvalds@linux-foundation.org>,
	kbuild test robot <fengguang.wu@intel.com>,
	LKML <linux-kernel@vger.kernel.org>
Subject: Re: [linus:master] BUILD REGRESSION f3b5ad89de16f5d42e8ad36fbdf85f705c1ae051
Date: Sun, 17 Dec 2017 15:25:25 +0000	[thread overview]
Message-ID: <20171217152525.GL21978@ZenIV.linux.org.uk> (raw)
In-Reply-To: <nycvar.YSQ.7.76.1712162238020.19130@knanqh.ubzr>

On Sat, Dec 16, 2017 at 10:46:05PM -0500, Nicolas Pitre wrote:
> Date: Fri, 10 Nov 2017 15:57:21 +0100
> From: Arnd Bergmann <arnd@arndb.de>
> Subject: [PATCH] cramfs: fix MTD dependency
> 
> With CONFIG_MTD=m and CONFIG_CRAMFS=y, we now get a link failure:
> 
> fs/cramfs/inode.o: In function `cramfs_mount':
> inode.c:(.text+0x220): undefined reference to `mount_mtd'
> fs/cramfs/inode.o: In function `cramfs_mtd_fill_super':
> inode.c:(.text+0x6d8): undefined reference to `mtd_point'
> inode.c:(.text+0xae4): undefined reference to `mtd_unpoint'
> 
> This adds a more specific Kconfig dependency to avoid the
> broken configuration. Alternatively we could make CRAMFS
> itself depend on "MTD || !MTD" with a similar result.
> 
> Fixes: 99c18ce580c6 ("cramfs: direct memory access support")
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> Signed-off-by: Nicolas Pitre <nico@linaro.org>
> ---
>  fs/cramfs/Kconfig | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/fs/cramfs/Kconfig b/fs/cramfs/Kconfig
> index f937082f3244..58e2fe40b2a0 100644
> --- a/fs/cramfs/Kconfig
> +++ b/fs/cramfs/Kconfig
> @@ -34,6 +34,7 @@ config CRAMFS_BLOCKDEV
>  config CRAMFS_MTD
>  	bool "Support CramFs image directly mapped in physical memory"
>  	depends on CRAMFS && MTD
> +	depends on CRAMFS=m || MTD=y

*Ugh*

So basically the trouble case is CRAMFS=y, MTD=m; in that situation
mount_mtd() et.al. are not stubbed out at compiler level (as they
would with CRAMFS=y, MTD=n) and we end up with linker catching that.
Not pretty solution, but...

Linus, would you take that directly or should I include it into vfs.git
pull request?

  reply	other threads:[~2017-12-17 15:25 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-12-17  3:00 [linus:master] BUILD REGRESSION f3b5ad89de16f5d42e8ad36fbdf85f705c1ae051 kbuild test robot
2017-12-17  3:24 ` Linus Torvalds
2017-12-17  3:46   ` Nicolas Pitre
2017-12-17 15:25     ` Al Viro [this message]
2017-12-17 20:22       ` Linus Torvalds

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20171217152525.GL21978@ZenIV.linux.org.uk \
    --to=viro@zeniv.linux.org.uk \
    --cc=fengguang.wu@intel.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=nicolas.pitre@linaro.org \
    --cc=torvalds@linux-foundation.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.