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>
OLAND 0x1002:0x6604 0x1028:0x066F 0x00 seems to have problems
with higher sclks.
Acked-by: Christian König <christian.koenig@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Tim Gardner <tim.gardner@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>
This doesn't attempt to reuse any of the P7/8 defines or functions,
because that becomes too complex. The better option in future is to use
a table driven approach.
Signed-off-by: Nicholas Piggin <npiggin@gmail.com> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
(cherry picked from commit 7b9f71f974a12740e79e918cfd58c2fce0b5b580) Signed-off-by: Breno Leitao <brenohl@br.ibm.com> Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Nicholas Piggin [Fri, 24 Mar 2017 13:40:39 +0000 (10:40 -0300)]
powerpc/64s: allow machine check handler to set severity and initiator
BugLink: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1675771
Currently severity and initiator are always set to MCE_SEV_ERROR_SYNC and
MCE_INITIATOR_CPU in the core mce code. Allow them to be set by the
machine specific mce handlers.
No functional change for existing handlers.
Signed-off-by: Nicholas Piggin <npiggin@gmail.com> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
(cherry picked from commit c1bbf387d6191e6e18f3adc4db45b922822c2ba4) Signed-off-by: Breno Leitao <brenohl@br.ibm.com> Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Nicholas Piggin [Fri, 24 Mar 2017 13:40:38 +0000 (10:40 -0300)]
powerpc/64s: fix handling of non-synchronous machine checks
BugLink: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1675771
A synchronous machine check is an exception raised by the attempt to
execute the current instruction. If the error can't be corrected, it
can make sense to SIGBUS the currently running process.
In other cases, the error condition is not related to the current
instruction, so killing the current process is not the right thing to
do.
Today, all machine checks are MCE_SEV_ERROR_SYNC, so this has no
practical change. It will be used to handle POWER9 asynchronous
machine checks.
Signed-off-by: Nicholas Piggin <npiggin@gmail.com> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
(cherry picked from commit 1363875bdb6317a2d0798284d7aaf320f0782f6d) Signed-off-by: Breno Leitao <brenohl@br.ibm.com> Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
HWCAP variables contain bitmasks which can be used by userspace
applications to detect which instruction sets are supported by CPU. On x86
architecture information about CPU capabilities can be checked via CPUID
instructions, unfortunately presence of ring 3 MONITOR/MWAIT feature cannot
be checked this way. ELF_HWCAP cannot be used as well, because on x86 it is
set to CPUID[1].EDX which means that all bits are reserved there.
HWCAP2 approach was chosen because it reuses existing solution present
in other architectures, so only minor modifications are required to the
kernel and userspace applications. When ELF_HWCAP2 is defined
kernel maps it to AT_HWCAP2 during the start of the application.
This way the ring 3 MONITOR/MWAIT feature can be detected using getauxval()
API in a simple and fast manner. ELF_HWCAP2 type is u32 to be consistent
with x86 ELF_HWCAP type.
On supported CPUs if bit 1 of this MSR is set, then calling MONITOR and
MWAIT instructions outside of ring 0 will not cause invalid-opcode
exception.
The MSR MISC_FEATURE_ENABLES is not yet documented in the SDM. Here is the
relevant documentation:
Hex Dec Name Scope
140H 320 MISC_FEATURE_ENABLES Thread
0 Reserved
1 If set to 1, the MONITOR and MWAIT instructions do not
cause invalid-opcode exceptions when executed with CPL > 0
or in virtual-8086 mode. If MWAIT is executed when CPL > 0
or in virtual-8086 mode, and if EAX indicates a C-state
other than C0 or C1, the instruction operates as if EAX
indicated the C-state C1.
63:2 Reserved
Piotr Luc [Fri, 20 Jan 2017 13:22:37 +0000 (14:22 +0100)]
x86/cpufeature: Enable RING3MWAIT for Knights Mill
BugLink: http://bugs.launchpad.net/bugs/1637550
Enable ring 3 MONITOR/MWAIT for Intel Xeon Phi codenamed Knights Mill. We
can't guarantee that this (KNM) will be the last CPU model that needs this
hack. But, we do recognize that this is far from optimal, and there is an
effort to ensure we don't keep doing extending this hack forever.
Presence of this feature cannot be detected automatically (by reading any
other MSR) therefore it is required to explicitly check for the family and
model of the CPU before attempting to enable it.
Mika Westerberg [Fri, 27 Jan 2017 10:07:16 +0000 (13:07 +0300)]
pinctrl: intel: Add Intel Gemini Lake pin controller support
BugLink: http://bugs.launchpad.net/bugs/1645951
This driver adds pinctrl/GPIO support for Intel Gemini Lake SoC. The
GPIO controller is based on the next generation GPIO hardware but still
compatible with the one supported by the Intel core pinctrl/GPIO driver.
This commit includes material from David E. Box.
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com> Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
(cherry picked from commit 6693f9f96a0936488dd7876b8079933786e27b1b) Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Signed-off-by: David E. Box <david.e.box@linux.intel.com> Signed-off-by: Jarkko Nikula <jarkko.nikula@linux.intel.com> Signed-off-by: Mark Brown <broonie@kernel.org>
(cherry picked from commit e18a80acd1365e91e3efcd69942d9073936cf851) Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by: Jean Delvare <jdelvare@suse.de> Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
(cherry picked from commit 9827f9eb79c56424eac6409197a290601cf78eee) Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Mika Westerberg [Sat, 28 Jan 2017 15:10:44 +0000 (17:10 +0200)]
pwm: lpss: Add Intel Gemini Lake PCI ID
BugLink: http://bugs.launchpad.net/bugs/1645951
Intel Gemini Lake PWM is pretty much same as used in Intel Broxton. Add
this new PCI ID to the list of supported devices.
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
(cherry picked from commit ae2520540cb0090eb8cdba559bcb6a82266f0308) Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Andy Shevchenko [Wed, 11 Jan 2017 12:16:09 +0000 (14:16 +0200)]
mfd: intel-lpss: Add Intel Gemini Lake PCI IDs
BugLink: http://bugs.launchpad.net/bugs/1645951
Intel Gemini Lake is essentially Broxton with different PCI IDs. Add these
new PCI IDs to the list of supported devices.
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Lee Jones <lee.jones@linaro.org>
(cherry picked from commit f80e78aa11ad754de20104233af1ce4cea8f16a5) Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Running TCRYPT with LRW compiled causes spinlock recursion:
testing speed of async lrw(aes) (lrw(ecb-aes-s5p)) encryption
tcrypt: test 0 (256 bit key, 16 byte blocks): 19007 operations in 1 seconds (304112 bytes)
tcrypt: test 1 (256 bit key, 64 byte blocks): 15753 operations in 1 seconds (1008192 bytes)
tcrypt: test 2 (256 bit key, 256 byte blocks): 14293 operations in 1 seconds (3659008 bytes)
tcrypt: test 3 (256 bit key, 1024 byte blocks): 11906 operations in 1 seconds (12191744 bytes)
tcrypt: test 4 (256 bit key, 8192 byte blocks):
BUG: spinlock recursion on CPU#1, irq/84-10830000/89
lock: 0xeea99a68, .magic: dead4ead, .owner: irq/84-10830000/89, .owner_cpu: 1
CPU: 1 PID: 89 Comm: irq/84-10830000 Not tainted 4.11.0-rc1-00001-g897ca6d0800d #559
Hardware name: SAMSUNG EXYNOS (Flattened Device Tree)
[<c010e1ec>] (unwind_backtrace) from [<c010ae1c>] (show_stack+0x10/0x14)
[<c010ae1c>] (show_stack) from [<c03449c0>] (dump_stack+0x78/0x8c)
[<c03449c0>] (dump_stack) from [<c015de68>] (do_raw_spin_lock+0x11c/0x120)
[<c015de68>] (do_raw_spin_lock) from [<c0720110>] (_raw_spin_lock_irqsave+0x20/0x28)
[<c0720110>] (_raw_spin_lock_irqsave) from [<c0572ca0>] (s5p_aes_crypt+0x2c/0xb4)
[<c0572ca0>] (s5p_aes_crypt) from [<bf1d8aa4>] (do_encrypt+0x78/0xb0 [lrw])
[<bf1d8aa4>] (do_encrypt [lrw]) from [<bf1d8b00>] (encrypt_done+0x24/0x54 [lrw])
[<bf1d8b00>] (encrypt_done [lrw]) from [<c05732a0>] (s5p_aes_complete+0x60/0xcc)
[<c05732a0>] (s5p_aes_complete) from [<c0573440>] (s5p_aes_interrupt+0x134/0x1a0)
[<c0573440>] (s5p_aes_interrupt) from [<c01667c4>] (irq_thread_fn+0x1c/0x54)
[<c01667c4>] (irq_thread_fn) from [<c0166a98>] (irq_thread+0x12c/0x1e0)
[<c0166a98>] (irq_thread) from [<c0136a28>] (kthread+0x108/0x138)
[<c0136a28>] (kthread) from [<c0107778>] (ret_from_fork+0x14/0x3c)
Interrupt handling routine was calling req->base.complete() under
spinlock. In most cases this wasn't fatal but when combined with some
of the cipher modes (like LRW) this caused recursion - starting the new
encryption (s5p_aes_crypt()) while still holding the spinlock from
previous round (s5p_aes_complete()).
Beside that, the s5p_aes_interrupt() error handling path could execute
two completions in case of error for RX and TX blocks.
Rewrite the interrupt handling routine and the completion by:
1. Splitting the operations on scatterlist copies from
s5p_aes_complete() into separate s5p_sg_done(). This still should be
done under lock.
The s5p_aes_complete() now only calls req->base.complete() and it has
to be called outside of lock.
2. Moving the s5p_aes_complete() out of spinlock critical sections.
In interrupt service routine s5p_aes_interrupts(), it appeared in few
places, including error paths inside other functions called from ISR.
This code was not so obvious to read so simplify it by putting the
s5p_aes_complete() only within ISR level.
Reported-by: Nathan Royce <nroycea+kernel@gmail.com> Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org> 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>
We hang if SIGKILL has been sent, but the task is stuck in down_read()
(after do_exit()), even though no task is doing down_write() on the
rwsem in question:
INFO: task libupnp:21868 blocked for more than 120 seconds.
libupnp D 0 21868 1 0x08100008
...
Call Trace:
__schedule()
schedule()
__down_read()
do_exit()
do_group_exit()
__wake_up_parent()
This bug has already been fixed for CONFIG_RWSEM_XCHGADD_ALGORITHM=y in
the following commit:
If one thread mmaps a perf event while another thread in the same mm
is in some context where active_mm != mm (which can happen in the
scheduler, for example), refresh_pce() would write the wrong value
to CR4.PCE. This broke some PAPI tests.
Reported-and-tested-by: Vince Weaver <vincent.weaver@maine.edu> Signed-off-by: Andy Lutomirski <luto@kernel.org> Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com> Cc: Arnaldo Carvalho de Melo <acme@redhat.com> Cc: Borislav Petkov <bpetkov@suse.de> Cc: H. Peter Anvin <hpa@zytor.com> Cc: Jiri Olsa <jolsa@redhat.com> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Stephane Eranian <eranian@google.com> Cc: Thomas Gleixner <tglx@linutronix.de> Fixes: 7911d3f7af14 ("perf/x86: Only allow rdpmc if a perf_event is mapped") Link: http://lkml.kernel.org/r/0c5b38a76ea50e405f9abe07a13dfaef87c173a1.1489694270.git.luto@kernel.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>
The rdtgroup_kn_unlock waits for the last user to release and put its
node. But it's calling kernfs_put on the node which calls the
rdtgroup_kn_unlock, which might not be the group's directory node, but
another group's file node.
This race could be easily reproduced by running 2 instances
of following script:
The kernel doesn't boot with both PROFILE_ANNOTATED_BRANCHES=y and KASAN=y
options selected. With branch profiling enabled we end up calling
ftrace_likely_update() before kasan_early_init(). ftrace_likely_update() is
built with KASAN instrumentation, so calling it before kasan has been
initialized leads to crash.
Use DISABLE_BRANCH_PROFILING define to make sure that we don't call
ftrace_likely_update() from early code before kasan_early_init().
Subhransu reported that convert_art_to_tsc() isn't working for him.
The ART to TSC relation is only set up for systems which use the refined
TSC calibration. Systems with known TSC frequency (available via CPUID 15)
are not using the refined calibration and therefor the ART to TSC relation
is never established.
Add the setup to the known frequency init path which skips ART
calibration. The init code needs to be duplicated as for systems which use
refined calibration the ART setup must be delayed until calibration has
been done.
The problem has been there since the ART support was introdduced, but only
detected now because Subhransu tested the first time on hardware which has
TSC frequency enumerated via CPUID 15.
Note for stable: The conditional has changed from TSC_RELIABLE to
TSC_KNOWN_FREQUENCY.
[ tglx: Rewrote changelog and identified the proper 'Fixes' commit ]
Pavel Machek reported the following warning on x86-32:
WARNING: kernel stack frame pointer at f50cdf98 in swapper/2:0 has bad value (null)
The warning is caused by the unwinder not realizing that it reached the
end of the stack, due to an unusual prologue which gcc sometimes
generates for aligned stacks. The prologue is based on a gcc feature
called the Dynamic Realign Argument Pointer (DRAP). It's almost always
enabled for aligned stacks when -maccumulate-outgoing-args isn't set.
This issue is similar to the one fixed by the following commit:
8023e0e2a48d ("x86/unwind: Adjust last frame check for aligned function stacks")
... but that fix was specific to x86-64.
Make the fix more generic to cover x86-32 as well, and also ensure that
the return address referred to by the frame pointer is a copy of the
original return address.
Fixes: acb4608ad186 ("x86/unwind: Create stack frames for saved syscall registers") Reported-by: Pavel Machek <pavel@ucw.cz> Signed-off-by: Josh Poimboeuf <jpoimboe@redhat.com> Link: http://lkml.kernel.org/r/50d4924db716c264b14f1633037385ec80bf89d2.1489465609.git.jpoimboe@redhat.com Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
projects / mirror_ubuntu-zesty-kernel.git / log