summaryrefslogtreecommitdiff
path: root/include/linux
AgeCommit message (Collapse)Author
2026-09-16posix-timers: Move posixtimer_exec_cleanup() out of exec.cThomas Gleixner
Move it to the POSIX timer code and provide a proper stub when POSIX timers are disabled in Kconfig. No functional change. Signed-off-by: Thomas Gleixner <tglx@kernel.org> Tested-by: Kijo Park <red993688@gmail.com> Reviewed-by: Frederic Weisbecker <frederic@kernel.org> Reviewed-by: Oleg Nesterov <oleg@redhat.com> Link: https://patch.msgid.link/20260911090541.680668094@kernel.org
2026-09-16crypto: ccp - repair all kernel-doc commentsRandy Dunlap
Eliminate all kernel-doc warnings in <linux/ccp.h>: - add Returns: for function return values - use the enum keyword when describing an enum in kernel-doc - add missing enum value descriptions - add or repair missing struct member descriptions - use nested struct notation as needed Warning: include/linux/ccp.h:30 No description found for return value of 'ccp_present' Warning: include/linux/ccp.h:42 No description found for return value of 'ccp_version' Warning: include/linux/ccp.h:67 No description found for return value of 'ccp_enqueue_cmd' Warning: include/linux/ccp.h:97 cannot understand function prototype: 'enum ccp_aes_type' Warning: include/linux/ccp.h:114 cannot understand function prototype: 'enum ccp_aes_mode' Warning: include/linux/ccp.h:128 Enum value 'CCP_AES_MODE_GHASH' not described in enum 'ccp_aes_mode' Warning: include/linux/ccp.h:128 Enum value 'CCP_AES_MODE_GCTR' not described in enum 'ccp_aes_mode' Warning: include/linux/ccp.h:128 Enum value 'CCP_AES_MODE_GCM' not described in enum 'ccp_aes_mode' Warning: include/linux/ccp.h:128 Enum value 'CCP_AES_MODE_GMAC' not described in enum 'ccp_aes_mode' Warning: include/linux/ccp.h:134 cannot understand function prototype: 'enum ccp_aes_action' Warning: include/linux/ccp.h:190 struct member 'authsize' not described in 'ccp_aes_engine' Warning: include/linux/ccp.h:190 struct member 'aad_len' not described in 'ccp_aes_engine' Warning: include/linux/ccp.h:202 cannot understand function prototype: 'enum ccp_xts_aes_unit_size' Warning: include/linux/ccp.h:245 struct member 'type' not described in 'ccp_xts_aes_engine' Warning: include/linux/ccp.h:255 cannot understand function prototype: 'enum ccp_sha_type' Warning: include/linux/ccp.h:394 cannot understand function prototype: 'enum ccp_passthru_bitwise' Warning: include/linux/ccp.h:410 cannot understand function prototype: 'enum ccp_passthru_byteswap' Warning: include/linux/ccp.h:472 struct member 'src_dma' not described in 'ccp_passthru_nomap_engine' Warning: include/linux/ccp.h:472 struct member 'dst_dma' not described in 'ccp_passthru_nomap_engine' Warning: include/linux/ccp.h:472 Excess struct member 'src' description in 'ccp_passthru_nomap_engine' (did you mean one of: 'src_len', 'src_dma') Warning: include/linux/ccp.h:472 Excess struct member 'dst' description in 'ccp_passthru_nomap_engine' (did you mean one of: 'dst_dma') Warning: include/linux/ccp.h:489 cannot understand function prototype: 'enum ccp_ecc_function' Warning: include/linux/ccp.h:587 struct member 'u' not described in 'ccp_ecc_engine' Warning: include/linux/ccp.h:587 Excess struct member 'mm' description in 'ccp_ecc_engine' (did you mean one of: 'u.mm') Warning: include/linux/ccp.h:587 Excess struct member 'pm' description in 'ccp_ecc_engine' (did you mean one of: 'u.pm') Warning: include/linux/ccp.h:602 cannot understand function prototype: 'enum ccp_engine' Signed-off-by: Randy Dunlap <rdunlap@infradead.org> Acked-by: Tom Lendacky <thomas.lendacky@amd.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2026-09-16siphash: clean up kernel-doc commentsRandy Dunlap
Use the correct function parameter names and add function return value descriptions to avoid kernel-doc warnings: Warning: include/linux/siphash.h:82 function parameter 'len' not described in 'siphash' Warning: include/linux/siphash.h:82 No description found for return value of 'siphash' Warning: include/linux/siphash.h:132 function parameter 'len' not described in 'hsiphash' Warning: include/linux/siphash.h:132 No description found for return value of 'hsiphash' Signed-off-by: Randy Dunlap <rdunlap@infradead.org> Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
2026-09-16gpio: regmap: Add optional runtime PM supportJanani Sunil
Some gpio-regmap consumers share their regmap with a parent device that may be runtime suspended. GPIO register accesses must resume that device first. Add an optional pm_dev field and acquire it before register translation or access. Release it using runtime autosuspend after each operation. Keep the device active across the complete direction-output sequence and propagate failure when setting the initial output value. Reviewed-by: Andy Shevchenko <andriy.shevchenko@intel.com> Reviewed-by: Michael Walle <mwalle@kernel.org> Signed-off-by: Janani Sunil <janani.sunil@analog.com> Reviewed-by: Linus Walleij <linusw@kernel.org> Link: https://patch.msgid.link/20260910-ad7768-gpio-v8-2-6aaaa15adeb3@analog.com Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
2026-09-16Merge fdo/drm/drm-fixes into drm-misc-fixesMaxime Ripard
Backmerging to get drm-misc-fixes up to v7.3-rc3. Signed-off-by: Maxime Ripard <mripard@kernel.org>
2026-09-16platform/x86: asus-wmi: Add ASUS_WMI_DEVID_DGPU_POWER_STATE defineMarco Scardovi
Add WMI device ID 0x00120097 (ASUS_WMI_DEVID_DGPU_POWER_STATE) to the asus-wmi platform header. This device ID is used on ASUS ROG laptops to query the discrete GPU (dGPU) power state level. Suggested-by: Denis Benato <denis.benato@linux.dev> Signed-off-by: Marco Scardovi <scardracs@disroot.org> Link: https://patch.msgid.link/20260805183131.3075-2-scardracs@disroot.org Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
2026-09-15dmaengine: bestcomm: make gen_bd init helpers staticRosen Penev
bcom_gen_bd_rx_init() and bcom_gen_bd_tx_init() are only called from the PSC wrapper functions in gen_bd.c, so make them static, drop their now-unneeded exports, and remove the corresponding header declarations. These had use before commit 7d3ee229ea51 ("powerpc: Drop MPC5200 LocalPlus bus FIFO driver") Assisted-by: LLM Signed-off-by: Rosen Penev <rosenp@gmail.com> Reviewed-by: Frank Li <Frank.Li@nxp.com> Reviewed-by: Christophe Leroy (CS GROUP) <chleroy@kernel.org> Link: https://patch.msgid.link/20260913194804.39939-1-rosenp@gmail.com Signed-off-by: Vinod Koul <vkoul@kernel.org>
2026-09-15firmware: arm_scmi: Add ACPI PCC transportSudeep Holla
Add an SCMI transport for ACPI-described systems using PCCT PCC subspaces through the Linux PCC mailbox layer. Parse the SCMI Device Properties _DSD packages defined by Arm document 111115A v1.0, sections 2.2.1.1, 2.2.2.1 and 2.2.3. Map transport UIDs to PCC subspaces for common and protocol-exclusive A2P and P2A channels, validate the mappings, and cache them for channel setup. Support the Powercap and System Telemetry protocol properties and add the System Telemetry protocol ID. Implement PCC channel management, message framing, shared-memory bounds validation, and response and notification delivery. Add the corresponding Kconfig, module and ARML0001 ACPI matching plumbing. Link: https://patch.msgid.link/20260915-acpi_scmi_pcc-v5-7-298579e9f359@kernel.org Signed-off-by: Sudeep Holla <sudeep.holla@kernel.org>
2026-09-15dmaengine: add union chan_dev for dma_chan::dev for clarityFrank Li
The current dma_chan structure contains both "device" and "dev". So chan->device->dev refers to the DMA engine device. chan->dev->device refers to the per-channel device instance. Their similar naming makes the distinction unclear and increases reader confusion. Add union dma_chan::chan_dev to make its purpose explicit and clearly identify it as the per-channel device. After all user switch to chan_dev, union and dma_chan::dev will be removed. Update the kernel-doc accordingly. Besides its sysfs usage, the per-channel device is also used by some DMA engine drivers for IOMMU mapping and therefore deserves a more accurate description. No functional change intended. Reviewed-by: Logan Gunthorpe <logang@deltatee.com> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Frank Li <Frank.Li@nxp.com> Link: https://patch.msgid.link/20260909-dma-chan_dev-rename-v4-4-d8fb6892a70f@nxp.com Signed-off-by: Vinod Koul <vkoul@kernel.org>
2026-09-15dmaengine: add (dmaengine|vchan)_chan_dev() helperFrank Li
Add a new helper function (dmaengine|vchan)_chan_dev() to access the DMA channel device embedded in struct dma_chan_dev (chan->dev->device). This provides a cleaner API instead of open-coding &chan->dev->device throughout the drivers. Replay private chan2dev() and dchan2dev() with this new common APIs in indivial DMA engine drivers. Prepare rename dma_chan::dev field. Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Frank Li <Frank.Li@nxp.com> Link: https://patch.msgid.link/20260909-dma-chan_dev-rename-v4-3-d8fb6892a70f@nxp.com Signed-off-by: Vinod Koul <vkoul@kernel.org>
2026-09-15dmaengine: dw-edma: Add changes to support Channel SeparationDevendra K Verma
HDMA supports configurable DMA channel register space separation which ranges from 256B to 32KB. Current implementation supports 256B as default for DMA channel register space. CPM6 supports the selection of channel register space via VSEC. The default value for channel register space for CPM6 is 512B. Updated the functions and methods to calculate the DMA channel registers base address as per the selected channel separation available as part of 'ch_space_sz'. Removed the unused function __dw_regs() and structs, namely dw_hdma_v0_ch and dw_hdma_v0_regs. Signed-off-by: Devendra K Verma <devverma@amd.com> Reviewed-by: Frank Li <Frank.Li@nxp.com> Link: https://patch.msgid.link/20260907101213.1917064-3-devverma@amd.com Signed-off-by: Vinod Koul <vkoul@kernel.org>
2026-09-15remoteproc: k3-dsp: Fix usage of omap_mbox_message and mbox_msg_tAndrew Davis
The type of message sent using omap-mailbox is always u32. The definition of mbox_msg_t is uintptr_t which is wrong as that type changes based on the architecture (32bit vs 64bit). Make the type fixed to u32. This then means we need to fix the helper macro omap_mbox_message so it doesn't cast to u32 twice. What this macro should be doing is converting from the message type returned from the mailbox framework into the omap-mailbox type. When fixing this we should add a macro for the other direction (from omap-mailbox type to something that can be used with mbox_send_message). After these changes, make use of the new macros as appropriate. Signed-off-by: Andrew Davis <afd@ti.com> Reviewed-by: Beleswar Padhi <b-padhi@ti.com> Tested-by: Beleswar Padhi <b-padhi@ti.com> Link: https://lore.kernel.org/r/20260904195634.2275867-2-afd@ti.com Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org>
2026-09-15block: serialize zone revalidationDamien Le Moal
The zone related fields of struct gendisk can be modified by blk_revalidate_disk_zones() either on the first scan of the disk, or during user triggered scans or device revalidation, if some characteristics of the disk has changed (e.g. the disk capacity). Changes to these fields are always done with the disk request queue frozen so that BIO processing does not see any inconsistent state of the zones. This implies a contract that reading these zone related fields must always be done while holding a usage count on the request queue of the disk. However, increasing the usage count of the disk request queue cannot be done from the context of blk_revalidate_disk_zones() itself, as that would prevent freezing the disk queue and result in a deadlock. This prevents blk_revalidate_disk_zones() from consulting the zone related fields of struct gendisk to detect, for instance, a change in the number of zones of the disk. For such case, we want to detect the change, take appropriate measures and revalidate exclusively revalidate the zones to avoid concurrent revalidation calls to see the same change while corrections are already on-going. A simple solution to avoid this issue is to introduce a mutex to serialize calls to blk_revalidate_disk_zones() and ensure only a single context at a time can modify the zone related fields of a gendisk. In preparation for handling disk capacity revalidation in blk_revalidate_disk_zones(), do so with the mutex zone_revalidate_mutex. This mutex is initialized in disk_init_zone_resources(), destroyed in disk_release_zone_resources() and taken and released only in blk_revalidate_disk_zones() to serialize the execution of this function. Signed-off-by: Damien Le Moal <dlemoal@kernel.org> Reviewed-by: Hannes Reinecke <hare@kernel.org> Reviewed-by: Christoph Hellwig <hch@lst.de> Link: https://patch.msgid.link/20260908085745.1082697-10-dlemoal@kernel.org Signed-off-by: Jens Axboe <axboe@kernel.dk>
2026-09-15block: remember a zone type regardless of its conditionDamien Le Moal
Currently, bdev_zone_is_seq() identifies a sequential zone by looking at the zone condition, assuming that any zone that does not have the condition BLK_ZONE_COND_NOT_WP is a sequential write required zone. That is correct only as long as the target zoned device does not support storage element depopulation (aka HDD head depopulation), which is a feature that can transition conventional zones to the read-only or offline condition. For such device, we cannot distinguish anymore between conventional and sequential zones using the zone condition as both zone types can have the same conditions. Prepare for fully supporting storage element depopulation and restoration by caching the type of a zone in addition to its condition. This is implemented by reformating the zones_cond array using a more compact zone condition representation with the new enum blk_zstate. This zone condition representation only uses the lower 4 bits of a byte for the condition values, thus leaving the high order 4 bits of each byte entry of the array for flags. The flag BLK_ZFLAG_CONV is defined to indicate conventional zones. The helper functions blk_zstate_to_zone_cond() and blk_zone_cond_to_zstate() are implemented using lookup tables to convert between enum blk_zone_condition values and enum blk_zstate zone condition values. The helper blk_zstate_set() can be used to set a zones_state entry with a zone condition and zone type flags, safely in accordance to the size of the zone state array being accessed. This helper is used in disk_zone_set_cond() to update a zone condition. bdev_zone_is_seq() is modified to use the flags of the zones_state array entries to identify sequential zones. The zones_state array initialization and revalidation is unchanged from the former zones_cond array. Overall, any zone condition that is being considered outside of the zones_state array always uses the enum blk_zone_condition values as before, thus minimizing the number of changes. Signed-off-by: Damien Le Moal <dlemoal@kernel.org> Reviewed-by: Bart Van Assche <bvanassche@acm.org> Reviewed-by: Christoph Hellwig <hch@lst.de> Reviewed-by: Hannes Reinecke <hare@kernel.org> Reviewed-by: Johannes Thumshirn <johannes.thumshirn@wdc.com> Link: https://patch.msgid.link/20260908085745.1082697-6-dlemoal@kernel.org Signed-off-by: Jens Axboe <axboe@kernel.dk>
2026-09-15ata: libata: Do not leave ata_host_stop() registered when activation failsNiklas Cassel
ata_host_start() registers ata_host_stop() as a devres action as soon as it has succeeded, which hands the release of the host resources over to devres: ->port_stop() and ->host_stop() are then called by the driver core when probe() fails. ata_host_activate() and ahci_host_activate_multi_irqs() can both fail after ata_host_start() has succeeded, e.g. if devm_request_irq() or ata_host_register() fails, and they return the error with the devres action still registered. A driver which releases the host resources in its probe() error path therefore releases them twice: once itself and once through ->host_stop(). All ahci-platform drivers are in that situation, e.g. ahci_probe() calls ahci_platform_disable_resources() while ahci_host_stop() does the same through devres. This gives refcount underflow warnings from the clk, regulator and phy cores and, for shared resources, can disable resources which are still in use by other devices. Add ata_host_undo_start(), which stops the ports and drops the devres action without calling ->host_stop(), and call it from both activation helpers when they fail. Releasing the host resources on failure is then always left to the caller, which is what all callers having a probe() error path already assume. This changes the semantics for the drivers which implement ->host_stop() while also completely lacking error handling for the activate host call. Add activate host error handling for sata_qstor and sata_fsl. For sata_fsl this also means that hcr_base and host_priv are now released when activating the host fails, which ->host_stop() did not do when ata_host_start() itself failed. Note that ata_pci_sff_activate_host() is deliberately left as is: none of its callers releases the host resources in its probe() error path, they all rely on ->host_stop() being called by devres, including ata_pci_init_one(), which releases the devres group of the host itself. Fixes: 1896b15eddb4 ("ahci_platform: perform platform exit in host_stop() hook") Cc: stable@vger.kernel.org Reviewed-by: Damien Le Moal <dlemoal@kernel.org> Link: https://lore.kernel.org/r/20260915084127.692494-13-cassel@kernel.org Signed-off-by: Niklas Cassel <cassel@kernel.org>
2026-09-15dma-buf/dma-fence: fix checking signaling bit for timeline and driver name v3Christian König
The patch "dma-buf: dma-fence: Fix potential NULL pointer dereference" changed the check to test for the ops pointer instead of the signaled bit to avoid a potential NULL dereference when the ops pointer has been cleared. The problem is now that the ops pointer is cleared only when neither the release nor the wait callback is implemented and this isn't true for a lot of dma_fence implementations yet. So those implementations lost the RCU protection after signaling of the returned string resulting in potential use after free. Add the signaling check additional to the ops pointer check so that we have both the protection against NULL dereference as well as the RCU protection after signaling for the returned string. v2: improve comments to note RCU protection and explain why we check both signaling state and ops pointer v3: some comment improvements suggested by Philip Signed-off-by: Christian König <christian.koenig@amd.com> Fixes: 035219a760ed ("dma-buf: dma-fence: Fix potential NULL pointer dereference") CC: stable@vger.kernel.org # 7.2+ Reported-by: Jonghyuk Kim(MalHyuk) <malhyuk97@gmail.com> Tested-by: Jonghyuk Kim(MalHyuk) <malhyuk97@gmail.com> Reviewed-by: Philipp Stanner <phasta@kernel.org> Link: https://lore.kernel.org/r/20260914182740.1587-1-christian.koenig@amd.com
2026-09-15phy: core: Define TBT phy_modeKonrad Dybcio
There exist OS-accessible USB4 and Thunderbolt PHYs that need specific configuration. Define a new phy_mode for them. Currently, USB4 and TBT3 are defined as submodes, because they're quite distinct, most visibly in the electrical/analog aspects (slightly different frequencies, timings, etc.). This results in a need to make the PHY aware of the actual mode needed (at least in the Qualcomm implementation, but I believe that'll be a general need). Newer versions of TBT are basically supersets of USB4 with higher host-side requirements, so these are not defined. This can always be changed as necessary. Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Reviewed-by: Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com> Signed-off-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Link: https://patch.msgid.link/20260908-topic-usb4phy-v5-2-73aac69578ef@oss.qualcomm.com Signed-off-by: Vinod Koul <vkoul@kernel.org>
2026-09-14net: rtnetlink: add pacing_offload attribute to net_deviceWillem de Bruijn
Add a new flag to administratively control pacing offload. The feature is disabled by default. That does not cause regressions, as no driver advertises max_pacing_offload_horizon yet. Also add NLA_REJECT for max_pacing_offload_horizon, in line with other such read-only members of link-attrs. Both fields can be read with ynl --family rt-link --do getlink \ --json '{"ifname": "eth0"}' | grep pacing And pacing offload enabled with ynl --family rt-link --do setlink \ --json '{"ifname": "eth0", "pacing-offload": 1}' Signed-off-by: Willem de Bruijn <willemb@google.com> Link: https://patch.msgid.link/20260910171131.2532487-2-willemdebruijn.kernel@gmail.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-09-15firewire: core: correct comment about execution contextTakashi Sakamoto
The comment for fw_address_callback_t describes the execution context, but the callback has not been called from RCU read-side critical section since v6.17. Fixes: e884a8a0c573 ("firewire: core: call FCP address handlers outside RCU read-side critical section") Fixes: e8cf6875005b ("firewire: core: call handler for exclusive regions outside RCU read-side critical section") Link: https://lore.kernel.org/r/20260914221434.213633-1-o-takashi@sakamocchi.jp Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
2026-09-14lsm: Preserve full ioctl commands in audit recordsMickaël Salaün
Ioctl commands are unsigned int values, with their encoded direction and size in the upper 16 bits. However, struct lsm_ioctlop_audit keeps only a u16, and the common audit formatter uses %hx. This logs 0xc00ffeee as 0xfeee and makes distinct commands with matching low 16 bits indistinguishable. Change cmd to unsigned int and use %x. Pass the full command through ioctl_has_perm() as well. Its driver and xperm values remain u8 values derived from the same low 16 bits, so SELinux enforcement does not change. Commands that fit in 16 bits keep the same audit text. Cc: Jeff Vander Stoep <jeffv@google.com> Cc: Paul Moore <paul@paul-moore.com> Fixes: 671a2781ff01 ("security: add ioctl specific auditing to lsm_audit") Signed-off-by: Mickaël Salaün <mic@digikod.net> Signed-off-by: Paul Moore <paul@paul-moore.com>
2026-09-14f2fs: parameterize node helpers and macrosChao Yu
In gang-lookup loops such as last_fsync_dnode(), f2fs_sync_node_pages(), and f2fs_fsync_node_pages(), candidate dirty node folios returned by filemap_get_folios_tag() are inspected and filtered before acquiring their folio locks: - IS_DNODE - is_cold_node - ino_of_node - ofs_of_node (called by IS_DNODE) These helpers previously relied on F2FS_F_SB(folio) which dereferences folio->mapping to obtain sbi. This can suffer a race condition with concurrent node truncation, causing a NULL pointer dereference panic: Thread A Thread B - f2fs_sync_node_pages - filemap_get_folios_tag - truncate_node - invalidate_mapping_pages - filemap_remove_folio - folio->mapping = NULL - IS_DNODE - F2FS_F_SB - folio->mapping->host (panic) To resolve this race condition, pass struct f2fs_sb_info *sbi explicitly to these helpers. All these helpers fundamentally rely on F2FS_NODE_FOOTER(), which dynamically locates the node footer at: folio_address(folio) + F2FS_BLKSIZE(sbi) - sizeof(struct node_footer). Consequently, F2FS_NODE_FOOTER() and its direct sibling footer accessors: - IS_INODE - nid_of_node - cpver_of_node - next_blkaddr_of_node are also parameterized with struct f2fs_sb_info *sbi. In get_dnode_base() and get_dnode_addr(), derive sbi safely via `inode ? F2FS_I_SB(inode) : F2FS_F_SB(node_folio)` to support callers passing NULL inode (e.g. is_alive()). Signed-off-by: Chao Yu <chao@kernel.org> Signed-off-by: Jaegeuk Kim <jaegeuk@kernel.org>
2026-09-14f2fs: parameterize block size and mask macrosKelvin Zhang
Block size constants, shift counts, masks, and page-to-block ratios were globally defined assuming a fixed 4KB block size. Parameterize F2FS_BLKSIZE, F2FS_BLKSIZE_BITS, F2FS_BLKSIZE_MASK, F2FS_BLKS_PER_PAGE, and CP_CHKSUM_OFFSET with struct f2fs_sb_info *sbi to reference sbi->blocksize, sbi->log_blocksize, and runtime masks. Update call sites across metadata operations, data I/O, file operations, garbage collection, inline data, and sysfs information. Signed-off-by: Kelvin Zhang <zhangxp1998@gmail.com> Reviewed-by: Chao Yu <chao@kernel.org> Signed-off-by: Jaegeuk Kim <jaegeuk@kernel.org>
2026-09-14f2fs: describe node tree geometry dynamicallyKelvin Zhang
The file indexing tree boundaries separating direct, indirect, and double-indirect node blocks depend on the number of data block addresses and node IDs contained in each node block. Parameterize index boundary macros (NODE_DIR1_BLOCK, NODE_DIR2_BLOCK, NODE_IND1_BLOCK, NODE_IND2_BLOCK, and NODE_DIND_BLOCK) and address capacity helpers (DEF_ADDRS_PER_BLOCK, NIDS_PER_BLOCK, cur_addrs_per_inode, addrs_per_page, and addrs_per_folio) with struct f2fs_sb_info *sbi. Update file mapping, block allocation, truncate, garbage collection, and recovery paths to compute indexing tree offsets from the runtime geometry. Signed-off-by: Kelvin Zhang <zhangxp1998@gmail.com> Reviewed-by: Chao Yu <chao@kernel.org> Signed-off-by: Jaegeuk Kim <jaegeuk@kernel.org>
2026-09-14f2fs: parameterize byte and block conversion macrosKelvin Zhang
Byte-to-block and block-to-byte conversion helpers previously relied on global PAGE_SIZE, PAGE_SHIFT, or F2FS_BLKSIZE_BITS. Parameterize F2FS_BYTES_TO_BLK, F2FS_BLK_TO_BYTES, F2FS_BLK_END_BYTES, F2FS_BLK_ALIGN, and max_file_blocks with struct f2fs_sb_info *sbi using sbi->log_blocksize. Update all call sites across data mapping, file operations, fiemap queries, fsverity checks, NAT bitmap allocations, and truncate paths. Signed-off-by: Kelvin Zhang <zhangxp1998@gmail.com> Reviewed-by: Chao Yu <chao@kernel.org> Signed-off-by: Jaegeuk Kim <jaegeuk@kernel.org>
2026-09-14f2fs: parameterize sector conversion macrosKelvin Zhang
Sector-to-block and block-to-sector conversion helpers previously assumed a fixed sector count per block derived from 4KB pages. Parameterize F2FS_LOG_SECTORS_PER_BLOCK, SECTOR_FROM_BLOCK, and SECTOR_TO_BLOCK with struct f2fs_sb_info *sbi, using sbi->log_sectors_per_block. Update all call sites across metadata I/O, data mapping, discard operations, and zoned block device reporting. Signed-off-by: Kelvin Zhang <zhangxp1998@gmail.com> Reviewed-by: Chao Yu <chao@kernel.org> Signed-off-by: Jaegeuk Kim <jaegeuk@kernel.org>
2026-09-14f2fs: describe xattr block layout dynamicallyKelvin Zhang
The usable capacity of dedicated on-disk extended attribute blocks and inline xattr regions scales with the filesystem block size. Parameterize VALID_XATTR_BLOCK_SIZE and MAX_INLINE_XATTR_SIZE to calculate usable xattr limits dynamically from sbi->blocksize rather than hardcoding PAGE_SIZE or DEF_ADDRS_PER_INODE. Update mount option consistency validation for inline_xattr_size to evaluate allowed boundaries dynamically against the runtime block size. Signed-off-by: Kelvin Zhang <zhangxp1998@gmail.com> Reviewed-by: Chao Yu <chao@kernel.org> Signed-off-by: Jaegeuk Kim <jaegeuk@kernel.org>
2026-09-14f2fs: describe {i,d,id}node block layout dynamicallyKelvin Zhang
An inode block ends with five i_nid entries followed by a node footer. Data block address pointers (i_addr[]) precede them. Similarly, direct and indirect node blocks contain data addresses or node IDs followed by a node footer at the end of the block. Describe struct f2fs_inode, struct direct_node, and struct indirect_node using flexible array members. Compute the locations of i_nid and node footers dynamically from the filesystem block size. Introduce F2FS_INODE_NIDS() and F2FS_NODE_FOOTER() helpers to access these tail fields. Compute sbi->addrs_per_inode, sbi->addrs_per_block, and sbi->nids_per_block in init_sb_info(), and update node management, file mapping, and recovery paths accordingly. Signed-off-by: Kelvin Zhang <zhangxp1998@gmail.com> Reviewed-by: Chao Yu <chao@kernel.org> Signed-off-by: Jaegeuk Kim <jaegeuk@kernel.org>
2026-09-14f2fs: describe dentry block layout dynamicallyKelvin Zhang
An on-disk directory block contains a bitmap, reserved padding, an array of directory entries (struct f2fs_dir_entry), and matching filename slots. A fixed compile-time structure couples their offsets to 4KB blocks and relies on static reserved-space definitions. Remove struct f2fs_dentry_block and compute region offsets (bitmap bytes, directory-entry count, and filename slots) dynamically from the filesystem block size. Access directory blocks through struct f2fs_dentry_ptr views initialized with the runtime geometry. Update directory operations, inline dentry handling, and recovery paths to use the dynamic block layout. No functional change is introduced for 4KB blocks. Signed-off-by: Kelvin Zhang <zhangxp1998@gmail.com> Reviewed-by: Chao Yu <chao@kernel.org> Signed-off-by: Jaegeuk Kim <jaegeuk@kernel.org>
2026-09-14f2fs: describe orphan block layout dynamicallyKelvin Zhang
An on-disk orphan block contains a variable-length array of 32-bit inode numbers followed by a fixed footer at the end of the block. A compile-time whole-block structure cannot represent the footer position when the block size varies at runtime. Remove struct f2fs_orphan_block, introduce struct f2fs_orphan_block_footer, and compute sbi->orphans_per_block dynamically in init_sb_info(). Add helpers to access the inode entry array and footer from a block buffer. Update orphan inode recovery, checkpointing, and mount paths to use the parameterized helpers. This preserves the on-disk format while decoupling orphan handling from compile-time constants. Signed-off-by: Kelvin Zhang <zhangxp1998@gmail.com> Reviewed-by: Chao Yu <chao@kernel.org> Signed-off-by: Jaegeuk Kim <jaegeuk@kernel.org>
2026-09-14f2fs: describe NAT block layout dynamicallyKelvin Zhang
A NAT block is a filesystem-block-sized array of struct f2fs_nat_entry elements. The compile-time NAT_ENTRY_PER_BLOCK definition hardcodes the NAT capacity to a 4KB block size. Replace the fixed array in struct f2fs_nat_block with a C flexible array member, and calculate sbi->nat_entries_per_block dynamically in init_sb_info(). Parameterize NAT geometry helpers (NAT_ENTRY_PER_BLOCK, NAT_BLOCK_OFFSET, f2fs_start_nid, NAT_BLK_CNT, and f2fs_nat_bitmap_size) with sbi. Update call sites across node management, checkpointing, GC, and sysfs. This is a layout-only change without behavioral differences for 4KB blocks. Signed-off-by: Kelvin Zhang <zhangxp1998@gmail.com> Reviewed-by: Chao Yu <chao@kernel.org> Signed-off-by: Jaegeuk Kim <jaegeuk@kernel.org>
2026-09-14f2fs: describe SIT block layout dynamicallyKelvin Zhang
An SIT block consists of an on-disk array of struct f2fs_sit_entry elements whose total capacity depends on the filesystem block size. The existing fixed SIT_ENTRY_PER_BLOCK macro hardcodes a 4KB block size. Convert the entries array in struct f2fs_sit_block into a C flexible array member, and calculate sbi->sit_entries_per_block dynamically in init_sb_info(). Parameterize SIT indexing helpers (SIT_ENTRY_PER_BLOCK, SIT_BLOCK_OFFSET, SIT_BLK_CNT, and f2fs_start_segno) to take struct f2fs_sb_info *sbi, and update all call sites across segment management, checkpointing, and mount. This is a layout-only change; valid 4KB filesystems retain identical runtime geometry and behavior. Signed-off-by: Kelvin Zhang <zhangxp1998@gmail.com> Reviewed-by: Chao Yu <chao@kernel.org> Signed-off-by: Jaegeuk Kim <jaegeuk@kernel.org>
2026-09-14x86,fs/resctrl: Add resctrl_arch_preconvert_bw()Dave Martin
On MPAM systems the rounding behaviour of the MBA control would be improved if the rounding in the fs/resctrl code is removed but this is not the case for x86. To allow any rounding or conversion of the bandwidth value provided by the user to be specified by the arch code a new arch hook is required. Introduce resctrl_arch_preconvert_bw(), and add its x86 implementation. This is currently unused in resctrl but when plumbed in it will replace the call to roundup() in bw_validate(). Signed-off-by: Dave Martin <dave.martin@arm.com> Signed-off-by: Ben Horgan <ben.horgan@arm.com> Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de> Reviewed-by: Reinette Chatre <reinette.chatre@intel.com> Reviewed-by: Gavin Shan <gshan@redhat.com> Link: https://patch.msgid.link/20260911163613.1131447-2-ben.horgan@arm.com
2026-09-14block,iomap: remove the old read side bounce buffering supportChristoph Hellwig
bio_iov_iter_bounce_read turned to generate suboptimal I/O sizes and isn't usable for lazy bounce buffering. Now that is has been replaced with the iomap side implementation that requires extra bounce bios, it is unused and can be removed. Change the interface so that the previously hidden write-side implementation is directly exposed. Signed-off-by: Christoph Hellwig <hch@lst.de> Reviewed-by: "Darrick J. Wong" <djwong@kernel.org> Link: https://patch.msgid.link/20260909060924.1102037-17-hch@lst.de Signed-off-by: Jens Axboe <axboe@kernel.dk>
2026-09-14iomap,xfs: move integrity verification to the file systemChristoph Hellwig
Integrity support in file systems already requires file system-specific completion handling because it must be run in process context. Move the actual verification to the file system so that it can better handle errors in file system specific ways, and to support lazy bounce buffering. Signed-off-by: Christoph Hellwig <hch@lst.de> Reviewed-by: "Darrick J. Wong" <djwong@kernel.org> Link: https://patch.msgid.link/20260909060924.1102037-13-hch@lst.de Signed-off-by: Jens Axboe <axboe@kernel.dk>
2026-09-14iomap: better read bounce buffering supportChristoph Hellwig
Add helpers to bounce buffer an upper bio into one or more lower bios using bounce buffers, and to copy the data back on completion. Compared to the existing IOMAP_DIO_BOUNCE support for read bios, this has two advantages: by removing the special bounce bio_vec it allows to the full and "round" size of a single bio, i.e., 1MiB when using 4k pages. This is important for good performance on HDD. Additionally it allows to bounce buffer a bio from completion conext, and thus implement a "lazy" bounce buffering scheme, where the data is only read into a bounce buffer after an initial checksum validation failure, thus avoiding the bounce buffering I/O for most I/O. Signed-off-by: Christoph Hellwig <hch@lst.de> Reviewed-by: "Darrick J. Wong" <djwong@kernel.org> Link: https://patch.msgid.link/20260909060924.1102037-11-hch@lst.de Signed-off-by: Jens Axboe <axboe@kernel.dk>
2026-09-14block,iomap: fix protection information verification with initial bvec offsetChristoph Hellwig
When reconstructing a bvec_iter from an ioend for protection information verification, iomap currently ignores the offset into the initial bio_vec. This can't happen for buffered I/O or direct I/O to user addresses, but is exercised by splice on O_DIRECT file descriptors or when using the loop driver in direct I/O mode. Fortunately the only file system PI user (XFS) currently always bounce buffers, so this can't actually be triggered yet. But we'll want to make the bounce buffering conditional soon, for which this needs to be fixed. Store the initial offset in struct iomap_ioend, and pass a pre-constructed bvec_iter to fs_bio_integrity_verify. For the synchronous read case the fix is even simpler as this path can simply stash away the original bvec_iter. Fixes: 0bde8a12b554 ("block: add fs_bio_integrity helpers") Signed-off-by: Christoph Hellwig <hch@lst.de> Reviewed-by: "Darrick J. Wong" <djwong@kernel.org> Link: https://patch.msgid.link/20260909060924.1102037-10-hch@lst.de Signed-off-by: Jens Axboe <axboe@kernel.dk>
2026-09-14iomap: add a IOMAP_IOEND_INTEGRITY flagChristoph Hellwig
This will make it easier to share code for the various submit callback provided by the file system to iomap. Signed-off-by: Christoph Hellwig <hch@lst.de> Reviewed-by: "Darrick J. Wong" <djwong@kernel.org> Link: https://patch.msgid.link/20260909060924.1102037-7-hch@lst.de Signed-off-by: Jens Axboe <axboe@kernel.dk>
2026-09-14iomap: add a iomap_ioend_flags helperChristoph Hellwig
Add a helper to initialize the ioend flags to the values that can be directly derived from the iomap. Signed-off-by: Christoph Hellwig <hch@lst.de> Reviewed-by: "Darrick J. Wong" <djwong@kernel.org> Link: https://patch.msgid.link/20260909060924.1102037-6-hch@lst.de Signed-off-by: Jens Axboe <axboe@kernel.dk>
2026-09-14block: pass a maxlen argument to bio_iov_iter_get_pagesChristoph Hellwig
Writes that require additional per-I/O allocations such as when using file system level protection information can be limited to a maximum size. Allow passing that to bio_iov_iter_get_pages. Signed-off-by: Christoph Hellwig <hch@lst.de> Signed-off-by: Jens Axboe <axboe@kernel.dk>
2026-09-14dma-fence: Fix dma_fence_enable_signaling() reference in kernel-docKarl Mehltretter
The kernel-doc comment of dma_fence_is_signaled_locked() refers to dma_fence_enable_sw_signaling, which was renamed to dma_fence_enable_signaling by commit 9370a5c664e8 ("dma-buf: rename dma_fence_enable_sw_signaling"). Say dma_fence_enable_signaling. Fixes: 9370a5c664e8 ("dma-buf: rename dma_fence_enable_sw_signaling") Assisted-by: LLM Signed-off-by: Karl Mehltretter <kmehltretter@gmail.com> Reviewed-by: Christian König <christian.koenig@amd.com> Signed-off-by: Christian König <christian.koenig@amd.com> Link: https://lore.kernel.org/r/20260911221100.7079-1-kmehltretter@gmail.com
2026-09-14tracing: Include linux/types.h in trace_remote_event.hFuad Tabba
trace_remote_event.h uses bool without including linux/types.h, so a translation unit that includes it ahead of anything else that pulls types.h in fails to build, as with nvhe/trace.h at EL2. Reviewed-by: Vincent Donnefort <vdonnefort@google.com> Reviewed-by: Marc Zyngier <maz@kernel.org> Acked-by: Steven Rostedt <rostedt@goodmis.org> Signed-off-by: Fuad Tabba <fuad.tabba@linux.dev> Acked-by: Steven Rostedt <rostedt@goodmis.org.> Link: https://patch.msgid.link/20260901140326.3812068-2-fuad.tabba@linux.dev Signed-off-by: Marc Zyngier <maz@kernel.org>
2026-09-14KVM: arm64: gic-v5: Implement VPE IRS MMIO OpsSascha Bischoff
Introduce interfaces to make VPEs valid, and to configure them, via the host's IRS. As with the other valid bits in the GICv5 VM tables, VPEs cannot be made valid directly, and instead are made valid via an IRS MMIO Op. Additionally, some of the VPE configuration takes place via the IRS MMIO interface too (via the IRS_VPE_CR0, IRS_VPE_DBR). VPE doorbells are, for example, configured via this interface. The existing VPE-doorbell-based commands are extended with: VPE_MAKE_VALID - Make the VPE valid in the VPET Note: There is no VPE_MAKE_INVALID as VPEs are only made invalid on teardown, at which point the whole VMTE is marked as invalid. Hence, it is not required. Signed-off-by: Sascha Bischoff <sascha.bischoff@arm.com> Link: https://patch.msgid.link/20260904113404.4051341-14-sascha.bischoff@arm.com Signed-off-by: Marc Zyngier <maz@kernel.org>
2026-09-14KVM: arm64: gic-v5: Introduce guest IST alloc and managementSascha Bischoff
GICv5 guests use Interrupt State Tables (ISTs) to track and manage the interrupt state for SPIs and LPIs. These ISTs are provided to the host's IRS via the VMTE. On a host GICv5 system, SPIs do not require any up-front memory allocation prior to their use, unlike LPIs which require the OS to allocate an IST. For a GICv5 guest, the same holds from the guest's point of view: SPIs should require no explicit memory allocation by the guest. This means that KVM must provision the memory passed to the IRS for managing a guest's SPI state. Introduce the machinery needed to allocate a linear SPI IST. A later commit will allocate it as part of VM creation, before running the guest for the first time. The host is responsible for freeing this memory on guest teardown. For LPIs, the guest provisions memory for its LPI IST. KVM does not pass that memory directly to the host IRS. Instead, add support for allocating a shadow LPI IST and passing that to the IRS through the VMTE. The LPI IST may be allocated as a two-level structure when supported and required by the configured LPI ID space, as many more LPIs are expected than SPIs. The host frees this memory on guest teardown. Assigning an IST to a VM requires an IRS operation rather than writing the Valid bit directly in the VMTE. Extend the doorbell command interface with the operations needed to make SPI and LPI ISTs valid or invalid. Together with the existing VMT commands, the command set is: VMT_L2_MAP - Make a second level VM table valid VMTE_MAKE_VALID - Make a single VMTE, and hence VM, valid VMTE_MAKE_INVALID - Make a single VMTE, and hence VM, invalid SPI_VIST_MAKE_VALID - Make the SPI IST valid LPI_VIST_MAKE_VALID - Make the LPI IST valid LPI_VIST_MAKE_INVALID - Make the LPI IST invalid Once implemented, irq_set_vcpu_affinity() will act as an ioctl-like interface for issuing commands specific to either a VM or the particular VPE that the doorbell belongs to. None of these commands are plumbed through to the host IRS at this stage. There is intentionally no SPI_VIST_MAKE_INVALID command. The SPI IST will be allocated as part of VM creation and will remain valid for the lifetime of the VM. It can be freed after the VMTE has been made invalid during teardown. The LPI IST, on the other hand, is driven by the guest, which is free to invalidate and free its LPI IST at any point. Signed-off-by: Sascha Bischoff <sascha.bischoff@arm.com> Link: https://patch.msgid.link/20260904113404.4051341-11-sascha.bischoff@arm.com Signed-off-by: Marc Zyngier <maz@kernel.org>
2026-09-14KVM: arm64: gic-v5: Create and manage VM and VPE tablesSascha Bischoff
GICv5 uses a set of in-memory tables to track and manage VM state. These must be allocated by the hypervisor and provided to the IRS. The VMT (Virtual Machine Table) is a linear or two-level table comprising VMT Entries (VMTEs). Each VMTE describes the state for a single VM. This state includes things such as the SPI and LPI IST configuration (coming in a future commit), an implementation-defined VM Descriptor, and a VPE Table (VPET). The VPET contains one entry per possible VPE ID belonging to a VM. It is used to mark a VPE as valid and provide the address of an implementation-defined VPE Descriptor (VPED), which the hardware uses to track and manage VPE state. Allocate each VM's VPEDs as a single dense array indexed by vcpu_idx, while the VPET remains indexed by the userspace-provided vcpu_id. This keeps VPED storage proportional to the number of vCPUs even when their IDs are sparse. The VMT and VPET are shared with the IRS. On systems with a non-coherent IRS, cache maintenance operates at cache-line granularity, while multiple entries can occupy the same cache line. Use a common lock for CPU accesses to these tables and IRS command processing so that writing back one entry cannot overwrite an IRS update to a neighbouring entry. The implementation-defined VMD and VPED storage is also visible to the IRS. Round these allocations up to whole cache lines to prevent cache maintenance from corrupting unrelated slab objects. Initialise the storage before publishing its addresses to the IRS. This commit adds support for allocating the VMT and its descriptor backing state, and for managing VMTEs. The VMTEs can be initialised or released for reuse. VM IDs are allocated with an IDA, while an XArray tracks the host-side allocations associated with populated VMTEs. Signed-off-by: Sascha Bischoff <sascha.bischoff@arm.com> Link: https://patch.msgid.link/20260904113404.4051341-10-sascha.bischoff@arm.com Signed-off-by: Marc Zyngier <maz@kernel.org>
2026-09-14KVM: arm64: gic-v5: Add VPE doorbell domainSascha Bischoff
VPE doorbells allow the GICv5 hardware to notify KVM when an SPI or LPI can be signalled to a non-resident VPE. This provides the mechanism used to wake blocked vcpus once the hardware determines that the interrupt is eligible to be delivered. Add support for a per-VM VPE doorbell irq domain. The domain is created under the GICv5 LPI domain, with one doorbell allocated per VPE. Store the allocated doorbell base in the VM's GICv5 state so that later patches can request per-vcpu doorbell IRQs and use them for IRS commands and wakeups. Add the per-VPE doorbell state to the GICv5 CPU interface state. The doorbell IRQ number is populated when the IRQs are requested, and the db_fired state is used by later patches once doorbell delivery is wired up. Signed-off-by: Sascha Bischoff <sascha.bischoff@arm.com> Link: https://patch.msgid.link/20260904113404.4051341-9-sascha.bischoff@arm.com Signed-off-by: Marc Zyngier <maz@kernel.org>
2026-09-14KVM: arm64: gic-v5: Define remaining IRS MMIO registersSascha Bischoff
Complete the set of defined IRS MMIO registers in the GICv5 header file. Up until now, the set of defined IRS MMIO registers has been driven by code requirements. However, in order to properly emulate the IRS MMIO interface in KVM, the full set of IRS MMIO registers needs to be added. Signed-off-by: Sascha Bischoff <sascha.bischoff@arm.com> Link: https://patch.msgid.link/20260904113404.4051341-5-sascha.bischoff@arm.com Signed-off-by: Marc Zyngier <maz@kernel.org>
2026-09-14irqchip/gic-v5: Provide OF IRS config frame attrs to KVMSascha Bischoff
KVM needs to interact with the host IRS in order to, for example, make VMs or VPEs valid. There are two potential approaches here. Either the host irqchip driver can provide an interface, or KVM can interact directly with the host IRS. The latter of these two is chosen as the set of MMIO registers that KVM needs to interact with is orthogonal to the set used by the host irqchip driver (with the exception of some of the read-only IRS_IDRx registers). Pass KVM a pointer to an IRS config frame - the config frame belonging to ANY IRS is fine as long as one IRS's config frame is used consistently - in struct gic_kvm_info. Additionally, include a flag telling KVM whether the IRS is coherent or non-coherent in order to make sure that KVM can do the correct cache state management, if required. Only OF (Device Tree) is supported with this change. ACPI is not. Signed-off-by: Sascha Bischoff <sascha.bischoff@arm.com> Link: https://patch.msgid.link/20260904113404.4051341-3-sascha.bischoff@arm.com Signed-off-by: Marc Zyngier <maz@kernel.org>
2026-09-14thunderbolt: Add tb_ring_poll_pending()Mika Westerberg
This helper can be used to figure out whether tb_ring_poll() has a frame to be returned. This can be used without the caller needing to take its own lock. Assisted-by: LLM Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2026-09-13Merge tag 'x86_urgent_for_7.3-rc4' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip Pull x86 fixes from Dave Hansen: "The most notable fix is THP not silently losing user data and having been around for a couple of years. The main explanation I'd have for its longevity is that it requires a few different things to align at the same time: MADV_FREE, THP and heavy reclaim. - Fix user-space data loss with THP - Fix set_memory oopses - Fix addition of large constants in mul_u64_add_u64_div_u64() - Fix FineIBT hash offset in cfi_get_func_hash() - Fix PCI device reference counting in amd_smn_init()" * tag 'x86_urgent_for_7.3-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: x86/amd_node: Fix PCI device reference counting in amd_smn_init() x86/div64: Fix addition of large constants in mul_u64_add_u64_div_u64() x86/cfi: Fix FineIBT hash offset in cfi_get_func_hash() x86/mm: Fix user-space data loss with MADV_FREE and THP x86/mm/pat: Allocate split page tables as kernel page tables x86/alternatives: Exclude text poking against change_page_attr() x86/mm/pat: Acquire init_mm read lock on attribute changes to avoid UAF x86/mm/pat: Acquire init_mm write lock on collapse to avoid UAF
2026-09-13Merge tag 'trace-v7.3-rc2' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/trace/linux-trace Pull tracing fixes from Steven Rostedt: - Don't destroy user event fields when removal fails User event fields are destroyed before the event is removed from visibility. But that can fail leaving the still visible event with no fields. Move the destroying of the fields to after the event is successfully removed from visibility. - Initialize function graph state is fork before calling copy_exec_state() For non-CLONE_VM forks, copy_exec_state() allocates a new task_exec_state. If that allocation fails, ftrace_graph_exit_task() will free the tasks ret_stack pointer. Since that pointer is still using the parent's ret_stack, it mistakenly frees the parent's pointer too. Call ftrace_graph_init() on the task first which will NULL out the new tasks's ret_stack and if the copy fails, it will not free anything. - Remove FGRAPH_MAX_INDEX The macro FGRAPH_MAX_INDEX was added but never used. Remove it. - Save ent_size in function graph printing of nested functions The function graph tracer needs to look at the next event to see if the next event is the return of the current function entry. If it is, it prints a single line: ktime_get(); Otherwise it prints it like a nested function: tick_nohz_irq_exit() { ktime_get(); kcpustat_irq_exit(); } In order to look at the next event, it must save the current event so that it has the information to print from it. It saves the event in the iterator descriptor called "ent". What it doesn't save is the ent_size of the event which is now used to know if the function graph arguments are to be printed. The peek doesn't save the size so the size used happens to be that of the size of the last event that was seen. Save the entry event size in the iterator descriptor so that the correct size is used. - Fix several errors with freeing data in the histogram code The histogram code had a lot of leaked or or incorrect accounting when failures happen. Correct them. - Fix histogram regression of .percent and .graph modifiers Up until 6.3 histogram values could have "percent" or "graph" modifiers that changed how they were printed. But a change that added restricting histograms values from being strings, stack traces and other modifiers inadvertently prevented them from using the percent and graph modifiers, which were legal use cases for values. Put back the percent and graph modifiers. - Fix various typos in the comments - Set the trace_clock before initializing a histogram with clock argument The histogram API allows the user to specific which trace clock to use via a "clock=" string. The histogram is set up first before the clock is checked. If the passed in clock is not valid, it exits without fully fixing up the histogram leaving it on the list and a use-after-free can trigger. Update the clock argument first and if it fails then exit gracefully before the histogram trigger is placed on any lists. - Restore :mod: trailer after parsing in ftrace_set_clr_event The function ftrace_set_clr_event() modifies the parse string and needs to put it back to what was passed in. It searches for ":mod:" via a strsep() but fails to put back the first ':' in the string. Add back the ':' in the passed in string. - Take trace_array reference when opening a tracer options file The options files are dynamically created and some tracers add their own options. When a tracer adds their own list of options, the trace_array holding them has an array to hold the list of options for each tracer. This array increases in size via a krealloc(), and the new entry gets a newly allocated array to hold the options of the new tracer being added. The element in each entry of the tracer's option array holds a pointer back to the trace_array, a pointer to the tracer it is associated to, a pointer to the flags of the option. The issue is that these arrays are freed when the trace_array is freed when its instance it represents is removed from the instances directory. There's a race that an open of one of these options files can happen when the instance is being removed. Add a new helper function to be called by the open function of the options file to iterate all existing trace_arrays under a lock and find the one that has the given option element in one of it's tracer arrays. If found, then update the associated trace_array's reference counter to keep it from being freed. If not found, have the open call return -ENODEV. - Disable interrupts when acquiring the lock in rb_wake_up_waiters() The function rb_wake_up_waiters() assumes it will be called in interrupt context and does not disable irqs when taking cpu_buffer->reader_lock, which can be called in hard interrupt context. The issue is in PREEMPT_RT, this function is called in thread context leaving this lock open to a deadlock. Take the lock with interrupts disabled. - Use rcu_assign_pointer() for tmp_ops filter hash The tmp_ops used in update_ftrace_direct_mod() assigns its filter_hash field directly, but that field is annotated as __rcu and sparse complains. Assign it with rcu_assign_pointer() - Fix use-after-free in enable_trigger_private_data_free() The trace_event_call is accessed through the event_trigger_data's trace_event_file pointer to put the trace_event_call on freeing. The issue is that the trace_event_file data may have been freed already causing a use-after-free. Add a field to the event_trigger_data that points directly to the trace_event_call so that it can decrement its reference directly without needing to go through the trace_event_file. - Fix accounting of buffer data remote headers trace_buffer_desc_size() and trace_remote_alloc_buffer() undercount the number of pages is needed for the asked for size as it doesn't take into account the meta data on each page. Add a helper function to do the calculation properly and use that in these functions. - Catch nr_page_va overflow in ring_buffer_desc sizing The number of pages per remote ring buffer is capped by ring_buffer_desc::nr_page_va (32 bits). A buffer_size large enough to overflow that field would silently allocate a descriptor smaller than what was asked for. - Do not resize the subbuf order if any per_cpu buffer is disabled The mmapping of ring buffers disables resizing the subbuffers, but it is done per-cpu whereas the subbuf size change is done for all the per_cpu buffers under the buffer->mutex. It could change the size of some while the mapping is happening on others. Have the resize of the subbuf order check all the per_cpu buffers under the lock to see if any of them is disabled before starting and causing an inconsistency between buffers that are being mapped. * tag 'trace-v7.3-rc2' of git://git.kernel.org/pub/scm/linux/kernel/git/trace/linux-trace: (25 commits) ring-buffer: Check resize_disabled before publishing the new subbuf order tracing/remotes: Catch nr_page_va overflow in ring_buffer_desc sizing tracing/remotes: Account for ring buffer page header in size calculation tracing: Don't dereference trace_event_file in deferred trigger free ftrace: Use rcu_assign_pointer() for tmp_ops filter hash ring-buffer: Acquire the lock with irqsave in rb_wake_up_waiters() tracing: Take trace_array reference when opening a tracer options file tracing: Fix ring_buffer_read_page_size() kernel-doc tracing: Restore :mod: trailer after parsing in ftrace_set_clr_event() tracing: Fix memory corruption from a "STACKTRACE" histogram key tracing: Fix memory corruption from the histogram stacktrace modifier tracing: Undo the registration when enabling the histogram trigger fails tracing: Take the reference before publishing the named histogram trigger tracing: Set the trace clock before registering the histogram trigger tracing: Fix typo "preceeded" in comment tracing: Fix typo "availabe" in comment tracing: Let histogram values keep the percent and graph modifiers tracing: Keep the entry count when the histogram stats allocation fails tracing: Free histogram the field rejected for a bad modifier tracing: Free histogram the var ref when its initialization fails ...