Odroid 3.13.y #75
Closed
Odroid 3.13.y #75
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
commit d651aa1 upstream. Each sub-buffer (buffer page) has a full 64 bit timestamp. The events on that page use a 27 bit delta against that timestamp in order to save on bits written to the ring buffer. If the time between events is larger than what the 27 bits can hold, a "time extend" event is added to hold the entire 64 bit timestamp again and the events after that hold a delta from that timestamp. As a "time extend" is always paired with an event, it is logical to just allocate the event with the time extend, to make things a bit more efficient. Unfortunately, when the pairing code was written, it removed the "delta = 0" from the first commit on a page, causing the events on the page to be slightly skewed. Fixes: 69d1b83 "ring-buffer: Bind time extend and data events together" Signed-off-by: Steven Rostedt <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
commit fc09149 upstream. This patch addresses a >= v3.11 free-after-use regression in core_scsi3_emulate_pro_register() that was introduced in the following commit: commit bc118fe Author: Andy Grover <[email protected]> Date: Thu May 16 10:41:04 2013 -0700 target: Further refactoring of core_scsi3_emulate_pro_register() To avoid the free-after-use, save an type value before hand, and only call core_scsi3_put_pr_reg() with a valid *pr_reg. Reported-by: Dan Carpenter <[email protected]> Cc: Andy Grover <[email protected]> Signed-off-by: Nicholas Bellinger <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
commit 2c45aad upstream. In allmodconfig builds for sparc and any other arch which does not set CONFIG_SPARSE_IRQ, the following will be seen at modpost: CC [M] lib/cpu-notifier-error-inject.o CC [M] lib/pm-notifier-error-inject.o ERROR: "irq_to_desc" [drivers/gpio/gpio-mcp23s08.ko] undefined! make[2]: *** [__modpost] Error 1 This happens because commit 3911ff3 ("genirq: export handle_edge_irq() and irq_to_desc()") added one export for it, but there were actually two instances of it, in an if/else clause for CONFIG_SPARSE_IRQ. Add the second one. Signed-off-by: Paul Gortmaker <[email protected]> Cc: Jiri Kosina <[email protected]> Link: http://lkml.kernel.org/r/[email protected] Signed-off-by: Thomas Gleixner <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
commit 79040ca upstream. If you do echo 0 > /sys/module/edac_core/parameters/edac_mc_poll_msec the following stack trace is output because the edac module is not designed to poll with a timeout of zero. WARNING: CPU: 12 PID: 0 at lib/list_debug.c:33 __list_add+0xac/0xc0() list_add corruption. prev->next should be next (ffff8808291dd1b8), but was (null). (prev=ffff8808286fe3f8). Modules linked in: sg nfsv3 rpcsec_gss_krb5 nfsv4 dns_resolver nfs fscache cfg80211 rfkill x86_pkg_temp_thermal coretemp kvm_intel kvm ixgbe e1000e crct10dif_pclmul crc32_pclmul crc32c_intel ghash_clmulni_intel aesni_intel lrw gf128mul glue_helper ablk_helper cryptd iTCO_wdt ptp sb_edac iTCO_vendor_support pps_core mdio ipmi_devintf edac_core ioatdma microcode shpchp lpc_ich pcspkr i2c_i801 dca mfd_core ipmi_si wmi ipmi_msghandler nfsd auth_rpcgss nfs_acl lockd sunrpc xfs libcrc32c sd_mod sr_mod cdrom crc_t10dif crct10dif_common mgag200 syscopyarea sysfillrect sysimgblt isci i2c_algo_bit drm_kms_helper ttm drm libsas ahci libahci scsi_transport_sas libata i2c_core dm_mirror dm_region_hash dm_log dm_mod CPU: 12 PID: 0 Comm: swapper/12 Not tainted 3.13.0+ #1 Hardware name: Intel Corporation LH Pass ........../SVRBD-ROW_T, BIOS SE5C600.86B.01.08.0003.022620131521 02/26/2013 Call Trace: <IRQ> __list_add+0xac/0xc0 __internal_add_timer+0xab/0x130 internal_add_timer+0x17/0x40 mod_timer_pinned+0xca/0x170 intel_pstate_timer_func+0x28a/0x380 call_timer_fn+0x36/0x100 run_timer_softirq+0x1ff/0x2f0 __do_softirq+0xf5/0x2e0 irq_exit+0x10d/0x120 smp_apic_timer_interrupt+0x45/0x60 apic_timer_interrupt+0x6d/0x80 <EOI> cpuidle_idle_call+0xb9/0x1f0 arch_cpu_idle+0xe/0x30 cpu_startup_entry+0x9e/0x240 start_secondary+0x1e4/0x290 kernel BUG at kernel/timer.c:1084! invalid opcode: 0000 [#1] SMP Modules linked in: sg nfsv3 rpcsec_gss_krb5 nfsv4 dns_resolver nfs fscache cfg80211 rfkill x86_pkg_temp_thermal coretemp kvm_intel kvm ixgbe e1000e crct10dif_pclmul crc32_pclmul crc32c_intel ghash_clmulni_intel aesni_intel lrw gf128mul glue_helper ablk_helper cryptd iTCO_wdt ptp sb_edac iTCO_vendor_support pps_core mdio ipmi_devintf edac_core ioatdma microcode shpchp lpc_ich pcspkr i2c_i801 dca mfd_core ipmi_si wmi ipmi_msghandler nfsd auth_rpcgss nfs_acl lockd sunrpc xfs libcrc32c sd_mod sr_mod cdrom crc_t10dif crct10dif_common mgag200 syscopyarea sysfillrect sysimgblt isci i2c_algo_bit drm_kms_helper ttm drm libsas ahci libahci scsi_transport_sas libata i2c_core dm_mirror dm_region_hash dm_log dm_mod CPU: 12 PID: 0 Comm: swapper/12 Tainted: G W 3.13.0+ #1 Hardware name: Intel Corporation LH Pass ........../SVRBD-ROW_T, BIOS SE5C600.86B.01.08.0003.022620131521 02/26/2013 Call Trace: <IRQ> run_timer_softirq+0x245/0x2f0 __do_softirq+0xf5/0x2e0 irq_exit+0x10d/0x120 smp_apic_timer_interrupt+0x45/0x60 apic_timer_interrupt+0x6d/0x80 <EOI> cpuidle_idle_call+0xb9/0x1f0 arch_cpu_idle+0xe/0x30 cpu_startup_entry+0x9e/0x240 start_secondary+0x1e4/0x290 RIP cascade+0x93/0xa0 WARNING: CPU: 36 PID: 1154 at kernel/workqueue.c:1461 __queue_delayed_work+0xed/0x1a0() Modules linked in: sg nfsv3 rpcsec_gss_krb5 nfsv4 dns_resolver nfs fscache cfg80211 rfkill x86_pkg_temp_thermal coretemp kvm_intel kvm ixgbe e1000e crct10dif_pclmul crc32_pclmul crc32c_intel ghash_clmulni_intel aesni_intel lrw gf128mul glue_helper ablk_helper cryptd iTCO_wdt ptp sb_edac iTCO_vendor_support pps_core mdio ipmi_devintf edac_core ioatdma microcode shpchp lpc_ich pcspkr i2c_i801 dca mfd_core ipmi_si wmi ipmi_msghandler nfsd auth_rpcgss nfs_acl lockd sunrpc xfs libcrc32c sd_mod sr_mod cdrom crc_t10dif crct10dif_common mgag200 syscopyarea sysfillrect sysimgblt isci i2c_algo_bit drm_kms_helper ttm drm libsas ahci libahci scsi_transport_sas libata i2c_core dm_mirror dm_region_hash dm_log dm_mod CPU: 36 PID: 1154 Comm: kworker/u481:3 Tainted: G W 3.13.0+ #1 Hardware name: Intel Corporation LH Pass ........../SVRBD-ROW_T, BIOS SE5C600.86B.01.08.0003.022620131521 02/26/2013 Workqueue: edac-poller edac_mc_workq_function [edac_core] Call Trace: dump_stack+0x45/0x56 warn_slowpath_common+0x7d/0xa0 warn_slowpath_null+0x1a/0x20 __queue_delayed_work+0xed/0x1a0 queue_delayed_work_on+0x27/0x50 edac_mc_workq_function+0x72/0xa0 [edac_core] process_one_work+0x17b/0x460 worker_thread+0x11b/0x400 kthread+0xd2/0xf0 ret_from_fork+0x7c/0xb0 This patch adds a range check in the edac_mc_poll_msec code to check for 0. Signed-off-by: Prarit Bhargava <[email protected]> Cc: Doug Thompson <[email protected]> Cc: Mauro Carvalho Chehab <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Linus Torvalds <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
commit 9da21b1 upstream. Sanitize code even more to accept unsigned longs only and to not allow polling intervals below 1 second as this is unnecessary and doesn't make much sense anyway for polling errors. Signed-off-by: Borislav Petkov <[email protected]> Link: http://lkml.kernel.org/r/[email protected] Cc: Doug Thompson <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
commit cb6ef42 upstream. We're using edac_mc_workq_setup() both on the init path, when we load an edac driver and when we change the polling period (edac_mc_reset_delay_period) through /sys/.../edac_mc_poll_msec. On that second path we don't need to init the workqueue which has been initialized already. Thanks to Tejun for workqueue insights. Signed-off-by: Borislav Petkov <[email protected]> Link: http://lkml.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
hgn
pushed a commit
to hgn/linux
that referenced
this pull request
Mar 4, 2014
Turn it into (for example): [ 0.073380] x86: Booting SMP configuration: [ 0.074005] .... node #0, CPUs: #1 #2 #3 #4 #5 #6 #7 [ 0.603005] .... node #1, CPUs: #8 torvalds#9 torvalds#10 torvalds#11 torvalds#12 torvalds#13 torvalds#14 torvalds#15 [ 1.200005] .... node #2, CPUs: torvalds#16 torvalds#17 torvalds#18 torvalds#19 torvalds#20 torvalds#21 torvalds#22 torvalds#23 [ 1.796005] .... node #3, CPUs: torvalds#24 torvalds#25 torvalds#26 torvalds#27 torvalds#28 torvalds#29 torvalds#30 torvalds#31 [ 2.393005] .... node #4, CPUs: torvalds#32 torvalds#33 torvalds#34 torvalds#35 torvalds#36 torvalds#37 torvalds#38 torvalds#39 [ 2.996005] .... node #5, CPUs: torvalds#40 torvalds#41 torvalds#42 torvalds#43 torvalds#44 torvalds#45 torvalds#46 torvalds#47 [ 3.600005] .... node #6, CPUs: torvalds#48 torvalds#49 torvalds#50 torvalds#51 #52 #53 torvalds#54 torvalds#55 [ 4.202005] .... node #7, CPUs: torvalds#56 torvalds#57 #58 torvalds#59 torvalds#60 torvalds#61 torvalds#62 torvalds#63 [ 4.811005] .... node #8, CPUs: torvalds#64 torvalds#65 torvalds#66 torvalds#67 torvalds#68 torvalds#69 #70 torvalds#71 [ 5.421006] .... node torvalds#9, CPUs: torvalds#72 torvalds#73 torvalds#74 torvalds#75 torvalds#76 torvalds#77 torvalds#78 torvalds#79 [ 6.032005] .... node torvalds#10, CPUs: torvalds#80 torvalds#81 torvalds#82 torvalds#83 torvalds#84 torvalds#85 torvalds#86 torvalds#87 [ 6.648006] .... node torvalds#11, CPUs: torvalds#88 torvalds#89 torvalds#90 torvalds#91 torvalds#92 torvalds#93 torvalds#94 torvalds#95 [ 7.262005] .... node torvalds#12, CPUs: torvalds#96 torvalds#97 torvalds#98 torvalds#99 torvalds#100 torvalds#101 torvalds#102 torvalds#103 [ 7.865005] .... node torvalds#13, CPUs: torvalds#104 torvalds#105 torvalds#106 torvalds#107 torvalds#108 torvalds#109 torvalds#110 torvalds#111 [ 8.466005] .... node torvalds#14, CPUs: torvalds#112 torvalds#113 torvalds#114 torvalds#115 torvalds#116 torvalds#117 torvalds#118 torvalds#119 [ 9.073006] .... node torvalds#15, CPUs: torvalds#120 torvalds#121 torvalds#122 torvalds#123 torvalds#124 torvalds#125 torvalds#126 torvalds#127 [ 9.679901] x86: Booted up 16 nodes, 128 CPUs and drop useless elements. Change num_digits() to hpa's division-avoiding, cell-phone-typed version which he went at great lengths and pains to submit on a Saturday evening. Signed-off-by: Borislav Petkov <[email protected]> Cc: [email protected] Cc: [email protected] Cc: [email protected] Cc: [email protected] Cc: [email protected] Cc: Linus Torvalds <[email protected]> Cc: Andrew Morton <[email protected]> Cc: Peter Zijlstra <[email protected]> Cc: Thomas Gleixner <[email protected]> Link: http://lkml.kernel.org/r/[email protected] Signed-off-by: Ingo Molnar <[email protected]>
commit 21ed494 upstream. inverted logic. Signed-off-by: Alex Deucher <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
commit 6d8ea7d upstream. Apply the same logic as CI to SI for setting up the display tiling parameters. The num banks may vary per tiling index just like CI. Bugs: https://bugs.freedesktop.org/show_bug.cgi?id=71488 https://bugs.freedesktop.org/show_bug.cgi?id=73946 https://bugs.freedesktop.org/show_bug.cgi?id=74927 Signed-off-by: Alex Deucher <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
commit 8f53492 upstream. The CP semaphore queue on CIK has a bug that triggers if uncompleted waits use the same address while a signal is still pending. Work around this by using different addresses for each sync. Signed-off-by: Christian König <[email protected]> Signed-off-by: Alex Deucher <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
commit 7d3428c upstream. Since commit 0fa9061 ("drm/nouveau/mc: handle irq-related setup ourselves"), drm_device->irq_enabled remained unset. This is needed in order to properly wait for a vblank event in the generic drm code. See https://bugs.freedesktop.org/show_bug.cgi?id=74195 Reported-by: Jan Janecek <[email protected]> Signed-off-by: Ilia Mirkin <[email protected]> Signed-off-by: Ben Skeggs <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
commit 95ca5b5 upstream. commit 8613e73 Author: Ben Skeggs <[email protected]> Date: Mon Oct 21 08:50:25 2013 +1000 drm/nouveau/fb: remove ram oclass argument from base fb constructor Introduced a unfortunate regression by using nv10 ram oclass for nv1a hardware, causing corruption and eventually system lockup. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=74866 Reported-by: John F. Godfrey <[email protected]> Signed-off-by: Emil Velikov <[email protected]> Signed-off-by: Ben Skeggs <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
commit a7f1c1e upstream. Commit 0a0afd2 ("drm/nv50-/disp: move DP link training to core and train from supervisor") added code that uses the wrong register for computing the display bpp, used for bandwidth calculation. Adjust to use the same register as used by exec_clkcmp and nv50_disp_intr_unk20_2_dp. Reported-by: Torsten Wagner <[email protected]> Reported-by: Michael Gulick <[email protected]> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=67628 Signed-off-by: Ilia Mirkin <[email protected]> Signed-off-by: Ben Skeggs <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
commit 753b1ad upstream. intel_ring_cachline_align() emits MI_NOOPs until the ring tail is aligned to a cacheline boundary. Cc: Bjoern C <[email protected]> Cc: Alexandru DAMIAN <[email protected]> Cc: Enrico Tagliavini <[email protected]> Suggested-by: Chris Wilson <[email protected]> Signed-off-by: Ville Syrjälä <[email protected]> Reviewed-by: Chris Wilson <[email protected]> Signed-off-by: Daniel Vetter <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
commit f66fab8 upstream. According to BSpec the entire MI_DISPLAY_FLIP packet must be contained in a single cacheline. Make sure that happens. v2: Use intel_ring_begin_cacheline_safe() v3: Use intel_ring_cacheline_align() (Chris) Cc: Bjoern C <[email protected]> Cc: Alexandru DAMIAN <[email protected]> Cc: Enrico Tagliavini <[email protected]> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=74053 Signed-off-by: Ville Syrjälä <[email protected]> Cc: [email protected] Signed-off-by: Daniel Vetter <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
commit 15cc176 upstream. Commit a115f74 (ext4: remove wait for unwritten extent conversion from ext4_truncate) exposed a bug in ext4_ext_handle_uninitialized_extents(). It can be triggered by xfstest generic/299 when run on a test file system created without a journal. This test continuously fallocates and truncates files to which random dio/aio writes are simultaneously performed by a separate process. The test completes successfully, but if the test filesystem is mounted with the block_validity option, a warning message stating that a logical block has been mapped to an illegal physical block is posted in the kernel log. The bug occurs when an extent is being converted to the written state by ext4_end_io_dio() and ext4_ext_handle_uninitialized_extents() discovers a mapping for an existing uninitialized extent. Although it sets EXT4_MAP_MAPPED in map->m_flags, it fails to set map->m_pblk to the discovered physical block number. Because map->m_pblk is not otherwise initialized or set by this function or its callers, its uninitialized value is returned to ext4_map_blocks(), where it is stored as a bogus mapping in the extent status tree. Since map->m_pblk can accidentally contain illegal values that are larger than the physical size of the file system, calls to check_block_validity() in ext4_map_blocks() that are enabled if the block_validity mount option is used can fail, resulting in the logged warning message. Signed-off-by: Eric Whitney <[email protected]> Signed-off-by: "Theodore Ts'o" <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
commit 30d29b1 upstream. In swap_inode_boot_loader() we forgot to release ->i_mutex and resume unlocked dio for inode and inode_bl if there is an error starting the journal handle. This commit fixes this issue. Reported-by: Ahmed Tamrawi <[email protected]> Cc: Andreas Dilger <[email protected]> Cc: Dr. Tilmann Bubeck <[email protected]> Signed-off-by: Zheng Liu <[email protected]> Signed-off-by: "Theodore Ts'o" <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
commit 2330141 upstream. If an ext4 file system is created by some tool other than mke2fs (perhaps by someone who has a pathalogical fear of the GPL) that doesn't set one or the other of the EXT2_FLAGS_{UN}SIGNED_HASH flags, and that file system is then mounted read-only, don't try to modify the s_flags field. Otherwise, if dm_verity is in use, the superblock will change, causing an dm_verity failure. Signed-off-by: "Theodore Ts'o" <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
commit b93c953 upstream. If a file system has a large number of inodes per block group, all of the metadata blocks in a flex_bg may be larger than what can fit in a single block group. Unfortunately, ext4_alloc_group_tables() in resize.c was never tested to see if it would handle this case correctly, and there were a large number of bugs which caused the following sequence to result in a BUG_ON: kernel bug at fs/ext4/resize.c:409! ... call trace: [<ffffffff81256768>] ext4_flex_group_add+0x1448/0x1830 [<ffffffff81257de2>] ext4_resize_fs+0x7b2/0xe80 [<ffffffff8123ac50>] ext4_ioctl+0xbf0/0xf00 [<ffffffff811c111d>] do_vfs_ioctl+0x2dd/0x4b0 [<ffffffff811b9df2>] ? final_putname+0x22/0x50 [<ffffffff811c1371>] sys_ioctl+0x81/0xa0 [<ffffffff81676aa9>] system_call_fastpath+0x16/0x1b code: c8 4c 89 df e8 41 96 f8 ff 44 89 e8 49 01 c4 44 29 6d d4 0 rip [<ffffffff81254fa1>] set_flexbg_block_bitmap+0x171/0x180 This can be reproduced with the following command sequence: mke2fs -t ext4 -i 4096 /dev/vdd 1G mount -t ext4 /dev/vdd /vdd resize2fs /dev/vdd 8G To fix this, we need to make sure the right thing happens when a block group's inode table straddles two block groups, which means the following bugs had to be fixed: 1) Not clearing the BLOCK_UNINIT flag in the second block group in ext4_alloc_group_tables --- the was proximate cause of the BUG_ON. 2) Incorrectly determining how many block groups contained contiguous free blocks in ext4_alloc_group_tables(). 3) Incorrectly setting the start of the next block range to be marked in use after a discontinuity in setup_new_flex_group_blocks(). Signed-off-by: "Theodore Ts'o" <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
commit 3d2660d upstream. The set_flexbg_block_bitmap() function assumed that the number of blocks in a blockgroup was sb->blocksize * 8, which is normally true, but not always! Use EXT4_BLOCKS_PER_GROUP(sb) instead, to fix block bitmap corruption after: mke2fs -t ext4 -g 3072 -i 4096 /dev/vdd 1G mount -t ext4 /dev/vdd /vdd resize2fs /dev/vdd 8G Signed-off-by: "Theodore Ts'o" <[email protected]> Reported-by: Jon Bernard <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
commit 19ea806 upstream. If the i_crtime field is not present in the inode, don't leave the field uninitialized. Fixes: ef7f383 ("ext4: Add nanosecond timestamps") Reported-by: Vegard Nossum <[email protected]> Tested-by: Vegard Nossum <[email protected]> Signed-off-by: "Theodore Ts'o" <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
commit 10c8562 upstream. GFP_ATOMIC is not a single gfp flag, but a macro which expands to the other flags and LACK of __GFP_WAIT flag. To check if caller wanted to perform an atomic allocation, the code must test __GFP_WAIT flag presence. This patch fixes the issue introduced in v3.6-rc5 Signed-off-by: Marek Szyprowski <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
commit 4d9c5b8 upstream. The stage-2 memory attributes are distinct from the Hyp memory attributes and the Stage-1 memory attributes. We were using the stage-1 memory attributes for stage-2 mappings causing device mappings to be mapped as normal memory. Add the S2 equivalent defines for memory attributes and fix the comments explaining the defines while at it. Add a prot_pte_s2 field to the mem_type struct and fill out the field for device mappings accordingly. Acked-by: Marc Zyngier <[email protected]> Acked-by: Catalin Marinas <[email protected]> Signed-off-by: Christoffer Dall <[email protected]> Signed-off-by: Russell King <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
commit bae0ca2 upstream. During __v{6,7}_setup, we invalidate the TLBs since we are about to enable the MMU on return to head.S. Unfortunately, without a subsequent dsb instruction, the invalidation is not guaranteed to have completed by the time we write to the sctlr, potentially exposing us to junk/stale translations cached in the TLB. This patch reworks the init functions so that the dsb used to ensure completion of cache/predictor maintenance is also used to ensure completion of the TLB invalidation. Reported-by: Albin Tonnerre <[email protected]> Signed-off-by: Will Deacon <[email protected]> Signed-off-by: Russell King <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
commit 7c8746a upstream. When unlocking a spinlock, we require the following, strictly ordered sequence of events: <barrier> /* dmb */ <unlock> <barrier> /* dsb */ <sev> Whilst the code does indeed reflect this in terms of the architecture, the final <barrier> + <sev> have been contracted into a single inline asm without a "memory" clobber, therefore the compiler is at liberty to reorder the unlock to the end of the above sequence. In such a case, a waiting CPU may be woken up before the lock has been unlocked, leading to extremely poor performance. This patch reworks the dsb_sev() function to make use of the dsb() macro and ensure ordering against the unlock. Reported-by: Mark Rutland <[email protected]> Signed-off-by: Will Deacon <[email protected]> Signed-off-by: Russell King <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
commit 39544ac upstream. Add DSB after icache flush to complete the cache maintenance operation. Signed-off-by: Vinayak Kale <[email protected]> Acked-by: Catalin Marinas <[email protected]> Signed-off-by: Russell King <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
…is built as module commit 6b187b2 upstream. Fixes: commit bc6b1e7 ARM: OMAP: gpmc: add DT bindings for GPMC timings and NAND OMAP SoC(s) depend on GPMC controller driver to parse GPMC DT child nodes and register them platform_device for NAND driver to probe later. However this does not happen if generic MTD_NAND framework is built as module (CONFIG_MTD_NAND=m). Therefore, when MTD/NAND and MTD/NAND/OMAP2 modules are loaded, they are unable to find any matching platform_device and remain un-binded. This causes on board NAND flash to remain un-detected. This patch causes GPMC controller to parse DT nodes when CONFIG_MTD_NAND=y || CONFIG_MTD_NAND=m Signed-off-by: Pekon Gupta <[email protected]> Signed-off-by: Tony Lindgren <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
…ENAND is built as module commit 980386d upstream. Fixes: commit 75d3625 ARM: OMAP2+: gpmc: add DT bindings for OneNAND OMAP SoC(s) depend on GPMC controller driver to parse GPMC DT child nodes and register them platform_device for ONENAND driver to probe later. However this does not happen if generic MTD_ONENAND framework is built as module (CONFIG_MTD_ONENAND=m). Therefore, when MTD/ONENAND and MTD/ONENAND/OMAP2 modules are loaded, they are unable to find any matching platform_device and remain un-binded. This causes on board ONENAND flash to remain un-detected. This patch causes GPMC controller to parse DT nodes when CONFIG_MTD_ONENAND=y || CONFIG_MTD_ONENAND=m Signed-off-by: Pekon Gupta <[email protected]> Signed-off-by: Tony Lindgren <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
commit 28a9f3b upstream. When building a kernel image with only CONFIG_CPU_IDLE but no CONFIG_PM, we will get the following link error. LD init/built-in.o arch/arm/mach-imx/built-in.o: In function `imx6q_enter_wait': platform-spi_imx.c:(.text+0x25c0): undefined reference to `imx6q_set_lpm' platform-spi_imx.c:(.text+0x25d4): undefined reference to `imx6q_set_lpm' arch/arm/mach-imx/built-in.o: In function `imx6q_cpuidle_init': platform-spi_imx.c:(.init.text+0x75d4): undefined reference to `imx6q_set_chicken_bit' make[1]: *** [vmlinux] Error 1 Since pm-imx6q.c has been a collection of library functions that access CCM low-power registers used by not only suspend but also cpuidle and other drivers, let's build pm-imx6q.c independently of CONFIG_PM to fix above error. Reported-by: Lucas Stach <[email protected]> Signed-off-by: Shawn Guo <[email protected]> Acked-by: Christian Gmeiner <[email protected]> Signed-off-by: Olof Johansson <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
guidosarducci
added a commit
to guidosarducci/linux
that referenced
this pull request
Sep 21, 2025
Update memory-layout, alignment, and expected results to ensure consistent behaviour regardless of 32/64-bit host architecture, similar to a previous fix [0]. All tests now pass on 32-bit armhf after these changes: root@qemu-armhf:/usr/libexec/kselftests-bpf# ./test_progs -a core_reloc torvalds#75/1 core_reloc/kernel:OK torvalds#75/2 core_reloc/module_probed:OK torvalds#75/3 core_reloc/module_direct:OK [...] torvalds#75/78 core_reloc/enum64val___err_missing:OK torvalds#75 core_reloc:OK Summary: 1/78 PASSED, 0 SKIPPED, 0 FAILED 0: 5705d70 ("selftests/bpf: Correct various core_reloc 64-bit assumptions") Signed-off-by: Tony Ambardar <[email protected]>
guidosarducci
added a commit
to guidosarducci/linux
that referenced
this pull request
Sep 23, 2025
Update memory-layout, alignment, and expected results to ensure consistent behaviour regardless of 32/64-bit host architecture, similar to a previous fix [0]. All tests now pass on 32-bit armhf after these changes: root@qemu-armhf:/usr/libexec/kselftests-bpf# ./test_progs -a core_reloc torvalds#75/1 core_reloc/kernel:OK torvalds#75/2 core_reloc/module_probed:OK torvalds#75/3 core_reloc/module_direct:OK [...] torvalds#75/78 core_reloc/enum64val___err_missing:OK torvalds#75 core_reloc:OK Summary: 1/78 PASSED, 0 SKIPPED, 0 FAILED 0: 5705d70 ("selftests/bpf: Correct various core_reloc 64-bit assumptions") Signed-off-by: Tony Ambardar <[email protected]>
guidosarducci
added a commit
to guidosarducci/linux
that referenced
this pull request
Sep 23, 2025
Update memory-layout, alignment, and expected results to ensure consistent behaviour regardless of 32/64-bit host architecture, similar to a previous fix [0]. All tests now pass on 32-bit armhf after these changes: root@qemu-armhf:/usr/libexec/kselftests-bpf# ./test_progs -a core_reloc torvalds#75/1 core_reloc/kernel:OK torvalds#75/2 core_reloc/module_probed:OK torvalds#75/3 core_reloc/module_direct:OK [...] torvalds#75/78 core_reloc/enum64val___err_missing:OK torvalds#75 core_reloc:OK Summary: 1/78 PASSED, 0 SKIPPED, 0 FAILED 0: 5705d70 ("selftests/bpf: Correct various core_reloc 64-bit assumptions") Signed-off-by: Tony Ambardar <[email protected]>
guidosarducci
added a commit
to guidosarducci/linux
that referenced
this pull request
Sep 23, 2025
Update memory-layout, alignment, and expected results to ensure consistent behaviour regardless of 32/64-bit host architecture, similar to a previous fix [0]. All tests now pass on 32-bit armhf after these changes: root@qemu-armhf:/usr/libexec/kselftests-bpf# ./test_progs -a core_reloc torvalds#75/1 core_reloc/kernel:OK torvalds#75/2 core_reloc/module_probed:OK torvalds#75/3 core_reloc/module_direct:OK [...] torvalds#75/78 core_reloc/enum64val___err_missing:OK torvalds#75 core_reloc:OK Summary: 1/78 PASSED, 0 SKIPPED, 0 FAILED 0: 5705d70 ("selftests/bpf: Correct various core_reloc 64-bit assumptions") Signed-off-by: Tony Ambardar <[email protected]>
guidosarducci
added a commit
to guidosarducci/linux
that referenced
this pull request
Sep 23, 2025
Update memory-layout, alignment, and expected results to ensure consistent behaviour regardless of 32/64-bit host architecture, similar to a previous fix [0]. All tests now pass on 32-bit armhf after these changes: root@qemu-armhf:/usr/libexec/kselftests-bpf# ./test_progs -a core_reloc torvalds#75/1 core_reloc/kernel:OK torvalds#75/2 core_reloc/module_probed:OK torvalds#75/3 core_reloc/module_direct:OK [...] torvalds#75/78 core_reloc/enum64val___err_missing:OK torvalds#75 core_reloc:OK Summary: 1/78 PASSED, 0 SKIPPED, 0 FAILED 0: 5705d70 ("selftests/bpf: Correct various core_reloc 64-bit assumptions") Signed-off-by: Tony Ambardar <[email protected]>
guidosarducci
added a commit
to guidosarducci/linux
that referenced
this pull request
Sep 24, 2025
Update memory-layout, alignment, and expected results to ensure consistent behaviour regardless of 32/64-bit host architecture, similar to a previous fix [0]. All tests now pass on 32-bit armhf after these changes: root@qemu-armhf:/usr/libexec/kselftests-bpf# ./test_progs -a core_reloc torvalds#75/1 core_reloc/kernel:OK torvalds#75/2 core_reloc/module_probed:OK torvalds#75/3 core_reloc/module_direct:OK [...] torvalds#75/78 core_reloc/enum64val___err_missing:OK torvalds#75 core_reloc:OK Summary: 1/78 PASSED, 0 SKIPPED, 0 FAILED 0: 5705d70 ("selftests/bpf: Correct various core_reloc 64-bit assumptions") Signed-off-by: Tony Ambardar <[email protected]>
guidosarducci
added a commit
to guidosarducci/linux
that referenced
this pull request
Sep 25, 2025
Update memory-layout, alignment, and expected results to ensure consistent behaviour regardless of 32/64-bit host architecture, similar to a previous fix [0]. All tests now pass on 32-bit armhf after these changes: root@qemu-armhf:/usr/libexec/kselftests-bpf# ./test_progs -a core_reloc torvalds#75/1 core_reloc/kernel:OK torvalds#75/2 core_reloc/module_probed:OK torvalds#75/3 core_reloc/module_direct:OK [...] torvalds#75/78 core_reloc/enum64val___err_missing:OK torvalds#75 core_reloc:OK Summary: 1/78 PASSED, 0 SKIPPED, 0 FAILED 0: 5705d70 ("selftests/bpf: Correct various core_reloc 64-bit assumptions") Signed-off-by: Tony Ambardar <[email protected]>
guidosarducci
added a commit
to guidosarducci/linux
that referenced
this pull request
Sep 27, 2025
Update memory-layout, alignment, and expected results to ensure consistent behaviour regardless of 32/64-bit host architecture, similar to a previous fix [0]. All tests now pass on 32-bit armhf after these changes: root@qemu-armhf:/usr/libexec/kselftests-bpf# ./test_progs -a core_reloc torvalds#75/1 core_reloc/kernel:OK torvalds#75/2 core_reloc/module_probed:OK torvalds#75/3 core_reloc/module_direct:OK [...] torvalds#75/78 core_reloc/enum64val___err_missing:OK torvalds#75 core_reloc:OK Summary: 1/78 PASSED, 0 SKIPPED, 0 FAILED 0: 5705d70 ("selftests/bpf: Correct various core_reloc 64-bit assumptions") Signed-off-by: Tony Ambardar <[email protected]>
guidosarducci
added a commit
to guidosarducci/linux
that referenced
this pull request
Sep 27, 2025
Update memory-layout, alignment, and expected results to ensure consistent behaviour regardless of 32/64-bit host architecture, similar to a previous fix [0]. All tests now pass on 32-bit armhf after these changes: root@qemu-armhf:/usr/libexec/kselftests-bpf# ./test_progs -a core_reloc torvalds#75/1 core_reloc/kernel:OK torvalds#75/2 core_reloc/module_probed:OK torvalds#75/3 core_reloc/module_direct:OK [...] torvalds#75/78 core_reloc/enum64val___err_missing:OK torvalds#75 core_reloc:OK Summary: 1/78 PASSED, 0 SKIPPED, 0 FAILED 0: 5705d70 ("selftests/bpf: Correct various core_reloc 64-bit assumptions") Signed-off-by: Tony Ambardar <[email protected]>
guidosarducci
added a commit
to guidosarducci/linux
that referenced
this pull request
Oct 1, 2025
Update memory-layout, alignment, and expected results to ensure consistent behaviour regardless of 32/64-bit host architecture, similar to a previous fix [0]. All tests now pass on 32-bit armhf after these changes: root@qemu-armhf:/usr/libexec/kselftests-bpf# ./test_progs -a core_reloc torvalds#75/1 core_reloc/kernel:OK torvalds#75/2 core_reloc/module_probed:OK torvalds#75/3 core_reloc/module_direct:OK [...] torvalds#75/78 core_reloc/enum64val___err_missing:OK torvalds#75 core_reloc:OK Summary: 1/78 PASSED, 0 SKIPPED, 0 FAILED 0: 5705d70 ("selftests/bpf: Correct various core_reloc 64-bit assumptions") Signed-off-by: Tony Ambardar <[email protected]>
guidosarducci
added a commit
to guidosarducci/linux
that referenced
this pull request
Oct 10, 2025
Update memory-layout, alignment, and expected results to ensure consistent behaviour regardless of 32/64-bit host architecture, similar to a previous fix [0]. All tests now pass on 32-bit armhf after these changes: root@qemu-armhf:/usr/libexec/kselftests-bpf# ./test_progs -a core_reloc torvalds#75/1 core_reloc/kernel:OK torvalds#75/2 core_reloc/module_probed:OK torvalds#75/3 core_reloc/module_direct:OK [...] torvalds#75/78 core_reloc/enum64val___err_missing:OK torvalds#75 core_reloc:OK Summary: 1/78 PASSED, 0 SKIPPED, 0 FAILED 0: 5705d70 ("selftests/bpf: Correct various core_reloc 64-bit assumptions") Signed-off-by: Tony Ambardar <[email protected]>
guidosarducci
added a commit
to guidosarducci/linux
that referenced
this pull request
Oct 11, 2025
Update memory-layout, alignment, and expected results to ensure consistent behaviour regardless of 32/64-bit host architecture, similar to a previous fix [0]. All tests now pass on 32-bit armhf after these changes: root@qemu-armhf:/usr/libexec/kselftests-bpf# ./test_progs -a core_reloc torvalds#75/1 core_reloc/kernel:OK torvalds#75/2 core_reloc/module_probed:OK torvalds#75/3 core_reloc/module_direct:OK [...] torvalds#75/78 core_reloc/enum64val___err_missing:OK torvalds#75 core_reloc:OK Summary: 1/78 PASSED, 0 SKIPPED, 0 FAILED 0: 5705d70 ("selftests/bpf: Correct various core_reloc 64-bit assumptions") Signed-off-by: Tony Ambardar <[email protected]>
guidosarducci
added a commit
to guidosarducci/linux
that referenced
this pull request
Oct 15, 2025
Update memory-layout, alignment, and expected results to ensure consistent behaviour regardless of 32/64-bit host architecture, similar to a previous fix [0]. All tests now pass on 32-bit armhf after these changes: root@qemu-armhf:/usr/libexec/kselftests-bpf# ./test_progs -a core_reloc torvalds#75/1 core_reloc/kernel:OK torvalds#75/2 core_reloc/module_probed:OK torvalds#75/3 core_reloc/module_direct:OK [...] torvalds#75/78 core_reloc/enum64val___err_missing:OK torvalds#75 core_reloc:OK Summary: 1/78 PASSED, 0 SKIPPED, 0 FAILED 0: 5705d70 ("selftests/bpf: Correct various core_reloc 64-bit assumptions") Signed-off-by: Tony Ambardar <[email protected]>
guidosarducci
added a commit
to guidosarducci/linux
that referenced
this pull request
Oct 20, 2025
Update memory-layout, alignment, and expected results to ensure consistent behaviour regardless of 32/64-bit host architecture, similar to a previous fix [0]. All tests now pass on 32-bit armhf after these changes: root@qemu-armhf:/usr/libexec/kselftests-bpf# ./test_progs -a core_reloc torvalds#75/1 core_reloc/kernel:OK torvalds#75/2 core_reloc/module_probed:OK torvalds#75/3 core_reloc/module_direct:OK [...] torvalds#75/78 core_reloc/enum64val___err_missing:OK torvalds#75 core_reloc:OK Summary: 1/78 PASSED, 0 SKIPPED, 0 FAILED 0: 5705d70 ("selftests/bpf: Correct various core_reloc 64-bit assumptions") Signed-off-by: Tony Ambardar <[email protected]>
guidosarducci
added a commit
to guidosarducci/linux
that referenced
this pull request
Oct 21, 2025
Update memory-layout, alignment, and expected results to ensure consistent behaviour regardless of 32/64-bit host architecture, similar to a previous fix [0]. All tests now pass on 32-bit armhf after these changes: root@qemu-armhf:/usr/libexec/kselftests-bpf# ./test_progs -a core_reloc torvalds#75/1 core_reloc/kernel:OK torvalds#75/2 core_reloc/module_probed:OK torvalds#75/3 core_reloc/module_direct:OK [...] torvalds#75/78 core_reloc/enum64val___err_missing:OK torvalds#75 core_reloc:OK Summary: 1/78 PASSED, 0 SKIPPED, 0 FAILED 0: 5705d70 ("selftests/bpf: Correct various core_reloc 64-bit assumptions") Signed-off-by: Tony Ambardar <[email protected]>
guidosarducci
added a commit
to guidosarducci/linux
that referenced
this pull request
Oct 21, 2025
Update memory-layout, alignment, and expected results to ensure consistent behaviour regardless of 32/64-bit host architecture, similar to a previous fix [0]. All tests now pass on 32-bit armhf after these changes: root@qemu-armhf:/usr/libexec/kselftests-bpf# ./test_progs -a core_reloc torvalds#75/1 core_reloc/kernel:OK torvalds#75/2 core_reloc/module_probed:OK torvalds#75/3 core_reloc/module_direct:OK [...] torvalds#75/78 core_reloc/enum64val___err_missing:OK torvalds#75 core_reloc:OK Summary: 1/78 PASSED, 0 SKIPPED, 0 FAILED 0: 5705d70 ("selftests/bpf: Correct various core_reloc 64-bit assumptions") Signed-off-by: Tony Ambardar <[email protected]>
guidosarducci
added a commit
to guidosarducci/linux
that referenced
this pull request
Oct 21, 2025
Update memory-layout, alignment, and expected results to ensure consistent behaviour regardless of 32/64-bit host architecture, similar to a previous fix [0]. All tests now pass on 32-bit armhf after these changes: root@qemu-armhf:/usr/libexec/kselftests-bpf# ./test_progs -a core_reloc torvalds#75/1 core_reloc/kernel:OK torvalds#75/2 core_reloc/module_probed:OK torvalds#75/3 core_reloc/module_direct:OK [...] torvalds#75/78 core_reloc/enum64val___err_missing:OK torvalds#75 core_reloc:OK Summary: 1/78 PASSED, 0 SKIPPED, 0 FAILED 0: 5705d70 ("selftests/bpf: Correct various core_reloc 64-bit assumptions") Signed-off-by: Tony Ambardar <[email protected]>
aotot
pushed a commit
to jove-decompiler/linux
that referenced
this pull request
Oct 26, 2025
…zones
In case we have to migrate a ballon page to a newpage of another zone, the
managed page count of both zones is wrong. Paired with memory offlining
(which will adjust the managed page count), we can trigger kernel crashes
and all kinds of different symptoms.
One way to reproduce:
1. Start a QEMU guest with 4GB, no NUMA
2. Hotplug a 1GB DIMM and online the memory to ZONE_NORMAL
3. Inflate the balloon to 1GB
4. Unplug the DIMM (be quick, otherwise unmovable data ends up on it)
5. Observe /proc/zoneinfo
Node 0, zone Normal
pages free 16810
min 24848885473806
low 18471592959183339
high 36918337032892872
spanned 262144
present 262144
managed 18446744073709533486
6. Do anything that requires some memory (e.g., inflate the balloon some
more). The OOM goes crazy and the system crashes
[ 238.324946] Out of memory: Killed process 537 (login) total-vm:27584kB, anon-rss:860kB, file-rss:0kB, shmem-rss:00
[ 238.338585] systemd invoked oom-killer: gfp_mask=0x100cca(GFP_HIGHUSER_MOVABLE), order=0, oom_score_adj=0
[ 238.339420] CPU: 0 PID: 1 Comm: systemd Tainted: G D W 5.4.0-next-20191204+ torvalds#75
[ 238.340139] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.12.0-59-gc9ba5276e321-prebuilt.qemu4
[ 238.341121] Call Trace:
[ 238.341337] dump_stack+0x8f/0xd0
[ 238.341630] dump_header+0x61/0x5ea
[ 238.341942] oom_kill_process.cold+0xb/0x10
[ 238.342299] out_of_memory+0x24d/0x5a0
[ 238.342625] __alloc_pages_slowpath+0xd12/0x1020
[ 238.343024] __alloc_pages_nodemask+0x391/0x410
[ 238.343407] pagecache_get_page+0xc3/0x3a0
[ 238.343757] filemap_fault+0x804/0xc30
[ 238.344083] ? ext4_filemap_fault+0x28/0x42
[ 238.344444] ext4_filemap_fault+0x30/0x42
[ 238.344789] __do_fault+0x37/0x1a0
[ 238.345087] __handle_mm_fault+0x104d/0x1ab0
[ 238.345450] handle_mm_fault+0x169/0x360
[ 238.345790] do_user_addr_fault+0x20d/0x490
[ 238.346154] do_page_fault+0x31/0x210
[ 238.346468] async_page_fault+0x43/0x50
[ 238.346797] RIP: 0033:0x7f47eba4197e
[ 238.347110] Code: Bad RIP value.
[ 238.347387] RSP: 002b:00007ffd7c0c1890 EFLAGS: 00010293
[ 238.347834] RAX: 0000000000000002 RBX: 000055d196a20a20 RCX: 00007f47eba4197e
[ 238.348437] RDX: 0000000000000033 RSI: 00007ffd7c0c18c0 RDI: 0000000000000004
[ 238.349047] RBP: 00007ffd7c0c1c20 R08: 0000000000000000 R09: 0000000000000033
[ 238.349660] R10: 00000000ffffffff R11: 0000000000000293 R12: 0000000000000001
[ 238.350261] R13: ffffffffffffffff R14: 0000000000000000 R15: 00007ffd7c0c18c0
[ 238.350878] Mem-Info:
[ 238.351085] active_anon:3121 inactive_anon:51 isolated_anon:0
[ 238.351085] active_file:12 inactive_file:7 isolated_file:0
[ 238.351085] unevictable:0 dirty:0 writeback:0 unstable:0
[ 238.351085] slab_reclaimable:5565 slab_unreclaimable:10170
[ 238.351085] mapped:3 shmem:111 pagetables:155 bounce:0
[ 238.351085] free:720717 free_pcp:2 free_cma:0
[ 238.353757] Node 0 active_anon:12484kB inactive_anon:204kB active_file:48kB inactive_file:28kB unevictable:0kB iss
[ 238.355979] Node 0 DMA free:11556kB min:36kB low:48kB high:60kB reserved_highatomic:0KB active_anon:152kB inactivB
[ 238.358345] lowmem_reserve[]: 0 2955 2884 2884 2884
[ 238.358761] Node 0 DMA32 free:2677864kB min:7004kB low:10028kB high:13052kB reserved_highatomic:0KB active_anon:0B
[ 238.361202] lowmem_reserve[]: 0 0 72057594037927865 72057594037927865 72057594037927865
[ 238.361888] Node 0 Normal free:193448kB min:99395541895224kB low:73886371836733356kB high:147673348131571488kB reB
[ 238.364765] lowmem_reserve[]: 0 0 0 0 0
[ 238.365101] Node 0 DMA: 7*4kB (U) 5*8kB (UE) 6*16kB (UME) 2*32kB (UM) 1*64kB (U) 2*128kB (UE) 3*256kB (UME) 2*512B
[ 238.366379] Node 0 DMA32: 0*4kB 1*8kB (U) 2*16kB (UM) 2*32kB (UM) 2*64kB (UM) 1*128kB (U) 1*256kB (U) 1*512kB (U)B
[ 238.367654] Node 0 Normal: 1985*4kB (UME) 1321*8kB (UME) 844*16kB (UME) 524*32kB (UME) 300*64kB (UME) 138*128kB (B
[ 238.369184] Node 0 hugepages_total=0 hugepages_free=0 hugepages_surp=0 hugepages_size=2048kB
[ 238.369915] 130 total pagecache pages
[ 238.370241] 0 pages in swap cache
[ 238.370533] Swap cache stats: add 0, delete 0, find 0/0
[ 238.370981] Free swap = 0kB
[ 238.371239] Total swap = 0kB
[ 238.371488] 1048445 pages RAM
[ 238.371756] 0 pages HighMem/MovableOnly
[ 238.372090] 306992 pages reserved
[ 238.372376] 0 pages cma reserved
[ 238.372661] 0 pages hwpoisoned
In another instance (older kernel), I was able to observe this
(negative page count :/):
[ 180.896971] Offlined Pages 32768
[ 182.667462] Offlined Pages 32768
[ 184.408117] Offlined Pages 32768
[ 186.026321] Offlined Pages 32768
[ 187.684861] Offlined Pages 32768
[ 189.227013] Offlined Pages 32768
[ 190.830303] Offlined Pages 32768
[ 190.833071] Built 1 zonelists, mobility grouping on. Total pages: -36920272750453009
In another instance (older kernel), I was no longer able to start any
process:
[root@vm ~]# [ 214.348068] Offlined Pages 32768
[ 215.973009] Offlined Pages 32768
cat /proc/meminfo
-bash: fork: Cannot allocate memory
[root@vm ~]# cat /proc/meminfo
-bash: fork: Cannot allocate memory
Fix it by properly adjusting the managed page count when migrating if
the zone changed. The managed page count of the zones now looks after
unplug of the DIMM (and after deflating the balloon) just like before
inflating the balloon (and plugging+onlining the DIMM).
We'll temporarily modify the totalram page count. If this ever becomes a
problem, we can fine tune by providing helpers that don't touch
the totalram pages (e.g., adjust_zone_managed_page_count()).
Please note that fixing up the managed page count is only necessary when
we adjusted the managed page count when inflating - only if we
don't have VIRTIO_BALLOON_F_DEFLATE_ON_OOM. With that feature, the
managed page count is not touched when inflating/deflating.
Reported-by: Yumei Huang <[email protected]>
Fixes: a813125 ("mm: correctly update zone->managed_pages")
Cc: <[email protected]> # v3.11+
Cc: "Michael S. Tsirkin" <[email protected]>
Cc: Jason Wang <[email protected]>
Cc: Jiang Liu <[email protected]>
Cc: Andrew Morton <[email protected]>
Cc: Igor Mammedov <[email protected]>
Cc: [email protected]
Signed-off-by: David Hildenbrand <[email protected]>
Signed-off-by: Michael S. Tsirkin <[email protected]>
guidosarducci
added a commit
to guidosarducci/linux
that referenced
this pull request
Oct 27, 2025
Update memory-layout, alignment, and expected results to ensure consistent behaviour regardless of 32/64-bit host architecture, similar to a previous fix [0]. All tests now pass on 32-bit armhf after these changes: root@qemu-armhf:/usr/libexec/kselftests-bpf# ./test_progs -a core_reloc torvalds#75/1 core_reloc/kernel:OK torvalds#75/2 core_reloc/module_probed:OK torvalds#75/3 core_reloc/module_direct:OK [...] torvalds#75/78 core_reloc/enum64val___err_missing:OK torvalds#75 core_reloc:OK Summary: 1/78 PASSED, 0 SKIPPED, 0 FAILED 0: 5705d70 ("selftests/bpf: Correct various core_reloc 64-bit assumptions") Signed-off-by: Tony Ambardar <[email protected]>
guidosarducci
added a commit
to guidosarducci/linux
that referenced
this pull request
Oct 27, 2025
Update memory-layout, alignment, and expected results to ensure consistent behaviour regardless of 32/64-bit host architecture, similar to a previous fix [0]. All tests now pass on 32-bit armhf after these changes: root@qemu-armhf:/usr/libexec/kselftests-bpf# ./test_progs -a core_reloc torvalds#75/1 core_reloc/kernel:OK torvalds#75/2 core_reloc/module_probed:OK torvalds#75/3 core_reloc/module_direct:OK [...] torvalds#75/78 core_reloc/enum64val___err_missing:OK torvalds#75 core_reloc:OK Summary: 1/78 PASSED, 0 SKIPPED, 0 FAILED 0: 5705d70 ("selftests/bpf: Correct various core_reloc 64-bit assumptions") Signed-off-by: Tony Ambardar <[email protected]>
guidosarducci
added a commit
to guidosarducci/linux
that referenced
this pull request
Oct 27, 2025
Update memory-layout, alignment, and expected results to ensure consistent behaviour regardless of 32/64-bit host architecture, similar to a previous fix [0]. All tests now pass on 32-bit armhf after these changes: root@qemu-armhf:/usr/libexec/kselftests-bpf# ./test_progs -a core_reloc torvalds#75/1 core_reloc/kernel:OK torvalds#75/2 core_reloc/module_probed:OK torvalds#75/3 core_reloc/module_direct:OK [...] torvalds#75/78 core_reloc/enum64val___err_missing:OK torvalds#75 core_reloc:OK Summary: 1/78 PASSED, 0 SKIPPED, 0 FAILED 0: 5705d70 ("selftests/bpf: Correct various core_reloc 64-bit assumptions") Signed-off-by: Tony Ambardar <[email protected]>
guidosarducci
added a commit
to guidosarducci/linux
that referenced
this pull request
Oct 27, 2025
Update memory-layout, alignment, and expected results to ensure consistent behaviour regardless of 32/64-bit host architecture, similar to a previous fix [0]. All tests now pass on 32-bit armhf after these changes: root@qemu-armhf:/usr/libexec/kselftests-bpf# ./test_progs -a core_reloc torvalds#75/1 core_reloc/kernel:OK torvalds#75/2 core_reloc/module_probed:OK torvalds#75/3 core_reloc/module_direct:OK [...] torvalds#75/78 core_reloc/enum64val___err_missing:OK torvalds#75 core_reloc:OK Summary: 1/78 PASSED, 0 SKIPPED, 0 FAILED 0: 5705d70 ("selftests/bpf: Correct various core_reloc 64-bit assumptions") Signed-off-by: Tony Ambardar <[email protected]>
guidosarducci
added a commit
to guidosarducci/linux
that referenced
this pull request
Oct 27, 2025
Update memory-layout, alignment, and expected results to ensure consistent behaviour regardless of 32/64-bit host architecture, similar to a previous fix [0]. All tests now pass on 32-bit armhf after these changes: root@qemu-armhf:/usr/libexec/kselftests-bpf# ./test_progs -a core_reloc torvalds#75/1 core_reloc/kernel:OK torvalds#75/2 core_reloc/module_probed:OK torvalds#75/3 core_reloc/module_direct:OK [...] torvalds#75/78 core_reloc/enum64val___err_missing:OK torvalds#75 core_reloc:OK Summary: 1/78 PASSED, 0 SKIPPED, 0 FAILED 0: 5705d70 ("selftests/bpf: Correct various core_reloc 64-bit assumptions") Signed-off-by: Tony Ambardar <[email protected]>
guidosarducci
added a commit
to guidosarducci/linux
that referenced
this pull request
Oct 28, 2025
Update memory-layout, alignment, and expected results to ensure consistent behaviour regardless of 32/64-bit host architecture, similar to a previous fix [0]. All tests now pass on 32-bit armhf after these changes: root@qemu-armhf:/usr/libexec/kselftests-bpf# ./test_progs -a core_reloc torvalds#75/1 core_reloc/kernel:OK torvalds#75/2 core_reloc/module_probed:OK torvalds#75/3 core_reloc/module_direct:OK [...] torvalds#75/78 core_reloc/enum64val___err_missing:OK torvalds#75 core_reloc:OK Summary: 1/78 PASSED, 0 SKIPPED, 0 FAILED 0: 5705d70 ("selftests/bpf: Correct various core_reloc 64-bit assumptions") Signed-off-by: Tony Ambardar <[email protected]>
guidosarducci
added a commit
to guidosarducci/linux
that referenced
this pull request
Oct 30, 2025
Update memory-layout, alignment, and expected results to ensure consistent behaviour regardless of 32/64-bit host architecture, similar to a previous fix [0]. All tests now pass on 32-bit armhf after these changes: root@qemu-armhf:/usr/libexec/kselftests-bpf# ./test_progs -a core_reloc torvalds#75/1 core_reloc/kernel:OK torvalds#75/2 core_reloc/module_probed:OK torvalds#75/3 core_reloc/module_direct:OK [...] torvalds#75/78 core_reloc/enum64val___err_missing:OK torvalds#75 core_reloc:OK Summary: 1/78 PASSED, 0 SKIPPED, 0 FAILED 0: 5705d70 ("selftests/bpf: Correct various core_reloc 64-bit assumptions") Signed-off-by: Tony Ambardar <[email protected]>
guidosarducci
added a commit
to guidosarducci/linux
that referenced
this pull request
Nov 3, 2025
Update memory-layout, alignment, and expected results to ensure consistent behaviour regardless of 32/64-bit host architecture, similar to a previous fix [0]. All tests now pass on 32-bit armhf after these changes: root@qemu-armhf:/usr/libexec/kselftests-bpf# ./test_progs -a core_reloc torvalds#75/1 core_reloc/kernel:OK torvalds#75/2 core_reloc/module_probed:OK torvalds#75/3 core_reloc/module_direct:OK [...] torvalds#75/78 core_reloc/enum64val___err_missing:OK torvalds#75 core_reloc:OK Summary: 1/78 PASSED, 0 SKIPPED, 0 FAILED 0: 5705d70 ("selftests/bpf: Correct various core_reloc 64-bit assumptions") Signed-off-by: Tony Ambardar <[email protected]>
guidosarducci
added a commit
to guidosarducci/linux
that referenced
this pull request
Nov 5, 2025
Update memory-layout, alignment, and expected results to ensure consistent behaviour regardless of 32/64-bit host architecture, similar to a previous fix [0]. All tests now pass on 32-bit armhf after these changes: root@qemu-armhf:/usr/libexec/kselftests-bpf# ./test_progs -a core_reloc torvalds#75/1 core_reloc/kernel:OK torvalds#75/2 core_reloc/module_probed:OK torvalds#75/3 core_reloc/module_direct:OK [...] torvalds#75/78 core_reloc/enum64val___err_missing:OK torvalds#75 core_reloc:OK Summary: 1/78 PASSED, 0 SKIPPED, 0 FAILED 0: 5705d70 ("selftests/bpf: Correct various core_reloc 64-bit assumptions") Signed-off-by: Tony Ambardar <[email protected]>
guidosarducci
added a commit
to guidosarducci/linux
that referenced
this pull request
Nov 5, 2025
Update memory-layout, alignment, and expected results to ensure consistent behaviour regardless of 32/64-bit host architecture, similar to a previous fix [0]. All tests now pass on 32-bit armhf after these changes: root@qemu-armhf:/usr/libexec/kselftests-bpf# ./test_progs -a core_reloc torvalds#75/1 core_reloc/kernel:OK torvalds#75/2 core_reloc/module_probed:OK torvalds#75/3 core_reloc/module_direct:OK [...] torvalds#75/78 core_reloc/enum64val___err_missing:OK torvalds#75 core_reloc:OK Summary: 1/78 PASSED, 0 SKIPPED, 0 FAILED 0: 5705d70 ("selftests/bpf: Correct various core_reloc 64-bit assumptions") Signed-off-by: Tony Ambardar <[email protected]>
guidosarducci
added a commit
to guidosarducci/linux
that referenced
this pull request
Nov 7, 2025
Update memory-layout, alignment, and expected results to ensure consistent behaviour regardless of 32/64-bit host architecture, similar to a previous fix [0]. All tests now pass on 32-bit armhf after these changes: root@qemu-armhf:/usr/libexec/kselftests-bpf# ./test_progs -a core_reloc torvalds#75/1 core_reloc/kernel:OK torvalds#75/2 core_reloc/module_probed:OK torvalds#75/3 core_reloc/module_direct:OK [...] torvalds#75/78 core_reloc/enum64val___err_missing:OK torvalds#75 core_reloc:OK Summary: 1/78 PASSED, 0 SKIPPED, 0 FAILED 0: 5705d70 ("selftests/bpf: Correct various core_reloc 64-bit assumptions") Signed-off-by: Tony Ambardar <[email protected]>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
97 participants
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
No description provided.