summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2015-05-15drm/msm: fix locking inconsistencies in gpu->destroy()Rob Clark
In error paths, this was being called without struct_mutex held. Leading to panics like: msm 1a00000.qcom,mdss_mdp: No memory protection without IOMMU Kernel panic - not syncing: BUG! CPU: 0 PID: 1409 Comm: cat Not tainted 4.0.0-dirty #4 Hardware name: Qualcomm Technologies, Inc. APQ 8016 SBC (DT) Call trace: [<ffffffc000089c78>] dump_backtrace+0x0/0x118 [<ffffffc000089da0>] show_stack+0x10/0x20 [<ffffffc0006686d4>] dump_stack+0x84/0xc4 [<ffffffc0006678b4>] panic+0xd0/0x210 [<ffffffc0003e1ce4>] drm_gem_object_free+0x5c/0x60 [<ffffffc000402870>] adreno_gpu_cleanup+0x60/0x80 [<ffffffc0004035a0>] a3xx_destroy+0x20/0x70 [<ffffffc0004036f4>] a3xx_gpu_init+0x84/0x108 [<ffffffc0004018b8>] adreno_load_gpu+0x58/0x190 [<ffffffc000419dac>] msm_open+0x74/0x88 [<ffffffc0003e0a48>] drm_open+0x168/0x400 [<ffffffc0003e7210>] drm_stub_open+0xa8/0x118 [<ffffffc0001a0e84>] chrdev_open+0x94/0x198 [<ffffffc000199f88>] do_dentry_open+0x208/0x310 [<ffffffc00019a4c4>] vfs_open+0x44/0x50 [<ffffffc0001aa26c>] do_last.isra.14+0x2c4/0xc10 [<ffffffc0001aac38>] path_openat+0x80/0x5e8 [<ffffffc0001ac354>] do_filp_open+0x2c/0x98 [<ffffffc00019b60c>] do_sys_open+0x13c/0x228 [<ffffffc00019b72c>] SyS_openat+0xc/0x18 CPU1: stopping But there isn't any particularly good reason to hold struct_mutex for teardown, so just standardize on calling it without the mutex held and use the _unlocked() versions for GEM obj unref'ing Signed-off-by: Rob Clark <robdclark@gmail.com>
2015-05-15MAINTAINERS: Add dts entries for some of the Marvell SoCsGregory CLEMENT
Since many releases, the modifications of the mvebu and berlin device tree files are merged through the mvebu subsystem. This patch makes it official in order to help the contributors using the get_maintainer.pl to find the accurate peoples. In the same time, updated the mvebu description which now includes the kirkwood SoCs and new Armada SoCs. Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com> Acked-by: Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com> Acked-by: Jason Cooper <jason@lakedaemon.net> Acked-by: Andrew Lunn <andrew@lunn.ch>
2015-05-15ARM: fix missing syscall trace exitRussell King
Josh Stone reports: I've discovered a case where both arm and arm64 will miss a ptrace syscall-exit that they should report. If the syscall is entered without TIF_SYSCALL_TRACE set, then it goes on the fast path. It's then possible to have TIF_SYSCALL_TRACE added in the middle of the syscall, but ret_fast_syscall doesn't check this flag again. Fix this by always checking for a syscall trace in the fast exit path. Reported-by: Josh Stone <jistone@redhat.com> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2015-05-15x86: Align jump targets to 1-byte boundariesIngo Molnar
The following NOP in a hot function caught my attention: > 5a: 66 0f 1f 44 00 00 nopw 0x0(%rax,%rax,1) That's a dead NOP that bloats the function a bit, added for the default 16-byte alignment that GCC applies for jump targets. I realize that x86 CPU manufacturers recommend 16-byte jump target alignments (it's in the Intel optimization manual), to help their relatively narrow decoder prefetch alignment and uop cache constraints, but the cost of that is very significant: text data bss dec filename 12566391 1617840 1089536 15273767 vmlinux.align.16-byte 12224951 1617840 1089536 14932327 vmlinux.align.1-byte By using 1-byte jump target alignment (i.e. no alignment at all) we get an almost 3% reduction in kernel size (!) - and a probably similar reduction in I$ footprint. Now, the usual justification for jump target alignment is the following: - modern decoders tend to have 16-byte (effective) decoder prefetch windows. (AMD documents it higher but measurements suggest the effective prefetch window on curretn uarchs is still around 16 bytes) - on Intel there's also the uop-cache with cachelines that have 16-byte granularity and limited associativity. - older x86 uarchs had a penalty for decoder fetches that crossed 16-byte boundaries. These limits are mostly gone from recent uarchs. So if a forward jump target is aligned to cacheline boundary then prefetches will start from a new prefetch-cacheline and there's higher chance for decoding in fewer steps and packing tightly. But I think that argument is flawed for typical optimized kernel code flows: forward jumps often go to 'cold' (uncommon) pieces of code, and aligning cold code to cache lines does not bring a lot of advantages (they are uncommon), while it causes collateral damage: - their alignment 'spreads out' the cache footprint, it shifts followup hot code further out - plus it slows down even 'cold' code that immediately follows 'hot' code (like in the above case), which could have benefited from the partial cacheline that comes off the end of hot code. But even in the cache-hot case the 16 byte alignment brings disadvantages: - it spreads out the cache footprint, possibly making the code fall out of the L1 I$. - On Intel CPUs, recent microarchitectures have plenty of uop cache (typically doubling every 3 years) - while the size of the L1 cache grows much less aggressively. So workloads are rarely uop cache limited. The only situation where alignment might matter are tight loops that could fit into a single 16 byte chunk - but those are pretty rare in the kernel: if they exist they tend to be pointer chasing or generic memory ops, which both tend to be cache miss (or cache allocation) intensive and are not decoder bandwidth limited. So the balance of arguments strongly favors packing kernel instructions tightly versus maximizing for decoder bandwidth: this patch changes the jump target alignment from 16 bytes to 1 byte (tightly packed, unaligned). Acked-by: Denys Vlasenko <dvlasenk@redhat.com> Cc: Andy Lutomirski <luto@amacapital.net> Cc: Aswin Chandramouleeswaran <aswin@hp.com> Cc: Borislav Petkov <bp@alien8.de> Cc: Brian Gerst <brgerst@gmail.com> Cc: Davidlohr Bueso <dave@stgolabs.net> Cc: H. Peter Anvin <hpa@zytor.com> Cc: Jason Low <jason.low2@hp.com> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Paul E. McKenney <paulmck@linux.vnet.ibm.com> Cc: Peter Zijlstra <a.p.zijlstra@chello.nl> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Tim Chen <tim.c.chen@linux.intel.com> Link: http://lkml.kernel.org/r/20150410120846.GA17101@gmail.com Signed-off-by: Ingo Molnar <mingo@kernel.org>
2015-05-15iwlwifi: mvm: fix MLME triggerEmmanuel Grumbach
A few triggers have status = MLME_SUCCESS and they are still interesting. E.g. if we want to collect data upon deauth, the status will be MLME_SUCCESS. Fix that. Fixes: d42f53503406 ("iwlwifi: mvm: add trigger for firmware dump upon MLME failures") Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
2015-05-15iwlwifi: pcie: don't disable the busmaster DMA clock for family 8000Avri Altman
Disabling the clocks is a standard procedure while stopping the device. On family 8000 however, disabling the bus master DMA clock increases the NIC's power consumption. To fix this, skip this call if the device family is IWL_DEVICE_FAMILY_8000. Signed-off-by: Avri Altman <avri.altman@intel.com> Reviewed-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
2015-05-15iwlwifi: 7000: modify the firmware name for 3165Emmanuel Grumbach
3165 really needs to load iwlwifi-7265D-13.ucode. This device is supported starting from -13.ucode, update the MIN and OK defines accordingly. While at it, add 3165 to the device list in the Kconfig file. Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
2015-05-15Merge branch 'liblockdep-fixes' of ↵Ingo Molnar
git://git.kernel.org/pub/scm/linux/kernel/git/sashal/linux into perf/urgent Pull liblockdep fixes from Sasha Levin: "two fixes that deal with compilation errors in liblockdep." Signed-off-by: Ingo Molnar <mingo@kernel.org>
2015-05-15Merge tag 'perf-core-for-mingo' of ↵Ingo Molnar
git://git.kernel.org/pub/scm/linux/kernel/git/acme/linux into perf/core Pull perf/core improvements and fixes from Arnaldo Carvalho de Melo: User visible changes: - Add --range option to show a variable's location range in 'perf probe', helping in collecting variables in probes when there is a mismatch between assembly and source code (He Kuang) - Show better error message when failed to find variable in 'perf probe' (He Kuang) - Fix 'perf report --thread' handling and document it better (Namhyung Kim) Infrastructure changes: - Fix to get negative exit codes in 'perf test' test routines (He Kuang) - Make flex/bison calls honour V=1 (Jiri Olsa) - Ignore tail calls to probed functions in 'perf probe' (Naveen N. Rao) - Fix refcount expectations in map_group share 'perf test' (Arnaldo Carvalho de Melo) Build Fixes: - Fix 'perf kmem' build due to compiler thinking uninitialized var is being accessed (Arnaldo Carvalho de Melo) - Provide le16toh if not defined, to fix the libtraceevent build on older distros (Arnaldo Carvalho de Melo) - Fix 'perf trace' build on older distros by providing some CLOEXEC, NONBLOCK defines (Arnaldo Carvalho de Melo) Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com> Signed-off-by: Ingo Molnar <mingo@kernel.org>
2015-05-15Merge tag 'drm-intel-fixes-2015-05-13' of ↵Dave Airlie
git://anongit.freedesktop.org/drm-intel into drm-fixes fix one gpu hang on resume. * tag 'drm-intel-fixes-2015-05-13' of git://anongit.freedesktop.org/drm-intel: drm/i915: Avoid GPU hang when coming out of s3 or s4
2015-05-15Merge branch 'drm-fixes-4.1' of git://people.freedesktop.org/~agd5f/linux ↵Dave Airlie
into drm-fixes radeon minor fixes, and pci id addition. * 'drm-fixes-4.1' of git://people.freedesktop.org/~agd5f/linux: drm/radeon: don't do mst probing if MST isn't enabled. drm/radeon: add new bonaire pci id drm/radeon: fix VM_CONTEXT*_PAGE_TABLE_END_ADDR handling
2015-05-15turn user_{path_at,path,lpath,path_dir}() into static inlinesAl Viro
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
2015-05-15namei: move saved_nd pointer into struct nameidataAl Viro
these guys are always declared next to each other; might as well put the former (pointer to previous instance) into the latter and simplify the calling conventions for {set,restore}_nameidata() Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
2015-05-15inline user_path_create()Al Viro
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
2015-05-15inline user_path_parent()Al Viro
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
2015-05-15namei: trim do_last() argumentsAl Viro
now that struct filename is stashed in nameidata we have no need to pass it in Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
2015-05-15namei: stash dfd and name into nameidataAl Viro
fewer arguments to pass around... Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
2015-05-15namei: fold path_cleanup() into terminate_walk()Al Viro
they are always called next to each other; moreover, terminate_walk() is more symmetrical that way. Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
2015-05-15namei: saner calling conventions for filename_parentat()Al Viro
a) make it reject ERR_PTR() for name b) make it putname(name) on all other failure exits c) make it return name on success again, simplifies the callers Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
2015-05-15namei: saner calling conventions for filename_create()Al Viro
a) make it reject ERR_PTR() for name b) make it putname(name) upon return in all other cases. seriously simplifies the callers... Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
2015-05-15namei: shift nameidata down into filename_parentat()Al Viro
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
2015-05-15namei: make filename_lookup() reject ERR_PTR() passed as nameAl Viro
makes for much easier life in callers Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
2015-05-15namei: shift nameidata inside filename_lookup()Al Viro
pass root instead; non-NULL => copy to nd.root and set LOOKUP_ROOT in flags Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
2015-05-15namei: move putname() call into filename_lookup()Al Viro
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
2015-05-15namei: pass the struct path to store the result down into path_lookupat()Al Viro
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
2015-05-15namei: uninline set_root{,_rcu}()Al Viro
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
2015-05-15namei: be careful with mountpoint crossings in follow_dotdot_rcu()Al Viro
Otherwise we are risking a hard error where nonlazy restart would be the right thing to do; it's a very narrow race with mount --move and most of the time it ends up being completely harmless, but it's possible to construct a case when we'll get a bogus hard error instead of falling back to non-lazy walk... For one thing, when crossing _into_ overmount of parent we need to check for mount_lock bumps when we get NULL from __lookup_mnt() as well. For another, and less exotically, we need to make sure that the data fetched in follow_up_rcu() had been consistent. ->mnt_mountpoint is pinned for as long as it is a mountpoint, but we need to check mount_lock after fetching to verify that. Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
2015-05-15Documentation: remove outdated information from automount-support.txtNeilBrown
The guidelines for adding automount support to a filesystem in filesystems/automount-support.txt is out or date. filesystems/autofs4.txt contains more current text, so replace the out-of-date content with a reference to that. Signed-off-by: NeilBrown <neilb@suse.de> Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
2015-05-15get rid of assorted nameidata-related debrisAl Viro
pointless forward declarations, stale comments Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
2015-05-15lustre: kill unused helperAl Viro
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
2015-05-15lustre: kill unused macro (LOOKUP_CONTINUE)Al Viro
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
2015-05-15namei: unlazy_walk() doesn't need to mess with current->fs anymoreAl Viro
now that we have ->root_seq, legitimize_path(&nd->root, nd->root_seq) will do just fine... Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
2015-05-15update Documentation/filesystems/ regarding the follow_link/put_link changesAl Viro
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
2015-05-15namei: handle absolute symlinks without dropping out of RCU modeAl Viro
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
2015-05-15enable passing fast relative symlinks without dropping out of RCU modeAl Viro
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
2015-05-15VFS/namei: make the use of touch_atime() in get_link() RCU-safe.NeilBrown
touch_atime is not RCU-safe, and so cannot be called on an RCU walk. However, in situations where RCU-walk makes a difference, the symlink will likely to accessed much more often than it is useful to update the atime. So split out the test of "Does the atime actually need to be updated" into atime_needs_update(), and have get_link() unlazy if it finds that it will need to do that update. Signed-off-by: NeilBrown <neilb@suse.de> Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
2015-05-15namei: don't unlazy until get_link()Al Viro
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
2015-05-15namei: make unlazy_walk and terminate_walk handle nd->stack, add unlazy_linkAl Viro
We are almost done - primitives for leaving RCU mode are aware of nd->stack now, a new primitive for going to non-RCU mode when we have a symlink on hands added. The thing we are heavily relying upon is that *any* unlazy failure will be shortly followed by terminate_walk(), with no access to nameidata in between. So it's enough to leave the things in a state terminate_walk() would cope with. Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
2015-05-15ext4: fix an ext3 collapse range regression in xfstestsTheodore Ts'o
The xfstests test suite assumes that an attempt to collapse range on the range (0, 1) will return EOPNOTSUPP if the file system does not support collapse range. Commit 280227a75b56: "ext4: move check under lock scope to close a race" broke this, and this caused xfstests to fail when run when testing file systems that did not have the extents feature enabled. Reported-by: Eric Whitney <enwlinux@gmail.com> Signed-off-by: Theodore Ts'o <tytso@mit.edu>
2015-05-14target: Add missing parenthesesBart Van Assche
Code like " &= ~CMD_T_BUSY | ..." only clears CMD_T_BUSY but not the other flag. Modify these statements such that both flags are cleared. (Fix fuzz for target_write_prot_action code in mainline - nab) Signed-off-by: Bart Van Assche <bart.vanassche@sandisk.com> Reviewed-by: Christoph Hellwig <hch@lst.de> Signed-off-by: Nicholas Bellinger <nab@linux-iscsi.org>
2015-05-14target: Fix bidi command handlingBart Van Assche
The function transport_complete_qf() must call either queue_data_in() or queue_status() but not both. Signed-off-by: Bart Van Assche <bart.vanassche@sandisk.com> Reviewed-by: Christoph Hellwig <hch@lst.de> Signed-off-by: Nicholas Bellinger <nab@linux-iscsi.org>
2015-05-14rename RTNH_F_EXTERNAL to RTNH_F_OFFLOADRoopa Prabhu
RTNH_F_EXTERNAL today is printed as "offload" in iproute2 output. This patch renames the flag to be consistent with what the user sees. Signed-off-by: Roopa Prabhu <roopa@cumulusnetworks.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2015-05-14net/mlx4: Avoid 'may be used uninitialized' warningsBjorn Helgaas
With a cross-compiler based on gcc-4.9, I see warnings like the following: drivers/net/ethernet/mellanox/mlx4/resource_tracker.c: In function 'mlx4_SW2HW_CQ_wrapper': drivers/net/ethernet/mellanox/mlx4/resource_tracker.c:3048:10: error: 'cq' may be used uninitialized in this function [-Werror=maybe-uninitialized] cq->mtt = mtt; I think the warning is spurious because we only use cq when cq_res_start_move_to() returns zero, and it always initializes *cq in that case. The srq case is similar. But maybe gcc isn't smart enough to figure that out. Initialize cq and srq explicitly to avoid the warnings. Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2015-05-14ipv6: Fix udp checksums with raw socketsVlad Yasevich
It was reported that trancerout6 would cause a kernel to crash when trying to compute checksums on raw UDP packets. The cause was the check in __ip6_append_data that would attempt to use partial checksums on the packet. However, raw sockets do not initialize partial checksum fields so partial checksums can't be used. Solve this the same way IPv4 does it. raw sockets pass transhdrlen value of 0 to ip_append_data which causes the checksum to be computed in software. Use the same check in ip6_append_data (check transhdrlen). Reported-by: Wolfgang Walter <linux@stwm.de> CC: Wolfgang Walter <linux@stwm.de> CC: Eric Dumazet <eric.dumazet@gmail.com> Signed-off-by: Vladislav Yasevich <vyasevic@redhat.com> Acked-by: Eric Dumazet <edumazet@google.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2015-05-14Merge tag 'pm+acpi-4.1-rc4' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm Pull ACPI fixes from Rafael Wysocki: "Two fixes here, one revert of a recent ACPICA commit that broke audio support on one Dell machine and a fix for a long-standing issue that may cause systems to break randomly during boot. Specifics: - The recent ACPICA commit that set the ACPI _REV return value to 2 (which is the value always used by Windows and now mandated by the spec too) in order to prevent the firmware people from using it to play tricks with us caused a serious audio regression to happen on Dell XPS 13 (the AML on that machine uses the _REV return value to decide how to expose audio to the OS and does that to hide the lack of proper support for its I2S audio in Linux), so revert that commit for now and we'll revisit the issue in the next cycle. - Ensure that the ordering of acpi_reserve_resources() with respect to the rest of the ACPI initialization sequence will always be the same, or the IO or memory region occupied by the ACPI fixed registers may be assigned to a PCI host bridge as a result of a race and random breakage ensues going forward" * tag 'pm+acpi-4.1-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm: Revert "ACPICA: Permanently set _REV to the value '2'." ACPI / init: Fix the ordering of acpi_reserve_resources()
2015-05-14Merge tag 'arm64-fixes' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux Pull arm64 fixes from Will Deacon: - fix potential memory leak in perf PMU probing - BPF sign extension fix for 64-bit immediates - fix build failure with unusual configuration - revert unused and broken branch patching from alternative code * tag 'arm64-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux: arm64: perf: fix memory leak when probing PMU PPIs arm64: bpf: fix signedness bug in loading 64-bit immediate arm64: mm: Fix build error with CONFIG_SPARSEMEM_VMEMMAP disabled Revert "arm64: alternative: Allow immediate branch as alternative instruction"
2015-05-14Merge branch 'dmi-for-linus' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/jdelvare/staging Pull dmi fixes from Jean Delvare. * 'dmi-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/jdelvare/staging: firmware: dmi_scan: Fix ordering of product_uuid firmware: dmi_scan: Simplified displayed version
2015-05-14mm, numa: really disable NUMA balancing by default on single node machinesMel Gorman
NUMA balancing is meant to be disabled by default on UMA machines but the check is using nr_node_ids (highest node) instead of num_online_nodes (online nodes). The consequences are that a UMA machine with a node ID of 1 or higher will enable NUMA balancing. This will incur useless overhead due to minor faults with the impact depending on the workload. These are the impact on the stats when running a kernel build on a single node machine whose node ID happened to be 1: vanilla patched NUMA base PTE updates 5113158 0 NUMA huge PMD updates 643 0 NUMA page range updates 5442374 0 NUMA hint faults 2109622 0 NUMA hint local faults 2109622 0 NUMA hint local percent 100 100 NUMA pages migrated 0 0 Signed-off-by: Mel Gorman <mgorman@suse.de> Reviewed-by: Rik van Riel <riel@redhat.com> Cc: <stable@vger.kernel.org> [3.8+] Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2015-05-14MAINTAINERS: update Jingoo Han's email addressJingoo Han
Change my private email address. Signed-off-by: Jingoo Han <jingoohan1@gmail.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2015-05-14CMA: page_isolation: check buddy before accessing itHui Zhu
I had an issue: Unable to handle kernel NULL pointer dereference at virtual address 0000082a pgd = cc970000 [0000082a] *pgd=00000000 Internal error: Oops: 5 [#1] PREEMPT SMP ARM PC is at get_pageblock_flags_group+0x5c/0xb0 LR is at unset_migratetype_isolate+0x148/0x1b0 pc : [<c00cc9a0>] lr : [<c0109874>] psr: 80000093 sp : c7029d00 ip : 00000105 fp : c7029d1c r10: 00000001 r9 : 0000000a r8 : 00000004 r7 : 60000013 r6 : 000000a4 r5 : c0a357e4 r4 : 00000000 r3 : 00000826 r2 : 00000002 r1 : 00000000 r0 : 0000003f Flags: Nzcv IRQs off FIQs on Mode SVC_32 ISA ARM Segment user Control: 10c5387d Table: 2cb7006a DAC: 00000015 Backtrace: get_pageblock_flags_group+0x0/0xb0 unset_migratetype_isolate+0x0/0x1b0 undo_isolate_page_range+0x0/0xdc __alloc_contig_range+0x0/0x34c alloc_contig_range+0x0/0x18 This issue is because when calling unset_migratetype_isolate() to unset a part of CMA memory, it try to access the buddy page to get its status: if (order >= pageblock_order) { page_idx = page_to_pfn(page) & ((1 << MAX_ORDER) - 1); buddy_idx = __find_buddy_index(page_idx, order); buddy = page + (buddy_idx - page_idx); if (!is_migrate_isolate_page(buddy)) { But the begin addr of this part of CMA memory is very close to a part of memory that is reserved at boot time (not in buddy system). So add a check before accessing it. [akpm@linux-foundation.org: use conventional code layout] Signed-off-by: Hui Zhu <zhuhui@xiaomi.com> Suggested-by: Laura Abbott <labbott@redhat.com> Suggested-by: Joonsoo Kim <iamjoonsoo.kim@lge.com> Cc: Vlastimil Babka <vbabka@suse.cz> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
generated by cgit (git 2.34.1) at 2025-09-19 15:48:21 +0000