| Message ID | 20230801145409.8935-1-james.morse@arm.com (mailing list archive) |
|---|---|
| Headers | show |
| Series | ARM/arm64: Fix loading of modules with an exit section | expand |
On Tue, Aug 01, 2023 at 02:54:06PM +0000, James Morse wrote: > Adam reports that Yocto can't load modules on arm64. This turns out to be due > to the arch code disagreeing with the core code when it comes to the layout > of the modules exit text, resulting in a shortage of PLTs and a bunch of > warnings. > > arm and arm64 are unusual here as they are counting the PLTs based on the > section name. This series exposes the helper that core code uses to decide > the layout. > > I've been unable to reproduce the behaviour on 32bit - but it looks like > its possible to reach the BUG_ON() in get_module_plt(). To test this, disable > CONFIG_MODULE_UNLOAD, and try to load modules with relocations in their exit > text. > > This series is based on v6.5-rc4, and can be retrieved from: > https://git.kernel.org/pub/scm/linux/kernel/git/morse/linux.git arm64/modules/exit_sections/v1 > Reviewed-by: Luis Chamberlain <mcgrof@kernel.org> Do you want this to go through the modules tree or do you want to take this in your tree? Either way is fine by me, at this point there should be no conflicts. Luis
Hi Luis, On 01/08/2023 18:14, Luis Chamberlain wrote: > On Tue, Aug 01, 2023 at 02:54:06PM +0000, James Morse wrote: >> Adam reports that Yocto can't load modules on arm64. This turns out to be due >> to the arch code disagreeing with the core code when it comes to the layout >> of the modules exit text, resulting in a shortage of PLTs and a bunch of >> warnings. >> >> arm and arm64 are unusual here as they are counting the PLTs based on the >> section name. This series exposes the helper that core code uses to decide >> the layout. >> >> I've been unable to reproduce the behaviour on 32bit - but it looks like >> its possible to reach the BUG_ON() in get_module_plt(). To test this, disable >> CONFIG_MODULE_UNLOAD, and try to load modules with relocations in their exit >> text. >> >> This series is based on v6.5-rc4, and can be retrieved from: >> https://git.kernel.org/pub/scm/linux/kernel/git/morse/linux.git arm64/modules/exit_sections/v1 >> > > Reviewed-by: Luis Chamberlain <mcgrof@kernel.org> Thanks! > Do you want this to go through the modules tree or do you want to take > this in your tree? Either way is fine by me, at this point there should > be no conflicts. If Russell agrees the problem exists on 32bit arm, then I think it would be best to keep these three together - going via the modules tree would make the most sense. This has been broken for a while, so it can wait for v6.6-rc1. I think the yocto folk plan to carry this out of tree until its in their chosen stable version. Thanks, James
On Wed, Aug 02, 2023 at 05:28:10PM +0100, James Morse wrote: > Hi Luis, > > On 01/08/2023 18:14, Luis Chamberlain wrote: > > On Tue, Aug 01, 2023 at 02:54:06PM +0000, James Morse wrote: > >> Adam reports that Yocto can't load modules on arm64. This turns out to be due > >> to the arch code disagreeing with the core code when it comes to the layout > >> of the modules exit text, resulting in a shortage of PLTs and a bunch of > >> warnings. > >> > >> arm and arm64 are unusual here as they are counting the PLTs based on the > >> section name. This series exposes the helper that core code uses to decide > >> the layout. > >> > >> I've been unable to reproduce the behaviour on 32bit - but it looks like > >> its possible to reach the BUG_ON() in get_module_plt(). To test this, disable > >> CONFIG_MODULE_UNLOAD, and try to load modules with relocations in their exit > >> text. > >> > >> This series is based on v6.5-rc4, and can be retrieved from: > >> https://git.kernel.org/pub/scm/linux/kernel/git/morse/linux.git arm64/modules/exit_sections/v1 > >> > > > > Reviewed-by: Luis Chamberlain <mcgrof@kernel.org> > > Thanks! > > > > Do you want this to go through the modules tree or do you want to take > > this in your tree? Either way is fine by me, at this point there should > > be no conflicts. > > If Russell agrees the problem exists on 32bit arm, then I think it would be best to keep > these three together - going via the modules tree would make the most sense. > > This has been broken for a while, so it can wait for v6.6-rc1. > I think the yocto folk plan to carry this out of tree until its in their chosen stable > version. The thing about PLTs is that it's something I've never had the need to make use of - because I've never been in the situation where the arm32 module space has been close to overflowing. The addition of PLT support for 32-bit arm did make my eyebrows raise for this very reason, but I guess there are a small number of people who want to use really large modules. As such, I couldn't say whether it's broken or not - but it seems sensible to keep both the 64-bit and 32-bit code tracking each other.
On Thu, Aug 03, 2023 at 11:20:06AM +0100, Russell King (Oracle) wrote: > On Wed, Aug 02, 2023 at 05:28:10PM +0100, James Morse wrote: > > If Russell agrees the problem exists on 32bit arm, then I think it > > would be best to keep these three together - going via the modules > > tree would make the most sense. > > The thing about PLTs is that it's something I've never had the need to > make use of - because I've never been in the situation where the > arm32 module space has been close to overflowing. The addition of PLT > support for 32-bit arm did make my eyebrows raise for this very reason, > but I guess there are a small number of people who want to use really > large modules. > > As such, I couldn't say whether it's broken or not - but it seems > sensible to keep both the 64-bit and 32-bit code tracking each other. Alrighty, merged and pushed onto modules-next. Luis