On 31 January 2018 at 12:46, Russell King - ARM Linux <li...@armlinux.org.uk> wrote: > On Wed, Jan 31, 2018 at 12:25:33PM +0100, Arnd Bergmann wrote: >> On Tue, Jan 30, 2018 at 12:57 AM, Russell King - ARM Linux >> <li...@armlinux.org.uk> wrote: >> > On Tue, Jan 30, 2018 at 12:49:00AM +0100, Anders Roxell wrote: >> >> 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. >> > >> >> Suggested-by: Arnd Bergmann <a...@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? > >> 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. > >> 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