I think the proper course here is to make the use conditional,
assuming that there will never be a 32-bit application running if
CONFIG_COMPAT is not enabled.  Thank you Mark for catching this, and
Catalin for your suggestions.  I've just posted patch-set v4, which
addresses some of Catalin's remarks and this breakage; I'd have no
objection to removing v3 from next, especially in light of this.

Thank You,
Dan

On Thu, Nov 26, 2015 at 7:10 AM, Catalin Marinas
[off-list ref] wrote:

On Thu, Nov 26, 2015 at 11:32:13AM +0000, Mark Brown wrote:

quoted

Today's -next fails to build an arm64 allnoconfig due to:

quoted

    arm64-allnoconfig
../arch/arm64/mm/mmap.c:55:49: error: 'mmap_rnd_compat_bits' undeclared (first use in this function)

which was introduced by a combination of 8f62c06c279a3 (mm: mmap: add
new /proc tunable for mmap_base ASLR) and 9411708692954 (arm64: mm:
support ARCH_MMAP_RND_BITS).  These add an unconditional use of
mmap_rnd_compat_bits which is only defined in linux/mmap.h if
HAVE_ARCH_MMAP_RND_COMPAT_BITS is selected but that is only enabled for
arm64 if COMPAT is enabled.  Either the select needs to be unconditional
or the use needs to be.

There are other problems with these patches for arm64, I already replied
here:

http://lkml.kernel.org/g/20151125120601.GC3109@e104818-lin.cambridge.arm.com

So I don't think they should be in -next.

--
Catalin

-- 
Dan Cashman