aboutsummaryrefslogtreecommitdiffstatshomepage
path: root/tools/perf/scripts/python/parallel-perf.py (unfollow)
AgeCommit message (Collapse)AuthorFilesLines
2025-04-15drm/imagination: Move ELF fw utils to common fileMatt Coster4-56/+74
Currently only MIPS firmware processors use ELF-formatted firmware. When adding support for RISC-V firmware processors, it will be useful to have ELF handling functions ready to go. Reviewed-by: Frank Binns <frank.binns@imgtec.com> Link: https://lore.kernel.org/r/20250410-sets-bxs-4-64-patch-v1-v6-13-eda620c5865f@imgtec.com Signed-off-by: Matt Coster <matt.coster@imgtec.com>
2025-04-15drm/imagination: Use callbacks for fw irq handlingMatt Coster4-44/+63
This allows for more versatility in checking and clearing firmware registers used for interrupt handling. Reviewed-by: Frank Binns <frank.binns@imgtec.com> Link: https://lore.kernel.org/r/20250410-sets-bxs-4-64-patch-v1-v6-12-eda620c5865f@imgtec.com Signed-off-by: Matt Coster <matt.coster@imgtec.com>
2025-04-15drm/imagination: Use a lookup table for fw defsMatt Coster3-9/+23
With more than two firmware processor types, the if/else chain in pvr_fw_init() gets a bit ridiculous. Use a static array indexed on pvr_fw_processor_type (which is now a proper enum instead of #defines) instead. Reviewed-by: Frank Binns <frank.binns@imgtec.com> Link: https://lore.kernel.org/r/20250410-sets-bxs-4-64-patch-v1-v6-11-eda620c5865f@imgtec.com Signed-off-by: Matt Coster <matt.coster@imgtec.com>
2025-04-15drm/imagination: Make has_fixed_data_addr a valueMatt Coster4-30/+11
This is currently a callback function which takes no parameters; there's no reason for this so let's make it a straightforward value in pvr_fw_defs. Reviewed-by: Frank Binns <frank.binns@imgtec.com> Link: https://lore.kernel.org/r/20250410-sets-bxs-4-64-patch-v1-v6-10-eda620c5865f@imgtec.com Signed-off-by: Matt Coster <matt.coster@imgtec.com>
2025-04-15drm/imagination: Rename event_mask -> status_maskMatt Coster3-5/+5
Now that enable_reg isn't used, rename the previously shared event_mask to status_mask since it's only used with status_reg. Reviewed-by: Frank Binns <frank.binns@imgtec.com> Link: https://lore.kernel.org/r/20250410-sets-bxs-4-64-patch-v1-v6-9-eda620c5865f@imgtec.com Signed-off-by: Matt Coster <matt.coster@imgtec.com>
2025-04-15drm/imagination: Remove firmware enable_regMatt Coster4-13/+1
After a previous commit ("drm/imagination: Mask GPU IRQs in threaded handler"), this register is now only used to enable firmware interrupts at start-of-day. This is, however, unnecessary since they are enabled by default. In addition, the soon-to-be-added RISC-V firmware processors do not have an equivalent register. Reviewed-by: Frank Binns <frank.binns@imgtec.com> Link: https://lore.kernel.org/r/20250410-sets-bxs-4-64-patch-v1-v6-8-eda620c5865f@imgtec.com Signed-off-by: Matt Coster <matt.coster@imgtec.com>
2025-04-15drm/imagination: Handle Rogue safety event IRQsAlessio Belle3-2/+117
Extend interrupt handling logic to check for safety event IRQs, then clear and handle them in the IRQ handler thread. Safety events need to be checked and cleared with a different set of GPU registers than those the IRQ handler has been using so far. Only two safety events need to be handled on the host: FW fault (ECC error correction or detection) and device watchdog timeout. Handling right now simply consists of clearing any error and logging the event. If either of these events results in an unrecoverable GPU or FW, the driver will eventually attempt to recover from it e.g. via pvr_power_reset(). Note that Rogue GPUs may send interrupts to the host for all types of safety events, not just the two above. For events not handled by the host, clearing the associated interrupt is sufficient. Signed-off-by: Alessio Belle <alessio.belle@imgtec.com> Reviewed-by: Frank Binns <frank.binns@imgtec.com> Link: https://lore.kernel.org/r/20250410-sets-bxs-4-64-patch-v1-v6-7-eda620c5865f@imgtec.com Signed-off-by: Matt Coster <matt.coster@imgtec.com>
2025-04-15drm/imagination: Mask GPU IRQs in threaded handlerAlessio Belle1-7/+5
Pass IRQF_ONESHOT flag to request_threaded_irq(), so that interrupts will be masked by the kernel until the end of the threaded IRQ handler. Since the calls to pvr_fw_irq_enable() and pvr_fw_irq_disable() are now redundant, remove them. Interrupts to the host from the soon-to-be-added RISC-V firmware processors cannot be masked in hardware. This change allows us to continue using the threaded handler in GPUs with a RISC-V firmware. For simplicity, the same approach is taken for all firmware processors. Signed-off-by: Alessio Belle <alessio.belle@imgtec.com> Reviewed-by: Frank Binns <frank.binns@imgtec.com> Link: https://lore.kernel.org/r/20250410-sets-bxs-4-64-patch-v1-v6-6-eda620c5865f@imgtec.com Signed-off-by: Matt Coster <matt.coster@imgtec.com>
2025-04-15drm/imagination: Add power domain controlMatt Coster4-0/+132
The first supported GPU only used a single power domain so this was automatically handled by the device runtime. In order to support multiple power domains, they must be enumerated from devicetree and linked to both the GPU device and each other to ensure correct power sequencing at start time. For all Imagination Rogue GPUs, power domains are named "a", "b", etc. and the sequence A->B->... is always valid for startup with the reverse true for shutdown. Note this is not always the *only* valid sequence, but it's simple and does not require special-casing for different GPU power topologies. Reviewed-by: Frank Binns <frank.binns@imgtec.com> Link: https://lore.kernel.org/r/20250410-sets-bxs-4-64-patch-v1-v6-5-eda620c5865f@imgtec.com Signed-off-by: Matt Coster <matt.coster@imgtec.com>
2025-04-15drm/imagination: Use new generic compatible stringMatt Coster1-0/+7
Follow-on from the companion dt-bindings change ("dt-bindings: gpu: img: More explicit compatible strings"), deprecating "img,img-axe" in favour of the more explicit combination of "img,img-rogue" and "img,img-axe-1-16m". Since all relevant details are interrogated from the device at runtime, we can match on the generic "img,img-rogue" and avoid adding more entries with NULL data members (barring hardware quirks). Reviewed-by: Frank Binns <frank.binns@imgtec.com> Link: https://lore.kernel.org/r/20250410-sets-bxs-4-64-patch-v1-v6-4-eda620c5865f@imgtec.com Signed-off-by: Matt Coster <matt.coster@imgtec.com>
2025-04-15drm/imagination: Update register defs for newer GPUsAlessio Belle1-19/+134
Update the register define header to a newer version that covers more recent GPUs, including BXS-4-64. Signed-off-by: Alessio Belle <alessio.belle@imgtec.com> Reviewed-by: Frank Binns <frank.binns@imgtec.com> Link: https://lore.kernel.org/r/20250410-sets-bxs-4-64-patch-v1-v6-3-eda620c5865f@imgtec.com Signed-off-by: Matt Coster <matt.coster@imgtec.com>
2025-04-15dt-bindings: gpu: img: Add BXS-4-64 devicetree bindingsMatt Coster1-2/+36
Unlike AXE-1-16M, BXS-4-64 uses two power domains. Like the existing AXE-1-16M integration, BXS-4-64 uses the single clock integration in the TI k3-j721s2. Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Link: https://lore.kernel.org/r/20250410-sets-bxs-4-64-patch-v1-v6-2-eda620c5865f@imgtec.com Signed-off-by: Matt Coster <matt.coster@imgtec.com>
2025-04-15dt-bindings: gpu: img: Future-proofing enhancementsMatt Coster1-5/+38
The first compatible strings added for the AXE-1-16M are not sufficient to accurately describe all the IMG Rogue GPUs. The current "img,img-axe" string refers to the entire family of Series AXE GPUs, but this is primarily a marketing term and does not denote a level of hardware similarity any greater than just "Rogue". The more specific "img,img-axe-1-16m" string refers to individual AXE-1-16M GPU. For example, unlike the rest of the Series AXE GPUs, the AXE-1-16M only uses a single power domain. The situation is actually slightly worse than described in the first paragraph, since many "series" (such as Series BXS found in the TI AM68 among others and added later in this series) contain cores with both Rogue and Volcanic architectures. Besides attempting to move away from vague groupings defined only by marketing terms, we want to draw a line between properties inherent to the IP core and choices made by the silicon vendor at integration time. For instance, the number of power domains is a property of the IP core, whereas the decision to use one or multiple clocks is a vendor one. In the original compatible strings, we must use "ti,am62-gpu" to constrain both of these properties since the number of power domains cannot be fixed for "img,img-axe". Work is currently underway to add support for volcanic-based Imagination GPUs, for which bindings will be added in "img,powervr-volcanic.yaml". As alluded to previously, the split between rogue and volcanic cores is non-obvious at times, so add a generic top-level "img,img-rogue" compatible string here to allow for simpler differentiation in devicetrees without referring back to the bindings. The currently supported GPU (AXE-1-16M) only requires a single power domain. Subsequent patches will add support for BXS-4-64 MC1, which has two power domains. Add infrastructure now to allow for this. Also allow the dma-coherent property to be added to IMG Rogue GPUs, which are DMA devices. The decision for coherency is made at integration time and this property should be applied wherever it accurately describes the vendor integration. Note that the new required properties for power domains are conditional on the new base compatible string to avoid an ABI break. Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Link: https://lore.kernel.org/r/20250410-sets-bxs-4-64-patch-v1-v6-1-eda620c5865f@imgtec.com Signed-off-by: Matt Coster <matt.coster@imgtec.com>
2025-04-15drm/display: hdmi: provide central data authority for ACR paramsDmitry Baryshkov2-0/+174
HDMI standard defines recommended N and CTS values for Audio Clock Regeneration. Currently each driver implements those, frequently in somewhat unique way. Provide a generic helper for getting those values to be used by the HDMI drivers. The helper is added to drm_hdmi_helper.c rather than drm_hdmi_audio.c since HDMI drivers can be using this helper function even without switching to DRM HDMI Audio helpers. Note: currently this only handles the values per HDMI 1.4b Section 7.2 and HDMI 2.0 Section 9.2.1. Later the table can be expanded to accommodate for Deep Color TMDS char rates per HDMI 1.4 Appendix D and/or HDMI 2.0 / 2.1 Appendix C). Reviewed-by: Maxime Ripard <mripard@kernel.org> Link: https://lore.kernel.org/r/20250408-drm-hdmi-acr-v2-1-dee7298ab1af@oss.qualcomm.com Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
2025-04-15drm/bridge: anx7625: Use devm_pm_runtime_enable()Chen-Yu Tsai1-8/+1
The anx7625 driver is open coding what devm_pm_runtime_enable() does. Switch to the common helper instead. Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Link: https://patch.msgid.link/20250409093814.3977025-1-wenst@chromium.org Signed-off-by: Chen-Yu Tsai <wenst@chromium.org>
2025-04-14drm/vmwgfx: Use dma_buf from GEM object instanceThomas Zimmermann1-3/+3
Avoid dereferencing struct drm_gem_object.import_attach for the imported dma-buf. The dma_buf field in the GEM object instance refers to the same buffer. Prepares to make import_attach optional. Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Cc: Zack Rusin <zack.rusin@broadcom.com> Cc: Broadcom internal kernel review list <bcm-kernel-feedback-list@broadcom.com> Reviewed-by: Zack Rusin <zack.rusin@broadcom.com> Link: https://lore.kernel.org/r/20250317131923.238374-15-tzimmermann@suse.de
2025-04-14drm/vmwgfx: Test for imported buffers with drm_gem_is_imported()Thomas Zimmermann2-5/+5
Instead of testing import_attach for imported GEM buffers, invoke drm_gem_is_imported() to do the test. The helper tests the dma_buf itself while import_attach is just an artifact of the import. Prepares to make import_attach optional. Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Cc: Zack Rusin <zack.rusin@broadcom.com> Cc: Broadcom internal kernel review list <bcm-kernel-feedback-list@broadcom.com> Reviewed-by: Zack Rusin <zack.rusin@broadcom.com> Link: https://lore.kernel.org/r/20250317131923.238374-14-tzimmermann@suse.de
2025-04-14drm/panthor: Test for imported buffers with drm_gem_is_imported()Thomas Zimmermann2-6/+6
Instead of testing import_attach for imported GEM buffers, invoke drm_gem_is_imported() to do the test. The helper tests the dma_buf itself while import_attach is just an artifact of the import. Prepares to make import_attach optional. Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Cc: Boris Brezillon <boris.brezillon@collabora.com> Cc: Steven Price <steven.price@arm.com> Cc: Liviu Dudau <liviu.dudau@arm.com> Reviewed-by: Liviu Dudau <liviu.dudau@arm.com> Reviewed-by: Steven Price <steven.price@arm.com> Link: https://lore.kernel.org/r/20250317131923.238374-10-tzimmermann@suse.de
2025-04-14drm/panfrost: Test for imported buffers with drm_gem_is_imported()Thomas Zimmermann1-1/+1
Instead of testing import_attach for imported GEM buffers, invoke drm_gem_is_imported() to do the test. The helper tests the dma_buf itself while import_attach is just an artifact of the import. Prepares to make import_attach optional. Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Cc: Boris Brezillon <boris.brezillon@collabora.com> Cc: Rob Herring <robh@kernel.org> Cc: Steven Price <steven.price@arm.com> Reviewed-by: Steven Price <steven.price@arm.com> Link: https://lore.kernel.org/r/20250317131923.238374-9-tzimmermann@suse.de
2025-04-14drm/msm: Test for imported buffers with drm_gem_is_imported()Thomas Zimmermann4-6/+6
Instead of testing import_attach for imported GEM buffers, invoke drm_gem_is_imported() to do the test. The helper tests the dma_buf itself while import_attach is just an artifact of the import. Prepares to make import_attach optional. Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Cc: Rob Clark <robdclark@gmail.com> Cc: Abhinav Kumar <quic_abhinavk@quicinc.com> Cc: Dmitry Baryshkov <lumag@kernel.org> Cc: Sean Paul <sean@poorly.run> Cc: Marijn Suijten <marijn.suijten@somainline.org> Cc: linux-arm-msm@vger.kernel.org Cc: freedreno@lists.freedesktop.org Acked-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Link: https://lore.kernel.org/r/20250317131923.238374-7-tzimmermann@suse.de
2025-04-14drm/etnaviv: Use dma_buf from GEM object instanceThomas Zimmermann1-2/+2
Avoid dereferencing struct drm_gem_object.import_attach for the imported dma-buf. The dma_buf field in the GEM object instance refers to the same buffer. Prepares to make import_attach optional. Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Cc: Lucas Stach <l.stach@pengutronix.de> Cc: Russell King <linux+etnaviv@armlinux.org.uk> Cc: Christian Gmeiner <christian.gmeiner@gmail.com> Cc: etnaviv@lists.freedesktop.org Reviewed-by: Lucas Stach <l.stach@pengutronix.de> Link: https://lore.kernel.org/r/20250317131923.238374-4-tzimmermann@suse.de
2025-04-14drm/etnaviv: Test for imported buffers with drm_gem_is_imported()Thomas Zimmermann1-2/+2
Instead of testing import_attach for imported GEM buffers, invoke drm_gem_is_imported() to do the test. The helper tests the dma_buf itself while import_attach is just an artifact of the import. Prepares to make import_attach optional. Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Cc: Lucas Stach <l.stach@pengutronix.de> Cc: Russell King <linux+etnaviv@armlinux.org.uk> Cc: Christian Gmeiner <christian.gmeiner@gmail.com> Cc: etnaviv@lists.freedesktop.org Reviewed-by: Lucas Stach <l.stach@pengutronix.de> Link: https://lore.kernel.org/r/20250317131923.238374-3-tzimmermann@suse.de
2025-04-14drm/udl: Support adapters without firmware descriptorThomas Zimmermann1-16/+21
Set default limit on the number of pixels for adapters without vendor firmware descriptor. The devices work as expected, they just don't provide any description. If parsing the vendor firmware descriptor fails, the device falls back to the given default limits. Failing to allocate memory is still an error. v2: - fix typo in constant (Patrik) Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Patrik Jakobsson <patrik.r.jakobsson@gmail.com> Link: https://lore.kernel.org/r/20250410105948.25463-10-tzimmermann@suse.de
2025-04-14drm/udl: Validate length in vendor-descriptor parserThomas Zimmermann1-26/+51
Rewrite the parser for the vendor firmware descriptor with the following improvements. - Validate the key-value length given in a vendor descriptor against the length of the descriptor. The current code fails to do this and might read more bytes than available. This can lead to out-of-bounds reads of the allocated buffer. - Read raw data with helpers for unaligned data. This allows the code to run on platforms that do now support unaligned memory access by default. - Validate the pixel limit against a default value. The default comes from real-world devices. If the reported number of pixels is significantly above the limit, it is likely invalid. - Drop the obsolete print macros. There is still a warning about invalid firmware descriptors. The rest of the output is bogus. Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Patrik Jakobsson <patrik.r.jakobsson@gmail.com> Link: https://lore.kernel.org/r/20250410105948.25463-9-tzimmermann@suse.de
2025-04-14drm/udl: Treat vendor descriptor as u8Thomas Zimmermann1-8/+8
The vendor descriptor is an array of unsigned bytes. It is raw data that is not to be modified. Declare it as 'const u8'. Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Patrik Jakobsson <patrik.r.jakobsson@gmail.com> Link: https://lore.kernel.org/r/20250410105948.25463-8-tzimmermann@suse.de
2025-04-14drm/udl: Return error if vendor descriptor is too shortThomas Zimmermann1-36/+36
There need to be least 5 bytes in the vendor descriptor. Return an error otherwise. Also change the branching to early-out on the error. Adjust indention of the rest of the parser function. The original length test expected more than 5 bytes in the vendor descriptor. As a descriptor with no key-value pairs has exactly 5 bytes and is still valid, change the test to accept this case as well. v2 - clarify changes to length test in commit description (Patrik) Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Patrik Jakobsson <patrik.r.jakobsson@gmail.com> Link: https://lore.kernel.org/r/20250410105948.25463-7-tzimmermann@suse.de
2025-04-14drm/udl: Handle errors from usb_get_descriptor()Thomas Zimmermann1-10/+14
Reading the vendor descriptor from the udl device can fail with an error, which the current code fails to capture. Store the return value in an integer and test for the error. Abort parsing on errors or treat the value as length on success. Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Patrik Jakobsson <patrik.r.jakobsson@gmail.com> Link: https://lore.kernel.org/r/20250410105948.25463-6-tzimmermann@suse.de
2025-04-14drm/udl: The number of pixels is always positiveThomas Zimmermann1-2/+2
Store sku_pixel_limit as type unsigned long instead of int. The number of pixels available is always positive. Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Patrik Jakobsson <patrik.r.jakobsson@gmail.com> Link: https://lore.kernel.org/r/20250410105948.25463-5-tzimmermann@suse.de
2025-04-14drm/udl: Improve type safety when using struct udl_deviceThomas Zimmermann5-36/+37
Push upcasts from struct drm_device to struct udl_device outwards in the call chain; cast earlier and call functions with the upcasted value. Improves type safety. Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Patrik Jakobsson <patrik.r.jakobsson@gmail.com> Link: https://lore.kernel.org/r/20250410105948.25463-4-tzimmermann@suse.de
2025-04-14drm/udl: Remove unused field gem_lock from struct udl_deviceThomas Zimmermann2-4/+0
Reduce the size of struct udl_device by removing the unused field gem_lock. Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Patrik Jakobsson <patrik.r.jakobsson@gmail.com> Link: https://lore.kernel.org/r/20250410105948.25463-3-tzimmermann@suse.de
2025-04-14drm/udl: Remove unused field dev from struct udl_deviceThomas Zimmermann1-1/+0
Reduce the size of struct udl_device by removing the unused field dev. Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Patrik Jakobsson <patrik.r.jakobsson@gmail.com> Link: https://lore.kernel.org/r/20250410105948.25463-2-tzimmermann@suse.de
2025-04-14drm/sysfb: Share helpers for screen_info validationThomas Zimmermann5-192/+160
Share efidrm's and vesadrm's validation of struct screen_info in shared helpers. Update the drivers. Most validation helpers test individual values against limits and can be shared as they are. For color formats, a common helper looks up the correct DRM format info from a driver-provided list of color formats. These screen_info helpers are only available if CONFIG_SCREEN_INFO has been selected, as done by efidrm and vesadrm. Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Javier Martinez Canillas <javierm@redhat.com> Link: https://lore.kernel.org/r/20250410083834.10810-4-tzimmermann@suse.de
2025-04-14drm/sysfb: Share helpers for integer validationThomas Zimmermann6-72/+48
Provide sysfb helpers for validating framebuffer integer values against limits. Update drivers. If a driver did not specify a limit for a certain value, use INT_MAX. v2: - declare module information near EOF (Javier) Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Javier Martinez Canillas <javierm@redhat.com> Link: https://lore.kernel.org/r/20250410083834.10810-3-tzimmermann@suse.de
2025-04-14drm/sysfb: Split source fileThomas Zimmermann4-4/+16
Split drm_sysfb_helper.c into two source files. There's now one source file for the mode-setting pipeline and one source file for module meta data. Prepares for adding additional source code to sysfb helpers. v2: - fix typo in commit message (Javier) Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Javier Martinez Canillas <javierm@redhat.com> Link: https://lore.kernel.org/r/20250410083834.10810-2-tzimmermann@suse.de
2025-04-13Linux 6.15-rc2Linus Torvalds1-1/+1
2025-04-12ext4: fix off-by-one error in do_splitArtem Sadovnikov1-1/+1
Syzkaller detected a use-after-free issue in ext4_insert_dentry that was caused by out-of-bounds access due to incorrect splitting in do_split. BUG: KASAN: use-after-free in ext4_insert_dentry+0x36a/0x6d0 fs/ext4/namei.c:2109 Write of size 251 at addr ffff888074572f14 by task syz-executor335/5847 CPU: 0 UID: 0 PID: 5847 Comm: syz-executor335 Not tainted 6.12.0-rc6-syzkaller-00318-ga9cda7c0ffed #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/30/2024 Call Trace: <TASK> __dump_stack lib/dump_stack.c:94 [inline] dump_stack_lvl+0x241/0x360 lib/dump_stack.c:120 print_address_description mm/kasan/report.c:377 [inline] print_report+0x169/0x550 mm/kasan/report.c:488 kasan_report+0x143/0x180 mm/kasan/report.c:601 kasan_check_range+0x282/0x290 mm/kasan/generic.c:189 __asan_memcpy+0x40/0x70 mm/kasan/shadow.c:106 ext4_insert_dentry+0x36a/0x6d0 fs/ext4/namei.c:2109 add_dirent_to_buf+0x3d9/0x750 fs/ext4/namei.c:2154 make_indexed_dir+0xf98/0x1600 fs/ext4/namei.c:2351 ext4_add_entry+0x222a/0x25d0 fs/ext4/namei.c:2455 ext4_add_nondir+0x8d/0x290 fs/ext4/namei.c:2796 ext4_symlink+0x920/0xb50 fs/ext4/namei.c:3431 vfs_symlink+0x137/0x2e0 fs/namei.c:4615 do_symlinkat+0x222/0x3a0 fs/namei.c:4641 __do_sys_symlink fs/namei.c:4662 [inline] __se_sys_symlink fs/namei.c:4660 [inline] __x64_sys_symlink+0x7a/0x90 fs/namei.c:4660 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f </TASK> The following loop is located right above 'if' statement. for (i = count-1; i >= 0; i--) { /* is more than half of this entry in 2nd half of the block? */ if (size + map[i].size/2 > blocksize/2) break; size += map[i].size; move++; } 'i' in this case could go down to -1, in which case sum of active entries wouldn't exceed half the block size, but previous behaviour would also do split in half if sum would exceed at the very last block, which in case of having too many long name files in a single block could lead to out-of-bounds access and following use-after-free. Found by Linux Verification Center (linuxtesting.org) with Syzkaller. Cc: stable@vger.kernel.org Fixes: 5872331b3d91 ("ext4: fix potential negative array index in do_split()") Signed-off-by: Artem Sadovnikov <a.sadovnikov@ispras.ru> Reviewed-by: Jan Kara <jack@suse.cz> Link: https://patch.msgid.link/20250404082804.2567-3-a.sadovnikov@ispras.ru Signed-off-by: Theodore Ts'o <tytso@mit.edu>
2025-04-12ext4: make block validity check resistent to sb bh corruptionOjaswin Mujoo2-6/+6
Block validity checks need to be skipped in case they are called for journal blocks since they are part of system's protected zone. Currently, this is done by checking inode->ino against sbi->s_es->s_journal_inum, which is a direct read from the ext4 sb buffer head. If someone modifies this underneath us then the s_journal_inum field might get corrupted. To prevent against this, change the check to directly compare the inode with journal->j_inode. **Slight change in behavior**: During journal init path, check_block_validity etc might be called for journal inode when sbi->s_journal is not set yet. In this case we now proceed with ext4_inode_block_valid() instead of returning early. Since systems zones have not been set yet, it is okay to proceed so we can perform basic checks on the blocks. Suggested-by: Baokun Li <libaokun1@huawei.com> Reviewed-by: Baokun Li <libaokun1@huawei.com> Reviewed-by: Jan Kara <jack@suse.cz> Reviewed-by: Zhang Yi <yi.zhang@huawei.com> Signed-off-by: Ojaswin Mujoo <ojaswin@linux.ibm.com> Link: https://patch.msgid.link/0c06bc9ebfcd6ccfed84a36e79147bf45ff5adc1.1743142920.git.ojaswin@linux.ibm.com Signed-off-by: Theodore Ts'o <tytso@mit.edu>
2025-04-12ext4: avoid -Wflex-array-member-not-at-end warningGustavo A. R. Silva1-10/+8
-Wflex-array-member-not-at-end was introduced in GCC-14, and we are getting ready to enable it, globally. Use the `DEFINE_RAW_FLEX()` helper for an on-stack definition of a flexible structure where the size of the flexible-array member is known at compile-time, and refactor the rest of the code, accordingly. So, with these changes, fix the following warning: fs/ext4/mballoc.c:3041:40: warning: structure containing a flexible array member is not at the end of another structure [-Wflex-array-member-not-at-end] Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org> Reviewed-by: Kees Cook <kees@kernel.org> Link: https://patch.msgid.link/Z-SF97N3AxcIMlSi@kspp Signed-off-by: Theodore Ts'o <tytso@mit.edu>
2025-04-12Documentation: ext4: Add fields to ext4_super_block documentationTom Vierjahn1-6/+14
Documentation and implementation of the ext4 super block have slightly diverged: Padding has been removed in order to make room for new fields that are still missing in the documentation. Add the new fields s_encryption_level, s_first_error_errorcode, s_last_error_errorcode to the documentation of the ext4 super block. Fixes: f542fbe8d5e8 ("ext4 crypto: reserve codepoints used by the ext4 encryption feature") Fixes: 878520ac45f9 ("ext4: save the error code which triggered an ext4_error() in the superblock") Signed-off-by: Tom Vierjahn <tom.vierjahn@acm.org> Reviewed-by: Ojaswin Mujoo <ojaswin@linux.ibm.com> Link: https://patch.msgid.link/20250324221004.5268-1-tom.vierjahn@acm.org Signed-off-by: Theodore Ts'o <tytso@mit.edu>
2025-04-12rv: Fix out-of-bound memory access in rv_is_container_monitor()Nam Cao1-1/+6
When rv_is_container_monitor() is called on the last monitor in rv_monitors_list, KASAN yells: BUG: KASAN: global-out-of-bounds in rv_is_container_monitor+0x101/0x110 Read of size 8 at addr ffffffff97c7c798 by task setup/221 The buggy address belongs to the variable: rv_monitors_list+0x18/0x40 This is due to list_next_entry() is called on the last entry in the list. It wraps around to the first list_head, and the first list_head is not embedded in struct rv_monitor_def. Fix it by checking if the monitor is last in the list. Cc: stable@vger.kernel.org Cc: Gabriele Monaco <gmonaco@redhat.com> Fixes: cb85c660fcd4 ("rv: Add option for nested monitors and include sched") Link: https://lore.kernel.org/e85b5eeb7228bfc23b8d7d4ab5411472c54ae91b.1744355018.git.namcao@linutronix.de Signed-off-by: Nam Cao <namcao@linutronix.de> Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org>
2025-04-12ftrace: Do not have print_graph_retval() add a newlineSteven Rostedt1-6/+5
The retval and retaddr options for function_graph tracer will add a comment at the end of a function for both leaf and non leaf functions that looks like: __wake_up_common(); /* ret=0x1 */ } /* pick_next_task_fair ret=0x0 */ The function print_graph_retval() adds a newline after the "*/". But if that's not called, the caller function needs to make sure there's a newline added. This is confusing and when the function parameters code was added, it added a newline even when calling print_graph_retval() as the fact that the print_graph_retval() function prints a newline isn't obvious. This caused an extra newline to be printed and that made it fail the selftests when the retval option was set, as the selftests were not expecting blank lines being injected into the trace. Instead of having print_graph_retval() print a newline, just have the caller always print the newline regardless if it calls print_graph_retval() or not. This not only fixes this bug, but it also simplifies the code. Cc: Masami Hiramatsu <mhiramat@kernel.org> Cc: Mark Rutland <mark.rutland@arm.com> Cc: Mathieu Desnoyers <mathieu.desnoyers@efficios.com> Link: https://lore.kernel.org/20250411133015.015ca393@gandalf.local.home Reported-by: Mark Brown <broonie@kernel.org> Tested-by: Mark Brown <broonie@kernel.org> Closes: https://lore.kernel.org/all/ccc40f2b-4b9e-4abd-8daf-d22fce2a86f0@sirena.org.uk/ Fixes: ff5c9c576e754 ("ftrace: Add support for function argument to graph tracer") Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org>