Li Zhong [Tue, 28 Mar 2017 16:54:43 +0000 (13:54 -0300)]
KVM: PPC: Book 3S: XICS: Don't lock twice when checking for resend
BugLink: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1675806
This patch improves the code that takes lock twice to check the resend flag
and do the actual resending, by checking the resend flag locklessly, and
add a boolean parameter check_resend to icp_[rm_]deliver_irq(), so the
resend flag can be checked in the lock when doing the delivery.
We need make sure when we clear the ics's bit in the icp's resend_map, we
don't miss the resend flag of the irqs that set the bit. It could be
ordered through the barrier in test_and_clear_bit(), and a newly added
wmb between setting irq's resend flag, and icp's resend_map.
Signed-off-by: Li Zhong <zhong@linux.vnet.ibm.com> Signed-off-by: Paul Mackerras <paulus@ozlabs.org>
(cherry picked from commit 21acd0e4df04f02176e773468658c3cebff096bb) Signed-off-by: Breno Leitao <breno.leitao@gmail.com> Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
powerpc: Update to new option-vector-5 format for CAS
BugLink: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1675806
On POWER9 the ibm,client-architecture-support (CAS) negotiation process
has been updated to change how the host to guest negotiation is done for
the new hash/radix mmu as well as the nest mmu, process tables and guest
translation shootdown (GTSE).
This is documented in the unreleased PAPR ACR "CAS option vector
additions for P9".
The host tells the guest which options it supports in
ibm,arch-vec-5-platform-support. The guest then chooses a subset of these
to request in the CAS call and these are agreed to in the
ibm,architecture-vec-5 property of the chosen node.
Thus we read ibm,arch-vec-5-platform-support and make our selection before
calling CAS. We then parse the ibm,architecture-vec-5 property of the
chosen node to check whether we should run as hash or radix.
ibm,arch-vec-5-platform-support format:
index value pairs: <index, val> ... <index, val>
index: Option vector 5 byte number
val: Some representation of supported values
Signed-off-by: Suraj Jitindar Singh <sjitindarsingh@gmail.com> Acked-by: Paul Mackerras <paulus@ozlabs.org>
[mpe: Don't print about unknown options, be consistent with OV5_FEAT] Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
(cherry picked from commit 014d02cbf16b3106dc8e93281d2a9c189751ed5e) Signed-off-by: Breno Leitao <breno.leitao@gmail.com> Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Paul Mackerras [Tue, 28 Mar 2017 16:54:41 +0000 (13:54 -0300)]
powerpc/64: Invalidate process table caching after setting process table
BugLink: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1675806
The POWER9 MMU reads and caches entries from the process table.
When we kexec from one kernel to another, the second kernel sets
its process table pointer but doesn't currently do anything to
make the CPU invalidate any cached entries from the old process table.
This adds a tlbie (TLB invalidate entry) instruction with parameters
to invalidate caching of the process table after the new process
table is installed.
Signed-off-by: Paul Mackerras <paulus@ozlabs.org> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
(cherry picked from commit 7a70d7288c926ae88e0c773fbb506aa374e99c2d) Signed-off-by: Breno Leitao <breno.leitao@gmail.com> Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Paul Mackerras [Tue, 28 Mar 2017 16:54:39 +0000 (13:54 -0300)]
KVM: PPC: Book3S HV: Don't try to signal cpu -1
BugLink: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1675806
If the target vcpu for kvmppc_fast_vcpu_kick_hv() is not running on
any CPU, then we will have vcpu->arch.thread_cpu == -1, and as it
happens, kvmppc_fast_vcpu_kick_hv will call kvmppc_ipi_thread with
-1 as the cpu argument. Although this is not meaningful, in the past,
before commit 1704a81ccebc ("KVM: PPC: Book3S HV: Use msgsnd for IPIs
to other cores on POWER9", 2016-11-18), it was harmless because CPU
-1 is not in the same core as any real CPU thread. On a POWER9,
however, we don't do the "same core" check, so we were trying to
do a msgsnd to thread -1, which is invalid. To avoid this, we add
a check to see that vcpu->arch.thread_cpu is >= 0 before calling
kvmppc_ipi_thread() with it. Since vcpu->arch.thread_vcpu can change
asynchronously, we use READ_ONCE to ensure that the value we check is
the same value that we use as the argument to kvmppc_ipi_thread().
Fixes: 1704a81ccebc ("KVM: PPC: Book3S HV: Use msgsnd for IPIs to other cores on POWER9") Signed-off-by: Paul Mackerras <paulus@ozlabs.org>
(cherry picked from commit 3deda5e50c893be38c1b6b3a73f8f8fb5560baa4) Signed-off-by: Breno Leitao <breno.leitao@gmail.com> Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Paul Mackerras [Tue, 28 Mar 2017 16:54:38 +0000 (13:54 -0300)]
KVM: PPC: Book3S HV: Don't use ASDR for real-mode HPT faults on POWER9
BugLink: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1675806
In HPT mode on POWER9, the ASDR register is supposed to record
segment information for hypervisor page faults. It turns out that
POWER9 DD1 does not record the page size information in the ASDR
for faults in guest real mode. We have the necessary information
in memory already, so by moving the checks for real mode that already
existed, we can use the in-memory copy. Since a load is likely to
be faster than reading an SPR, we do this unconditionally (not just
for POWER9 DD1).
Signed-off-by: Paul Mackerras <paulus@ozlabs.org>
(cherry picked from commit 4e5acdc23a3dcbd6ad6dc93a9783dd9c838987c8) Signed-off-by: Breno Leitao <breno.leitao@gmail.com> Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Paul Mackerras [Tue, 28 Mar 2017 16:54:37 +0000 (13:54 -0300)]
KVM: PPC: Book3S HV: Fix software walk of guest process page tables
BugLink: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1675806
This fixes some bugs in the code that walks the guest's page tables.
These bugs cause MMIO emulation to fail whenever the guest is in
virtial mode (MMU on), leading to the guest hanging if it tried to
access a virtio device.
The first bug was that when reading the guest's process table, we were
using the whole of arch->process_table, not just the field that contains
the process table base address. The second bug was that the mask used
when reading the process table entry to get the radix tree base address,
RPDB_MASK, had the wrong value.
Fixes: 9e04ba69beec ("KVM: PPC: Book3S HV: Add basic infrastructure for radix guests") Fixes: e99833448c5f ("powerpc/mm/radix: Add partition table format & callback") Signed-off-by: Paul Mackerras <paulus@ozlabs.org>
(cherry picked from commit 70cd4c10b290dd77fff6dc702a9a2c8c679df121) Signed-off-by: Breno Leitao <breno.leitao@gmail.com> Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Nicholas Piggin [Tue, 28 Mar 2017 16:54:36 +0000 (13:54 -0300)]
powerpc/64: CONFIG_RELOCATABLE support for hmi interrupts
BugLink: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1675806
The branch from hmi_exception_early to hmi_exception_realmode must use
a "relocatable-style" branch, because it is branching from unrelocated
exception code to beyond __end_interrupts.
Signed-off-by: Nicholas Piggin <npiggin@gmail.com> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
(cherry picked from commit 2337d207288f163e10bd8d4d7eeb0c1c75046a0c) Signed-off-by: Breno Leitao <breno.leitao@gmail.com> Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
* Implement the backends for the KVM_PPC_CONFIGURE_V3_MMU and
KVM_PPC_GET_RMMU_INFO ioctls for radix guests
* On POWER9, allow secondary threads to be on/off-lined while guests
are running.
* Set up LPCR and the partition table entry for radix guests.
* Don't allocate the rmap array in the kvm_memory_slot structure
on radix.
* Don't try to initialize the HPT for radix guests, since they don't
have an HPT.
* Take out the code that prevents the HV KVM module from
initializing on radix hosts.
At this stage, we only support radix guests if the host is running
in radix mode, and only support HPT guests if the host is running in
HPT mode. Thus a guest cannot switch from one mode to the other,
which enables some simplifications.
Signed-off-by: Paul Mackerras <paulus@ozlabs.org> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
(cherry picked from commit 8cf4ecc0ca9bd9bdc9b4ca0a99f7445a1e74afed) Signed-off-by: Breno Leitao <breno.leitao@gmail.com> Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Paul Mackerras [Tue, 28 Mar 2017 16:54:33 +0000 (13:54 -0300)]
KVM: PPC: Book3S HV: Allow guest exit path to have MMU on
BugLink: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1675806
If we allow LPCR[AIL] to be set for radix guests, then interrupts from
the guest to the host can be delivered by the hardware with relocation
on, and thus the code path starting at kvmppc_interrupt_hv can be
executed in virtual mode (MMU on) for radix guests (previously it was
only ever executed in real mode).
Most of the code is indifferent to whether the MMU is on or off, but
the calls to OPAL that use the real-mode OPAL entry code need to
be switched to use the virtual-mode code instead. The affected
calls are the calls to the OPAL XICS emulation functions in
kvmppc_read_one_intr() and related functions. We test the MSR[IR]
bit to detect whether we are in real or virtual mode, and call the
opal_rm_* or opal_* function as appropriate.
The other place that depends on the MMU being off is the optimization
where the guest exit code jumps to the external interrupt vector or
hypervisor doorbell interrupt vector, or returns to its caller (which
is __kvmppc_vcore_entry). If the MMU is on and we are returning to
the caller, then we don't need to use an rfid instruction since the
MMU is already on; a simple blr suffices. If there is an external
or hypervisor doorbell interrupt to handle, we branch to the
relocation-on version of the interrupt vector.
Signed-off-by: Paul Mackerras <paulus@ozlabs.org> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
(cherry picked from commit 53af3ba2e8195f504d6a3a0667ccb5e7d4c57599) Signed-off-by: Breno Leitao <breno.leitao@gmail.com> Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Paul Mackerras [Tue, 28 Mar 2017 16:54:32 +0000 (13:54 -0300)]
KVM: PPC: Book3S HV: Invalidate TLB on radix guest vcpu movement
BugLink: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1675806
With radix, the guest can do TLB invalidations itself using the tlbie
(global) and tlbiel (local) TLB invalidation instructions. Linux guests
use local TLB invalidations for translations that have only ever been
accessed on one vcpu. However, that doesn't mean that the translations
have only been accessed on one physical cpu (pcpu) since vcpus can move
around from one pcpu to another. Thus a tlbiel might leave behind stale
TLB entries on a pcpu where the vcpu previously ran, and if that task
then moves back to that previous pcpu, it could see those stale TLB
entries and thus access memory incorrectly. The usual symptom of this
is random segfaults in userspace programs in the guest.
To cope with this, we detect when a vcpu is about to start executing on
a thread in a core that is a different core from the last time it
executed. If that is the case, then we mark the core as needing a
TLB flush and then send an interrupt to any thread in the core that is
currently running a vcpu from the same guest. This will get those vcpus
out of the guest, and the first one to re-enter the guest will do the
TLB flush. The reason for interrupting the vcpus executing on the old
core is to cope with the following scenario:
CPU 0 CPU 1 CPU 4
(core 0) (core 0) (core 1)
VCPU 0 runs task X VCPU 1 runs
core 0 TLB gets
entries from task X
VCPU 0 moves to CPU 4
VCPU 0 runs task X
Unmap pages of task X
tlbiel
(still VCPU 1) task X moves to VCPU 1
task X runs
task X sees stale TLB
entries
That is, as soon as the VCPU starts executing on the new core, it
could unmap and tlbiel some page table entries, and then the task
could migrate to one of the VCPUs running on the old core and
potentially see stale TLB entries.
Since the TLB is shared between all the threads in a core, we only
use the bit of kvm->arch.need_tlb_flush corresponding to the first
thread in the core. To ensure that we don't have a window where we
can miss a flush, this moves the clearing of the bit from before the
actual flush to after it. This way, two threads might both do the
flush, but we prevent the situation where one thread can enter the
guest before the flush is finished.
Signed-off-by: Paul Mackerras <paulus@ozlabs.org> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
(cherry picked from commit a29ebeaf5575d03eef178bb87c425a1e46cae1ca) Signed-off-by: Breno Leitao <breno.leitao@gmail.com> Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Paul Mackerras [Tue, 28 Mar 2017 16:54:31 +0000 (13:54 -0300)]
KVM: PPC: Book3S HV: Make HPT-specific hypercalls return error in radix mode
BugLink: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1675806
If the guest is in radix mode, then it doesn't have a hashed page
table (HPT), so all of the hypercalls that manipulate the HPT can't
work and should return an error. This adds checks to make them
return H_FUNCTION ("function not supported").
Signed-off-by: Paul Mackerras <paulus@ozlabs.org> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
(cherry picked from commit 65dae5403a162fe6ef7cd8b2835de9d23c303891) Signed-off-by: Breno Leitao <breno.leitao@gmail.com> Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
BugLink: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1675806
This adds code to keep track of dirty pages when requested (that is,
when memslot->dirty_bitmap is non-NULL) for radix guests. We use the
dirty bits in the PTEs in the second-level (partition-scoped) page
tables, together with a bitmap of pages that were dirty when their
PTE was invalidated (e.g., when the page was paged out). This bitmap
is stored in the first half of the memslot->dirty_bitmap area, and
kvm_vm_ioctl_get_dirty_log_hv() now uses the second half for the
bitmap that gets returned to userspace.
Signed-off-by: Paul Mackerras <paulus@ozlabs.org> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
(cherry picked from commit 8f7b79b8379a85fb8dd0c3f42d9f452ec5552161) Signed-off-by: Breno Leitao <breno.leitao@gmail.com> Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Paul Mackerras [Tue, 28 Mar 2017 16:54:29 +0000 (13:54 -0300)]
KVM: PPC: Book3S HV: MMU notifier callbacks for radix guests
BugLink: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1675806
This adapts our implementations of the MMU notifier callbacks
(unmap_hva, unmap_hva_range, age_hva, test_age_hva, set_spte_hva)
to call radix functions when the guest is using radix. These
implementations are much simpler than for HPT guests because we
have only one PTE to deal with, so we don't need to traverse
rmap chains.
Signed-off-by: Paul Mackerras <paulus@ozlabs.org> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
(cherry picked from commit 01756099e0a5f431bbada9693d566269acfb51f9) Signed-off-by: Breno Leitao <breno.leitao@gmail.com> Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Paul Mackerras [Tue, 28 Mar 2017 16:54:28 +0000 (13:54 -0300)]
KVM: PPC: Book3S HV: Page table construction and page faults for radix guests
BugLink: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1675806
This adds the code to construct the second-level ("partition-scoped" in
architecturese) page tables for guests using the radix MMU. Apart from
the PGD level, which is allocated when the guest is created, the rest
of the tree is all constructed in response to hypervisor page faults.
As well as hypervisor page faults for missing pages, we also get faults
for reference/change (RC) bits needing to be set, as well as various
other error conditions. For now, we only set the R or C bit in the
guest page table if the same bit is set in the host PTE for the
backing page.
This code can take advantage of the guest being backed with either
transparent or ordinary 2MB huge pages, and insert 2MB page entries
into the guest page tables. There is no support for 1GB huge pages
yet.
Signed-off-by: Paul Mackerras <paulus@ozlabs.org> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
(cherry picked from commit 5a319350a46572d073042a3194676099dd2c135d) Signed-off-by: Breno Leitao <breno.leitao@gmail.com> Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
BugLink: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1675806
This adds code to branch around the parts that radix guests don't
need - clearing and loading the SLB with the guest SLB contents,
saving the guest SLB contents on exit, and restoring the host SLB
contents.
Since the host is now using radix, we need to save and restore the
host value for the PID register.
On hypervisor data/instruction storage interrupts, we don't do the
guest HPT lookup on radix, but just save the guest physical address
for the fault (from the ASDR register) in the vcpu struct.
Signed-off-by: Paul Mackerras <paulus@ozlabs.org> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
(cherry picked from commit f4c51f841d2ac7d36cacb84efbc383190861f87c) Signed-off-by: Breno Leitao <breno.leitao@gmail.com> Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Paul Mackerras [Tue, 28 Mar 2017 16:54:26 +0000 (13:54 -0300)]
KVM: PPC: Book3S HV: Add basic infrastructure for radix guests
BugLink: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1675806
This adds a field in struct kvm_arch and an inline helper to
indicate whether a guest is a radix guest or not, plus a new file
to contain the radix MMU code, which currently contains just a
translate function which knows how to traverse the guest page
tables to translate an address.
Signed-off-by: Paul Mackerras <paulus@ozlabs.org> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
(cherry picked from commit 9e04ba69beec372ddf857c700ff922e95f50b0d0) Signed-off-by: Breno Leitao <breno.leitao@gmail.com> Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Paul Mackerras [Tue, 28 Mar 2017 16:54:25 +0000 (13:54 -0300)]
KVM: PPC: Book3S HV: Use ASDR for HPT guests on POWER9
BugLink: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1675806
POWER9 adds a register called ASDR (Access Segment Descriptor
Register), which is set by hypervisor data/instruction storage
interrupts to contain the segment descriptor for the address
being accessed, assuming the guest is using HPT translation.
(For radix guests, it contains the guest real address of the
access.)
Thus, for HPT guests on POWER9, we can use this register rather
than looking up the SLB with the slbfee. instruction.
Signed-off-by: Paul Mackerras <paulus@ozlabs.org> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
(cherry picked from commit ef8c640cb9cc865a461827b698fcc55b0ecaa600) Signed-off-by: Breno Leitao <breno.leitao@gmail.com> Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Paul Mackerras [Tue, 28 Mar 2017 16:54:23 +0000 (13:54 -0300)]
KVM: PPC: Book3S HV: Add userspace interfaces for POWER9 MMU
BugLink: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1675806
This adds two capabilities and two ioctls to allow userspace to
find out about and configure the POWER9 MMU in a guest. The two
capabilities tell userspace whether KVM can support a guest using
the radix MMU, or using the hashed page table (HPT) MMU with a
process table and segment tables. (Note that the MMUs in the
POWER9 processor cores do not use the process and segment tables
when in HPT mode, but the nest MMU does).
The KVM_PPC_CONFIGURE_V3_MMU ioctl allows userspace to specify
whether a guest will use the radix MMU or the HPT MMU, and to
specify the size and location (in guest space) of the process
table.
The KVM_PPC_GET_RMMU_INFO ioctl gives userspace information about
the radix MMU. It returns a list of supported radix tree geometries
(base page size and number of bits indexed at each level of the
radix tree) and the encoding used to specify the various page
sizes for the TLB invalidate entry instruction.
Initially, both capabilities return 0 and the ioctls return -EINVAL,
until the necessary infrastructure for them to operate correctly
is added.
Signed-off-by: Paul Mackerras <paulus@ozlabs.org> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
(cherry picked from commit c92701322711682de89b2bd0f32affad040b6e86) Signed-off-by: Breno Leitao <breno.leitao@gmail.com> Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Paul Mackerras [Tue, 28 Mar 2017 16:54:22 +0000 (13:54 -0300)]
powerpc/64: Allow for relocation-on interrupts from guest to host
BugLink: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1675806
With host and guest both using radix translation, it is feasible
for the host to take interrupts that come from the guest with
relocation on, and that is in fact what the POWER9 hardware will
do when LPCR[AIL] = 3. All such interrupts use HSRR0/1 not SRR0/1
except for system call with LEV=1 (hcall).
Therefore this adds the KVM tests to the _HV variants of the
relocation-on interrupt handlers, and adds the KVM test to the
relocation-on system call entry point.
We also instantiate the relocation-on versions of the hypervisor
data storage and instruction interrupt handlers, since these can
occur with relocation on in radix guests.
Signed-off-by: Paul Mackerras <paulus@ozlabs.org> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
(cherry picked from commit bc3551257af837fc603d295e59f9e32953525b98) Signed-off-by: Breno Leitao <breno.leitao@gmail.com> Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Paul Mackerras [Tue, 28 Mar 2017 16:54:21 +0000 (13:54 -0300)]
powerpc/64: Make type of partition table flush depend on partition type
BugLink: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1675806
When changing a partition table entry on POWER9, we do a particular
form of the tlbie instruction which flushes all TLBs and caches of
the partition table for a given logical partition ID (LPID).
This instruction has a field in the instruction word, labelled R
(radix), which should be 1 if the partition was previously a radix
partition and 0 if it was a HPT partition. This implements that
logic.
Signed-off-by: Paul Mackerras <paulus@ozlabs.org> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
(cherry picked from commit 16ed141677c5a1a796408e74ccd0a6f6554c3f21) Signed-off-by: Breno Leitao <breno.leitao@gmail.com> Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Paul Mackerras [Tue, 28 Mar 2017 16:54:19 +0000 (13:54 -0300)]
powerpc/64: More definitions for POWER9
BugLink: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1675806
This adds definitions for bits in the DSISR register which are used
by POWER9 for various translation-related exception conditions, and
for some more bits in the partition table entry that will be needed
by KVM.
Signed-off-by: Paul Mackerras <paulus@ozlabs.org> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
(cherry picked from commit dbcbfee0c81c7938e40d7d6bc659a5191f490b50) Signed-off-by: Breno Leitao <breno.leitao@gmail.com> Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Nicholas Piggin [Tue, 28 Mar 2017 16:54:18 +0000 (13:54 -0300)]
KVM: PPC: Book3S: 64-bit CONFIG_RELOCATABLE support for interrupts
BugLink: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1675806
64-bit Book3S exception handlers must find the dynamic kernel base
to add to the target address when branching beyond __end_interrupts,
in order to support kernel running at non-0 physical address.
Support this in KVM by branching with CTR, similarly to regular
interrupt handlers. The guest CTR saved in HSTATE_SCRATCH1 and
restored after the branch.
Without this, the host kernel hangs and crashes randomly when it is
running at a non-0 address and a KVM guest is started.
Signed-off-by: Nicholas Piggin <npiggin@gmail.com> Acked-by: Paul Mackerras <paulus@ozlabs.org> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
(cherry picked from commit a97a65d53d9f53b6897dc1b2aed381bc1707136b) Signed-off-by: Breno Leitao <breno.leitao@gmail.com> Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Nicholas Piggin [Tue, 28 Mar 2017 16:54:17 +0000 (13:54 -0300)]
KVM: PPC: Book3S: Move 64-bit KVM interrupt handler out from alt section
BugLink: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1675806
A subsequent patch to make KVM handlers relocation-safe makes them
unusable from within alt section "else" cases (due to the way fixed
addresses are taken from within fixed section head code).
Stop open-coding the KVM handlers, and add them both as normal. A more
optimal fix may be to allow some level of alternate feature patching in
the exception macros themselves, but for now this will do.
The TRAMP_KVM handlers must be moved to the "virt" fixed section area
(name is arbitrary) in order to be closer to .text and avoid the dreaded
"relocation truncated to fit" error.
Signed-off-by: Nicholas Piggin <npiggin@gmail.com> Acked-by: Paul Mackerras <paulus@ozlabs.org> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
(cherry picked from commit 7ede531773ea69fa56b02a873ed83ce3507eb8d5) Signed-off-by: Breno Leitao <breno.leitao@gmail.com> Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
The 64-bit PR handler entry translates the calling convention back
to match the previous call convention (i.e., shared with 32-bit), for
simplicity.
Signed-off-by: Nicholas Piggin <npiggin@gmail.com> Acked-by: Paul Mackerras <paulus@ozlabs.org> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
(cherry picked from commit d3918e7fd4a27564f93ec46d0359a9739c5deb8d) Signed-off-by: Breno Leitao <breno.leitao@gmail.com> Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
In the mlx4 case, this will cause that VF's comm channel to be disabled
before the VM has an opportunity to invoke the VF device's "shutdown"
method.
For such Hypervisors, there is a race condition between the VF's
shutdown method and its internal-error detection/reset thread.
The internal-error detection/reset thread (which runs every 5 seconds) also
detects a disabled comm channel. If the internal-error detection/reset
flow wins the race, we still get delays (while that flow tries repeatedly
to detect comm-channel recovery).
The cited commit fixed the command timeout problem when the
internal-error detection/reset flow loses the race.
This commit avoids the unneeded delays when the internal-error
detection/reset flow wins.
Fixes: d585df1c5ccf ("net/mlx4_core: Avoid command timeouts during VF driver device shutdown") Signed-off-by: Jack Morgenstein <jackm@dev.mellanox.co.il> Reported-by: Simon Xiao <sixiao@microsoft.com> Signed-off-by: Tariq Toukan <tariqt@mellanox.com> Signed-off-by: David S. Miller <davem@davemloft.net>
(cherry picked from commit 4cbe4dac82e423ecc9a0ba46af24a860853259f4) Signed-off-by: Joseph Salisbury <joseph.salisbury@canonical.com> Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Eric Dumazet [Sat, 18 Feb 2017 18:34:18 +0000 (10:34 -0800)]
mlx4: reduce OOM risk on arches with large pages
BugLink: http://bugs.launchpad.net/bugs/1676858
Since mlx4 NIC are used on PowerPC with 64K pages, we need to adapt
MLX4_EN_ALLOC_PREFER_ORDER definition.
Otherwise, a fragment sitting in an out of order TCP queue can hold
0.5 Mbytes and it is a serious OOM risk.
Fixes: 51151a16a60f ("mlx4: allow order-0 memory allocations in RX path") Signed-off-by: Eric Dumazet <edumazet@google.com> Reviewed-by: Tariq Toukan <tariqt@mellanox.com> Signed-off-by: David S. Miller <davem@davemloft.net>
(cherry picked from commit 3608b13ccc51d06e499dfe12b27f134de1286e28) Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Signed-off-by: Alexander Shishkin <alexander.shishkin@linux.intel.com>
(cherry picked from commit 340837f985c2cb87ca0868d4aa9ce42b0fab3a21) Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Signed-off-by: Alexander Shishkin <alexander.shishkin@linux.intel.com>
(cherry picked from commit 5118ccd34780f4637a9360be580f41f4c1feab48) Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Roi Dayan [Tue, 21 Mar 2017 13:59:14 +0000 (15:59 +0200)]
net/mlx5: E-Switch, Don't allow changing inline mode when flows are configured
BugLink: http://bugs.launchpad.net/bugs/1676388
Changing the eswitch inline mode can potentially cause already configured
flows not to match the policy. E.g. set policy L4, add some L4 rules,
set policy to L2 --> bad! Hence we disallow it.
Keep track of how many offloaded rules are now set and refuse
inline mode changes if this isn't zero.
Fixes: bffaa916588e ("net/mlx5: E-Switch, Add control for inline mode") Signed-off-by: Roi Dayan <roid@mellanox.com> Reviewed-by: Or Gerlitz <ogerlitz@mellanox.com> Signed-off-by: Saeed Mahameed <saeedm@mellanox.com> Signed-off-by: David S. Miller <davem@davemloft.net>
(cherry picked from commit 375f51e2b5b7b9a42b3139aea519cbb1bfc5d6ef) Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Or Gerlitz [Tue, 21 Mar 2017 13:59:13 +0000 (15:59 +0200)]
net/mlx5e: Change the TC offload rule add/del code path to be per NIC or E-Switch
BugLink: http://bugs.launchpad.net/bugs/1676388
Refactor the code to deal with add/del TC rules to have handler per NIC/E-switch
offloading use case, and push the latter into the e-switch code. This provides
better separation and is to be used in down-stream patch for applying a fix.
Fixes: bffaa916588e ("net/mlx5: E-Switch, Add control for inline mode") Signed-off-by: Or Gerlitz <ogerlitz@mellanox.com> Reviewed-by: Roi Dayan <roid@mellanox.com> Signed-off-by: Saeed Mahameed <saeedm@mellanox.com> Signed-off-by: David S. Miller <davem@davemloft.net>
(cherry picked from commit d85cdccbb3fe9a632ec9d0f4e4526c8c84fc3523) Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Signed-off-by: Jiri Pirko <jiri@mellanox.com> Signed-off-by: David S. Miller <davem@davemloft.net>
(cherry picked from commit 4456f61cfd2a589c4368fe0b9080b646b9bd470d) Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Signed-off-by: Jiri Pirko <jiri@mellanox.com> Signed-off-by: David S. Miller <davem@davemloft.net>
(cherry picked from commit 1a6aa36b6f92b1a2f2e6789f6785372d4d6ddca9) Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Signed-off-by: Jiri Pirko <jiri@mellanox.com> Signed-off-by: David S. Miller <davem@davemloft.net>
(cherry picked from commit 21e3d2dd4a19f842e7d134c341eb584970ff3b32) Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Jiri Pirko [Thu, 9 Feb 2017 14:54:33 +0000 (15:54 +0100)]
devlink: fix the name of eswitch commands
BugLink: http://bugs.launchpad.net/bugs/1676388
The eswitch_[gs]et command is supposed to be similar to port_[gs]et
command - for multiple eswitch attributes. However, when it was introduced
by 08f4b5918b2d ("net/devlink: Add E-Switch mode control") it was wrongly
named with the word "mode" in it. So fix this now, make the oririnal
enum value existing but obsolete.
Signed-off-by: Jiri Pirko <jiri@mellanox.com> Signed-off-by: David S. Miller <davem@davemloft.net>
(cherry picked from commit adf200f31c000d707e4afe238ed1d1199e0cce7c) Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Or Gerlitz [Fri, 10 Mar 2017 12:33:04 +0000 (14:33 +0200)]
net/mlx5e: Avoid wrong identification of rules on deletion
BugLink: http://bugs.launchpad.net/bugs/1676388
When deleting offloaded TC flows, we must correctly identify E-switch
rules. The current check could get us wrong w.r.t to rules set on the
PF. Since it's possible to set NIC rules on the PF, switch to SRIOV
offloads mode and then attempt to delete a NIC rule.
To solve that, we add a flags field to offloaded rules, set it on
creation time and use that over the code where currently needed.
Fixes: 8b32580df1cb ('net/mlx5e: Add TC vlan action for SRIOV offloads') Signed-off-by: Or Gerlitz <ogerlitz@mellanox.com> Reviewed-by: Roi Dayan <roid@mellanox.com> Signed-off-by: Saeed Mahameed <saeedm@mellanox.com> Signed-off-by: David S. Miller <davem@davemloft.net>
(cherry picked from commit 65ba8fb7d5c6803ec236bb8d6650465fed7f9769) Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Ard Biesheuvel [Wed, 22 Mar 2017 15:22:13 +0000 (10:22 -0500)]
UBUNTU: SAUCE: efi: arm-stub: Round up FDT allocation to mapping size
The FDT is mapped via a fixmap entry that is at least 2 MB in size and
2 MB aligned on 4 KB page size kernels.
On UEFI systems, the FDT allocation may share this 2 MB block with a
reserved region, or another memory region that we should never map,
unless we account for this in the size of the allocation (the alignment
is already 2 MB)
So instead of taking guesses at the needed space, simply allocate 2 MB
immediately. The allocation will be recorded as a EFI_LOADER_DATA, and
the kernel only memblock_reserve()'s the actual size of the FDT, so the
unused space will be released to the kernel.
BugLink: http://bugs.launchpad.net/bugs/1675046 Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Reviewed-By: Jeffrey Hugo <jhugo@codeaurora.org> Signed-off-by: Manoj Iyer <manoj.iyer@canonical.com> Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Ard Biesheuvel [Wed, 22 Mar 2017 15:22:04 +0000 (10:22 -0500)]
UBUNTU: SAUCE: efi: arm-stub: Correct FDT and initrd allocation rules for arm64
On arm64, we have made some changes over the past year to the way the
kernel itself is allocated and to how it deals with the initrd and FDT.
This patch brings the allocation logic in the EFI stub in line with that,
which is necessary because the introduction of KASLR has created the
possibility for the initrd to be allocated in a place where the kernel
may not be able to map it. (This is mostly a theoretical scenario, since
it only affects systems where the physical memory footprint exceeds the
size of the linear mapping.)
Since we know the kernel itself will be covered by the linear mapping,
choose a suitably sized window (i.e., based on the size of the linear
region) covering the kernel when allocating memory for the initrd.
The FDT may be anywhere in memory on arm64 now that we map it via the
fixmap, so we can lift the address restriction there completely.
BugLink: http://bugs.launchpad.net/bugs/1675046 Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Reviewed-By: Jeffrey Hugo <jhugo@codeaurora.org> Signed-off-by: Manoj Iyer <manoj.iyer@canonical.com> Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
BugLink: http://bugs.launchpad.net/bugs/1675872
Currently, command threads fails to return ioctls commands for older
controller versions, since it returns when all the fibs have been
allocated. Another issue is even all the fibs have not been allocated,
the correct allocated fibs is not updated nor freed.
Fixes: 113156bcea9ef1e6 (scsi: aacraid: Reworked aac_command_thread) Reported-by: Tomas Henzl <thenzl@redhat.com> Signed-off-by: Raghava Aditya Renukunta <RaghavaAditya.Renukunta@microsemi.com> Reviewed-by: Dave Carroll <david.carroll@microsemi.com> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
(cherry picked from linux-next commit e498520edec6655e93ac5e768b04f4fd2299fe4d) Signed-off-by: Seth Forshee <seth.forshee@canonical.com>
BugLink: http://bugs.launchpad.net/bugs/1675872
The return status of the adapter check on KERNEL_PANIC is supposed to be
the upper 16 bits of the OMR status register.
Fixes: c421530bf848604e (scsi: aacraid: Reorder Adpater status check) Reported-by: Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by: Raghava Aditya Renukunta <RaghavaAditya.Renukunta@microsemi.com> Reviewed-by: Dave Carroll <david.carroll@microsemi.com> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
(cherry picked from commit 934767c56b0d9dbb95a40e9e6e4d9dcdc3a165ad) Signed-off-by: Seth Forshee <seth.forshee@canonical.com>
Colin Ian King [Fri, 24 Feb 2017 14:43:30 +0000 (14:43 +0000)]
scsi: aacraid: remove redundant zero check on ret
BugLink: http://bugs.launchpad.net/bugs/1675872
The check for ret being zero is redundant as a few statements earlier we
break out of the while loop if ret is non-zero. Thus we can remove the
zero check and also the dead-code non-zero case too.
Detected by CoverityScan, CID#1411632 ("Logically Dead Code")
Signed-off-by: Colin Ian King <colin.king@canonical.com> Acked-by: Dave Carroll <david.carroll@microsemi.com> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
(cherry picked from commit fbdab3e7fd547e1ce558db1521659707bdf02cc6) Signed-off-by: Seth Forshee <seth.forshee@canonical.com>
Theodore Ts'o [Sat, 25 Mar 2017 21:22:47 +0000 (17:22 -0400)]
ext4: lock the xattr block before checksuming it
BugLink: http://bugs.launchpad.net/bugs/1658633
We must lock the xattr block before calculating or verifying the
checksum in order to avoid spurious checksum failures.
Reported-by: Colin Ian King <colin.king@canonical.com> Signed-off-by: Theodore Ts'o <tytso@mit.edu> Cc: stable@vger.kernel.org
(cherry picked from commit dac7a4b4b1f664934e8b713f529b629f67db313c) Signed-off-by: Tim Gardner <tim.gardner@canonical.com> Signed-off-by: Colin King <colin.king@canonical.com>
The VF reps are effectively related to the same mlx5 PCI device as the
PF. Since the kernel invokes the (say) delete ndo for each netdev, the
FW erred on multiple vxlan dst port deletes when the port was deleted
from the system.
We fix that by keeping the registration to be carried out only by the
PF. Since the PF serves as the uplink device, the VF reps will look
up a port there and realize if they are ok to offload that.
Tested:
<SETUP VFS>
<SETUP switchdev mode to have representors>
ip link add vxlan1 type vxlan id 44 dev ens5f0 dstport 9999
ip link set vxlan1 up
ip link del dev vxlan1
Fixes: 4a25730eb202 ('net/mlx5e: Add ndo_udp_tunnel_add to VF representors') Signed-off-by: Paul Blakey <paulb@mellanox.com> Reviewed-by: Or Gerlitz <ogerlitz@mellanox.com> Signed-off-by: Saeed Mahameed <saeedm@mellanox.com> Signed-off-by: David S. Miller <davem@davemloft.net>
(cherry picked from commit 1ad9a00ae0efc2e9337148d6c382fad3d27bf99a) Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Paul Blakey [Fri, 10 Mar 2017 12:33:01 +0000 (14:33 +0200)]
net/mlx5: Fix create autogroup prev initializer
BugLink: http://bugs.launchpad.net/bugs/1676388
The autogroups list is a list of non overlapping group boundaries
sorted by their start index. If the autogroups list wasn't empty
and an empty group slot was found at the start of the list,
the new group was added to the end of the list instead of the
beginning, as the prev initializer was incorrect.
When this was repeated, it caused multiple groups to have
overlapping boundaries.
Fixed that by correctly initializing the prev pointer to the
start of the list.
Fixes: eccec8da3b4e ('net/mlx5: Keep autogroups list ordered') Signed-off-by: Paul Blakey <paulb@mellanox.com> Reviewed-by: Mark Bloch <markb@mellanox.com> Signed-off-by: Saeed Mahameed <saeedm@mellanox.com> Signed-off-by: David S. Miller <davem@davemloft.net>
(cherry picked from commit af36370569eb37420e1e78a2e60c277b781fcd00) Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
dann frazier [Fri, 24 Mar 2017 19:53:05 +0000 (13:53 -0600)]
UBUNTU: SAUCE: arm64: arch_timer: Add check for unknown erratum
BugLink: https://bugs.launchpad.net/bugs/1675509
If an unknown erratum type is passed into arch_timer_check_ool_workaround(),
we would call arch_timer_iterate_errata with a NULL match_fn and trigger
an Oops. This does not look possible with the existing code (all types are
accounted for), but emit an error and return if it happens to come to pass
in the future.
Marc Zyngier [Tue, 21 Feb 2017 15:04:27 +0000 (15:04 +0000)]
UBUNTU: SAUCE: arm64: arch_timer: Add HISILICON_ERRATUM_161010101 ACPI matching data
BugLink: https://bugs.launchpad.net/bugs/1675509
In order to deal with ACPI enabled platforms suffering from the
HISILICON_ERRATUM_161010101, let's add the required OEM data that
allow the workaround to be enabled.
Tested-by: dann frazier <dann.frazier@canonical.com> Tested-by: Hanjun Guo <hanjun.guo@linaro.org> Reviewed-by: Hanjun Guo <hanjun.guo@linaro.org> Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
(cherry picked from commit 68fedd693bbdf8601667302ee12e677e50fe06d8
in the timers/errata-rework branch of
git://git.kernel.org/pub/scm/linux/kernel/git/maz/arm-platforms.git) Signed-off-by: dann frazier <dann.frazier@canonical.com> Signed-off-by: Seth Forshee <seth.forshee@canonical.com>
Marc Zyngier [Tue, 21 Feb 2017 14:37:30 +0000 (14:37 +0000)]
UBUNTU: SAUCE: arm64: arch_timer: Allow erratum matching with ACPI OEM information
BugLink: https://bugs.launchpad.net/bugs/1675509
Just as we're able to identify a broken platform using some DT
information, let's enable a way to spot the offenders with ACPI.
The difference is that we can only match on some OEM info instead
of implementation-specific properties. So in order to avoid the
insane multiplication of errata structures, we allow an array
of OEM descriptions to be attached to an erratum structure.
Tested-by: dann frazier <dann.frazier@canonical.com> Tested-by: Hanjun Guo <hanjun.guo@linaro.org> Reviewed-by: Hanjun Guo <hanjun.guo@linaro.org> Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
(cherry picked from commit b6789e1ee3a11f2edcd43ce13628a6de664a2c28
in the timers/errata-rework branch of
git://git.kernel.org/pub/scm/linux/kernel/git/maz/arm-platforms.git) Signed-off-by: dann frazier <dann.frazier@canonical.com> Signed-off-by: Seth Forshee <seth.forshee@canonical.com>
The workaround involves performing the read twice, and to return
one or the other depending on whether a transition has taken place.
Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
(cherry picked from commit 7b1f8a2afb42458f5878060aec51ad9c28cbf653
in the timers/errata-rework branch of
git://git.kernel.org/pub/scm/linux/kernel/git/maz/arm-platforms.git) Signed-off-by: dann frazier <dann.frazier@canonical.com> Signed-off-by: Seth Forshee <seth.forshee@canonical.com>
Marc Zyngier [Wed, 1 Feb 2017 12:07:15 +0000 (12:07 +0000)]
UBUNTU: SAUCE: arm64: arch_timer: Enable CNTVCT_EL0 trap if workaround is enabled
BugLink: https://bugs.launchpad.net/bugs/1675509
Userspace being allowed to use read CNTVCT_EL0 anytime (and not
only in the VDSO), we need to enable trapping whenever a cntvct
workaround is enabled on a given CPU.
Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
(cherry picked from commit 13fbbd32946ac882cdd3f07c02687f6b860d1a7f
in the timers/errata-rework branch of
git://git.kernel.org/pub/scm/linux/kernel/git/maz/arm-platforms.git) Signed-off-by: dann frazier <dann.frazier@canonical.com> Signed-off-by: Seth Forshee <seth.forshee@canonical.com>
Marc Zyngier [Wed, 1 Feb 2017 11:53:46 +0000 (11:53 +0000)]
UBUNTU: SAUCE: arm64: arch_timer: Move clocksource_counter and co around
BugLink: https://bugs.launchpad.net/bugs/1675509
In order to access clocksource_counter from the errata handling code,
move it (together with the related structures and functions) towards
the top of the file.
Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
(backported from commit d610f30af30c621399d2e7f5111ddc695f74311b
in the timers/errata-rework branch of
git://git.kernel.org/pub/scm/linux/kernel/git/maz/arm-platforms.git) Signed-off-by: dann frazier <dann.frazier@canonical.com> Signed-off-by: Seth Forshee <seth.forshee@canonical.com>
Marc Zyngier [Mon, 20 Feb 2017 18:34:48 +0000 (18:34 +0000)]
UBUNTU: SAUCE: arm64: arch_timer: Allows a CPU-specific erratum to only affect a subset of CPUs
BugLink: https://bugs.launchpad.net/bugs/1675509
Instead of applying a CPU-specific workaround to all CPUs in the system,
allow it to only affect a subset of them (typical big-little case).
This is done by turning the erratum pointer into a per-CPU variable.
Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
(cherry picked from commit a47c823df361fb477bdc98cb8d7d53841f6624a6
in the timers/errata-rework branch of
git://git.kernel.org/pub/scm/linux/kernel/git/maz/arm-platforms.git) Signed-off-by: dann frazier <dann.frazier@canonical.com> Signed-off-by: Seth Forshee <seth.forshee@canonical.com>
Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
(cherry picked from commit 7ecb0c2a0e111449128d17f559f0d0c6828d784c
in the timers/errata-rework branch of
git://git.kernel.org/pub/scm/linux/kernel/git/maz/arm-platforms.git) Signed-off-by: dann frazier <dann.frazier@canonical.com> Signed-off-by: Seth Forshee <seth.forshee@canonical.com>
Marc Zyngier [Fri, 27 Jan 2017 10:27:09 +0000 (10:27 +0000)]
UBUNTU: SAUCE: arm64: arch_timer: Rework the set_next_event workarounds
BugLink: https://bugs.launchpad.net/bugs/1675509
The way we work around errata affecting set_next_event is not very
nice, at it imposes this workaround on errata that do not need it.
Add new workaround hooks and let the existing workarounds use them.
Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
(cherry picked from commit afb31094daae2cb654266707293d992bb491576d
in the timers/errata-rework branch of
git://git.kernel.org/pub/scm/linux/kernel/git/maz/arm-platforms.git) Signed-off-by: dann frazier <dann.frazier@canonical.com> Signed-off-by: Seth Forshee <seth.forshee@canonical.com>
Marc Zyngier [Fri, 27 Jan 2017 10:27:09 +0000 (10:27 +0000)]
UBUNTU: SAUCE: arm64: arch_timer: Get rid of erratum_workaround_set_sne
BugLink: https://bugs.launchpad.net/bugs/1675509
Let's move the handling of workarounds affecting set_next_event
to the affected function, instead of overriding the pointers
as an afterthough. Yes, this is an extra indirection on the
erratum handling path, but the HW is busted anyway.
This will allow for some more flexibility later.
Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
(cherry picked from commit 32e0bde2c5371a9747ce917db8156e29d5c9fc8e
in the timers/errata-rework branch of
git://git.kernel.org/pub/scm/linux/kernel/git/maz/arm-platforms.git) Signed-off-by: dann frazier <dann.frazier@canonical.com> Signed-off-by: Seth Forshee <seth.forshee@canonical.com>
Marc Zyngier [Fri, 20 Jan 2017 18:28:32 +0000 (18:28 +0000)]
UBUNTU: SAUCE: arm64: arch_timer: Move arch_timer_reg_read/write around
BugLink: https://bugs.launchpad.net/bugs/1675509
As we're about to move things around, let's start with the low
level read/write functions. This allows us to use these functions
in the errata handling code without having to use forward declaration
of static functions.
Acked-by: Mark Rutland <mark.rutland@arm.com> Signed-off-by: Marc Zyngier <marc.zyngier@arm.com> Acked-by: Daniel Lezcano <daniel.lezcano@linaro.org>
(cherry picked from commit 685cbf2298afcf404bd519361c0915154ba48c89
in the timers/errata-rework branch of
git://git.kernel.org/pub/scm/linux/kernel/git/maz/arm-platforms.git) Signed-off-by: dann frazier <dann.frazier@canonical.com> Signed-off-by: Seth Forshee <seth.forshee@canonical.com>
Marc Zyngier [Mon, 20 Mar 2017 16:47:59 +0000 (16:47 +0000)]
UBUNTU: SAUCE: arm64: arch_timer: Add erratum handler for CPU-specific capability
BugLink: https://bugs.launchpad.net/bugs/1675509
Should we ever have a workaround for an erratum that is detected using
a capability and affecting a particular CPU, it'd be nice to have
a way to probe them directly.
Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
(cherry picked from commit 062d3f37a3e173053e0722f40fa15a46d82c7301
in the timers/errata-rework branch of
git://git.kernel.org/pub/scm/linux/kernel/git/maz/arm-platforms.git) Signed-off-by: dann frazier <dann.frazier@canonical.com> Signed-off-by: Seth Forshee <seth.forshee@canonical.com>
Marc Zyngier [Fri, 27 Jan 2017 11:27:26 +0000 (11:27 +0000)]
UBUNTU: SAUCE: arm64: arch_timer: Add erratum handler for globally defined capability
BugLink: https://bugs.launchpad.net/bugs/1675509
Should we ever have a workaround for an erratum that is detected using
a capability (and affecting the whole system), it'd be nice to have
a way to probe them directly.
Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
(cherry picked from commit b50b1f54abc59e7f4913b9bf476c6e89259776b7
in the timers/errata-rework branch of
git://git.kernel.org/pub/scm/linux/kernel/git/maz/arm-platforms.git) Signed-off-by: dann frazier <dann.frazier@canonical.com> Signed-off-by: Seth Forshee <seth.forshee@canonical.com>
BugLink: https://bugs.launchpad.net/bugs/1675509
We're currently stuck with DT when it comes to handling errata, which
is pretty restrictive. In order to make things more flexible, let's
introduce an infrastructure that could support alternative discovery
methods. No change in functionality.
Reviewed-by: Hanjun Guo <hanjun.guo@linaro.org> Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
(cherry picked from commit 180cb954f2b26c6bccfd1a1229e6bb7c8fb07167
in the timers/errata-rework branch of
git://git.kernel.org/pub/scm/linux/kernel/git/maz/arm-platforms.git) Signed-off-by: dann frazier <dann.frazier@canonical.com> Signed-off-by: Seth Forshee <seth.forshee@canonical.com>
BugLink: https://bugs.launchpad.net/bugs/1675509
In order to work around Cortex-A73 erratum 858921 in a subsequent
patch, add the required capability that advertise the erratum.
As the configuration option it depends on is not present yet,
this has no immediate effect.
Signed-off-by: Marc Zyngier <marc.zyngier@arm.com> Acked-by: Daniel Lezcano <daniel.lezcano@linaro.org>
(cherry picked from commit b0f0a6a803aada6268a546c3faf1987e36cbb3ca
in the timers/errata-rework branch of
git://git.kernel.org/pub/scm/linux/kernel/git/maz/arm-platforms.git) Signed-off-by: dann frazier <dann.frazier@canonical.com> Signed-off-by: Seth Forshee <seth.forshee@canonical.com>
Marc Zyngier [Wed, 1 Feb 2017 14:38:46 +0000 (14:38 +0000)]
UBUNTU: SAUCE: arm64: cpu_errata: Allow an erratum to be match for all revisions of a core
BugLink: https://bugs.launchpad.net/bugs/1675509
Some minor erratum may not be fixed in further revisions of a core,
leading to a situation where the workaround needs to be updated each
time an updated core is released.
Introduce a MIDR_ALL_VERSIONS match helper that will work for all
versions of that MIDR, once and for all.
Acked-by: Mark Rutland <mark.rutland@arm.com> Reviewed-by: Suzuki K Poulose <suzuki.poulose@arm.com> Signed-off-by: Marc Zyngier <marc.zyngier@arm.com> Acked-by: Daniel Lezcano <daniel.lezcano@linaro.org>
(cherry picked from commit 8b8ebca44292a59789c612c0e060c58cb7e0be40
in the timers/errata-rework branch of
git://git.kernel.org/pub/scm/linux/kernel/git/maz/arm-platforms.git) Signed-off-by: dann frazier <dann.frazier@canonical.com> Signed-off-by: Seth Forshee <seth.forshee@canonical.com>
Marc Zyngier [Mon, 30 Jan 2017 14:18:49 +0000 (14:18 +0000)]
UBUNTU: SAUCE: arm64: Define Cortex-A73 MIDR
BugLink: https://bugs.launchpad.net/bugs/1675509
As we're about to introduce a new workaround that is specific to
Cortex-A73, let's define the coresponding MIDR.
Acked-by: Mark Rutland <mark.rutland@arm.com> Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
(cherry picked from commit fcd3b9e93c6e735185c2e8187408847dd3295c20
in the timers/errata-rework branch of
git://git.kernel.org/pub/scm/linux/kernel/git/maz/arm-platforms.git) Signed-off-by: dann frazier <dann.frazier@canonical.com> Signed-off-by: Seth Forshee <seth.forshee@canonical.com>
Marc Zyngier [Wed, 1 Feb 2017 11:48:58 +0000 (11:48 +0000)]
UBUNTU: SAUCE: arm64: Add CNTVCT_EL0 trap handler
BugLink: https://bugs.launchpad.net/bugs/1675509
Since people seem to make a point in breaking the userspace visible
counter, we have no choice but to trap the access. Add the required
handler.
Acked-by: Mark Rutland <mark.rutland@arm.com> Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
(cherry picked from commit 2b88ddaa935c5d004c951b23089256f7f25fcaa3
in the timers/errata-rework branch of
git://git.kernel.org/pub/scm/linux/kernel/git/maz/arm-platforms.git) Signed-off-by: dann frazier <dann.frazier@canonical.com> Signed-off-by: Seth Forshee <seth.forshee@canonical.com>
Marc Zyngier [Mon, 30 Jan 2017 15:39:52 +0000 (15:39 +0000)]
UBUNTU: SAUCE: arm64: Allow checking of a CPU-local erratum
BugLink: https://bugs.launchpad.net/bugs/1675509
this_cpu_has_cap() only checks the feature array, and not the errata
one. In order to be able to check for a CPU-local erratum, allow it
to inspect the latter as well.
This is consistent with cpus_have_cap()'s behaviour, which includes
errata already.
Reviewed-by: Suzuki K Poulose <suzuki.poulose@arm.com> Signed-off-by: Marc Zyngier <marc.zyngier@arm.com> Acked-by: Daniel Lezcano <daniel.lezcano@linaro.org>
(cherry picked from commit cd3fc121809c82f577363d112bf028b2bd3a655d
in the timers/errata-rework branch of
git://git.kernel.org/pub/scm/linux/kernel/git/maz/arm-platforms.git) Signed-off-by: dann frazier <dann.frazier@canonical.com> Signed-off-by: Seth Forshee <seth.forshee@canonical.com>
Mark Rutland [Thu, 9 Feb 2017 15:19:18 +0000 (15:19 +0000)]
arm64: ptrace: add XZR-safe regs accessors
BugLink: http://bugs.launchpad.net/bugs/1675509
In A64, XZR and the SP share the same encoding (31), and whether an
instruction accesses XZR or SP for a particular register parameter
depends on the definition of the instruction.
We store the SP in pt_regs::regs[31], and thus when emulating
instructions, we must be careful to not erroneously read from or write
back to the saved SP. Unfortunately, we often fail to be this careful.
In all cases, instructions using a transfer register parameter Xt use
this to refer to XZR rather than SP. This patch adds helpers so that we
can more easily and consistently handle these cases.
Signed-off-by: Mark Rutland <mark.rutland@arm.com> Cc: Catalin Marinas <catalin.marinas@arm.com> Cc: Marc Zyngier <marc.zyngier@arm.com> Cc: Will Deacon <will.deacon@arm.com> Signed-off-by: Will Deacon <will.deacon@arm.com>
(cherry picked from commit 6c23e2ff7013be2c4bbcb7b9b3cc27c763348223) Signed-off-by: dann frazier <dann.frazier@canonical.com> Signed-off-by: Seth Forshee <seth.forshee@canonical.com>
pids_can_fork() is special in that the css association is guaranteed
to be stable throughout the function and thus doesn't need RCU
protection around task_css access. When determining the css to charge
the pid, task_css_check() is used to override the RCU sanity check.
While adding a warning message on fork rejection from pids limit, 135b8b37bd91 ("cgroup: Add pids controller event when fork fails
because of pid limit") incorrectly added a task_css access which is
neither RCU protected or explicitly annotated. This triggers the
following suspicious RCU usage warning when RCU debugging is enabled.
There's no reason to dereference task_css again here when the
associated css is already available. Fix it by replacing the
task_cgroup() call with css->cgroup.
Signed-off-by: Tejun Heo <tj@kernel.org> Reported-by: Mike Galbraith <efault@gmx.de> Fixes: 135b8b37bd91 ("cgroup: Add pids controller event when fork fails because of pid limit") Cc: Kenny Yu <kennyyu@fb.com> Signed-off-by: Tejun Heo <tj@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Update to pcpu_nr_empty_pop_pages in pcpu_alloc() is currently done
without holding pcpu_lock. This can lead to bad updates to the variable.
Add missing lock calls.
Commit 88ffbf3e03 switches to using rhashtables for glocks, hashing over
the entire struct lm_lockname instead of its individual fields. On some
architectures, struct lm_lockname contains a hole of uninitialized
memory due to alignment rules, which now leads to incorrect hash values.
Get rid of that hole.
Signed-off-by: Andreas Gruenbacher <agruenba@redhat.com> Signed-off-by: Bob Peterson <rpeterso@redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Make sure to check the number of endpoints to avoid dereferencing a
NULL-pointer should a malicious device lack endpoints.
Fixes: cf7776dc05b8 ("[PATCH] isdn4linux: Siemens Gigaset drivers - direct USB connection") Cc: Hansjoerg Lipp <hjlipp@web.de> Signed-off-by: Johan Hovold <johan@kernel.org> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
As reported by Max, the Windows 2008 R2 chkdsk utility expects
VERIFY_16 to be supported, and does not handle the returned
CHECK_CONDITION properly, resulting in an infinite loop.
Commit 669f044170d8 ("scsi: srp_transport: Move queuecommand() wait code
to SCSI core") can make scsi_internal_device_block() sleep. However,
the mpt3sas driver can call this function from an interrupt
handler. Hence add a second argument to scsi_internal_device_block()
that restores the old behavior of this function for the mpt3sas handler.
The call chain that triggered an "IRQ handler enabled interrupts"
complaint is as follows:
There's a rather long standing regression from the commit "libiscsi:
Reduce locking contention in fast path"
Depending on iSCSI target behavior, it's possible to hit the case in
iscsi_complete_task where the task is still on a pending list
(!list_empty(&task->running)). When that happens the task is removed
from the list while holding the session back_lock, but other task list
modification occur under the frwd_lock. That leads to linked list
corruption and eventually a panicked system.
Rather than back out the session lock split entirely, in order to try
and keep some of the performance gains this patch adds another lock to
maintain the task lists integrity.
Major enterprise supported kernels have been backing out the lock split
for while now, thanks to the efforts at IBM where a lab setup has the
most reliable reproducer I've seen on this issue. This patch has been
tested there successfully.
Signed-off-by: Chris Leech <cleech@redhat.com> Fixes: 659743b02c41 ("[SCSI] libiscsi: Reduce locking contention in fast path") Reported-by: Prashantha Subbarao <psubbara@us.ibm.com> Reviewed-by: Guilherme G. Piccoli <gpiccoli@linux.vnet.ibm.com> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
We see lpfc devices regularly fail during kexec. Fix this by adding a
shutdown method which mirrors the remove method.
Signed-off-by: Anton Blanchard <anton@samba.org> Reviewed-by: Mauricio Faria de Oliveira <mauricfo@linux.vnet.ibm.com> Tested-by: Mauricio Faria de Oliveira <mauricfo@linux.vnet.ibm.com> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
The following fixes a divide by zero OOPs with TYPE_TAPE
due to pscsi_tape_read_blocksize() failing causing a zero
sd->sector_size being propigated up via dev_attrib.hw_block_size.
It also fixes another long-standing bug where TYPE_TAPE and
TYPE_MEDIMUM_CHANGER where using pscsi_create_type_other(),
which does not call scsi_device_get() to take the device
reference. Instead, rename pscsi_create_type_rom() to
pscsi_create_type_nondisk() and use it for all cases.
Finally, also drop a dump_stack() in pscsi_get_blocks() for
non TYPE_DISK, which in modern target-core can get invoked
via target_sense_desc_format() during CHECK_CONDITION.
Reported-by: Malcolm Haak <insanemal@gmail.com> Signed-off-by: Nicholas Bellinger <nab@linux-iscsi.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Neil Brown pointed out a potential deadlock in raid 10 code with
bio_split/chain. The raid1 code could have the same issue, but recent
barrier rework makes it less likely to happen. The deadlock happens in
below sequence:
1. generic_make_request(bio), this will set current->bio_list
2. raid10_make_request will split bio to bio1 and bio2
3. __make_request(bio1), wait_barrer, add underlayer disk bio to
current->bio_list
4. __make_request(bio2), wait_barrer
If raise_barrier happens between 3 & 4, since wait_barrier runs at 3,
raise_barrier waits for IO completion from 3. And since raise_barrier
sets barrier, 4 waits for raise_barrier. But IO from 3 can't be
dispatched because raid10_make_request() doesn't finished yet.
The solution is to adjust the IO ordering. Quotes from Neil:
"
It is much safer to:
if (need to split) {
split = bio_split(bio, ...)
bio_chain(...)
make_request_fn(split);
generic_make_request(bio);
} else
make_request_fn(mddev, bio);
This way we first process the initial section of the bio (in 'split')
which will queue some requests to the underlying devices. These
requests will be queued in generic_make_request.
Then we queue the remainder of the bio, which will be added to the end
of the generic_make_request queue.
Then we return.
generic_make_request() will pop the lower-level device requests off the
queue and handle them first. Then it will process the remainder
of the original bio once the first section has been fully processed.
"
Note, this only happens in read path. In write path, the bio is flushed to
underlaying disks either by blk flush (from schedule) or offladed to raid1/10d.
It's queued in current->bio_list.
Cc: Coly Li <colyli@suse.de> Suggested-by: NeilBrown <neilb@suse.com> Reviewed-by: Jack Wang <jinpu.wang@profitbricks.com> Signed-off-by: Shaohua Li <shli@fb.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
ends up, through the reg_map_eip76[] array, in accessing the register at
offset 0, which is the RNG_OUTPUT_0_REG. This by itself doesn't cause
any problem, but clearly doesn't enable the interrupt as it was
expected.
On EIP76, the register that allows to enable the interrupt is
RNG_CONTROL_REG. And just like RNG_INTMASK_REG, it's bit 1 of this
register that allows to enable the shutdown_oflo interrupt.
Fixes: 383212425c926 ("hwrng: omap - Add device variant for SafeXcel IP-76 found in Armada 8K") Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
The omap-rng driver currently uses of_clk_get() to get a reference to
the clock, but never releases that reference. This commit fixes that by
using devm_clk_get() instead.
Fixes: 383212425c926 ("hwrng: omap - Add device variant for SafeXcel IP-76 found in Armada 8K") Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Commit 383212425c926 ("hwrng: omap - Add device variant for SafeXcel
IP-76 found in Armada 8K") added support for the SafeXcel IP-76 variant
of the IP. This modification included getting a reference and enabling a
clock. Unfortunately, this was done *after* writing to the
RNG_INTMASK_REG register. This generally works fine when the driver is
built-in because the clock might have been left enabled by the
bootloader, but fails short when the driver is built as a module: it
causes a system hang because a register is being accessed while the
clock is not enabled.
This commit fixes that by making the register access *after* enabling
the clock.
This issue was found by the kernelci.org testing effort.
Fixes: 383212425c926 ("hwrng: omap - Add device variant for SafeXcel IP-76 found in Armada 8K") Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Recent toolchains force the TOC to be 256 byte aligned. We need to
enforce this alignment in the zImage linker script, otherwise pointers
to our TOC variables (__toc_start) could be incorrect. If the actual
start of the TOC and __toc_start don't have the same value we crash
early in the zImage wrapper.
Suggested-by: Alan Modra <amodra@gmail.com> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Since rpc_task is async, the release function should be called which
will free the impl_id, scope, and owner.
Trond pointed at 2 more problems:
-- use of client pointer after free in the nfs4_exchangeid_release() function
-- cl_count mismatch if rpc_run_task() isn't run
Fixes: 8d89bd70bc9 ("NFS setup async exchange_id") Signed-off-by: Olga Kornievskaia <kolga@netapp.com> Signed-off-by: Anna Schumaker <Anna.Schumaker@Netapp.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
I can't reproduce this running sparse here. Likewise, "make W=1
net/sunrpc/xprtrdma/verbs.o" never indicated any issue.
A little poking suggests that because the range of its values is
small, gcc can make the actual width of RPCRDMA_MAX_SEND_SGES
smaller than the width of an unsigned integer.
Fixes: 16f906d66cd7 ("xprtrdma: Reduce required number of send SGEs") Signed-off-by: Chuck Lever <chuck.lever@oracle.com> Signed-off-by: Anna Schumaker <Anna.Schumaker@Netapp.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Before this patch, device InJournal will be included in prexor
(SYNDROME_SRC_WANT_DRAIN) but not in reconstruct (SYNDROME_SRC_WRITTEN). So it
will break parity calculation. With srctype == SYNDROME_SRC_WRITTEN, we need
include both dev with non-null ->written and dev with R5_InJournal. This fixes
logic in 1e6d690(md/r5cache: caching phase of r5cache)
Signed-off-by: Song Liu <songliubraving@fb.com> Signed-off-by: Shaohua Li <shli@fb.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
While hunting for clues to a use-after-free, Oleg spotted that
perf_event_init_context() can loose an error value with the result
that fork() can succeed even though we did not fully inherit the perf
event context.
Spotted-by: Oleg Nesterov <oleg@redhat.com> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com> Cc: Arnaldo Carvalho de Melo <acme@kernel.org> Cc: Arnaldo Carvalho de Melo <acme@redhat.com> Cc: Dmitry Vyukov <dvyukov@google.com> Cc: Frederic Weisbecker <fweisbec@gmail.com> Cc: Jiri Olsa <jolsa@redhat.com> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Mathieu Desnoyers <mathieu.desnoyers@efficios.com> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Stephane Eranian <eranian@google.com> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Vince Weaver <vincent.weaver@maine.edu> Cc: oleg@redhat.com Fixes: 889ff0150661 ("perf/core: Split context's event group list into pinned and non-pinned lists") Link: http://lkml.kernel.org/r/20170316125823.190342547@infradead.org Signed-off-by: Ingo Molnar <mingo@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
This patch closes the hole by making perf_event_free_task() destroy the
task <-> ctx relation such that perf_event_release_kernel() will no longer
observe the now dead task.
Spotted-by: Oleg Nesterov <oleg@redhat.com> Reported-by: Dmitry Vyukov <dvyukov@google.com> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com> Cc: Arnaldo Carvalho de Melo <acme@kernel.org> Cc: Arnaldo Carvalho de Melo <acme@redhat.com> Cc: Jiri Olsa <jolsa@redhat.com> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Mathieu Desnoyers <mathieu.desnoyers@efficios.com> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Stephane Eranian <eranian@google.com> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Vince Weaver <vincent.weaver@maine.edu> Cc: fweisbec@gmail.com Cc: oleg@redhat.com Fixes: c6e5b73242d2 ("perf: Synchronously clean up child events") Link: http://lkml.kernel.org/r/20170314155949.GE32474@worktop Link: http://lkml.kernel.org/r/20170316125823.140295131@infradead.org Signed-off-by: Ingo Molnar <mingo@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
On those parisc machines which don't provide a software power off
function, the system currently kills the init process at the end of a
shutdown and unexpectedly restarts insteads of halting.
Fix it by adding a loop which will not return.
The parisc kernel doesn't work with CONFIG_MODVERSIONS since the commit 71810db27c1c853b335675bee335d893bc3d324b. It can't load modules with the
error: "module unix: Unknown relocation: 41".
The commit changes __kcrctab from 64-bit valus to 32-bit values. The
assembler generates R_PARISC_SECREL32 secrel relocation for them and the
module loader doesn't support this relocation.
This patch adds the R_PARISC_SECREL32 relocation to the module loader.
The previously submitted patch did not resolve the random segmentation
faults observed on the phantom buildd system. There are still
unresolved problems with the Debian 4.8 and 4.9 kernels on C8000.
The attached patch removes the flush of the offset map pages and does a
whole data cache flush for large ranges. No other arch flushes the
offset map in these routines as far as I can tell.
I have not observed any random segmentation faults on rp3440 in two
weeks of testing with 4.10.0 and 4.10.1.
Signed-off-by: John David Anglin <dave.anglin@bell.net> Signed-off-by: Helge Deller <deller@gmx.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
When FW notify driver or driver detects low FW resource,
driver tries to send out Busy SCSI Status to tell Initiator
side to back off. During the send process, the lock was not held.
Signed-off-by: Quinn Tran <quinn.tran@qlogic.com> Signed-off-by: Himanshu Madhani <himanshu.madhani@cavium.com> Signed-off-by: Nicholas Bellinger <nab@linux-iscsi.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
gcc-7 has an "optimization" pass that completely screws up, and
generates the code expansion for the (impossible) case of calling
ilog2() with a zero constant, even when the code gcc compiles does not
actually have a zero constant.
And we try to generate a compile-time error for anybody doing ilog2() on
a constant where that doesn't make sense (be it zero or negative). So
now gcc7 will fail the build due to our sanity checking, because it
created that constant-zero case that didn't actually exist in the source
code.
There's a whole long discussion on the kernel mailing about how to work
around this gcc bug. The gcc people themselevs have discussed their
"feature" in
but it's all water under the bridge, because while it looked at one
point like it would be solved by the time gcc7 was released, that was
not to be.
So now we have to deal with this compiler braindamage.
And the only simple approach seems to be to just delete the code that
tries to warn about bad uses of ilog2().
So now "ilog2()" will just return 0 not just for the value 1, but for
any non-positive value too.
It's not like I can recall anybody having ever actually tried to use
this function on any invalid value, but maybe the sanity check just
meant that such code never made it out in public.
Reported-by: Laura Abbott <labbott@redhat.com> Cc: John Stultz <john.stultz@linaro.org>, Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Cc: Jiri Slaby <jslaby@suse.cz> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
projects / mirror_ubuntu-artful-kernel.git / log