linux-kernel - Re: linux-next: Tree for Jul 18 (header build error)

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: <20190719003045.GF692234@magnolia>
Date:   Thu, 18 Jul 2019 17:30:45 -0700
From:   "Darrick J. Wong" <darrick.wong@...cle.com>
To:     Stephen Rothwell <sfr@...b.auug.org.au>
Cc:     Randy Dunlap <rdunlap@...radead.org>,
        Linux Next Mailing List <linux-next@...r.kernel.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Masahiro Yamada <yamada.masahiro@...ionext.com>,
        linux-kbuild <linux-kbuild@...r.kernel.org>,
        Christoph Hellwig <hch@...radead.org>
Subject: Re: linux-next: Tree for Jul 18 (header build error)

On Fri, Jul 19, 2019 at 10:05:57AM +1000, Stephen Rothwell wrote:
> Hi all,
> 
> On Thu, 18 Jul 2019 10:00:22 -0700 Randy Dunlap <rdunlap@...radead.org> wrote:
> >
> > on x86_64, when CONFIG_BLOCK is not set:
> > 
> >   CC      include/linux/iomap.h.s
> > In file included from <command-line>:0:0:
> > ./../include/linux/iomap.h: In function ‘iomap_sector’:
> > ./../include/linux/iomap.h:76:48: error: ‘SECTOR_SHIFT’ undeclared (first use in this function); did you mean ‘SECTIONS_SHIFT’?
> >   return (iomap->addr + pos - iomap->offset) >> SECTOR_SHIFT;
> >                                                 ^~~~~~~~~~~~
> 
> include/linux/iomap.h should only be used when CONFIG_BLOCK is set (if
> you follow the Kconfig trail).  So maybe this header should only be
> compile tested if CONFIG_BLOCK is set.

Yeah, that's basically what Christoph said earlier today.

Granted, nobody replied to my question about where in the kernel would
someone be using iomap to map file offsets to disk locations without
block devices, but ...

... oh, this is some weird "mash all the kernel headers together and see
if they compile" thing, isn't it?  Um, yes, iomap.h should only be
tested if CONFIG_IOMAP=y (which in turn requires CONFIG_BLOCK=y).

--D

> -- 
> Cheers,
> Stephen Rothwell