- 18 Apr, 2016 1 commit
-
-
Tim Gardner authored
Ignore: yes Signed-off-by:Tim Gardner <tim.gardner@canonical.com>
-
- 15 Apr, 2016 8 commits
-
-
Tim Gardner authored
Signed-off-by: -
Seth Forshee authored
BugLink: http://bugs.launchpad.net/bugs/1570906 Two kernfs-based filesystems are currently mountable from non-init user namespaces, sysfs and cgroupfs. Both of these have use cases which end up attempting to mount the same superblock from different user namespaces, but sget() no longer allows this so these mount attempts will fail. Update kernfs_test_super() to return false whenever s_user_ns is not the current user namespace, resulting in a new super block being allocated for these mounts. kernfs, sysfs, and cgroupfs are all equipped to handle this situation. Tested-by:
Tycho Andersen <tycho.andersen@canonical.com> Acked-by:
Leann Ogasawara <leann.ogasawara@canonical.com> Signed-off-by:
-
Peter Zijlstra authored
BugLink: http://bugs.launchpad.net/bugs/1570441 It turns out AMD gets x86_max_cores wrong when there are compute units. The issue is that Linux assumes: nr_logical_cpus = nr_cores * nr_siblings But AMD reports its CU unit as 2 cores, but then sets num_smp_siblings to 2 as well. Boris: fixup ras/mce_amd_inj.c too, to compute the Node Base Core properly, according to the new nomenclature. Fixes: 1f12e32f ("x86/topology: Create logical package id") Reported-by:
Xiong Zhou <jencce.kernel@gmail.com> Signed-off-by:
Peter Zijlstra (Intel) <peterz@infradead.org> Signed-off-by:
Borislav Petkov <bp@suse.de> Cc: Andreas Herrmann <aherrmann@suse.com> Cc: Andy Lutomirski <luto@kernel.org> Link: http://lkml.kernel.org/r/20160317095220.GO6344@twins.programming.kicks-ass.netSigned-off-by:
Thomas Gleixner <tglx@linutronix.de> (cherry picked from commit ee6825c8) Signed-off-by:
Stefan Bader <stefan.bader@canonical.com> Signed-off-by:
Colin King <colin.king@canonical.com> Signed-off-by:
-
Boris Ostrovsky authored
BugLink: http://bugs.launchpad.net/bugs/1570441 Currently Xen uses default_cpu_present_to_apicid() which will always report BAD_APICID for PV guests since x86_bios_cpu_apic_id is initialised to that value and is never updated. With commit 1f12e32f ("x86/topology: Create logical package id"), this op is now called by smp_init_package_map() when deciding whether to call topology_update_package_map() which sets cpu_data(cpu).logical_proc_id. The latter (as topology_logical_package_id(cpu)) may be used, for example, by cpu_to_rapl_pmu() as an array index. Since uninitialized logical_package_id is set to -1, the index will become 64K which is obviously problematic. While RAPL code (and any other users of logical_package_id) should be careful in their assumptions about id's validity, Xen's cpu_present_to_apicid op should still provide value consistent with its own xen_apic_read(APIC_ID). Signed-off-by:
Boris Ostrovsky <boris.ostrovsky@oracle.com> Signed-off-by:
Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> (cherry picked from commit ed6069be) Signed-off-by:
-
Thomas Gleixner authored
BugLink: http://bugs.launchpad.net/bugs/1570441 nr_cpu_ids can be limited on the command line via nr_cpus=. That can break the logical package management because it results in a smaller number of packages, but the cpus to online are occupying the full package space as the hyper threads are enumerated after the physical cores typically. total_cpus is the real possible cpu space not limited by nr_cpus command line and gives us the proper number of packages. Reported-by:
Mike Galbraith <umgwanakikbuti@gmail.com> Fixes: 1f12e32f ("x86/topology: Create logical package id") Signed-off-by:
-
Peter Zijlstra authored
BugLink: http://bugs.launchpad.net/bugs/1570441 As per the comment in the code; due to BIOS it is sometimes impossible to know if there actually are smp siblings until the machine is fully enumerated. So we rather overestimate the number of possible packages. Fixes: 1f12e32f ("x86/topology: Create logical package id") Signed-off-by:
-
Peter Zijlstra authored
BugLink: http://bugs.launchpad.net/bugs/1570441 That first branch testing pkg against __max_logical_packages is wrong, because if the first pkg id is larger, then the find_first_zero will find us logical package id 0. However, if the second pkg id is indeed 0, we'll again claim it without testing if it was already taken. Also, it fails to print the mapping. Fixes: 1f12e32f ("x86/topology: Create logical package id") Reported-by:
-
John Stultz authored
BugLink: http://bugs.launchpad.net/bugs/1566465 Recently, in commit 37cf4dc3 I forgot to check if the timeval being passed was actually a timespec (as is signaled with ADJ_NANO). This resulted in that patch breaking ADJ_SETOFFSET users who set ADJ_NANO, by rejecting valid timespecs that were compared with valid timeval ranges. This patch addresses this by checking for the ADJ_NANO flag and using the timepsec check instead in that case. Reported-by:
Harald Hoyer <harald@redhat.com> Reported-by:
Kay Sievers <kay@vrfy.org> Fixes: 37cf4dc3 "time: Verify time values in adjtimex ADJ_SETOFFSET to avoid overflow" Signed-off-by:
John Stultz <john.stultz@linaro.org> Cc: Sasha Levin <sasha.levin@oracle.com> Cc: Richard Cochran <richardcochran@gmail.com> Cc: Prarit Bhargava <prarit@redhat.com> Cc: David Herrmann <dh.herrmann@gmail.com> Link: http://lkml.kernel.org/r/1453417415-19110-2-git-send-email-john.stultz@linaro.orgSigned-off-by:
Kamal Mostafa <kamal@canonical.com> Signed-off-by:
-
- 14 Apr, 2016 2 commits
-
-
Tim Gardner authored
Ignore: yes Signed-off-by: -
Tim Gardner authored
Signed-off-by:
-
- 13 Apr, 2016 7 commits
-
-
Willy Tarreau authored
On no-so-small systems, it is possible for a single process to cause an OOM condition by filling large pipes with data that are never read. A typical process filling 4000 pipes with 1 MB of data will use 4 GB of memory. On small systems it may be tricky to set the pipe max size to prevent this from happening. This patch makes it possible to enforce a per-user soft limit above which new pipes will be limited to a single page, effectively limiting them to 4 kB each, as well as a hard limit above which no new pipes may be created for this user. This has the effect of protecting the system against memory abuse without hurting other users, and still allowing pipes to work correctly though with less data at once. The limit are controlled by two new sysctls : pipe-user-pages-soft, and pipe-user-pages-hard. Both may be disabled by setting them to zero. The default soft limit allows the default number of FDs per process (1024) to create pipes of the default size (64kB), thus reaching a limit of 64MB before starting to create only smaller pipes. With 256 processes limited to 1024 FDs each, this results in 1024*64kB + (256*1024 - 1024) * 4kB = 1084 MB of memory allocated for a user. The hard limit is disabled by default to avoid breaking existing applications that make intensive use of pipes (eg: for splicing). Reported-by: socketpair@gmail.com Reported-by:
Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp> Mitigates: CVE-2013-4312 (Linux 2.0+) Suggested-by:
Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by:
Willy Tarreau <w@1wt.eu> Signed-off-by:
Al Viro <viro@zeniv.linux.org.uk> (cherry picked from commit 759c0114) CVE-2016-2847 BugLink: https://bugs.launchpad.net/bugs/1554260Signed-off-by:
Luis Henriques <luis.henriques@canonical.com> Signed-off-by:
-
Quinn Tran authored
BugLink: http://bugs.launchpad.net/bugs/1554003 Commit cdb898c5 introduced a regression by accessing a Null pointer. This occured when checking older 4G adapters, that do not have MSIX support. Add a check for rsp->msix. Fixes: commit cdb898c5: ("qla2xxx: Add irq affinity notification") Signed-off-by:
Joseph Salisbury <joseph.salisbury@canonical.com> Signed-off-by:
-
Marc Zyngier authored
BugLink: http://bugs.launchpad.net/bugs/1549494 On a host that runs NTP, corrections can have a direct impact on the background timer that we program on the behalf of a vcpu. In particular, NTP performing a forward correction will result in a timer expiring sooner than expected from a guest point of view. Not a big deal, we kick the vcpu anyway. But on wake-up, the vcpu thread is going to perform a check to find out whether or not it should block. And at that point, the timer check is going to say "timer has not expired yet, go back to sleep". This results in the timer event being lost forever. There are multiple ways to handle this. One would be record that the timer has expired and let kvm_cpu_has_pending_timer return true in that case, but that would be fairly invasive. Another is to check for the "short sleep" condition in the hrtimer callback, and restart the timer for the remaining time when the condition is detected. This patch implements the latter, with a bit of refactoring in order to avoid too much code duplication. Cc: <stable@vger.kernel.org> Reported-by:
Alexander Graf <agraf@suse.de> Reviewed-by:
Marc Zyngier <marc.zyngier@arm.com> Signed-off-by:
Christoffer Dall <christoffer.dall@linaro.org> (cherry picked from linux-next commit 1c5631c7) Signed-off-by:
dann frazier <dann.frazier@canonical.com> Acked-by:
-
Tim Gardner authored
BugLink: http://bugs.launchpad.net/bugs/1566221Signed-off-by:
-
Tim Gardner authored
Should have run updateconfigs after committing 'UBUNTU: SAUCE: i915_bpo: Disable preliminary hw support' Signed-off-by: -
Pavel Rojtberg authored
Track the status of the irq_out URB to prevent submission iof new requests while current one is active. Failure to do so results in the "URB submitted while active" warning/stack trace. Store pending brightness and FF effect in the driver structure and replace it with the latest requests until the device is ready to process next request. Alternate serving LED vs FF requests to make sure one does not starve another. See [1] for discussion. Inspired by patch of Sarah Bessmer [2]. [1]: http://www.spinics.net/lists/linux-input/msg40708.html [2]: http://www.spinics.net/lists/linux-input/msg31450.htmlSigned-off-by:
Pavel Rojtberg <rojtberg@gmail.com> Signed-off-by:
Dmitry Torokhov <dmitry.torokhov@gmail.com> (cherry picked from commit 7fc595f4) Signed-off-by:
-
Christian Borntraeger authored
BugLink: http://bugs.launchpad.net/bugs/1555344 we have to check bit 40 of the facility list before issuing LPP and not bit 48. Otherwise a guest running on a system with "The decimal-floating-point zoned-conversion facility" and without the "The set-program-parameters facility" might crash on an lpp instruction. Signed-off-by:
Christian Borntraeger <borntraeger@de.ibm.com> Cc: stable@vger.kernel.org # v4.4+ Fixes: e22cf8ca ("s390/cpumf: rework program parameter setting to detect guest samples") Signed-off-by:
Martin Schwidefsky <schwidefsky@de.ibm.com> (cherry picked from commit 7a76aa95) Signed-off-by:
Seth Forshee <seth.forshee@canonical.com> Signed-off-by:
-
- 11 Apr, 2016 4 commits
-
-
Heiko Carstens authored
BugLink: http://bugs.launchpad.net/bugs/1555344 head.s contains an stfle instruction which stores it result at the storage location that is assigned to the stfl instruction. This is currently no problem, since we only care about one double word. However if the number of double words in the ALS bitfield grows the current code is not very stable. E.g. before issuing the stfle command the memory to which it stores must be cleared, since the instruction may or may not clear memory contents where no bits are set. In order to simplify the code a bit always use the storage location that we reserved for the stfle result. Signed-off-by:
Heiko Carstens <heiko.carstens@de.ibm.com> Signed-off-by:
-
Heiko Carstens authored
BugLink: http://bugs.launchpad.net/bugs/1555344 Now that 31 bit support is gone, the assembler always knows about the stfl instruction. Therefore lets use a readable mnemonic. Also remove the not needed extable entry for the inline assembly and fix the output constraint. Signed-off-by:
-
Tim Gardner authored
BugLink: http://bugs.launchpad.net/bugs/1536245Signed-off-by:
-
Tim Gardner authored
BugLink: http://bugs.launchpad.net/bugs/1567581 This reverts commit ebfd4a07. Acked-by: seth.forshee@canonical.com Acked-by: stefan.bader@canonical.com Signed-off-by:
-
- 07 Apr, 2016 10 commits
-
-
Shilpasri G Bhat authored
BugLink: http://bugs.launchpad.net/bugs/1555765 Create sysfs attributes to export throttle information in /sys/devices/system/cpu/cpuX/cpufreq/throttle_stats directory. The newly added sysfs files are as follows: 1)/sys/devices/system/cpu/cpuX/cpufreq/throttle_stats/turbo_stat 2)/sys/devices/system/cpu/cpuX/cpufreq/throttle_stats/sub-turbo_stat 3)/sys/devices/system/cpu/cpuX/cpufreq/throttle_stats/unthrottle 4)/sys/devices/system/cpu/cpuX/cpufreq/throttle_stats/powercap 5)/sys/devices/system/cpu/cpuX/cpufreq/throttle_stats/overtemp 6)/sys/devices/system/cpu/cpuX/cpufreq/throttle_stats/supply_fault 7)/sys/devices/system/cpu/cpuX/cpufreq/throttle_stats/overcurrent 8)/sys/devices/system/cpu/cpuX/cpufreq/throttle_stats/occ_reset Detailed explanation of each attribute is added to Documentation/ABI/testing/sysfs-devices-system-cpu Signed-off-by:
Shilpasri G Bhat <shilpa.bhat@linux.vnet.ibm.com> Acked-by:
Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by:
Rafael J. Wysocki <rafael.j.wysocki@intel.com> (cherry picked from commit 1b028984) Signed-off-by:
-
Viresh Kumar authored
BugLink: http://bugs.launchpad.net/bugs/1555765 Revert commit 3510fac4 (cpufreq: postfix policy directory with the first CPU in related_cpus). Earlier, the policy->kobj was added to the kobject core, before ->init() callback was called for the cpufreq drivers. Which allowed those drivers to add or remove, driver dependent, sysfs files/directories to the same kobj from their ->init() and ->exit() callbacks. That isn't possible anymore after commit 3510fac4. Now, there is no other clean alternative that people can adopt. Its better to revert the earlier commit to allow cpufreq drivers to create/remove sysfs files from ->init() and ->exit() callbacks. Signed-off-by:
-
Michael Neuling authored
BugLink: http://bugs.launchpad.net/bugs/1555765 Commit 96c4726f "cpufreq: powernv: Remove cpu_to_chip_id() from hot-path" introduced a 'core_to_chip_map' array to cache the chip-ids of all cores. Replace this with a per-CPU variable that stores the pointer to the chip-array. This removes the linear lookup and provides a neater and simpler solution. Signed-off-by:
Michael Neuling <mikey@neuling.org> Signed-off-by:
-
Tim Gardner authored
BugLink: http://bugs.launchpad.net/bugs/1566468Signed-off-by:
-
Sunil Goutham authored
BugLink: http://bugs.launchpad.net/bugs/1567093 Adjusted nicvf structure such that all elements used in hot path like napi, xmit e.t.c fall into same cache line. This reduced no of cache misses and resulted in ~2% increase in no of packets handled on a core. Also modified elements with :1 notation to boolean, to be consistent with other element definitions. Signed-off-by:
Sunil Goutham <sgoutham@cavium.com> Signed-off-by:
David S. Miller <davem@davemloft.net> (cherry picked from commit 1d368790) Signed-off-by:
-
Sunil Goutham authored
BugLink: http://bugs.launchpad.net/bugs/1567093 Instead of calling get_page() for every receive buffer carved out of page, set page's usage count at the end, to reduce no of atomic calls. Signed-off-by:
-
Sunil Goutham authored
BugLink: http://bugs.launchpad.net/bugs/1567091 Counting rx packets for every CQE_RX in CQ irq handler is incorrect. Synchronization is missing when multiple queues are receiving packets simultaneously. Like transmit packet stats use HW stats here. Also removed unused 'cqe_type' parameter in nicvf_rcv_pkt_handler(). Signed-off-by:
-
Sunil Goutham authored
BugLink: http://bugs.launchpad.net/bugs/1567091 For secondary Qsets 'hw_tso' is not getting set as probe() returns much earlier. Fixed it by moving silicon revision check. Signed-off-by:
-
Sunil Goutham authored
BugLink: http://bugs.launchpad.net/bugs/1567091 When a interface is assigned morethan 8 queues and the logical interface is toggled i.e down & up, additional queues or qsets are not initialized as secondary qset count is being set to zero while tearing down. Signed-off-by:
-
Tim Gardner authored
Ignore: yes Signed-off-by:
-
- 06 Apr, 2016 8 commits
-
-
Tim Gardner authored
Signed-off-by: -
Mika Kuoppala authored
BugLink: http://bugs.launchpad.net/bugs/1564759 Experiments with heaven 4.0 benchmark and skylake gt3e (rev 0xa) suggest that WaForceContextSaveRestoreNonCoherent is needed for all revs. Extending this to all revs cures a gpu hang with rev 0xa when running heaven4.0 gpu benchmark. We have been here before, with problems enabling gt4e and extending up to revision F0 instead of false claims of bspec of E0 only. See commit <e238659d> ("drm/i915/skl: Default to noncoherent access up to F0"). In retrospect we should have covered this with this big blanket back then already, as E0 vs F0 discrepancy was suspicious enough. Previously the WaForceEnableNonCoherent has been tied to context non-coherence, atleast in relevant hsds. So keep this tie and extended this alongside. Cc: Abdiel Janulgue <abdiel.janulgue@linux.intel.com> Cc: Ben Widawsky <benjamin.widawsky@intel.com> Cc: Timo Aaltonen <tjaalton@ubuntu.com> Cc: stable@vger.kernel.org Reported-by:
Mike Lothian <mike@fireburn.co.uk> References: https://bugs.freedesktop.org/show_bug.cgi?id=93491Signed-off-by:
Mika Kuoppala <mika.kuoppala@intel.com> (pulled from stable@ list) Signed-off-by:
Timo Aaltonen <timo.aaltonen@canonical.com> Signed-off-by:
-
Mika Kuoppala authored
BugLink: http://bugs.launchpad.net/bugs/1564759 For all gt3 and gt4 skylake variants, extend the usage of WaRsDisableCoarsePowerGating for all revisions. Without this gt3 and gt4 skylakes up to atleast rev 0xa can gpu hang or system hang. Cc: Abdiel Janulgue <abdiel.janulgue@linux.intel.com> Cc: Ben Widawsky <benjamin.widawsky@intel.com> Cc: Timo Aaltonen <tjaalton@ubuntu.com> Cc: <stable@vger.kernel.org> Reported-by:
Mikael Djurfeldt <mikael@djurfeldt.com> References: https://bugs.freedesktop.org/show_bug.cgi?id=94161Signed-off-by:
-
Timo Aaltonen authored
It was mistakenly enabled, the option should be left disabled and instead enable KBL/BXT via the driver once they have been properly tested. Signed-off-by:
-
Tim Gardner authored
BugLink: http://bugs.launchpad.net/bugs/1566283Signed-off-by:
-
Vikas Shivappa authored
BugLink: http://bugs.launchpad.net/bugs/1397880 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 <vikas.shivappa@linux.intel.com> Signed-off-by:
Tony Luck <tony.luck@intel.com> Acked-by:
Ingo Molnar <mingo@kernel.org> (cherry picked from commit e7ee3e8c) Signed-off-by:
-
Vikas Shivappa authored
BugLink: http://bugs.launchpad.net/bugs/1397880 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:
-
Tony Luck authored
BugLink: http://bugs.launchpad.net/bugs/1397880 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:
-
