aboutsummaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2016-03-21drm/amdgpu: clean up path handling for powerplayAlex Deucher1-7/+7
Use $(FULL_AMD_PATH) like everything else. Reviewed-by: Christian König <[email protected]> Reviewed-by: Michel Dänzer <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2016-03-21drm/amd/powerplay: fix memory leak of tdp_tableColin Ian King1-1/+3
tdp_table is being leaked on failed allocations of hwmgr->dyn_state.cac_dtp_table. kfree tdp_table on the error return path to fix the leak. Signed-off-by: Colin Ian King <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2016-03-21mdio-sun4i: oops in error handling in probeDan Carpenter1-1/+3
We could end up dereferencing an error pointer when we call regulator_disable(). Fixes: 4bdcb1dd9feb ('net: Add MDIO bus driver for the Allwinner EMAC') Signed-off-by: Dan Carpenter <[email protected]> Acked-by: Chen-Yu Tsai <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2016-03-21net: smc911x: avoid unused variable warningsArnd Bergmann1-0/+2
The change to use the generic DMA engine API in the smc911x driver has led to a harmless warning about unused local variables: smsc/smc911x.c: In function 'smc911x_probe': smsc/smc911x.c:1796:20: error: unused variable 'param' smsc/smc911x.c:1795:17: error: unused variable 'mask' smsc/smc911x.c:1794:26: error: unused variable 'config' This puts the variable declarations inside of the same #ifdef that protects their use. Signed-off-by: Arnd Bergmann <[email protected]> Fixes: 79d3b59a93ba ("net: smc911x: convert pxa dma to dmaengine") Signed-off-by: David S. Miller <[email protected]>
2016-03-21ALSA: hda - Fix missing ELD update at unpluggingTakashi Iwai1-2/+1
i915 get_eld ops may return an error when no encoder is connected, and currently we regard the error as fatal and skip the whole ELD handling. This ended up with the missing ELD update at unplugging. This patch fixes the issue by treating the error as the unplugged state, instead of skipping the rest. Reported-by: Libin Yang <[email protected]> Cc: <[email protected]> # v4.5 Signed-off-by: Takashi Iwai <[email protected]>
2016-03-21drivers/xen: make platform-pci.c explicitly non-modularPaul Gortmaker1-13/+9
The Kconfig currently controlling compilation of this code is: arch/x86/xen/Kconfig:config XEN_PVHVM arch/x86/xen/Kconfig: def_bool y ...meaning that it currently is not being built as a module by anyone. Lets remove the modular code that is essentially orphaned, so that when reading the driver there is no doubt it is builtin-only. Since module_init translates to device_initcall in the non-modular case, the init ordering remains unchanged with this commit. Also note that MODULE_DEVICE_TABLE is a no-op for non-modular code. We also delete the MODULE_LICENSE tag etc. since all that information was (or is now) contained at the top of the file in the comments. In removing "module" from the init fcn name, we observe a namespace collision with the probe function, so we use "probe" in the name of the probe function, and "init" in the registration fcn, as per standard convention, as suggested by Stefano. Signed-off-by: Paul Gortmaker <[email protected]> Reviewed-by: Stefano Stabellini <[email protected]> Signed-off-by: David Vrabel <[email protected]>
2016-03-21drivers/xen: make sys-hypervisor.c explicitly non-modularPaul Gortmaker1-51/+8
The Kconfig currently controlling compilation of this code is: config XEN_SYS_HYPERVISOR bool "Create xen entries under /sys/hypervisor" ...meaning that it currently is not being built as a module by anyone. Lets remove the modular code that is essentially orphaned, so that when reading the driver there is no doubt it is builtin-only. Since module_init translates to device_initcall in the non-modular case, the init ordering remains unchanged with this commit. However one could argue that fs_initcall() might make more sense here. This change means that the one line function xen_properties_destroy() has only one user left, and since that is inside an #ifdef, we just manually inline it there vs. adding more ifdeffery around the function to avoid compile warnings about "defined but not used". In order to be consistent we also manually inline the other _destroy functions that are also just one line sysfs functions calls with only one call site remaing, even though they wouldn't need #ifdeffery. Signed-off-by: Paul Gortmaker <[email protected]> Reviewed-by: Stefano Stabellini <[email protected]> Signed-off-by: David Vrabel <[email protected]>
2016-03-21drivers/xen: make xenbus_dev_[front/back]end explicitly non-modularPaul Gortmaker2-22/+4
The Makefile / Kconfig currently controlling compilation here is: obj-y += xenbus_dev_frontend.o [...] obj-$(CONFIG_XEN_BACKEND) += xenbus_dev_backend.o ...with: drivers/xen/Kconfig:config XEN_BACKEND drivers/xen/Kconfig: bool "Backend driver support" ...meaning that they currently are not being built as modules by anyone. Lets remove the modular code that is essentially orphaned, so that when reading the driver there is no doubt it is builtin-only. Since module_init translates to device_initcall in the non-modular case, the init ordering remains unchanged with this commit. We also delete the MODULE_LICENSE tag since all that information is already contained at the top of the file in the comments. Signed-off-by: Paul Gortmaker <[email protected]> Reviewed-by: Stefano Stabellini <[email protected]> Signed-off-by: David Vrabel <[email protected]>
2016-03-21drivers/xen: make [xen-]ballon explicitly non-modularPaul Gortmaker2-15/+3
The Makefile / Kconfig currently controlling compilation here is: obj-y += grant-table.o features.o balloon.o manage.o preempt.o time.o [...] obj-$(CONFIG_XEN_BALLOON) += xen-balloon.o ...with: drivers/xen/Kconfig:config XEN_BALLOON drivers/xen/Kconfig: bool "Xen memory balloon driver" ...meaning that they currently are not being built as modules by anyone. Lets remove the modular code that is essentially orphaned, so that when reading the driver there is no doubt it is builtin-only. In doing so we uncover two implict includes that were obtained by module.h having such a wide include scope itself: In file included from drivers/xen/xen-balloon.c:41:0: include/xen/balloon.h:26:51: warning: ‘struct page’ declared inside parameter list [enabled by default] int alloc_xenballooned_pages(int nr_pages, struct page **pages); ^ include/xen/balloon.h: In function ‘register_xen_selfballooning’: include/xen/balloon.h:35:10: error: ‘ENOSYS’ undeclared (first use in this function) return -ENOSYS; ^ This is fixed by adding mm-types.h and errno.h to the list. We also delete the MODULE_LICENSE tags since all that information is already contained at the top of the file in the comments. Signed-off-by: Paul Gortmaker <[email protected]> Reviewed-by: Stefano Stabellini <[email protected]> Signed-off-by: David Vrabel <[email protected]>
2016-03-21xen: audit usages of module.h ; remove unnecessary instancesPaul Gortmaker12-11/+7
Code that uses no modular facilities whatsoever should not be sourcing module.h at all, since that header drags in a bunch of other headers with it. Similarly, code that is not explicitly using modular facilities like module_init() but only is declaring module_param setup variables should be using moduleparam.h and not the larger module.h file for that. In making this change, we also uncover an implicit use of BUG() in inline fcns within arch/arm/include/asm/xen/hypercall.h so we explicitly source <linux/bug.h> for that file now. Signed-off-by: Paul Gortmaker <[email protected]> Reviewed-by: Stefano Stabellini <[email protected]> Signed-off-by: David Vrabel <[email protected]>
2016-03-21mailbox: Introduce TI message manager driverNishanth Menon4-0/+687
Support for TI Message Manager Module. This hardware block manages a bunch of hardware queues meant for communication between processor entities. Clients sitting on top of this would manage the required protocol for communicating with the counterpart entities. For more details on TI Message Manager hardware block, see documentation that will is available here: http://www.ti.com/lit/ug/spruhy8/spruhy8.pdf Chapter 8.1(Message Manager) Signed-off-by: Nishanth Menon <[email protected]> Signed-off-by: Jassi Brar <[email protected]>
2016-03-21Documentation: dt: mailbox: Add TI Message ManagerNishanth Menon1-0/+50
Message Manager is a hardware block used to communicate with various processor systems within certain Texas Instrument's Keystone generation SoCs. This hardware engine is used to transfer messages from various compute entities(or processors) within the SoC. It is designed to be self contained without needing software initialization for operation. Signed-off-by: Nishanth Menon <[email protected]> Acked-by: Rob Herring <[email protected]> Signed-off-by: Jassi Brar <[email protected]>
2016-03-21cpuidle: menu: Fall back to polling if next timer event is nearRafael J. Wysocki1-4/+8
Commit a9ceb78bc75c (cpuidle,menu: use interactivity_req to disable polling) changed the behavior of the fallback state selection part of menu_select() so it looks at interactivity_req instead of data->next_timer_us when it makes its decision. That effectively caused polling to be used more often as fallback idle which led to significant increases of energy consumption in some cases. Commit e132b9b3bc7f (cpuidle: menu: use high confidence factors only when considering polling) changed that logic again to be more predictable, but that didn't help with the increased energy consumption problem. For this reason, go back to making decisions on which state to fall back to based on data->next_timer_us which is the time we know for sure something will happen rather than a prediction (which may be inaccurate and turns out to be so often enough to be problematic). However, take the target residency of the first proper idle state (C1) into account, so that state is not used as the fallback one if its target residency is greater than data->next_timer_us. Fixes: a9ceb78bc75c (cpuidle,menu: use interactivity_req to disable polling) Signed-off-by: Rafael J. Wysocki <[email protected]> Reported-and-tested-by: Doug Smythies <[email protected]>
2016-03-21btrfs: make sure we stay inside the bvec during __btrfs_lookup_bio_sumsChris Mason1-0/+10
Commit c40a3d38aff4e1c (Btrfs: Compute and look up csums based on sectorsized blocks) changes around how we walk the bios while looking up crcs. There's an inner loop that is jumping to the next bvec based on sectors and before it derefs the next bvec, it needs to make sure we're still in the bio. In this case, the outer loop would have decided to stop moving forward too, and the bvec deref is never actually used for anything. But CONFIG_DEBUG_PAGEALLOC catches it because we're outside our bio. Signed-off-by: Chris Mason <[email protected]> Reviewed-by: David Sterba <[email protected]>
2016-03-21Merge branches 'arm/rockchip', 'arm/exynos', 'arm/smmu', 'arm/mediatek', ↵Joerg Roedel25-414/+2953
'arm/io-pgtable', 'arm/renesas' and 'core' into next
2016-03-21kvm: arm64: Disable compiler instrumentation for hypervisor codeCatalin Marinas1-0/+4
With the recent rewrite of the arm64 KVM hypervisor code in C, enabling certain options like KASAN would allow the compiler to generate memory accesses or function calls to addresses not mapped at EL2. This patch disables the compiler instrumentation on the arm64 hypervisor code for gcov-based profiling (GCOV_KERNEL), undefined behaviour sanity checker (UBSAN) and kernel address sanitizer (KASAN). Signed-off-by: Catalin Marinas <[email protected]> Cc: Christoffer Dall <[email protected]> Cc: Marc Zyngier <[email protected]> Cc: Paolo Bonzini <[email protected]> Cc: <[email protected]> # 4.5+ Signed-off-by: Christoffer Dall <[email protected]>
2016-03-21PCI: Restore inclusion of pci/hotplug KconfigTero Roponen1-0/+1
Commit e7e127e3c767 ("PCI: Include pci/hotplug Kconfig directly from pci/Kconfig") added one line to pci/Kconfig. However, for some mysterious reason it isn't there now, even though there are no traces of removing it in the git log. I detected this issue when 'make oldconfig' removed all the options that depended on HOTPLUG_PCI. [bhelgaas: I botched the cfeb8139a1fb ("Merge branch 'pci/host-hv' into next") merge. "git diff cfeb8139a1fb^ cfeb8139a1fb" shows a conflict in drivers/pci/Kconfig, and I mistakenly dropped the hotplug/Kconfig piece.] Signed-off-by: Tero Roponen <[email protected]> Signed-off-by: Bjorn Helgaas <[email protected]>
2016-03-21arm64: Split pr_notice("Virtual kernel memory layout...") into multiple ↵Catalin Marinas1-32/+28
pr_cont() The printk() implementation has a limit of LOG_LINE_MAX (== 1024 - 32) buffer per call which the arm64 mem_init() breaches when printing the virtual memory layout with CONFIG_KASAN enabled. The result is that the last line is no longer printed. This patch splits the call into a pr_notice() + additional pr_cont() calls. Signed-off-by: Catalin Marinas <[email protected]> Acked-by: Mark Rutland <[email protected]>
2016-03-21arm64: drop unused __local_flush_icache_all()Kefeng Wang1-7/+0
After commit 65da0a8e34a8 ("arm64: use non-global mappings for UEFI runtime regions"), nobody use __local_flush_icache_all() anymore, so drop it. Signed-off-by: Kefeng Wang <[email protected]> Acked-by: Mark Rutland <[email protected]> Signed-off-by: Catalin Marinas <[email protected]>
2016-03-21arm64: fix KASLR boot-time I-cache maintenanceMark Rutland1-2/+3
Commit f80fb3a3d50843a4 ("arm64: add support for kernel ASLR") missed a DSB necessary to complete I-cache maintenance in the primary boot path, and hence stale instructions may still be present in the I-cache and may be executed until the I-cache maintenance naturally completes. Since commit 8ec41987436d566f ("arm64: mm: ensure patched kernel text is fetched from PoU"), all CPUs invalidate their I-caches after their MMU is enabled. Prior a CPU's MMU having been enabled, arbitrary lines may have been fetched from the PoC into I-caches. We never patch text expected to be executed with the MMU off. Thus, it is unnecessary to perform broadcast I-cache maintenance in the primary boot path. This patch reduces the scope of the I-cache maintenance to the local CPU, and adds the missing DSB with similar scope, matching prior maintenance in the primary boot path. Signed-off-by: Mark Rutland <[email protected]> Acked-by: Ard Biesehvuel <[email protected]> Cc: Will Deacon <[email protected]> Signed-off-by: Catalin Marinas <[email protected]>
2016-03-21arm64/kernel: fix incorrect EL0 check in inv_entry macroArd Biesheuvel1-1/+1
The implementation of macro inv_entry refers to its 'el' argument without the required leading backslash, which results in an undefined symbol 'el' to be passed into the kernel_entry macro rather than the index of the exception level as intended. This undefined symbol strangely enough does not result in build failures, although it is visible in vmlinux: $ nm -n vmlinux |head U el 0000000000000000 A _kernel_flags_le_hi32 0000000000000000 A _kernel_offset_le_hi32 0000000000000000 A _kernel_size_le_hi32 000000000000000a A _kernel_flags_le_lo32 ..... However, it does result in incorrect code being generated for invalid exceptions taken from EL0, since the argument check in kernel_entry assumes EL1 if its argument does not equal '0'. Signed-off-by: Ard Biesheuvel <[email protected]> Signed-off-by: Catalin Marinas <[email protected]>
2016-03-21drivers/perf: arm_pmu: avoid NULL dereference when not using devicetreeWill Deacon1-4/+3
Commit c6b90653f1f7 ("drivers/perf: arm_pmu: make info messages more verbose") breaks booting on systems where the PMU is probed without devicetree (e.g by inspecting the MIDR of the current CPU). In this case, pdev->dev.of_node is NULL and we shouldn't try to access its ->fullname field when printing probe error messages. This patch fixes the probing code to use of_node_full_name, which safely handles NULL nodes and removes the "Error %i" part of the string, since it's not terribly useful. Reported-by: Guenter Roeck <[email protected]> Signed-off-by: Will Deacon <[email protected]>
2016-03-21irqchip/mbigen: Handle multiple device nodes in a mbigen moduleMaJun1-14/+24
Each mbigen device is represented as a independent platform device. If the devices belong to the same mbigen hardware module, then the register space for these devices is the same. That leads to a resource conflict. The solution for this is to represent the mbigen module as a platform device and make the mbigen devices subdevices of that. The register space is associated to the mbigen module and therefor the resource conflict is avoided. [ tglx: Massaged changelog, cleaned up the code and removed the silly printk ] Signed-off-by: Ma Jun <[email protected]> Cc: [email protected] Cc: [email protected] Cc: [email protected] Cc: [email protected] Cc: [email protected] Cc: [email protected] Cc: [email protected] Cc: [email protected] Cc: [email protected] Cc: [email protected] Cc: [email protected] Cc: [email protected] Link: http://lkml.kernel.org/r/[email protected] Signed-off-by: Thomas Gleixner <[email protected]>
2016-03-21irqchip/mbigen: Adjust DT bindings to handle multiple devices in a moduleMaJun1-5/+17
A mbigen hardware module can contain more than one device node. These device nodes contain the same register definition. mbigen_dev1:intc_dev1 { ... reg = <0x0 0xc0080000 0x0 0x10000>; ... }; mbigen_dev2:intc_dev2 { ... reg = <0x0 0xc0080000 0x0 0x10000>; ... }; In this case both devices try to request the same resource resulting in a resource conflict. To address this problem the devices need to be subnodes of the mbigen hardware module, which then contains the unique register space. [ tglx: Massaged changelog ] Suggested-by: Mark Rutland <[email protected]> Signed-off-by: Ma Jun <[email protected]> Cc: [email protected] Cc: [email protected] Cc: [email protected] Cc: [email protected] Cc: [email protected] Cc: [email protected] Cc: [email protected] Cc: [email protected] Cc: [email protected] Cc: [email protected] Cc: [email protected] Link: http://lkml.kernel.org/r/20160203111602.GA1234@leverpostej Link: http://lkml.kernel.org/r/[email protected] Signed-off-by: Thomas Gleixner <[email protected]>
2016-03-21perf/x86/intel/rapl: Add missing Broadwell modelsSrinivas Pandruvada1-0/+2
Added Broadwell-H and Broadwell-Server. Signed-off-by: Srinivas Pandruvada <[email protected]> Cc: Alexander Shishkin <[email protected]> Cc: Arnaldo Carvalho de Melo <[email protected]> Cc: David Ahern <[email protected]> Cc: Jiri Olsa <[email protected]> Cc: Linus Torvalds <[email protected]> Cc: Namhyung Kim <[email protected]> Cc: Peter Zijlstra <[email protected]> Cc: Stephane Eranian <[email protected]> Cc: Thomas Gleixner <[email protected]> Cc: Vince Weaver <[email protected]> Cc: [email protected] Link: http://lkml.kernel.org/r/1458517938-25308-1-git-send-email-srinivas.pandruvada@linux.intel.com Signed-off-by: Ingo Molnar <[email protected]>
2016-03-21perf/x86/intel/uncore: Remove ev_sel_ext bit support for PCUKan Liang1-5/+2
The ev_sel_ext in PCU_MSR_PMON_CTL is locked on some CPU models, so despite it being documented in the SDM, if we write 1 to that bit then we can get a #GP fault. Which #GP the perf fuzzer happily triggered in Peter Zijlstra's testing. Also, there are no public events which use that bit, so remove ev_sel_ext bit support for PCU. Reported-by: Peter Zijlstra <[email protected]> Signed-off-by: Kan Liang <[email protected]> Acked-by: Peter Zijlstra <[email protected]> Cc: Alexander Shishkin <[email protected]> Cc: Arnaldo Carvalho de Melo <[email protected]> Cc: David Ahern <[email protected]> Cc: Jiri Olsa <[email protected]> Cc: Linus Torvalds <[email protected]> Cc: Namhyung Kim <[email protected]> Cc: Stephane Eranian <[email protected]> Cc: Thomas Gleixner <[email protected]> Cc: Vince Weaver <[email protected]> Link: http://lkml.kernel.org/r/[email protected] Signed-off-by: Ingo Molnar <[email protected]>
2016-03-21sched/cpuacct: Simplify the cpuacct codeZhao Lei2-25/+7
- Use for() instead of while() loop in some functions to make the code simpler. - Use this_cpu_ptr() instead of per_cpu_ptr() to make the code cleaner and a bit faster. Suggested-by: Peter Zijlstra <[email protected]> Signed-off-by: Zhao Lei <[email protected]> Signed-off-by: Peter Zijlstra (Intel) <[email protected]> Cc: Linus Torvalds <[email protected]> Cc: Tejun Heo <[email protected]> Cc: Thomas Gleixner <[email protected]> Link: http://lkml.kernel.org/r/d8a7ef9592f55224630cb26dea239f05b6398a4e.1458187654.git.zhaolei@cn.fujitsu.com Signed-off-by: Ingo Molnar <[email protected]>
2016-03-21sched/cpuacct: Rename parameter in cpuusage_write() for readabilityDongsheng Yang1-2/+5
The name of the 'reset' parameter to cpuusage_write() is quite confusing, because the only valid value we allow is '0', so !reset is actually the case that resets ... Rename it to 'val' and explain it in a comment that we only allow 0. Signed-off-by: Dongsheng Yang <[email protected]> Cc: Linus Torvalds <[email protected]> Cc: Peter Zijlstra <[email protected]> Cc: Thomas Gleixner <[email protected]> Cc: [email protected] Cc: [email protected] Link: http://lkml.kernel.org/r/[email protected] Signed-off-by: Ingo Molnar <[email protected]>
2016-03-21sched/fair: Add comments to explain select_idle_sibling()Matt Fleming1-1/+18
It's not entirely obvious how the main loop in select_idle_sibling() works on first glance. Sprinkle a few comments to explain the design and intention behind the loop based on some conversations with Mike and Peter. Signed-off-by: Matt Fleming <[email protected]> Signed-off-by: Peter Zijlstra (Intel) <[email protected]> Cc: Linus Torvalds <[email protected]> Cc: Mel Gorman <[email protected]> Cc: Mike Galbraith <[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]>
2016-03-21bitops: Do not default to __clear_bit() for __clear_bit_unlock()Peter Zijlstra1-7/+7
__clear_bit_unlock() is a special little snowflake. While it carries the non-atomic '__' prefix, it is specifically documented to pair with test_and_set_bit() and therefore should be 'somewhat' atomic. Therefore the generic implementation of __clear_bit_unlock() cannot use the fully non-atomic __clear_bit() as a default. If an arch is able to do better; is must provide an implementation of __clear_bit_unlock() itself. Specifically, this came up as a result of hackbench livelock'ing in slab_lock() on ARC with SMP + SLUB + !LLSC. The issue was incorrect pairing of atomic ops. slab_lock() -> bit_spin_lock() -> test_and_set_bit() slab_unlock() -> __bit_spin_unlock() -> __clear_bit() The non serializing __clear_bit() was getting "lost" 80543b8e: ld_s r2,[r13,0] <--- (A) Finds PG_locked is set 80543b90: or r3,r2,1 <--- (B) other core unlocks right here 80543b94: st_s r3,[r13,0] <--- (C) sets PG_locked (overwrites unlock) Fixes ARC STAR 9000817404 (and probably more). Reported-by: Vineet Gupta <[email protected]> Tested-by: Vineet Gupta <[email protected]> Signed-off-by: Peter Zijlstra (Intel) <[email protected]> Cc: Andrew Morton <[email protected]> Cc: Christoph Lameter <[email protected]> Cc: David Rientjes <[email protected]> Cc: Helge Deller <[email protected]> Cc: James E.J. Bottomley <[email protected]> Cc: Joonsoo Kim <[email protected]> Cc: Linus Torvalds <[email protected]> Cc: Noam Camus <[email protected]> Cc: Paul E. McKenney <[email protected]> Cc: Pekka Enberg <[email protected]> Cc: Peter Zijlstra <[email protected]> Cc: Thomas Gleixner <[email protected]> Cc: [email protected] Link: http://lkml.kernel.org/r/[email protected] Signed-off-by: Ingo Molnar <[email protected]>
2016-03-21sched/fair: Fix fairness issue on migrationPeter Zijlstra1-6/+14
Pavan reported that in the presence of very light tasks (or cgroups) the placement of migrated tasks can cause severe fairness issues. The problem is that enqueue_entity() places the task before it updates time, thereby it can place the task far in the past (remember that light tasks will shoot virtual time forward at a high speed, so in relation to the pre-existing light task, we can land far in the past). This is done because update_curr() needs the current task, and we might be placing the current task. The obvious solution is to differentiate between the current and any other task; placing the current before we update time, and placing any other task after, such that !curr tasks end up at the current moment in time, and not in the past. Reported-by: Pavan Kondeti <[email protected]> Tested-by: Pavan Kondeti <[email protected]> Signed-off-by: Peter Zijlstra (Intel) <[email protected]> Cc: Ben Segall <[email protected]> Cc: Linus Torvalds <[email protected]> Cc: Matt Fleming <[email protected]> Cc: Mike Galbraith <[email protected]> Cc: Morten Rasmussen <[email protected]> Cc: Paul Turner <[email protected]> Cc: Peter Zijlstra <[email protected]> Cc: Thomas Gleixner <[email protected]> Cc: [email protected] Link: http://lkml.kernel.org/r/[email protected] Signed-off-by: Ingo Molnar <[email protected]>
2016-03-21sched/cgroup: Fix/cleanup cgroup teardown/initPeter Zijlstra1-21/+14
The CPU controller hasn't kept up with the various changes in the whole cgroup initialization / destruction sequence, and commit: 2e91fa7f6d45 ("cgroup: keep zombies associated with their original cgroups") caused it to explode. The reason for this is that zombies do not inhibit css_offline() from being called, but do stall css_released(). Now we tear down the cfs_rq structures on css_offline() but zombies can run after that, leading to use-after-free issues. The solution is to move the tear-down to css_released(), which guarantees nobody (including no zombies) is still using our cgroup. Furthermore, a few simple cleanups are possible too. There doesn't appear to be any point to us using css_online() (anymore?) so fold that in css_alloc(). And since cgroup code guarantees an RCU grace period between css_released() and css_free() we can forgo using call_rcu() and free the stuff immediately. Suggested-by: Tejun Heo <[email protected]> Reported-by: Kazuki Yamaguchi <[email protected]> Reported-by: Niklas Cassel <[email protected]> Tested-by: Niklas Cassel <[email protected]> Signed-off-by: Peter Zijlstra (Intel) <[email protected]> Acked-by: Tejun Heo <[email protected]> Cc: Linus Torvalds <[email protected]> Cc: Peter Zijlstra <[email protected]> Cc: Thomas Gleixner <[email protected]> Fixes: 2e91fa7f6d45 ("cgroup: keep zombies associated with their original cgroups") Link: http://lkml.kernel.org/r/[email protected] Signed-off-by: Ingo Molnar <[email protected]>
2016-03-21Merge branch 'linus' into sched/urgent, to pick up dependenciesIngo Molnar986-9365/+26835
Signed-off-by: Ingo Molnar <[email protected]>
2016-03-21arm64: KVM: Turn kvm_ksym_ref into a NOP on VHEMarc Zyngier1-1/+7
When running with VHE, there is no need to translate kernel pointers to the EL2 memory space, since we're already there (and we have a much saner memory map to start with). Unfortunately, kvm_ksym_ref is getting in the way, and the first call into the "hypervisor" section is going to end up in fireworks, since we're now branching into nowhereland. Meh. A potential solution is to test if VHE is engaged or not, and only perform the translation in the negative case. With this in place, VHE is able to run again. Signed-off-by: Marc Zyngier <[email protected]> Signed-off-by: Christoffer Dall <[email protected]>
2016-03-21KVM: arm/arm64: disable preemption when calling smp_call_function_manyEric Auger1-0/+2
Preemption must be disabled when calling smp_call_function_many Reported-by: [email protected] Signed-off-by: Eric Auger <[email protected]> Signed-off-by: Christoffer Dall <[email protected]>
2016-03-21perf/x86/amd/power: Add AMD accumulated power reporting mechanismHuang Rui5-2/+369
Introduce an AMD accumlated power reporting mechanism for the Family 15h, Model 60h processor that can be used to calculate the average power consumed by a processor during a measurement interval. The feature support is indicated by CPUID Fn8000_0007_EDX[12]. This feature will be implemented both in hwmon and perf. The current design provides one event to report per package/processor power consumption by counting each compute unit power value. Here the gory details of how the computation is done: * Tsample: compute unit power accumulator sample period * Tref: the PTSC counter period (PTSC: performance timestamp counter) * N: the ratio of compute unit power accumulator sample period to the PTSC period * Jmax: max compute unit accumulated power which is indicated by MSR_C001007b[MaxCpuSwPwrAcc] * Jx/Jy: compute unit accumulated power which is indicated by MSR_C001007a[CpuSwPwrAcc] * Tx/Ty: the value of performance timestamp counter which is indicated by CU_PTSC MSR_C0010280[PTSC] * PwrCPUave: CPU average power i. Determine the ratio of Tsample to Tref by executing CPUID Fn8000_0007. N = value of CPUID Fn8000_0007_ECX[CpuPwrSampleTimeRatio[15:0]]. ii. Read the full range of the cumulative energy value from the new MSR MaxCpuSwPwrAcc. Jmax = value returned. iii. At time x, software reads CpuSwPwrAcc and samples the PTSC. Jx = value read from CpuSwPwrAcc and Tx = value read from PTSC. iv. At time y, software reads CpuSwPwrAcc and samples the PTSC. Jy = value read from CpuSwPwrAcc and Ty = value read from PTSC. v. Calculate the average power consumption for a compute unit over time period (y-x). Unit of result is uWatt: if (Jy < Jx) // Rollover has occurred Jdelta = (Jy + Jmax) - Jx else Jdelta = Jy - Jx PwrCPUave = N * Jdelta * 1000 / (Ty - Tx) Simple example: root@hr-zp:/home/ray/tip# ./tools/perf/perf stat -a -e 'power/power-pkg/' make -j4 CHK include/config/kernel.release CHK include/generated/uapi/linux/version.h CHK include/generated/utsrelease.h CHK include/generated/timeconst.h CHK include/generated/bounds.h CHK include/generated/asm-offsets.h CALL scripts/checksyscalls.sh CHK include/generated/compile.h SKIPPED include/generated/compile.h Building modules, stage 2. Kernel: arch/x86/boot/bzImage is ready (#40) MODPOST 4225 modules Performance counter stats for 'system wide': 183.44 mWatts power/power-pkg/ 341.837270111 seconds time elapsed root@hr-zp:/home/ray/tip# ./tools/perf/perf stat -a -e 'power/power-pkg/' sleep 10 Performance counter stats for 'system wide': 0.18 mWatts power/power-pkg/ 10.012551815 seconds time elapsed Suggested-by: Peter Zijlstra <[email protected]> Suggested-by: Ingo Molnar <[email protected]> Suggested-by: Borislav Petkov <[email protected]> Signed-off-by: Huang Rui <[email protected]> Signed-off-by: Peter Zijlstra (Intel) <[email protected]> Reviewed-by: Thomas Gleixner <[email protected]> Cc: Alexander Shishkin <[email protected]> Cc: Andy Lutomirski <[email protected]> Cc: Arnaldo Carvalho de Melo <[email protected]> Cc: Arnaldo Carvalho de Melo <[email protected]> Cc: Borislav Petkov <[email protected]> Cc: Brian Gerst <[email protected]> Cc: David Ahern <[email protected]> Cc: Denys Vlasenko <[email protected]> Cc: H. Peter Anvin <[email protected]> Cc: Jiri Olsa <[email protected]> Cc: Kan Liang <[email protected]> Cc: Linus Torvalds <[email protected]> Cc: Namhyung Kim <[email protected]> Cc: Robert Richter <[email protected]> Cc: Stephane Eranian <[email protected]> Cc: Vince Weaver <[email protected]> Cc: [email protected] Link: http://lkml.kernel.org/r/[email protected] [ Fixed the modular build. ] Signed-off-by: Ingo Molnar <[email protected]>
2016-03-21x86/cpufeature, perf/x86: Add AMD Accumulated Power Mechanism feature flagHuang Rui2-1/+5
AMD CPU family 15h model 0x60 introduces a mechanism for measuring accumulated power. It is used to report the processor power consumption and support for it is indicated by CPUID Fn8000_0007_EDX[12]. Signed-off-by: Huang Rui <[email protected]> Signed-off-by: Borislav Petkov <[email protected]> Cc: Aaron Lu <[email protected]> Cc: Alexander Shishkin <[email protected]> Cc: Andreas Herrmann <[email protected]> Cc: Andy Lutomirski <[email protected]> Cc: Andy Lutomirski <[email protected]> Cc: Aravind Gopalakrishnan <[email protected]> Cc: Arnaldo Carvalho de Melo <[email protected]> Cc: Borislav Petkov <[email protected]> Cc: Brian Gerst <[email protected]> Cc: David Ahern <[email protected]> Cc: Denys Vlasenko <[email protected]> Cc: Fengguang Wu <[email protected]> Cc: Frédéric Weisbecker <[email protected]> Cc: Guenter Roeck <[email protected]> Cc: H. Peter Anvin <[email protected]> Cc: Hector Marco-Gisbert <[email protected]> Cc: Jacob Shin <[email protected]> Cc: Jiri Olsa <[email protected]> Cc: John Stultz <[email protected]> Cc: Kristen Carlson Accardi <[email protected]> Cc: Linus Torvalds <[email protected]> Cc: Namhyung Kim <[email protected]> Cc: Peter Zijlstra <[email protected]> Cc: Robert Richter <[email protected]> Cc: Ross Zwisler <[email protected]> Cc: Stephane Eranian <[email protected]> Cc: Suravee Suthikulpanit <[email protected]> Cc: Thomas Gleixner <[email protected]> Cc: Vince Weaver <[email protected]> Cc: Wan Zongshun <[email protected]> Cc: [email protected] Link: http://lkml.kernel.org/r/[email protected] [ Resolved conflict and moved the synthetic CPUID slot to 19. ] Signed-off-by: Ingo Molnar <[email protected]>
2016-03-21perf/core: Document some hotplug bitsPeter Zijlstra1-0/+19
Document some of the hotplug notifier usage. Requested-by: Thomas Gleixner <[email protected]> Signed-off-by: Peter Zijlstra (Intel) <[email protected]> Cc: Alexander Shishkin <[email protected]> Cc: Andy Lutomirski <[email protected]> Cc: Arnaldo Carvalho de Melo <[email protected]> Cc: Borislav Petkov <[email protected]> Cc: Brian Gerst <[email protected]> Cc: David Ahern <[email protected]> Cc: Denys Vlasenko <[email protected]> Cc: H. Peter Anvin <[email protected]> Cc: Jiri Olsa <[email protected]> Cc: Linus Torvalds <[email protected]> Cc: Namhyung Kim <[email protected]> Cc: Peter Zijlstra <[email protected]> Cc: Stephane Eranian <[email protected]> Cc: Thomas Gleixner <[email protected]> Cc: Vince Weaver <[email protected]> Signed-off-by: Ingo Molnar <[email protected]>
2016-03-21perf/x86/amd: Add support for new IOMMU performance eventsSuravee Suthikulpanit1-0/+5
This patch adds new IOMMU performance event based on the information in table 74 of the AMD I/O Virtualization Technology (IOMMU) Specification (Document Id: 4882, Rev 2.62, Feb 2015) Signed-off-by: Suravee Suthikulpanit <[email protected]> Signed-off-by: Peter Zijlstra (Intel) <[email protected]> Reviewed-by: Joerg Roedel <[email protected]> Acked-by: Joerg Roedel <[email protected]> Cc: <[email protected]> Cc: Alexander Shishkin <[email protected]> Cc: Andy Lutomirski <[email protected]> Cc: Arnaldo Carvalho de Melo <[email protected]> Cc: Borislav Petkov <[email protected]> Cc: Brian Gerst <[email protected]> Cc: David Ahern <[email protected]> Cc: Denys Vlasenko <[email protected]> Cc: H. Peter Anvin <[email protected]> Cc: Jiri Olsa <[email protected]> Cc: Linus Torvalds <[email protected]> Cc: Namhyung Kim <[email protected]> Cc: Peter Zijlstra <[email protected]> Cc: Stephane Eranian <[email protected]> Cc: Thomas Gleixner <[email protected]> Cc: Vince Weaver <[email protected]> Link: http://support.amd.com/TechDocs/48882_IOMMU.pdf Signed-off-by: Ingo Molnar <[email protected]>
2016-03-21dma-buf/fence: fix fence_is_later v2Christian König1-1/+1
A fence is never later than itself. This caused a bunch of overhead for AMDGPU. v2: simplify check as suggested by Michel. Signed-off-by: Christian König <[email protected]> Reviewed-by: Michel Dänzer <[email protected]> Reviewed-by: Alex Deucher <[email protected]> Reviewed-by: Gustavo Padovan <[email protected]> Reviewed-by: Maarten Lankhorst <[email protected]> Signed-off-by: Alex Deucher <[email protected]> Signed-off-by: Sumit Semwal <[email protected]> Signed-off-by: Daniel Vetter <[email protected]>
2016-03-21dma-buf: Update docs for SYNC ioctlDaniel Vetter2-6/+7
Just a bit of wording polish plus mentioning that it can fail and must be restarted. Requested by Sumit. v2: Fix them typos (Hans). Cc: Chris Wilson <[email protected]> Cc: Tiago Vignatti <[email protected]> Cc: Stéphane Marchesin <[email protected]> Cc: David Herrmann <[email protected]> Cc: Sumit Semwal <[email protected]> Cc: Daniel Vetter <[email protected]> CC: [email protected] Cc: [email protected] Cc: [email protected] Cc: [email protected] Cc: [email protected] Cc: Hans Verkuil <[email protected]> Acked-by: Sumit Semwal <[email protected]> Acked-by: Hans Verkuil <[email protected]> Signed-off-by: Daniel Vetter <[email protected]>
2016-03-21perf/x86/amd: Move nodes_per_socket into bsp_init_amd()Huang Rui1-2/+12
nodes_per_socket is static and it needn't be initialized many times during every CPU core init. So move its initialization into bsp_init_amd(). Signed-off-by: Huang Rui <[email protected]> Signed-off-by: Borislav Petkov <[email protected]> Cc: Aaron Lu <[email protected]> Cc: Alexander Shishkin <[email protected]> Cc: Andreas Herrmann <[email protected]> Cc: Andy Lutomirski <[email protected]> Cc: Andy Lutomirski <[email protected]> Cc: Aravind Gopalakrishnan <[email protected]> Cc: Arnaldo Carvalho de Melo <[email protected]> Cc: Borislav Petkov <[email protected]> Cc: Brian Gerst <[email protected]> Cc: David Ahern <[email protected]> Cc: Denys Vlasenko <[email protected]> Cc: Fengguang Wu <[email protected]> Cc: Frédéric Weisbecker <[email protected]> Cc: Guenter Roeck <[email protected]> Cc: H. Peter Anvin <[email protected]> Cc: Hector Marco-Gisbert <[email protected]> Cc: Jacob Shin <[email protected]> Cc: Jiri Olsa <[email protected]> Cc: John Stultz <[email protected]> Cc: Linus Torvalds <[email protected]> Cc: Namhyung Kim <[email protected]> Cc: Peter Zijlstra <[email protected]> Cc: Robert Richter <[email protected]> Cc: Stephane Eranian <[email protected]> Cc: Suravee Suthikulpanit <[email protected]> Cc: Thomas Gleixner <[email protected]> Cc: Vince Weaver <[email protected]> Cc: [email protected] Link: http://lkml.kernel.org/r/[email protected] Signed-off-by: Ingo Molnar <[email protected]>
2016-03-21perf/x86/cqm: Factor out some common codePeter Zijlstra1-15/+13
Having the same code twice (and once quite ugly) is fragile. Signed-off-by: Peter Zijlstra (Intel) <[email protected]> Cc: Alexander Shishkin <[email protected]> Cc: Andy Lutomirski <[email protected]> Cc: Arnaldo Carvalho de Melo <[email protected]> Cc: Borislav Petkov <[email protected]> Cc: Brian Gerst <[email protected]> Cc: David Ahern <[email protected]> Cc: Denys Vlasenko <[email protected]> Cc: H. Peter Anvin <[email protected]> Cc: Jiri Olsa <[email protected]> Cc: Linus Torvalds <[email protected]> Cc: Namhyung Kim <[email protected]> Cc: Peter Zijlstra <[email protected]> Cc: Stephane Eranian <[email protected]> Cc: Thomas Gleixner <[email protected]> Cc: Vince Weaver <[email protected]> Signed-off-by: Ingo Molnar <[email protected]>
2016-03-21perf/x86/mbm: Add support for MBM counter overflow handlingVikas Shivappa1-5/+134
This patch adds a per package timer which periodically updates the memory bandwidth counters for the events that are currently active. Current patch has a periodic timer every 1s since the SDM guarantees that the counter will not overflow in 1s but this time can be definitely improved by calibrating on the system. The overflow is really a function of the max memory b/w that the socket can support, max counter value and scaling factor. Signed-off-by: Vikas Shivappa <[email protected]> Signed-off-by: Peter Zijlstra (Intel) <[email protected]> Reviewed-by: Tony Luck <[email protected]> Acked-by: Thomas Gleixner <[email protected]> Cc: Alexander Shishkin <[email protected]> Cc: Andy Lutomirski <[email protected]> Cc: Arnaldo Carvalho de Melo <[email protected]> Cc: Borislav Petkov <[email protected]> Cc: Brian Gerst <[email protected]> Cc: David Ahern <[email protected]> Cc: Denys Vlasenko <[email protected]> Cc: H. Peter Anvin <[email protected]> Cc: Jiri Olsa <[email protected]> Cc: Linus Torvalds <[email protected]> Cc: Matt Fleming <[email protected]> Cc: Namhyung Kim <[email protected]> Cc: Peter Zijlstra <[email protected]> Cc: Stephane Eranian <[email protected]> Cc: Vince Weaver <[email protected]> Cc: [email protected] Cc: [email protected] Cc: [email protected] Cc: [email protected] Link: http://lkml.kernel.org/r/013b756c5006b1c4ca411f3ecf43ed52f19fbf87.1457723885.git.tony.luck@intel.com Signed-off-by: Ingo Molnar <[email protected]>
2016-03-21perf/x86/mbm: Implement RMID recyclingVikas Shivappa1-4/+27
RMID could be allocated or deallocated as part of RMID recycling. When an RMID is allocated for MBM event, the MBM counter needs to be initialized because next time we read the counter we need the previous value to account for total bytes that went to the memory controller. Similarly, when RMID is deallocated we need to update the ->count variable. Signed-off-by: Vikas Shivappa <[email protected]> Signed-off-by: Peter Zijlstra (Intel) <[email protected]> Reviewed-by: Tony Luck <[email protected]> Acked-by: Thomas Gleixner <[email protected]> Cc: Alexander Shishkin <[email protected]> Cc: Andy Lutomirski <[email protected]> Cc: Arnaldo Carvalho de Melo <[email protected]> Cc: Borislav Petkov <[email protected]> Cc: Brian Gerst <[email protected]> Cc: David Ahern <[email protected]> Cc: Denys Vlasenko <[email protected]> Cc: H. Peter Anvin <[email protected]> Cc: Jiri Olsa <[email protected]> Cc: Linus Torvalds <[email protected]> Cc: Matt Fleming <[email protected]> Cc: Namhyung Kim <[email protected]> Cc: Peter Zijlstra <[email protected]> Cc: Stephane Eranian <[email protected]> Cc: Vince Weaver <[email protected]> Cc: [email protected] Cc: [email protected] Cc: [email protected] Cc: [email protected] Link: http://lkml.kernel.org/r/[email protected] Signed-off-by: Ingo Molnar <[email protected]>
2016-03-21perf/x86/mbm: Add memory bandwidth monitoring event managementTony Luck1-6/+116
Includes all the core infrastructure to measure the total_bytes and bandwidth. We have per socket counters for both total system wide L3 external bytes and local socket memory-controller bytes. The OS does MSR writes to MSR_IA32_QM_EVTSEL and MSR_IA32_QM_CTR to read the counters and uses the IA32_PQR_ASSOC_MSR to associate the RMID with the task. The tasks have a common RMID for CQM (cache quality of service monitoring) and MBM. Hence most of the scheduling code is reused from CQM. Signed-off-by: Tony Luck <[email protected]> [ Restructured rmid_read to not have an obvious hole, removed MBM_CNTR_MAX as its unused. ] Signed-off-by: Peter Zijlstra (Intel) <[email protected]> Reviewed-by: Vikas Shivappa <[email protected]> Acked-by: Thomas Gleixner <[email protected]> Cc: Alexander Shishkin <[email protected]> Cc: Andy Lutomirski <[email protected]> Cc: Arnaldo Carvalho de Melo <[email protected]> Cc: Borislav Petkov <[email protected]> Cc: Brian Gerst <[email protected]> Cc: David Ahern <[email protected]> Cc: Denys Vlasenko <[email protected]> Cc: H. Peter Anvin <[email protected]> Cc: Jiri Olsa <[email protected]> Cc: Linus Torvalds <[email protected]> Cc: Matt Fleming <[email protected]> Cc: Namhyung Kim <[email protected]> Cc: Peter Zijlstra <[email protected]> Cc: Stephane Eranian <[email protected]> Cc: Vince Weaver <[email protected]> Cc: [email protected] Cc: [email protected] Cc: [email protected] Cc: [email protected] Link: http://lkml.kernel.org/r/abd7aac9a18d93b95b985b931cf258df0164746d.1457723885.git.tony.luck@intel.com Signed-off-by: Ingo Molnar <[email protected]>
2016-03-21perf/x86/mbm: Add Intel Memory B/W Monitoring enumeration and initVikas Shivappa3-4/+128
The MBM init patch enumerates the Intel MBM (Memory b/w monitoring) and initializes the perf events and datastructures for monitoring the memory b/w. Its based on original patch series by Tony Luck and Kanaka Juvva. Memory bandwidth monitoring (MBM) provides OS/VMM a way to monitor bandwidth from one level of cache to another. The current patches support L3 external bandwidth monitoring. It supports both 'local bandwidth' and 'total bandwidth' monitoring for the socket. Local bandwidth measures the amount of data sent through the memory controller on the socket and total b/w measures the total system bandwidth. Extending the cache quality of service monitoring (CQM) we add two more events to the perf infrastructure: intel_cqm_llc/local_bytes - bytes sent through local socket memory controller intel_cqm_llc/total_bytes - total L3 external bytes sent The tasks are associated with a Resouce Monitoring ID (RMID) just like in CQM and OS uses a MSR write to indicate the RMID of the task during scheduling. Signed-off-by: Vikas Shivappa <[email protected]> Signed-off-by: Peter Zijlstra (Intel) <[email protected]> Reviewed-by: Tony Luck <[email protected]> Acked-by: Thomas Gleixner <[email protected]> Cc: Alexander Shishkin <[email protected]> Cc: Andy Lutomirski <[email protected]> Cc: Arnaldo Carvalho de Melo <[email protected]> Cc: Borislav Petkov <[email protected]> Cc: Brian Gerst <[email protected]> Cc: David Ahern <[email protected]> Cc: Denys Vlasenko <[email protected]> Cc: H. Peter Anvin <[email protected]> Cc: Jiri Olsa <[email protected]> Cc: Linus Torvalds <[email protected]> Cc: Matt Fleming <[email protected]> Cc: Namhyung Kim <[email protected]> Cc: Peter Zijlstra <[email protected]> Cc: Stephane Eranian <[email protected]> Cc: Vince Weaver <[email protected]> Cc: [email protected] Cc: [email protected] Cc: [email protected] Cc: [email protected] Link: http://lkml.kernel.org/r/[email protected] Signed-off-by: Ingo Molnar <[email protected]>
2016-03-21perf/x86/cqm: Fix CQM memory leak and notifier leakVikas Shivappa1-11/+32
Fixes the hotcpu notifier leak and other global variable memory leaks during CQM (cache quality of service monitoring) initialization. Signed-off-by: Vikas Shivappa <[email protected]> Signed-off-by: Peter Zijlstra (Intel) <[email protected]> Reviewed-by: Tony Luck <[email protected]> Acked-by: Thomas Gleixner <[email protected]> Cc: Alexander Shishkin <[email protected]> Cc: Andy Lutomirski <[email protected]> Cc: Arnaldo Carvalho de Melo <[email protected]> Cc: Borislav Petkov <[email protected]> Cc: Brian Gerst <[email protected]> Cc: David Ahern <[email protected]> Cc: Denys Vlasenko <[email protected]> Cc: H. Peter Anvin <[email protected]> Cc: Jiri Olsa <[email protected]> Cc: Linus Torvalds <[email protected]> Cc: Matt Fleming <[email protected]> Cc: Namhyung Kim <[email protected]> Cc: Peter Zijlstra <[email protected]> Cc: Stephane Eranian <[email protected]> Cc: Vince Weaver <[email protected]> Cc: [email protected] Cc: [email protected] Cc: [email protected] Cc: [email protected] Link: http://lkml.kernel.org/r/[email protected] Signed-off-by: Ingo Molnar <[email protected]>
2016-03-21perf/x86/cqm: Fix CQM handling of grouping events into a cache_groupVikas Shivappa2-3/+11
Currently CQM (cache quality of service monitoring) is grouping all events belonging to same PID to use one RMID. However its not counting all of these different events. Hence we end up with a count of zero for all events other than the group leader. The patch tries to address the issue by keeping a flag in the perf_event.hw which has other CQM related fields. The field is updated at event creation and during grouping. Signed-off-by: Vikas Shivappa <[email protected]> [peterz: Changed hw_perf_event::is_group_event to an int] Signed-off-by: Peter Zijlstra (Intel) <[email protected]> Reviewed-by: Tony Luck <[email protected]> Acked-by: Thomas Gleixner <[email protected]> Cc: Alexander Shishkin <[email protected]> Cc: Andy Lutomirski <[email protected]> Cc: Arnaldo Carvalho de Melo <[email protected]> Cc: Borislav Petkov <[email protected]> Cc: Brian Gerst <[email protected]> Cc: David Ahern <[email protected]> Cc: Denys Vlasenko <[email protected]> Cc: H. Peter Anvin <[email protected]> Cc: Jiri Olsa <[email protected]> Cc: Linus Torvalds <[email protected]> Cc: Matt Fleming <[email protected]> Cc: Namhyung Kim <[email protected]> Cc: Peter Zijlstra <[email protected]> Cc: Stephane Eranian <[email protected]> Cc: Vince Weaver <[email protected]> Cc: [email protected] Cc: [email protected] Cc: [email protected] Cc: [email protected] Link: http://lkml.kernel.org/r/[email protected] Signed-off-by: Ingo Molnar <[email protected]>
2016-03-21perf/core: Fix Undefined behaviour in rb_alloc()Peter Zijlstra1-2/+4
Sasha reported: [ 3494.030114] UBSAN: Undefined behaviour in kernel/events/ring_buffer.c:685:22 [ 3494.030647] shift exponent -1 is negative Andrey spotted that this is because: It happens if nr_pages = 0: rb->page_order = ilog2(nr_pages); Fix it by making both assignments conditional on nr_pages; since otherwise they should both be 0 anyway, and will be because of the kzalloc() used to allocate the structure. Reported-by: Sasha Levin <[email protected]> Reported-by: Andrey Ryabinin <[email protected]> Signed-off-by: Peter Zijlstra (Intel) <[email protected]> Cc: Alexander Shishkin <[email protected]> Cc: Andy Lutomirski <[email protected]> Cc: Arnaldo Carvalho de Melo <[email protected]> Cc: Arnaldo Carvalho de Melo <[email protected]> Cc: Borislav Petkov <[email protected]> Cc: Brian Gerst <[email protected]> Cc: David Ahern <[email protected]> Cc: Denys Vlasenko <[email protected]> Cc: H. Peter Anvin <[email protected]> Cc: Jiri Olsa <[email protected]> Cc: Linus Torvalds <[email protected]> Cc: Namhyung Kim <[email protected]> Cc: Peter Zijlstra <[email protected]> Cc: Stephane Eranian <[email protected]> Cc: Thomas Gleixner <[email protected]> Cc: Vince Weaver <[email protected]> Link: http://lkml.kernel.org/r/20160129141751.GA407@worktop Signed-off-by: Ingo Molnar <[email protected]>