Heiko Carstens [Wed, 5 Mar 2014 09:43:51 +0000 (10:43 +0100)]
fs/compat: optional preadv64/pwrite64 compat system calls
The preadv64/pwrite64 have been implemented for the x32 ABI, in order
to allow passing 64 bit arguments from user space without splitting
them into two 32 bit parameters, like it would be necessary for usual
compat tasks.
Howevert these two system calls are only being used for the x32 ABI,
so add __ARCH_WANT_COMPAT defines for these two compat syscalls and
make these two only visible for x86.
Heiko Carstens [Tue, 4 Mar 2014 11:39:03 +0000 (12:39 +0100)]
ipc/compat_sys_msgrcv: change msgtyp type from long to compat_long_t
Change the type of compat_sys_msgrcv's msgtyp parameter from long
to compat_long_t, since compat user space passes only a 32 bit signed
value.
Let the compat wrapper do proper sign extension to 64 bit of this
parameter.
Heiko Carstens [Mon, 3 Mar 2014 09:06:12 +0000 (10:06 +0100)]
s390/compat: partial parameter conversion within syscall wrappers
Parameter conversion within the system call wrappers is only needed
for parameters which differ in size and have a size of eight bytes on
64 bit.
For system call parameters with a size of less than eight byte the
called system call itself will perform parameter conversion anyway.
So we can save the double conversion of e.g. int parameters.
The only types which need to be converted are therefore pointer and
(unsigned) long parameters.
Heiko Carstens [Sat, 1 Mar 2014 12:45:03 +0000 (13:45 +0100)]
s390/compat: automatic zero, sign and pointer conversion of syscalls
Instead of explicitly changing compat system call parameters from e.g.
unsigned long to compat_ulong_t let the COMPAT_SYSCALL_WRAP macros
automatically detect (unsigned) long parameters and zero and sign
extend them automatically.
The resulting binary is completely identical.
In addition add a sys_[system call name] prototype for each system call
wrapper. This will cause compile errors if the prototype does not match
the prototype in include/linux/syscall.h.
Therefore we should now always get the correct zero and sign extension
of system call parameters. Pointers are handled like before.
Heiko Carstens [Sat, 1 Mar 2014 12:09:26 +0000 (13:09 +0100)]
s390/compat: add sync_file_range and fallocate compat syscalls
The compat syscall wrappers for sync_file_range and fallocate merged 32 bit
parameters into 64 bit parameters. Therefore they did more than just the
usual zero and/or sign extension of system call parameters.
So convert these two wrappers to full s390 specific compat sytem calls.
Heiko Carstens [Thu, 27 Feb 2014 08:52:01 +0000 (09:52 +0100)]
s390/compat: convert system call wrappers to C part 01
Introduce a new compat_wrap.c file which contains the s390 specific compat
system call wrappers.
The s390 specific system call wrappers only perform sign, zero and pointer
conversion of system call arguments before actually calling the non-compat
system call.
Therefore introduce COMPAT_SYSCALL_WRAPx macros which generate C code that
is nearly identical to the assembly code. This has the advantage that the
compile will generate correct code, and we avoid the frequent copy-paste
errors seen in the compat_wrapper.S file.
Heiko Carstens [Mon, 3 Mar 2014 09:44:03 +0000 (10:44 +0100)]
compat: let architectures define __ARCH_WANT_COMPAT_SYS_GETDENTS64
For architecture dependent compat syscalls in common code an architecture
must define something like __ARCH_WANT_<WHATEVER> if it wants to use the
code.
This however is not true for compat_sys_getdents64 for which architectures
must define __ARCH_OMIT_COMPAT_SYS_GETDENTS64 if they do not want the code.
This leads to the situation where all architectures, except mips, get the
compat code but only x86_64, arm64 and the generic syscall architectures
actually use it.
So invert the logic, so that architectures actively must do something to
get the compat code.
This way a couple of architectures get rid of otherwise dead code.
Linus Torvalds [Sun, 2 Mar 2014 23:15:07 +0000 (15:15 -0800)]
Merge tag 'usb-3.14-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb
Pull USB fixes from Greg KH:
"Here are 2 USB patches for 3.14-rc5, one a new device id, and the
other fixes a reported problem with threaded irqs and the USB EHCI
driver"
* tag 'usb-3.14-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb:
usb: ehci: fix deadlock when threadirqs option is used
USB: ftdi_sio: add Cressi Leonardo PID
Linus Torvalds [Sun, 2 Mar 2014 23:12:54 +0000 (15:12 -0800)]
Merge tag 'staging-3.14-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging
Pull staging tree fixes from Greg KH:
"Here are a few IIO fixes, and a new device id for a staging driver for
3.14-rc5. All have been in linux-next for a while, I did a final
merge to get the IIO fixes into this tree, they were incorrectly in
the char-misc tree for a few weeks, and I forgot to tell you to pull
them from there. This makes it a single pull request for you"
* tag 'staging-3.14-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging:
staging: r8188eu: Add new device ID
staging:iio:adc:MXS:LRADC: fix touchscreen statemachine
iio:gyro: bug on L3GD20H gyroscope support
iio: cm32181: Change cm32181 ambient light sensor driver
iio: cm36651: Fix read/write integration time function.
Dave Airlie [Sun, 2 Mar 2014 23:04:41 +0000 (09:04 +1000)]
Merge branch 'drm-fixes-3.14' of git://people.freedesktop.org/~agd5f/linux into drm-fixes
more radeon fixes
* 'drm-fixes-3.14' of git://people.freedesktop.org/~agd5f/linux:
drm/radeon: enable speaker allocation setup on dce3.2
drm/radeon: change audio enable logic
drm/radeon: fix audio disable on dce6+
drm/radeon: free uvd ring on unload
drm/radeon: disable pll sharing for DP on DCE4.1
drm/radeon: fix missing bo reservation
drm/radeon: print the supported atpx function mask
Dave Airlie [Sun, 2 Mar 2014 10:54:31 +0000 (20:54 +1000)]
Merge tag 'vmwgfx-fixes-3.14-2014-03-02' of git://people.freedesktop.org/~thomash/linux into drm-fixes
A couple of minor fixes.
Pull request of 2014-03-02
* tag 'vmwgfx-fixes-3.14-2014-03-02' of git://people.freedesktop.org/~thomash/linux:
drm/vmwgfx: avoid null pointer dereference at failure paths
drm/vmwgfx: Make sure backing mobs are cleared when allocated. Update driver date.
drm/vmwgfx: Remove some unused surface formats
drm/vmwgfx: avoid null pointer dereference at failure paths
vmw_takedown_otable_base() and vmw_mob_unbind() check for
potential vmw_fifo_reserve() failure and print error message,
but then immediately dereference NULL pointer.
Found by Linux Driver Verification project (linuxtesting.org).
Signed-off-by: Alexey Khoroshilov <khoroshilov@ispras.ru> Reviewed-by: Thomas Hellstrom <thellstrom@vmware.com>
Thomas Hellstrom [Fri, 28 Feb 2014 12:33:21 +0000 (13:33 +0100)]
drm/vmwgfx: Make sure backing mobs are cleared when allocated. Update driver date.
Backing mob contents is propagated to user-space, so make sure backing
mobs are cleared when allocated. This also accidently fix rendering errors
with celestia when emulating legacy mode.
Also update driver date.
Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com> Reviewed-by: Brian Paul <brianp@vmware.com>
Linus Torvalds [Sun, 2 Mar 2014 04:48:14 +0000 (22:48 -0600)]
Merge branch 'x86-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip
Pull x86 fixes from Peter Anvin:
"The VMCOREINFO patch I'll pushing for this release to avoid having a
release with kASLR and but without that information.
I was hoping to include the FPU patches from Suresh, but ran into a
problem (see other thread); will try to make them happen next week"
* 'x86-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
x86, kaslr: add missed "static" declarations
x86, kaslr: export offset in VMCOREINFO ELF notes
Pull SCSI target fixes from Nicholas Bellinger:
"The bulk of the series are bugfixes for qla2xxx target NPIV support
that went in for v3.14-rc1. Also included are a few DIF related
fixes, a qla2xxx fix (Cc'ed to stable) from Greg W., and vhost/scsi
protocol version related fix from Venkatesh.
Also just a heads up that a series to address a number of issues with
iser-target active I/O reset/shutdown is still being tested, and will
be included in a separate -rc6 PULL request"
* git://git.kernel.org/pub/scm/linux/kernel/git/nab/target-pending:
vhost/scsi: Check LUN structure byte 0 is set to 1, per spec
qla2xxx: Fix kernel panic on selective retransmission request
Target/sbc: Don't use sg as iterator in sbc_verify_read
target: Add DIF sense codes in transport_generic_request_failure
target/sbc: Fix sbc_dif_copy_prot addr offset bug
tcm_qla2xxx: Fix NAA formatted name for NPIV WWPNs
tcm_qla2xxx: Perform configfs depend/undepend for base_tpg
tcm_qla2xxx: Add NPIV specific enable/disable attribute logic
qla2xxx: Check + fail when npiv_vports_inuse exists in shutdown
qla2xxx: Fix qlt_lport_register base_vha callback race
Linus Torvalds [Sun, 2 Mar 2014 03:30:43 +0000 (21:30 -0600)]
Merge branch 'fixes' of git://git.infradead.org/users/vkoul/slave-dma
Pull slave-dma fixes from Vinod Koul:
"This request brings you two small fixes. First one for fixing
dereference of freed descriptor and second for fixing sdma bindings
for it to work for imx25.
I was planning to send this about 10days ago but then I had to proceed
on my paternity leave and didnt get chance to send this. Now got a
bit of time from dady duties :)"
Linus Torvalds [Sun, 2 Mar 2014 03:28:38 +0000 (21:28 -0600)]
Merge tag 'pm+acpi-3.14-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm
Pull ACPI and power management fixes from Rafael Wysocki:
"These three commits fix a recent intel_pstate regression and two old
bugs that should be fixed in -stable too, one in the ACPI processor
driver and one in the firmare loader.
Specifics:
- One of the recent intel_pstate driver fixes introduced a rounding
error that on some systems causes the frequency to be stuck at the
lowest level forever. Fix from Dirk Brandewie.
- The firmware_class driver's PM notifier doesn't handle the
PM_RESTORE_PREPARE event during hibernation image restore and that
leads to a deadlock on umhelper_sem in __usermodehelper_disable().
Fix from Sebastian Capella.
- acpi_processor_set_throttling() abuses set_cpus_allowed_ptr() in a
nasty way which triggers the WARN_ON_ONCE() in wq_worker_waking_up()
among other things. Fix from Lan Tianyu"
* tag 'pm+acpi-3.14-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm:
ACPI / processor: Rework processor throttling with work_on_cpu()
PM / hibernate: Fix restore hang in freeze_processes()
intel_pstate: Change busy calculation to use fixed point math.
Merge tag 'fixes-for-3.14d' of git://git.kernel.org/pub/scm/linux/kernel/git/jic23/iio into staging-linus
Jonathan writes:
Fourth set of IIO fixes for the 3.14 kernel.
A single line patch fixing a regression that was introduced in 3.13 in the
reworking of the mxs touch screen and ADC drivers to be interrupt rather
than polling driven. It resulted in a stray double reporting of the release
coordinate in the touch screen driver. The bug lay in the adc side
of the driver which left the statemachine in the wrong state.
Linus Torvalds [Fri, 28 Feb 2014 19:53:33 +0000 (11:53 -0800)]
Merge tag 'dm-3.14-fixes-1' of git://git.kernel.org/pub/scm/linux/kernel/git/device-mapper/linux-dm
Pull device mapper fixes from Mike Snitzer:
"A few dm-cache fixes, an invalid ioctl handling fix for dm multipath,
a couple immutable biovec fixups for dm mirror, and a few dm-thin
fixes.
There will likely be additional dm-thin metadata and data resize fixes
to include in 3.14-rc6 next week.
Note to stable-minded folks: Immutable biovecs were introduced in
3.14, so the related fixups for dm mirror are not needed in stable@
kernels"
* tag 'dm-3.14-fixes-1' of git://git.kernel.org/pub/scm/linux/kernel/git/device-mapper/linux-dm:
dm cache: fix truncation bug when mapping I/O to >2TB fast device
dm thin: allow metadata space larger than supported to go unused
dm mpath: fix stalls when handling invalid ioctls
dm thin: fix the error path for the thin device constructor
dm raid1: fix immutable biovec related BUG when retrying read bio
dm io: fix I/O to multiple destinations
dm thin: avoid metadata commit if a pool's thin devices haven't changed
dm cache: do not add migration to completed list before unhooking bio
dm cache: move hook_info into common portion of per_bio_data structure
Linus Torvalds [Fri, 28 Feb 2014 19:50:32 +0000 (11:50 -0800)]
Merge tag 'sound-3.14-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound
Pull sound fixes from Takashi Iwai:
"It's a bad habit to get a higher volume of fixes often lately, but
things happen again.
All commits found here are real bug fixes, and are mostly trivial.
Most of changes in ASoC are the fixes for enum items due to the wrong
API usages, in addition to a few DAPM mutex deadlock and other fixes.
In HD-audio, only fixups for HP laptops. Although diffstat shows
much, the changes are simple: there are just so many different device
entries there"
* tag 'sound-3.14-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound:
ASoC: sta32x: Fix wrong enum for limiter2 release rate
ASoC: da732x: Mark DC offset control registers volatile
ALSA: hda/realtek - Add more entry for enable HP mute led
ALSA: hda - Add a fixup for HP Folio 13 mute LED
ASoC: wm8958-dsp: Fix firmware block loading
ASoC: sta32x: Fix cache sync
ALSA: hda/realtek - Add more entry for enable HP mute led
ASoC: dapm: Add locking to snd_soc_dapm_xxxx_pin functions
Input - arizona-haptics: Fix double lock of dapm_mutex
ASoC: wm8400: Fix the wrong number of enum items
ASoC: isabelle: Fix the wrong number of items in enum ctls
ASoC: ad1980: Fix wrong number of items for capture source
ASoC: wm8994: Fix the wrong number of enum items
ASoC: wm8900: Fix the wrong number of enum items
ASoC: wm8770: Fix wrong number of enum items
ASoC: sta32x: Fix array access overflow
ASoC: dapm: Correct regulator bypass error messages
Linus Torvalds [Fri, 28 Feb 2014 19:49:09 +0000 (11:49 -0800)]
Merge tag 'edac_fixes_for_3.14' of git://git.kernel.org/pub/scm/linux/kernel/git/bp/bp
Pull EDAC fixes from Borislav Petkov:
"Two fixes below for PCI devices disappearing when a reference count
underflow happens after a couple of insmod/rmmod cycles in succession"
* tag 'edac_fixes_for_3.14' of git://git.kernel.org/pub/scm/linux/kernel/git/bp/bp:
i7300_edac: Fix device reference count
i7core_edac: Fix PCI device reference count
Linus Torvalds [Fri, 28 Feb 2014 19:45:03 +0000 (11:45 -0800)]
Merge tag 'for-linus' of git://git.kernel.org/pub/scm/virt/kvm/kvm
Pull KVM fixes from Paolo Bonzini:
"Three x86 fixes and one for ARM/ARM64.
In particular, nested virtualization on Intel is broken in 3.13 and
fixed by this pull request"
* tag 'for-linus' of git://git.kernel.org/pub/scm/virt/kvm/kvm:
kvm, vmx: Really fix lazy FPU on nested guest
kvm: x86: fix emulator buffer overflow (CVE-2014-0049)
arm/arm64: KVM: detect CPU reset on CPU_PM_EXIT
KVM: MMU: drop read-only large sptes when creating lower level sptes
Catalin Marinas [Fri, 28 Feb 2014 16:12:25 +0000 (16:12 +0000)]
arm64: Fix !CONFIG_SMP kernel build
Commit fb4a96029c8a (arm64: kernel: fix per-cpu offset restore on
resume) uses per_cpu_offset() unconditionally during CPU wakeup,
however, this is only defined for the SMP case.
Signed-off-by: Catalin Marinas <catalin.marinas@arm.com> Reported-by: Dave P Martin <Dave.Martin@arm.com>
Steve Capper [Tue, 25 Feb 2014 11:38:53 +0000 (11:38 +0000)]
arm64: mm: Add double logical invert to pte accessors
Page table entries on ARM64 are 64 bits, and some pte functions such as
pte_dirty return a bitwise-and of a flag with the pte value. If the
flag to be tested resides in the upper 32 bits of the pte, then we run
into the danger of the result being dropped if downcast.
For example:
gather_stats(page, md, pte_dirty(*pte), 1);
where pte_dirty(*pte) is downcast to an int.
This patch adds a double logical invert to all the pte_ accessors to
ensure predictable downcasting.
Signed-off-by: Steve Capper <steve.capper@linaro.org> Cc: <stable@vger.kernel.org> Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
dm cache: fix truncation bug when mapping I/O to >2TB fast device
When remapping a block to the cache's fast device that is larger than
2TB we must not truncate the destination sector to 32bits. The 32bit
temporary result of from_cblock() was being overflowed in
remap_to_cache() due to the logical left shift.
Use an intermediate 64bit type to store the 32bit from_cblock() result
to fix the overflow.
Signed-off-by: Heinz Mauelshagen <heinzm@redhat.com> Signed-off-by: Mike Snitzer <snitzer@redhat.com> Cc: stable@vger.kernel.org
Jiri Olsa [Wed, 26 Feb 2014 17:14:26 +0000 (18:14 +0100)]
perf tools: Fix strict alias issue for find_first_bit
When compiling perf tool code with gcc 4.4.7 I'm getting
following error:
CC util/session.o
cc1: warnings being treated as errors
util/session.c: In function ‘perf_session_deliver_event’:
tools/perf/util/include/linux/bitops.h:109: error: dereferencing pointer ‘p’ does break strict-aliasing rules
tools/perf/util/include/linux/bitops.h:101: error: dereferencing pointer ‘p’ does break strict-aliasing rules
util/session.c:697: note: initialized from here
tools/perf/util/include/linux/bitops.h:101: note: initialized from here
make[1]: *** [util/session.o] Error 1
make: *** [util/session.o] Error 2
The aliased types here are u64 and unsigned long pointers, which is safe
for the find_first_bit processing.
This error shows up for me only for gcc 4.4 on 32bit x86, even for
-Wstrict-aliasing=3, while newer gcc are quiet and scream here for
-Wstrict-aliasing={2,1}. Looks like newer gcc changed the rules for
strict alias warnings.
The gcc documentation offers workaround for valid aliasing by using
__may_alias__ attribute:
The OPAL firmware functions opal_xscom_read and opal_xscom_write
take a 64-bit argument for the XSCOM (PCB) address in order to
support the indirect mode on P8.
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org> CC: <stable@vger.kernel.org> [v3.13]
[ The current diag data is so big that it overflows the printk
buffer pretty quickly in cases when we get a handful of errors
at once which can happen. --BenH
]
Signed-off-by: Gavin Shan <shangw@linux.vnet.ibm.com> CC: <stable@vger.kernel.org> Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Gavin Shan [Tue, 25 Feb 2014 07:28:37 +0000 (15:28 +0800)]
powerpc/powernv: Dump PHB diag-data immediately
The PHB diag-data is important to help locating the root cause for
EEH errors such as frozen PE or fenced PHB. However, the EEH core
enables IO path by clearing part of HW registers before collecting
this data causing it to be corrupted.
This patch fixes this by dumping the PHB diag-data immediately when
frozen/fenced state on PE or PHB is detected for the first time in
eeh_ops::get_state() or next_error() backend.
Signed-off-by: Gavin Shan <shangw@linux.vnet.ibm.com> CC: <stable@vger.kernel.org> Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Paul Mackerras [Wed, 26 Feb 2014 06:07:38 +0000 (17:07 +1100)]
powerpc: Increase stack redzone for 64-bit userspace to 512 bytes
The new ELFv2 little-endian ABI increases the stack redzone -- the
area below the stack pointer that can be used for storing data --
from 288 bytes to 512 bytes. This means that we need to allow more
space on the user stack when delivering a signal to a 64-bit process.
To make the code a bit clearer, we define new USER_REDZONE_SIZE and
KERNEL_REDZONE_SIZE symbols in ptrace.h. For now, we leave the
kernel redzone size at 288 bytes, since increasing it to 512 bytes
would increase the size of interrupt stack frames correspondingly.
Gcc currently only makes use of 288 bytes of redzone even when
compiling for the new little-endian ABI, and the kernel cannot
currently be compiled with the new ABI anyway.
In the future, hopefully gcc will provide an option to control the
amount of redzone used, and then we could reduce it even more.
This also changes the code in arch_compat_alloc_user_space() to
preserve the expanded redzone. It is not clear why this function would
ever be used on a 64-bit process, though.
Signed-off-by: Paul Mackerras <paulus@samba.org> CC: <stable@vger.kernel.org> [v3.13] Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Laurent Dufour [Mon, 24 Feb 2014 16:30:55 +0000 (17:30 +0100)]
powerpc/crashdump : Fix page frame number check in copy_oldmem_page
In copy_oldmem_page, the current check using max_pfn and min_low_pfn to
decide if the page is backed or not, is not valid when the memory layout is
not continuous.
This happens when running as a QEMU/KVM guest, where RTAS is mapped higher
in the memory. In that case max_pfn points to the end of RTAS, and a hole
between the end of the kdump kernel and RTAS is not backed by PTEs. As a
consequence, the kdump kernel is crashing in copy_oldmem_page when accessing
in a direct way the pages in that hole.
This fix relies on the memblock's service memblock_is_region_memory to
check if the read page is part or not of the directly accessible memory.
Tony Breeds [Thu, 20 Feb 2014 10:13:52 +0000 (21:13 +1100)]
powerpc/le: Ensure that the 'stop-self' RTAS token is handled correctly
Currently we're storing a host endian RTAS token in
rtas_stop_self_args.token. We then pass that directly to rtas. This is
fine on big endian however on little endian the token is not what we
expect.
This will typically result in hitting:
panic("Alas, I survived.\n");
To fix this we always use the stop-self token in host order and always
convert it to be32 before passing this to rtas.
Signed-off-by: Tony Breeds <tony@bakeyournoodle.com> Cc: stable@vger.kernel.org Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Paolo Bonzini [Thu, 27 Feb 2014 21:54:11 +0000 (22:54 +0100)]
kvm, vmx: Really fix lazy FPU on nested guest
Commit e504c9098ed6 (kvm, vmx: Fix lazy FPU on nested guest, 2013-11-13)
highlighted a real problem, but the fix was subtly wrong.
nested_read_cr0 is the CR0 as read by L2, but here we want to look at
the CR0 value reflecting L1's setup. In other words, L2 might think
that TS=0 (so nested_read_cr0 has the bit clear); but if L1 is actually
running it with TS=1, we should inject the fault into L1.
The effective value of CR0 in L2 is contained in vmcs12->guest_cr0, use
it.
Jerome Glisse [Thu, 27 Feb 2014 00:22:47 +0000 (19:22 -0500)]
drm/radeon: free uvd ring on unload
Need to free the uvd ring. Also reshuffle gart tear down to
happen after uvd tear down.
Signed-off-by: Jérôme Glisse <jglisse@redhat.com> Cc: stable@vger.kernel.org Reviewed-by: Christian König <christian.koenig@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Linus Torvalds [Thu, 27 Feb 2014 18:54:52 +0000 (10:54 -0800)]
Merge tag 'metag-fixes-v3.14' of git://git.kernel.org/pub/scm/linux/kernel/git/jhogan/metag
Pull Metag arch and asm-generic fixes from James Hogan:
- Add the new sched_setattr/sched_getattr syscalls to the asm-generic
syscall list, which is used by arc, arm64, c6x, hexagon, metag,
openrisc, score, tile, and unicore32.
- An IRQ affinity bug fix for metag to prevent interrupts being
vectored to offline CPUs when their affinity is changed via
/proc/irq/ (thanks tglx).
* tag 'metag-fixes-v3.14' of git://git.kernel.org/pub/scm/linux/kernel/git/jhogan/metag:
irq-metag*: stop set_affinity vectoring to offline cpus
asm-generic: add sched_setattr/sched_getattr syscalls
Linus Torvalds [Thu, 27 Feb 2014 18:54:20 +0000 (10:54 -0800)]
Merge tag 'pwm/for-3.14-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/thierry.reding/linux-pwm
Pull pwm fix from Thierry Reding:
"Just a single trivial patch to plug a memory leak in an error path"
* tag 'pwm/for-3.14-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/thierry.reding/linux-pwm:
pwm: lp3943: Fix potential memory leak during request
Linus Torvalds [Thu, 27 Feb 2014 18:37:22 +0000 (10:37 -0800)]
Merge branch 'for_linus' of git://git.kernel.org/pub/scm/linux/kernel/git/jack/linux-fs
Pull filesystem fixes from Jan Kara:
"Notification, writeback, udf, quota fixes
The notification patches are (with one exception) a fallout of my
fsnotify rework which went into -rc1 (I've extented LTP to cover these
cornercases to avoid similar breakage in future).
The UDF patch is a nasty data corruption Al has recently reported,
the revert of the writeback patch is due to possibility of violating
sync(2) guarantees, and a quota bug can lead to corruption of quota
files in ocfs2"
* 'for_linus' of git://git.kernel.org/pub/scm/linux/kernel/git/jack/linux-fs:
fsnotify: Allocate overflow events with proper type
fanotify: Handle overflow in case of permission events
fsnotify: Fix detection whether overflow event is queued
Revert "writeback: do not sync data dirtied after sync start"
quota: Fix race between dqput() and dquot_scan_active()
udf: Fix data corruption on file type conversion
inotify: Fix reporting of cookies for inotify events
The problem occurs when the guest performs a pusha with the stack
address pointing to an mmio address (or an invalid guest physical
address) to start with, but then extending into an ordinary guest
physical address. When doing repeated emulated pushes
emulator_read_write sets mmio_needed to 1 on the first one. On a
later push when the stack points to regular memory,
mmio_nr_fragments is set to 0, but mmio_is_needed is not set to 0.
As a result, KVM exits to userspace, and then returns to
complete_emulated_mmio. In complete_emulated_mmio
vcpu->mmio_cur_fragment is incremented. The termination condition of
vcpu->mmio_cur_fragment == vcpu->mmio_nr_fragments is never achieved.
The code bounces back and fourth to userspace incrementing
mmio_cur_fragment past it's buffer. If the guest does nothing else it
eventually leads to a a crash on a memcpy from invalid memory address.
However if a guest code can cause the vm to be destroyed in another
vcpu with excellent timing, then kvm_clear_async_pf_completion_queue
can be used by the guest to control the data that's pointed to by the
call to cancel_work_item, which can be used to gain execution.
Fixes: f78146b0f9230765c6315b2e14f56112513389ad Signed-off-by: Andrew Honig <ahonig@google.com> Cc: stable@vger.kernel.org (3.5+) Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Marc Zyngier [Wed, 26 Feb 2014 18:47:36 +0000 (18:47 +0000)]
arm/arm64: KVM: detect CPU reset on CPU_PM_EXIT
Commit 1fcf7ce0c602 (arm: kvm: implement CPU PM notifier) added
support for CPU power-management, using a cpu_notifier to re-init
KVM on a CPU that entered CPU idle.
The code assumed that a CPU entering idle would actually be powered
off, loosing its state entierely, and would then need to be
reinitialized. It turns out that this is not always the case, and
some HW performs CPU PM without actually killing the core. In this
case, we try to reinitialize KVM while it is still live. It ends up
badly, as reported by Andre Przywara (using a Calxeda Midway):
[ 3.663897] Kernel panic - not syncing: unexpected prefetch abort in Hyp mode at: 0x685760
[ 3.663897] unexpected data abort in Hyp mode at: 0xc067d150
[ 3.663897] unexpected HVC/SVC trap in Hyp mode at: 0xc0901dd0
The trick here is to detect if we've been through a full re-init or
not by looking at HVBAR (VBAR_EL2 on arm64). This involves
implementing the backend for __hyp_get_vectors in the main KVM HYP
code (rather small), and checking the return value against the
default one when the CPU notifier is called on CPU_PM_EXIT.
Reported-by: Andre Przywara <osp@andrep.de> Tested-by: Andre Przywara <osp@andrep.de> Cc: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Cc: Rob Herring <rob.herring@linaro.org> Acked-by: Christoffer Dall <christoffer.dall@linaro.org> Signed-off-by: Marc Zyngier <marc.zyngier@arm.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Mike Snitzer [Thu, 13 Feb 2014 04:58:15 +0000 (23:58 -0500)]
dm thin: allow metadata space larger than supported to go unused
It was always intended that a user could provide a thin metadata device
that is larger than the max supported by the on-disk format. The extra
space would just go unused.
Unfortunately that never worked. If the user attempted to use a larger
metadata device on creation they would get an error like the following:
device-mapper: space map common: space map too large
device-mapper: transaction manager: couldn't create metadata space map
device-mapper: thin metadata: tm_create_with_sm failed
device-mapper: table: 252:17: thin-pool: Error creating metadata object
device-mapper: ioctl: error adding target to table
Fix this by allowing the initial metadata space map creation to cap its
size at the max number of blocks supported (DM_SM_METADATA_MAX_BLOCKS).
get_metadata_dev_size() must also impose DM_SM_METADATA_MAX_BLOCKS (via
THIN_METADATA_MAX_SECTORS), otherwise extending metadata would cap at
THIN_METADATA_MAX_SECTORS_WARNING (which is larger than supported).
Also, the calculation for THIN_METADATA_MAX_SECTORS didn't account for
the sizeof the disk_bitmap_header. So the supported maximum metadata
size is a bit smaller (reduced from 33423360 to 33292800 sectors).
Lastly, remove the "excess space will not be used" warning message from
get_metadata_dev_size(); it resulted in printing the warning multiple
times. Factor out warn_if_metadata_device_too_big(), call it from
pool_ctr() and maybe_resize_metadata_dev().
Signed-off-by: Mike Snitzer <snitzer@redhat.com> Acked-by: Joe Thornber <ejt@redhat.com>
Peter Zijlstra [Mon, 24 Feb 2014 11:06:12 +0000 (12:06 +0100)]
perf: Fix hotplug splat
Drew Richardson reported that he could make the kernel go *boom* when hotplugging
while having perf events active.
It turned out that when you have a group event, the code in
__perf_event_exit_context() fails to remove the group siblings from
the context.
We then proceed with destroying and freeing the event, and when you
re-plug the CPU and try and add another event to that CPU, things go
*boom* because you've still got dead entries there.
Reported-by: Drew Richardson <drew.richardson@arm.com> Signed-off-by: Peter Zijlstra <peterz@infradead.org> Cc: Will Deacon <will.deacon@arm.com> Cc: <stable@vger.kernel.org> Link: http://lkml.kernel.org/n/tip-k6v5wundvusvcseqj1si0oz0@git.kernel.org Signed-off-by: Ingo Molnar <mingo@kernel.org>
Peter Zijlstra [Fri, 21 Feb 2014 15:03:12 +0000 (16:03 +0100)]
perf/x86: Fix event scheduling
Vince "Super Tester" Weaver reported a new round of syscall fuzzing (Trinity) failures,
with perf WARN_ON()s triggering. He also provided traces of the failures.
We try and add the {BP,cycles,br_insn} group (fd[3], fd[4], fd[15]).
These events are 0:cycles and 4:br_insn, the BP event isn't x86_pmu so
that's not visible.
group_sched_in()
pmu->start_txn() /* nop - BP pmu */
event_sched_in()
event->pmu->add()
But seeing the below state on x86_pmu_enable(), the must have failed,
because the 0 and 4 events aren't there anymore.
Looking at group_sched_in(), since the BP is the leader, its
event_sched_in() must have succeeded, for otherwise we would not have
seen the sibling adds.
But since neither 0 or 4 are in the below state; their event_sched_in()
must have failed; but I don't see why, the complete state: 0,0,1:p,4
fits perfectly fine on a core2.
However, since we try and schedule 4 it means the 0 event must have
succeeded! Therefore the 4 event must have failed, its failure will
have put group_sched_in() into the fail path, which will call:
event_sched_out()
event->pmu->del()
on 0 and the BP event.
Now x86_pmu_del() will reduce n_events; but it will not reduce n_added;
giving what we see below:
So the problem is that x86_pmu_del(), when called from a
group_sched_in() that fails (for whatever reason), and without x86_pmu
TXN support (because the leader is !x86_pmu), will corrupt the n_added
state.
Reported-and-Tested-by: Vince Weaver <vincent.weaver@maine.edu> Signed-off-by: Peter Zijlstra <peterz@infradead.org> Cc: Paul Mackerras <paulus@samba.org> Cc: Steven Rostedt <rostedt@goodmis.org> Cc: Stephane Eranian <eranian@google.com> Cc: Dave Jones <davej@redhat.com> Cc: <stable@vger.kernel.org> Link: http://lkml.kernel.org/r/20140221150312.GF3104@twins.programming.kicks-ass.net Signed-off-by: Ingo Molnar <mingo@kernel.org>
Mark Brown [Thu, 27 Feb 2014 11:26:07 +0000 (20:26 +0900)]
Merge tag 'asoc-v3.14-rc4' into asoc-linus
ASoC: Fixes for v3.14
A somewhat large set of fixes here due to the identification of some
systematic problems with hard to use APIs in the subsystem. Takashi did
a lot of work to address the enumeration API which uncovered a number of
off by one bugs caused by confusing APIs while Charles addressed issues
in the locking around DAPM.
# gpg: Signature made Sun 23 Feb 2014 13:29:34 KST using RSA key ID 7EA229BD
# gpg: Good signature from "Mark Brown <broonie@sirena.org.uk>"
# gpg: aka "Mark Brown <broonie@debian.org>"
# gpg: aka "Mark Brown <broonie@kernel.org>"
# gpg: aka "Mark Brown <broonie@tardis.ed.ac.uk>"
# gpg: aka "Mark Brown <broonie@linaro.org>"
# gpg: aka "Mark Brown <Mark.Brown@linaro.org>"
Mark Brown [Thu, 27 Feb 2014 11:26:07 +0000 (20:26 +0900)]
Merge tag 'asoc-v3.14-rc3' into asoc-linus
ASoC: Fixes for v3.14
A few fixes, all driver speccific ones. The DaVinci ones aren't as
clear as they should be from the subject lines on the commits but they
fix issues which will prevent correct operation in some use cases and
only affect that particular driver so are reasonably safe.
# gpg: Signature made Wed 19 Feb 2014 13:23:13 KST using RSA key ID 7EA229BD
# gpg: Good signature from "Mark Brown <broonie@sirena.org.uk>"
# gpg: aka "Mark Brown <broonie@debian.org>"
# gpg: aka "Mark Brown <broonie@kernel.org>"
# gpg: aka "Mark Brown <broonie@tardis.ed.ac.uk>"
# gpg: aka "Mark Brown <broonie@linaro.org>"
# gpg: aka "Mark Brown <Mark.Brown@linaro.org>"
Takashi Iwai [Thu, 27 Feb 2014 06:41:32 +0000 (07:41 +0100)]
ASoC: sta32x: Fix wrong enum for limiter2 release rate
There is a typo in the Limiter2 Release Rate control, a wrong enum for
Limiter1 is assigned. It must point to Limiter2.
Spotted by a compile warning:
In file included from sound/soc/codecs/sta32x.c:34:0:
sound/soc/codecs/sta32x.c:223:29: warning: ‘sta32x_limiter2_release_rate_enum’ defined but not used [-Wunused-variable]
static SOC_ENUM_SINGLE_DECL(sta32x_limiter2_release_rate_enum,
^
include/sound/soc.h:275:18: note: in definition of macro ‘SOC_ENUM_DOUBLE_DECL’
struct soc_enum name = SOC_ENUM_DOUBLE(xreg, xshift_l, xshift_r, \
^
sound/soc/codecs/sta32x.c:223:8: note: in expansion of macro ‘SOC_ENUM_SINGLE_DECL’
static SOC_ENUM_SINGLE_DECL(sta32x_limiter2_release_rate_enum,
^
Signed-off-by: Takashi Iwai <tiwai@suse.de> Signed-off-by: Mark Brown <broonie@linaro.org> Cc: <stable@vger.kernel.org>
Takashi Iwai [Thu, 27 Feb 2014 06:16:15 +0000 (07:16 +0100)]
Merge tag 'asoc-v3.14-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound into for-linus
ASoC: Fixes for v3.14
A somewhat large set of fixes here due to the identification of some
systematic problems with hard to use APIs in the subsystem. Takashi did
a lot of work to address the enumeration API which uncovered a number of
off by one bugs caused by confusing APIs while Charles addressed issues
in the locking around DAPM.
Alex Deucher [Tue, 18 Feb 2014 15:03:44 +0000 (10:03 -0500)]
MAINTAINERS: update drm git tree entry
Fix Dave's git tree.
Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Reviewed-by: Christian König <christian.koenig@amd.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
Alex Deucher [Tue, 18 Feb 2014 15:03:43 +0000 (10:03 -0500)]
MAINTAINERS: add entry for drm radeon driver
Add an entry for radeon.
Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Reviewed-by: Christian König <christian.koenig@amd.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
usb: ehci: fix deadlock when threadirqs option is used
ehci_irq() and ehci_hrtimer_func() can deadlock on ehci->lock when
threadirqs option is used. To prevent the deadlock use
spin_lock_irqsave() in ehci_irq().
This change can be reverted when hrtimer callbacks become threaded.
Joerg Dorchain [Fri, 21 Feb 2014 19:29:33 +0000 (20:29 +0100)]
USB: ftdi_sio: add Cressi Leonardo PID
Hello,
the following patch adds an entry for the PID of a Cressi Leonardo
diving computer interface to kernel 3.13.0.
It is detected as FT232RL.
Works with subsurface.
Lan Tianyu [Wed, 26 Feb 2014 13:03:05 +0000 (21:03 +0800)]
ACPI / processor: Rework processor throttling with work_on_cpu()
acpi_processor_set_throttling() uses set_cpus_allowed_ptr() to make
sure that the (struct acpi_processor)->acpi_processor_set_throttling()
callback will run on the right CPU. However, the function may be
called from a worker thread already bound to a different CPU in which
case that won't work.
Make acpi_processor_set_throttling() use work_on_cpu() as appropriate
instead of abusing set_cpus_allowed_ptr().
Reported-and-tested-by: Jiri Olsa <jolsa@redhat.com> Signed-off-by: Lan Tianyu <tianyu.lan@intel.com> Cc: All applicable <stable@vger.kernel.org>
[rjw: Changelog] Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Marcelo Tosatti [Mon, 24 Feb 2014 16:59:32 +0000 (13:59 -0300)]
KVM: MMU: drop read-only large sptes when creating lower level sptes
Read-only large sptes can be created due to read-only faults as
follows:
- QEMU pagetable entry that maps guest memory is read-only
due to COW.
- Guest read faults such memory, COW is not broken, because
it is a read-only fault.
- Enable dirty logging, large spte not nuked because it is read-only.
- Write-fault on such memory causes guest to loop endlessly
(which must go down to level 1 because dirty logging is enabled).
Fix by dropping large spte when necessary.
Signed-off-by: Marcelo Tosatti <mtosatti@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
pwm: lp3943: Fix potential memory leak during request
Fix a memory leak in the lp3943_pwm_request_map() error handling path.
Make sure already allocated pwm map memory is freed correctly.
Detected by Coverity: CID 1162829.
Signed-off-by: Christian Engelmayer <cengelma@gmx.at> Acked-by: Milo Kim <milo.kim@ti.com> Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
projects / linux-beck.git / log