aboutsummaryrefslogtreecommitdiffstats
path: root/tools/perf/scripts/python/stackcollapse.py (unfollow)
AgeCommit message (Collapse)AuthorFilesLines
2025-03-08power: supply: rt9455: convert to use maple tree register cacheBo Liu1-1/+1
The maple tree register cache is based on a much more modern data structure than the rbtree cache and makes optimisation choices which are probably more appropriate for modern systems than those made by the rbtree cache. Signed-off-by: Bo Liu <liubo03@inspur.com> Link: https://lore.kernel.org/r/20250228080236.2759-9-liubo03@inspur.com Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
2025-03-08power: supply: max1720x: convert to use maple tree register cacheBo Liu1-1/+1
The maple tree register cache is based on a much more modern data structure than the rbtree cache and makes optimisation choices which are probably more appropriate for modern systems than those made by the rbtree cache. Signed-off-by: Bo Liu <liubo03@inspur.com> Link: https://lore.kernel.org/r/20250228080236.2759-8-liubo03@inspur.com Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
2025-03-08power: supply: ltc4162l: convert to use maple tree register cacheBo Liu1-1/+1
The maple tree register cache is based on a much more modern data structure than the rbtree cache and makes optimisation choices which are probably more appropriate for modern systems than those made by the rbtree cache. Signed-off-by: Bo Liu <liubo03@inspur.com> Link: https://lore.kernel.org/r/20250228080236.2759-7-liubo03@inspur.com Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
2025-03-08power: supply: bq25980: convert to use maple tree register cacheBo Liu1-3/+3
The maple tree register cache is based on a much more modern data structure than the rbtree cache and makes optimisation choices which are probably more appropriate for modern systems than those made by the rbtree cache. Signed-off-by: Bo Liu <liubo03@inspur.com> Link: https://lore.kernel.org/r/20250228080236.2759-6-liubo03@inspur.com Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
2025-03-08power: supply: bq25890: convert to use maple tree register cacheBo Liu1-1/+1
The maple tree register cache is based on a much more modern data structure than the rbtree cache and makes optimisation choices which are probably more appropriate for modern systems than those made by the rbtree cache. Signed-off-by: Bo Liu <liubo03@inspur.com> Link: https://lore.kernel.org/r/20250228080236.2759-5-liubo03@inspur.com Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
2025-03-08power: supply: bq2515x: convert to use maple tree register cacheBo Liu1-2/+2
The maple tree register cache is based on a much more modern data structure than the rbtree cache and makes optimisation choices which are probably more appropriate for modern systems than those made by the rbtree cache. Signed-off-by: Bo Liu <liubo03@inspur.com> Link: https://lore.kernel.org/r/20250228080236.2759-4-liubo03@inspur.com Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
2025-03-08power: supply: bq24257: convert to use maple tree register cacheBo Liu1-1/+1
The maple tree register cache is based on a much more modern data structure than the rbtree cache and makes optimisation choices which are probably more appropriate for modern systems than those made by the rbtree cache. Signed-off-by: Bo Liu <liubo03@inspur.com> Link: https://lore.kernel.org/r/20250228080236.2759-3-liubo03@inspur.com Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
2025-03-08power: supply: bd99954: convert to use maple tree register cacheBo Liu1-1/+1
The maple tree register cache is based on a much more modern data structure than the rbtree cache and makes optimisation choices which are probably more appropriate for modern systems than those made by the rbtree cache. Signed-off-by: Bo Liu <liubo03@inspur.com> Link: https://lore.kernel.org/r/20250228080236.2759-2-liubo03@inspur.com Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
2025-03-08power: supply: Remove unused set_charged methodDr. David Alan Gilbert1-1/+0
The previous patches in this series removed the only caller and only setter of this method. Remove it. Signed-off-by: Dr. David Alan Gilbert <linux@treblig.org> Link: https://lore.kernel.org/r/20250307230225.128775-4-linux@treblig.org Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
2025-03-08power: supply: ds2760: Remove unused ds2760_battery_set_chargedDr. David Alan Gilbert1-49/+0
With power_supply_set_battery_charged() deleted in the previous patch, there's no one left to call the set_charged method. The only implemented is in ds2760, unwire it and delete the associated functions and data. (Arguably it might be time to delete ds2760 since I don't think there are any users left) Signed-off-by: Dr. David Alan Gilbert <linux@treblig.org> Link: https://lore.kernel.org/r/20250307230225.128775-3-linux@treblig.org Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
2025-03-08power: supply: core: Remove unused power_supply_set_battery_chargedDr. David Alan Gilbert2-14/+0
power_supply_set_battery_charged() has been unused since 2019's commit 0f884f8a090e ("ARM: pxa: remove raumfeld board files and defconfig") Remove it. Signed-off-by: Dr. David Alan Gilbert <linux@treblig.org> Link: https://lore.kernel.org/r/20250307230225.128775-2-linux@treblig.org Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
2025-02-25power: supply: sc27xx: use devm_kmemdup_array()Raag Jadav1-3/+2
Convert to use devm_kmemdup_array() which is more robust. Signed-off-by: Raag Jadav <raag.jadav@intel.com> Link: https://lore.kernel.org/r/20250221165333.2780888-9-raag.jadav@intel.com Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
2025-02-24input: ipaq-micro-keys: use devm_kmemdup_array()Raag Jadav1-3/+2
Convert to use devm_kmemdup_array() which is more robust. Signed-off-by: Raag Jadav <raag.jadav@intel.com> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
2025-02-24input: sparse-keymap: use devm_kmemdup_array()Raag Jadav1-2/+1
Convert to use devm_kmemdup_array() and while at it, use source size instead of destination. Signed-off-by: Raag Jadav <raag.jadav@intel.com> Acked-by: Dmitry Torokhov <dmitry.torokhov@gmail.com> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
2025-02-24iio: adc: xilinx-xadc-core: use devm_kmemdup_array()Raag Jadav1-2/+2
Convert to use devm_kmemdup_array() and while at it, use source size instead of destination. Signed-off-by: Raag Jadav <raag.jadav@intel.com> Acked-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
2025-02-24pinctrl: pxa2xx: use devm_kmemdup_array()Raag Jadav1-4/+4
Convert to use devm_kmemdup_array() which is more robust. Signed-off-by: Raag Jadav <raag.jadav@intel.com> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
2025-02-24pinctrl: tangier: use devm_kmemdup_array()Raag Jadav1-3/+2
Convert to use devm_kmemdup_array() and while at it, use source size instead of destination. Signed-off-by: Raag Jadav <raag.jadav@intel.com> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
2025-02-24pinctrl: cherryview: use devm_kmemdup_array()Raag Jadav1-3/+2
Convert to use devm_kmemdup_array() and while at it, use source size instead of destination. Signed-off-by: Raag Jadav <raag.jadav@intel.com> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
2025-02-24pinctrl: baytrail: copy communities using devm_kmemdup_array()Raag Jadav1-4/+2
Copy communities using devm_kmemdup_array() instead of doing it manually. Signed-off-by: Raag Jadav <raag.jadav@intel.com> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
2025-02-24pinctrl: intel: copy communities using devm_kmemdup_array()Raag Jadav1-4/+2
Copy communities using devm_kmemdup_array() instead of doing it manually. Signed-off-by: Raag Jadav <raag.jadav@intel.com> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
2025-02-24devres: Introduce devm_kmemdup_array()Raag Jadav1-0/+5
Introduce '_array' variant of devm_kmemdup() which is more robust and consistent with alloc family of helpers. Suggested-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Raag Jadav <raag.jadav@intel.com> Reviewed-by: Dmitry Torokhov <dmitry.torokhov@gmail.com> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
2025-02-24iio: imu: st_lsm9ds0: Replace device.h with what is neededAndy Shevchenko2-2/+2
Instead of including a huge device.h with tons of dependencies include only what driver actually uses. Acked-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
2025-02-24driver core: Split devres APIs to device/devres.hAndy Shevchenko2-118/+125
device.h is a huge header which is hard to follow and easy to miss something. Improve that by splitting devres APIs to device/devres.h. In particular this helps to speedup the build of the code that includes device.h solely for a devres APIs. While at it, cast the error pointers to __iomem using IOMEM_ERR_PTR() and fix sparse warnings. Signed-off-by: Raag Jadav <raag.jadav@intel.com> Acked-by: Arnd Bergmann <arnd@arndb.de> Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
2025-02-24err.h: move IOMEM_ERR_PTR() to err.hRaag Jadav2-2/+3
Since IOMEM_ERR_PTR() macro deals with an error pointer, a better place for it is err.h. This helps avoid dependency on io.h for the users that don't need it. Suggested-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Raag Jadav <raag.jadav@intel.com> Acked-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
2025-02-21power: supply: axp20x_battery: Update temp sensor for AXP717 from device treeChris Morgan1-0/+21
Allow a boolean property of "x-powers,no-thermistor" to specify devices where the ts pin is not connected to anything. This works around an issue found with some devices where the efuse is not programmed correctly from the factory or when the register gets set erroneously. Signed-off-by: Chris Morgan <macromorgan@hotmail.com> Tested-by: Philippe Simons <simons.philippe@gmail.com> Link: https://lore.kernel.org/r/20250204155835.161973-4-macroalpha82@gmail.com Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
2025-02-21dt-bindings: power: supply: axp20x-battery: Add x-powers,no-thermistorChris Morgan1-3/+17
Add the vendor specific boolean property of x-powers,no-thermistor. This property optionally describes hardware where no thermistor is present on the battery and is specific to the AXP717. In rare circumstances this value can be set incorrectly in the efuse of the PMIC, and if it is not hard-coded the device will fail to charge. Signed-off-by: Chris Morgan <macromorgan@hotmail.com> Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Link: https://lore.kernel.org/r/20250204155835.161973-2-macroalpha82@gmail.com Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
2025-02-20mfd: axp20x: AXP717: Add AXP717_TS_PIN_CFG to writeable regsChris Morgan2-0/+2
Add AXP717_TS_PIN_CFG (register 0x50) to the table of writeable registers so that the temperature sensor can be configured by the battery driver. Signed-off-by: Chris Morgan <macromorgan@hotmail.com> Link: https://lore.kernel.org/r/20250204155835.161973-3-macroalpha82@gmail.com Signed-off-by: Lee Jones <lee@kernel.org>
2025-02-20power: supply: bq27xxx_battery: do not update cached flags prematurelySicelo A. Mhlongo1-1/+0
Commit 243f8ffc883a1 ("power: supply: bq27xxx_battery: Notify also about status changes") intended to notify userspace when the status changes, based on the flags register. However, the cached state is updated too early, before the flags are tested for any changes. Remove the premature update. Fixes: 243f8ffc883a1 ("power: supply: bq27xxx_battery: Notify also about status changes") Signed-off-by: Sicelo A. Mhlongo <absicsz@gmail.com> Link: https://lore.kernel.org/r/20241125152945.47937-1-absicsz@gmail.com Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
2025-02-20dt-bindings: power: reset: xilinx: Make "interrupts" property optionalShubhrajyoti Datta1-1/+0
The "interrupts" property in the ZynqMP power/reset binding was previously marked as required. However, there are multiple mechanisms for handling power/reset events, including: -Event management registration, -Mailbox (mboxes), -Interrupts (interrupts). When event management support is available (default on Versal SoC), the "interrupts" property is not used hence not required. Signed-off-by: Shubhrajyoti Datta <shubhrajyoti.datta@amd.com> Acked-by: Rob Herring (Arm) <robh@kernel.org> Acked-by: Michal Simek <michal.simek@amd.com> Link: https://lore.kernel.org/r/20250217095226.12606-1-shubhrajyoti.datta@amd.com Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
2025-02-20dt-bindings: power: reset: atmel,sama5d2-shdwc: Add microchip,sama7d65-shdwcRyan Wanner1-0/+5
Add SAMA7D65 SHDWC compatible to DT bindings documentation Signed-off-by: Ryan Wanner <Ryan.Wanner@microchip.com> Acked-by: Rob Herring (Arm) <robh@kernel.org> Link: https://lore.kernel.org/r/f7d7e5fdaa86c61e586978dfc11014cb45c32cd7.1739221064.git.Ryan.Wanner@microchip.com Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
2025-02-20power: supply: bq27xxx: do not report bogus zero valuesSicelo A. Mhlongo1-2/+15
On the bq27x00 and bq27x10 variants, a number of conditions may reset the value stored in the NAC register. This will cause capacity, energy, and charge to report the value 0, even when the battery is full. On the other hand, the chip also provides a flag, EDVF, which accurately detects the true battery empty condition, when capacity, charge, and energy are really 0. Therefore, discard readings for these properties if their value is 0 while EDVF is unset. Tested on the Nokia N900 with bq27200. Signed-off-by: Sicelo A. Mhlongo <absicsz@gmail.com> Link: https://lore.kernel.org/r/20250207220605.106768-1-absicsz@gmail.com Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
2025-02-20power: supply: bq27xxx: Add voltage_max_design property for bq270x0 and bq27x10Sicelo A. Mhlongo2-0/+38
Report VOLTAGE_MAX_DESIGN for the bq27x00 and bq27x10 fuel gauges. Per the datasheet, this value is stored in the Charge Termination Voltage Settings (QV0 and QV1) of the Pack Configuration register. Tested on the Nokia N900 with bq27200. Signed-off-by: Sicelo A. Mhlongo <absicsz@gmail.com> Link: https://lore.kernel.org/r/20250207211521.103357-1-absicsz@gmail.com Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
2025-02-20power: supply: max1720x: add health propertyDimitri Fedrau1-0/+47
Add health property, which checks that temperature, voltage and current are within limits for the battery. Limits can be programmed in non-volatile memory. Signed-off-by: Dimitri Fedrau <dimitri.fedrau@liebherr.com> Link: https://lore.kernel.org/r/20250204-max1720x_health-v1-1-97ebbe4a0bc5@liebherr.com Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
2025-02-15power: supply: axp20x_usb_power: Fix typo in dev_warn messageAndrew Kreimer1-1/+1
There is a typo in a dev_warn message: - reqested -> requested Fix it via codespell. Signed-off-by: Andrew Kreimer <algonell@gmail.com> Acked-by: Chen-Yu Tsai <wens@csie.org> Link: https://lore.kernel.org/r/20250206083405.10286-1-algonell@gmail.com Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
2025-02-15power: supply: max1720x: fix a comment typoAndré Draszik1-1/+1
mesaurment -> measurement Signed-off-by: André Draszik <andre.draszik@linaro.org> Link: https://lore.kernel.org/r/20250213-max1720x-typo-v1-1-9c88611cac34@linaro.org Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
2025-02-02Linux 6.14-rc1v6.14-rc1Linus Torvalds1-2/+2
2025-02-02tools/power turbostat: version 2025.02.02Len Brown1-1/+1
Summary of Changes since 2024.11.30: Fix regression in 2023.11.07 that affinitized forked child in one-shot mode. Harden one-shot mode against hotplug online/offline Enable RAPL SysWatt column by default. Add initial PTL, CWF platform support. Harden initial PMT code in response to early use. Enable first built-in PMT counter: CWF c1e residency Refuse to run on unsupported platforms without --force, to encourage updating to a version that supports the system, and to avoid no-so-useful measurement results. Signed-off-by: Len Brown <len.brown@intel.com>
2025-02-01MAINTAINERS: include linux-mm for xarray maintenanceAndrew Morton1-0/+1
MM developers have an interest in the xarray code. Cc: David Gow <davidgow@google.com> Cc: Geert Uytterhoeven <geert@linux-m68k.org> Cc: "Liam R. Howlett" <Liam.Howlett@oracle.com> Cc: Lorenzo Stoakes <lorenzo.stoakes@oracle.com> Cc: Matthew Wilcox <willy@infradead.org> Cc: Sidhartha Kumar <sidhartha.kumar@oracle.com> Cc: Tamir Duberstein <tamird@gmail.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2025-02-01revert "xarray: port tests to kunit"Andrew Morton16-410/+294
Revert c7bb5cf9fc4e ("xarray: port tests to kunit"). It broke the build when compiing the xarray userspace test harness code. Reported-by: Sidhartha Kumar <sidhartha.kumar@oracle.com> Closes: https://lkml.kernel.org/r/07cf896e-adf8-414f-a629-a808fc26014a@oracle.com Cc: David Gow <davidgow@google.com> Cc: Matthew Wilcox <willy@infradead.org> Cc: Tamir Duberstein <tamird@gmail.com> Cc: "Liam R. Howlett" <Liam.Howlett@oracle.com> Cc: Geert Uytterhoeven <geert@linux-m68k.org> Cc: Lorenzo Stoakes <lorenzo.stoakes@oracle.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2025-02-01MAINTAINERS: add lib/test_xarray.cTamir Duberstein1-0/+1
Ensure test-only changes are sent to the relevant maintainer. Link: https://lkml.kernel.org/r/20250129-xarray-test-maintainer-v1-1-482e31f30f47@gmail.com Signed-off-by: Tamir Duberstein <tamird@gmail.com> Cc: Mattew Wilcox <willy@infradead.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2025-02-01mailmap, MAINTAINERS, docs: update Carlos's email addressCarlos Bilbao3-6/+8
Update .mailmap to reflect my new (and final) primary email address, carlos.bilbao@kernel.org. Also update contact information in files Documentation/translations/sp_SP/index.rst and MAINTAINERS. Link: https://lkml.kernel.org/r/20250130012248.1196208-1-carlos.bilbao@kernel.org Signed-off-by: Carlos Bilbao <carlos.bilbao@kernel.org> Cc: Carlos Bilbao <bilbao@vt.edu> Cc: Jonathan Corbet <corbet@lwn.net> Cc: Mattew Wilcox <willy@infradead.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2025-02-01mm/hugetlb: fix hugepage allocation for interleaved memory nodesRitesh Harjani (IBM)1-1/+1
gather_bootmem_prealloc() assumes the start nid as 0 and size as num_node_state(N_MEMORY). That means in case if memory attached numa nodes are interleaved, then gather_bootmem_prealloc_parallel() will fail to scan few of these nodes. Since memory attached numa nodes can be interleaved in any fashion, hence ensure that the current code checks for all numa node ids (.size = nr_node_ids). Let's still keep max_threads as N_MEMORY, so that it can distributes all nr_node_ids among the these many no. threads. e.g. qemu cmdline ======================== numa_cmd="-numa node,nodeid=1,memdev=mem1,cpus=2-3 -numa node,nodeid=0,cpus=0-1 -numa dist,src=0,dst=1,val=20" mem_cmd="-object memory-backend-ram,id=mem1,size=16G" w/o this patch for cmdline (default_hugepagesz=1GB hugepagesz=1GB hugepages=2): ========================== ~ # cat /proc/meminfo |grep -i huge AnonHugePages: 0 kB ShmemHugePages: 0 kB FileHugePages: 0 kB HugePages_Total: 0 HugePages_Free: 0 HugePages_Rsvd: 0 HugePages_Surp: 0 Hugepagesize: 1048576 kB Hugetlb: 0 kB with this patch for cmdline (default_hugepagesz=1GB hugepagesz=1GB hugepages=2): =========================== ~ # cat /proc/meminfo |grep -i huge AnonHugePages: 0 kB ShmemHugePages: 0 kB FileHugePages: 0 kB HugePages_Total: 2 HugePages_Free: 2 HugePages_Rsvd: 0 HugePages_Surp: 0 Hugepagesize: 1048576 kB Hugetlb: 2097152 kB Link: https://lkml.kernel.org/r/f8d8dad3a5471d284f54185f65d575a6aaab692b.1736592534.git.ritesh.list@gmail.com Fixes: b78b27d02930 ("hugetlb: parallelize 1G hugetlb initialization") Signed-off-by: Ritesh Harjani (IBM) <ritesh.list@gmail.com> Reported-by: Pavithra Prakash <pavrampu@linux.ibm.com> Suggested-by: Muchun Song <muchun.song@linux.dev> Tested-by: Sourabh Jain <sourabhjain@linux.ibm.com> Reviewed-by: Luiz Capitulino <luizcap@redhat.com> Acked-by: David Rientjes <rientjes@google.com> Cc: Donet Tom <donettom@linux.ibm.com> Cc: Gang Li <gang.li@linux.dev> Cc: Daniel Jordan <daniel.m.jordan@oracle.com> Cc: <stable@vger.kernel.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2025-02-01mm: gup: fix infinite loop within __get_longterm_lockedZhaoyang Huang1-10/+4
We can run into an infinite loop in __get_longterm_locked() when collect_longterm_unpinnable_folios() finds only folios that are isolated from the LRU or were never added to the LRU. This can happen when all folios to be pinned are never added to the LRU, for example when vm_ops->fault allocated pages using cma_alloc() and never added them to the LRU. Fix it by simply taking a look at the list in the single caller, to see if anything was added. [zhaoyang.huang@unisoc.com: move definition of local] Link: https://lkml.kernel.org/r/20250122012604.3654667-1-zhaoyang.huang@unisoc.com Link: https://lkml.kernel.org/r/20250121020159.3636477-1-zhaoyang.huang@unisoc.com Fixes: 67e139b02d99 ("mm/gup.c: refactor check_and_migrate_movable_pages()") Signed-off-by: Zhaoyang Huang <zhaoyang.huang@unisoc.com> Reviewed-by: John Hubbard <jhubbard@nvidia.com> Reviewed-by: David Hildenbrand <david@redhat.com> Suggested-by: David Hildenbrand <david@redhat.com> Acked-by: David Hildenbrand <david@redhat.com> Cc: Aijun Sun <aijun.sun@unisoc.com> Cc: Alistair Popple <apopple@nvidia.com> Cc: <stable@vger.kernel.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2025-02-01mm, swap: fix reclaim offset calculation error during allocationKairui Song1-1/+1
There is a code error that will cause the swap entry allocator to reclaim and check the whole cluster with an unexpected tail offset instead of the part that needs to be reclaimed. This may cause corruption of the swap map, so fix it. Link: https://lkml.kernel.org/r/20250130115131.37777-1-ryncsn@gmail.com Fixes: 3b644773eefd ("mm, swap: reduce contention on device lock") Signed-off-by: Kairui Song <kasong@tencent.com> Cc: Chris Li <chrisl@kernel.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2025-02-01.mailmap: update email address for Christopher ObbardChristopher Obbard1-0/+1
Update my email address. Link: https://lkml.kernel.org/r/20250122-wip-obbardc-update-email-v2-1-12bde6b79ad0@linaro.org Signed-off-by: Christopher Obbard <christopher.obbard@linaro.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2025-02-01kfence: skip __GFP_THISNODE allocations on NUMA systemsMarco Elver1-0/+2
On NUMA systems, __GFP_THISNODE indicates that an allocation _must_ be on a particular node, and failure to allocate on the desired node will result in a failed allocation. Skip __GFP_THISNODE allocations if we are running on a NUMA system, since KFENCE can't guarantee which node its pool pages are allocated on. Link: https://lkml.kernel.org/r/20250124120145.410066-1-elver@google.com Fixes: 236e9f153852 ("kfence: skip all GFP_ZONEMASK allocations") Signed-off-by: Marco Elver <elver@google.com> Reported-by: Vlastimil Babka <vbabka@suse.cz> Acked-by: Vlastimil Babka <vbabka@suse.cz> Cc: Christoph Lameter <cl@linux.com> Cc: Alexander Potapenko <glider@google.com> Cc: Chistoph Lameter <cl@linux.com> Cc: Dmitriy Vyukov <dvyukov@google.com> Cc: <stable@vger.kernel.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2025-02-01nilfs2: fix possible int overflows in nilfs_fiemap()Nikita Zhandarovich1-3/+3
Since nilfs_bmap_lookup_contig() in nilfs_fiemap() calculates its result by being prepared to go through potentially maxblocks == INT_MAX blocks, the value in n may experience an overflow caused by left shift of blkbits. While it is extremely unlikely to occur, play it safe and cast right hand expression to wider type to mitigate the issue. Found by Linux Verification Center (linuxtesting.org) with static analysis tool SVACE. Link: https://lkml.kernel.org/r/20250124222133.5323-1-konishi.ryusuke@gmail.com Fixes: 622daaff0a89 ("nilfs2: fiemap support") Signed-off-by: Nikita Zhandarovich <n.zhandarovich@fintech.ru> Signed-off-by: Ryusuke Konishi <konishi.ryusuke@gmail.com> Cc: <stable@vger.kernel.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2025-02-01mm: compaction: use the proper flag to determine watermarksyangge1-4/+25
There are 4 NUMA nodes on my machine, and each NUMA node has 32GB of memory. I have configured 16GB of CMA memory on each NUMA node, and starting a 32GB virtual machine with device passthrough is extremely slow, taking almost an hour. Long term GUP cannot allocate memory from CMA area, so a maximum of 16 GB of no-CMA memory on a NUMA node can be used as virtual machine memory. There is 16GB of free CMA memory on a NUMA node, which is sufficient to pass the order-0 watermark check, causing the __compaction_suitable() function to consistently return true. For costly allocations, if the __compaction_suitable() function always returns true, it causes the __alloc_pages_slowpath() function to fail to exit at the appropriate point. This prevents timely fallback to allocating memory on other nodes, ultimately resulting in excessively long virtual machine startup times. Call trace: __alloc_pages_slowpath if (compact_result == COMPACT_SKIPPED || compact_result == COMPACT_DEFERRED) goto nopage; // should exit __alloc_pages_slowpath() from here We could use the real unmovable allocation context to have __zone_watermark_unusable_free() subtract CMA pages, and thus we won't pass the order-0 check anymore once the non-CMA part is exhausted. There is some risk that in some different scenario the compaction could in fact migrate pages from the exhausted non-CMA part of the zone to the CMA part and succeed, and we'll skip it instead. But only __GFP_NORETRY allocations should be affected in the immediate "goto nopage" when compaction is skipped, others will attempt with DEF_COMPACT_PRIORITY anyway and won't fail without trying to compact-migrate the non-CMA pageblocks into CMA pageblocks first, so it should be fine. After this fix, it only takes a few tens of seconds to start a 32GB virtual machine with device passthrough functionality. Link: https://lore.kernel.org/lkml/1736335854-548-1-git-send-email-yangge1116@126.com/ Link: https://lkml.kernel.org/r/1737788037-8439-1-git-send-email-yangge1116@126.com Signed-off-by: yangge <yangge1116@126.com> Acked-by: Vlastimil Babka <vbabka@suse.cz> Reviewed-by: Baolin Wang <baolin.wang@linux.alibaba.com> Acked-by: Johannes Weiner <hannes@cmpxchg.org> Cc: Barry Song <21cnbao@gmail.com> Cc: David Hildenbrand <david@redhat.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2025-02-01kernel: be more careful about dup_mmap() failures and uprobe registeringLiam R. Howlett2-3/+18
If a memory allocation fails during dup_mmap(), the maple tree can be left in an unsafe state for other iterators besides the exit path. All the locks are dropped before the exit_mmap() call (in mm/mmap.c), but the incomplete mm_struct can be reached through (at least) the rmap finding the vmas which have a pointer back to the mm_struct. Up to this point, there have been no issues with being able to find an mm_struct that was only partially initialised. Syzbot was able to make the incomplete mm_struct fail with recent forking changes, so it has been proven unsafe to use the mm_struct that hasn't been initialised, as referenced in the link below. Although 8ac662f5da19f ("fork: avoid inappropriate uprobe access to invalid mm") fixed the uprobe access, it does not completely remove the race. This patch sets the MMF_OOM_SKIP to avoid the iteration of the vmas on the oom side (even though this is extremely unlikely to be selected as an oom victim in the race window), and sets MMF_UNSTABLE to avoid other potential users from using a partially initialised mm_struct. When registering vmas for uprobe, skip the vmas in an mm that is marked unstable. Modifying a vma in an unstable mm may cause issues if the mm isn't fully initialised. Link: https://lore.kernel.org/all/6756d273.050a0220.2477f.003d.GAE@google.com/ Link: https://lkml.kernel.org/r/20250127170221.1761366-1-Liam.Howlett@oracle.com Fixes: d24062914837 ("fork: use __mt_dup() to duplicate maple tree in dup_mmap()") Signed-off-by: Liam R. Howlett <Liam.Howlett@Oracle.com> Reviewed-by: Lorenzo Stoakes <lorenzo.stoakes@oracle.com> Cc: Oleg Nesterov <oleg@redhat.com> Cc: Masami Hiramatsu <mhiramat@kernel.org> Cc: Jann Horn <jannh@google.com> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Michal Hocko <mhocko@suse.com> Cc: Peng Zhang <zhangpeng.00@bytedance.com> Cc: Matthew Wilcox <willy@infradead.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2025-02-01mm/fake-numa: handle cases with no SRAT infoBruno Faccini1-1/+10
Handle more gracefully cases where no SRAT information is available, like in VMs with no Numa support, and allow fake-numa configuration to complete successfully in these cases Link: https://lkml.kernel.org/r/20250127171623.1523171-1-bfaccini@nvidia.com Fixes: 63db8170bf34 (“mm/fake-numa: allow later numa node hotplug”) Signed-off-by: Bruno Faccini <bfaccini@nvidia.com> Cc: David Hildenbrand <david@redhat.com> Cc: Hyeonggon Yoo <hyeonggon.yoo@sk.com> Cc: John Hubbard <jhubbard@nvidia.com> Cc: Len Brown <lenb@kernel.org> Cc: "Mike Rapoport (IBM)" <rppt@kernel.org> Cc: "Rafael J. Wysocki" <rafael@kernel.org> Cc: Zi Yan <ziy@nvidia.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>