On 31 January 2018 at 12:46, Russell King - ARM Linux
[off-list ref] wrote:

On Wed, Jan 31, 2018 at 12:25:33PM +0100, Arnd Bergmann wrote:

quoted

On Tue, Jan 30, 2018 at 12:57 AM, Russell King - ARM Linux
[off-list ref] wrote:

quoted

On Tue, Jan 30, 2018 at 12:49:00AM +0100, Anders Roxell wrote:

quoted

While testing multi_v7_defconfig with LOCKDEP enabled, the kernel
fails to load simple modules, as reported by kselftest:

[   34.107620] test_printf: section 4 reloc 2 sym 'memset': relocation
28 out of range (0xbf046044 -> 0xc109f720)
selftests: printf.sh [FAIL]

The problem that is seen when LOCKDEP is enabled without
ARM_MODULE_PLTS, is that LOCKDEP eats so much memory that the top of the
kernel gets out of reach from the bottom of the module area.

This really doesn't follow IMHO - enabling various features can cause
this, and we're not going to end up stuffing the Kconfig full of these
select statements each time we find a combination of Kconfig symbols
that cause it.

lockdep isn't that special - I can (and do) build kernels with lockdep
enabled, with modules, and I do not run into this problem.  So it's
not as simple as you make out in this commit description.

It's likely that you have either a fairly full kernel configuration (it
must be to place memset() more than 16MB) or you are not placing the
kernel at 0xc0008000 due to memory reservations in the low memory.

quoted

Suggested-by: Arnd Bergmann <arnd@arndb.de>

I guess this was discussed privately with Arnd, since there's no record
of the discussion on the lists - which is even more reason why the
commit message needs to describe better why you need this change.

I don't remember the original discussion exactly, but it's clear that
the addition of LOCKDEP to the build is what caused the size to
grow dramatically and prevent module loading.

As I say above, it does not follow "lockdep is enabled" therefore "we
need module plts" so I don't accept this argument.

Yes, if you have a lot of features built in, then its entirely possible
that enabling lockdep will cause the kernel to overflow the non-plt
boundary.  It will also be true that enabling a few more other features
will also cause the kernel to overflow the non-plt boundary as well.
Should we add those other features to a Kconfig expression too?  At
what point do we stop adding these?

quoted

There are two alternative ways to do this without forcing
ARM_MODULE_PLTS on all the time (which also triggered
the 0day bot warning):

Yes, 0day is pointing out yet again what a silly idea it is to select
symbols that (a) have dependencies and (b) are user visible, something
that I've long disagreed about.

quoted

a) we could make ARM_MODULE_PLTS default to 'y' when
LOCKDEP is anbled, making it a more reasonable default while
also letting users turn it off when the lockdep-enabled kernel
is still small enough

As I've said, I don't believe "LOCKDEP" therefore need "MODULE_PLTS"
follows.  It's just a symptom of an already large kernel.  I suspect
without lockdep, Ander's kernel is already approaching the
problematical 16MB mark.

Another option that causes the kernel to grow by a few megabytes is
the kernel protection options (ronx etc).  I suspect if Anders built
a kernel that had lockdep enabled and ronx etc disabled, that there
would be no need for module plts.  Should we turn on module plts if
lockdep or ronx is enabled?

I don't think there's a _sane_ solution to this other than defaulting
ARM_MODULE_PLTS to 'y' without any of these dependencies, and if people
want to turn it off, they still can if they're sure they won't run into
this situation.

I'll send out a v2 with this change shortly.

Thank you all for your comments.

Cheers,
Anders