Bitmap operators are overkill when touching only one bit.
Signed-off-by: Dave Gordon <david.s.gordon@intel.com>
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
To properly verify the driver->doorbell->GuC functionality, validation
needs to know how the driver has assigned the doorbell cache lines and
registers, so make them visible through debugfs.
v2: use kernel bitmap-printing format (%pb) rather than %x.
Signed-off-by: Dave Gordon <david.s.gordon@intel.com>
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Unlike the debug_fault_info table, we never intentionally alter the
fault_info table at runtime, and all derived pointers are treated as
const currently.
Make the table const so that it can be placed in .rodata and protected
from unintentional writes, as we do for the syscall tables.
Signed-off-by: Mark Rutland <mark.rutland@arm.com>
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Will Deacon <will.deacon@arm.com>
Signed-off-by: Will Deacon <will.deacon@arm.com>
If the kernel is set to show unhandled signals, and a user task does not
handle a SIGILL as a result of an instruction abort, we will attempt to
log the offending instruction with dump_instr before killing the task.
We use dump_instr to log the encoding of the offending userspace
instruction. However, dump_instr is also used to dump instructions from
kernel space, and internally always switches to KERNEL_DS before dumping
the instruction with get_user. When both PAN and UAO are in use, reading
a user instruction via get_user while in KERNEL_DS will result in a
permission fault, which leads to an Oops.
As we have regs corresponding to the context of the original instruction
abort, we can inspect this and only flip to KERNEL_DS if the original
abort was taken from the kernel, avoiding this issue. At the same time,
remove the redundant (and incorrect) comments regarding the order
dump_mem and dump_instr are called in.
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: James Morse <james.morse@arm.com>
Cc: Robin Murphy <robin.murphy@arm.com>
Cc: <stable@vger.kernel.org> #4.6+
Signed-off-by: Mark Rutland <mark.rutland@arm.com>
Reported-by: Vladimir Murzin <vladimir.murzin@arm.com>
Tested-by: Vladimir Murzin <vladimir.murzin@arm.com>
Fixes: 57f4959bad ("arm64: kernel: Add support for User Access Override")
Signed-off-by: Will Deacon <will.deacon@arm.com>
We need card to be early suspended and late resumed, so use prepare and
complete for card suspend and resume.
Signed-off-by: Jeeja KP <jeeja.kp@intel.com>
Signed-off-by: Senthilnathan Veppur <senthilnathanx.veppur@intel.com>
Signed-off-by: Vinod Koul <vinod.koul@intel.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
The stall bits needs to comprehend the number of DSP cores
running, so update the stall and unstall register writes to
comprehend SKL_DSP_CORES_MASK values as well.
Signed-off-by: Jayachandran B <jayachandran.b@intel.com>
Signed-off-by: Ramesh Babu <ramesh.babu@intel.com>
Signed-off-by: Vinod Koul <vinod.koul@intel.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Broxton needs to send Purge firmware IPC to DSP before downloading the
firmware. The DMA id needs to be updated for that.
While at it also update Broxton boot sequence to send purge request after
power up and before yanking off reset.
Signed-off-by: Senthilnathan Veppur <senthilnathanx.veppur@intel.com>
Signed-off-by: Vinod Koul <vinod.koul@intel.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Broxton DSP needs retains code loaded during runtime_pm cycles.
But it looses that on suspend cycle, so on resume we need to
download the firmware again.
This is done by adding a new flag and based on flag status, we
download the firmware.
Signed-off-by: Jayachandran B <jayachandran.b@intel.com>
Signed-off-by: Senthilnathan Veppur <senthilnathanx.veppur@intel.com>
Signed-off-by: Vinod Koul <vinod.koul@intel.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Capture from DMIC requires that we ignore the suspend, so mark
these as ignore_suspend in bxt-rt298 machine.
Signed-off-by: Senthilnathan Veppur <senthilnathanx.veppur@intel.com>
Signed-off-by: Vinod Koul <vinod.koul@intel.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
We support stereo 48Khz audio, so add these as constraints
for this card
Signed-off-by: Senthilnathan Veppur <senthilnathanx.veppur@intel.com>
Signed-off-by: Vinod Koul <vinod.koul@intel.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Like Skylake, we can support 4 channel for DMIC, so add
hw_params and constraints in the bxt-rt298 machine
While at it, also add codec1 pipe for speaker playback.
Signed-off-by: Senthilnathan Veppur <senthilnathanx.veppur@intel.com>
Signed-off-by: Vinod Koul <vinod.koul@intel.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
The newly added nau8825_dai_is_active() function is only called from
the PM logic that is build-time conditional in this driver, so we get
a warning when CONFIG_PM is disabled:
sound/soc/codecs/nau8825.c:229:13: error: 'nau8825_dai_is_active' defined but not used [-Werror=unused-function]
static bool nau8825_dai_is_active(struct nau8825 *nau8825)
By replacing the #ifdef around the functions with a __maybe_unused
annotation, the code becomes more robust to this kind of problem
and we no longer get the warning while also slightly improving
readability.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Fixes: b50455fab4 ("ASoC: nau8825: cross talk suppression measurement function")
Signed-off-by: Mark Brown <broonie@kernel.org>
A recent commit made a few arrays 'const', but also added the
same attribute to a function return type, where it makes no
sense, and we get a warning when building with W=1:
sound/soc/codecs/arizona.c:1725:27: error: type qualifiers ignored on function return type [-Werror=ignored-qualifiers]
static const char * const arizona_dai_clk_str(int clk_id)
This removes it again.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Acked-by: Charles Keepax <ckeepax@opensource.wolfsonmicro.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
The nl80211 layer expects P2P search operation to be aborted
if needed when stopping P2P device. If the P2P search operation
is still running after returning from stop_p2p_device
it causes a WARN_ON and possibly a kernel crash.
Fix this by aborting the P2P search in wil_cfg80211_stop_p2p_device
and preventing P2P search from being started on a stopped P2P
device.
Note, the fix does not cover the case where a regular scan
is started on the P2P device. It will be completed in the
future when support is added for aborting a scan operation.
Signed-off-by: Lior David <qca_liord@qca.qualcomm.com>
Signed-off-by: Maya Erez <qca_merez@qca.qualcomm.com>
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
In wil_p2p_listen chan is checked to protect against NULL
pointer access only before setting channel = chan->hw_value.
Add a global parameter check to cover all accesses to chan.
Signed-off-by: Maya Erez <qca_merez@qca.qualcomm.com>
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
Uncomment and export synthesize_perf_probe_point() which had once
introduced but has been disabled for a long time. This renews the code
and re-enable it.
Signed-off-by: Masami Hiramatsu <mhiramat@kernel.org>
Cc: Ananth N Mavinakayanahalli <ananth@linux.vnet.ibm.com>
Cc: Brendan Gregg <brendan.d.gregg@gmail.com>
Cc: Hemant Kumar <hemant@linux.vnet.ibm.com>
Cc: Namhyung Kim <namhyung@kernel.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Link: http://lkml.kernel.org/r/20160608092949.3116.21958.stgit@devbox
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Add perf_probe_event__copy() to copy perf_probe_event data structure and
sub data structures under given source perf_probe_event.
Signed-off-by: Masami Hiramatsu <mhiramat@kernel.org>
Cc: Ananth N Mavinakayanahalli <ananth@linux.vnet.ibm.com>
Cc: Brendan Gregg <brendan.d.gregg@gmail.com>
Cc: Hemant Kumar <hemant@linux.vnet.ibm.com>
Cc: Namhyung Kim <namhyung@kernel.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Link: http://lkml.kernel.org/r/20160608092940.3116.18034.stgit@devbox
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Rename and export build_id_cache__cachedir() for retrieving use of the
path of cache directory for given build_id.
Signed-off-by: Masami Hiramatsu <mhiramat@kernel.org>
Cc: Ananth N Mavinakayanahalli <ananth@linux.vnet.ibm.com>
Cc: Brendan Gregg <brendan.d.gregg@gmail.com>
Cc: Hemant Kumar <hemant@linux.vnet.ibm.com>
Cc: Namhyung Kim <namhyung@kernel.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Link: http://lkml.kernel.org/r/20160608092930.3116.67575.stgit@devbox
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Fix rm_rf() to handle non-regular files correctly. This fix includes two
changes;
- Fix to use lstat(3) instead of stat(3) since if the target
file is a symbolic link, rm_rf() should unlink the symbolic
link itself, not the file which pointed by the symlink.
- Fix to unlink non-regular files (except for directory),
including symlink.
Even though the first one fixes to stat symlink itself, without second
fix, it still failed because the symlink is not a regular file.
Signed-off-by: Masami Hiramatsu <mhiramat@kernel.org>
Cc: Ananth N Mavinakayanahalli <ananth@linux.vnet.ibm.com>
Cc: Brendan Gregg <brendan.d.gregg@gmail.com>
Cc: Hemant Kumar <hemant@linux.vnet.ibm.com>
Cc: Namhyung Kim <namhyung@kernel.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Link: http://lkml.kernel.org/r/20160608092911.3116.90929.stgit@devbox
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
perf_config_set__delete() purge and free the config set that contains
all config key-value pairs. But if the config set (i.e. 'set' variable
at the function) is NULL, this is wrong so handle it.
Signed-off-by: Taeung Song <treeze.taeung@gmail.com>
Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
Cc: Jiri Olsa <jolsa@redhat.com>
Cc: Masami Hiramatsu <mhiramat@kernel.org>
Cc: Namhyung Kim <namhyung@kernel.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Wang Nan <wangnan0@huawei.com>
Link: http://lkml.kernel.org/r/1465389413-8936-2-git-send-email-treeze.taeung@gmail.com
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Make sign-file determine the format of the X.509 certificate by reading the
first two bytes and seeing if the first byte is 0x30 and the second
0x81-0x84. If this is the case, assume it's DER encoded, otherwise assume
it to be PEM encoded.
Without this, it gets awkward to deal with the error messages from
d2i_X509_bio() when we want to call BIO_reset() and then PEM_read_bio() in
case the certificate was PEM encoded rather than X.509 encoded.
Reported-by: Ben Hutchings <ben@decadent.org.uk>
Signed-off-by: David Howells <dhowells@redhat.com>
Tested-by: Ben Hutchings <ben@decadent.org.uk>
cc: David Woodhouse <dwmw2@infradead.org>
cc: Juerg Haefliger <juerg.haefliger@hpe.com>
cc: Ben Hutchings <ben@decadent.org.uk>
In this switch statement, the default case does not always assign
sifs. In practice, ah->ah_bwmode cannot take values besides the
other labels, so this is not an actual problem, but it looks odd
and smatch complains thus:
ath5k_hw_get_default_sifs() warn: missing break? reassigning 'sifs'
Silence the warning by moving default label up a line.
Signed-off-by: Bob Copeland <me@bobcopeland.com>
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
commit 5c86d97bcc ("ath10k: combine txrx and replenish task")
introduced deadlock while processing rx in order indication message
for qca6174 based devices. While merging replenish and txrx tasklets,
replenish task should be called out of htt rx ring locking since it
is also try to acquire the same lock.
Unfortunately this issue is not exposed by other solutions (qca988x,
qca99x0 & qca4019), as rx_in_ord_ind message is specific to qca6174
based devices. This patch fixes
=============================================
[ INFO: possible recursive locking detected ]
4.7.0-rc2-wt-ath+ #1353 Tainted: G E
---------------------------------------------
swapper/3/0 is trying to acquire lock:
(&(&htt->rx_ring.lock)->rlock){+.-...}, at: [<f8d7ef19>]
ath10k_htt_rx_msdu_buff_replenish+0x29/0x90 [ath10k_core]
but task is already holding lock:
(&(&htt->rx_ring.lock)->rlock){+.-...}, at: [<f8d82cab>]
ath10k_htt_txrx_compl_task+0x21b/0x250 [ath10k_core]
other info that might help us debug this:
Possible unsafe locking scenario:
CPU0
----
lock(&(&htt->rx_ring.lock)->rlock);
lock(&(&htt->rx_ring.lock)->rlock);
*** DEADLOCK ***
May be due to missing lock nesting notation
1 lock held by swapper/3/0:
#0: (&(&htt->rx_ring.lock)->rlock){+.-...}, at: [<f8d82cab>]
ath10k_htt_txrx_compl_task+0x21b/0x250 [ath10k_core]
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=119151
Fixes: 5c86d97bcc ("ath10k: combine txrx and replenish task")
Reported-by: Mike Lothian <mike@fireburn.co.uk>
Signed-off-by: Rajkumar Manoharan <rmanohar@qti.qualcomm.com>
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
In QCA4019, cycle counter wraparound is not tied to rx
clear counter. Each counter would wraparound individually
and after wraparound the respective counter will be reset
to 0x7fffffff while other counter still running unaffected.
Define a new wraparound type for this behaviour and handle
it separately so that rx clear counter wraparound is also
handled just like cycle counter. With this type of
wraparound we can accurately compute and report channel
active/busy time when any of the counter overflows.
Fixes: ee9ca147c5 ("ath10k: Fix survey reporting with QCA4019")
Signed-off-by: Vasanthakumar Thiagarajan <vthiagar@qti.qualcomm.com>
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
QCA988X hw implements a different cycle counter wraparound
behaviour when compared to QCA4019. To properly handle different
wraparound logic for these chipsets replace already available
bool hw_params member, has_shifted_cc_wraparound, with an
enum which could be extended to handle different wraparound
behaviour. This patch keeps the existing logic functionally
same and a prepares cycle counter wraparound handling to
extend for other chips.
Signed-off-by: Vasanthakumar Thiagarajan <vthiagar@qti.qualcomm.com>
[kvalo@qca.qualcomm.com: change also QCA9887 wrap type]
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
CCK hardware table mapping from QCA99X0 onwards got revised.
The CCK hardware rate values are in a proper order wrt. to
rate and preamble as below
ATH10K_HW_RATE_REV2_CCK_LP_1M = 1,
ATH10K_HW_RATE_REV2_CCK_LP_2M = 2,
ATH10K_HW_RATE_REV2_CCK_LP_5_5M = 3,
ATH10K_HW_RATE_REV2_CCK_LP_11M = 4,
ATH10K_HW_RATE_REV2_CCK_SP_2M = 5,
ATH10K_HW_RATE_REV2_CCK_SP_5_5M = 6,
ATH10K_HW_RATE_REV2_CCK_SP_11M = 7,
This results in reporting of rx frames (with CCK rates)
totally wrong for QCA99X0, QCA4019. Fix this by having
separate CCK rate table for these chipsets with rev2 suffix
and registering the correct rate mapping to mac80211 based on
the new hw_param (introduced) 'cck_rate_map_rev2' which shall
be true for any newchipsets from QCA99X0 onwards
Signed-off-by: Mohammed Shafi Shajakhan <mohammed@qti.qualcomm.com>
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
All these flags are not used and their use is completely
covered by 'ath10k_hw_rate_ofdm', 'ath10k_hw_rate_cck',
and RX_PPDU_START_RATE_FLAG
Signed-off-by: Mohammed Shafi Shajakhan <mohammed@qti.qualcomm.com>
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
Only five bits are defined to pass tid information in HTT_RX_IND
message, so the mask which can be used to extract tid should be 0x1f
instead of the current 0x3f. Also, macros which can be used to extract
flush_valid and release_valid bits have to be left shifted one bit less
because these information follow the tid right after. This patch does
not really fix anything functionally because these macros are not used
currently.
Signed-off-by: Vasanthakumar Thiagarajan <vthiagar@qti.qualcomm.com>
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
Lengthy output of sysrq-w may take a lot of time on slow serial console.
Currently we reset NMI-watchdog on the current CPU to avoid spurious
lockup messages. Sometimes this doesn't work since softlockup watchdog
might trigger on another CPU which is waiting for an IPI to proceed.
We reset softlockup watchdogs on all CPUs, but we do this only after
listing all tasks, and this may be too late on a busy system.
So, reset watchdogs CPUs earlier, in for_each_process_thread() loop.
Signed-off-by: Andrey Ryabinin <aryabinin@virtuozzo.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: <stable@vger.kernel.org>
Link: http://lkml.kernel.org/r/1465474805-14641-1-git-send-email-aryabinin@virtuozzo.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Intel Merrifield platform has Punit generation that somehow compatible to what
is already supported by punit_atom_debug driver.
Add necessary bits to enable that support.
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Acked-by: Thomas Gleixner <tglx@linutronix.de>
Cc: Bjorn Helgaas <bhelgaas@google.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Link: http://lkml.kernel.org/r/1465842481-136852-2-git-send-email-andriy.shevchenko@linux.intel.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
On Intel Merrifield platform several PCI devices have a bogus configuration,
i.e. the IRQ0 had been assigned to few of them. These are PCI root bridge,
eMMC0, HS UART common registers, PWM, and HDMI. The actual interrupt line can
be allocated to one device exclusively, in our case to eMMC0, the rest should
cope without it and basically known drivers for them are not using interrupt
line at all.
Rework IRQ0 workaround, which was previously done to avoid conflict between
eMMC0 and HS UART common registers, to behave differently based on the device
in question, i.e. allocate interrupt line to eMMC0, but silently skip interrupt
allocation for the rest except HS UART common registers which are not used
anyway. With this rework IOSF MBI driver in particular would be used.
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Acked-by: Thomas Gleixner <tglx@linutronix.de>
Cc: Bjorn Helgaas <bhelgaas@google.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Fixes: 39d9b77b8d ("x86/pci/intel_mid_pci: Work around for IRQ0 assignment")
Link: http://lkml.kernel.org/r/1465842481-136852-1-git-send-email-andriy.shevchenko@linux.intel.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
I've had this code for a while, but never submitted it upstream. Now
that Skylake hardware is out in the wild, folks can actually run this
for real. It tests the following:
1. The MPX hardware is enabled by the kernel and doing what it
is supposed to
2. The MPX management code is present and enabled in the kernel
3. MPX Signal handling
4. The MPX bounds table population code (on-demand population)
5. The MPX bounds table unmapping code (kernel-initiated freeing
when unused)
This has also caught bugs in the XSAVE code because MPX state is
saved/restored with XSAVE.
I'm submitting it now because it would have caught the recent issues
with the compat_siginfo code not being properly augmented when new
siginfo state is added.
Signed-off-by: Dave Hansen <dave.hansen@linux.intel.com>
Cc: Al Viro <viro@zeniv.linux.org.uk>
Cc: Andy Lutomirski <luto@kernel.org>
Cc: Borislav Petkov <bp@alien8.de>
Cc: Brian Gerst <brgerst@gmail.com>
Cc: Dave Hansen <dave@sr71.net>
Cc: Denys Vlasenko <dvlasenk@redhat.com>
Cc: H. Peter Anvin <hpa@zytor.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Oleg Nesterov <oleg@redhat.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Shuah Khan <shuahkh@osg.samsung.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Link: http://lkml.kernel.org/r/20160608172535.5B40B0EE@viggo.jf.intel.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
There were at least 3 features added to the __SI_FAULT area of the
siginfo struct that did not make it to the compat siginfo:
1. The si_addr_lsb used in SIGBUS's sent for machine checks
2. The upper/lower bounds for MPX SIGSEGV faults
3. The protection key for pkey faults
There was also some turmoil when I was attempting to add the pkey
field because it needs to be a fixed size on 32 and 64-bit and
not have any alignment constraints.
This patch adds some compile-time checks to the compat code to
make it harder to screw this up. Basically, the checks are
supposed to trip any time someone changes the siginfo structure.
That sounds bad, but it's what we want. If someone changes
siginfo, we want them to also be _forced_ to go look at the
compat code.
The details are in the comments.
Signed-off-by: Dave Hansen <dave.hansen@linux.intel.com>
Cc: Al Viro <viro@zeniv.linux.org.uk>
Cc: Andy Lutomirski <luto@kernel.org>
Cc: Borislav Petkov <bp@alien8.de>
Cc: Brian Gerst <brgerst@gmail.com>
Cc: Dave Hansen <dave@sr71.net>
Cc: Denys Vlasenko <dvlasenk@redhat.com>
Cc: H. Peter Anvin <hpa@zytor.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Oleg Nesterov <oleg@redhat.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Tony Luck <tony.luck@intel.com>
Cc: linux-edac@vger.kernel.org
Link: http://lkml.kernel.org/r/20160608172534.C73DAFC3@viggo.jf.intel.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
The 32-bit siginfo is a different binary format than the 64-bit
one. So, when running 32-bit binaries on 64-bit kernels, we have
to convert the kernel's 64-bit version to a 32-bit version that
userspace can grok.
We've added a few features to siginfo over the past few years and
neglected to add them to arch/x86/kernel/signal_compat.c:
1. The si_addr_lsb used in SIGBUS's sent for machine checks
2. The upper/lower bounds for MPX SIGSEGV faults
3. The protection key for pkey faults
I caught this with some protection keys unit tests and realized
it affected a few more features.
This was tested only with my protection keys patch that looks
for a proper value in si_pkey. I didn't actually test the machine
check or MPX code.
Signed-off-by: Dave Hansen <dave.hansen@linux.intel.com>
Cc: Al Viro <viro@zeniv.linux.org.uk>
Cc: Andy Lutomirski <luto@kernel.org>
Cc: Borislav Petkov <bp@alien8.de>
Cc: Brian Gerst <brgerst@gmail.com>
Cc: Dave Hansen <dave@sr71.net>
Cc: Denys Vlasenko <dvlasenk@redhat.com>
Cc: H. Peter Anvin <hpa@zytor.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Oleg Nesterov <oleg@redhat.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Tony Luck <tony.luck@intel.com>
Cc: linux-edac@vger.kernel.org
Link: http://lkml.kernel.org/r/20160608172533.F8F05637@viggo.jf.intel.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
sigreturn.S was historically included by the various
__kernel_vsyscall implementations due to assumptions about all the
32-bit vDSO images having the sigreturn symbols at the same address.
Those assumptions were removed in v3.16, and as of v4.4, there is only
a single 32-bit vDSO left.
Simplify the build process by assembling sigreturn.S into a normal
object file.
Signed-off-by: Andy Lutomirski <luto@kernel.org>
Cc: Borislav Petkov <bp@alien8.de>
Cc: Brian Gerst <brgerst@gmail.com>
Cc: Denys Vlasenko <dvlasenk@redhat.com>
Cc: H. Peter Anvin <hpa@zytor.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Link: http://lkml.kernel.org/r/d7b6dfde3c7397aa26977320da90448363b5a7e9.1465505753.git.luto@kernel.org
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Update the contact info for Muli, clean-up my name, and update the
mailing list to the IOMMU mailing list.
Signed-off-by: Jon Mason <jdmason@kudzu.us>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Krzysztof Kozlowski <k.kozlowski@samsung.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Muli Ben-Yehuda <mulix@mulix.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Link: http://lkml.kernel.org/r/1465493059-11840-2-git-send-email-jdmason@kudzu.us
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Fix kprobe_fault_handler() to clear the TF (trap flag) bit of
the flags register in the case of a fault fixup on single-stepping.
If we put a kprobe on the instruction which caused a
page fault (e.g. actual mov instructions in copy_user_*),
that fault happens on the single-stepping buffer. In this
case, kprobes resets running instance so that the CPU can
retry execution on the original ip address.
However, current code forgets to reset the TF bit. Since this
fault happens with TF bit set for enabling single-stepping,
when it retries, it causes a debug exception and kprobes
can not handle it because it already reset itself.
On the most of x86-64 platform, it can be easily reproduced
by using kprobe tracer. E.g.
# cd /sys/kernel/debug/tracing
# echo p copy_user_enhanced_fast_string+5 > kprobe_events
# echo 1 > events/kprobes/enable
And you'll see a kernel panic on do_debug(), since the debug
trap is not handled by kprobes.
To fix this problem, we just need to clear the TF bit when
resetting running kprobe.
Signed-off-by: Masami Hiramatsu <mhiramat@kernel.org>
Reviewed-by: Ananth N Mavinakayanahalli <ananth@linux.vnet.ibm.com>
Acked-by: Steven Rostedt <rostedt@goodmis.org>
Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
Cc: Andy Lutomirski <luto@kernel.org>
Cc: Arnaldo Carvalho de Melo <acme@redhat.com>
Cc: Borislav Petkov <bp@alien8.de>
Cc: Brian Gerst <brgerst@gmail.com>
Cc: Denys Vlasenko <dvlasenk@redhat.com>
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>
Cc: Vince Weaver <vincent.weaver@maine.edu>
Cc: systemtap@sourceware.org
Cc: stable@vger.kernel.org # All the way back to ancient kernels
Link: http://lkml.kernel.org/r/20160611140648.25885.37482.stgit@devbox
[ Updated the comments. ]
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Even with spin_unlock_wait() fixed, nf_conntrack_lock{,_all}() is
borken as it misses a bunch of memory barriers to order the whole
global vs local locks scheme.
Even x86 (and other TSO archs) are affected.
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
[ Updated the comments. ]
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: David S. Miller <davem@davemloft.net>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Ingo Molnar <mingo@kernel.org>
With the modified semantics of spin_unlock_wait() a number of
explicit barriers can be removed. Also update the comment for the
do_exit() usecase, as that was somewhat stale/obscure.
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Ingo Molnar <mingo@kernel.org>
This patch updates/fixes all spin_unlock_wait() implementations.
The update is in semantics; where it previously was only a control
dependency, we now upgrade to a full load-acquire to match the
store-release from the spin_unlock() we waited on. This ensures that
when spin_unlock_wait() returns, we're guaranteed to observe the full
critical section we waited on.
This fixes a number of spin_unlock_wait() users that (not
unreasonably) rely on this.
I also fixed a number of ticket lock versions to only wait on the
current lock holder, instead of for a full unlock, as this is
sufficient.
Furthermore; again for ticket locks; I added an smp_rmb() in between
the initial ticket load and the spin loop testing the current value
because I could not convince myself the address dependency is
sufficient, esp. if the loads are of different sizes.
I'm more than happy to remove this smp_rmb() again if people are
certain the address dependency does indeed work as expected.
Note: PPC32 will be fixed independently
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: chris@zankel.net
Cc: cmetcalf@mellanox.com
Cc: davem@davemloft.net
Cc: dhowells@redhat.com
Cc: james.hogan@imgtec.com
Cc: jejb@parisc-linux.org
Cc: linux@armlinux.org.uk
Cc: mpe@ellerman.id.au
Cc: ralf@linux-mips.org
Cc: realmz6@gmail.com
Cc: rkuo@codeaurora.org
Cc: rth@twiddle.net
Cc: schwidefsky@de.ibm.com
Cc: tony.luck@intel.com
Cc: vgupta@synopsys.com
Cc: ysato@users.sourceforge.jp
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Since TILE doesn't do read speculation, its control dependencies also
guarantee LOAD->LOAD order and we don't need the additional RMB
otherwise required to provide ACQUIRE semantics.
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Acked-by: Chris Metcalf <cmetcalf@mellanox.com>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Since all asm/barrier.h should/must include asm-generic/barrier.h the
latter is a good place for generic infrastructure like this.
This also allows archs to override the new smp_acquire__after_ctrl_dep().
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Introduce smp_acquire__after_ctrl_dep(), this construct is not
uncommon, but the lack of this barrier is.
Use it to better express smp_rmb() uses in WRITE_ONCE(), the IPC
semaphore code and the qspinlock code.
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Ingo Molnar <mingo@kernel.org>
This new form allows using hardware assisted waiting.
Some hardware (ARM64 and x86) allow monitoring an address for changes,
so by providing a pointer we can use this to replace the cpu_relax()
with hardware optimized methods in the future.
Requested-by: Will Deacon <will.deacon@arm.com>
Suggested-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Ingo Molnar <mingo@kernel.org>
This is a WA affecting pooled eu which is a bxt specific feature.
Reviewed-by: Mika Kuoppala <mika.kuoppala@intel.com>
Cc: Winiarski, Michal <michal.winiarski@intel.com>
Cc: Zou, Nanhai <nanhai.zou@intel.com>
Cc: Yang, Rong R <rong.r.yang@intel.com>
Cc: Jeff McGee <jeff.mcgee@intel.com>
Signed-off-by: Arun Siluvery <arun.siluvery@linux.intel.com>
Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
