* [GIT PULL] firmware: arm_scmi: Fixes for v6.9
From: Sudeep Holla @ 2024-04-04 14:03 UTC (permalink / raw)
To: ARM SoC Team, SoC Team, ALKML
Cc: Sudeep Holla, Arnd Bergmann, Cristian Marussi, Olof Johansson
Hi ARM SoC Team,
Please pull !
Regards,
Sudeep
-->8
The following changes since commit 4cece764965020c22cff7665b18a012006359095:
Linux 6.9-rc1 (2024-03-24 14:10:05 -0700)
are available in the Git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/sudeep.holla/linux.git tags/scmi-fixes-6.9
for you to fetch changes up to b70c7996d4ffb2e02895132e8a79a37cee66504f:
firmware: arm_scmi: Make raw debugfs entries non-seekable (2024-03-25 10:14:28 +0000)
----------------------------------------------------------------
Arm SCMI fixes for v6.9
Couple of fixes to address wrong fastchannel initialization in powercap
protocol and disable seeking support for SCMI raw debugfs entries.
----------------------------------------------------------------
Cristian Marussi (1):
firmware: arm_scmi: Make raw debugfs entries non-seekable
Pierre Gondois (1):
firmware: arm_scmi: Fix wrong fastchannel initialization
drivers/firmware/arm_scmi/powercap.c | 2 +-
drivers/firmware/arm_scmi/raw_mode.c | 7 ++++++-
2 files changed, 7 insertions(+), 2 deletions(-)
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [GIT PULL] firmware: arm_ffa: Fix for v6.9
From: Sudeep Holla @ 2024-04-04 14:03 UTC (permalink / raw)
To: ARM SoC Team, SoC Team, ALKML; +Cc: Sudeep Holla, Arnd Bergmann, Olof Johansson
Hi ARM SoC Team,
Please pull !
Regards,
Sudeep
-->8
The following changes since commit 4cece764965020c22cff7665b18a012006359095:
Linux 6.9-rc1 (2024-03-24 14:10:05 -0700)
are available in the Git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/sudeep.holla/linux.git tags/ffa-fix-6.9
for you to fetch changes up to 1a4bd2b128fb5ca62e4d1c5ca298d3d06b9c1e8e:
firmware: arm_ffa: Fix the partition ID check in ffa_notification_info_get() (2024-03-25 10:14:17 +0000)
----------------------------------------------------------------
Arm FF-A fix for v6.9
A single fix to address the incorrect check of VM ID count for the
global notification in the response received for FFA_NOTIFICATION_INFO_GET()
in the schedule receiver interrupt handler.
----------------------------------------------------------------
Jens Wiklander (1):
firmware: arm_ffa: Fix the partition ID check in ffa_notification_info_get()
drivers/firmware/arm_ffa/driver.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v6 03/29] iommu/arm-smmu-v3: Do not allow a SVA domain to be set on the wrong PASID
From: Jason Gunthorpe @ 2024-04-04 14:04 UTC (permalink / raw)
To: Mostafa Saleh
Cc: iommu, Joerg Roedel, linux-arm-kernel, Robin Murphy, Will Deacon,
Lu Baolu, Eric Auger, Jean-Philippe Brucker, Joerg Roedel,
Kevin Tian, kernel test robot, Moritz Fischer, Moritz Fischer,
Michael Shavit, Nicolin Chen, patches, Shameer Kolothum, Tony Zhu,
Yi Liu, Zhangfei Gao
In-Reply-To: <ZgVuErNrG9EcbPbX@google.com>
On Thu, Mar 28, 2024 at 01:18:10PM +0000, Mostafa Saleh wrote:
> Hi Jason,
>
> On Wed, Mar 27, 2024 at 03:07:49PM -0300, Jason Gunthorpe wrote:
> > The SVA code is wired to assume that the SVA is programmed onto the
> > mm->pasid. The current core code always does this, so it is fine.
> >
> > Add a check for clarity.
> >
> > Fixes: 386fa64fd52b ("arm-smmu-v3/sva: Add SVA domain support")
> > Tested-by: Nicolin Chen <nicolinc@nvidia.com>
> > Tested-by: Shameer Kolothum <shameerali.kolothum.thodi@huawei.com>
> > Reviewed-by: Mostafa Saleh <smostafa@google.com>
>
> I think there might have been a mix up, this was patch 01 in v5,
> I didn’t add a tag on it. I don’t have a problem with the patch.
Oh yes, it is somehow my mistake, sorry. All this tag annotation is
done by hand :(
I also didn't intend to re-send the first two patches, they are going
to be in rc3.
Jason
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v2 0/5] SCMI misc small-updates
From: Sudeep Holla @ 2024-04-04 14:10 UTC (permalink / raw)
To: linux-kernel, linux-arm-kernel, Cristian Marussi; +Cc: Sudeep Holla
In-Reply-To: <20240325204620.1437237-1-cristian.marussi@arm.com>
On Mon, 25 Mar 2024 20:46:15 +0000, Cristian Marussi wrote:
> a bunch of small SCMI updates based on v6.9-rc1.
> Mainly adding traces for weird SCMI messages like late timed-out replies,
> out of order unexpected messages and malformed messages due to spurious
> mbox IRQs.
>
> Thanks,
> Cristian
>
> [...]
Applied to sudeep.holla/linux (for-next/scmi/updates), thanks!
[1/5] include: trace: Widen the tag buffer in trace_scmi_dump_msg
https://git.kernel.org/sudeep.holla/c/da251ce21061
[2/5] firmware: arm_scmi: Add helper to trace bad messages
https://git.kernel.org/sudeep.holla/c/5dc0e0b1f0ea
[3/5] firmware: arm_scmi: Add message dump traces for bad and unexpected replies
https://git.kernel.org/sudeep.holla/c/5076ab66db16
[4/5] firmware: arm_scmi: Simplify scmi_devm_notifier_unregister
https://git.kernel.org/sudeep.holla/c/264a2c520628
[5/5] firmware: arm_scmi: Use dev_err_probe to bail out
https://git.kernel.org/sudeep.holla/c/3a7d93d1f71b
--
Regards,
Sudeep
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 1/1] dt-bindings: media: imx-jpeg: add clocks,clock-names,slot to fix warning
From: Frank Li @ 2024-04-04 13:54 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: Fabio Estevam, Mirela Rabulea, Mauro Carvalho Chehab, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Shawn Guo, Sascha Hauer,
Pengutronix Kernel Team,
open list:NXP i.MX 8QXP/8QM JPEG V4L2 DRIVER,
open list:NXP i.MX 8QXP/8QM JPEG V4L2 DRIVER,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE,
open list
In-Reply-To: <e78c8c2e-1c83-4492-9db9-08f06856a414@linaro.org>
On Thu, Apr 04, 2024 at 01:59:57PM +0200, Krzysztof Kozlowski wrote:
> On 04/04/2024 13:03, Fabio Estevam wrote:
> > On Thu, Apr 4, 2024 at 3:54 AM Krzysztof Kozlowski
> > <krzysztof.kozlowski@linaro.org> wrote:
> >
> >> And for the clocks, instead pick up this patch:
> >> https://lore.kernel.org/all/20230721111020.1234278-3-alexander.stein@ew.tq-group.com/
> >
> > Or maybe this one:
> > https://lore.kernel.org/linux-devicetree/DB9PR04MB923493D0DA82C9EC4386BC2A8FF1A@DB9PR04MB9234.eurprd04.prod.outlook.com/
>
>
> Three people were fixing same clocks issue... and three or more people
> were trying to fix the slot property.
>
> This is really bad binding maintenance and driver upstreaming, NXP.
Thanks everyone help make imx dts and binding better. I should google
before send.
Patchwork for imx already was created.
https://patchwork.kernel.org/project/imx/list/?series=&submitter=150701&state=&q=&archive=&delegate=
I hope to patchwork help reduce duplicate work.
Frank
>
> Best regards,
> Krzysztof
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH] firmware: arm_scmi: Avoid non-constant printk format strings
From: Sudeep Holla @ 2024-04-04 14:12 UTC (permalink / raw)
To: Cristian Marussi, Arnd Bergmann
Cc: Sudeep Holla, Arnd Bergmann, Nathan Chancellor, Nick Desaulniers,
Bill Wendling, Justin Stitt, Nikunj Kela, linux-arm-kernel,
linux-kernel, llvm
In-Reply-To: <20240403111040.3924658-1-arnd@kernel.org>
On Wed, 03 Apr 2024 13:10:24 +0200, Arnd Bergmann wrote:
> A recent rework changed the constant format strings to a local variable,
> which causes warnings from clang when -Wformat-security is enabled:
>
> drivers/firmware/arm_scmi/driver.c: In function 'scmi_probe':
> drivers/firmware/arm_scmi/driver.c:2936:25: error: format not a string literal and no format arguments [-Werror=format-security]
> 2936 | dev_err(dev, err_str);
> | ^~~~~~~
> drivers/firmware/arm_scmi/driver.c:2993:9: error: format not a string literal and no format arguments [-Werror=format-security]
> 2993 | return dev_err_probe(dev, ret, err_str);
>
> [...]
Applied to sudeep.holla/linux (for-next/scmi/updates), thanks!
[1/1] firmware: arm_scmi: Avoid non-constant printk format strings
https://git.kernel.org/sudeep.holla/c/495667d49c50
--
Regards,
Sudeep
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v3 23/25] drivers: media: i2c: imx258: Add support for powerdown gpio
From: Dave Stevenson @ 2024-04-04 14:12 UTC (permalink / raw)
To: Luigi311
Cc: Ondřej Jirman, Sakari Ailus, linux-media, jacopo.mondi,
mchehab, robh, krzysztof.kozlowski+dt, conor+dt, shawnguo,
s.hauer, kernel, festevam, devicetree, imx, linux-arm-kernel,
linux-kernel, pavel, phone-devel
In-Reply-To: <dd0e64c8-5eef-421a-9d9f-8a5865743369@luigi311.com>
Hi Luigi
On Wed, 3 Apr 2024 at 20:34, Luigi311 <git@luigi311.com> wrote:
>
> On 4/3/24 10:57, Ondřej Jirman wrote:
> > Hi Sakari and Luis,
> >
> > On Wed, Apr 03, 2024 at 04:25:41PM GMT, Sakari Ailus wrote:
> >> Hi Luis, Ondrej,
> >>
> >> On Wed, Apr 03, 2024 at 09:03:52AM -0600, git@luigi311.com wrote:
> >>> From: Luis Garcia <git@luigi311.com>
> >>>
> >>> On some boards powerdown signal needs to be deasserted for this
> >>> sensor to be enabled.
> >>>
> >>> Signed-off-by: Ondrej Jirman <megi@xff.cz>
> >>> Signed-off-by: Luis Garcia <git@luigi311.com>
> >>> ---
> >>> drivers/media/i2c/imx258.c | 13 +++++++++++++
> >>> 1 file changed, 13 insertions(+)
> >>>
> >>> diff --git a/drivers/media/i2c/imx258.c b/drivers/media/i2c/imx258.c
> >>> index 30352c33f63c..163f04f6f954 100644
> >>> --- a/drivers/media/i2c/imx258.c
> >>> +++ b/drivers/media/i2c/imx258.c
> >>> @@ -679,6 +679,8 @@ struct imx258 {
> >>> unsigned int lane_mode_idx;
> >>> unsigned int csi2_flags;
> >>>
> >>> + struct gpio_desc *powerdown_gpio;
> >>> +
> >>> /*
> >>> * Mutex for serialized access:
> >>> * Protect sensor module set pad format and start/stop streaming safely.
> >>> @@ -1213,6 +1215,8 @@ static int imx258_power_on(struct device *dev)
> >>> struct imx258 *imx258 = to_imx258(sd);
> >>> int ret;
> >>>
> >>> + gpiod_set_value_cansleep(imx258->powerdown_gpio, 0);
> >>
> >> What does the spec say? Should this really happen before switching on the
> >> supplies below?
> >
> > There's no powerdown input in the IMX258 manual. The manual only mentions
> > that XCLR (reset) should be held low during power on.
> >
> > https://megous.com/dl/tmp/15b0992a720ab82d.png
> >
> > https://megous.com/dl/tmp/f2cc991046d97641.png
> >
> > This sensor doesn’t have a built-in “Power ON Reset” function. The XCLR pin
> > is set to “LOW” and the power supplies are brought up. Then the XCLR pin
> > should be set to “High” after INCK supplied.
> >
> > So this input is some feature on camera module itself outside of the
> > IMX258 chip, which I think is used to gate power to the module. Eg. on Pinephone
> > Pro, there are two modules with shared power rails, so enabling supply to
> > one module enables it to the other one, too. So this input becomes the only way
> > to really enable/disable power to the chip when both are used at once at some
> > point, because regulator_bulk_enable/disable becomes ineffective at that point.
> >
> > Luis, maybe you saw some other datasheet that mentions this input? IMO,
> > it just gates the power rails via some mosfets on the module itself, since
> > there's not power down input to the chip itself.
> >
> > kind regards,
> > o.
> >
>
> Ondrej, I did not see anything else in the datasheet since I'm pretty sure
> I'm looking at the same datasheet as it was supplied to me by Pine64. I'm
> not sure what datasheet Dave has access to since he got his for a
> completely different module than what we are testing with though.
I only have a leaked datasheet (isn't the internet wonderful!) [1]
XCLR is documented in that, as Ondrej has said.
If this powerdown GPIO is meant to be driving XCLR, then it is in the
wrong order against the supplies.
This does make me confused over the difference between this powerdown
GPIO and the reset GPIO that you implement in 24/25.
Following the PinePhone Pro DT [3] and schematics [4]
reset-gpios = <&gpio1 RK_PA0 GPIO_ACTIVE_LOW>;
powerdown-gpios = <&gpio2 RK_PD4 GPIO_ACTIVE_HIGH>;
Schematic page 11 upper right block
GPIO1_A0/ISP0_SHUTTER_EN/ISP1_SHUTTER_EN/TCPD_VBUS_SINK_EN_d becomes
Camera_RST_L. Page 18 feeds that through to the RESET on the camera
connector.
Page 11 left middle block GPIO2_D4/SDIO0_BKPWR_d becomes DVP_PDN1_H.
Page 18 feeds that through to the PWDN on the camera connector.
Seeing as we apparently have a lens driver kicking around as well,
potentially one is reset to the VCM, and one to the sensor? DW9714
does have an XSD shutdown pin.
Only the module integrator is going to really know the answer,
although potentially a little poking with gpioset and i2cdetect may
tell you more.
Dave
[1] https://web.archive.org/web/20201027131326/www.hi.app/IMX258-datasheet.pdf
[2] https://files.pine64.org/doc/PinePhonePro/PinephonePro-Schematic-V1.0-20211127.pdf
[3] https://xff.cz/git/linux/tree/arch/arm64/boot/dts/rockchip/rk3399-pinephone-pro.dts?h=orange-pi-5.18#n868
[4] https://files.pine64.org/doc/PinePhonePro/PinephonePro-Schematic-V1.0-20211127.pdf
> >>> +
> >>> ret = regulator_bulk_enable(IMX258_NUM_SUPPLIES,
> >>> imx258->supplies);
> >>> if (ret) {
> >>> @@ -1224,6 +1228,7 @@ static int imx258_power_on(struct device *dev)
> >>> ret = clk_prepare_enable(imx258->clk);
> >>> if (ret) {
> >>> dev_err(dev, "failed to enable clock\n");
> >>> + gpiod_set_value_cansleep(imx258->powerdown_gpio, 1);
> >>> regulator_bulk_disable(IMX258_NUM_SUPPLIES, imx258->supplies);
> >>> }
> >>>
> >>> @@ -1238,6 +1243,8 @@ static int imx258_power_off(struct device *dev)
> >>> clk_disable_unprepare(imx258->clk);
> >>> regulator_bulk_disable(IMX258_NUM_SUPPLIES, imx258->supplies);
> >>>
> >>> + gpiod_set_value_cansleep(imx258->powerdown_gpio, 1);
> >>> +
> >>> return 0;
> >>> }
> >>>
> >>> @@ -1541,6 +1548,12 @@ static int imx258_probe(struct i2c_client *client)
> >>> if (!imx258->variant_cfg)
> >>> imx258->variant_cfg = &imx258_cfg;
> >>>
> >>> + /* request optional power down pin */
> >>> + imx258->powerdown_gpio = devm_gpiod_get_optional(&client->dev, "powerdown",
> >>> + GPIOD_OUT_HIGH);
> >>> + if (IS_ERR(imx258->powerdown_gpio))
> >>> + return PTR_ERR(imx258->powerdown_gpio);
> >>> +
> >>> /* Initialize subdev */
> >>> v4l2_i2c_subdev_init(&imx258->sd, client, &imx258_subdev_ops);
> >>>
> >>
> >> --
> >> Regards,
> >>
> >> Sakari Ailus
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH net-next v3 0/5] allocate dummy device dynamically
From: Breno Leitao @ 2024-04-04 14:22 UTC (permalink / raw)
To: Kalle Valo
Cc: aleksander.lobakin, kuba, davem, pabeni, edumazet, elder,
linux-arm-kernel, linux-mediatek, nbd, sean.wang, Mark-MC.Lee,
lorenzo, taras.chornyi, Matthias Brugger,
AngeloGioacchino Del Regno, quic_jjohnson, leon,
dennis.dalessandro, linux-kernel, netdev, bpf
In-Reply-To: <87plv549ts.fsf@kernel.org>
Hello Kalle,
On Thu, Apr 04, 2024 at 02:59:59PM +0300, Kalle Valo wrote:
> Breno Leitao <leitao@debian.org> writes:
>
> > struct net_device shouldn't be embedded into any structure, instead,
> > the owner should use the private space to embed their state into
> > net_device.
> >
> > But, in some cases the net_device is embedded inside the private
> > structure, which blocks the usage of zero-length arrays inside
> > net_device.
> >
> > Create a helper to allocate a dummy device at dynamically runtime, and
> > move the Ethernet devices to use it, instead of embedding the dummy
> > device inside the private structure.
> >
> > This fixes all the network cases except for wireless drivers.
> >
> > PS: Due to lack of hardware, unfortunately all these patches are
> > compiled tested only.
>
> BTW if it helps, and if you have an ath10k or ath11k patch already, I
> can run a quick test on real hardware.
That would be very much appreciated! Thanks!
I don't have them ready yet, but, I will work on them soon and I will
send it to you probably tomorrow.
Should I send them as RFC, or as a regular patch, and we iterate over?
What would you prefer?
Thanks!
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH] drm: fix DRM_DISPLAY_DP_HELPER dependencies
From: Maxime Ripard @ 2024-04-04 14:23 UTC (permalink / raw)
To: Inki Dae, Seung-Woo Kim, Kyungmin Park, David Airlie,
Daniel Vetter, Krzysztof Kozlowski, Sandy Huang,
Heiko Stübner, Andy Yan, Maarten Lankhorst,
Thomas Zimmermann, Jani Nikula, Arnd Bergmann
Cc: Arnd Bergmann, Alim Akhtar, Sam Ravnborg, dri-devel,
linux-arm-kernel, linux-samsung-soc, linux-kernel, linux-rockchip
In-Reply-To: <20240404124101.2988099-1-arnd@kernel.org>
On Thu, 04 Apr 2024 14:40:51 +0200, Arnd Bergmann wrote:
> Both the exynos and rockchip drivers ran into link failures after
> a Kconfig cleanup:
>
> aarch64-linux-ld: drivers/gpu/drm/exynos/exynos_dp.o: in function `exynos_dp_resume':
> exynos_dp.c:(.text+0xc0): undefined reference to `analogix_dp_resume'
> aarch64-linux-ld: drivers/gpu/drm/exynos/exynos_dp.o: in function `exynos_dp_suspend':
> exynos_dp.c:(.text+0xf4): undefined reference to `analogix_dp_suspend'
>
> [...]
Applied to misc/kernel.git (drm-misc-next).
Thanks!
Maxime
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v2 0/5] Rework SCMI Clock driver clk_ops setup procedure
From: Sudeep Holla @ 2024-04-04 14:25 UTC (permalink / raw)
To: mturquette, sboyd
Cc: Cristian Marussi, Sudeep Holla, linux-kernel, linux-arm-kernel,
linux-clk, james.quinlan, f.fainelli, vincent.guittot, peng.fan,
michal.simek, quic_sibis, quic_nkela, souvik.chakravarty
In-Reply-To: <20240325210025.1448717-1-cristian.marussi@arm.com>
Hi Stephen,
On Mon, Mar 25, 2024 at 09:00:20PM +0000, Cristian Marussi wrote:
> Hi,
>
[...]
>
> This rework introduces a dynamic allocation mechanism to be able to
> configure the required clk_ops at run-time when the SCMI clocks are
> enumerated.
>
> Only one single clk_ops is generated for each of the features combinations
> effectively found in the set of returned SCMI resources.
>
> Once this preliminary rework is done in 1/5, the following patches use this
> new clk_ops schema to introduce a number of restricted clk_ops depending on
> the specific retrieved SCMI clocks characteristics.
>
Let me know if you are happy with this changes. There is no strict
dependency on the changes in SCMI tree ATM, so I can provide reviewed-by
if you would like to take it via clk tree. If you prefer me to take it
via SCMI tree, please provide Ack if you are OK with the changes.
--
Regards,
Sudeep
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH v2 0/4] Speed up boot with faster linear map creation
From: Ryan Roberts @ 2024-04-04 14:33 UTC (permalink / raw)
To: Catalin Marinas, Will Deacon, Mark Rutland, Ard Biesheuvel,
David Hildenbrand, Donald Dutile, Eric Chanudet
Cc: Ryan Roberts, linux-arm-kernel, linux-kernel
Hi All,
It turns out that creating the linear map can take a significant proportion of
the total boot time, especially when rodata=full. And most of the time is spent
waiting on superfluous tlb invalidation and memory barriers. This series reworks
the kernel pgtable generation code to significantly reduce the number of those
TLBIs, ISBs and DSBs. See each patch for details.
The below shows the execution time of map_mem() across a couple of different
systems with different RAM configurations. We measure after applying each patch
and show the improvement relative to base (v6.9-rc2):
| Apple M2 VM | Ampere Altra| Ampere Altra| Ampere Altra
| VM, 16G | VM, 64G | VM, 256G | Metal, 512G
---------------|-------------|-------------|-------------|-------------
| ms (%) | ms (%) | ms (%) | ms (%)
---------------|-------------|-------------|-------------|-------------
base | 153 (0%) | 2227 (0%) | 8798 (0%) | 17442 (0%)
no-cont-remap | 77 (-49%) | 431 (-81%) | 1727 (-80%) | 3796 (-78%)
batch-barriers | 13 (-92%) | 162 (-93%) | 655 (-93%) | 1656 (-91%)
no-alloc-remap | 11 (-93%) | 109 (-95%) | 449 (-95%) | 1257 (-93%)
lazy-unmap | 6 (-96%) | 61 (-97%) | 257 (-97%) | 838 (-95%)
This series applies on top of v6.9-rc2. All mm selftests pass. I've compile and
boot tested various PAGE_SIZE and VA size configs.
---
Changes since v1 [1]
====================
- Added Tested-by tags (thanks to Eric and Itaru)
- Renamed ___set_pte() -> __set_pte_nosync() (per Ard)
- Reordered patches (biggest impact & least controversial first)
- Reordered alloc/map/unmap functions in mmu.c to aid reader
- pte_clear() -> __pte_clear() in clear_fixmap_nosync()
- Reverted generic p4d_index() which caused x86 build error. Replaced with
unconditional p4d_index() define under arm64.
[1] https://lore.kernel.org/linux-arm-kernel/20240326101448.3453626-1-ryan.roberts@arm.com/
Thanks,
Ryan
Ryan Roberts (4):
arm64: mm: Don't remap pgtables per-cont(pte|pmd) block
arm64: mm: Batch dsb and isb when populating pgtables
arm64: mm: Don't remap pgtables for allocate vs populate
arm64: mm: Lazily clear pte table mappings from fixmap
arch/arm64/include/asm/fixmap.h | 5 +-
arch/arm64/include/asm/mmu.h | 8 +
arch/arm64/include/asm/pgtable.h | 13 +-
arch/arm64/kernel/cpufeature.c | 10 +-
arch/arm64/mm/fixmap.c | 11 +
arch/arm64/mm/mmu.c | 377 +++++++++++++++++++++++--------
6 files changed, 319 insertions(+), 105 deletions(-)
--
2.25.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH v2 2/4] arm64: mm: Batch dsb and isb when populating pgtables
From: Ryan Roberts @ 2024-04-04 14:33 UTC (permalink / raw)
To: Catalin Marinas, Will Deacon, Mark Rutland, Ard Biesheuvel,
David Hildenbrand, Donald Dutile, Eric Chanudet
Cc: Ryan Roberts, linux-arm-kernel, linux-kernel, Itaru Kitayama
In-Reply-To: <20240404143308.2224141-1-ryan.roberts@arm.com>
After removing uneccessary TLBIs, the next bottleneck when creating the
page tables for the linear map is DSB and ISB, which were previously
issued per-pte in __set_pte(). Since we are writing multiple ptes in a
given pte table, we can elide these barriers and insert them once we
have finished writing to the table.
Execution time of map_mem(), which creates the kernel linear map page
tables, was measured on different machines with different RAM configs:
| Apple M2 VM | Ampere Altra| Ampere Altra| Ampere Altra
| VM, 16G | VM, 64G | VM, 256G | Metal, 512G
---------------|-------------|-------------|-------------|-------------
| ms (%) | ms (%) | ms (%) | ms (%)
---------------|-------------|-------------|-------------|-------------
before | 77 (0%) | 431 (0%) | 1727 (0%) | 3796 (0%)
after | 13 (-84%) | 162 (-62%) | 655 (-62%) | 1656 (-56%)
Signed-off-by: Ryan Roberts <ryan.roberts@arm.com>
Tested-by: Itaru Kitayama <itaru.kitayama@fujitsu.com>
Tested-by: Eric Chanudet <echanude@redhat.com>
---
arch/arm64/include/asm/pgtable.h | 7 ++++++-
arch/arm64/mm/mmu.c | 13 ++++++++++++-
2 files changed, 18 insertions(+), 2 deletions(-)
diff --git a/arch/arm64/include/asm/pgtable.h b/arch/arm64/include/asm/pgtable.h
index afdd56d26ad7..105a95a8845c 100644
--- a/arch/arm64/include/asm/pgtable.h
+++ b/arch/arm64/include/asm/pgtable.h
@@ -271,9 +271,14 @@ static inline pte_t pte_mkdevmap(pte_t pte)
return set_pte_bit(pte, __pgprot(PTE_DEVMAP | PTE_SPECIAL));
}
-static inline void __set_pte(pte_t *ptep, pte_t pte)
+static inline void __set_pte_nosync(pte_t *ptep, pte_t pte)
{
WRITE_ONCE(*ptep, pte);
+}
+
+static inline void __set_pte(pte_t *ptep, pte_t pte)
+{
+ __set_pte_nosync(ptep, pte);
/*
* Only if the new pte is valid and kernel, otherwise TLB maintenance
diff --git a/arch/arm64/mm/mmu.c b/arch/arm64/mm/mmu.c
index fd91b5bdb514..dc86dceb0efe 100644
--- a/arch/arm64/mm/mmu.c
+++ b/arch/arm64/mm/mmu.c
@@ -178,7 +178,11 @@ static pte_t *init_pte(pte_t *ptep, unsigned long addr, unsigned long end,
do {
pte_t old_pte = __ptep_get(ptep);
- __set_pte(ptep, pfn_pte(__phys_to_pfn(phys), prot));
+ /*
+ * Required barriers to make this visible to the table walker
+ * are deferred to the end of alloc_init_cont_pte().
+ */
+ __set_pte_nosync(ptep, pfn_pte(__phys_to_pfn(phys), prot));
/*
* After the PTE entry has been populated once, we
@@ -234,6 +238,13 @@ static void alloc_init_cont_pte(pmd_t *pmdp, unsigned long addr,
} while (addr = next, addr != end);
pte_clear_fixmap();
+
+ /*
+ * Ensure all previous pgtable writes are visible to the table walker.
+ * See init_pte().
+ */
+ dsb(ishst);
+ isb();
}
static pmd_t *init_pmd(pmd_t *pmdp, unsigned long addr, unsigned long end,
--
2.25.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH v2 1/4] arm64: mm: Don't remap pgtables per-cont(pte|pmd) block
From: Ryan Roberts @ 2024-04-04 14:33 UTC (permalink / raw)
To: Catalin Marinas, Will Deacon, Mark Rutland, Ard Biesheuvel,
David Hildenbrand, Donald Dutile, Eric Chanudet
Cc: Ryan Roberts, linux-arm-kernel, linux-kernel, Itaru Kitayama
In-Reply-To: <20240404143308.2224141-1-ryan.roberts@arm.com>
A large part of the kernel boot time is creating the kernel linear map
page tables. When rodata=full, all memory is mapped by pte. And when
there is lots of physical ram, there are lots of pte tables to populate.
The primary cost associated with this is mapping and unmapping the pte
table memory in the fixmap; at unmap time, the TLB entry must be
invalidated and this is expensive.
Previously, each pmd and pte table was fixmapped/fixunmapped for each
cont(pte|pmd) block of mappings (16 entries with 4K granule). This means
we ended up issuing 32 TLBIs per (pmd|pte) table during the population
phase.
Let's fix that, and fixmap/fixunmap each page once per population, for a
saving of 31 TLBIs per (pmd|pte) table. This gives a significant boot
speedup.
Execution time of map_mem(), which creates the kernel linear map page
tables, was measured on different machines with different RAM configs:
| Apple M2 VM | Ampere Altra| Ampere Altra| Ampere Altra
| VM, 16G | VM, 64G | VM, 256G | Metal, 512G
---------------|-------------|-------------|-------------|-------------
| ms (%) | ms (%) | ms (%) | ms (%)
---------------|-------------|-------------|-------------|-------------
before | 153 (0%) | 2227 (0%) | 8798 (0%) | 17442 (0%)
after | 77 (-49%) | 431 (-81%) | 1727 (-80%) | 3796 (-78%)
Signed-off-by: Ryan Roberts <ryan.roberts@arm.com>
Tested-by: Itaru Kitayama <itaru.kitayama@fujitsu.com>
Tested-by: Eric Chanudet <echanude@redhat.com>
---
arch/arm64/mm/mmu.c | 32 ++++++++++++++++++--------------
1 file changed, 18 insertions(+), 14 deletions(-)
diff --git a/arch/arm64/mm/mmu.c b/arch/arm64/mm/mmu.c
index 495b732d5af3..fd91b5bdb514 100644
--- a/arch/arm64/mm/mmu.c
+++ b/arch/arm64/mm/mmu.c
@@ -172,12 +172,9 @@ bool pgattr_change_is_safe(u64 old, u64 new)
return ((old ^ new) & ~mask) == 0;
}
-static void init_pte(pmd_t *pmdp, unsigned long addr, unsigned long end,
- phys_addr_t phys, pgprot_t prot)
+static pte_t *init_pte(pte_t *ptep, unsigned long addr, unsigned long end,
+ phys_addr_t phys, pgprot_t prot)
{
- pte_t *ptep;
-
- ptep = pte_set_fixmap_offset(pmdp, addr);
do {
pte_t old_pte = __ptep_get(ptep);
@@ -193,7 +190,7 @@ static void init_pte(pmd_t *pmdp, unsigned long addr, unsigned long end,
phys += PAGE_SIZE;
} while (ptep++, addr += PAGE_SIZE, addr != end);
- pte_clear_fixmap();
+ return ptep;
}
static void alloc_init_cont_pte(pmd_t *pmdp, unsigned long addr,
@@ -204,6 +201,7 @@ static void alloc_init_cont_pte(pmd_t *pmdp, unsigned long addr,
{
unsigned long next;
pmd_t pmd = READ_ONCE(*pmdp);
+ pte_t *ptep;
BUG_ON(pmd_sect(pmd));
if (pmd_none(pmd)) {
@@ -219,6 +217,7 @@ static void alloc_init_cont_pte(pmd_t *pmdp, unsigned long addr,
}
BUG_ON(pmd_bad(pmd));
+ ptep = pte_set_fixmap_offset(pmdp, addr);
do {
pgprot_t __prot = prot;
@@ -229,20 +228,20 @@ static void alloc_init_cont_pte(pmd_t *pmdp, unsigned long addr,
(flags & NO_CONT_MAPPINGS) == 0)
__prot = __pgprot(pgprot_val(prot) | PTE_CONT);
- init_pte(pmdp, addr, next, phys, __prot);
+ ptep = init_pte(ptep, addr, next, phys, __prot);
phys += next - addr;
} while (addr = next, addr != end);
+
+ pte_clear_fixmap();
}
-static void init_pmd(pud_t *pudp, unsigned long addr, unsigned long end,
- phys_addr_t phys, pgprot_t prot,
- phys_addr_t (*pgtable_alloc)(int), int flags)
+static pmd_t *init_pmd(pmd_t *pmdp, unsigned long addr, unsigned long end,
+ phys_addr_t phys, pgprot_t prot,
+ phys_addr_t (*pgtable_alloc)(int), int flags)
{
unsigned long next;
- pmd_t *pmdp;
- pmdp = pmd_set_fixmap_offset(pudp, addr);
do {
pmd_t old_pmd = READ_ONCE(*pmdp);
@@ -269,7 +268,7 @@ static void init_pmd(pud_t *pudp, unsigned long addr, unsigned long end,
phys += next - addr;
} while (pmdp++, addr = next, addr != end);
- pmd_clear_fixmap();
+ return pmdp;
}
static void alloc_init_cont_pmd(pud_t *pudp, unsigned long addr,
@@ -279,6 +278,7 @@ static void alloc_init_cont_pmd(pud_t *pudp, unsigned long addr,
{
unsigned long next;
pud_t pud = READ_ONCE(*pudp);
+ pmd_t *pmdp;
/*
* Check for initial section mappings in the pgd/pud.
@@ -297,6 +297,7 @@ static void alloc_init_cont_pmd(pud_t *pudp, unsigned long addr,
}
BUG_ON(pud_bad(pud));
+ pmdp = pmd_set_fixmap_offset(pudp, addr);
do {
pgprot_t __prot = prot;
@@ -307,10 +308,13 @@ static void alloc_init_cont_pmd(pud_t *pudp, unsigned long addr,
(flags & NO_CONT_MAPPINGS) == 0)
__prot = __pgprot(pgprot_val(prot) | PTE_CONT);
- init_pmd(pudp, addr, next, phys, __prot, pgtable_alloc, flags);
+ pmdp = init_pmd(pmdp, addr, next, phys, __prot, pgtable_alloc,
+ flags);
phys += next - addr;
} while (addr = next, addr != end);
+
+ pmd_clear_fixmap();
}
static void alloc_init_pud(p4d_t *p4dp, unsigned long addr, unsigned long end,
--
2.25.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH v2 3/4] arm64: mm: Don't remap pgtables for allocate vs populate
From: Ryan Roberts @ 2024-04-04 14:33 UTC (permalink / raw)
To: Catalin Marinas, Will Deacon, Mark Rutland, Ard Biesheuvel,
David Hildenbrand, Donald Dutile, Eric Chanudet
Cc: Ryan Roberts, linux-arm-kernel, linux-kernel, Itaru Kitayama
In-Reply-To: <20240404143308.2224141-1-ryan.roberts@arm.com>
During linear map pgtable creation, each pgtable is fixmapped /
fixunmapped twice; once during allocation to zero the memory, and a
again during population to write the entries. This means each table has
2 TLB invalidations issued against it. Let's fix this so that each table
is only fixmapped/fixunmapped once, halving the number of TLBIs, and
improving performance.
Achieve this by abstracting pgtable allocate, map and unmap operations
out of the main pgtable population loop code and into a `struct
pgtable_ops` function pointer structure. This allows us to formalize the
semantics of "alloc" to mean "alloc and map", requiring an "unmap" when
finished. So "map" is only performed (and also matched by "unmap") if
the pgtable has already been allocated.
As a side effect of this refactoring, we no longer need to use the
fixmap at all once pages have been mapped in the linear map because
their "map" operation can simply do a __va() translation. So with this
change, we are down to 1 TLBI per table when doing early pgtable
manipulations, and 0 TLBIs when doing late pgtable manipulations.
Execution time of map_mem(), which creates the kernel linear map page
tables, was measured on different machines with different RAM configs:
| Apple M2 VM | Ampere Altra| Ampere Altra| Ampere Altra
| VM, 16G | VM, 64G | VM, 256G | Metal, 512G
---------------|-------------|-------------|-------------|-------------
| ms (%) | ms (%) | ms (%) | ms (%)
---------------|-------------|-------------|-------------|-------------
before | 13 (0%) | 162 (0%) | 655 (0%) | 1656 (0%)
after | 11 (-15%) | 109 (-33%) | 449 (-31%) | 1257 (-24%)
Signed-off-by: Ryan Roberts <ryan.roberts@arm.com>
Tested-by: Itaru Kitayama <itaru.kitayama@fujitsu.com>
Tested-by: Eric Chanudet <echanude@redhat.com>
---
arch/arm64/include/asm/mmu.h | 8 +
arch/arm64/include/asm/pgtable.h | 2 +
arch/arm64/kernel/cpufeature.c | 10 +-
arch/arm64/mm/mmu.c | 308 ++++++++++++++++++++++---------
4 files changed, 237 insertions(+), 91 deletions(-)
diff --git a/arch/arm64/include/asm/mmu.h b/arch/arm64/include/asm/mmu.h
index 65977c7783c5..ae44353010e8 100644
--- a/arch/arm64/include/asm/mmu.h
+++ b/arch/arm64/include/asm/mmu.h
@@ -109,6 +109,14 @@ static inline bool kaslr_requires_kpti(void)
return true;
}
+#ifdef CONFIG_UNMAP_KERNEL_AT_EL0
+extern
+void create_kpti_ng_temp_pgd(pgd_t *pgdir, phys_addr_t phys, unsigned long virt,
+ phys_addr_t size, pgprot_t prot,
+ void *(*pgtable_alloc)(int, phys_addr_t *),
+ int flags);
+#endif
+
#define INIT_MM_CONTEXT(name) \
.pgd = swapper_pg_dir,
diff --git a/arch/arm64/include/asm/pgtable.h b/arch/arm64/include/asm/pgtable.h
index 105a95a8845c..92c9aed5e7af 100644
--- a/arch/arm64/include/asm/pgtable.h
+++ b/arch/arm64/include/asm/pgtable.h
@@ -1010,6 +1010,8 @@ static inline p4d_t *p4d_offset_kimg(pgd_t *pgdp, u64 addr)
static inline bool pgtable_l5_enabled(void) { return false; }
+#define p4d_index(addr) (((addr) >> P4D_SHIFT) & (PTRS_PER_P4D - 1))
+
/* Match p4d_offset folding in <asm/generic/pgtable-nop4d.h> */
#define p4d_set_fixmap(addr) NULL
#define p4d_set_fixmap_offset(p4dp, addr) ((p4d_t *)p4dp)
diff --git a/arch/arm64/kernel/cpufeature.c b/arch/arm64/kernel/cpufeature.c
index 56583677c1f2..9a70b1954706 100644
--- a/arch/arm64/kernel/cpufeature.c
+++ b/arch/arm64/kernel/cpufeature.c
@@ -1866,17 +1866,13 @@ static bool has_lpa2(const struct arm64_cpu_capabilities *entry, int scope)
#ifdef CONFIG_UNMAP_KERNEL_AT_EL0
#define KPTI_NG_TEMP_VA (-(1UL << PMD_SHIFT))
-extern
-void create_kpti_ng_temp_pgd(pgd_t *pgdir, phys_addr_t phys, unsigned long virt,
- phys_addr_t size, pgprot_t prot,
- phys_addr_t (*pgtable_alloc)(int), int flags);
-
static phys_addr_t __initdata kpti_ng_temp_alloc;
-static phys_addr_t __init kpti_ng_pgd_alloc(int shift)
+static void *__init kpti_ng_pgd_alloc(int type, phys_addr_t *pa)
{
kpti_ng_temp_alloc -= PAGE_SIZE;
- return kpti_ng_temp_alloc;
+ *pa = kpti_ng_temp_alloc;
+ return __va(kpti_ng_temp_alloc);
}
static int __init __kpti_install_ng_mappings(void *__unused)
diff --git a/arch/arm64/mm/mmu.c b/arch/arm64/mm/mmu.c
index dc86dceb0efe..90bf822859b8 100644
--- a/arch/arm64/mm/mmu.c
+++ b/arch/arm64/mm/mmu.c
@@ -41,9 +41,42 @@
#include <asm/pgalloc.h>
#include <asm/kfence.h>
+enum pgtable_type {
+ TYPE_P4D = 0,
+ TYPE_PUD = 1,
+ TYPE_PMD = 2,
+ TYPE_PTE = 3,
+};
+
+/**
+ * struct pgtable_ops - Ops to allocate and access pgtable memory. Calls must be
+ * serialized by the caller.
+ * @alloc: Allocates 1 page of memory for use as pgtable `type` and maps it
+ * into va space. Returned memory is zeroed. Puts physical address
+ * of page in *pa, and returns virtual address of the mapping. User
+ * must explicitly unmap() before doing another alloc() or map() of
+ * the same `type`.
+ * @map: Determines the physical address of the pgtable of `type` by
+ * interpretting `parent` as the pgtable entry for the next level
+ * up. Maps the page and returns virtual address of the pgtable
+ * entry within the table that corresponds to `addr`. User must
+ * explicitly unmap() before doing another alloc() or map() of the
+ * same `type`.
+ * @unmap: Unmap the currently mapped page of `type`, which will have been
+ * mapped either as a result of a previous call to alloc() or
+ * map(). The page's virtual address must be considered invalid
+ * after this call returns.
+ */
+struct pgtable_ops {
+ void *(*alloc)(int type, phys_addr_t *pa);
+ void *(*map)(int type, void *parent, unsigned long addr);
+ void (*unmap)(int type);
+};
+
#define NO_BLOCK_MAPPINGS BIT(0)
#define NO_CONT_MAPPINGS BIT(1)
#define NO_EXEC_MAPPINGS BIT(2) /* assumes FEAT_HPDS is not used */
+#define NO_ALLOC BIT(3)
u64 kimage_voffset __ro_after_init;
EXPORT_SYMBOL(kimage_voffset);
@@ -106,34 +139,89 @@ pgprot_t phys_mem_access_prot(struct file *file, unsigned long pfn,
}
EXPORT_SYMBOL(phys_mem_access_prot);
-static phys_addr_t __init early_pgtable_alloc(int shift)
+static void *__init early_pgtable_alloc(int type, phys_addr_t *pa)
{
- phys_addr_t phys;
- void *ptr;
+ void *va;
- phys = memblock_phys_alloc_range(PAGE_SIZE, PAGE_SIZE, 0,
- MEMBLOCK_ALLOC_NOLEAKTRACE);
- if (!phys)
+ *pa = memblock_phys_alloc_range(PAGE_SIZE, PAGE_SIZE, 0,
+ MEMBLOCK_ALLOC_NOLEAKTRACE);
+ if (!*pa)
panic("Failed to allocate page table page\n");
- /*
- * The FIX_{PGD,PUD,PMD} slots may be in active use, but the FIX_PTE
- * slot will be free, so we can (ab)use the FIX_PTE slot to initialise
- * any level of table.
- */
- ptr = pte_set_fixmap(phys);
+ switch (type) {
+ case TYPE_P4D:
+ va = p4d_set_fixmap(*pa);
+ break;
+ case TYPE_PUD:
+ va = pud_set_fixmap(*pa);
+ break;
+ case TYPE_PMD:
+ va = pmd_set_fixmap(*pa);
+ break;
+ case TYPE_PTE:
+ va = pte_set_fixmap(*pa);
+ break;
+ default:
+ BUG();
+ }
+ memset(va, 0, PAGE_SIZE);
- memset(ptr, 0, PAGE_SIZE);
+ /* Ensure the zeroed page is visible to the page table walker */
+ dsb(ishst);
- /*
- * Implicit barriers also ensure the zeroed page is visible to the page
- * table walker
- */
- pte_clear_fixmap();
+ return va;
+}
+
+static void *__init early_pgtable_map(int type, void *parent, unsigned long addr)
+{
+ void *entry;
+
+ switch (type) {
+ case TYPE_P4D:
+ entry = p4d_set_fixmap_offset((pgd_t *)parent, addr);
+ break;
+ case TYPE_PUD:
+ entry = pud_set_fixmap_offset((p4d_t *)parent, addr);
+ break;
+ case TYPE_PMD:
+ entry = pmd_set_fixmap_offset((pud_t *)parent, addr);
+ break;
+ case TYPE_PTE:
+ entry = pte_set_fixmap_offset((pmd_t *)parent, addr);
+ break;
+ default:
+ BUG();
+ }
- return phys;
+ return entry;
+}
+
+static void __init early_pgtable_unmap(int type)
+{
+ switch (type) {
+ case TYPE_P4D:
+ p4d_clear_fixmap();
+ break;
+ case TYPE_PUD:
+ pud_clear_fixmap();
+ break;
+ case TYPE_PMD:
+ pmd_clear_fixmap();
+ break;
+ case TYPE_PTE:
+ pte_clear_fixmap();
+ break;
+ default:
+ BUG();
+ }
}
+static struct pgtable_ops early_pgtable_ops __initdata = {
+ .alloc = early_pgtable_alloc,
+ .map = early_pgtable_map,
+ .unmap = early_pgtable_unmap,
+};
+
bool pgattr_change_is_safe(u64 old, u64 new)
{
/*
@@ -200,7 +288,7 @@ static pte_t *init_pte(pte_t *ptep, unsigned long addr, unsigned long end,
static void alloc_init_cont_pte(pmd_t *pmdp, unsigned long addr,
unsigned long end, phys_addr_t phys,
pgprot_t prot,
- phys_addr_t (*pgtable_alloc)(int),
+ struct pgtable_ops *ops,
int flags)
{
unsigned long next;
@@ -214,14 +302,15 @@ static void alloc_init_cont_pte(pmd_t *pmdp, unsigned long addr,
if (flags & NO_EXEC_MAPPINGS)
pmdval |= PMD_TABLE_PXN;
- BUG_ON(!pgtable_alloc);
- pte_phys = pgtable_alloc(PAGE_SHIFT);
+ BUG_ON(flags & NO_ALLOC);
+ ptep = ops->alloc(TYPE_PTE, &pte_phys);
+ ptep += pte_index(addr);
__pmd_populate(pmdp, pte_phys, pmdval);
- pmd = READ_ONCE(*pmdp);
+ } else {
+ BUG_ON(pmd_bad(pmd));
+ ptep = ops->map(TYPE_PTE, pmdp, addr);
}
- BUG_ON(pmd_bad(pmd));
- ptep = pte_set_fixmap_offset(pmdp, addr);
do {
pgprot_t __prot = prot;
@@ -237,7 +326,7 @@ static void alloc_init_cont_pte(pmd_t *pmdp, unsigned long addr,
phys += next - addr;
} while (addr = next, addr != end);
- pte_clear_fixmap();
+ ops->unmap(TYPE_PTE);
/*
* Ensure all previous pgtable writes are visible to the table walker.
@@ -249,7 +338,7 @@ static void alloc_init_cont_pte(pmd_t *pmdp, unsigned long addr,
static pmd_t *init_pmd(pmd_t *pmdp, unsigned long addr, unsigned long end,
phys_addr_t phys, pgprot_t prot,
- phys_addr_t (*pgtable_alloc)(int), int flags)
+ struct pgtable_ops *ops, int flags)
{
unsigned long next;
@@ -271,7 +360,7 @@ static pmd_t *init_pmd(pmd_t *pmdp, unsigned long addr, unsigned long end,
READ_ONCE(pmd_val(*pmdp))));
} else {
alloc_init_cont_pte(pmdp, addr, next, phys, prot,
- pgtable_alloc, flags);
+ ops, flags);
BUG_ON(pmd_val(old_pmd) != 0 &&
pmd_val(old_pmd) != READ_ONCE(pmd_val(*pmdp)));
@@ -285,7 +374,7 @@ static pmd_t *init_pmd(pmd_t *pmdp, unsigned long addr, unsigned long end,
static void alloc_init_cont_pmd(pud_t *pudp, unsigned long addr,
unsigned long end, phys_addr_t phys,
pgprot_t prot,
- phys_addr_t (*pgtable_alloc)(int), int flags)
+ struct pgtable_ops *ops, int flags)
{
unsigned long next;
pud_t pud = READ_ONCE(*pudp);
@@ -301,14 +390,15 @@ static void alloc_init_cont_pmd(pud_t *pudp, unsigned long addr,
if (flags & NO_EXEC_MAPPINGS)
pudval |= PUD_TABLE_PXN;
- BUG_ON(!pgtable_alloc);
- pmd_phys = pgtable_alloc(PMD_SHIFT);
+ BUG_ON(flags & NO_ALLOC);
+ pmdp = ops->alloc(TYPE_PMD, &pmd_phys);
+ pmdp += pmd_index(addr);
__pud_populate(pudp, pmd_phys, pudval);
- pud = READ_ONCE(*pudp);
+ } else {
+ BUG_ON(pud_bad(pud));
+ pmdp = ops->map(TYPE_PMD, pudp, addr);
}
- BUG_ON(pud_bad(pud));
- pmdp = pmd_set_fixmap_offset(pudp, addr);
do {
pgprot_t __prot = prot;
@@ -319,18 +409,17 @@ static void alloc_init_cont_pmd(pud_t *pudp, unsigned long addr,
(flags & NO_CONT_MAPPINGS) == 0)
__prot = __pgprot(pgprot_val(prot) | PTE_CONT);
- pmdp = init_pmd(pmdp, addr, next, phys, __prot, pgtable_alloc,
- flags);
+ pmdp = init_pmd(pmdp, addr, next, phys, __prot, ops, flags);
phys += next - addr;
} while (addr = next, addr != end);
- pmd_clear_fixmap();
+ ops->unmap(TYPE_PMD);
}
static void alloc_init_pud(p4d_t *p4dp, unsigned long addr, unsigned long end,
phys_addr_t phys, pgprot_t prot,
- phys_addr_t (*pgtable_alloc)(int),
+ struct pgtable_ops *ops,
int flags)
{
unsigned long next;
@@ -343,14 +432,15 @@ static void alloc_init_pud(p4d_t *p4dp, unsigned long addr, unsigned long end,
if (flags & NO_EXEC_MAPPINGS)
p4dval |= P4D_TABLE_PXN;
- BUG_ON(!pgtable_alloc);
- pud_phys = pgtable_alloc(PUD_SHIFT);
+ BUG_ON(flags & NO_ALLOC);
+ pudp = ops->alloc(TYPE_PUD, &pud_phys);
+ pudp += pud_index(addr);
__p4d_populate(p4dp, pud_phys, p4dval);
- p4d = READ_ONCE(*p4dp);
+ } else {
+ BUG_ON(p4d_bad(p4d));
+ pudp = ops->map(TYPE_PUD, p4dp, addr);
}
- BUG_ON(p4d_bad(p4d));
- pudp = pud_set_fixmap_offset(p4dp, addr);
do {
pud_t old_pud = READ_ONCE(*pudp);
@@ -372,7 +462,7 @@ static void alloc_init_pud(p4d_t *p4dp, unsigned long addr, unsigned long end,
READ_ONCE(pud_val(*pudp))));
} else {
alloc_init_cont_pmd(pudp, addr, next, phys, prot,
- pgtable_alloc, flags);
+ ops, flags);
BUG_ON(pud_val(old_pud) != 0 &&
pud_val(old_pud) != READ_ONCE(pud_val(*pudp)));
@@ -380,12 +470,12 @@ static void alloc_init_pud(p4d_t *p4dp, unsigned long addr, unsigned long end,
phys += next - addr;
} while (pudp++, addr = next, addr != end);
- pud_clear_fixmap();
+ ops->unmap(TYPE_PUD);
}
static void alloc_init_p4d(pgd_t *pgdp, unsigned long addr, unsigned long end,
phys_addr_t phys, pgprot_t prot,
- phys_addr_t (*pgtable_alloc)(int),
+ struct pgtable_ops *ops,
int flags)
{
unsigned long next;
@@ -398,21 +488,21 @@ static void alloc_init_p4d(pgd_t *pgdp, unsigned long addr, unsigned long end,
if (flags & NO_EXEC_MAPPINGS)
pgdval |= PGD_TABLE_PXN;
- BUG_ON(!pgtable_alloc);
- p4d_phys = pgtable_alloc(P4D_SHIFT);
+ BUG_ON(flags & NO_ALLOC);
+ p4dp = ops->alloc(TYPE_P4D, &p4d_phys);
+ p4dp += p4d_index(addr);
__pgd_populate(pgdp, p4d_phys, pgdval);
- pgd = READ_ONCE(*pgdp);
+ } else {
+ BUG_ON(pgd_bad(pgd));
+ p4dp = ops->map(TYPE_P4D, pgdp, addr);
}
- BUG_ON(pgd_bad(pgd));
- p4dp = p4d_set_fixmap_offset(pgdp, addr);
do {
p4d_t old_p4d = READ_ONCE(*p4dp);
next = p4d_addr_end(addr, end);
- alloc_init_pud(p4dp, addr, next, phys, prot,
- pgtable_alloc, flags);
+ alloc_init_pud(p4dp, addr, next, phys, prot, ops, flags);
BUG_ON(p4d_val(old_p4d) != 0 &&
p4d_val(old_p4d) != READ_ONCE(p4d_val(*p4dp)));
@@ -420,13 +510,13 @@ static void alloc_init_p4d(pgd_t *pgdp, unsigned long addr, unsigned long end,
phys += next - addr;
} while (p4dp++, addr = next, addr != end);
- p4d_clear_fixmap();
+ ops->unmap(TYPE_P4D);
}
static void __create_pgd_mapping_locked(pgd_t *pgdir, phys_addr_t phys,
unsigned long virt, phys_addr_t size,
pgprot_t prot,
- phys_addr_t (*pgtable_alloc)(int),
+ struct pgtable_ops *ops,
int flags)
{
unsigned long addr, end, next;
@@ -445,8 +535,7 @@ static void __create_pgd_mapping_locked(pgd_t *pgdir, phys_addr_t phys,
do {
next = pgd_addr_end(addr, end);
- alloc_init_p4d(pgdp, addr, next, phys, prot, pgtable_alloc,
- flags);
+ alloc_init_p4d(pgdp, addr, next, phys, prot, ops, flags);
phys += next - addr;
} while (pgdp++, addr = next, addr != end);
}
@@ -454,36 +543,31 @@ static void __create_pgd_mapping_locked(pgd_t *pgdir, phys_addr_t phys,
static void __create_pgd_mapping(pgd_t *pgdir, phys_addr_t phys,
unsigned long virt, phys_addr_t size,
pgprot_t prot,
- phys_addr_t (*pgtable_alloc)(int),
+ struct pgtable_ops *ops,
int flags)
{
mutex_lock(&fixmap_lock);
__create_pgd_mapping_locked(pgdir, phys, virt, size, prot,
- pgtable_alloc, flags);
+ ops, flags);
mutex_unlock(&fixmap_lock);
}
-#ifdef CONFIG_UNMAP_KERNEL_AT_EL0
-extern __alias(__create_pgd_mapping_locked)
-void create_kpti_ng_temp_pgd(pgd_t *pgdir, phys_addr_t phys, unsigned long virt,
- phys_addr_t size, pgprot_t prot,
- phys_addr_t (*pgtable_alloc)(int), int flags);
-#endif
-
-static phys_addr_t __pgd_pgtable_alloc(int shift)
+static void *__pgd_pgtable_alloc(int type, phys_addr_t *pa)
{
- void *ptr = (void *)__get_free_page(GFP_PGTABLE_KERNEL);
- BUG_ON(!ptr);
+ void *va = (void *)__get_free_page(GFP_PGTABLE_KERNEL);
+
+ BUG_ON(!va);
/* Ensure the zeroed page is visible to the page table walker */
dsb(ishst);
- return __pa(ptr);
+ *pa = __pa(va);
+ return va;
}
-static phys_addr_t pgd_pgtable_alloc(int shift)
+static void *pgd_pgtable_alloc(int type, phys_addr_t *pa)
{
- phys_addr_t pa = __pgd_pgtable_alloc(shift);
- struct ptdesc *ptdesc = page_ptdesc(phys_to_page(pa));
+ void *va = __pgd_pgtable_alloc(type, pa);
+ struct ptdesc *ptdesc = page_ptdesc(phys_to_page(*pa));
/*
* Call proper page table ctor in case later we need to
@@ -493,13 +577,69 @@ static phys_addr_t pgd_pgtable_alloc(int shift)
* We don't select ARCH_ENABLE_SPLIT_PMD_PTLOCK if pmd is
* folded, and if so pagetable_pte_ctor() becomes nop.
*/
- if (shift == PAGE_SHIFT)
+ if (type == TYPE_PTE)
BUG_ON(!pagetable_pte_ctor(ptdesc));
- else if (shift == PMD_SHIFT)
+ else if (type == TYPE_PMD)
BUG_ON(!pagetable_pmd_ctor(ptdesc));
- return pa;
+ return va;
+}
+
+static void *pgd_pgtable_map(int type, void *parent, unsigned long addr)
+{
+ void *entry;
+
+ switch (type) {
+ case TYPE_P4D:
+ entry = p4d_offset((pgd_t *)parent, addr);
+ break;
+ case TYPE_PUD:
+ entry = pud_offset((p4d_t *)parent, addr);
+ break;
+ case TYPE_PMD:
+ entry = pmd_offset((pud_t *)parent, addr);
+ break;
+ case TYPE_PTE:
+ entry = pte_offset_kernel((pmd_t *)parent, addr);
+ break;
+ default:
+ BUG();
+ }
+
+ return entry;
+}
+
+static void pgd_pgtable_unmap(int type)
+{
+}
+
+static struct pgtable_ops pgd_pgtable_ops = {
+ .alloc = pgd_pgtable_alloc,
+ .map = pgd_pgtable_map,
+ .unmap = pgd_pgtable_unmap,
+};
+
+static struct pgtable_ops __pgd_pgtable_ops = {
+ .alloc = __pgd_pgtable_alloc,
+ .map = pgd_pgtable_map,
+ .unmap = pgd_pgtable_unmap,
+};
+
+#ifdef CONFIG_UNMAP_KERNEL_AT_EL0
+void create_kpti_ng_temp_pgd(pgd_t *pgdir, phys_addr_t phys, unsigned long virt,
+ phys_addr_t size, pgprot_t prot,
+ void *(*pgtable_alloc)(int, phys_addr_t *),
+ int flags)
+{
+ struct pgtable_ops ops = {
+ .alloc = pgtable_alloc,
+ .map = pgd_pgtable_map,
+ .unmap = pgd_pgtable_unmap,
+ };
+
+ __create_pgd_mapping_locked(pgdir, phys, virt, size, prot, &ops, flags);
}
+#endif
/*
* This function can only be used to modify existing table entries,
@@ -514,8 +654,8 @@ void __init create_mapping_noalloc(phys_addr_t phys, unsigned long virt,
&phys, virt);
return;
}
- __create_pgd_mapping(init_mm.pgd, phys, virt, size, prot, NULL,
- NO_CONT_MAPPINGS);
+ __create_pgd_mapping(init_mm.pgd, phys, virt, size, prot,
+ &early_pgtable_ops, NO_CONT_MAPPINGS | NO_ALLOC);
}
void __init create_pgd_mapping(struct mm_struct *mm, phys_addr_t phys,
@@ -530,7 +670,7 @@ void __init create_pgd_mapping(struct mm_struct *mm, phys_addr_t phys,
flags = NO_BLOCK_MAPPINGS | NO_CONT_MAPPINGS;
__create_pgd_mapping(mm->pgd, phys, virt, size, prot,
- pgd_pgtable_alloc, flags);
+ &pgd_pgtable_ops, flags);
}
static void update_mapping_prot(phys_addr_t phys, unsigned long virt,
@@ -542,8 +682,8 @@ static void update_mapping_prot(phys_addr_t phys, unsigned long virt,
return;
}
- __create_pgd_mapping(init_mm.pgd, phys, virt, size, prot, NULL,
- NO_CONT_MAPPINGS);
+ __create_pgd_mapping(init_mm.pgd, phys, virt, size, prot,
+ &pgd_pgtable_ops, NO_CONT_MAPPINGS | NO_ALLOC);
/* flush the TLBs after updating live kernel mappings */
flush_tlb_kernel_range(virt, virt + size);
@@ -553,7 +693,7 @@ static void __init __map_memblock(pgd_t *pgdp, phys_addr_t start,
phys_addr_t end, pgprot_t prot, int flags)
{
__create_pgd_mapping(pgdp, start, __phys_to_virt(start), end - start,
- prot, early_pgtable_alloc, flags);
+ prot, &early_pgtable_ops, flags);
}
void __init mark_linear_text_alias_ro(void)
@@ -744,7 +884,7 @@ static int __init map_entry_trampoline(void)
memset(tramp_pg_dir, 0, PGD_SIZE);
__create_pgd_mapping(tramp_pg_dir, pa_start, TRAMP_VALIAS,
entry_tramp_text_size(), prot,
- __pgd_pgtable_alloc, NO_BLOCK_MAPPINGS);
+ &__pgd_pgtable_ops, NO_BLOCK_MAPPINGS);
/* Map both the text and data into the kernel page table */
for (i = 0; i < DIV_ROUND_UP(entry_tramp_text_size(), PAGE_SIZE); i++)
@@ -1346,7 +1486,7 @@ int arch_add_memory(int nid, u64 start, u64 size,
flags |= NO_BLOCK_MAPPINGS | NO_CONT_MAPPINGS;
__create_pgd_mapping(swapper_pg_dir, start, __phys_to_virt(start),
- size, params->pgprot, __pgd_pgtable_alloc,
+ size, params->pgprot, &__pgd_pgtable_ops,
flags);
memblock_clear_nomap(start, size);
--
2.25.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH v2 4/4] arm64: mm: Lazily clear pte table mappings from fixmap
From: Ryan Roberts @ 2024-04-04 14:33 UTC (permalink / raw)
To: Catalin Marinas, Will Deacon, Mark Rutland, Ard Biesheuvel,
David Hildenbrand, Donald Dutile, Eric Chanudet
Cc: Ryan Roberts, linux-arm-kernel, linux-kernel, Itaru Kitayama
In-Reply-To: <20240404143308.2224141-1-ryan.roberts@arm.com>
With the pgtable operations abstracted into `struct pgtable_ops`, the
early pgtable alloc, map and unmap operations are nicely centralized. So
let's enhance the implementation to speed up the clearing of pte table
mappings in the fixmap.
Extend FIX_MAP so that we now have 16 slots in the fixmap dedicated for
pte tables. At alloc/map time, we select the next slot in the series and
map it. Or if we are at the end and no more slots are available, clear
down all of the slots and start at the beginning again. Batching the
clear like this means we can issue tlbis more efficiently.
Due to the batching, there may still be some slots mapped at the end, so
address this by adding an optional cleanup() function to `struct
pgtable_ops` to handle this for us.
Execution time of map_mem(), which creates the kernel linear map page
tables, was measured on different machines with different RAM configs:
| Apple M2 VM | Ampere Altra| Ampere Altra| Ampere Altra
| VM, 16G | VM, 64G | VM, 256G | Metal, 512G
---------------|-------------|-------------|-------------|-------------
| ms (%) | ms (%) | ms (%) | ms (%)
---------------|-------------|-------------|-------------|-------------
before | 11 (0%) | 109 (0%) | 449 (0%) | 1257 (0%)
after | 6 (-46%) | 61 (-44%) | 257 (-43%) | 838 (-33%)
Signed-off-by: Ryan Roberts <ryan.roberts@arm.com>
Tested-by: Itaru Kitayama <itaru.kitayama@fujitsu.com>
Tested-by: Eric Chanudet <echanude@redhat.com>
---
arch/arm64/include/asm/fixmap.h | 5 +++-
arch/arm64/include/asm/pgtable.h | 4 ---
arch/arm64/mm/fixmap.c | 11 ++++++++
arch/arm64/mm/mmu.c | 44 +++++++++++++++++++++++++++++---
4 files changed, 56 insertions(+), 8 deletions(-)
diff --git a/arch/arm64/include/asm/fixmap.h b/arch/arm64/include/asm/fixmap.h
index 87e307804b99..91fcd7c5c513 100644
--- a/arch/arm64/include/asm/fixmap.h
+++ b/arch/arm64/include/asm/fixmap.h
@@ -84,7 +84,9 @@ enum fixed_addresses {
* Used for kernel page table creation, so unmapped memory may be used
* for tables.
*/
- FIX_PTE,
+#define NR_PTE_SLOTS 16
+ FIX_PTE_END,
+ FIX_PTE_BEGIN = FIX_PTE_END + NR_PTE_SLOTS - 1,
FIX_PMD,
FIX_PUD,
FIX_P4D,
@@ -108,6 +110,7 @@ void __init early_fixmap_init(void);
#define __late_clear_fixmap(idx) __set_fixmap((idx), 0, FIXMAP_PAGE_CLEAR)
extern void __set_fixmap(enum fixed_addresses idx, phys_addr_t phys, pgprot_t prot);
+void __init clear_fixmap_nosync(enum fixed_addresses idx);
#include <asm-generic/fixmap.h>
diff --git a/arch/arm64/include/asm/pgtable.h b/arch/arm64/include/asm/pgtable.h
index 92c9aed5e7af..4c7114d49697 100644
--- a/arch/arm64/include/asm/pgtable.h
+++ b/arch/arm64/include/asm/pgtable.h
@@ -691,10 +691,6 @@ static inline unsigned long pmd_page_vaddr(pmd_t pmd)
/* Find an entry in the third-level page table. */
#define pte_offset_phys(dir,addr) (pmd_page_paddr(READ_ONCE(*(dir))) + pte_index(addr) * sizeof(pte_t))
-#define pte_set_fixmap(addr) ((pte_t *)set_fixmap_offset(FIX_PTE, addr))
-#define pte_set_fixmap_offset(pmd, addr) pte_set_fixmap(pte_offset_phys(pmd, addr))
-#define pte_clear_fixmap() clear_fixmap(FIX_PTE)
-
#define pmd_page(pmd) phys_to_page(__pmd_to_phys(pmd))
/* use ONLY for statically allocated translation tables */
diff --git a/arch/arm64/mm/fixmap.c b/arch/arm64/mm/fixmap.c
index de1e09d986ad..0cb09bedeeec 100644
--- a/arch/arm64/mm/fixmap.c
+++ b/arch/arm64/mm/fixmap.c
@@ -131,6 +131,17 @@ void __set_fixmap(enum fixed_addresses idx,
}
}
+void __init clear_fixmap_nosync(enum fixed_addresses idx)
+{
+ unsigned long addr = __fix_to_virt(idx);
+ pte_t *ptep;
+
+ BUG_ON(idx <= FIX_HOLE || idx >= __end_of_fixed_addresses);
+
+ ptep = fixmap_pte(addr);
+ __pte_clear(&init_mm, addr, ptep);
+}
+
void *__init fixmap_remap_fdt(phys_addr_t dt_phys, int *size, pgprot_t prot)
{
const u64 dt_virt_base = __fix_to_virt(FIX_FDT);
diff --git a/arch/arm64/mm/mmu.c b/arch/arm64/mm/mmu.c
index 90bf822859b8..2e3b594aa23c 100644
--- a/arch/arm64/mm/mmu.c
+++ b/arch/arm64/mm/mmu.c
@@ -66,11 +66,14 @@ enum pgtable_type {
* mapped either as a result of a previous call to alloc() or
* map(). The page's virtual address must be considered invalid
* after this call returns.
+ * @cleanup: (Optional) Called at the end of a set of operations to cleanup
+ * any lazy state.
*/
struct pgtable_ops {
void *(*alloc)(int type, phys_addr_t *pa);
void *(*map)(int type, void *parent, unsigned long addr);
void (*unmap)(int type);
+ void (*cleanup)(void);
};
#define NO_BLOCK_MAPPINGS BIT(0)
@@ -139,9 +142,33 @@ pgprot_t phys_mem_access_prot(struct file *file, unsigned long pfn,
}
EXPORT_SYMBOL(phys_mem_access_prot);
+static int pte_slot_next __initdata = FIX_PTE_BEGIN;
+
+static void __init clear_pte_fixmap_slots(void)
+{
+ unsigned long start = __fix_to_virt(FIX_PTE_BEGIN);
+ unsigned long end = __fix_to_virt(pte_slot_next);
+ int i;
+
+ for (i = FIX_PTE_BEGIN; i > pte_slot_next; i--)
+ clear_fixmap_nosync(i);
+
+ flush_tlb_kernel_range(start, end);
+ pte_slot_next = FIX_PTE_BEGIN;
+}
+
+static int __init pte_fixmap_slot(void)
+{
+ if (pte_slot_next < FIX_PTE_END)
+ clear_pte_fixmap_slots();
+
+ return pte_slot_next--;
+}
+
static void *__init early_pgtable_alloc(int type, phys_addr_t *pa)
{
void *va;
+ int slot;
*pa = memblock_phys_alloc_range(PAGE_SIZE, PAGE_SIZE, 0,
MEMBLOCK_ALLOC_NOLEAKTRACE);
@@ -159,7 +186,9 @@ static void *__init early_pgtable_alloc(int type, phys_addr_t *pa)
va = pmd_set_fixmap(*pa);
break;
case TYPE_PTE:
- va = pte_set_fixmap(*pa);
+ slot = pte_fixmap_slot();
+ set_fixmap(slot, *pa);
+ va = (pte_t *)__fix_to_virt(slot);
break;
default:
BUG();
@@ -174,7 +203,9 @@ static void *__init early_pgtable_alloc(int type, phys_addr_t *pa)
static void *__init early_pgtable_map(int type, void *parent, unsigned long addr)
{
+ phys_addr_t pa;
void *entry;
+ int slot;
switch (type) {
case TYPE_P4D:
@@ -187,7 +218,10 @@ static void *__init early_pgtable_map(int type, void *parent, unsigned long addr
entry = pmd_set_fixmap_offset((pud_t *)parent, addr);
break;
case TYPE_PTE:
- entry = pte_set_fixmap_offset((pmd_t *)parent, addr);
+ slot = pte_fixmap_slot();
+ pa = pte_offset_phys((pmd_t *)parent, addr);
+ set_fixmap(slot, pa);
+ entry = (pte_t *)(__fix_to_virt(slot) + (pa & (PAGE_SIZE - 1)));
break;
default:
BUG();
@@ -209,7 +243,7 @@ static void __init early_pgtable_unmap(int type)
pmd_clear_fixmap();
break;
case TYPE_PTE:
- pte_clear_fixmap();
+ // Unmap lazily: see clear_pte_fixmap_slots().
break;
default:
BUG();
@@ -220,6 +254,7 @@ static struct pgtable_ops early_pgtable_ops __initdata = {
.alloc = early_pgtable_alloc,
.map = early_pgtable_map,
.unmap = early_pgtable_unmap,
+ .cleanup = clear_pte_fixmap_slots,
};
bool pgattr_change_is_safe(u64 old, u64 new)
@@ -538,6 +573,9 @@ static void __create_pgd_mapping_locked(pgd_t *pgdir, phys_addr_t phys,
alloc_init_p4d(pgdp, addr, next, phys, prot, ops, flags);
phys += next - addr;
} while (pgdp++, addr = next, addr != end);
+
+ if (ops->cleanup)
+ ops->cleanup();
}
static void __create_pgd_mapping(pgd_t *pgdir, phys_addr_t phys,
--
2.25.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* Re: [PATCH v2 1/4] arm64: patching: always use fixmap
From: Jarkko Sakkinen @ 2024-04-04 14:48 UTC (permalink / raw)
To: Mark Rutland
Cc: linux-kernel, Catalin Marinas, Will Deacon, anil.s.keshavamurthy,
aou, davem, linux-arm-kernel, mhiramat, naveen.n.rao, palmer,
paul.walmsley
In-Reply-To: <Zg2JIFNy8IgwIyUV@FVFF77S0Q05N>
On Wed Apr 3, 2024 at 7:51 PM EEST, Mark Rutland wrote:
> On Wed, Apr 03, 2024 at 07:20:31PM +0300, Jarkko Sakkinen wrote:
> > On Wed Apr 3, 2024 at 6:01 PM EEST, Mark Rutland wrote:
> > > For historical reasons, patch_map() won't bother to fixmap non-image
> > > addresses when CONFIG_STRICT_MODULE_RWX=n, matching the behaviour prior
> > > to the introduction of CONFIG_STRICT_MODULE_RWX. However, as arm64
> > > doesn't select CONFIG_ARCH_OPTIONAL_KERNEL_RWX, CONFIG_MODULES implies
> > > CONFIG_STRICT_MODULE_RWX, so any kernel built with module support will
> > > use the fixmap for any non-image address.
> >
> > Not familiar with the config flag but I'd guess it is essentially
> > w^x enforcement right for the sections?
>
> Essentially, yes.
>
> > > Historically we only used patch_map() for the kernel image and modules,
> > > but these days its also used by BPF and KPROBES to write to read-only
> > > pages of executable text. Currently these both depend on CONFIG_MODULES,
> > > but we'd like to change that in subsequent patches, which will require
> > > using the fixmap regardless of CONFIG_STRICT_MODULE_RWX.
> > >
> > > This patch changes patch_map() to always use the fixmap, and simplifies
> > > the logic:
> > >
> > > * Use is_image_text() directly in the if-else, rather than using a
> > > temporary boolean variable.
> > >
> > > * Use offset_in_page() to get the offset within the mapping.
> > >
> > > * Remove uintaddr and cast the address directly when using
> > > is_image_text().
> > >
> > > For kernels built with CONFIG_MODULES=y, there should be no functional
> > > change as a result of this patch.
> > >
> > > For kernels built with CONFIG_MODULES=n, patch_map() will use the fixmap
> > > for non-image addresses, but there are no extant users with non-image
> > > addresses when CONFIG_MODULES=n, and hence there should be no functional
> > > change as a result of this patch alone.
> > >
> > > Signed-off-by: Mark Rutland <mark.rutland@arm.com>
> > > Cc: Catalin Marinas <catalin.marinas@arm.com>
> > > Cc: Will Deacon <will@kernel.org>
> > > ---
> > > arch/arm64/kernel/patching.c | 10 +++-------
> > > 1 file changed, 3 insertions(+), 7 deletions(-)
> > >
> > > Catalin, Will, this is a prerequisite for the final two patches in the
> > > series. Are you happy for this go via the tracing tree?
> > >
> > > Mark.
> > >
> > > diff --git a/arch/arm64/kernel/patching.c b/arch/arm64/kernel/patching.c
> > > index 2555349303684..f0f3a2a82ca5a 100644
> > > --- a/arch/arm64/kernel/patching.c
> > > +++ b/arch/arm64/kernel/patching.c
> > > @@ -30,20 +30,16 @@ static bool is_image_text(unsigned long addr)
> > >
> > > static void __kprobes *patch_map(void *addr, int fixmap)
> > > {
> > > - unsigned long uintaddr = (uintptr_t) addr;
> > > - bool image = is_image_text(uintaddr);
> > > struct page *page;
> > >
> > > - if (image)
> > > + if (is_image_text((unsigned long)addr))
> > > page = phys_to_page(__pa_symbol(addr));
> > > - else if (IS_ENABLED(CONFIG_STRICT_MODULE_RWX))
> > > - page = vmalloc_to_page(addr);
> > > else
> > > - return addr;
> > > + page = vmalloc_to_page(addr);
> > >
> > > BUG_ON(!page);
> > > return (void *)set_fixmap_offset(fixmap, page_to_phys(page) +
> > > - (uintaddr & ~PAGE_MASK));
> > > + offset_in_page(addr));
> >
> > nit: could be a single line but i guess it is up to the taste (and
> > subsystem maintainer). I.e. checkpatch will allow it at least.
> >
> > I don't mind it too much just mentioning for completeness.
>
> At that point it goes to 93 chars long, and I stuck with the existing line
> wrapping at 80 chars. I'd rather have a temporary 'phys_addr_t phys' variable
> and do:
>
> phys = page_to_phys(page) + offset_in_page(addr);
> return (void *)set_fixmap(fixmap, phys);
>
> ... but I'll leave this as-is for now.
>
> > > }
> > >
> > > static void __kprobes patch_unmap(int fixmap)
> >
> > If my assumption about the config flag holds this makes sense:
> >
> > Reviewed-by: Jarkko Sakkinen <jarkko@kernel.rg>
>
> Thanks! I assume that should be "kernel.org", with an 'o' ;)
Yes, that's correct, not from Gibraltar :-)
BR, Jarkko
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v5 02/10] dt-bindings: mailbox: Add mboxes property for CMDQ secure driver
From: Conor Dooley @ 2024-04-04 14:52 UTC (permalink / raw)
To: Jason-JH Lin (林睿祥)
Cc: Shawn Sung (宋孝謙),
linux-kernel@vger.kernel.org, linux-mediatek@lists.infradead.org,
Houlong Wei (魏厚龙),
devicetree@vger.kernel.org, CK Hu (胡俊光),
conor+dt@kernel.org, robh@kernel.org,
linux-arm-kernel@lists.infradead.org,
krzysztof.kozlowski+dt@linaro.org, matthias.bgg@gmail.com,
jassisinghbrar@gmail.com, angelogioacchino.delregno@collabora.com
In-Reply-To: <9b9707a4a0e285a12741fe4140680ad2578d8d2b.camel@mediatek.com>
[-- Attachment #1.1: Type: text/plain, Size: 2253 bytes --]
On Thu, Apr 04, 2024 at 04:31:06AM +0000, Jason-JH Lin (林睿祥) wrote:
> Hi Conor,
>
> Thanks for the reviews.
>
> On Wed, 2024-04-03 at 16:46 +0100, Conor Dooley wrote:
> > On Wed, Apr 03, 2024 at 06:25:54PM +0800, Shawn Sung wrote:
> > > From: "Jason-JH.Lin" <jason-jh.lin@mediatek.com>
> > >
> > > Add mboxes to define a GCE loopping thread as a secure irq handler.
> > > This property is only required if CMDQ secure driver is supported.
> > >
> > > Signed-off-by: Jason-JH.Lin <jason-jh.lin@mediatek.com>
> > > Signed-off-by: Hsiao Chien Sung <shawn.sung@mediatek.com>
> > > ---
> > > .../bindings/mailbox/mediatek,gce-mailbox.yaml | 10
> > > ++++++++++
> > > 1 file changed, 10 insertions(+)
> > >
> > > diff --git
> > > a/Documentation/devicetree/bindings/mailbox/mediatek,gce-
> > > mailbox.yaml
> > > b/Documentation/devicetree/bindings/mailbox/mediatek,gce-
> > > mailbox.yaml
> > > index cef9d76013985..c0d80cc770899 100644
> > > --- a/Documentation/devicetree/bindings/mailbox/mediatek,gce-
> > > mailbox.yaml
> > > +++ b/Documentation/devicetree/bindings/mailbox/mediatek,gce-
> > > mailbox.yaml
> > > @@ -49,6 +49,16 @@ properties:
> > > items:
> > > - const: gce
> > >
> > > + mediatek,gce-events:
> > > + description:
> > > + The event id which is mapping to the specific hardware event
> > > signal
> > > + to gce. The event id is defined in the gce header
> > > + include/dt-bindings/gce/<chip>-gce.h of each chips.
> >
> > Missing any info here about when this should be used, hint - you have
> > it
> > in the commit message.
> >
> > > + $ref: /schemas/types.yaml#/definitions/uint32-arrayi
> >
> > Why is the ID used by the CMDQ service not fixed for each SoC?
> >
> I forgot to sync with Shawn about this:
> https://lore.kernel.org/all/20240124011459.12204-1-jason-
> jh.lin@mediatek.com
>
> I'll fix it at the next version.
When I say "fixed" I don't mean "this is wrong, please fix it", I mean
"why is the value not static for a particular SoC". This needs to be
explained in the patch (and the description for the event here needs to
explain what the gce-mailbox is reserving an event for).
Thanks,
Conor.
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
[-- Attachment #2: Type: text/plain, Size: 176 bytes --]
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH net-next v3 0/5] allocate dummy device dynamically
From: Kalle Valo @ 2024-04-04 15:01 UTC (permalink / raw)
To: Breno Leitao
Cc: aleksander.lobakin, kuba, davem, pabeni, edumazet, elder,
linux-arm-kernel, linux-mediatek, nbd, sean.wang, Mark-MC.Lee,
lorenzo, taras.chornyi, Matthias Brugger,
AngeloGioacchino Del Regno, quic_jjohnson, leon,
dennis.dalessandro, linux-kernel, netdev, bpf
In-Reply-To: <Zg63iwvtTMlZSGcd@gmail.com>
Breno Leitao <leitao@debian.org> writes:
> Hello Kalle,
>
> On Thu, Apr 04, 2024 at 02:59:59PM +0300, Kalle Valo wrote:
>> Breno Leitao <leitao@debian.org> writes:
>>
>> > struct net_device shouldn't be embedded into any structure, instead,
>> > the owner should use the private space to embed their state into
>> > net_device.
>> >
>> > But, in some cases the net_device is embedded inside the private
>> > structure, which blocks the usage of zero-length arrays inside
>> > net_device.
>> >
>> > Create a helper to allocate a dummy device at dynamically runtime, and
>> > move the Ethernet devices to use it, instead of embedding the dummy
>> > device inside the private structure.
>> >
>> > This fixes all the network cases except for wireless drivers.
>> >
>> > PS: Due to lack of hardware, unfortunately all these patches are
>> > compiled tested only.
>>
>> BTW if it helps, and if you have an ath10k or ath11k patch already, I
>> can run a quick test on real hardware.
>
> That would be very much appreciated! Thanks!
>
> I don't have them ready yet, but, I will work on them soon and I will
> send it to you probably tomorrow.
>
> Should I send them as RFC, or as a regular patch, and we iterate over?
> What would you prefer?
A regular patch, like you did last time with ath11k, is fine for me. But
please do add a lore or patchwork link to the depency patchset so that
I'm testing with correct patches.
--
https://patchwork.kernel.org/project/linux-wireless/list/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v3] arm64: dts: ti: k3-am62p: use eFuse MAC Address for CPSW3G Port 1
From: Krzysztof Kozlowski @ 2024-04-04 13:50 UTC (permalink / raw)
To: Siddharth Vadapalli, nm, vigneshr, kristo, robh, krzk+dt,
conor+dt
Cc: devicetree, linux-kernel, linux-arm-kernel, srk
In-Reply-To: <20240404124614.891416-1-s-vadapalli@ti.com>
On 04/04/2024 14:46, Siddharth Vadapalli wrote:
> Add the "ethernet-mac-syscon" node within "wkup_conf" node corresponding to
> the CTRLMMR_MAC_IDx registers within the CTRL_MMR space. Assign the
> compatible "ti,am62p-cpsw-mac-efuse" to enable "syscon_regmap" operations
> on these registers. The MAC Address programmed in the eFuse is accessible
> through the CTRLMMR_MAC_IDx registers. The "ti,syscon-efuse" device-tree
> property points to the CTRLMMR_MAC_IDx registers, allowing the CPSW driver
> to fetch the MAC Address and assign it to the network interface associated
> with CPSW3G MAC Port 1.
>
> Signed-off-by: Siddharth Vadapalli <s-vadapalli@ti.com>
> ---
>
Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Best regards,
Krzysztof
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 2/2] arm64: dts: rockchip: add Protonic MECSBC device-tree
From: Andrew Lunn @ 2024-04-04 15:10 UTC (permalink / raw)
To: Sascha Hauer
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Heiko Stuebner,
devicetree, linux-arm-kernel, linux-rockchip, linux-kernel,
David Jander
In-Reply-To: <20240404-protonic-mecsbc-v1-2-ad5b42ade6c6@pengutronix.de>
> +&gmac1 {
> + assigned-clocks = <&cru SCLK_GMAC1_RX_TX>, <&cru SCLK_GMAC1>;
> + assigned-clock-parents = <&cru SCLK_GMAC1_RGMII_SPEED>, <&cru CLK_MAC1_2TOP>;
> + phy-handle = <&rgmii_phy1>;
> + phy-mode = "rgmii";
> + clock_in_out = "output";
> + pinctrl-names = "default";
> + pinctrl-0 = <&gmac1m1_miim
> + &gmac1m1_tx_bus2
> + &gmac1m1_rx_bus2
> + &gmac1m1_rgmii_clk
> + &gmac1m1_clkinout
> + &gmac1m1_rgmii_bus>;
> + status = "okay";
> + tx_delay = <0x30>;
> + rx_delay = <0x10>;
> +};
There was a discussion about phy-mode = "rgmii"; and these
tx/rx_delays last month. Please could you go read that discussion and
them make use of rgmii-id, and change the delays.
Also, where did you copy this from? If possible, it would be good to
fix the example everybody copies into new DT blobs.
Andrew
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v2 4/4] kprobes: Remove core dependency on modules
From: Jarkko Sakkinen @ 2024-04-04 15:18 UTC (permalink / raw)
To: Jarkko Sakkinen, Mark Rutland, linux-kernel
Cc: anil.s.keshavamurthy, aou, catalin.marinas, davem,
linux-arm-kernel, mhiramat, naveen.n.rao, palmer, paul.walmsley,
will
In-Reply-To: <D0B6SY8DJ5RC.KLZ08YRNLOH3@kernel.org>
On Thu Apr 4, 2024 at 11:15 AM EEST, Jarkko Sakkinen wrote:
> On Wed Apr 3, 2024 at 6:01 PM EEST, Mark Rutland wrote:
> > From: Jarkko Sakkinen <jarkko@kernel.org>
> >
> > Tracing with kprobes while running a monolithic kernel is currently
> > impossible because KPROBES depends on MODULES. While this dependency is
> > necessary when HAVE_KPROBES_ALLOC=n and the core kprobes code allocates
> > memory using module_alloc(), all the other module-specific code only
> > exist to handle the case when MODULES=y, and can be hidden behind
> > ifdeffery.
> >
> > Add the necessary ifdeffery, and remove the dependency on MODULES=y when
> > HAVE_KPROBES_ALLOC=y.
> >
> > As of this patch kprobes can be used when MODULES=n on arm64 and
> > riscv. All other architectures still depend on MODULES, either by virtue
> > of the core dependency on MODULES when HAVE_KPROBES_ALLOC=n, or by
> > virtue of an explciit dependency on MODULES in arch code.
> >
> > Other architectures can enable support by implementing their own
> > kprobes_alloc_insn_page() and kprobes_free_insn_page() which do not
> > depend on MODULES.
> >
> > Signed-off-by: Jarkko Sakkinen <jarkko@kernel.org>
> > Link: https://lore.kernel.org/lkml/20240326134616.7691-1-jarkko@kernel.org/
> > [Mark: Remove execmem changes, depend on HAVE_KPROBES_ALLOC]
> > Signed-off-by: Mark Rutland <mark.rutland@arm.com>
> > Cc: Albert Ou <aou@eecs.berkeley.edu>
> > Cc: Anil S Keshavamurthy <anil.s.keshavamurthy@intel.com>
> > Cc: Catalin Marinas <catalin.marinas@arm.com>
> > Cc: David S. Miller <davem@davemloft.net>
> > Cc: Jarkko Sakkinen <jarkko@kernel.org>
> > Cc: Masami Hiramatsu <mhiramat@kernel.org>
> > Cc: Naveen N. Rao <naveen.n.rao@linux.ibm.com>
> > Cc: Palmer Dabbelt <palmer@dabbelt.com>
> > Cc: Paul Walmsley <paul.walmsley@sifive.com>
> > Cc: Will Deacon <will@kernel.org>
> > ---
> > arch/Kconfig | 2 +-
> > kernel/kprobes.c | 46 ++++++++++++++++++++++---------------
> > kernel/trace/trace_kprobe.c | 15 ++++++++++--
> > 3 files changed, 41 insertions(+), 22 deletions(-)
> >
> > diff --git a/arch/Kconfig b/arch/Kconfig
> > index 85bb59f7b8c07..0df2c88547b3c 100644
> > --- a/arch/Kconfig
> > +++ b/arch/Kconfig
> > @@ -52,7 +52,7 @@ config GENERIC_ENTRY
> >
> > config KPROBES
> > bool "Kprobes"
> > - depends on MODULES
> > + depends on MODULES || HAVE_KPROBES_ALLOC
> > depends on HAVE_KPROBES
> > select KALLSYMS
> > select TASKS_RCU if PREEMPTION
> > diff --git a/kernel/kprobes.c b/kernel/kprobes.c
> > index fa2ee4e59eca2..ec4493a41b505 100644
> > --- a/kernel/kprobes.c
> > +++ b/kernel/kprobes.c
> > @@ -1594,6 +1594,7 @@ static int check_kprobe_address_safe(struct kprobe *p,
> > goto out;
> > }
> >
> > +#ifdef CONFIG_MODULES
> > /*
> > * If the module freed '.init.text', we couldn't insert
> > * kprobes in there.
> > @@ -1604,7 +1605,9 @@ static int check_kprobe_address_safe(struct kprobe *p,
> > *probed_mod = NULL;
> > ret = -ENOENT;
> > }
> > +#endif /* CONFIG_MODULES */
> > }
> > +
> > out:
> > preempt_enable();
> > jump_label_unlock();
> > @@ -2484,24 +2487,6 @@ int kprobe_add_area_blacklist(unsigned long start, unsigned long end)
> > return 0;
> > }
> >
> > -/* Remove all symbols in given area from kprobe blacklist */
> > -static void kprobe_remove_area_blacklist(unsigned long start, unsigned long end)
> > -{
> > - struct kprobe_blacklist_entry *ent, *n;
> > -
> > - list_for_each_entry_safe(ent, n, &kprobe_blacklist, list) {
> > - if (ent->start_addr < start || ent->start_addr >= end)
> > - continue;
> > - list_del(&ent->list);
> > - kfree(ent);
> > - }
> > -}
> > -
> > -static void kprobe_remove_ksym_blacklist(unsigned long entry)
> > -{
> > - kprobe_remove_area_blacklist(entry, entry + 1);
> > -}
> > -
> > int __weak arch_kprobe_get_kallsym(unsigned int *symnum, unsigned long *value,
> > char *type, char *sym)
> > {
> > @@ -2566,6 +2551,25 @@ static int __init populate_kprobe_blacklist(unsigned long *start,
> > return ret ? : arch_populate_kprobe_blacklist();
> > }
> >
> > +#ifdef CONFIG_MODULES
> > +/* Remove all symbols in given area from kprobe blacklist */
> > +static void kprobe_remove_area_blacklist(unsigned long start, unsigned long end)
> > +{
> > + struct kprobe_blacklist_entry *ent, *n;
> > +
> > + list_for_each_entry_safe(ent, n, &kprobe_blacklist, list) {
> > + if (ent->start_addr < start || ent->start_addr >= end)
> > + continue;
> > + list_del(&ent->list);
> > + kfree(ent);
> > + }
> > +}
> > +
> > +static void kprobe_remove_ksym_blacklist(unsigned long entry)
> > +{
> > + kprobe_remove_area_blacklist(entry, entry + 1);
> > +}
> > +
> > static void add_module_kprobe_blacklist(struct module *mod)
> > {
> > unsigned long start, end;
> > @@ -2662,6 +2666,9 @@ static int kprobes_module_callback(struct notifier_block *nb,
> > mutex_unlock(&kprobe_mutex);
> > return NOTIFY_DONE;
> > }
> > +#else
> > +#define kprobes_module_callback (NULL)
> > +#endif /* CONFIG_MODULES */
> >
> > static struct notifier_block kprobe_module_nb = {
> > .notifier_call = kprobes_module_callback,
> > @@ -2726,7 +2733,8 @@ static int __init init_kprobes(void)
> > err = arch_init_kprobes();
> > if (!err)
> > err = register_die_notifier(&kprobe_exceptions_nb);
> > - if (!err)
> > +
> > + if (!err && IS_ENABLED(CONFIG_MODULES))
> > err = register_module_notifier(&kprobe_module_nb);
> >
> > kprobes_initialized = (err == 0);
> > diff --git a/kernel/trace/trace_kprobe.c b/kernel/trace/trace_kprobe.c
> > index 14099cc17fc9e..c509ba776e679 100644
> > --- a/kernel/trace/trace_kprobe.c
> > +++ b/kernel/trace/trace_kprobe.c
> > @@ -111,6 +111,7 @@ static nokprobe_inline bool trace_kprobe_within_module(struct trace_kprobe *tk,
> > return strncmp(module_name(mod), name, len) == 0 && name[len] == ':';
> > }
> >
> > +#ifdef CONFIG_MODULES
> > static nokprobe_inline bool trace_kprobe_module_exist(struct trace_kprobe *tk)
> > {
> > char *p;
> > @@ -129,6 +130,9 @@ static nokprobe_inline bool trace_kprobe_module_exist(struct trace_kprobe *tk)
> >
> > return ret;
> > }
> > +#else
> > +#define trace_kprobe_module_exist(tk) false /* aka a module never exists */
> > +#endif /* CONFIG_MODULES */
> >
> > static bool trace_kprobe_is_busy(struct dyn_event *ev)
> > {
> > @@ -670,6 +674,7 @@ static int register_trace_kprobe(struct trace_kprobe *tk)
> > return ret;
> > }
> >
> > +#ifdef CONFIG_MODULES
> > /* Module notifier call back, checking event on the module */
> > static int trace_kprobe_module_callback(struct notifier_block *nb,
> > unsigned long val, void *data)
> > @@ -699,6 +704,9 @@ static int trace_kprobe_module_callback(struct notifier_block *nb,
> >
> > return NOTIFY_DONE;
> > }
> > +#else
> > +#define trace_kprobe_module_callback (NULL)
> > +#endif /* CONFIG_MODULES */
> >
> > static struct notifier_block trace_kprobe_module_nb = {
> > .notifier_call = trace_kprobe_module_callback,
> > @@ -1933,8 +1941,11 @@ static __init int init_kprobe_trace_early(void)
> > if (ret)
> > return ret;
> >
> > - if (register_module_notifier(&trace_kprobe_module_nb))
> > - return -EINVAL;
> > + if (IS_ENABLED(CONFIG_MODULES)) {
> > + ret = register_module_notifier(&trace_kprobe_module_nb);
> > + if (ret)
> > + return -EINVAL;
> > + }
> >
> > return 0;
> > }
>
> 2/4, 3/4, 4/4:
>
> Tested-by: Jarkko Sakkinen <jarkko@kernel.org> # arch/riscv
Hey, I tried the pci_proc_init example:
[ 3.060703] ------------[ ftrace bug ]------------
[ 3.060944] ftrace faulted on writing
[ 3.060987] [<ffffffff8102c0da>] pci_proc_init+0x0/0x80
[ 3.061509] Updating ftrace call site to call a different ftrace function
[ 3.061756] ftrace record flags: 80100001
[ 3.061925] (1)
[ 3.061925] expected tramp: ffffffff8000aa60
[ 3.062527] ------------[ cut here ]------------
[ 3.062652] WARNING: CPU: 0 PID: 18 at kernel/trace/ftrace.c:2180 ftrace_bug+0x282/0x2b8
[ 3.062747] CPU: 0 PID: 18 Comm: migration/0 Not tainted 6.9.0-rc1 #2
[ 3.062807] Hardware name: riscv-virtio,qemu (DT)
[ 3.062868] Stopper: multi_cpu_stop+0x0/0x1a0 <- stop_machine_cpuslocked+0x140/0x18c
[ 3.062925] epc : ftrace_bug+0x282/0x2b8
[ 3.062957] ra : ftrace_bug+0x282/0x2b8
[ 3.062989] epc : ffffffff80fc31f4 ra : ffffffff80fc31f4 sp : ff20000000093c70
[ 3.063014] gp : ffffffff824b7780 tp : ff60000002a85940 t0 : ffffffff800923a6
[ 3.063037] t1 : 0000000000000020 t2 : 6465746365707865 s0 : ff20000000093cb0
[ 3.063061] s1 : ffffffff8102c0da a0 : 0000000000000022 a1 : ffffffff8229b7f0
[ 3.063084] a2 : 0000000000000010 a3 : fffffffffffffffe a4 : 0000000000000000
[ 3.063108] a5 : 0000000000000000 a6 : 0000000000000000 a7 : 0000000000000001
[ 3.063131] s2 : ff60000002850ab0 s3 : ffffffffffffffff s4 : 0000000000000002
[ 3.063154] s5 : 0000000002000000 s6 : 0000000082000000 s7 : 0000000000000000
[ 3.063178] s8 : 0000000000000001 s9 : ffffffff824bca18 s10: ff60000002845140
[ 3.063202] s11: 00000000000000ab t3 : ffffffff824ce9ef t4 : ffffffff824ce9ef
[ 3.063225] t5 : ffffffff824ce9f0 t6 : ff20000000093aa8
[ 3.063248] status: 0000000200000100 badaddr: 0000000000000000 cause: 0000000000000003
[ 3.063331] [<ffffffff80fc31f4>] ftrace_bug+0x282/0x2b8
[ 3.063398] [<ffffffff80108b1a>] ftrace_replace_code+0xfe/0x168
[ 3.063430] [<ffffffff80108c82>] ftrace_modify_all_code+0x5c/0x16a
[ 3.063460] [<ffffffff80108da2>] __ftrace_modify_code+0x12/0x1c
[ 3.063490] [<ffffffff800f299c>] multi_cpu_stop+0x118/0x1a0
[ 3.063519] [<ffffffff800f242e>] cpu_stopper_thread+0xb2/0x12a
[ 3.063548] [<ffffffff8005dece>] smpboot_thread_fn+0x1aa/0x1d2
[ 3.063577] [<ffffffff80057fec>] kthread+0xfe/0x106
[ 3.063606] [<ffffffff80fe3d76>] ret_from_fork+0xe/0x20
[ 3.063676] ---[ end trace 0000000000000000 ]---
[ 3.069730] ------------[ cut here ]------------
[ 3.069861] Failed to disarm kprobe-ftrace at pci_proc_init+0x0/0x80 (error -19)
[ 3.070078] WARNING: CPU: 0 PID: 1 at kernel/kprobes.c:1128 __disarm_kprobe_ftrace+0x9a/0xae
[ 3.070124] CPU: 0 PID: 1 Comm: swapper/0 Tainted: G W 6.9.0-rc1 #2
[ 3.070133] Hardware name: riscv-virtio,qemu (DT)
[ 3.070141] epc : __disarm_kprobe_ftrace+0x9a/0xae
[ 3.070150] ra : __disarm_kprobe_ftrace+0x9a/0xae
[ 3.070157] epc : ffffffff800ffcda ra : ffffffff800ffcda sp : ff2000000000be30
[ 3.070162] gp : ffffffff824b7780 tp : ff60000002a70000 t0 : ffffffff800923a6
[ 3.070167] t1 : 0000000000000046 t2 : 6f742064656c6961 s0 : ff2000000000be60
[ 3.070173] s1 : ffffffffffffffed a0 : 0000000000000044 a1 : ffffffff8229b7f0
[ 3.070178] a2 : 0000000000000010 a3 : fffffffffffffffe a4 : 0000000000000000
[ 3.070182] a5 : 0000000000000000 a6 : 0000000000000000 a7 : 0000000000000001
[ 3.070187] s2 : ffffffff824bc940 s3 : ffffffff822ac158 s4 : ff60000002b53c80
[ 3.070192] s5 : ffffffff824bc940 s6 : ffffffff822ac158 s7 : ffffffff81000000
[ 3.070197] s8 : ffffffff814775f8 s9 : ffffffff824f23d8 s10: 0000000000000000
[ 3.070202] s11: 0000000000000000 t3 : ffffffff824ce9d7 t4 : ffffffff824ce9d7
[ 3.070206] t5 : ffffffff824ce9d8 t6 : ff2000000000bc48
[ 3.070211] status: 0000000200000120 badaddr: 0000000000000000 cause: 0000000000000003
[ 3.070218] [<ffffffff800ffcda>] __disarm_kprobe_ftrace+0x9a/0xae
[ 3.070228] [<ffffffff80101b16>] kprobe_free_init_mem+0xc2/0x130
[ 3.070236] [<ffffffff80fd9b38>] kernel_init+0x46/0x14e
[ 3.070245] [<ffffffff80fe3d76>] ret_from_fork+0xe/0x20
[ 3.070254] ---[ end trace 0000000000000000 ]---
[
This is with riscv64 defconfig, tracing shenanigans and the following
bootconfig and the bug was realized in QEMU:
ftrace {
tracing_on = 0
tracer = "function_graph"
event {
kprobes.pci_proc_init_begin {
probes = "pci_proc_init"
actions = "traceon"
}
kprobes.pci_proc_init_end {
probes = "pci_proc_init%return"
actions = "traceoff"
}
}
}
kernel {
console = hvc0
dyndbg = "file arch/riscv/kernel/* +p"
earlycon = sbi
memblock = debug
memtest = 1
tp_printk
frace_dump_on_oops
}
BR, Jarkko
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH V2] firmware: arm_scmi: perf: print domain name in error path
From: Sudeep Holla @ 2024-04-04 14:08 UTC (permalink / raw)
To: cristian.marussi, Peng Fan (OSS)
Cc: Sudeep Holla, linux-arm-kernel, linux-kernel, Peng Fan
In-Reply-To: <20240322080531.3365016-1-peng.fan@oss.nxp.com>
On Fri, 22 Mar 2024 16:05:31 +0800, Peng Fan (OSS) wrote:
> It would be easier to locate the problem if domain name is printed out.
>
Applied to sudeep.holla/linux (for-next/scmi/updates), thanks!
[1/1] firmware: arm_scmi: perf: print domain name in error path
https://git.kernel.org/sudeep.holla/c/42a31d4410a8
--
Regards,
Sudeep
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 2/2] arm64: dts: rockchip: add Protonic MECSBC device-tree
From: Diederik de Haas @ 2024-04-04 15:26 UTC (permalink / raw)
To: Sascha Hauer
Cc: linux-rockchip, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Heiko Stuebner, devicetree, linux-arm-kernel, linux-rockchip,
linux-kernel, David Jander, Andrew Lunn
In-Reply-To: <9d325b4e-031c-4f6c-9788-fa5a68470efa@lunn.ch>
[-- Attachment #1.1: Type: text/plain, Size: 970 bytes --]
On Thursday, 4 April 2024 17:10:41 CEST Andrew Lunn wrote:
> > +&gmac1 {
> > + assigned-clocks = <&cru SCLK_GMAC1_RX_TX>, <&cru SCLK_GMAC1>;
> > + assigned-clock-parents = <&cru SCLK_GMAC1_RGMII_SPEED>, <&cru
> > CLK_MAC1_2TOP>; + phy-handle = <&rgmii_phy1>;
> > + phy-mode = "rgmii";
> > + clock_in_out = "output";
> > + pinctrl-names = "default";
> > + pinctrl-0 = <&gmac1m1_miim
> > + &gmac1m1_tx_bus2
> > + &gmac1m1_rx_bus2
> > + &gmac1m1_rgmii_clk
> > + &gmac1m1_clkinout
> > + &gmac1m1_rgmii_bus>;
> > + status = "okay";
> > + tx_delay = <0x30>;
> > + rx_delay = <0x10>;
> > +};
>
> There was a discussion about phy-mode = "rgmii"; and these
> tx/rx_delays last month. Please could you go read that discussion and
> them make use of rgmii-id, and change the delays.
https://lore.kernel.org/linux-rockchip/20240304084612.711678-2-ukleinek@debian.org/
titled "[PATCH] arm64: dts: rockchip: qnap-ts433: Simplify network PHY connection"
[-- Attachment #1.2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
[-- Attachment #2: Type: text/plain, Size: 176 bytes --]
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 7/8] pwm: Add more locking
From: Uwe Kleine-König @ 2024-04-04 15:33 UTC (permalink / raw)
To: Marek Szyprowski
Cc: linux-pwm, linux-amlogic, LKML, kernel, linux-clk,
Alexander Stein, linux-arm-kernel
In-Reply-To: <5a49cadd-21b7-4384-9e7d-9105ccc288b3@samsung.com>
[-- Attachment #1.1: Type: text/plain, Size: 5973 bytes --]
Hello Marek,
[Cc += linux-clk@vger.kernel.org, Alexander Stein, linux-arm-kernel@lists.infradead.org]
On Thu, Apr 04, 2024 at 02:09:32PM +0200, Marek Szyprowski wrote:
> On 17.03.2024 11:40, Uwe Kleine-König wrote:
> > This ensures that a pwm_chip that has no corresponding driver isn't used
> > and that a driver doesn't go away while a callback is still running.
> >
> > In the presence of device links this isn't necessary yet (so this is no
> > fix) but for pwm character device support this is needed.
> >
> > To not serialize all pwm_apply_state() calls, this introduces a per chip
> > lock. An additional complication is that for atomic chips a mutex cannot
> > be used (as pwm_apply_atomic() must not sleem) and a spinlock cannot be
> > held while calling an operation for a sleeping chip. So depending on the
> > chip being atomic or not a spinlock or a mutex is used.
> >
> > Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
>
>
> This patch landed some time ago in linux-next as commit a740f7879609
> ("pwm: Add more locking"). Recently I've finally found that $subject
> patch is responsible for the following lock dep splat observed for some
> time during day-to-day linux-next testing:
>
> ======================================================
> WARNING: possible circular locking dependency detected
> 6.9.0-rc1+ #14790 Tainted: G C
> ------------------------------------------------------
> kworker/u24:4/59 is trying to acquire lock:
> ffff00003c65b510 (&chip->nonatomic_lock){+.+.}-{3:3}, at:
> pwm_apply_might_sleep+0x90/0xd8
>
> but task is already holding lock:
> ffff80008310fa40 (prepare_lock){+.+.}-{3:3}, at: clk_prepare_lock+0x4c/0xa8
>
> which lock already depends on the new lock.
>
>
> the existing dependency chain (in reverse order) is:
>
> -> #1 (prepare_lock){+.+.}-{3:3}:
> lock_acquire+0x68/0x84
> __mutex_lock+0xa0/0x840
> mutex_lock_nested+0x24/0x30
> clk_prepare_lock+0x4c/0xa8
> clk_round_rate+0x38/0xd0
> meson_pwm_apply+0x128/0x220 [pwm_meson]
> __pwm_apply+0x64/0x1f8
> pwm_apply_might_sleep+0x58/0xd8
> pwm_regulator_set_voltage+0xbc/0x12c
> _regulator_do_set_voltage+0x110/0x688
> regulator_set_voltage_rdev+0x64/0x25c
> regulator_do_balance_voltage+0x20c/0x47c
> regulator_balance_voltage+0x50/0x9c
> regulator_set_voltage_unlocked+0xa4/0x128
> regulator_set_voltage+0x50/0xec
> _opp_config_regulator_single+0x4c/0x130
> _set_opp+0xfc/0x544
> dev_pm_opp_set_rate+0x190/0x284
> set_target+0x34/0x40
> __cpufreq_driver_target+0x170/0x290
> cpufreq_online+0x814/0xa3c
> cpufreq_add_dev+0x80/0x98
> subsys_interface_register+0xfc/0x118
> cpufreq_register_driver+0x150/0x234
> dt_cpufreq_probe+0x150/0x480
> platform_probe+0x68/0xd8
> really_probe+0xbc/0x2a0
> __driver_probe_device+0x78/0x12c
> driver_probe_device+0xdc/0x164
> __device_attach_driver+0xb8/0x138
> bus_for_each_drv+0x84/0xe0
> __device_attach+0xa8/0x1b0
> device_initial_probe+0x14/0x20
> bus_probe_device+0xb0/0xb4
> deferred_probe_work_func+0x8c/0xc8
> process_one_work+0x220/0x634
> worker_thread+0x268/0x3a8
> kthread+0x124/0x128
> ret_from_fork+0x10/0x20
This is the meson pwm driver calling clk_set_rate() in the .apply()
callback.
> -> #0 (&chip->nonatomic_lock){+.+.}-{3:3}:
> __lock_acquire+0x1318/0x20c4
> lock_acquire.part.0+0xc8/0x20c
> lock_acquire+0x68/0x84
> __mutex_lock+0xa0/0x840
> mutex_lock_nested+0x24/0x30
> pwm_apply_might_sleep+0x90/0xd8
> clk_pwm_prepare+0x54/0x84
> clk_core_prepare+0xc8/0x2f8
> clk_prepare+0x28/0x44
> mmc_pwrseq_simple_pre_power_on+0x4c/0x8c
> mmc_pwrseq_pre_power_on+0x24/0x34
> mmc_power_up.part.0+0x20/0x16c
> mmc_start_host+0xa0/0xac
> mmc_add_host+0x84/0xf0
> meson_mmc_probe+0x318/0x3e8
> platform_probe+0x68/0xd8
> really_probe+0xbc/0x2a0
> __driver_probe_device+0x78/0x12c
> driver_probe_device+0xdc/0x164
> __device_attach_driver+0xb8/0x138
> bus_for_each_drv+0x84/0xe0
> __device_attach_async_helper+0xb0/0xd4
> async_run_entry_fn+0x34/0xe0
> process_one_work+0x220/0x634
> worker_thread+0x268/0x3a8
> kthread+0x124/0x128
> ret_from_fork+0x10/0x20
This is the clk_pwm driver that calls pwm_enable() in its .prepare()
callback. Looking at
arch/arm64/boot/dts/amlogic/meson-g12b-s922x-khadas-vim3.dts the
pwm-clock uses &pwm_ef which is a meson pwm.
This alone only works because clk_prepare_lock() is reentrant for a
single thread (see commit 533ddeb1e86f ("clk: allow reentrant calls into
the clk framework")). (Is this really safe? What does the prepare_lock
actually protect?)
And because of this the lockdep splat is a false positive (as is every
ABBA splat involving the clk prepare_lock).
I think to properly address this, the global prepare_lock should be
replaced by a per-clk lock. This would at least make
https://lore.kernel.org/all/20231017135436.1241650-1-alexander.stein@ew.tq-group.com/
(which I think is racy and needs a call to clk_rate_exclusive_get())
unnecessary.
Having said that, I don't know how to prevent that lockdep splat with
neither dropping the blamed commit (which is needed for race free
operation in the pwm framework) nor spending hours to rework the locking
of the clk framework.
Best regards
Uwe
--
Pengutronix e.K. | Uwe Kleine-König |
Industrial Linux Solutions | https://www.pengutronix.de/ |
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
[-- Attachment #2: Type: text/plain, Size: 176 bytes --]
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH v2 1/3] dt-bindings: arm64: marvell: add solidrun cn9130 som based boards
From: Josua Mayer @ 2024-04-04 15:35 UTC (permalink / raw)
To: Andrew Lunn, Gregory Clement, Sebastian Hesselbarth, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Rob Herring
Cc: Yazan Shhady, linux-arm-kernel, devicetree, linux-kernel,
Josua Mayer
In-Reply-To: <20240404-cn9130-som-v2-0-3af2229c7d2d@solid-run.com>
Add bindings for SolidRun boards based on CN9130 SoM.
Three boards are added in total:
- Clearfog Base
- Clearfog Pro
- SolidWAN
The Clearfog boards are identical to the older Armada 388 based boards,
upgraded with a new SoM and SoC.
However the feature set and performance characteristics are different,
therefore compatible strings from armada 388 versions are not included.
SolidWAN uses the same SoM adding a southbridge on the carrier.
Since 2019 there are bindings in-tree for two boards based on cn9130 and
9131. These are extremely verbose by listing cn9132, cn9131, cn9130,
ap807-quad, ap807 for the SoC alone.
CN9130 SoC combines an application processor (ap807) and a
communication processor (cp115) in a single package.
The communication processor (short CP) is also available separately as a
southbridge. It only functions in combination with the CN9130 SoC.
Complete systems adding one or two southbridges are by convention called
CN9131 and CN9132 respectively.
Despite different naming all systems are built around the same SoC.
Therefore marvell,cn9131 and marvell,cn9132 can be omitted. The number
of CPs is part of a board's BoM and can be reflected in the board
compatible string instead.
Existing bindings also describe cn9130 as a specialisation of
ap807-quad. Usually board-level compatibles stop at the SoC without
going into silicon versions or individual dies.
There is no programming model at this layer, and in particular not for
parts of an SoC. Therefore the ap compatibles can also be omitted.
Signed-off-by: Josua Mayer <josua@solid-run.com>
---
.../devicetree/bindings/arm/marvell/armada-7k-8k.yaml | 10 ++++++++++
1 file changed, 10 insertions(+)
diff --git a/Documentation/devicetree/bindings/arm/marvell/armada-7k-8k.yaml b/Documentation/devicetree/bindings/arm/marvell/armada-7k-8k.yaml
index 16d2e132d3d1..74d935ea279c 100644
--- a/Documentation/devicetree/bindings/arm/marvell/armada-7k-8k.yaml
+++ b/Documentation/devicetree/bindings/arm/marvell/armada-7k-8k.yaml
@@ -82,4 +82,14 @@ properties:
- const: marvell,armada-ap807-quad
- const: marvell,armada-ap807
+ - description:
+ SolidRun CN9130 SoM based single-board computers
+ items:
+ - enum:
+ - solidrun,cn9130-clearfog-base
+ - solidrun,cn9130-clearfog-pro
+ - solidrun,cn9131-solidwan
+ - const: solidrun,cn9130-sr-som
+ - const: marvell,cn9130
+
additionalProperties: true
--
2.35.3
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox