aboutsummaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2016-03-21vxlan: fix sparse warningsJiri Benc1-8/+8
Sparse reports false positives for the header manipulation inlines. Annotate them correctly. Tested by sparse on a little endian and big endian machine. Fixes: 54bfd872bf16d ("vxlan: keep flags and vni in network byte order") Reported-by: kbuild test robot <[email protected]> Signed-off-by: Jiri Benc <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2016-03-21net: add description for len argument of dev_get_phys_port_nameLuis de Bethencourt1-0/+1
When the function dev_get_phys_port_name was added it missed a description for it's len argument. Adding it. Fixes: db24a9044ee1 ("net: add support for phys_port_name") Signed-off-by: Luis de Bethencourt <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2016-03-21Merge branch 'for-4.6-ns' of ↵Linus Torvalds13-48/+689
git://git.kernel.org/pub/scm/linux/kernel/git/tj/cgroup Pull cgroup namespace support from Tejun Heo: "These are changes to implement namespace support for cgroup which has been pending for quite some time now. It is very straight-forward and only affects what part of cgroup hierarchies are visible. After unsharing, mounting a cgroup fs will be scoped to the cgroups the task belonged to at the time of unsharing and the cgroup paths exposed to userland would be adjusted accordingly" * 'for-4.6-ns' of git://git.kernel.org/pub/scm/linux/kernel/git/tj/cgroup: cgroup: fix and restructure error handling in copy_cgroup_ns() cgroup: fix alloc_cgroup_ns() error handling in copy_cgroup_ns() Add FS_USERNS_FLAG to cgroup fs cgroup: Add documentation for cgroup namespaces cgroup: mount cgroupns-root when inside non-init cgroupns kernfs: define kernfs_node_dentry cgroup: cgroup namespace setns support cgroup: introduce cgroup namespaces sched: new clone flag CLONE_NEWCGROUP for cgroup namespace kernfs: Add API to generate relative kernfs path
2016-03-21nfs/blocklayout: make sure making a aligned read requestKinglong Mee1-6/+7
Only treat write goes up to the inode size as aligned request, because it always write PAGE_CACHE_SIZE, but read a dynamic size. Signed-off-by: Kinglong Mee <[email protected]> Signed-off-by: Trond Myklebust <[email protected]>
2016-03-21ovl: cleanup unused var in rename2Miklos Szeredi1-2/+0
Signed-off-by: Miklos Szeredi <[email protected]>
2016-03-21ovl: rename is_merge to is_lowestMiklos Szeredi1-8/+8
The 'is_merge' is an historical naming from when only a single lower layer could exist. With the introduction of multiple lower layers the meaning of this flag was changed to mean only the "lowest layer" (while all lower layers were being merged). So now 'is_merge' is inaccurate and hence renaming to 'is_lowest' Signed-off-by: Miklos Szeredi <[email protected]>
2016-03-21ovl: fixed coding style warningSohom Bhattacharjee1-0/+1
This patch fixes a newline warning found by the checkpatch.pl tool Signed-off-by: Sohom-Bhattacharjee <[email protected]> Signed-off-by: Miklos Szeredi <[email protected]>
2016-03-21ovl: Ensure upper filesystem supports d_typeVivek Goyal3-0/+53
In some instances xfs has been created with ftype=0 and there if a file on lower fs is removed, overlay leaves a whiteout in upper fs but that whiteout does not get filtered out and is visible to overlayfs users. And reason it does not get filtered out because upper filesystem does not report file type of whiteout as DT_CHR during iterate_dir(). So it seems to be a requirement that upper filesystem support d_type for overlayfs to work properly. Do this check during mount and fail if d_type is not supported. Suggested-by: Dave Chinner <[email protected]> Signed-off-by: Vivek Goyal <[email protected]> Signed-off-by: Miklos Szeredi <[email protected]>
2016-03-21ovl: Warn on copy up if a process has a R/O fd open to the lower fileDavid Howells1-0/+34
Print a warning when overlayfs copies up a file if the process that triggered the copy up has a R/O fd open to the lower file being copied up. This can help catch applications that do things like the following: fd1 = open("foo", O_RDONLY); fd2 = open("foo", O_RDWR); where they expect fd1 and fd2 to refer to the same file - which will no longer be the case post-copy up. With this patch, the following commands: bash 5</mnt/a/foo128 6<>/mnt/a/foo128 assuming /mnt/a/foo128 to be an un-copied up file on an overlay will produce the following warning in the kernel log: overlayfs: Copying up foo129, but open R/O on fd 5 which will cease to be coherent [pid=3818 bash] This is enabled by setting: /sys/module/overlay/parameters/check_copy_up to 1. The warnings are ratelimited and are also limited to one warning per file - assuming the copy up completes in each case. Signed-off-by: David Howells <[email protected]> Signed-off-by: Miklos Szeredi <[email protected]>
2016-03-21ovl: honor flag MS_SILENT at mountKonstantin Khlebnikov1-1/+2
This patch hides error about missing lowerdir if MS_SILENT is set. We use mount(NULL, "/", "overlay", MS_SILENT, NULL) for testing support of overlayfs: syscall returns -ENODEV if it's not supported. Otherwise kernel automatically loads module and returns -EINVAL because lowerdir is missing. Signed-off-by: Konstantin Khlebnikov <[email protected]> Signed-off-by: Miklos Szeredi <[email protected]>
2016-03-21ovl: verify upper dentry before unlink and renameMiklos Szeredi1-21/+38
Unlink and rename in overlayfs checked the upper dentry for staleness by verifying upper->d_parent against upperdir. However the dentry can go stale also by being unhashed, for example. Expand the verification to actually look up the name again (under parent lock) and check if it matches the upper dentry. This matches what the VFS does before passing the dentry to filesytem's unlink/rename methods, which excludes any inconsistency caused by overlayfs. Signed-off-by: Miklos Szeredi <[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-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-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-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]>
Powered by cgit, Gruvboxed by Blaster4385.