From: "Russell King (Oracle)" <linux@armlinux.org.uk>
To: James Morse <james.morse@arm.com>
Cc: Luis Chamberlain <mcgrof@kernel.org>,
linux-modules@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
Catalin Marinas <catalin.marinas@arm.com>,
Will Deacon <will@kernel.org>, Jessica Yu <jeyu@kernel.org>,
Adam Johnston <adam.johnston@arm.com>
Subject: Re: [PATCH 0/3] ARM/arm64: Fix loading of modules with an exit section
Date: Thu, 3 Aug 2023 11:20:06 +0100 [thread overview]
Message-ID: <ZMt/VgQoovUDi4g7@shell.armlinux.org.uk> (raw)
In-Reply-To: <4f9af3c3-bafa-c536-22a0-86d427049eb3@arm.com>
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.
--
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 80Mbps down 10Mbps up. Decent connectivity at last!
WARNING: multiple messages have this Message-ID (diff)
From: "Russell King (Oracle)" <linux@armlinux.org.uk>
To: James Morse <james.morse@arm.com>
Cc: Luis Chamberlain <mcgrof@kernel.org>,
linux-modules@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
Catalin Marinas <catalin.marinas@arm.com>,
Will Deacon <will@kernel.org>, Jessica Yu <jeyu@kernel.org>,
Adam Johnston <adam.johnston@arm.com>
Subject: Re: [PATCH 0/3] ARM/arm64: Fix loading of modules with an exit section
Date: Thu, 3 Aug 2023 11:20:06 +0100 [thread overview]
Message-ID: <ZMt/VgQoovUDi4g7@shell.armlinux.org.uk> (raw)
In-Reply-To: <4f9af3c3-bafa-c536-22a0-86d427049eb3@arm.com>
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.
--
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 80Mbps down 10Mbps up. Decent connectivity at last!
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2023-08-03 10:22 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-08-01 14:54 [PATCH 0/3] ARM/arm64: Fix loading of modules with an exit section James Morse
2023-08-01 14:54 ` James Morse
2023-08-01 14:54 ` [PATCH 1/3] module: Expose module_init_layout_section() James Morse
2023-08-01 14:54 ` James Morse
2023-08-01 14:54 ` [PATCH 2/3] arm64: module: Use module_init_layout_section() to spot init sections James Morse
2023-08-01 14:54 ` James Morse
2023-08-02 17:00 ` Catalin Marinas
2023-08-02 17:00 ` Catalin Marinas
2023-08-01 14:54 ` [PATCH 3/3] ARM: " James Morse
2023-08-01 14:54 ` James Morse
2023-08-01 17:14 ` [PATCH 0/3] ARM/arm64: Fix loading of modules with an exit section Luis Chamberlain
2023-08-01 17:14 ` Luis Chamberlain
2023-08-02 16:28 ` James Morse
2023-08-02 16:28 ` James Morse
2023-08-03 10:20 ` Russell King (Oracle) [this message]
2023-08-03 10:20 ` Russell King (Oracle)
2023-08-03 20:43 ` Luis Chamberlain
2023-08-03 20:43 ` Luis Chamberlain
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=ZMt/VgQoovUDi4g7@shell.armlinux.org.uk \
--to=linux@armlinux.org.uk \
--cc=adam.johnston@arm.com \
--cc=catalin.marinas@arm.com \
--cc=james.morse@arm.com \
--cc=jeyu@kernel.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-modules@vger.kernel.org \
--cc=mcgrof@kernel.org \
--cc=will@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.