Borislav Petkov [Wed, 2 Nov 2016 18:35:22 +0000 (19:35 +0100)]
x86/msr: Cleanup/streamline MSR helpers
Make the MSR argument an unsigned int, both low and high u32, put
"notrace" last in the function signature. Reflow function signatures for
better readability and cleanup white space.
Signed-off-by: Borislav Petkov <bp@suse.de>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Wanpeng Li [Mon, 7 Nov 2016 03:13:40 +0000 (11:13 +0800)]
x86/apic: Prevent tracing on apic_msr_write_eoi()
The following RCU lockdep warning led to adding irq_enter()/irq_exit() into
smp_reschedule_interrupt():
RCU used illegally from idle CPU!
rcu_scheduler_active = 1, debug_locks = 0
RCU used illegally from extended quiescent state!
no locks held by swapper/1/0.
do_trace_write_msr
native_write_msr
native_apic_msr_eoi_write
smp_reschedule_interrupt
reschedule_interrupt
As Peterz pointed out:
| So now we're making a very frequent interrupt slower because of debug
| code.
|
| The thing is, many many smp_reschedule_interrupt() invocations don't
| actually execute anything much at all and are only sent to tickle the
| return to user path (which does the actual preemption).
|
| Having to do the whole irq_enter/irq_exit dance just for this unlikely
| debug case totally blows.
Use the wrmsr_notrace() variant in native_apic_msr_write_eoi, annotate the
kvm variant with notrace and add a native_apic_eoi callback to the apic
structure so KVM guests are covered as well.
This allows to revert the irq_enter/irq_exit dance in
smp_reschedule_interrupt().
Suggested-by: Peter Zijlstra <peterz@infradead.org>
Suggested-by: Paolo Bonzini <pbonzini@redhat.com>
Signed-off-by: Wanpeng Li <wanpeng.li@hotmail.com>
Acked-by: Paolo Bonzini <pbonzini@redhat.com>
Cc: kvm@vger.kernel.org
Cc: Mike Galbraith <efault@gmx.de>
Cc: Borislav Petkov <bp@alien8.de>
Link: http://lkml.kernel.org/r/1478488420-5982-3-git-send-email-wanpeng.li@hotmail.com
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Wanpeng Li [Mon, 7 Nov 2016 03:13:39 +0000 (11:13 +0800)]
x86/msr: Add wrmsr_notrace()
Required to remove the extra irq_enter()/irq_exit() in
smp_reschedule_interrupt().
Suggested-by: Peter Zijlstra <peterz@infradead.org>
Suggested-by: Paolo Bonzini <pbonzini@redhat.com>
Signed-off-by: Wanpeng Li <wanpeng.li@hotmail.com>
Acked-by: Paolo Bonzini <pbonzini@redhat.com>
Reviewed-by: Borislav Petkov <bp@alien8.de>
Cc: kvm@vger.kernel.org
Cc: Mike Galbraith <efault@gmx.de>
Link: http://lkml.kernel.org/r/1478488420-5982-2-git-send-email-wanpeng.li@hotmail.com
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Sebastian Andrzej Siewior [Fri, 21 Oct 2016 08:44:49 +0000 (10:44 +0200)]
x86/apic: Get rid of "warning: 'acpi_ioapic_lock' defined but not used"
kbuild test robot reported this against the -RT tree:
|>> arch/x86/kernel/acpi/boot.c:90:21: warning: 'acpi_ioapic_lock' defined but not used [-Wunused-variable]
| static DEFINE_MUTEX(acpi_ioapic_lock);
| ^
| include/linux/mutex_rt.h:27:15: note: in definition of macro 'DEFINE_MUTEX'
| struct mutex mutexname = __MUTEX_INITIALIZER(mutexname)
^~~~~~~~~
which is also true (as in non-used) for !RT but the compiler does not
emit a warning.
Reported-by: kbuild test robot <fengguang.wu@intel.com>
Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
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/20161021084449.32523-1-bigeasy@linutronix.de
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Linus Torvalds [Thu, 20 Oct 2016 22:32:51 +0000 (15:32 -0700)]
Merge tag 'pm-4.9-rc2' of git://git./linux/kernel/git/rafael/linux-pm
Pull power management fix from Rafael Wysocki:
"This fixes the pointer arithmetics mess-up in the cpufreq core
introduced by one of recent commits and leading to all kinds of
breakage from kernel crashes to incorrect governor decisions (Sergey
Senozhatsky)"
* tag 'pm-4.9-rc2' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm:
cpufreq: fix overflow in cpufreq_table_find_index_dl()
Rafael J. Wysocki [Thu, 20 Oct 2016 21:24:58 +0000 (23:24 +0200)]
Merge branch 'pm-cpufreq'
* pm-cpufreq:
cpufreq: fix overflow in cpufreq_table_find_index_dl()
Linus Torvalds [Thu, 20 Oct 2016 17:17:13 +0000 (10:17 -0700)]
Merge tag 'arm64-fixes' of git://git./linux/kernel/git/arm64/linux
Pull arm64 fixes from Will Deacon:
"Most of these are CC'd for stable, but there are a few fixing issues
introduced during the recent merge window too.
There's also a fix for the xgene PMU driver, but it seemed daft to
send as a separate pull request, so I've included it here with the
rest of the fixes.
- Fix ACPI boot due to recent broken NUMA changes
- Fix remote enabling of CPU features requiring PSTATE bit manipulation
- Add address range check when emulating user cache maintenance
- Fix LL/SC loops that allow compiler to introduce memory accesses
- Fix recently added write_sysreg_s macro
- Ensure MDCR_EL2 is initialised on qemu targets without a PMU
- Avoid kaslr breakage due to MODVERSIONs and DYNAMIC_FTRACE
- Correctly drive recent ld when building relocatable Image
- Remove junk IS_ERR check from xgene PMU driver added during merge window
- pr_cont fixes after core changes in the merge window"
* tag 'arm64-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux:
arm64: remove pr_cont abuse from mem_init
arm64: fix show_regs fallout from KERN_CONT changes
arm64: kernel: force ET_DYN ELF type for CONFIG_RELOCATABLE=y
arm64: suspend: Reconfigure PSTATE after resume from idle
arm64: mm: Set PSTATE.PAN from the cpu_enable_pan() call
arm64: cpufeature: Schedule enable() calls instead of calling them via IPI
arm64: Cortex-A53 errata workaround: check for kernel addresses
arm64: percpu: rewrite ll/sc loops in assembly
arm64: swp emulation: bound LL/SC retries before rescheduling
arm64: sysreg: Fix use of XZR in write_sysreg_s
arm64: kaslr: keep modules close to the kernel when DYNAMIC_FTRACE=y
arm64: kernel: Init MDCR_EL2 even in the absence of a PMU
perf: xgene: Remove bogus IS_ERR() check
arm64: kernel: numa: fix ACPI boot cpu numa node mapping
arm64: kaslr: fix breakage with CONFIG_MODVERSIONS=y
Linus Torvalds [Thu, 20 Oct 2016 16:57:51 +0000 (09:57 -0700)]
Merge tag 'ceph-for-4.9-rc2' of git://github.com/ceph/ceph-client
Pull Ceph fixes from Ilya Dryomov:
"An rbd exclusive-lock edge case fix and several filesystem fixups.
Nikolay's error path patch is tagged for stable, everything else but
readdir vs frags race was introduced in this merge window"
* tag 'ceph-for-4.9-rc2' of git://github.com/ceph/ceph-client:
ceph: fix non static symbol warning
ceph: fix uninitialized dentry pointer in ceph_real_mount()
ceph: fix readdir vs fragmentation race
ceph: fix error handling in ceph_read_iter
rbd: don't retry watch reregistration if header object is gone
rbd: don't wait for the lock forever if blacklisted
Linus Torvalds [Thu, 20 Oct 2016 15:59:12 +0000 (08:59 -0700)]
Merge tag 'mmc-v4.9-rc1' of git://git./linux/kernel/git/ulfh/mmc
Pull MMC fixes from Ulf Hansson:
"Here are some mmc fixes intended for v4.9 rc2.
This time I have also included a few changes for a memstick driver
which has a corresponding mmc driver. They use the same USB device as
parent, hence both needs to play nice with runtime PM, which they
didn't.
MMC core:
- Update MAINTAINERS as the mmc tree moved to kernel.org
- A few fixes for HS400es mode
- A few other minor fixes
MMC host:
- sdhci: Fix an issue when dealing with stop commands
- sdhci-pci: Fix a bus power failure issue
- sdhci-esdhc-imx: Correct two register accesses
- sdhci-of-arasan: Fix the 1.8V I/O signal switch behaviour
- rtsx_usb_sdmmc: Fix runtime PM issues
Other: (Because of no maintainer)
- memstick: rtsx_usb_ms: Fix runtime PM issues"
* tag 'mmc-v4.9-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/ulfh/mmc:
MAINTAINERS: mmc: Move the mmc tree to kernel.org
memstick: rtsx_usb_ms: Manage runtime PM when accessing the device
memstick: rtsx_usb_ms: Runtime resume the device when polling for cards
mmc: rtsx_usb_sdmmc: Handle runtime PM while changing the led
mmc: rtsx_usb_sdmmc: Avoid keeping the device runtime resumed when unused
mmc: sdhci: cast unsigned int to unsigned long long to avoid unexpeted error
mmc: sdhci-esdhc-imx: Correct two register accesses
mmc: sdhci-pci: Fix bus power failing to enable for some Intel controllers
mmc: sdhci-pci: Let devices define their own sdhci_ops
mmc: sdhci: Rename sdhci_set_power() to sdhci_set_power_noreg()
mmc: sdhci: Fix SDHCI_QUIRK2_STOP_WITH_TC
mmc: core: Annotate cmd_hdr as __le32
mmc: sdhci-of-arasan: add sdhci_arasan_voltage_switch for arasan, 5.1
mmc: core: changes frequency to hs_max_dtr when selecting hs400es
mmc: core: switch to 1V8 or 1V2 for hs400es mode
mmc: block: add missing header dependencies
mmc: sdhci-of-arasan: Fix non static symbol warning
Linus Torvalds [Thu, 20 Oct 2016 15:49:03 +0000 (08:49 -0700)]
Merge branch 'for_linus' of git://git./linux/kernel/git/jack/linux-fs
Pull misc filesystem fixes from Jan Kara:
"A fix for an isofs change apparently breaking mount(8) in some cases
and one ext2 warning fix"
* 'for_linus' of git://git.kernel.org/pub/scm/linux/kernel/git/jack/linux-fs:
ext2: avoid bogus -Wmaybe-uninitialized warning
isofs: Do not return EACCES for unknown filesystems
Sergey Senozhatsky [Mon, 17 Oct 2016 15:41:12 +0000 (00:41 +0900)]
cpufreq: fix overflow in cpufreq_table_find_index_dl()
'best' is always less or equals to 'pos', so `best - pos' returns
a negative value which is then getting casted to `unsigned int'
and passed to __cpufreq_driver_target()->acpi_cpufreq_target()
for policy->freq_table selection. This results in
BUG: unable to handle kernel paging request at
ffff881019b469f8
IP: [<
ffffffffa00356c1>] acpi_cpufreq_target+0x4f/0x190 [acpi_cpufreq]
PGD
267f067
PUD 0
Oops: 0000 [#1] PREEMPT SMP
CPU: 6 PID: 70 Comm: kworker/6:1 Not tainted 4.9.0-rc1-next-
20161017-dbg-dirty
Workqueue: events dbs_work_handler
task:
ffff88041b808000 task.stack:
ffff88041b810000
RIP: 0010:[<
ffffffffa00356c1>] [<
ffffffffa00356c1>] acpi_cpufreq_target+0x4f/0x190 [acpi_cpufreq]
RSP: 0018:
ffff88041b813c60 EFLAGS:
00010282
RAX:
ffff880419b46a00 RBX:
ffff88041b848400 RCX:
ffff880419b20f80
RDX:
00000000001dff38 RSI:
00000000ffffffff RDI:
ffff88041b848400
RBP:
ffff88041b813cb0 R08:
0000000000000006 R09:
0000000000000040
R10:
ffffffff8207f9e0 R11:
ffffffff8173595b R12:
0000000000000000
R13:
ffff88041f1dff38 R14:
0000000000262900 R15:
0000000bfffffff4
FS:
0000000000000000(0000) GS:
ffff88041f000000(0000) knlGS:
0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0:
0000000080050033
CR2:
ffff881019b469f8 CR3:
000000041a2d3000 CR4:
00000000001406e0
Stack:
ffff88041b813cb0 ffffffff813347f9 ffff88041b813ca0 ffffffff81334663
ffff88041f1d4bc0 ffff88041b848400 0000000000000000 0000000000000000
0000000000262900 0000000000000000 ffff88041b813d00 ffffffff813355dc
Call Trace:
[<
ffffffff813347f9>] ? cpufreq_freq_transition_begin+0xf1/0xfc
[<
ffffffff81334663>] ? get_cpu_idle_time+0x97/0xa6
[<
ffffffff813355dc>] __cpufreq_driver_target+0x3b6/0x44e
[<
ffffffff81336ca3>] cs_dbs_timer+0x11a/0x135
[<
ffffffff81336fda>] dbs_work_handler+0x39/0x62
[<
ffffffff81057823>] process_one_work+0x280/0x4a5
[<
ffffffff81058719>] worker_thread+0x24f/0x397
[<
ffffffff810584ca>] ? rescuer_thread+0x30b/0x30b
[<
ffffffff81418380>] ? nl80211_get_key+0x29/0x36a
[<
ffffffff8105d2b7>] kthread+0xfc/0x104
[<
ffffffff8107ceea>] ? put_lock_stats.isra.9+0xe/0x20
[<
ffffffff8105d1bb>] ? kthread_create_on_node+0x3f/0x3f
[<
ffffffff814b2092>] ret_from_fork+0x22/0x30
Code: 56 4d 6b ff 0c 41 55 41 54 53 48 83 ec 28 48 8b 15 ad 1e 00 00 44 8b 41
08 48 8b 87 c8 00 00 00 49 89 d5 4e 03 2c c5 80 b2 78 81 <46> 8b 74 38 04 45
3b 75 00 75 11 31 c0 83 39 00 0f 84 1c 01 00
RIP [<
ffffffffa00356c1>] acpi_cpufreq_target+0x4f/0x190 [acpi_cpufreq]
RSP <
ffff88041b813c60>
CR2:
ffff881019b469f8
---[ end trace
16d9fc7a17897d37 ]---
[ rjw: In some cases this bug may also cause incorrect frequencies to
be selected by cpufreq governors. ]
Fixes:
899bb6642f2a (cpufreq: skip invalid entries when searching the frequency)
Link: http://marc.info/?l=linux-kernel&m=147672030714331&w=2
Reported-and-tested-by: Sedat Dilek <sedat.dilek@gmail.com>
Reported-and-tested-by: Jörg Otte <jrg.otte@gmail.com>
Signed-off-by: Sergey Senozhatsky <sergey.senozhatsky@gmail.com>
Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
Cc: 4.8+ <stable@vger.kernel.org> # 4.8+
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Mark Rutland [Thu, 20 Oct 2016 11:24:53 +0000 (12:24 +0100)]
arm64: remove pr_cont abuse from mem_init
All the lines printed by mem_init are independent, with each ending with
a newline. While they logically form a large block, none are actually
continuations of previous lines.
The kernel-side printk code and the userspace demsg tool differ in their
handling of KERN_CONT following a newline, and while this isn't always a
problem kernel-side, it does cause difficulty for userspace. Using
pr_cont causes the userspace tool to not print line prefix (e.g.
timestamps) even when following a newline, mis-aligning the output and
making it harder to read, e.g.
[ 0.000000] Virtual kernel memory layout:
[ 0.000000] modules : 0xffff000000000000 - 0xffff000008000000 ( 128 MB)
vmalloc : 0xffff000008000000 - 0xffff7dffbfff0000 (129022 GB)
.text : 0xffff000008080000 - 0xffff0000088b0000 ( 8384 KB)
.rodata : 0xffff0000088b0000 - 0xffff000008c50000 ( 3712 KB)
.init : 0xffff000008c50000 - 0xffff000008d50000 ( 1024 KB)
.data : 0xffff000008d50000 - 0xffff000008e25200 ( 853 KB)
.bss : 0xffff000008e25200 - 0xffff000008e6bec0 ( 284 KB)
fixed : 0xffff7dfffe7fd000 - 0xffff7dfffec00000 ( 4108 KB)
PCI I/O : 0xffff7dfffee00000 - 0xffff7dffffe00000 ( 16 MB)
vmemmap : 0xffff7e0000000000 - 0xffff800000000000 ( 2048 GB maximum)
0xffff7e0000000000 - 0xffff7e0026000000 ( 608 MB actual)
memory : 0xffff800000000000 - 0xffff800980000000 ( 38912 MB)
[ 0.000000] SLUB: HWalign=64, Order=0-3, MinObjects=0, CPUs=6, Nodes=1
Fix this by using pr_notice consistently for all lines, which both the
kernel and userspace are happy with.
Signed-off-by: Mark Rutland <mark.rutland@arm.com>
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: James Morse <james.morse@arm.com>
Cc: Kefeng Wang <wangkefeng.wang@huawei.com>
Cc: Will Deacon <will.deacon@arm.com>
Signed-off-by: Will Deacon <will.deacon@arm.com>
Mark Rutland [Thu, 20 Oct 2016 11:23:16 +0000 (12:23 +0100)]
arm64: fix show_regs fallout from KERN_CONT changes
Recently in commit
4bcc595ccd80decb ("printk: reinstate KERN_CONT for
printing continuation lines"), the behaviour of printk changed w.r.t.
KERN_CONT. Now, KERN_CONT is mandatory to continue existing lines.
Without this, prefixes are inserted, making output illegible, e.g.
[ 1007.069010] pc : [<
ffff00000871898c>] lr : [<
ffff000008718948>] pstate:
40000145
[ 1007.076329] sp :
ffff000008d53ec0
[ 1007.079606] x29:
ffff000008d53ec0 [ 1007.082797] x28:
0000000080c50018
[ 1007.086160]
[ 1007.087630] x27:
ffff000008e0c7f8 [ 1007.090820] x26:
ffff80097631ca00
[ 1007.094183]
[ 1007.095653] x25:
0000000000000001 [ 1007.098843] x24:
000000ea68b61cac
[ 1007.102206]
... or when dumped with the userpace dmesg tool, which has slightly
different implicit newline behaviour. e.g.
[ 1007.069010] pc : [<
ffff00000871898c>] lr : [<
ffff000008718948>] pstate:
40000145
[ 1007.076329] sp :
ffff000008d53ec0
[ 1007.079606] x29:
ffff000008d53ec0
[ 1007.082797] x28:
0000000080c50018
[ 1007.086160]
[ 1007.087630] x27:
ffff000008e0c7f8
[ 1007.090820] x26:
ffff80097631ca00
[ 1007.094183]
[ 1007.095653] x25:
0000000000000001
[ 1007.098843] x24:
000000ea68b61cac
[ 1007.102206]
We can't simply always use KERN_CONT for lines which may or may not be
continuations. That causes line prefixes (e.g. timestamps) to be
supressed, and the alignment of all but the first line will be broken.
For even more fun, we can't simply insert some dummy empty-string printk
calls, as GCC warns for an empty printk string, and even if we pass
KERN_DEFAULT explcitly to silence the warning, the prefix gets swallowed
unless there is an additional part to the string.
Instead, we must manually iterate over pairs of registers, which gives
us the legible output we want in either case, e.g.
[ 169.771790] pc : [<
ffff00000871898c>] lr : [<
ffff000008718948>] pstate:
40000145
[ 169.779109] sp :
ffff000008d53ec0
[ 169.782386] x29:
ffff000008d53ec0 x28:
0000000080c50018
[ 169.787650] x27:
ffff000008e0c7f8 x26:
ffff80097631de00
[ 169.792913] x25:
0000000000000001 x24:
00000027827b2cf4
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>
Ard Biesheuvel [Thu, 20 Oct 2016 10:12:57 +0000 (11:12 +0100)]
arm64: kernel: force ET_DYN ELF type for CONFIG_RELOCATABLE=y
GNU ld used to set the ELF file type to ET_DYN for PIE executables, which
is the same file type used for shared libraries. However, this was changed
recently, and now PIE executables are emitted as ET_EXEC instead.
The distinction is only relevant for ELF loaders, and so there is little
reason to care about the difference when building the kernel, which is
why the change has gone unnoticed until now.
However, debuggers do use the ELF binary, and expect ET_EXEC type files
to appear in memory at the exact offset described in the ELF metadata.
This means source level debugging is no longer possible when KASLR is in
effect or when executing the stub.
So add the -shared LD option when building with CONFIG_RELOCATABLE=y. This
forces the ELF file type to be set to ET_DYN (which is what you get when
building with binutils 2.24 and earlier anyway), and has no other ill
effects.
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Signed-off-by: Will Deacon <will.deacon@arm.com>
James Morse [Tue, 18 Oct 2016 10:27:48 +0000 (11:27 +0100)]
arm64: suspend: Reconfigure PSTATE after resume from idle
The suspend/resume path in kernel/sleep.S, as used by cpu-idle, does not
save/restore PSTATE. As a result of this cpufeatures that were detected
and have bits in PSTATE get lost when we resume from idle.
UAO gets set appropriately on the next context switch. PAN will be
re-enabled next time we return from user-space, but on a preemptible
kernel we may run work accessing user space before this point.
Add code to re-enable theses two features in __cpu_suspend_exit().
We re-use uao_thread_switch() passing current.
Signed-off-by: James Morse <james.morse@arm.com>
Cc: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Signed-off-by: Will Deacon <will.deacon@arm.com>
James Morse [Tue, 18 Oct 2016 10:27:47 +0000 (11:27 +0100)]
arm64: mm: Set PSTATE.PAN from the cpu_enable_pan() call
Commit
338d4f49d6f7 ("arm64: kernel: Add support for Privileged Access
Never") enabled PAN by enabling the 'SPAN' feature-bit in SCTLR_EL1.
This means the PSTATE.PAN bit won't be set until the next return to the
kernel from userspace. On a preemptible kernel we may schedule work that
accesses userspace on a CPU before it has done this.
Now that cpufeature enable() calls are scheduled via stop_machine(), we
can set PSTATE.PAN from the cpu_enable_pan() call.
Add WARN_ON_ONCE(in_interrupt()) to check the PSTATE value we updated
is not immediately discarded.
Reported-by: Tony Thompson <anthony.thompson@arm.com>
Reported-by: Vladimir Murzin <vladimir.murzin@arm.com>
Signed-off-by: James Morse <james.morse@arm.com>
[will: fixed typo in comment]
Signed-off-by: Will Deacon <will.deacon@arm.com>
James Morse [Tue, 18 Oct 2016 10:27:46 +0000 (11:27 +0100)]
arm64: cpufeature: Schedule enable() calls instead of calling them via IPI
The enable() call for a cpufeature/errata is called using on_each_cpu().
This issues a cross-call IPI to get the work done. Implicitly, this
stashes the running PSTATE in SPSR when the CPU receives the IPI, and
restores it when we return. This means an enable() call can never modify
PSTATE.
To allow PAN to do this, change the on_each_cpu() call to use
stop_machine(). This schedules the work on each CPU which allows
us to modify PSTATE.
This involves changing the protype of all the enable() functions.
enable_cpu_capabilities() is called during boot and enables the feature
on all online CPUs. This path now uses stop_machine(). CPU features for
hotplug'd CPUs are enabled by verify_local_cpu_features() which only
acts on the local CPU, and can already modify the running PSTATE as it
is called from secondary_start_kernel().
Reported-by: Tony Thompson <anthony.thompson@arm.com>
Reported-by: Vladimir Murzin <vladimir.murzin@arm.com>
Signed-off-by: James Morse <james.morse@arm.com>
Cc: Suzuki K Poulose <suzuki.poulose@arm.com>
Signed-off-by: Will Deacon <will.deacon@arm.com>
Andre Przywara [Wed, 19 Oct 2016 13:40:54 +0000 (14:40 +0100)]
arm64: Cortex-A53 errata workaround: check for kernel addresses
Commit
7dd01aef0557 ("arm64: trap userspace "dc cvau" cache operation on
errata-affected core") adds code to execute cache maintenance instructions
in the kernel on behalf of userland on CPUs with certain ARM CPU errata.
It turns out that the address hasn't been checked to be a valid user
space address, allowing userland to clean cache lines in kernel space.
Fix this by introducing an address check before executing the
instructions on behalf of userland.
Since the address doesn't come via a syscall parameter, we can't just
reject tagged pointers and instead have to remove the tag when checking
against the user address limit.
Cc: <stable@vger.kernel.org>
Fixes:
7dd01aef0557 ("arm64: trap userspace "dc cvau" cache operation on errata-affected core")
Reported-by: Kristina Martsenko <kristina.martsenko@arm.com>
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
[will: rework commit message + replace access_ok with max_user_addr()]
Signed-off-by: Will Deacon <will.deacon@arm.com>
Linus Torvalds [Wed, 19 Oct 2016 18:45:06 +0000 (11:45 -0700)]
Merge tag 'platform-drivers-x86-v4.9-2' of git://git.infradead.org/users/dvhart/linux-platform-drivers-x86
Pull x86 platform driver fixes from Darren Hart:
"Fix a Kconfig issue leading potential link failure, and add a DMI
match for an existing quirk.
asus-wmi:
- add SERIO_I8042 dependency
ideapad-laptop:
- Add Lenovo Yoga 910-13IKB to no_hw_rfkill dmi list"
* tag 'platform-drivers-x86-v4.9-2' of git://git.infradead.org/users/dvhart/linux-platform-drivers-x86:
platform/x86: asus-wmi: add SERIO_I8042 dependency
platform/x86: ideapad-laptop: Add Lenovo Yoga 910-13IKB to no_hw_rfkill dmi list
Linus Torvalds [Wed, 19 Oct 2016 18:21:06 +0000 (11:21 -0700)]
Merge tag 'sh-for-4.9' of git://git.libc.org/linux-sh
Pull arch/sh updates from Rich Felker:
"Minor changes to improve J2 support and match Kconfig expectations of
other subsystems"
* tag 'sh-for-4.9' of git://git.libc.org/linux-sh:
sh: add earlycon support to j2_defconfig
sh: add Kconfig option for J-Core SoC core drivers
sh: support CPU_J2 when compiler lacks -mj2
Linus Torvalds [Wed, 19 Oct 2016 17:03:55 +0000 (10:03 -0700)]
Merge branch 'sched-urgent-for-linus' of git://git./linux/kernel/git/tip/tip
Pull scheduler fix from Ingo Molnar:
"This fixes a group scheduling related performance/interactivity
regression introduced in v4.8, which affects certain hardware
environments where cpu_possible_mask != cpu_present_mask"
* 'sched-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
sched/fair: Fix incorrect task group ->load_avg
Linus Torvalds [Wed, 19 Oct 2016 16:56:57 +0000 (09:56 -0700)]
Merge branch 'for-linus' of git://git./linux/kernel/git/jikos/hid
Pull HID fixes from Jiri Kosina:
- hid-dr regression fix for certain dragonrise gamepads (device ID
0079:0006), from Ioan-Adrian Ratiu
- dma-on-stack fix for hid-led driver, from Heiner Kallweit
- quirk for Akai MIDImix device
* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/jikos/hid:
HID: add quirk for Akai MIDImix.
Revert "HID: dragonrise: fix HID Descriptor for 0x0006 PID"
HID: hid-dr: add input mapping for axis selection
HID: hid-led: fix issue with transfer buffer not being dma capable
Linus Torvalds [Wed, 19 Oct 2016 16:17:29 +0000 (09:17 -0700)]
Merge tag 'pinctrl-v4.9-2' of git://git./linux/kernel/git/linusw/linux-pinctrl
Pull first round of pin control fixes from Linus Walleij:
- a bunch of barnsjukdomar/kinderkrankheiten/maladie infantile in the
Aspeed driver. (Why doesn't English have a word for this?)
[ Maybe "teething problems" is the closest English idiom? - Linus T ]
- fix a lockdep bug on the Intel BayTrail.
- fix a few special laptop issues on the Intel pin controller solving
suspend issues.
* tag 'pinctrl-v4.9-2' of git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-pinctrl:
pinctrl: intel: Only restore pins that are used by the driver
pinctrl: baytrail: Fix lockdep
pinctrl: aspeed-g5: Fix pin association of SPI1 function
pinctrl: aspeed-g5: Fix GPIOE1 typo
pinctrl: aspeed-g5: Fix names of GPID2 pins
pinctrl: aspeed: "Not enabled" is a significant mux state
Linus Torvalds [Wed, 19 Oct 2016 16:11:24 +0000 (09:11 -0700)]
printk: suppress empty continuation lines
We have a fairly common pattern where you print several things as
continuations on one single line in a loop, and then at the end you do
printk(KERN_CONT "\n");
to flush the buffered output.
But if the output was flushed by something else (concurrent printk
activity, or just system logging), we don't want that final flushing to
just print an empty line.
So just suppress empty continuation lines when they couldn't be merged
into the line they are a continuation of.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Linus Torvalds [Wed, 19 Oct 2016 15:39:47 +0000 (08:39 -0700)]
Merge branch 'gup_flag-cleanups'
Merge the gup_flags cleanups from Lorenzo Stoakes:
"This patch series adjusts functions in the get_user_pages* family such
that desired FOLL_* flags are passed as an argument rather than
implied by flags.
The purpose of this change is to make the use of FOLL_FORCE explicit
so it is easier to grep for and clearer to callers that this flag is
being used. The use of FOLL_FORCE is an issue as it overrides missing
VM_READ/VM_WRITE flags for the VMA whose pages we are reading
from/writing to, which can result in surprising behaviour.
The patch series came out of the discussion around commit
38e088546522
("mm: check VMA flags to avoid invalid PROT_NONE NUMA balancing"),
which addressed a BUG_ON() being triggered when a page was faulted in
with PROT_NONE set but having been overridden by FOLL_FORCE.
do_numa_page() was run on the assumption the page _must_ be one marked
for NUMA node migration as an actual PROT_NONE page would have been
dealt with prior to this code path, however FOLL_FORCE introduced a
situation where this assumption did not hold.
See
https://marc.info/?l=linux-mm&m=
147585445805166
for the patch proposal"
Additionally, there's a fix for an ancient bug related to FOLL_FORCE and
FOLL_WRITE by me.
[ This branch was rebased recently to add a few more acked-by's and
reviewed-by's ]
* gup_flag-cleanups:
mm: replace access_process_vm() write parameter with gup_flags
mm: replace access_remote_vm() write parameter with gup_flags
mm: replace __access_remote_vm() write parameter with gup_flags
mm: replace get_user_pages_remote() write/force parameters with gup_flags
mm: replace get_user_pages() write/force parameters with gup_flags
mm: replace get_vaddr_frames() write/force parameters with gup_flags
mm: replace get_user_pages_locked() write/force parameters with gup_flags
mm: replace get_user_pages_unlocked() write/force parameters with gup_flags
mm: remove write/force parameters from __get_user_pages_unlocked()
mm: remove write/force parameters from __get_user_pages_locked()
mm: remove gup_flags FOLL_WRITE games from __get_user_pages()
Lorenzo Stoakes [Thu, 13 Oct 2016 00:20:20 +0000 (01:20 +0100)]
mm: replace access_process_vm() write parameter with gup_flags
This removes the 'write' argument from access_process_vm() and replaces
it with 'gup_flags' as use of this function previously silently implied
FOLL_FORCE, whereas after this patch callers explicitly pass this flag.
We make this explicit as use of FOLL_FORCE can result in surprising
behaviour (and hence bugs) within the mm subsystem.
Signed-off-by: Lorenzo Stoakes <lstoakes@gmail.com>
Acked-by: Jesper Nilsson <jesper.nilsson@axis.com>
Acked-by: Michal Hocko <mhocko@suse.com>
Acked-by: Michael Ellerman <mpe@ellerman.id.au>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Lorenzo Stoakes [Thu, 13 Oct 2016 00:20:19 +0000 (01:20 +0100)]
mm: replace access_remote_vm() write parameter with gup_flags
This removes the 'write' argument from access_remote_vm() and replaces
it with 'gup_flags' as use of this function previously silently implied
FOLL_FORCE, whereas after this patch callers explicitly pass this flag.
We make this explicit as use of FOLL_FORCE can result in surprising
behaviour (and hence bugs) within the mm subsystem.
Signed-off-by: Lorenzo Stoakes <lstoakes@gmail.com>
Acked-by: Michal Hocko <mhocko@suse.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Lorenzo Stoakes [Thu, 13 Oct 2016 00:20:18 +0000 (01:20 +0100)]
mm: replace __access_remote_vm() write parameter with gup_flags
This removes the 'write' argument from __access_remote_vm() and replaces
it with 'gup_flags' as use of this function previously silently implied
FOLL_FORCE, whereas after this patch callers explicitly pass this flag.
We make this explicit as use of FOLL_FORCE can result in surprising
behaviour (and hence bugs) within the mm subsystem.
Signed-off-by: Lorenzo Stoakes <lstoakes@gmail.com>
Acked-by: Michal Hocko <mhocko@suse.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Lorenzo Stoakes [Thu, 13 Oct 2016 00:20:17 +0000 (01:20 +0100)]
mm: replace get_user_pages_remote() write/force parameters with gup_flags
This removes the 'write' and 'force' from get_user_pages_remote() and
replaces them with 'gup_flags' to make the use of FOLL_FORCE explicit in
callers as use of this flag can result in surprising behaviour (and
hence bugs) within the mm subsystem.
Signed-off-by: Lorenzo Stoakes <lstoakes@gmail.com>
Acked-by: Michal Hocko <mhocko@suse.com>
Reviewed-by: Jan Kara <jack@suse.cz>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Lorenzo Stoakes [Thu, 13 Oct 2016 00:20:16 +0000 (01:20 +0100)]
mm: replace get_user_pages() write/force parameters with gup_flags
This removes the 'write' and 'force' from get_user_pages() and replaces
them with 'gup_flags' to make the use of FOLL_FORCE explicit in callers
as use of this flag can result in surprising behaviour (and hence bugs)
within the mm subsystem.
Signed-off-by: Lorenzo Stoakes <lstoakes@gmail.com>
Acked-by: Christian König <christian.koenig@amd.com>
Acked-by: Jesper Nilsson <jesper.nilsson@axis.com>
Acked-by: Michal Hocko <mhocko@suse.com>
Reviewed-by: Jan Kara <jack@suse.cz>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Lorenzo Stoakes [Thu, 13 Oct 2016 00:20:15 +0000 (01:20 +0100)]
mm: replace get_vaddr_frames() write/force parameters with gup_flags
This removes the 'write' and 'force' from get_vaddr_frames() and
replaces them with 'gup_flags' to make the use of FOLL_FORCE explicit in
callers as use of this flag can result in surprising behaviour (and
hence bugs) within the mm subsystem.
Signed-off-by: Lorenzo Stoakes <lstoakes@gmail.com>
Acked-by: Michal Hocko <mhocko@suse.com>
Reviewed-by: Jan Kara <jack@suse.cz>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Lorenzo Stoakes [Thu, 13 Oct 2016 00:20:14 +0000 (01:20 +0100)]
mm: replace get_user_pages_locked() write/force parameters with gup_flags
This removes the 'write' and 'force' use from get_user_pages_locked()
and replaces them with 'gup_flags' to make the use of FOLL_FORCE
explicit in callers as use of this flag can result in surprising
behaviour (and hence bugs) within the mm subsystem.
Signed-off-by: Lorenzo Stoakes <lstoakes@gmail.com>
Acked-by: Michal Hocko <mhocko@suse.com>
Reviewed-by: Jan Kara <jack@suse.cz>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Will Deacon [Mon, 4 Jul 2016 16:44:48 +0000 (17:44 +0100)]
arm64: percpu: rewrite ll/sc loops in assembly
Writing the outer loop of an LL/SC sequence using do {...} while
constructs potentially allows the compiler to hoist memory accesses
between the STXR and the branch back to the LDXR. On CPUs that do not
guarantee forward progress of LL/SC loops when faced with memory
accesses to the same ERG (up to 2k) between the failed STXR and the
branch back, we may end up livelocking.
This patch avoids this issue in our percpu atomics by rewriting the
outer loop as part of the LL/SC inline assembly block.
Cc: <stable@vger.kernel.org>
Fixes:
f97fc810798c ("arm64: percpu: Implement this_cpu operations")
Reviewed-by: Mark Rutland <mark.rutland@arm.com>
Tested-by: Mark Rutland <mark.rutland@arm.com>
Signed-off-by: Will Deacon <will.deacon@arm.com>
Will Deacon [Mon, 4 Jul 2016 15:59:43 +0000 (16:59 +0100)]
arm64: swp emulation: bound LL/SC retries before rescheduling
If a CPU does not implement a global monitor for certain memory types,
then userspace can attempt a kernel DoS by issuing SWP instructions
targetting the problematic memory (for example, a framebuffer mapped
with non-cacheable attributes).
The SWP emulation code protects against these sorts of attacks by
checking for pending signals and potentially rescheduling when the STXR
instruction fails during the emulation. Whilst this is good for avoiding
livelock, it harms emulation of legitimate SWP instructions on CPUs
where forward progress is not guaranteed if there are memory accesses to
the same reservation granule (up to 2k) between the failing STXR and
the retry of the LDXR.
This patch solves the problem by retrying the STXR a bounded number of
times (4) before breaking out of the LL/SC loop and looking for
something else to do.
Cc: <stable@vger.kernel.org>
Fixes:
bd35a4adc413 ("arm64: Port SWP/SWPB emulation support from arm")
Reviewed-by: Mark Rutland <mark.rutland@arm.com>
Signed-off-by: Will Deacon <will.deacon@arm.com>
Vincent Guittot [Wed, 19 Oct 2016 12:45:23 +0000 (14:45 +0200)]
sched/fair: Fix incorrect task group ->load_avg
A scheduler performance regression has been reported by Joseph Salisbury,
which he bisected back to:
3d30544f0212 ("sched/fair: Apply more PELT fixes)
The regression triggers when several levels of task groups are involved
(read: SystemD) and cpu_possible_mask != cpu_present_mask.
The root cause is that group entity's load (tg_child->se[i]->avg.load_avg)
is initialized to scale_load_down(se->load.weight). During the creation of
a child task group, its group entities on possible CPUs are attached to
parent's cfs_rq (tg_parent) and their loads are added to the parent's load
(tg_parent->load_avg) with update_tg_load_avg().
But only the load on online CPUs will then be updated to reflect real load,
whereas load on other CPUs will stay at the initial value.
The result is a tg_parent->load_avg that is higher than the real load, the
weight of group entities (tg_parent->se[i]->load.weight) on online CPUs is
smaller than it should be, and the task group gets a less running time than
what it could expect.
( This situation can be detected with /proc/sched_debug. The ".tg_load_avg"
of the task group will be much higher than sum of ".tg_load_avg_contrib"
of online cfs_rqs of the task group. )
The load of group entities don't have to be intialized to something else
than 0 because their load will increase when an entity is attached.
Reported-by: Joseph Salisbury <joseph.salisbury@canonical.com>
Tested-by: Dietmar Eggemann <dietmar.eggemann@arm.com>
Signed-off-by: Vincent Guittot <vincent.guittot@linaro.org>
Acked-by: Peter Zijlstra <a.p.zijlstra@chello.nl>
Cc: <stable@vger.kernel.org> # 4.8.x
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: joonwoop@codeaurora.org
Fixes:
3d30544f0212 ("sched/fair: Apply more PELT fixes)
Link: http://lkml.kernel.org/r/1476881123-10159-1-git-send-email-vincent.guittot@linaro.org
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Rich Felker [Tue, 18 Oct 2016 22:54:56 +0000 (18:54 -0400)]
sh: add earlycon support to j2_defconfig
Signed-off-by: Rich Felker <dalias@libc.org>
Rich Felker [Thu, 13 Oct 2016 19:51:47 +0000 (15:51 -0400)]
sh: add Kconfig option for J-Core SoC core drivers
Signed-off-by: Rich Felker <dalias@libc.org>
Linus Torvalds [Tue, 18 Oct 2016 21:15:23 +0000 (14:15 -0700)]
Merge tag 'for-f2fs-4.9-rc2' of git://git./linux/kernel/git/jaegeuk/f2fs
Pull f2fs bugfix from Jaegeuk Kim:
"This fixes a bug which referenced the wrong pointer, sum_page, in
f2fs_gc. It was newly introduced in 4.9-rc1.
* tag 'for-f2fs-4.9-rc2' of git://git.kernel.org/pub/scm/linux/kernel/git/jaegeuk/f2fs:
f2fs: fix wrong sum_page pointer in f2fs_gc
Lorenzo Stoakes [Thu, 13 Oct 2016 00:20:13 +0000 (01:20 +0100)]
mm: replace get_user_pages_unlocked() write/force parameters with gup_flags
This removes the 'write' and 'force' use from get_user_pages_unlocked()
and replaces them with 'gup_flags' to make the use of FOLL_FORCE
explicit in callers as use of this flag can result in surprising
behaviour (and hence bugs) within the mm subsystem.
Signed-off-by: Lorenzo Stoakes <lstoakes@gmail.com>
Reviewed-by: Jan Kara <jack@suse.cz>
Acked-by: Michal Hocko <mhocko@suse.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Lorenzo Stoakes [Thu, 13 Oct 2016 00:20:12 +0000 (01:20 +0100)]
mm: remove write/force parameters from __get_user_pages_unlocked()
This removes the redundant 'write' and 'force' parameters from
__get_user_pages_unlocked() to make the use of FOLL_FORCE explicit in
callers as use of this flag can result in surprising behaviour (and
hence bugs) within the mm subsystem.
Signed-off-by: Lorenzo Stoakes <lstoakes@gmail.com>
Acked-by: Paolo Bonzini <pbonzini@redhat.com>
Reviewed-by: Jan Kara <jack@suse.cz>
Acked-by: Michal Hocko <mhocko@suse.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Lorenzo Stoakes [Thu, 13 Oct 2016 00:20:11 +0000 (01:20 +0100)]
mm: remove write/force parameters from __get_user_pages_locked()
This removes the redundant 'write' and 'force' parameters from
__get_user_pages_locked() to make the use of FOLL_FORCE explicit in
callers as use of this flag can result in surprising behaviour (and
hence bugs) within the mm subsystem.
Signed-off-by: Lorenzo Stoakes <lstoakes@gmail.com>
Reviewed-by: Jan Kara <jack@suse.cz>
Acked-by: Michal Hocko <mhocko@suse.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Linus Torvalds [Thu, 13 Oct 2016 20:07:36 +0000 (13:07 -0700)]
mm: remove gup_flags FOLL_WRITE games from __get_user_pages()
This is an ancient bug that was actually attempted to be fixed once
(badly) by me eleven years ago in commit
4ceb5db9757a ("Fix
get_user_pages() race for write access") but that was then undone due to
problems on s390 by commit
f33ea7f404e5 ("fix get_user_pages bug").
In the meantime, the s390 situation has long been fixed, and we can now
fix it by checking the pte_dirty() bit properly (and do it better). The
s390 dirty bit was implemented in
abf09bed3cce ("s390/mm: implement
software dirty bits") which made it into v3.9. Earlier kernels will
have to look at the page state itself.
Also, the VM has become more scalable, and what used a purely
theoretical race back then has become easier to trigger.
To fix it, we introduce a new internal FOLL_COW flag to mark the "yes,
we already did a COW" rather than play racy games with FOLL_WRITE that
is very fundamental, and then use the pte dirty flag to validate that
the FOLL_COW flag is still valid.
Reported-and-tested-by: Phil "not Paul" Oester <kernel@linuxace.com>
Acked-by: Hugh Dickins <hughd@google.com>
Reviewed-by: Michal Hocko <mhocko@suse.com>
Cc: Andy Lutomirski <luto@kernel.org>
Cc: Kees Cook <keescook@chromium.org>
Cc: Oleg Nesterov <oleg@redhat.com>
Cc: Willy Tarreau <w@1wt.eu>
Cc: Nick Piggin <npiggin@gmail.com>
Cc: Greg Thelen <gthelen@google.com>
Cc: stable@vger.kernel.org
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Linus Torvalds [Tue, 18 Oct 2016 16:59:04 +0000 (09:59 -0700)]
Merge branch 'x86-urgent-for-linus' of git://git./linux/kernel/git/tip/tip
Pull x86 fixes from Ingo Molnar:
"Misc fixes, plus hw-enablement changes:
- fix persistent RAM handling
- remove pkeys warning
- remove duplicate macro
- fix debug warning in irq handler
- add new 'Knights Mill' CPU related constants and enable the perf bits"
* 'x86-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
perf/x86/intel/uncore: Add Knights Mill CPUID
perf/x86/intel/rapl: Add Knights Mill CPUID
perf/x86/intel: Add Knights Mill CPUID
x86/cpu/intel: Add Knights Mill to Intel family
x86/e820: Don't merge consecutive E820_PRAM ranges
pkeys: Remove easily triggered WARN
x86: Remove duplicate rtit status MSR macro
x86/smp: Add irq_enter/exit() in smp_reschedule_interrupt()
Linus Torvalds [Tue, 18 Oct 2016 16:57:12 +0000 (09:57 -0700)]
Merge branch 'timers-urgent-for-linus' of git://git./linux/kernel/git/tip/tip
Pull timer fixlet from Ingo Molnar:
"Remove an unused variable"
* 'timers-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
alarmtimer: Remove unused but set variable
Linus Torvalds [Tue, 18 Oct 2016 16:53:59 +0000 (09:53 -0700)]
Merge branch 'sched-urgent-for-linus' of git://git./linux/kernel/git/tip/tip
Pull scheduler fix from Ingo Molnar:
"Fix a crash that can trigger when racing with CPU hotplug: we didn't
use sched-domains data structures carefully enough in select_idle_cpu()"
* 'sched-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
sched/fair: Fix sched domains NULL dereference in select_idle_sibling()
Linus Torvalds [Tue, 18 Oct 2016 16:30:18 +0000 (09:30 -0700)]
Merge branch 'perf-urgent-for-linus' of git://git./linux/kernel/git/tip/tip
Pull perf fixes from Ingo Molnar:
"Four tooling fixes, two kprobes KASAN related fixes and an x86 PMU
driver fix/cleanup"
* 'perf-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
perf jit: Fix build issue on Ubuntu
perf jevents: Handle events including .c and .o
perf/x86/intel: Remove an inconsistent NULL check
kprobes: Unpoison stack in jprobe_return() for KASAN
kprobes: Avoid false KASAN reports during stack copy
perf header: Set nr_numa_nodes only when we parsed all the data
perf top: Fix refreshing hierarchy entries on TUI
Linus Torvalds [Tue, 18 Oct 2016 16:04:17 +0000 (09:04 -0700)]
Merge branch 'locking-urgent-for-linus' of git://git./linux/kernel/git/tip/tip
Pull locking fixes from Ingo Molnar:
"Two fixes:
- a file locks fix (missing critical section, bug introduced in this
merge window)
- an x86 down_write() stack frame annotation"
* 'locking-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
locking, fs/locks: Add missing file_sem locks
locking/rwsem/x86: Add stack frame dependency for ____down_write()
Linus Torvalds [Tue, 18 Oct 2016 16:01:22 +0000 (09:01 -0700)]
Merge branch 'irq-urgent-for-linus' of git://git./linux/kernel/git/tip/tip
Pull irq fixes from Ingo Molnar:
"Three irqchip driver fixes"
* 'irq-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
irqchip/gicv3: Handle loop timeout proper
irqchip/jcore: Fix lost per-cpu interrupts
irqchip/eznps: Acknowledge NPS_IPI before calling the handler
Linus Torvalds [Tue, 18 Oct 2016 15:35:07 +0000 (08:35 -0700)]
Merge branch 'core-urgent-for-linus' of git://git./linux/kernel/git/tip/tip
Pull misc fixes from Ingo Molnar:
"A CPU hotplug debuggability fix and three objtool false positive
warnings fixes for new GCC6 code generation patterns"
* 'core-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
cpu/hotplug: Use distinct name for cpu_hotplug.dep_map
objtool: Skip all "unreachable instruction" warnings for gcov kernels
objtool: Improve rare switch jump table pattern detection
objtool: Support '-mtune=atom' stack frame setup instruction
Linus Torvalds [Tue, 18 Oct 2016 15:28:08 +0000 (08:28 -0700)]
Merge tag 'firewire-update' of git://git./linux/kernel/git/ieee1394/linux1394
Pull firewire fixlet from Stefan Richter:
"IEEE 1394 subsystem patch: catch an initialization error in the packet
sniffer nosy"
* tag 'firewire-update' of git://git.kernel.org/pub/scm/linux/kernel/git/ieee1394/linux1394:
firewire: nosy: do not ignore errors in ioremap_nocache()
Linus Torvalds [Tue, 18 Oct 2016 15:05:29 +0000 (08:05 -0700)]
Merge tag 'drm-fixes-for-v4.9-rc2' of git://people.freedesktop.org/~airlied/linux
Pull drm fixes from Dave Airlie:
"Just had a couple of amdgpu fixes and one core fix I wanted to get out
early to fix some regressions.
I'm sure I'll have more stuff this week for -rc2"
* tag 'drm-fixes-for-v4.9-rc2' of git://people.freedesktop.org/~airlied/linux: (22 commits)
drm: Print device information again in debugfs
drm/amd/powerplay: fix bug stop dpm can't work on Vi.
drm/amd/powerplay: notify smu no display by default.
drm/amdgpu/dpm: implement thermal sensor for CZ/ST
drm/amdgpu/powerplay: implement thermal sensor for CZ/ST
drm/amdgpu: disable smu hw first on tear down
drm/amdgpu: fix amdgpu_need_full_reset (v2)
drm/amdgpu/si_dpm: Limit clocks on HD86xx part
drm/amd/powerplay: fix static checker warnings in smu7_hwmgr.c
drm/amdgpu: potential NULL dereference in debugfs code
drm/amd/powerplay: fix static checker warnings in smu7_hwmgr.c
drm/amd/powerplay: fix static checker warnings in iceland_smc.c
drm/radeon: change vblank_time's calculation method to reduce computational error.
drm/amdgpu: change vblank_time's calculation method to reduce computational error.
drm/amdgpu: clarify UVD/VCE special handling for CG
drm/amd/amdgpu: enable clockgating only after late init
drm/radeon: allow TA_CS_BC_BASE_ADDR on SI
drm/amdgpu: initialize the context reset_counter in amdgpu_ctx_init
drm/amdgpu/gfx8: fix CGCG_CGLS handling
drm/radeon: fix modeset tear down code
...
Mika Westerberg [Mon, 10 Oct 2016 13:39:31 +0000 (16:39 +0300)]
pinctrl: intel: Only restore pins that are used by the driver
Dell XPS 13 (and maybe some others) uses a GPIO (CPU_GP_1) during suspend
to explicitly disable USB touchscreen interrupt. This is done to prevent
situation where the lid is closed the touchscreen is left functional.
The pinctrl driver (wrongly) assumes it owns all pins which are owned by
host and not locked down. It is perfectly fine for BIOS to use those pins
as it is also considered as host in this context.
What happens is that when the lid of Dell XPS 13 is closed, the BIOS
configures CPU_GP_1 low disabling the touchscreen interrupt. During resume
we restore all host owned pins to the known state which includes CPU_GP_1
and this overwrites what the BIOS has programmed there causing the
touchscreen to fail as no interrupts are reaching the CPU anymore.
Fix this by restoring only those pins we know are explicitly requested by
the kernel one way or other.
Cc: stable@vger.kernel.org
Link: https://bugzilla.kernel.org/show_bug.cgi?id=176361
Reported-by: AceLan Kao <acelan.kao@canonical.com>
Tested-by: AceLan Kao <acelan.kao@canonical.com>
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Ville Syrjälä [Mon, 3 Oct 2016 14:56:55 +0000 (17:56 +0300)]
pinctrl: baytrail: Fix lockdep
Initialize the spinlock before using it.
INFO: trying to register non-static key.
the code is fine but needs lockdep annotation.
turning off the locking correctness validator.
CPU: 2 PID: 1 Comm: swapper/0 Not tainted 4.8.0-dwc-bisect #4
Hardware name: Intel Corp. VALLEYVIEW C0 PLATFORM/BYT-T FFD8, BIOS BLAKFF81.X64.0088.R10.
1403240443 FFD8_X64_R_2014_13_1_00 03/24/2014
0000000000000000 ffff8800788ff770 ffffffff8133d597 0000000000000000
0000000000000000 ffff8800788ff7e0 ffffffff810cfb9e 0000000000000002
ffff8800788ff7d0 ffffffff8205b600 0000000000000002 ffff8800788ff7f0
Call Trace:
[<
ffffffff8133d597>] dump_stack+0x67/0x90
[<
ffffffff810cfb9e>] register_lock_class+0x52e/0x540
[<
ffffffff810d2081>] __lock_acquire+0x81/0x16b0
[<
ffffffff810cede1>] ? save_trace+0x41/0xd0
[<
ffffffff810d33b2>] ? __lock_acquire+0x13b2/0x16b0
[<
ffffffff810cf05a>] ? __lock_is_held+0x4a/0x70
[<
ffffffff810d3b1a>] lock_acquire+0xba/0x220
[<
ffffffff8136f1fe>] ? byt_gpio_get_direction+0x3e/0x80
[<
ffffffff81631567>] _raw_spin_lock_irqsave+0x47/0x60
[<
ffffffff8136f1fe>] ? byt_gpio_get_direction+0x3e/0x80
[<
ffffffff8136f1fe>] byt_gpio_get_direction+0x3e/0x80
[<
ffffffff813740a9>] gpiochip_add_data+0x319/0x7d0
[<
ffffffff81631723>] ? _raw_spin_unlock_irqrestore+0x43/0x70
[<
ffffffff8136fe3b>] byt_pinctrl_probe+0x2fb/0x620
[<
ffffffff8142fb0c>] platform_drv_probe+0x3c/0xa0
...
Based on the diff it looks like the problem was introduced in
commit
71e6ca61e826 ("pinctrl: baytrail: Register pin control handling")
but I wasn't able to verify that empirically as the parent commit
just oopsed when I tried to boot it.
Cc: Cristina Ciocan <cristina.ciocan@intel.com>
Cc: stable@vger.kernel.org
Fixes:
71e6ca61e826 ("pinctrl: baytrail: Register pin control handling")
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Acked-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Andrew Jeffery [Tue, 27 Sep 2016 14:50:16 +0000 (00:20 +0930)]
pinctrl: aspeed-g5: Fix pin association of SPI1 function
The SPI1 function was associated with the wrong pins: The functions that
those pins provide is either an SPI debug or passthrough function
coupled to SPI1. Make the SPI1 mux function configure the relevant pins
and associate new SPI1DEBUG and SPI1PASSTHRU functions with the pins
that were already defined.
The notation used in the datasheet's multi-function pin table for the SoC is
often creative: in this case the SYS* signals are enabled by a single bit,
which is nothing unusual on its own, but in this case the bit was also
participating in a multi-bit bitfield and therefore represented multiple
functions. This fact was overlooked in the original patch.
Fixes:
56e57cb6c07f (pinctrl: Add pinctrl-aspeed-g5 driver)
Signed-off-by: Andrew Jeffery <andrew@aj.id.au>
Reviewed-by: Joel Stanley <joel@jms.id.au>
Acked-by: Rob Herring <robh@kernel.org>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Andrew Jeffery [Tue, 27 Sep 2016 14:50:15 +0000 (00:20 +0930)]
pinctrl: aspeed-g5: Fix GPIOE1 typo
This prevented C20 from successfully being muxed as GPIO.
Fixes:
56e57cb6c07f (pinctrl: Add pinctrl-aspeed-g5 driver)
Signed-off-by: Andrew Jeffery <andrew@aj.id.au>
Reviewed-by: Joel Stanley <joel@jms.id.au>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Andrew Jeffery [Tue, 27 Sep 2016 14:50:14 +0000 (00:20 +0930)]
pinctrl: aspeed-g5: Fix names of GPID2 pins
Fixes simple typos in the initial commit. There is no behavioural
change.
Fixes:
56e57cb6c07f (pinctrl: Add pinctrl-aspeed-g5 driver)
Reported-by: Xo Wang <xow@google.com>
Signed-off-by: Andrew Jeffery <andrew@aj.id.au>
Reviewed-by: Joel Stanley <joel@jms.id.au>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Andrew Jeffery [Tue, 27 Sep 2016 14:50:13 +0000 (00:20 +0930)]
pinctrl: aspeed: "Not enabled" is a significant mux state
Consider a scenario with one pin P that has two signals A and B, where A
is defined to be higher priority than B: That is, if the mux IP is in a
state that would consider both A and B to be active on P, then A will be
the active signal.
To instead configure B as the active signal we must configure the mux so
that A is inactive. The mux state for signals can be described by
logical operations on one or more bits from one or more registers (a
"signal expression"), which in some cases leads to aliased mux states for
a particular signal. Further, signals described by multi-bit bitfields
often do not only need to record the states that would make them active
(the "enable" expressions), but also the states that makes them inactive
(the "disable" expressions). All of this combined leads to four possible
states for a signal:
1. A signal is active with respect to an "enable" expression
2. A signal is not active with respect to an "enable" expression
3. A signal is inactive with respect to a "disable" expression
4. A signal is not inactive with respect to a "disable" expression
In the case of P, if we are looking to activate B without explicitly
having configured A it's enough to consider A inactive if all of A's
"enable" signal expressions evaluate to "not active". If any evaluate to
"active" then the corresponding "disable" states must be applied so it
becomes inactive.
For example, on the AST2400 the pins composing GPIO bank H provide
signals ROMD8 through ROMD15 (high priority) and those for UART6 (low
priority). The mux states for ROMD8 through ROMD15 are aliased, i.e.
there are two mux states that result in the respective signals being
configured:
A. SCU90[6]=1
B. Strap[4,1:0]=100
Further, the second mux state is a 3-bit bitfield that explicitly
defines the enabled state but the disabled state is implicit, i.e. if
Strap[4,1:0] is not exactly "100" then ROMD8 through ROMD15 are not
considered active. This requires the mux function evaluation logic to
use approach 2. above, however the existing code was using approach 3.
The problem was brought to light on the Palmetto machines where the
strap register value is 0x120ce416, and prevented GPIO requests in bank
H from succeeding despite the hardware being in a position to allow
them.
Fixes:
318398c09a8d ("pinctrl: Add core pinctrl support for Aspeed SoCs")
Signed-off-by: Andrew Jeffery <andrew@aj.id.au>
Reviewed-by: Joel Stanley <joel@jms.id.au>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Wei Yongjun [Mon, 17 Oct 2016 15:11:29 +0000 (15:11 +0000)]
ceph: fix non static symbol warning
Fixes the following sparse warning:
fs/ceph/xattr.c:19:28: warning:
symbol 'ceph_other_xattr_handler' was not declared. Should it be static?
Signed-off-by: Wei Yongjun <weiyongjun1@huawei.com>
Signed-off-by: Ilya Dryomov <idryomov@gmail.com>
Peter Zijlstra [Sat, 8 Oct 2016 08:12:28 +0000 (10:12 +0200)]
locking, fs/locks: Add missing file_sem locks
I overlooked a few code-paths that can lead to
locks_delete_global_locks().
Reported-by: Dmitry Vyukov <dvyukov@google.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Reviewed-by: Jeff Layton <jlayton@poochiereds.net>
Cc: Al Viro <viro@zeniv.linux.org.uk>
Cc: Bruce Fields <bfields@fieldses.org>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: linux-fsdevel@vger.kernel.org
Cc: syzkaller <syzkaller@googlegroups.com>
Link: http://lkml.kernel.org/r/20161008081228.GF3142@twins.programming.kicks-ass.net
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Josh Poimboeuf [Thu, 13 Oct 2016 21:26:15 +0000 (16:26 -0500)]
locking/rwsem/x86: Add stack frame dependency for ____down_write()
Arnd reported the following objtool warning:
kernel/locking/rwsem.o: warning: objtool: down_write_killable()+0x16: call without frame pointer save/setup
The warning means gcc placed the ____down_write() inline asm (and its
call instruction) before the frame pointer setup in
down_write_killable(), which breaks frame pointer convention and can
result in incorrect stack traces.
Force the stack frame to be created before the call instruction by
listing the stack pointer as an output operand in the inline asm
statement.
Reported-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Josh Poimboeuf <jpoimboe@redhat.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/1188b7015f04baf361e59de499ee2d7272c59dce.1476393828.git.jpoimboe@redhat.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Geert Uytterhoeven [Thu, 13 Oct 2016 15:15:37 +0000 (17:15 +0200)]
ceph: fix uninitialized dentry pointer in ceph_real_mount()
fs/ceph/super.c: In function ‘ceph_real_mount’:
fs/ceph/super.c:818: warning: ‘root’ may be used uninitialized in this function
If s_root is already valid, dentry pointer root is never initialized,
and returned by ceph_real_mount(). This will cause a crash later when
the caller dereferences the pointer.
Fixes:
ce2728aaa82bbeba ("ceph: avoid accessing / when mounting a subpath")
Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
Signed-off-by: Yan, Zheng <zyan@redhat.com>
Yan, Zheng [Wed, 12 Oct 2016 06:48:28 +0000 (14:48 +0800)]
ceph: fix readdir vs fragmentation race
following sequence of events tigger the race
- client readdir frag 0* -> got item 'A'
- MDS merges frag 0* and frag 1*
- client send readdir request (frag 1*, offset 2, readdir_start 'A')
- MDS reply items (that are after item 'A') in frag *
Link: http://tracker.ceph.com/issues/17286
Signed-off-by: Yan, Zheng <zyan@redhat.com>
Arnd Bergmann [Mon, 17 Oct 2016 22:05:34 +0000 (00:05 +0200)]
ext2: avoid bogus -Wmaybe-uninitialized warning
On ARM, we get this false-positive warning since the rework of
the ext2_get_blocks interface:
fs/ext2/inode.c: In function 'ext2_get_block':
include/linux/buffer_head.h:340:16: error: 'bno' may be used uninitialized in this function [-Werror=maybe-uninitialized]
The calling conventions for this function are rather complex, and it's
not surprising that the compiler gets this wrong, I spent a long time
trying to understand how it all fits together myself.
This change to avoid the warning makes sure the compiler sees that we
always set 'bno' pointer whenever we have a positive return code.
The transformation is correct because we always arrive at the 'got_it'
label with a positive count that gets used as the return value, while
any branch to the 'cleanup' label has a negative or zero 'err'.
Fixes:
6750ad71986d ("ext2: stop passing buffer_head to ext2_get_blocks")
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Cc: Dave Chinner <david@fromorbit.com>
Signed-off-by: Jan Kara <jack@suse.cz>
Jan Kara [Tue, 4 Oct 2016 11:44:06 +0000 (13:44 +0200)]
isofs: Do not return EACCES for unknown filesystems
When isofs_mount() is called to mount a device read-write, it returns
EACCES even before it checks that the device actually contains an isofs
filesystem. This may confuse mount(8) which then tries to mount all
subsequent filesystem types in read-only mode.
Fix the problem by returning EACCES only once we verify that the device
indeed contains an iso9660 filesystem.
CC: stable@vger.kernel.org
Fixes:
17b7f7cf58926844e1dd40f5eb5348d481deca6a
Reported-by: Kent Overstreet <kent.overstreet@gmail.com>
Reported-by: Karel Zak <kzak@redhat.com>
Signed-off-by: Jan Kara <jack@suse.cz>
Junjie Mao [Mon, 17 Oct 2016 01:20:25 +0000 (09:20 +0800)]
btrfs: assign error values to the correct bio structs
Fixes:
4246a0b63bd8 ("block: add a bi_error field to struct bio")
Signed-off-by: Junjie Mao <junjie.mao@enight.me>
Acked-by: David Sterba <dsterba@suse.cz>
Cc: stable@vger.kernel.org # 4.3+
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Dave Hansen [Mon, 17 Oct 2016 20:57:09 +0000 (13:57 -0700)]
x86, pkeys: remove cruft from never-merged syscalls
pkey_set() and pkey_get() were syscalls present in older versions
of the protection keys patches. The syscall number definitions
were inadvertently left in place. This patch removes them.
I did a git grep and verified that these are the last places in
the tree that these appear, save for the protection_keys.c tests
and Documentation. Those spots talk about functions called
pkey_get/set() which are wrappers for the direct PKRU
instructions, not the syscalls.
Signed-off-by: Dave Hansen <dave.hansen@linux.intel.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: linux-arch@vger.kernel.org
Cc: mgorman@techsingularity.net
Cc: arnd@arndb.de
Cc: linux-api@vger.kernel.org
Cc: linux-mm@kvack.org
Cc: luto@kernel.org
Cc: akpm@linux-foundation.org
Fixes:
f9afc6197e9bb ("x86: Wire up protection keys system calls")
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Will Deacon [Mon, 17 Oct 2016 12:38:14 +0000 (13:38 +0100)]
arm64: sysreg: Fix use of XZR in write_sysreg_s
Commit
8a71f0c656e0 ("arm64: sysreg: replace open-coded mrs_s/msr_s with
{read,write}_sysreg_s") introduced a write_sysreg_s macro for writing
to system registers that are not supported by binutils.
Unfortunately, this was implemented with the wrong template (%0 vs %x0),
so in the case that we are writing a constant 0, we will generate
invalid instruction syntax and bail with a cryptic assembler error:
| Error: constant expression required
This patch fixes the template.
Acked-by: Mark Rutland <mark.rutland@arm.com>
Signed-off-by: Will Deacon <will.deacon@arm.com>
Dave Hansen [Mon, 17 Oct 2016 15:18:15 +0000 (08:18 -0700)]
generic syscalls: kill cruft from removed pkey syscalls
pkey_set() and pkey_get() were syscalls present in older versions
of the protection keys patches. They were fully excised from the
x86 code, but some cruft was left in the generic syscall code. The
C++ comments were intended to help to make it more glaring to me to
fix them before actually submitting them. That technique worked,
but later than I would have liked.
I test-compiled this for arm64.
Fixes:
a60f7b69d92c0 ("generic syscalls: Wire up memory protection keys syscalls")
Signed-off-by: Dave Hansen <dave.hansen@linux.intel.com>
Acked-by: Arnd Bergmann <arnd@arndb.de>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: x86@kernel.org
Cc: linux-arch@vger.kernel.org
Cc: mgorman@techsingularity.net
Cc: linux-api@vger.kernel.org
Cc: linux-mm@kvack.org
Cc: luto@kernel.org
Cc: akpm@linux-foundation.org
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Ard Biesheuvel [Mon, 17 Oct 2016 15:18:39 +0000 (16:18 +0100)]
arm64: kaslr: keep modules close to the kernel when DYNAMIC_FTRACE=y
The RANDOMIZE_MODULE_REGION_FULL Kconfig option allows KASLR to be
configured in such a way that kernel modules and the core kernel are
allocated completely independently, which implies that modules are likely
to require branches via PLT entries to reach the core kernel. The dynamic
ftrace code does not expect that, and assumes that it can patch module
code to perform a relative branch to anywhere in the core kernel. This
may result in errors such as
branch_imm_common: offset out of range
------------[ cut here ]------------
WARNING: CPU: 3 PID: 196 at kernel/trace/ftrace.c:1995 ftrace_bug+0x220/0x2e8
Modules linked in:
CPU: 3 PID: 196 Comm: systemd-udevd Not tainted 4.8.0-22-generic #24
Hardware name: AMD Seattle/Seattle, BIOS 10:34:40 Oct 6 2016
task:
ffff8d1bef7dde80 task.stack:
ffff8d1bef6b0000
PC is at ftrace_bug+0x220/0x2e8
LR is at ftrace_process_locs+0x330/0x430
So make RANDOMIZE_MODULE_REGION_FULL mutually exclusive with DYNAMIC_FTRACE
at the Kconfig level.
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Signed-off-by: Will Deacon <will.deacon@arm.com>
Marc Zyngier [Mon, 17 Oct 2016 12:47:34 +0000 (13:47 +0100)]
arm64: kernel: Init MDCR_EL2 even in the absence of a PMU
Commit
f436b2ac90a0 ("arm64: kernel: fix architected PMU registers
unconditional access") made sure we wouldn't access unimplemented
PMU registers, but also left MDCR_EL2 uninitialized in that case,
leading to trap bits being potentially left set.
Make sure we always write something in that register.
Fixes:
f436b2ac90a0 ("arm64: kernel: fix architected PMU registers unconditional access")
Cc: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Cc: Will Deacon <will.deacon@arm.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
Signed-off-by: Will Deacon <will.deacon@arm.com>
Tai Nguyen [Thu, 13 Oct 2016 18:09:16 +0000 (11:09 -0700)]
perf: xgene: Remove bogus IS_ERR() check
In acpi_get_pmu_hw_inf we pass the address of a local variable to IS_ERR(),
which doesn't make sense, as the pointer must be a real, valid pointer.
This doesn't cause a functional problem, as IS_ERR() will evaluate as
false, but the check is bogus and causes static checkers to complain.
Remove the bogus check.
The bug is reported by Dan Carpenter <dan.carpenter@oracle.com> in [1]
[1] https://www.spinics.net/lists/arm-kernel/msg535957.html
Signed-off-by: Tai Nguyen <ttnguyen@apm.com>
Acked-by: Mark Rutland <mark.rutland@arm.com>
Signed-off-by: Will Deacon <will.deacon@arm.com>
Lorenzo Pieralisi [Mon, 17 Oct 2016 14:18:48 +0000 (15:18 +0100)]
arm64: kernel: numa: fix ACPI boot cpu numa node mapping
Commit
7ba5f605f3a0 ("arm64/numa: remove the limitation that cpu0 must
bind to node0") removed the numa cpu<->node mapping restriction whereby
logical cpu 0 always corresponds to numa node 0; removing the
restriction was correct, in that it does not really exist in practice
but the commit only updated the early mapping of logical cpu 0 to its
real numa node for the DT boot path, missing the ACPI one, leading to
boot failures on ACPI systems owing to missing node<->cpu map for
logical cpu 0.
Fix the issue by updating the ACPI boot path with code that carries out
the early cpu<->node mapping also for the boot cpu (ie cpu 0), mirroring
what is currently done in the DT boot path.
Fixes:
7ba5f605f3a0 ("arm64/numa: remove the limitation that cpu0 must bind to node0")
Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Tested-by: Laszlo Ersek <lersek@redhat.com>
Reported-by: Laszlo Ersek <lersek@redhat.com>
Cc: Will Deacon <will.deacon@arm.com>
Cc: Laszlo Ersek <lersek@redhat.com>
Cc: Hanjun Guo <hanjun.guo@linaro.org>
Cc: Andrew Jones <drjones@redhat.com>
Cc: Zhen Lei <thunder.leizhen@huawei.com>
Cc: Catalin Marinas <catalin.marinas@arm.com>
Signed-off-by: Will Deacon <will.deacon@arm.com>
Ingo Molnar [Mon, 17 Oct 2016 14:49:16 +0000 (16:49 +0200)]
Merge tag 'perf-urgent-for-mingo-
20161017' of git://git./linux/kernel/git/acme/linux into perf/urgent
Pull perf/urgent fixes from Arnaldo Carvalho de Melo:
- Fix handling of NUMA nodes in perf.data files (Jiri Olsa)
- Fix scrolling when refreshing 'perf top --tui --hierarchy' entries (Namhyung Kim)
- Fix building of JIT support on Ubuntu 16.04 (Anton Blanchard)
- Fix handling of events including .c and .o, that were being treated as
BPF scripts instead of vendor ones (Wang Nan)
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Anton Blanchard [Thu, 13 Oct 2016 02:20:43 +0000 (13:20 +1100)]
perf jit: Fix build issue on Ubuntu
When building on Ubuntu 16.04, I get the following error:
Makefile:49: *** the openjdk development package appears to me missing, install and try again. Stop.
The problem is that update-java-alternatives has multiple spaces between
fields, and cut treats each space as a new delimiter:
java-1.8.0-openjdk-ppc64el 1081 /usr/lib/jvm/java-1.8.0-openjdk-ppc64el
Fix this by using awk, which handles this fine.
Signed-off-by: Anton Blanchard <anton@samba.org>
Reviewed-by: Stephane Eranian <eranian@google.com>
Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Link: http://lkml.kernel.org/r/1476325243-15788-1-git-send-email-anton@ozlabs.org
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Wang Nan [Sat, 8 Oct 2016 04:16:25 +0000 (04:16 +0000)]
perf jevents: Handle events including .c and .o
This patch helps with Sukadev's vendor event tree where such events can happen.
>From Andi Kleen:
Any event including a .c/.o/.bpf currently triggers BPF compilation or loading
and then an error. This can happen for some Intel vendor events, which cannot
be used.
This patch fixes this problem by forbidding BPF file patch containing '{', '}'
and ',', make sure flex consumes the leading '{', instead of matching it using
a BPF file path.
Tested result:
$ perf stat -e '{unc_p_clockticks,unc_p_power_state_occupancy.cores_c0}' -a -I 1000
invalid or unsupported event: '{unc_p_clockticks,unc_p_power_state_occupancy.cores_c0}'
Run 'perf list' for a list of valid events
(as expected, interperted as event)
$ perf stat -e 'aaa.c' -a -I 1000
ERROR: problems with path aaa.c: No such file or directory
(as expected, interpreted as BPF source)
$ perf stat -e 'aaa.ccc' -a -I 1000
invalid or unsupported event: 'aaa.ccc'
(as expected, interpreted as event)
$ perf stat -e '{aaa.c}' -a -I 1000
ERROR: problems with path aaa.c: No such file or directory
event syntax error: '{aaa.c}'
<SKIP>
(as expected, interpreted as BPF source)
$ perf stat -e '{cycles,aaa.c}' -a -I 1000
ERROR: problems with path aaa.c: No such file or directory
event syntax error: '{cycles,aaa.c}'
(as expected, interpreted as BPF source)
Signed-off-by: Wang Nan <wangnan0@huawei.com>
Tested-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Reported-by: Andi Kleen <ak@linux.intel.com>
Cc: Jiri Olsa <jolsa@kernel.org>
Cc: Sukadev Bhattiprolu <sukadev@linux.vnet.ibm.com>
Cc: Zefan Li <lizefan@huawei.com>
Cc: pi3orama@163.com
Link: http://lkml.kernel.org/r/1475900185-37967-1-git-send-email-wangnan0@huawei.com
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Ulf Hansson [Mon, 17 Oct 2016 10:19:38 +0000 (12:19 +0200)]
MAINTAINERS: mmc: Move the mmc tree to kernel.org
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Ulf Hansson [Wed, 28 Sep 2016 18:33:28 +0000 (11:33 -0700)]
memstick: rtsx_usb_ms: Manage runtime PM when accessing the device
Accesses to the rtsx usb device, which is the parent of the rtsx memstick
device, must not be done unless it's runtime resumed. This is currently not
the case and it could trigger various errors.
Fix this by properly deal with runtime PM in this regards. This means
making sure the device is runtime resumed, when serving requests via the
->request() callback or changing settings via the ->set_param() callbacks.
Cc: <stable@vger.kernel.org>
Cc: Ritesh Raj Sarraf <rrs@researchut.com>
Cc: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Alan Stern [Mon, 26 Sep 2016 22:45:41 +0000 (15:45 -0700)]
memstick: rtsx_usb_ms: Runtime resume the device when polling for cards
Accesses to the rtsx usb device, which is the parent of the rtsx memstick
device, must not be done unless it's runtime resumed.
Therefore when the rtsx_usb_ms driver polls for inserted memstick cards,
let's add pm_runtime_get|put*() to make sure accesses is done when the
rtsx usb device is runtime resumed.
Reported-by: Ritesh Raj Sarraf <rrs@researchut.com>
Tested-by: Ritesh Raj Sarraf <rrs@researchut.com>
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Cc: <stable@vger.kernel.org>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Ulf Hansson [Thu, 15 Sep 2016 12:46:21 +0000 (14:46 +0200)]
mmc: rtsx_usb_sdmmc: Handle runtime PM while changing the led
Accesses of the rtsx sdmmc's parent device, which is the rtsx usb device,
must be done when it's runtime resumed. Currently this isn't case when
changing the led, so let's fix this by adding a pm_runtime_get_sync() and
a pm_runtime_put() around those operations.
Reported-by: Ritesh Raj Sarraf <rrs@researchut.com>
Tested-by: Ritesh Raj Sarraf <rrs@researchut.com>
Cc: <stable@vger.kernel.org>
Cc: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Ulf Hansson [Tue, 27 Sep 2016 15:44:33 +0000 (08:44 -0700)]
mmc: rtsx_usb_sdmmc: Avoid keeping the device runtime resumed when unused
The rtsx_usb_sdmmc driver may bail out in its ->set_ios() callback when no
SD card is inserted. This is wrong, as it could cause the device to remain
runtime resumed when it's unused. Fix this behaviour.
Tested-by: Ritesh Raj Sarraf <rrs@researchut.com>
Cc: <stable@vger.kernel.org>
Cc: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Haibo Chen [Mon, 17 Oct 2016 08:18:37 +0000 (10:18 +0200)]
mmc: sdhci: cast unsigned int to unsigned long long to avoid unexpeted error
Potentially overflowing expression
1000000 * data->timeout_clks with
type unsigned int is evaluated using 32-bit arithmetic, and then used
in a context that expects an expression of type unsigned long long.
To avoid overflow, cast 1000000U to type unsigned long long.
Special thanks to Coverity.
Fixes:
7f05538af71c ("mmc: sdhci: fix data timeout (part 2)")
Signed-off-by: Haibo Chen <haibo.chen@nxp.com>
Cc: stable@vger.kernel.org # v3.15+
Acked-by: Adrian Hunter <adrian.hunter@intel.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Ard Biesheuvel [Thu, 13 Oct 2016 16:42:09 +0000 (17:42 +0100)]
arm64: kaslr: fix breakage with CONFIG_MODVERSIONS=y
As it turns out, the KASLR code breaks CONFIG_MODVERSIONS, since the
kcrctab has an absolute address field that is relocated at runtime
when the kernel offset is randomized.
This has been fixed already for PowerPC in the past, so simply wire up
the existing code dealing with this issue.
Cc: <stable@vger.kernel.org>
Fixes:
f80fb3a3d508 ("arm64: add support for kernel ASLR")
Tested-by: Timur Tabi <timur@codeaurora.org>
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Signed-off-by: Will Deacon <will.deacon@arm.com>
Tobias Klauser [Mon, 17 Oct 2016 09:47:02 +0000 (11:47 +0200)]
alarmtimer: Remove unused but set variable
Remove the set but unused variable base in alarm_clock_get to fix the
following warning when building with 'W=1':
kernel/time/alarmtimer.c: In function ‘alarm_timer_create’:
kernel/time/alarmtimer.c:545:21: warning: variable ‘base’ set but not used [-Wunused-but-set-variable]
Signed-off-by: Tobias Klauser <tklauser@distanz.ch>
Cc: John Stultz <john.stultz@linaro.org>
Link: http://lkml.kernel.org/r/20161017094702.10873-1-tklauser@distanz.ch
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Ingo Molnar [Sun, 16 Oct 2016 16:17:05 +0000 (18:17 +0200)]
Merge branch 'mm/pkeys' into x86/urgent, to pick up pkeys fix
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Piotr Luc [Wed, 12 Oct 2016 18:27:58 +0000 (20:27 +0200)]
perf/x86/intel/uncore: Add Knights Mill CPUID
Add Knights Mill (KNM) to the list of CPUIDs supported by PMU.
Signed-off-by: Piotr Luc <piotr.luc@intel.com>
Reviewed-by: Dave Hansen <dave.hansen@intel.com>
Cc: 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: Josh Poimboeuf <jpoimboe@redhat.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/20161012182758.2925-1-piotr.luc@intel.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Piotr Luc [Wed, 12 Oct 2016 18:27:25 +0000 (20:27 +0200)]
perf/x86/intel/rapl: Add Knights Mill CPUID
Add Knights Mill (KNM) to the list of CPUIDs supported by rapl.
Signed-off-by: Piotr Luc <piotr.luc@intel.com>
Reviewed-by: Dave Hansen <dave.hansen@intel.com>
Cc: 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: Josh Poimboeuf <jpoimboe@redhat.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/20161012182725.2701-1-piotr.luc@intel.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Piotr Luc [Wed, 12 Oct 2016 18:26:34 +0000 (20:26 +0200)]
perf/x86/intel: Add Knights Mill CPUID
Add Knights Mill (KNM) to the list of CPUIDs supported by PMU.
Signed-off-by: Piotr Luc <piotr.luc@intel.com>
Reviewed-by: Dave Hansen <dave.hansen@intel.com>
Cc: 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: Josh Poimboeuf <jpoimboe@redhat.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/20161012182634.2462-1-piotr.luc@intel.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Piotr Luc [Wed, 12 Oct 2016 18:05:20 +0000 (20:05 +0200)]
x86/cpu/intel: Add Knights Mill to Intel family
Add CPUID of Knights Mill (KNM) processor to Intel family list.
Signed-off-by: Piotr Luc <piotr.luc@intel.com>
Reviewed-by: Dave Hansen <dave.hansen@intel.com>
Cc: 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: Josh Poimboeuf <jpoimboe@redhat.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/20161012180520.30976-1-piotr.luc@intel.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Daniel Vetter [Thu, 13 Oct 2016 14:13:44 +0000 (16:13 +0200)]
drm: Print device information again in debugfs
I was a bit over-eager in my cleanup in
commit
95c081c17f284de50eaca60d4d55643a64d39019
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date: Tue Jun 21 10:54:12 2016 +0200
drm: Move master pointer from drm_minor to drm_device
Noticed by Chris Wilson.
Fixes:
95c081c17f28 ("drm: Move master pointer from drm_minor to drm_device")
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Daniel Vetter <daniel.vetter@intel.com>
Cc: Emil Velikov <emil.l.velikov@gmail.com>
Cc: Julia Lawall <julia.lawall@lip6.fr>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Tested-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Emil Velikov <emil.l.velikov@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Dave Airlie [Sun, 16 Oct 2016 23:31:52 +0000 (09:31 +1000)]
Merge branch 'drm-next-4.9' of git://people.freedesktop.org/~agd5f/linux into drm-next
Fixes for radeon and amdgpu for 4.9:
- allow an additional reg in the SI reg checker
- fix thermal sensor readback on CZ/ST
- misc bug fixes
* 'drm-next-4.9' of git://people.freedesktop.org/~agd5f/linux: (21 commits)
drm/amd/powerplay: fix bug stop dpm can't work on Vi.
drm/amd/powerplay: notify smu no display by default.
drm/amdgpu/dpm: implement thermal sensor for CZ/ST
drm/amdgpu/powerplay: implement thermal sensor for CZ/ST
drm/amdgpu: disable smu hw first on tear down
drm/amdgpu: fix amdgpu_need_full_reset (v2)
drm/amdgpu/si_dpm: Limit clocks on HD86xx part
drm/amd/powerplay: fix static checker warnings in smu7_hwmgr.c
drm/amdgpu: potential NULL dereference in debugfs code
drm/amd/powerplay: fix static checker warnings in smu7_hwmgr.c
drm/amd/powerplay: fix static checker warnings in iceland_smc.c
drm/radeon: change vblank_time's calculation method to reduce computational error.
drm/amdgpu: change vblank_time's calculation method to reduce computational error.
drm/amdgpu: clarify UVD/VCE special handling for CG
drm/amd/amdgpu: enable clockgating only after late init
drm/radeon: allow TA_CS_BC_BASE_ADDR on SI
drm/amdgpu: initialize the context reset_counter in amdgpu_ctx_init
drm/amdgpu/gfx8: fix CGCG_CGLS handling
drm/radeon: fix modeset tear down code
drm/radeon: fix up dp aux tear down (v2)
...
Dan Carpenter [Fri, 14 Oct 2016 07:29:08 +0000 (10:29 +0300)]
perf/x86/intel: Remove an inconsistent NULL check
Smatch complains that we don't check "event->ctx" consistently. It's
never NULL so we can just remove the check.
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
Cc: Arnaldo Carvalho de Melo <acme@redhat.com>
Cc: David Carrillo-Cisneros <davidcc@google.com>
Cc: Jiri Olsa <jolsa@redhat.com>
Cc: Kan Liang <kan.liang@intel.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: kernel-janitors@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Ingo Molnar [Sun, 16 Oct 2016 09:31:39 +0000 (11:31 +0200)]
Merge tag 'v4.9-rc1' into x86/urgent, to pick up updates
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Dan Williams [Wed, 12 Oct 2016 18:01:48 +0000 (11:01 -0700)]
x86/e820: Don't merge consecutive E820_PRAM ranges
Commit:
917db484dc6a ("x86/boot: Fix kdump, cleanup aborted E820_PRAM max_pfn manipulation")
... fixed up the broken manipulations of max_pfn in the presence of
E820_PRAM ranges.
However, it also broke the sanitize_e820_map() support for not merging
E820_PRAM ranges.
Re-introduce the enabling to keep resource boundaries between
consecutive defined ranges. Otherwise, for example, an environment that
boots with memmap=2G!8G,2G!10G will end up with a single 4G /dev/pmem0
device instead of a /dev/pmem0 and /dev/pmem1 device 2G in size.
Reported-by: Dave Chinner <david@fromorbit.com>
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
Cc: <stable@vger.kernel.org>
Cc: 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: Jeff Moyer <jmoyer@redhat.com>
Cc: Josh Poimboeuf <jpoimboe@redhat.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Zhang Yi <yizhan@redhat.com>
Cc: linux-nvdimm@lists.01.org
Fixes:
917db484dc6a ("x86/boot: Fix kdump, cleanup aborted E820_PRAM max_pfn manipulation")
Link: http://lkml.kernel.org/r/147629530854.10618.10383744751594021268.stgit@dwillia2-desk3.amr.corp.intel.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Joonas Lahtinen [Wed, 12 Oct 2016 10:18:56 +0000 (13:18 +0300)]
cpu/hotplug: Use distinct name for cpu_hotplug.dep_map
Use distinctive name for cpu_hotplug.dep_map to avoid the actual
cpu_hotplug.lock appearing as cpu_hotplug.lock#2 in lockdep splats.
Signed-off-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Acked-by: Gautham R. Shenoy <ego@linux.vnet.ibm.com>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Gautham R . Shenoy <ego@linux.vnet.ibm.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: intel-gfx@lists.freedesktop.org
Cc: trivial@kernel.org
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Dmitry Vyukov [Fri, 14 Oct 2016 14:07:23 +0000 (16:07 +0200)]
kprobes: Unpoison stack in jprobe_return() for KASAN
I observed false KSAN positives in the sctp code, when
sctp uses jprobe_return() in jsctp_sf_eat_sack().
The stray 0xf4 in shadow memory are stack redzones:
[ ] ==================================================================
[ ] BUG: KASAN: stack-out-of-bounds in memcmp+0xe9/0x150 at addr
ffff88005e48f480
[ ] Read of size 1 by task syz-executor/18535
[ ] page:
ffffea00017923c0 count:0 mapcount:0 mapping: (null) index:0x0
[ ] flags: 0x1fffc0000000000()
[ ] page dumped because: kasan: bad access detected
[ ] CPU: 1 PID: 18535 Comm: syz-executor Not tainted 4.8.0+ #28
[ ] Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
[ ]
ffff88005e48f2d0 ffffffff82d2b849 ffffffff0bc91e90 fffffbfff10971e8
[ ]
ffffed000bc91e90 ffffed000bc91e90 0000000000000001 0000000000000000
[ ]
ffff88005e48f480 ffff88005e48f350 ffffffff817d3169 ffff88005e48f370
[ ] Call Trace:
[ ] [<
ffffffff82d2b849>] dump_stack+0x12e/0x185
[ ] [<
ffffffff817d3169>] kasan_report+0x489/0x4b0
[ ] [<
ffffffff817d31a9>] __asan_report_load1_noabort+0x19/0x20
[ ] [<
ffffffff82d49529>] memcmp+0xe9/0x150
[ ] [<
ffffffff82df7486>] depot_save_stack+0x176/0x5c0
[ ] [<
ffffffff817d2031>] save_stack+0xb1/0xd0
[ ] [<
ffffffff817d27f2>] kasan_slab_free+0x72/0xc0
[ ] [<
ffffffff817d05b8>] kfree+0xc8/0x2a0
[ ] [<
ffffffff85b03f19>] skb_free_head+0x79/0xb0
[ ] [<
ffffffff85b0900a>] skb_release_data+0x37a/0x420
[ ] [<
ffffffff85b090ff>] skb_release_all+0x4f/0x60
[ ] [<
ffffffff85b11348>] consume_skb+0x138/0x370
[ ] [<
ffffffff8676ad7b>] sctp_chunk_put+0xcb/0x180
[ ] [<
ffffffff8676ae88>] sctp_chunk_free+0x58/0x70
[ ] [<
ffffffff8677fa5f>] sctp_inq_pop+0x68f/0xef0
[ ] [<
ffffffff8675ee36>] sctp_assoc_bh_rcv+0xd6/0x4b0
[ ] [<
ffffffff8677f2c1>] sctp_inq_push+0x131/0x190
[ ] [<
ffffffff867bad69>] sctp_backlog_rcv+0xe9/0xa20
[ ... ]
[ ] Memory state around the buggy address:
[ ]
ffff88005e48f380: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
[ ]
ffff88005e48f400: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
[ ] >
ffff88005e48f480: f4 f4 00 00 00 00 00 00 00 00 00 00 00 00 00 00
[ ] ^
[ ]
ffff88005e48f500: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
[ ]
ffff88005e48f580: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
[ ] ==================================================================
KASAN stack instrumentation poisons stack redzones on function entry
and unpoisons them on function exit. If a function exits abnormally
(e.g. with a longjmp like jprobe_return()), stack redzones are left
poisoned. Later this leads to random KASAN false reports.
Unpoison stack redzones in the frames we are going to jump over
before doing actual longjmp in jprobe_return().
Signed-off-by: Dmitry Vyukov <dvyukov@google.com>
Acked-by: Masami Hiramatsu <mhiramat@kernel.org>
Reviewed-by: Mark Rutland <mark.rutland@arm.com>
Cc: Mark Rutland <mark.rutland@arm.com>
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Andrey Ryabinin <ryabinin.a.a@gmail.com>
Cc: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Cc: Alexander Potapenko <glider@google.com>
Cc: Will Deacon <will.deacon@arm.com>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Ananth N Mavinakayanahalli <ananth@linux.vnet.ibm.com>
Cc: Anil S Keshavamurthy <anil.s.keshavamurthy@intel.com>
Cc: "David S. Miller" <davem@davemloft.net>
Cc: Masami Hiramatsu <mhiramat@kernel.org>
Cc: kasan-dev@googlegroups.com
Cc: surovegin@google.com
Cc: rostedt@goodmis.org
Link: http://lkml.kernel.org/r/1476454043-101898-1-git-send-email-dvyukov@google.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Dmitry Vyukov [Tue, 11 Oct 2016 12:13:38 +0000 (14:13 +0200)]
kprobes: Avoid false KASAN reports during stack copy
Kprobes save and restore raw stack chunks with memcpy().
With KASAN these chunks can contain poisoned stack redzones,
as the result memcpy() interceptor produces false
stack out-of-bounds reports.
Use __memcpy() instead of memcpy() for stack copying.
__memcpy() is not instrumented by KASAN and does not lead
to the false reports.
Currently there is a spew of KASAN reports during boot
if CONFIG_KPROBES_SANITY_TEST is enabled:
[ ] Kprobe smoke test: started
[ ] ==================================================================
[ ] BUG: KASAN: stack-out-of-bounds in setjmp_pre_handler+0x17c/0x280 at addr
ffff88085259fba8
[ ] Read of size 64 by task swapper/0/1
[ ] page:
ffffea00214967c0 count:0 mapcount:0 mapping: (null) index:0x0
[ ] flags: 0x2fffff80000000()
[ ] page dumped because: kasan: bad access detected
[...]
Reported-by: CAI Qian <caiqian@redhat.com>
Tested-by: CAI Qian <caiqian@redhat.com>
Signed-off-by: Dmitry Vyukov <dvyukov@google.com>
Acked-by: Masami Hiramatsu <mhiramat@kernel.org>
Cc: Alexander Potapenko <glider@google.com>
Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
Cc: Ananth N Mavinakayanahalli <ananth@linux.vnet.ibm.com>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Andrey Ryabinin <ryabinin.a.a@gmail.com>
Cc: Andy Lutomirski <luto@kernel.org>
Cc: Anil S Keshavamurthy <anil.s.keshavamurthy@intel.com>
Cc: Arnaldo Carvalho de Melo <acme@redhat.com>
Cc: Borislav Petkov <bp@alien8.de>
Cc: Brian Gerst <brgerst@gmail.com>
Cc: David S. Miller <davem@davemloft.net>
Cc: Denys Vlasenko <dvlasenk@redhat.com>
Cc: H. Peter Anvin <hpa@zytor.com>
Cc: Jiri Olsa <jolsa@redhat.com>
Cc: Josh Poimboeuf <jpoimboe@redhat.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: kasan-dev@googlegroups.com
[ Improved various details. ]
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Josh Poimboeuf [Thu, 13 Oct 2016 21:22:53 +0000 (16:22 -0500)]
objtool: Skip all "unreachable instruction" warnings for gcov kernels
Recently objtool has started reporting a few "unreachable instruction"
warnings when CONFIG_GCOV is enabled for newer versions of GCC. Usually
this warning means there's some new control flow that objtool doesn't
understand. But in this case, objtool is correct and the instructions
really are inaccessible. It's an annoying quirk of gcov, but it's
harmless, so it's ok to just silence the warnings.
With older versions of GCC, it was relatively easy to detect
gcov-specific instructions and to skip any unreachable warnings produced
by them. But GCC 6 has gotten craftier.
Instead of continuing to play whack-a-mole with gcov, just use a bigger,
more permanent hammer and disable unreachable warnings for the whole
file when gcov is enabled. This is fine to do because a) unreachable
warnings are usually of questionable value; and b) gcov isn't used for
production kernels and we can relax the checks a bit there.
Reported-by: kbuild test robot <fengguang.wu@intel.com>
Signed-off-by: Josh Poimboeuf <jpoimboe@redhat.com>
Cc: Andy Lutomirski <luto@kernel.org>
Cc: Arnd Bergmann <arnd@arndb.de>
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/38d5c87d61d9cd46486dd2c86f46603dff0df86f.1476393584.git.jpoimboe@redhat.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Josh Poimboeuf [Thu, 13 Oct 2016 21:22:52 +0000 (16:22 -0500)]
objtool: Improve rare switch jump table pattern detection
GCC 6 added a new switch statement jump table optimization which makes
objtool's life harder. It looks like:
mov [rodata addr],%reg1
... some instructions ...
jmpq *(%reg1,%reg2,8)
The optimization is quite rare, but objtool still needs to be able to
identify the pattern so that it can follow all possible control flow
paths related to the switch statement.
In order to detect the pattern, objtool starts from the indirect jump
and scans backwards through the function until it finds the first
instruction in the pattern. If it encounters an unconditional jump
along the way, it stops and considers the pattern to be not found.
As it turns out, unconditional jumps can happen, as long as they are
small forward jumps within the range being scanned.
This fixes the following warnings:
drivers/infiniband/sw/rxe/rxe_comp.o: warning: objtool: rxe_completer()+0x2f4: sibling call from callable instruction with changed frame pointer
drivers/infiniband/sw/rxe/rxe_resp.o: warning: objtool: rxe_responder()+0x10f: sibling call from callable instruction with changed frame pointer
Reported-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Josh Poimboeuf <jpoimboe@redhat.com>
Cc: 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/8a9ed68ae1780e8d3963e4ee13f2f257fe3a3c33.1476393584.git.jpoimboe@redhat.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Nikolay Borisov [Mon, 10 Oct 2016 12:38:18 +0000 (15:38 +0300)]
ceph: fix error handling in ceph_read_iter
In case __ceph_do_getattr returns an error and the retry_op in
ceph_read_iter is not READ_INLINE, then it's possible to invoke
__free_page on a page which is NULL, this naturally leads to a crash.
This can happen when, for example, a process waiting on a MDS reply
receives sigterm.
Fix this by explicitly checking whether the page is set or not.
Cc: stable@vger.kernel.org # 3.19+
Signed-off-by: Nikolay Borisov <kernel@kyup.com>
Reviewed-by: Yan, Zheng <zyan@redhat.com>
Signed-off-by: Ilya Dryomov <idryomov@gmail.com>
Ilya Dryomov [Thu, 29 Sep 2016 12:23:12 +0000 (14:23 +0200)]
rbd: don't retry watch reregistration if header object is gone
If the header object gets deleted (perhaps along with the entire pool),
there is no point in attempting to reregister the watch. Treat this
the same as blacklisting: fail all pending and new I/Os requiring the
lock.
Signed-off-by: Ilya Dryomov <idryomov@gmail.com>
projects / GitHub / moto-9609 / android_kernel_motorola_exynos9610.git / log