Steven Whitehouse [Mon, 31 Mar 2014 16:48:27 +0000 (17:48 +0100)]
GFS2: Fix address space from page function
commit
1b2ad41214c9bf6e8befa000f0522629194bf540 upstream.
Now that rgrps use the address space which is part of the super
block, we need to update gfs2_mapping2sbd() to take account of
that. The only way to do that easily is to use a different set
of address_space_operations for rgrps.
Reported-by: Abhi Das <adas@redhat.com>
Tested-by: Abhi Das <adas@redhat.com>
Signed-off-by: Steven Whitehouse <swhiteho@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Ben Dooks [Fri, 8 Nov 2013 18:29:25 +0000 (18:29 +0000)]
ARM: probes: fix instruction fetch order with <asm/opcodes.h>
commit
888be25402021a425da3e85e2d5a954d7509286e upstream.
If we are running BE8, the data and instruction endianness do not
match, so use <asm/opcodes.h> to correctly translate memory accesses
into ARM instructions.
Acked-by: Jon Medhurst <tixy@linaro.org>
Signed-off-by: Ben Dooks <ben.dooks@codethink.co.uk>
[taras.kondratiuk@linaro.org: fixed Thumb instruction fetch order]
Signed-off-by: Taras Kondratiuk <taras.kondratiuk@linaro.org>
[wangnan: backport to 3.10 and 3.14:
- adjust context
- backport all changes on arch/arm/kernel/probes.c to
arch/arm/kernel/kprobes-common.c since we don't have
commit
c18377c303787ded44b7decd7dee694db0f205e9.
- After the above adjustments, becomes same to Taras Kondratiuk's
original patch:
http://lists.linaro.org/pipermail/linaro-kernel/2014-January/010346.html
]
Signed-off-by: Wang Nan <wangnan0@huawei.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Pablo Neira [Tue, 29 Jul 2014 16:12:15 +0000 (18:12 +0200)]
netfilter: xt_bpf: add mising opaque struct sk_filter definition
commit
e10038a8ec06ac819b7552bb67aaa6d2d6f850c1 upstream.
This structure is not exposed to userspace, so fix this by defining
struct sk_filter; so we skip the casting in kernelspace. This is safe
since userspace has no way to lurk with that internal pointer.
Fixes: e6f30c7 ("netfilter: x_tables: add xt_bpf match")
Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
Acked-by: Willem de Bruijn <willemb@google.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Arturo Borrero [Sun, 26 Oct 2014 11:22:40 +0000 (12:22 +0100)]
netfilter: nft_compat: fix wrong target lookup in nft_target_select_ops()
commit
7965ee93719921ea5978f331da653dfa2d7b99f5 upstream.
The code looks for an already loaded target, and the correct list to search
is nft_target_list, not nft_match_list.
Signed-off-by: Arturo Borrero Gonzalez <arturo.borrero.glez@gmail.com>
Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Houcheng Lin [Thu, 23 Oct 2014 08:36:08 +0000 (10:36 +0200)]
netfilter: nf_log: release skbuff on nlmsg put failure
commit
b51d3fa364885a2c1e1668f88776c67c95291820 upstream.
The kernel should reserve enough room in the skb so that the DONE
message can always be appended. However, in case of e.g. new attribute
erronously not being size-accounted for, __nfulnl_send() will still
try to put next nlmsg into this full skbuf, causing the skb to be stuck
forever and blocking delivery of further messages.
Fix issue by releasing skb immediately after nlmsg_put error and
WARN() so we can track down the cause of such size mismatch.
[ fw@strlen.de: add tailroom/len info to WARN ]
Signed-off-by: Houcheng Lin <houcheng@gmail.com>
Signed-off-by: Florian Westphal <fw@strlen.de>
Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Florian Westphal [Thu, 23 Oct 2014 08:36:07 +0000 (10:36 +0200)]
netfilter: nfnetlink_log: fix maximum packet length logged to userspace
commit
c1e7dc91eed0ed1a51c9b814d648db18bf8fc6e9 upstream.
don't try to queue payloads > 0xffff - NLA_HDRLEN, it does not work.
The nla length includes the size of the nla struct, so anything larger
results in u16 integer overflow.
This patch is similar to
9cefbbc9c8f9abe (netfilter: nfnetlink_queue: cleanup copy_range usage).
Signed-off-by: Florian Westphal <fw@strlen.de>
Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Florian Westphal [Thu, 23 Oct 2014 08:36:06 +0000 (10:36 +0200)]
netfilter: nf_log: account for size of NLMSG_DONE attribute
commit
9dfa1dfe4d5e5e66a991321ab08afe69759d797a upstream.
We currently neither account for the nlattr size, nor do we consider
the size of the trailing NLMSG_DONE when allocating nlmsg skb.
This can result in nflog to stop working, as __nfulnl_send() re-tries
sending forever if it failed to append NLMSG_DONE (which will never
work if buffer is not large enough).
Reported-by: Houcheng Lin <houcheng@gmail.com>
Signed-off-by: Florian Westphal <fw@strlen.de>
Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Dan Carpenter [Tue, 21 Oct 2014 08:28:12 +0000 (11:28 +0300)]
netfilter: ipset: off by one in ip_set_nfnl_get_byindex()
commit
0f9f5e1b83abd2b37c67658e02a6fc9001831fa5 upstream.
The ->ip_set_list[] array is initialized in ip_set_net_init() and it
has ->ip_set_max elements so this check should be >= instead of >
otherwise we are off by one.
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Acked-by: Jozsef Kadlecsik <kadlec@blackhole.kfki.hu>
Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Andrey Vagin [Mon, 13 Oct 2014 22:54:10 +0000 (15:54 -0700)]
ipc: always handle a new value of auto_msgmni
commit
1195d94e006b23c6292e78857e154872e33b6d7e upstream.
proc_dointvec_minmax() returns zero if a new value has been set. So we
don't need to check all charecters have been handled.
Below you can find two examples. In the new value has not been handled
properly.
$ strace ./a.out
open("/proc/sys/kernel/auto_msgmni", O_WRONLY) = 3
write(3, "0\n\0", 3) = 2
close(3) = 0
exit_group(0)
$ cat /sys/kernel/debug/tracing/trace
$strace ./a.out
open("/proc/sys/kernel/auto_msgmni", O_WRONLY) = 3
write(3, "0\n", 2) = 2
close(3) = 0
$ cat /sys/kernel/debug/tracing/trace
a.out-697 [000] .... 3280.998235: unregister_ipcns_notifier <-proc_ipcauto_dointvec_minmax
Fixes:
9eefe520c814 ("ipc: do not use a negative value to re-enable msgmni automatic recomputin")
Signed-off-by: Andrey Vagin <avagin@openvz.org>
Cc: Mathias Krause <minipli@googlemail.com>
Cc: Manfred Spraul <manfred@colorfullife.com>
Cc: Joe Perches <joe@perches.com>
Cc: Davidlohr Bueso <davidlohr@hp.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>
Devesh Sharma [Fri, 26 Sep 2014 15:15:32 +0000 (20:45 +0530)]
IB/core: Clear AH attr variable to prevent garbage data
commit
8b0f93d9490653a7b9fc91f3570089132faed1c0 upstream.
During create-ah from userspace, uverbs is sending garbage data in
attr.dmac and attr.vlan_id. This patch sets attr.dmac and
attr.vlan_id to zero.
Fixes:
dd5f03beb4f7 ("IB/core: Ethernet L2 attributes in verbs/cm structures")
Signed-off-by: Devesh Sharma <devesh.sharma@emulex.com>
Signed-off-by: Roland Dreier <roland@purestorage.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Bjorn Helgaas [Tue, 14 Oct 2014 00:59:09 +0000 (18:59 -0600)]
clocksource: Remove "weak" from clocksource_default_clock() declaration
commit
96a2adbc6f501996418da9f7afe39bf0e4d006a9 upstream.
kernel/time/jiffies.c provides a default clocksource_default_clock()
definition explicitly marked "weak". arch/s390 provides its own definition
intended to override the default, but the "weak" attribute on the
declaration applied to the s390 definition as well, so the linker chose one
based on link order (see
10629d711ed7 ("PCI: Remove __weak annotation from
pcibios_get_phb_of_node decl")).
Remove the "weak" attribute from the clocksource_default_clock()
declaration so we always prefer a non-weak definition over the weak one,
independent of link order.
Fixes:
f1b82746c1e9 ("clocksource: Cleanup clocksource selection")
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Acked-by: John Stultz <john.stultz@linaro.org>
Acked-by: Ingo Molnar <mingo@kernel.org>
CC: Daniel Lezcano <daniel.lezcano@linaro.org>
CC: Martin Schwidefsky <schwidefsky@de.ibm.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Bjorn Helgaas [Tue, 14 Oct 2014 01:00:25 +0000 (19:00 -0600)]
kgdb: Remove "weak" from kgdb_arch_pc() declaration
commit
107bcc6d566cb40184068d888637f9aefe6252dd upstream.
kernel/debug/debug_core.c provides a default kgdb_arch_pc() definition
explicitly marked "weak". Several architectures provide their own
definitions intended to override the default, but the "weak" attribute on
the declaration applied to the arch definitions as well, so the linker
chose one based on link order (see
10629d711ed7 ("PCI: Remove __weak
annotation from pcibios_get_phb_of_node decl")).
Remove the "weak" attribute from the declaration so we always prefer a
non-weak definition over the weak one, independent of link order.
Fixes:
688b744d8bc8 ("kgdb: fix signedness mixmatches, add statics, add declaration to header")
Tested-by: Vineet Gupta <vgupta@synopsys.com> # for ARC build
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Reviewed-by: Harvey Harrison <harvey.harrison@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Bjorn Helgaas [Tue, 14 Oct 2014 00:59:41 +0000 (18:59 -0600)]
vmcore: Remove "weak" from function declarations
commit
5ab03ac5aaa1f032e071f1b3dc433b7839359c03 upstream.
For the following functions:
elfcorehdr_alloc()
elfcorehdr_free()
elfcorehdr_read()
elfcorehdr_read_notes()
remap_oldmem_pfn_range()
fs/proc/vmcore.c provides default definitions explicitly marked "weak".
arch/s390 provides its own definitions intended to override the default
ones, but the "weak" attribute on the declarations applied to the s390
definitions as well, so the linker chose one based on link order (see
10629d711ed7 ("PCI: Remove __weak annotation from pcibios_get_phb_of_node
decl")).
Remove the "weak" attribute from the declarations so we always prefer a
non-weak definition over the weak one, independent of link order.
Fixes:
be8a8d069e50 ("vmcore: introduce ELF header in new memory feature")
Fixes:
9cb218131de1 ("vmcore: introduce remap_oldmem_pfn_range()")
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Acked-by: Andrew Morton <akpm@linux-foundation.org>
Acked-by: Vivek Goyal <vgoyal@redhat.com>
CC: Michael Holzheu <holzheu@linux.vnet.ibm.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Bjorn Helgaas [Tue, 14 Oct 2014 01:00:47 +0000 (19:00 -0600)]
memory-hotplug: Remove "weak" from memory_block_size_bytes() declaration
commit
e0a8400c6923a163265d52798cdd4c33f3f8ab5a upstream.
drivers/base/memory.c provides a default memory_block_size_bytes()
definition explicitly marked "weak". Several architectures provide their
own definitions intended to override the default, but the "weak" attribute
on the declaration applied to the arch definitions as well, so the linker
chose one based on link order (see
10629d711ed7 ("PCI: Remove __weak
annotation from pcibios_get_phb_of_node decl")).
Remove the "weak" attribute from the declaration so we always prefer a
non-weak definition over the weak one, independent of link order.
Fixes:
41f107266b19 ("drivers: base: Add prototype declaration to the header file")
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Acked-by: Andrew Morton <akpm@linux-foundation.org>
CC: Rashika Kheria <rashika.kheria@gmail.com>
CC: Nathan Fontenot <nfont@austin.ibm.com>
CC: Anton Blanchard <anton@au1.ibm.com>
CC: Heiko Carstens <heiko.carstens@de.ibm.com>
CC: Yinghai Lu <yinghai@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Dan Carpenter [Fri, 5 Sep 2014 12:09:28 +0000 (09:09 -0300)]
media: ttusb-dec: buffer overflow in ioctl
commit
f2e323ec96077642d397bb1c355def536d489d16 upstream.
We need to add a limit check here so we don't overflow the buffer.
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Trond Myklebust [Wed, 12 Nov 2014 19:44:49 +0000 (14:44 -0500)]
NFSv4.1: nfs41_clear_delegation_stateid shouldn't trust NFS_DELEGATED_STATE
commit
0c116cadd94b16b30b1dd90d38b2784d9b39b01a upstream.
This patch removes the assumption made previously, that we only need to
check the delegation stateid when it matches the stateid on a cached
open.
If we believe that we hold a delegation for this file, then we must assume
that its stateid may have been revoked or expired too. If we don't test it
then our state recovery process may end up caching open/lock state in a
situation where it should not.
We therefore rename the function nfs41_clear_delegation_stateid as
nfs41_check_delegation_stateid, and change it to always run through the
delegation stateid test and recovery process as outlined in RFC5661.
http://lkml.kernel.org/r/CAN-5tyHwG=Cn2Q9KsHWadewjpTTy_K26ee+UnSvHvG4192p-Xw@mail.gmail.com
Signed-off-by: Trond Myklebust <trond.myklebust@primarydata.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Trond Myklebust [Mon, 10 Nov 2014 23:43:56 +0000 (18:43 -0500)]
NFSv4: Fix races between nfs_remove_bad_delegation() and delegation return
commit
869f9dfa4d6d57b79e0afc3af14772c2a023eeb1 upstream.
Any attempt to call nfs_remove_bad_delegation() while a delegation is being
returned is currently a no-op. This means that we can end up looping
forever in nfs_end_delegation_return() if something causes the delegation
to be revoked.
This patch adds a mechanism whereby the state recovery code can communicate
to the delegation return code that the delegation is no longer valid and
that it should not be used when reclaiming state.
It also changes the return value for nfs4_handle_delegation_recall_error()
to ensure that nfs_end_delegation_return() does not reattempt the lock
reclaim before state recovery is done.
http://lkml.kernel.org/r/CAN-5tyHwG=Cn2Q9KsHWadewjpTTy_K26ee+UnSvHvG4192p-Xw@mail.gmail.com
Signed-off-by: Trond Myklebust <trond.myklebust@primarydata.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Jan Kara [Thu, 23 Oct 2014 12:02:47 +0000 (14:02 +0200)]
nfs: Fix use of uninitialized variable in nfs_getattr()
commit
16caf5b6101d03335b386e77e9e14136f989be87 upstream.
Variable 'err' needn't be initialized when nfs_getattr() uses it to
check whether it should call generic_fillattr() or not. That can result
in spurious error returns. Initialize 'err' properly.
Signed-off-by: Jan Kara <jack@suse.cz>
Signed-off-by: Trond Myklebust <trond.myklebust@primarydata.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Trond Myklebust [Fri, 17 Oct 2014 20:02:52 +0000 (23:02 +0300)]
NFS: Don't try to reclaim delegation open state if recovery failed
commit
f8ebf7a8ca35dde321f0cd385fee6f1950609367 upstream.
If state recovery failed, then we should not attempt to reclaim delegated
state.
http://lkml.kernel.org/r/CAN-5tyHwG=Cn2Q9KsHWadewjpTTy_K26ee+UnSvHvG4192p-Xw@mail.gmail.com
Signed-off-by: Trond Myklebust <trond.myklebust@primarydata.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Trond Myklebust [Fri, 17 Oct 2014 12:10:25 +0000 (15:10 +0300)]
NFSv4: Ensure that we remove NFSv4.0 delegations when state has expired
commit
4dfd4f7af0afd201706ad186352ca423b0f17d4b upstream.
NFSv4.0 does not have TEST_STATEID/FREE_STATEID functionality, so
unlike NFSv4.1, the recovery procedure when stateids have expired or
have been revoked requires us to just forget the delegation.
http://lkml.kernel.org/r/CAN-5tyHwG=Cn2Q9KsHWadewjpTTy_K26ee+UnSvHvG4192p-Xw@mail.gmail.com
Signed-off-by: Trond Myklebust <trond.myklebust@primarydata.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
NeilBrown [Tue, 28 Oct 2014 21:49:50 +0000 (08:49 +1100)]
md: Always set RECOVERY_NEEDED when clearing RECOVERY_FROZEN
commit
45eaf45dfa4850df16bc2e8e7903d89021137f40 upstream.
md_check_recovery will skip any recovery and also clear
MD_RECOVERY_NEEDED if MD_RECOVERY_FROZEN is set.
So when we clear _FROZEN, we must set _NEEDED and ensure that
md_check_recovery gets run.
Otherwise we could miss out on something that is needed.
In particular, this can make it impossible to remove a
failed device from an array is the 'recovery-needed' processing
didn't happen.
Suitable for stable kernels since 3.13.
Reported-and-tested-by: Joe Lawrence <joe.lawrence@stratus.com>
Fixes:
30b8feb730f9b9b3c5de02580897da03f59b6b16
Signed-off-by: NeilBrown <neilb@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Junjie Mao [Fri, 31 Oct 2014 13:40:38 +0000 (21:40 +0800)]
x86, kaslr: Prevent .bss from overlaping initrd
commit
e6023367d779060fddc9a52d1f474085b2b36298 upstream.
When choosing a random address, the current implementation does not take into
account the reversed space for .bss and .brk sections. Thus the relocated kernel
may overlap other components in memory. Here is an example of the overlap from a
x86_64 kernel in qemu (the ranges of physical addresses are presented):
Physical Address
0x0fe00000 --+--------------------+ <-- randomized base
/ | relocated kernel |
vmlinux.bin | (from vmlinux.bin) |
0x1336d000 (an ELF file) +--------------------+--
\ | | \
0x1376d870 --+--------------------+ |
| relocs table | |
0x13c1c2a8 +--------------------+ .bss and .brk
| | |
0x13ce6000 +--------------------+ |
| | /
0x13f77000 | initrd |--
| |
0x13fef374 +--------------------+
The initrd image will then be overwritten by the memset during early
initialization:
[ 1.655204] Unpacking initramfs...
[ 1.662831] Initramfs unpacking failed: junk in compressed archive
This patch prevents the above situation by requiring a larger space when looking
for a random kernel base, so that existing logic can effectively avoids the
overlap.
[kees: switched to perl to avoid hex translation pain in mawk vs gawk]
[kees: calculated overlap without relocs table]
Fixes:
82fa9637a2 ("x86, kaslr: Select random position from e820 maps")
Reported-by: Fengguang Wu <fengguang.wu@intel.com>
Signed-off-by: Junjie Mao <eternal.n08@gmail.com>
Signed-off-by: Kees Cook <keescook@chromium.org>
Cc: Josh Triplett <josh@joshtriplett.org>
Cc: Matt Fleming <matt.fleming@intel.com>
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Vivek Goyal <vgoyal@redhat.com>
Cc: Andi Kleen <ak@linux.intel.com>
Link: http://lkml.kernel.org/r/1414762838-13067-1-git-send-email-eternal.n08@gmail.com
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Borislav Petkov [Wed, 5 Nov 2014 16:42:42 +0000 (17:42 +0100)]
x86, microcode, AMD: Fix ucode patch stashing on 32-bit
commit
c0a717f23dccdb6e3b03471bc846fdc636f2b353 upstream.
Save the patch while we're running on the BSP instead of later, before
the initrd has been jettisoned. More importantly, on 32-bit we need to
access the physical address instead of the virtual.
This way we actually do find it on the APs instead of having to go
through the initrd each time.
Tested-by: Richard Hendershot <rshendershot@mchsi.com>
Fixes:
5335ba5cf475 ("x86, microcode, AMD: Fix early ucode loading")
Signed-off-by: Borislav Petkov <bp@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Borislav Petkov [Fri, 31 Oct 2014 22:23:43 +0000 (23:23 +0100)]
x86, microcode, AMD: Fix early ucode loading on 32-bit
commit
4750a0d112cbfcc744929f1530ffe3193436766c upstream.
Konrad triggered the following splat below in a 32-bit guest on an AMD
box. As it turns out, in save_microcode_in_initrd_amd() we're using the
*physical* address of the container *after* we have enabled paging and
thus we #PF in load_microcode_amd() when trying to access the microcode
container in the ramdisk range.
Because the ramdisk is exactly there:
[ 0.000000] RAMDISK: [mem 0x35e04000-0x36ef9fff]
and we fault at 0x35e04304.
And since this guest doesn't relocate the ramdisk, we don't do the
computation which will give us the correct virtual address and we end up
with the PA.
So, we should actually be using virtual addresses on 32-bit too by the
time we're freeing the initrd. Do that then!
Unpacking initramfs...
BUG: unable to handle kernel paging request at
35d4e304
IP: [<
c042e905>] load_microcode_amd+0x25/0x4a0
*pde =
00000000
Oops: 0000 [#1] SMP
Modules linked in:
CPU: 0 PID: 1 Comm: swapper/0 Not tainted 3.17.1-302.fc21.i686 #1
Hardware name: Xen HVM domU, BIOS 4.4.1 10/01/2014
task:
f5098000 ti:
f50d0000 task.ti:
f50d0000
EIP: 0060:[<
c042e905>] EFLAGS:
00010246 CPU: 0
EIP is at load_microcode_amd+0x25/0x4a0
EAX:
00000000 EBX:
f6e9ec4c ECX:
00001ec4 EDX:
00000000
ESI:
f5d4e000 EDI:
35d4e2fc EBP:
f50d1ed0 ESP:
f50d1e94
DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068
CR0:
8005003b CR2:
35d4e304 CR3:
00e33000 CR4:
000406d0
Stack:
00000000 00000000 f50d1ebc f50d1ec4 f5d4e000 c0d7735a f50d1ed0 15a3d17f
f50d1ec4 00600f20 00001ec4 bfb83203 f6e9ec4c f5d4e000 c0d7735a f50d1ed8
c0d80861 f50d1ee0 c0d80429 f50d1ef0 c0d889a9 f5d4e000 c0000000 f50d1f04
Call Trace:
? unpack_to_rootfs
? unpack_to_rootfs
save_microcode_in_initrd_amd
save_microcode_in_initrd
free_initrd_mem
populate_rootfs
? unpack_to_rootfs
do_one_initcall
? unpack_to_rootfs
? repair_env_string
? proc_mkdir
kernel_init_freeable
kernel_init
ret_from_kernel_thread
? rest_init
Reported-and-tested-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
References: https://bugzilla.redhat.com/show_bug.cgi?id=1158204
Fixes:
75a1ba5b2c52 ("x86, microcode, AMD: Unify valid container checks")
Signed-off-by: Borislav Petkov <bp@suse.de>
Link: http://lkml.kernel.org/r/20141101100100.GA4462@pd.tnic
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Krzysztof Kozlowski [Wed, 15 Oct 2014 14:25:10 +0000 (16:25 +0200)]
power: bq2415x_charger: Fix memory leak on DTS parsing error
commit
21e863b233553998737e1b506c823a00bf012e00 upstream.
Memory allocated for 'name' was leaking if required binding properties
were not present.
The memory for 'name' was allocated early at probe with kasprintf(). It
was freed in error paths executed before and after parsing DTS but not
in that error path.
Fix the error path for parsing device tree properties.
Signed-off-by: Krzysztof Kozlowski <k.kozlowski@samsung.com>
Fixes:
faffd234cf85 ("bq2415x_charger: Add DT support")
Signed-off-by: Sebastian Reichel <sre@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Krzysztof Kozlowski [Wed, 15 Oct 2014 14:25:09 +0000 (16:25 +0200)]
power: bq2415x_charger: Properly handle ENODEV from power_supply_get_by_phandle
commit
0eaf437aa14949d2230aeab7364f4ab47901304a upstream.
The power_supply_get_by_phandle() on error returns ENODEV or NULL.
The driver later expects obtained pointer to power supply to be
valid or NULL. If it is not NULL then it dereferences it in
bq2415x_notifier_call() which would lead to dereferencing ENODEV-value
pointer.
Properly handle the power_supply_get_by_phandle() error case by
replacing error value with NULL. This indicates that usb charger
detection won't be used.
Fix also memory leak of 'name' if power_supply_get_by_phandle() fails
with NULL and probe should defer.
Signed-off-by: Krzysztof Kozlowski <k.kozlowski@samsung.com>
Fixes:
faffd234cf85 ("bq2415x_charger: Add DT support")
[small fix regarding the missing ti,usb-charger-detection info message]
Signed-off-by: Sebastian Reichel <sre@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Krzysztof Kozlowski [Mon, 13 Oct 2014 13:34:31 +0000 (15:34 +0200)]
power: charger-manager: Fix accessing invalidated power supply after charger unbind
commit
cdaf3e15385d3232b52287e50692506f8fd01a09 upstream.
The charger manager obtained in probe references to power supplies for
all chargers with power_supply_get_by_name() for later usage. However
if such charger driver was removed then this reference would point to
old power supply (from driver which was removed).
This lead to accessing invalid memory which could be observed with:
$ echo "max77693-charger" > /sys/bus/platform/drivers/max77693-charger/unbind
$ grep . /sys/devices/virtual/power_supply/battery/charger.0/*
$ grep . /sys/devices/virtual/power_supply/battery/*
[ 15.339817] Unable to handle kernel paging request at virtual address
0001c12c
[ 15.346187] pgd =
edd08000
[ 15.348814] [
0001c12c] *pgd=
6dce2831, *pte=
00000000, *ppte=
00000000
[ 15.355075] Internal error: Oops:
80000007 [#1] PREEMPT SMP ARM
[ 15.360967] Modules linked in:
[ 15.364010] CPU: 2 PID: 1388 Comm: grep Not tainted 3.17.0-next-
20141007-00027-ga95e761db1b0 #245
[ 15.372859] task:
ee03ad00 ti:
edcf6000 task.ti:
edcf6000
[ 15.378241] PC is at 0x1c12c
[ 15.381113] LR is at is_ext_pwr_online+0x30/0x6c
[ 15.385706] pc : [<
0001c12c>] lr : [<
c0339fc4>] psr:
a0000013
[ 15.385706] sp :
edcf7e88 ip :
00000000 fp :
00000000
[ 15.397161] r10:
eeb02c08 r9 :
c04b1f84 r8 :
eeb02c00
[ 15.402369] r7 :
edc69a10 r6 :
eea6ac10 r5 :
eea6ac10 r4 :
00000004
[ 15.408878] r3 :
0001c12c r2 :
edcf7e8c r1 :
00000004 r0 :
ee914418
[ 15.415390] Flags: NzCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment user
[ 15.422506] Control:
10c5387d Table:
6dd0804a DAC:
00000015
[ 15.428236] Process grep (pid: 1388, stack limit = 0xedcf6240)
[ 15.434050] Stack: (0xedcf7e88 to 0xedcf8000)
[ 15.438395] 7e80:
ee03ad00 00000000 edcf7f80 eea6aca8 edcf7ec4 c033b7b0
[ 15.446554] 7ea0:
00000001 ee1cc3f0 00000004 c06e1e44 eebdc000 c06e1e44 eeb02c00 c0337144
[ 15.454713] 7ec0:
ee2dac68 c005cffc ee1cc3c0 c06e1e44 00000fff 00001000 eebdc000 c0278ca8
[ 15.462872] 7ee0:
c0278c8c ee1cc3c0 eeb7ce00 c014422c edcf7f20 00008000 ee1cc3c0 ee9a48c0
[ 15.471030] 7f00:
00000001 00000001 edcf7f80 c0142d94 c0142d70 c01060f4 00021000 ee1cc3f0
[ 15.479190] 7f20:
00000000 00000000 c06a2150 eebdc000 2e7ec000 ee9a48c0 00008000 00021000
[ 15.487349] 7f40:
edcf7f80 00008000 edcf6000 00021000 00021000 c00e39a4 00000000 ee9a48c0
[ 15.495508] 7f60:
00004000 00000000 00000000 ee9a48c0 ee9a48c0 00008000 00021000 c00e3aa0
[ 15.503668] 7f80:
00000000 00000000 0001f2e0 0001f2e0 00021000 00001000 00000003 c000f364
[ 15.511826] 7fa0:
00000000 c000f1a0 0001f2e0 00021000 00000003 00021000 00008000 00000000
[ 15.519986] 7fc0:
0001f2e0 00021000 00001000 00000003 00000001 000205e8 00000000 00021000
[ 15.528145] 7fe0:
00008000 bebbe910 0000a7ad b6edc49c 60000010 00000003 aaaaaaaa aaaaaaaa
[ 15.536320] [<
c0339fc4>] (is_ext_pwr_online) from [<
c033b7b0>] (charger_get_property+0x170/0x314)
[ 15.545164] [<
c033b7b0>] (charger_get_property) from [<
c0337144>] (power_supply_show_property+0x48/0x20c)
[ 15.554719] [<
c0337144>] (power_supply_show_property) from [<
c0278ca8>] (dev_attr_show+0x1c/0x48)
[ 15.563577] [<
c0278ca8>] (dev_attr_show) from [<
c014422c>] (sysfs_kf_seq_show+0x84/0x104)
[ 15.571725] [<
c014422c>] (sysfs_kf_seq_show) from [<
c0142d94>] (kernfs_seq_show+0x24/0x28)
[ 15.579973] [<
c0142d94>] (kernfs_seq_show) from [<
c01060f4>] (seq_read+0x1b0/0x484)
[ 15.587614] [<
c01060f4>] (seq_read) from [<
c00e39a4>] (vfs_read+0x88/0x144)
[ 15.594552] [<
c00e39a4>] (vfs_read) from [<
c00e3aa0>] (SyS_read+0x40/0x8c)
[ 15.601417] [<
c00e3aa0>] (SyS_read) from [<
c000f1a0>] (ret_fast_syscall+0x0/0x48)
[ 15.608877] Code: bad PC value
[ 15.611991] ---[ end trace
a88fcc95208db283 ]---
The charger-manager should get reference to charger power supply on
each use of get_property callback.
Signed-off-by: Krzysztof Kozlowski <k.kozlowski@samsung.com>
Fixes:
3bb3dbbd56ea ("power_supply: Add initial Charger-Manager driver")
Signed-off-by: Sebastian Reichel <sre@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Krzysztof Kozlowski [Mon, 13 Oct 2014 13:34:30 +0000 (15:34 +0200)]
power: charger-manager: Fix accessing invalidated power supply after fuel gauge unbind
commit
bdbe81445407644492b9ac69a24d35e3202d773b upstream.
The charger manager obtained reference to fuel gauge power supply in probe
with power_supply_get_by_name() for later usage. However if fuel gauge
driver was removed and re-added then this reference would point to old
power supply (from driver which was removed).
This lead to accessing old (and probably invalid) memory which could be
observed with:
$ echo "12-0036" > /sys/bus/i2c/drivers/max17042/unbind
$ echo "12-0036" > /sys/bus/i2c/drivers/max17042/bind
$ cat /sys/devices/virtual/power_supply/battery/capacity
[ 240.480084] INFO: task cat:1393 blocked for more than 120 seconds.
[ 240.484799] Not tainted 3.17.0-next-
20141007-00028-ge60b6dd79570 #203
[ 240.491782] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
[ 240.499589] cat D
c0469530 0 1393 1 0x00000000
[ 240.505947] [<
c0469530>] (__schedule) from [<
c0469d3c>] (schedule_preempt_disabled+0x14/0x20)
[ 240.514449] [<
c0469d3c>] (schedule_preempt_disabled) from [<
c046af08>] (mutex_lock_nested+0x1bc/0x458)
[ 240.523736] [<
c046af08>] (mutex_lock_nested) from [<
c0287a98>] (regmap_read+0x30/0x60)
[ 240.531647] [<
c0287a98>] (regmap_read) from [<
c032238c>] (max17042_get_property+0x2e8/0x350)
[ 240.540055] [<
c032238c>] (max17042_get_property) from [<
c03247d8>] (charger_get_property+0x264/0x348)
[ 240.549252] [<
c03247d8>] (charger_get_property) from [<
c0320764>] (power_supply_show_property+0x48/0x1e0)
[ 240.558808] [<
c0320764>] (power_supply_show_property) from [<
c027308c>] (dev_attr_show+0x1c/0x48)
[ 240.567664] [<
c027308c>] (dev_attr_show) from [<
c0141fb0>] (sysfs_kf_seq_show+0x84/0x104)
[ 240.575814] [<
c0141fb0>] (sysfs_kf_seq_show) from [<
c0140b18>] (kernfs_seq_show+0x24/0x28)
[ 240.584061] [<
c0140b18>] (kernfs_seq_show) from [<
c0104574>] (seq_read+0x1b0/0x484)
[ 240.591702] [<
c0104574>] (seq_read) from [<
c00e1e24>] (vfs_read+0x88/0x144)
[ 240.598640] [<
c00e1e24>] (vfs_read) from [<
c00e1f20>] (SyS_read+0x40/0x8c)
[ 240.605507] [<
c00e1f20>] (SyS_read) from [<
c000e760>] (ret_fast_syscall+0x0/0x48)
[ 240.612952] 4 locks held by cat/1393:
[ 240.616589] #0: (&p->lock){+.+.+.}, at: [<
c01043f4>] seq_read+0x30/0x484
[ 240.623414] #1: (&of->mutex){+.+.+.}, at: [<
c01417dc>] kernfs_seq_start+0x1c/0x8c
[ 240.631086] #2: (s_active#31){++++.+}, at: [<
c01417e4>] kernfs_seq_start+0x24/0x8c
[ 240.638777] #3: (&map->mutex){+.+...}, at: [<
c0287a98>] regmap_read+0x30/0x60
The charger-manager should get reference to fuel gauge power supply on
each use of get_property callback. The thermal zone 'tzd' field of
power supply should not be used because of the same reason.
Additionally this change solves also the issue with nested
thermal_zone_get_temp() calls and related false lockdep positive for
deadlock for thermal zone's mutex [1]. When fuel gauge is used as source of
temperature then the charger manager forwards its get_temp calls to fuel
gauge thermal zone. So actually different mutexes are used (one for
charger manager thermal zone and second for fuel gauge thermal zone) but
for lockdep this is one class of mutex.
The recursion is removed by retrieving temperature through power
supply's get_property().
In case external thermal zone is used ('cm-thermal-zone' property is
present in DTS) the recursion does not exist. Charger manager simply
exports POWER_SUPPLY_PROP_TEMP_AMBIENT property (instead of
POWER_SUPPLY_PROP_TEMP) thus no thermal zone is created for this power
supply.
[1] https://lkml.org/lkml/2014/10/6/309
Signed-off-by: Krzysztof Kozlowski <k.kozlowski@samsung.com>
Fixes:
3bb3dbbd56ea ("power_supply: Add initial Charger-Manager driver")
Signed-off-by: Sebastian Reichel <sre@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Pali Rohár [Sun, 9 Nov 2014 07:36:09 +0000 (23:36 -0800)]
Input: alps - ignore bad data on Dell Latitudes E6440 and E7440
commit
a7ef82aee91f26da79b981b9f5bca43b8817d3e4 upstream.
Sometimes on Dell Latitude laptops psmouse/alps driver receive invalid ALPS
protocol V3 packets with bit7 set in last byte. More often it can be
reproduced on Dell Latitude E6440 or E7440 with closed lid and pushing
cover above touchpad.
If bit7 in last packet byte is set then it is not valid ALPS packet. I was
told that ALPS devices never send these packets. It is not know yet who
send those packets, it could be Dell EC, bug in BIOS and also bug in
touchpad firmware...
With this patch alps driver does not process those invalid packets, but
instead of reporting PSMOUSE_BAD_DATA, getting into out of sync state,
getting back in sync with the next byte and spam dmesg we return
PSMOUSE_FULL_PACKET. If driver is truly out of sync we'll fail the checks
on the next byte and report PSMOUSE_BAD_DATA then.
Signed-off-by: Pali Rohár <pali.rohar@gmail.com>
Tested-by: Pali Rohár <pali.rohar@gmail.com>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Pali Rohár [Sat, 8 Nov 2014 20:58:57 +0000 (12:58 -0800)]
Input: alps - allow up to 2 invalid packets without resetting device
commit
9d720b34c0a432639252f63012e18b0507f5b432 upstream.
On some Dell Latitude laptops ALPS device or Dell EC send one invalid byte
in 6 bytes ALPS packet. In this case psmouse driver enter out of sync
state. It looks like that all other bytes in packets are valid and also
device working properly. So there is no need to do full device reset, just
need to wait for byte which match condition for first byte (start of
packet). Because ALPS packets are bigger (6 or 8 bytes) default limit is
small.
This patch increase number of invalid bytes to size of 2 ALPS packets which
psmouse driver can drop before do full reset.
Resetting ALPS devices take some time and when doing reset on some Dell
laptops touchpad, trackstick and also keyboard do not respond. So it is
better to do it only if really necessary.
Signed-off-by: Pali Rohár <pali.rohar@gmail.com>
Tested-by: Pali Rohár <pali.rohar@gmail.com>
Reviewed-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>
Pali Rohár [Sat, 8 Nov 2014 20:45:23 +0000 (12:45 -0800)]
Input: alps - ignore potential bare packets when device is out of sync
commit
4ab8f7f320f91f279c3f06a9795cfea5c972888a upstream.
5th and 6th byte of ALPS trackstick V3 protocol match condition for first
byte of PS/2 3 bytes packet. When driver enters out of sync state and ALPS
trackstick is sending data then driver match 5th, 6th and next 1st bytes as
PS/2.
It basically means if user is using trackstick when driver is in out of
sync state driver will never resync. Processing these bytes as 3 bytes PS/2
data cause total mess (random cursor movements, random clicks) and make
trackstick unusable until psmouse driver decide to do full device reset.
Lot of users reported problems with ALPS devices on Dell Latitude E6440,
E6540 and E7440 laptops. ALPS device or Dell EC for unknown reason send
some invalid ALPS PS/2 bytes which cause driver out of sync. It looks like
that i8042 and psmouse/alps driver always receive group of 6 bytes packets
so there are no missing bytes and no bytes were inserted between valid
ones.
This patch does not fix root of problem with ALPS devices found in Dell
Latitude laptops but it does not allow to process some (invalid)
subsequence of 6 bytes ALPS packets as 3 bytes PS/2 when driver is out of
sync.
So with this patch trackstick input device does not report bogus data when
also driver is out of sync, so trackstick should be usable on those
machines.
Signed-off-by: Pali Rohár <pali.rohar@gmail.com>
Tested-by: Pali Rohár <pali.rohar@gmail.com>
Reviewed-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>
Takashi Iwai [Thu, 6 Nov 2014 17:27:11 +0000 (09:27 -0800)]
Input: synaptics - add min/max quirk for Lenovo T440s
commit
e4742b1e786ca386e88e6cfb2801e14e15e365cd upstream.
The new Lenovo T440s laptop has a different PnP ID "LEN0039", and it
needs the similar min/max quirk to make its clickpad working.
BugLink: https://bugzilla.opensuse.org/show_bug.cgi?id=903748
Reported-and-tested-by: Joschi Brauchle <joschibrauchle@gmx.de>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Heinz Mauelshagen [Fri, 17 Oct 2014 11:38:50 +0000 (13:38 +0200)]
dm raid: ensure superblock's size matches device's logical block size
commit
40d43c4b4cac4c2647bf07110d7b07d35f399a84 upstream.
The dm-raid superblock (struct dm_raid_superblock) is padded to 512
bytes and that size is being used to read it in from the metadata
device into one preallocated page.
Reading or writing this on a 512-byte sector device works fine but on
a 4096-byte sector device this fails.
Set the dm-raid superblock's size to the logical block size of the
metadata device, because IO at that size is guaranteed too work. Also
add a size check to avoid silent partial metadata loss in case the
superblock should ever grow past the logical block size or PAGE_SIZE.
[includes pointer math fix from Dan Carpenter]
Reported-by: "Liuhua Wang" <lwang@suse.com>
Signed-off-by: Heinz Mauelshagen <heinzm@redhat.com>
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Mike Snitzer <snitzer@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Joe Thornber [Mon, 10 Nov 2014 15:03:24 +0000 (15:03 +0000)]
dm btree: fix a recursion depth bug in btree walking code
commit
9b460d3699324d570a4d4161c3741431887f102f upstream.
The walk code was using a 'ro_spine' to hold it's locked btree nodes.
But this data structure is designed for the rolling lock scheme, and
as such automatically unlocks blocks that are two steps up the call
chain. This is not suitable for the simple recursive walk algorithm,
which retraces its steps.
This code is only used by the persistent array code, which in turn is
only used by dm-cache. In order to trigger it you need to have a
mapping tree that is more than 2 levels deep; which equates to 8-16
million cache blocks. For instance a 4T ssd with a very small block
size of 32k only just triggers this bug.
The fix just places the locked blocks on the stack, and stops using
the ro_spine altogether.
Signed-off-by: Joe Thornber <ejt@redhat.com>
Signed-off-by: Mike Snitzer <snitzer@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Mikulas Patocka [Thu, 16 Oct 2014 18:45:20 +0000 (14:45 -0400)]
dm bufio: change __GFP_IO to __GFP_FS in shrinker callbacks
commit
9d28eb12447ee08bb5d1e8bb3195cf20e1ecd1c0 upstream.
The shrinker uses gfp flags to indicate what kind of operation can the
driver wait for. If __GFP_IO flag is present, the driver can wait for
block I/O operations, if __GFP_FS flag is present, the driver can wait on
operations involving the filesystem.
dm-bufio tested for __GFP_IO. However, dm-bufio can run on a loop block
device that makes calls into the filesystem. If __GFP_IO is present and
__GFP_FS isn't, dm-bufio could still block on filesystem operations if it
runs on a loop block device.
The change from __GFP_IO to __GFP_FS supposedly fixes one observed (though
unreproducible) deadlock involving dm-bufio and loop device.
Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>
Signed-off-by: Mike Snitzer <snitzer@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Jan Kara [Thu, 30 Oct 2014 19:43:38 +0000 (20:43 +0100)]
block: Fix computation of merged request priority
commit
ece9c72accdc45c3a9484dacb1125ce572647288 upstream.
Priority of a merged request is computed by ioprio_best(). If one of the
requests has undefined priority (IOPRIO_CLASS_NONE) and another request
has priority from IOPRIO_CLASS_BE, the function will return the
undefined priority which is wrong. Fix the function to properly return
priority of a request with the defined priority.
Fixes:
d58cdfb89ce0c6bd5f81ae931a984ef298dbda20
Signed-off-by: Jan Kara <jack@suse.cz>
Reviewed-by: Jeff Moyer <jmoyer@redhat.com>
Signed-off-by: Jens Axboe <axboe@fb.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Helge Deller [Mon, 10 Nov 2014 20:46:18 +0000 (21:46 +0100)]
parisc: Use compat layer for msgctl, shmat, shmctl and semtimedop syscalls
commit
2fe749f50b0bec07650ef135b29b1f55bf543869 upstream.
Switch over the msgctl, shmat, shmctl and semtimedop syscalls to use the compat
layer. The problem was found with the debian procenv package, which called
shmctl(0, SHM_INFO, &info);
in which the shmctl syscall then overwrote parts of the surrounding areas on
the stack on which the info variable was stored and thus lead to a segfault
later on.
Additionally fix the definition of struct shminfo64 to use unsigned longs like
the other architectures. This has no impact on userspace since we only have a
32bit userspace up to now.
Signed-off-by: Helge Deller <deller@gmx.de>
Cc: John David Anglin <dave.anglin@bell.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Christoph Hellwig [Mon, 3 Nov 2014 18:36:40 +0000 (19:36 +0100)]
scsi: only re-lock door after EH on devices that were reset
commit
48379270fe6808cf4612ee094adc8da2b7a83baa upstream.
Setups that use the blk-mq I/O path can lock up if a host with a single
device that has its door locked enters EH. Make sure to only send the
command to re-lock the door to devices that actually were reset and thus
might have lost their state. Otherwise the EH code might be get blocked
on blk_get_request as all requests for non-reset devices might be in use.
Signed-off-by: Christoph Hellwig <hch@lst.de>
Reported-by: Meelis Roos <meelis.roos@ut.ee>
Tested-by: Meelis Roos <meelis.roos@ut.ee>
Reviewed-by: Martin K. Petersen <martin.petersen@oracle.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
William Cohen [Tue, 11 Nov 2014 14:41:27 +0000 (09:41 -0500)]
Correct the race condition in aarch64_insn_patch_text_sync()
commit
899d5933b2dd2720f2b20b01eaa07871aa6ad096 upstream.
When experimenting with patches to provide kprobes support for aarch64
smp machines would hang when inserting breakpoints into kernel code.
The hangs were caused by a race condition in the code called by
aarch64_insn_patch_text_sync(). The first processor in the
aarch64_insn_patch_text_cb() function would patch the code while other
processors were still entering the function and incrementing the
cpu_count field. This resulted in some processors never observing the
exit condition and exiting the function. Thus, processors in the
system hung.
The first processor to enter the patching function performs the
patching and signals that the patching is complete with an increment
of the cpu_count field. When all the processors have incremented the
cpu_count field the cpu_count will be num_cpus_online()+1 and they
will return to normal execution.
Fixes:
ae16480785de arm64: introduce interfaces to hotpatch kernel and module code
Signed-off-by: William Cohen <wcohen@redhat.com>
Acked-by: Will Deacon <will.deacon@arm.com>
Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Peng Tao [Wed, 5 Nov 2014 14:36:50 +0000 (22:36 +0800)]
nfs: fix pnfs direct write memory leak
commit
8c393f9a721c30a030049a680e1bf896669bb279 upstream.
For pNFS direct writes, layout driver may dynamically allocate ds_cinfo.buckets.
So we need to take care to free them when freeing dreq.
Ideally this needs to be done inside layout driver where ds_cinfo.buckets
are allocated. But buckets are attached to dreq and reused across LD IO iterations.
So I feel it's OK to free them in the generic layer.
Signed-off-by: Peng Tao <tao.peng@primarydata.com>
Signed-off-by: Trond Myklebust <trond.myklebust@primarydata.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Simon Horman [Mon, 27 Oct 2014 00:14:30 +0000 (09:14 +0900)]
ata: sata_rcar: Disable DIPM mode for r8a7790 ES1
commit
aa1cf25887099bba68f1f3879c0d394e08b8779f upstream.
Unlike other SATA R-Car r8a7790 controllers the r8a7790 ES1 SATA R-Car
controller needs to be run with DIPM disabled.
Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
Signed-off-by: Tejun Heo <tj@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Stefan Richter [Tue, 11 Nov 2014 16:16:44 +0000 (17:16 +0100)]
firewire: cdev: prevent kernel stack leaking into ioctl arguments
commit
eaca2d8e75e90a70a63a6695c9f61932609db212 upstream.
Found by the UC-KLEE tool: A user could supply less input to
firewire-cdev ioctls than write- or write/read-type ioctl handlers
expect. The handlers used data from uninitialized kernel stack then.
This could partially leak back to the user if the kernel subsequently
generated fw_cdev_event_'s (to be read from the firewire-cdev fd)
which notably would contain the _u64 closure field which many of the
ioctl argument structures contain.
The fact that the handlers would act on random garbage input is a
lesser issue since all handlers must check their input anyway.
The fix simply always null-initializes the entire ioctl argument buffer
regardless of the actual length of expected user input. That is, a
runtime overhead of memset(..., 40) is added to each firewirew-cdev
ioctl() call. [Comment from Clemens Ladisch: This part of the stack is
most likely to be already in the cache.]
Remarks:
- There was never any leak from kernel stack to the ioctl output
buffer itself. IOW, it was not possible to read kernel stack by a
read-type or write/read-type ioctl alone; the leak could at most
happen in combination with read()ing subsequent event data.
- The actual expected minimum user input of each ioctl from
include/uapi/linux/firewire-cdev.h is, in bytes:
[0x00] = 32, [0x05] = 4, [0x0a] = 16, [0x0f] = 20, [0x14] = 16,
[0x01] = 36, [0x06] = 20, [0x0b] = 4, [0x10] = 20, [0x15] = 20,
[0x02] = 20, [0x07] = 4, [0x0c] = 0, [0x11] = 0, [0x16] = 8,
[0x03] = 4, [0x08] = 24, [0x0d] = 20, [0x12] = 36, [0x17] = 12,
[0x04] = 20, [0x09] = 24, [0x0e] = 4, [0x13] = 40, [0x18] = 4.
Reported-by: David Ramos <daramos@stanford.edu>
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Kyle McMartin [Wed, 12 Nov 2014 21:07:44 +0000 (21:07 +0000)]
arm64: __clear_user: handle exceptions on strb
commit
97fc15436b36ee3956efad83e22a557991f7d19d upstream.
ARM64 currently doesn't fix up faults on the single-byte (strb) case of
__clear_user... which means that we can cause a nasty kernel panic as an
ordinary user with any multiple PAGE_SIZE+1 read from /dev/zero.
i.e.: dd if=/dev/zero of=foo ibs=1 count=1 (or ibs=65537, etc.)
This is a pretty obscure bug in the general case since we'll only
__do_kernel_fault (since there's no extable entry for pc) if the
mmap_sem is contended. However, with CONFIG_DEBUG_VM enabled, we'll
always fault.
if (!down_read_trylock(&mm->mmap_sem)) {
if (!user_mode(regs) && !search_exception_tables(regs->pc))
goto no_context;
retry:
down_read(&mm->mmap_sem);
} else {
/*
* The above down_read_trylock() might have succeeded in
* which
* case, we'll have missed the might_sleep() from
* down_read().
*/
might_sleep();
if (!user_mode(regs) && !search_exception_tables(regs->pc))
goto no_context;
}
Fix that by adding an extable entry for the strb instruction, since it
touches user memory, similar to the other stores in __clear_user.
Signed-off-by: Kyle McMartin <kyle@redhat.com>
Reported-by: MiloÅ¡ PrchlÃk <mprchlik@redhat.com>
Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Joe Thornber [Fri, 10 Oct 2014 08:41:09 +0000 (09:41 +0100)]
dm thin: grab a virtual cell before looking up the mapping
commit
c822ed967cba38505713d59ed40a114386ef6c01 upstream.
Avoids normal IO racing with discard.
Signed-off-by: Joe Thornber <ejt@redhat.com>
Signed-off-by: Mike Snitzer <snitzer@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Roger Quadros [Mon, 3 Nov 2014 10:09:52 +0000 (12:09 +0200)]
pinctrl: dra: dt-bindings: Fix output pull up/down
commit
73b3a6657a88ef5348a0d69c9a8107d6f01ae862 upstream.
For PIN_OUTPUT_PULLUP and PIN_OUTPUT_PULLDOWN we must not set the
PULL_DIS bit which disables the PULLs.
PULL_ENA is a 0 and using it in an OR operation is a NOP, so don't
use it in the PIN_OUTPUT_PULLUP/DOWN macros.
Fixes:
23d9cec07c58 ("pinctrl: dra: dt-bindings: Fix pull enable/disable")
Signed-off-by: Roger Quadros <rogerq@ti.com>
Acked-by: Nishanth Menon <nm@ti.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Will Deacon [Tue, 4 Nov 2014 10:40:46 +0000 (11:40 +0100)]
ARM: 8191/1: decompressor: ensure I-side picks up relocated code
commit
238962ac71910d6c20162ea5230685fead1836a4 upstream.
To speed up decompression, the decompressor sets up a flat, cacheable
mapping of memory. However, when there is insufficient space to hold
the page tables for this mapping, we don't bother to enable the caches
and subsequently skip all the cache maintenance hooks.
Skipping the cache maintenance before jumping to the relocated code
allows the processor to predict the branch and populate the I-cache
with stale data before the relocation loop has completed (since a
bootloader may have SCTLR.I set, which permits normal, cacheable
instruction fetches regardless of SCTLR.M).
This patch moves the cache maintenance check into the maintenance
routines themselves, allowing the v6/v7 versions to invalidate the
I-cache regardless of the MMU state.
Reported-by: Marc Carino <marc.ceeeee@gmail.com>
Tested-by: Julien Grall <julien.grall@linaro.org>
Signed-off-by: Will Deacon <will.deacon@arm.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Nathan Lynch [Mon, 10 Nov 2014 22:46:27 +0000 (23:46 +0100)]
ARM: 8198/1: make kuser helpers depend on MMU
commit
08b964ff3c51b10aaf2e6ba639f40054c09f0f7a upstream.
The kuser helpers page is not set up on non-MMU systems, so it does
not make sense to allow CONFIG_KUSER_HELPERS to be enabled when
CONFIG_MMU=n. Allowing it to be set on !MMU results in an oops in
set_tls (used in execve and the arm_syscall trap handler):
Unhandled exception: IPSR =
00000005 LR =
fffffff1
CPU: 0 PID: 1 Comm: swapper Not tainted 3.18.0-rc1-00041-ga30465a #216
task:
8b838000 ti:
8b82a000 task.ti:
8b82a000
PC is at flush_thread+0x32/0x40
LR is at flush_thread+0x21/0x40
pc : [<
8f00157a>] lr : [<
8f001569>] psr:
4100000b
sp :
8b82be20 ip :
00000000 fp :
8b83c000
r10:
00000001 r9 :
88018c84 r8 :
8bb85000
r7 :
8b838000 r6 :
00000000 r5 :
8bb77400 r4 :
8b82a000
r3 :
ffff0ff0 r2 :
8b82a000 r1 :
00000000 r0 :
88020354
xPSR:
4100000b
CPU: 0 PID: 1 Comm: swapper Not tainted 3.18.0-rc1-00041-ga30465a #216
[<
8f002bc1>] (unwind_backtrace) from [<
8f002033>] (show_stack+0xb/0xc)
[<
8f002033>] (show_stack) from [<
8f00265b>] (__invalid_entry+0x4b/0x4c)
As best I can tell this issue existed for the set_tls ARM syscall
before commit
fbfb872f5f41 "ARM: 8148/1: flush TLS and thumbee
register state during exec" consolidated the TLS manipulation code
into the set_tls helper function, but now that we're using it to flush
register state during execve, !MMU users encounter the oops at the
first exec.
Prevent CONFIG_MMU=n configurations from enabling
CONFIG_KUSER_HELPERS.
Fixes:
fbfb872f5f41 (ARM: 8148/1: flush TLS and thumbee register state during exec)
Signed-off-by: Nathan Lynch <nathan_lynch@mentor.com>
Reported-by: Stefan Agner <stefan@agner.ch>
Acked-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Alex Deucher [Wed, 5 Nov 2014 22:14:32 +0000 (17:14 -0500)]
drm/radeon: add missing crtc unlock when setting up the MC
commit
f0d7bfb9407fccb6499ec01c33afe43512a439a2 upstream.
Need to unlock the crtc after updating the blanking state.
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Alex Deucher [Mon, 3 Nov 2014 14:57:46 +0000 (09:57 -0500)]
drm/radeon: make sure mode init is complete in bandwidth_update
commit
8efe82ca908400785253c8f0dfcf301e6bd93488 upstream.
The power management code calls into the display code for
certain things. If certain power management sysfs attributes
are called before the driver has finished initializing all of
the hardware we can run into problems with uninitialized
modesetting state. Add a check to make sure modesetting
init has completed to the bandwidth update callbacks to
fix this. Can be triggered by the tlp and laptop start
up scripts depending on the timing.
bugs:
https://bugzilla.kernel.org/show_bug.cgi?id=83611
https://bugs.freedesktop.org/show_bug.cgi?id=85771
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Jammy Zhou [Mon, 3 Nov 2014 13:58:20 +0000 (08:58 -0500)]
drm/radeon: set correct CE ram size for CIK
commit
dc4edad6530a9b7b66c3d905e2bc06021a05dcad upstream.
CE ram size is 32k/0k/0k for GFX/CS0/CS1 with CIK
Ported from amdgpu driver.
Signed-off-by: Jammy Zhou <Jammy.Zhou@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Johannes Berg [Mon, 3 Nov 2014 12:57:46 +0000 (13:57 +0100)]
mac80211: fix use-after-free in defragmentation
commit
b8fff407a180286aa683d543d878d98d9fc57b13 upstream.
Upon receiving the last fragment, all but the first fragment
are freed, but the multicast check for statistics at the end
of the function refers to the current skb (the last fragment)
causing a use-after-free bug.
Since multicast frames cannot be fragmented and we check for
this early in the function, just modify that check to also
do the accounting to fix the issue.
Reported-by: Yosef Khyal <yosefx.khyal@intel.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Luciano Coelho [Tue, 28 Oct 2014 11:33:05 +0000 (13:33 +0200)]
mac80211: schedule the actual switch of the station before CSA count 0
commit
ff1e417c7c239b7abfe70aa90460a77eaafc7f83 upstream.
Due to the time it takes to process the beacon that started the CSA
process, we may be late for the switch if we try to reach exactly
beacon 0. To avoid that, use count - 1 when calculating the switch time.
Reported-by: Jouni Malinen <j@w1.fi>
Signed-off-by: Luciano Coelho <luciano.coelho@intel.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Luciano Coelho [Tue, 28 Oct 2014 11:33:04 +0000 (13:33 +0200)]
mac80211: use secondary channel offset IE also beacons during CSA
commit
84469a45a1bedec9918e94ab2f78c5dc0739e4a7 upstream.
If we are switching from an HT40+ to an HT40- channel (or vice-versa),
we need the secondary channel offset IE to specify what is the
post-CSA offset to be used. This applies both to beacons and to probe
responses.
In ieee80211_parse_ch_switch_ie() we were ignoring this IE from
beacons and using the *current* HT information IE instead. This was
causing us to use the same offset as before the switch.
Fix that by using the secondary channel offset IE also for beacons and
don't ever use the pre-switch offset. Additionally, remove the
"beacon" argument from ieee80211_parse_ch_switch_ie(), since it's not
needed anymore.
Reported-by: Jouni Malinen <j@w1.fi>
Signed-off-by: Luciano Coelho <luciano.coelho@intel.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Johannes Berg [Tue, 21 Oct 2014 18:56:42 +0000 (20:56 +0200)]
mac80211: properly flush delayed scan work on interface removal
commit
46238845bd609a5c0fbe076e1b82b4c5b33360b2 upstream.
When an interface is deleted, an ongoing hardware scan is canceled and
the driver must abort the scan, at the very least reporting completion
while the interface is removed.
However, if it scheduled the work that might only run after everything
is said and done, which leads to cfg80211 warning that the scan isn't
reported as finished yet; this is no fault of the driver, it already
did, but mac80211 hasn't processed it.
To fix this situation, flush the delayed work when the interface being
removed is the one that was executing the scan.
Reported-by: Sujith Manoharan <sujith@msujith.org>
Tested-by: Sujith Manoharan <sujith@msujith.org>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Junjie Mao [Tue, 28 Oct 2014 01:31:47 +0000 (09:31 +0800)]
mac80211_hwsim: release driver when ieee80211_register_hw fails
commit
805dbe17d1c832ad341f14fae8cedf41b67ca6fa upstream.
The driver is not released when ieee80211_register_hw fails in
mac80211_hwsim_create_radio, leading to the access to the unregistered (and
possibly freed) device in platform_driver_unregister:
[ 0.447547] mac80211_hwsim: ieee80211_register_hw failed (-2)
[ 0.448292] ------------[ cut here ]------------
[ 0.448854] WARNING: CPU: 0 PID: 1 at ../include/linux/kref.h:47 kobject_get+0x33/0x50()
[ 0.449839] CPU: 0 PID: 1 Comm: swapper Not tainted 3.17.0-00001-gdd46990-dirty #2
[ 0.450813] Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011
[ 0.451512]
00000000 00000000 78025e38 7967c6c6 78025e68 7905e09b 7988b480 00000000
[ 0.452579]
00000001 79887d62 0000002f 79170bb3 79170bb3 78397008 79ac9d74 00000001
[ 0.453614]
78025e78 7905e15d 00000009 00000000 78025e84 79170bb3 78397000 78025e8c
[ 0.454632] Call Trace:
[ 0.454921] [<
7967c6c6>] dump_stack+0x16/0x18
[ 0.455453] [<
7905e09b>] warn_slowpath_common+0x6b/0x90
[ 0.456067] [<
79170bb3>] ? kobject_get+0x33/0x50
[ 0.456612] [<
79170bb3>] ? kobject_get+0x33/0x50
[ 0.457155] [<
7905e15d>] warn_slowpath_null+0x1d/0x20
[ 0.457748] [<
79170bb3>] kobject_get+0x33/0x50
[ 0.458274] [<
7925824f>] get_device+0xf/0x20
[ 0.458779] [<
7925b5cd>] driver_detach+0x3d/0xa0
[ 0.459331] [<
7925a3ff>] bus_remove_driver+0x8f/0xb0
[ 0.459927] [<
7925bf80>] ? class_unregister+0x40/0x80
[ 0.460660] [<
7925bad7>] driver_unregister+0x47/0x50
[ 0.461248] [<
7925c033>] ? class_destroy+0x13/0x20
[ 0.461824] [<
7925d07b>] platform_driver_unregister+0xb/0x10
[ 0.462507] [<
79b51ba0>] init_mac80211_hwsim+0x3e8/0x3f9
[ 0.463161] [<
79b30c58>] do_one_initcall+0x106/0x1a9
[ 0.463758] [<
79b517b8>] ? if_spi_init_module+0xac/0xac
[ 0.464393] [<
79b517b8>] ? if_spi_init_module+0xac/0xac
[ 0.465001] [<
79071935>] ? parse_args+0x2f5/0x480
[ 0.465569] [<
7906b41e>] ? __usermodehelper_set_disable_depth+0x3e/0x50
[ 0.466345] [<
79b30dd9>] kernel_init_freeable+0xde/0x17d
[ 0.466972] [<
79b304d6>] ? do_early_param+0x7a/0x7a
[ 0.467546] [<
79677b1b>] kernel_init+0xb/0xe0
[ 0.468072] [<
79075f42>] ? schedule_tail+0x12/0x40
[ 0.468658] [<
79686580>] ret_from_kernel_thread+0x20/0x30
[ 0.469303] [<
79677b10>] ? rest_init+0xc0/0xc0
[ 0.469829] ---[ end trace
ad8ac403ff8aef5c ]---
[ 0.470509] ------------[ cut here ]------------
[ 0.471047] WARNING: CPU: 0 PID: 1 at ../kernel/locking/lockdep.c:3161 __lock_acquire.isra.22+0x7aa/0xb00()
[ 0.472163] DEBUG_LOCKS_WARN_ON(id >= MAX_LOCKDEP_KEYS)
[ 0.472774] CPU: 0 PID: 1 Comm: swapper Tainted: G W 3.17.0-00001-gdd46990-dirty #2
[ 0.473815] Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011
[ 0.474492]
78025de0 78025de0 78025da0 7967c6c6 78025dd0 7905e09b 79888931 78025dfc
[ 0.475515]
00000001 79888a93 00000c59 7907f33a 7907f33a 78028000 fffe9d09 00000000
[ 0.476519]
78025de8 7905e10e 00000009 78025de0 79888931 78025dfc 78025e24 7907f33a
[ 0.477523] Call Trace:
[ 0.477821] [<
7967c6c6>] dump_stack+0x16/0x18
[ 0.478352] [<
7905e09b>] warn_slowpath_common+0x6b/0x90
[ 0.478976] [<
7907f33a>] ? __lock_acquire.isra.22+0x7aa/0xb00
[ 0.479658] [<
7907f33a>] ? __lock_acquire.isra.22+0x7aa/0xb00
[ 0.480417] [<
7905e10e>] warn_slowpath_fmt+0x2e/0x30
[ 0.480479] [<
7907f33a>] __lock_acquire.isra.22+0x7aa/0xb00
[ 0.480479] [<
79078aa5>] ? sched_clock_cpu+0xb5/0xf0
[ 0.480479] [<
7907fd06>] lock_acquire+0x56/0x70
[ 0.480479] [<
7925b5e8>] ? driver_detach+0x58/0xa0
[ 0.480479] [<
79682d11>] mutex_lock_nested+0x61/0x2a0
[ 0.480479] [<
7925b5e8>] ? driver_detach+0x58/0xa0
[ 0.480479] [<
7925b5e8>] ? driver_detach+0x58/0xa0
[ 0.480479] [<
7925b5e8>] driver_detach+0x58/0xa0
[ 0.480479] [<
7925a3ff>] bus_remove_driver+0x8f/0xb0
[ 0.480479] [<
7925bf80>] ? class_unregister+0x40/0x80
[ 0.480479] [<
7925bad7>] driver_unregister+0x47/0x50
[ 0.480479] [<
7925c033>] ? class_destroy+0x13/0x20
[ 0.480479] [<
7925d07b>] platform_driver_unregister+0xb/0x10
[ 0.480479] [<
79b51ba0>] init_mac80211_hwsim+0x3e8/0x3f9
[ 0.480479] [<
79b30c58>] do_one_initcall+0x106/0x1a9
[ 0.480479] [<
79b517b8>] ? if_spi_init_module+0xac/0xac
[ 0.480479] [<
79b517b8>] ? if_spi_init_module+0xac/0xac
[ 0.480479] [<
79071935>] ? parse_args+0x2f5/0x480
[ 0.480479] [<
7906b41e>] ? __usermodehelper_set_disable_depth+0x3e/0x50
[ 0.480479] [<
79b30dd9>] kernel_init_freeable+0xde/0x17d
[ 0.480479] [<
79b304d6>] ? do_early_param+0x7a/0x7a
[ 0.480479] [<
79677b1b>] kernel_init+0xb/0xe0
[ 0.480479] [<
79075f42>] ? schedule_tail+0x12/0x40
[ 0.480479] [<
79686580>] ret_from_kernel_thread+0x20/0x30
[ 0.480479] [<
79677b10>] ? rest_init+0xc0/0xc0
[ 0.480479] ---[ end trace
ad8ac403ff8aef5d ]---
[ 0.495478] BUG: unable to handle kernel paging request at
00200200
[ 0.496257] IP: [<
79682de5>] mutex_lock_nested+0x135/0x2a0
[ 0.496923] *pde =
00000000
[ 0.497290] Oops: 0002 [#1]
[ 0.497653] CPU: 0 PID: 1 Comm: swapper Tainted: G W 3.17.0-00001-gdd46990-dirty #2
[ 0.498659] Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011
[ 0.499321] task:
78028000 ti:
78024000 task.ti:
78024000
[ 0.499955] EIP: 0060:[<
79682de5>] EFLAGS:
00010097 CPU: 0
[ 0.500620] EIP is at mutex_lock_nested+0x135/0x2a0
[ 0.501145] EAX:
00200200 EBX:
78397434 ECX:
78397460 EDX:
78025e70
[ 0.501816] ESI:
00000246 EDI:
78028000 EBP:
78025e8c ESP:
78025e54
[ 0.502497] DS: 007b ES: 007b FS: 0000 GS: 0000 SS: 0068
[ 0.503076] CR0:
8005003b CR2:
00200200 CR3:
01b9d000 CR4:
00000690
[ 0.503773] Stack:
[ 0.503998]
00000000 00000001 00000000 7925b5e8 78397460 7925b5e8 78397474 78397460
[ 0.504944]
00200200 11111111 78025e70 78397000 79ac9d74 00000001 78025ea0 7925b5e8
[ 0.505451]
79ac9d74 fffffffe 00000001 78025ebc 7925a3ff 7a251398 78025ec8 7925bf80
[ 0.505451] Call Trace:
[ 0.505451] [<
7925b5e8>] ? driver_detach+0x58/0xa0
[ 0.505451] [<
7925b5e8>] ? driver_detach+0x58/0xa0
[ 0.505451] [<
7925b5e8>] driver_detach+0x58/0xa0
[ 0.505451] [<
7925a3ff>] bus_remove_driver+0x8f/0xb0
[ 0.505451] [<
7925bf80>] ? class_unregister+0x40/0x80
[ 0.505451] [<
7925bad7>] driver_unregister+0x47/0x50
[ 0.505451] [<
7925c033>] ? class_destroy+0x13/0x20
[ 0.505451] [<
7925d07b>] platform_driver_unregister+0xb/0x10
[ 0.505451] [<
79b51ba0>] init_mac80211_hwsim+0x3e8/0x3f9
[ 0.505451] [<
79b30c58>] do_one_initcall+0x106/0x1a9
[ 0.505451] [<
79b517b8>] ? if_spi_init_module+0xac/0xac
[ 0.505451] [<
79b517b8>] ? if_spi_init_module+0xac/0xac
[ 0.505451] [<
79071935>] ? parse_args+0x2f5/0x480
[ 0.505451] [<
7906b41e>] ? __usermodehelper_set_disable_depth+0x3e/0x50
[ 0.505451] [<
79b30dd9>] kernel_init_freeable+0xde/0x17d
[ 0.505451] [<
79b304d6>] ? do_early_param+0x7a/0x7a
[ 0.505451] [<
79677b1b>] kernel_init+0xb/0xe0
[ 0.505451] [<
79075f42>] ? schedule_tail+0x12/0x40
[ 0.505451] [<
79686580>] ret_from_kernel_thread+0x20/0x30
[ 0.505451] [<
79677b10>] ? rest_init+0xc0/0xc0
[ 0.505451] Code: 89 d8 e8 cf 9b 9f ff 8b 4f 04 8d 55 e4 89 d8 e8 72 9d 9f ff 8d 43 2c 89 c1 89 45 d8 8b 43 30 8d 55 e4 89 53 30 89 4d e4 89 45 e8 <89> 10 8b 55 dc 8b 45 e0 89 7d ec e8 db af 9f ff eb 11 90 31 c0
[ 0.505451] EIP: [<
79682de5>] mutex_lock_nested+0x135/0x2a0 SS:ESP 0068:
78025e54
[ 0.505451] CR2:
0000000000200200
[ 0.505451] ---[ end trace
ad8ac403ff8aef5e ]---
[ 0.505451] Kernel panic - not syncing: Fatal exception
Fixes:
9ea927748ced ("mac80211_hwsim: Register and bind to driver")
Reported-by: Fengguang Wu <fengguang.wu@intel.com>
Signed-off-by: Junjie Mao <eternal.n08@gmail.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Herbert Xu [Mon, 3 Nov 2014 06:01:25 +0000 (14:01 +0800)]
macvtap: Fix csum_start when VLAN tags are present
commit
3ce9b20f1971690b8b3b620e735ec99431573b39 upstream.
When VLAN is in use in macvtap_put_user, we end up setting
csum_start to the wrong place. The result is that the whoever
ends up doing the checksum setting will corrupt the packet instead
of writing the checksum to the expected location, usually this
means writing the checksum with an offset of -4.
This patch fixes this by adjusting csum_start when VLAN tags are
detected.
Fixes:
f09e2249c4f5 ("macvtap: restore vlan header on user read")
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
Ilya Dryomov [Wed, 22 Oct 2014 20:25:22 +0000 (00:25 +0400)]
libceph: do not crash on large auth tickets
commit
aaef31703a0cf6a733e651885bfb49edc3ac6774 upstream.
Large (greater than 32k, the value of PAGE_ALLOC_COSTLY_ORDER) auth
tickets will have their buffers vmalloc'ed, which leads to the
following crash in crypto:
[ 28.685082] BUG: unable to handle kernel paging request at
ffffeb04000032c0
[ 28.686032] IP: [<
ffffffff81392b42>] scatterwalk_pagedone+0x22/0x80
[ 28.686032] PGD 0
[ 28.688088] Oops: 0000 [#1] PREEMPT SMP
[ 28.688088] Modules linked in:
[ 28.688088] CPU: 0 PID: 878 Comm: kworker/0:2 Not tainted 3.17.0-vm+ #305
[ 28.688088] Hardware name: Bochs Bochs, BIOS Bochs 01/01/2007
[ 28.688088] Workqueue: ceph-msgr con_work
[ 28.688088] task:
ffff88011a7f9030 ti:
ffff8800d903c000 task.ti:
ffff8800d903c000
[ 28.688088] RIP: 0010:[<
ffffffff81392b42>] [<
ffffffff81392b42>] scatterwalk_pagedone+0x22/0x80
[ 28.688088] RSP: 0018:
ffff8800d903f688 EFLAGS:
00010286
[ 28.688088] RAX:
ffffeb04000032c0 RBX:
ffff8800d903f718 RCX:
ffffeb04000032c0
[ 28.688088] RDX:
0000000000000000 RSI:
0000000000000001 RDI:
ffff8800d903f750
[ 28.688088] RBP:
ffff8800d903f688 R08:
00000000000007de R09:
ffff8800d903f880
[ 28.688088] R10:
18df467c72d6257b R11:
0000000000000000 R12:
0000000000000010
[ 28.688088] R13:
ffff8800d903f750 R14:
ffff8800d903f8a0 R15:
0000000000000000
[ 28.688088] FS:
00007f50a41c7700(0000) GS:
ffff88011fc00000(0000) knlGS:
0000000000000000
[ 28.688088] CS: 0010 DS: 0000 ES: 0000 CR0:
000000008005003b
[ 28.688088] CR2:
ffffeb04000032c0 CR3:
00000000da3f3000 CR4:
00000000000006b0
[ 28.688088] Stack:
[ 28.688088]
ffff8800d903f698 ffffffff81392ca8 ffff8800d903f6e8 ffffffff81395d32
[ 28.688088]
ffff8800dac96000 ffff880000000000 ffff8800d903f980 ffff880119b7e020
[ 28.688088]
ffff880119b7e010 0000000000000000 0000000000000010 0000000000000010
[ 28.688088] Call Trace:
[ 28.688088] [<
ffffffff81392ca8>] scatterwalk_done+0x38/0x40
[ 28.688088] [<
ffffffff81392ca8>] scatterwalk_done+0x38/0x40
[ 28.688088] [<
ffffffff81395d32>] blkcipher_walk_done+0x182/0x220
[ 28.688088] [<
ffffffff813990bf>] crypto_cbc_encrypt+0x15f/0x180
[ 28.688088] [<
ffffffff81399780>] ? crypto_aes_set_key+0x30/0x30
[ 28.688088] [<
ffffffff8156c40c>] ceph_aes_encrypt2+0x29c/0x2e0
[ 28.688088] [<
ffffffff8156d2a3>] ceph_encrypt2+0x93/0xb0
[ 28.688088] [<
ffffffff8156d7da>] ceph_x_encrypt+0x4a/0x60
[ 28.688088] [<
ffffffff8155b39d>] ? ceph_buffer_new+0x5d/0xf0
[ 28.688088] [<
ffffffff8156e837>] ceph_x_build_authorizer.isra.6+0x297/0x360
[ 28.688088] [<
ffffffff8112089b>] ? kmem_cache_alloc_trace+0x11b/0x1c0
[ 28.688088] [<
ffffffff8156b496>] ? ceph_auth_create_authorizer+0x36/0x80
[ 28.688088] [<
ffffffff8156ed83>] ceph_x_create_authorizer+0x63/0xd0
[ 28.688088] [<
ffffffff8156b4b4>] ceph_auth_create_authorizer+0x54/0x80
[ 28.688088] [<
ffffffff8155f7c0>] get_authorizer+0x80/0xd0
[ 28.688088] [<
ffffffff81555a8b>] prepare_write_connect+0x18b/0x2b0
[ 28.688088] [<
ffffffff81559289>] try_read+0x1e59/0x1f10
This is because we set up crypto scatterlists as if all buffers were
kmalloc'ed. Fix it.
Signed-off-by: Ilya Dryomov <idryomov@redhat.com>
Reviewed-by: Sage Weil <sage@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Max Filippov [Mon, 6 Oct 2014 17:01:17 +0000 (21:01 +0400)]
xtensa: re-wire umount syscall to sys_oldumount
commit
2651cc6974d47fc43bef1cd8cd26966e4f5ba306 upstream.
Userspace actually passes single parameter (path name) to the umount
syscall, so new umount just fails. Fix it by requesting old umount
syscall implementation and re-wiring umount to it.
Signed-off-by: Max Filippov <jcmvbkbc@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Takashi Iwai [Tue, 11 Nov 2014 14:45:57 +0000 (15:45 +0100)]
ALSA: usb-audio: Fix memory leak in FTU quirk
commit
1a290581ded60e87276741f8ca97b161d2b226fc upstream.
M-audio FastTrack Ultra quirk doesn't release the kzalloc'ed memory.
This patch adds the private_free callback to release it properly.
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Tejun Heo [Mon, 27 Oct 2014 14:22:56 +0000 (10:22 -0400)]
ahci: disable MSI instead of NCQ on Samsung pci-e SSDs on macbooks
commit
66a7cbc303f4d28f201529b06061944d51ab530c upstream.
Samsung pci-e SSDs on macbooks failed miserably on NCQ commands, so
67809f85d31e ("ahci: disable NCQ on Samsung pci-e SSDs on macbooks")
disabled NCQ on them. It turns out that NCQ is fine as long as MSI is
not used, so let's turn off MSI and leave NCQ on.
Signed-off-by: Tejun Heo <tj@kernel.org>
Link: https://bugzilla.kernel.org/show_bug.cgi?id=60731
Tested-by: <dorin@i51.org>
Tested-by: Imre Kaloz <kaloz@openwrt.org>
Fixes:
67809f85d31e ("ahci: disable NCQ on Samsung pci-e SSDs on macbooks")
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
James Ralston [Mon, 13 Oct 2014 22:16:38 +0000 (15:16 -0700)]
ahci: Add Device IDs for Intel Sunrise Point PCH
commit
690000b930456a98663567d35dd5c54b688d1e3f upstream.
This patch adds the AHCI-mode SATA Device IDs for the Intel Sunrise Point PCH.
Signed-off-by: James Ralston <james.d.ralston@intel.com>
Signed-off-by: Tejun Heo <tj@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Miklos Szeredi [Tue, 4 Nov 2014 10:27:12 +0000 (11:27 +0100)]
audit: keep inode pinned
commit
799b601451b21ebe7af0e6e8f6e2ccd4683c5064 upstream.
Audit rules disappear when an inode they watch is evicted from the cache.
This is likely not what we want.
The guilty commit is "fsnotify: allow marks to not pin inodes in core",
which didn't take into account that audit_tree adds watches with a zero
mask.
Adding any mask should fix this.
Fixes:
90b1e7a57880 ("fsnotify: allow marks to not pin inodes in core")
Signed-off-by: Miklos Szeredi <mszeredi@suse.cz>
Signed-off-by: Paul Moore <pmoore@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Richard Guy Briggs [Thu, 30 Oct 2014 15:22:53 +0000 (11:22 -0400)]
audit: AUDIT_FEATURE_CHANGE message format missing delimiting space
commit
897f1acbb6702ddaa953e8d8436eee3b12016c7e upstream.
Add a space between subj= and feature= fields to make them parsable.
Signed-off-by: Richard Guy Briggs <rgb@redhat.com>
Signed-off-by: Paul Moore <pmoore@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Richard Guy Briggs [Mon, 25 Aug 2014 00:37:52 +0000 (20:37 -0400)]
audit: correct AUDIT_GET_FEATURE return message type
commit
9ef91514774a140e468f99d73d7593521e6d25dc upstream.
When an AUDIT_GET_FEATURE message is sent from userspace to the kernel, it
should reply with a message tagged as an AUDIT_GET_FEATURE type with a struct
audit_feature. The current reply is a message tagged as an AUDIT_GET
type with a struct audit_feature.
This appears to have been a cut-and-paste-eo in commit b0fed40.
Reported-by: Steve Grubb <sgrubb@redhat.com>
Signed-off-by: Richard Guy Briggs <rgb@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Andy Lutomirski [Fri, 5 Sep 2014 22:13:52 +0000 (15:13 -0700)]
x86, x32, audit: Fix x32's AUDIT_ARCH wrt audit
commit
81f49a8fd7088cfcb588d182eeede862c0e3303e upstream.
is_compat_task() is the wrong check for audit arch; the check should
be is_ia32_task(): x32 syscalls should be AUDIT_ARCH_X86_64, not
AUDIT_ARCH_I386.
CONFIG_AUDITSYSCALL is currently incompatible with x32, so this has
no visible effect.
Signed-off-by: Andy Lutomirski <luto@amacapital.net>
Link: http://lkml.kernel.org/r/a0138ed8c709882aec06e4acc30bfa9b623b8717.1409954077.git.luto@amacapital.net
Signed-off-by: H. Peter Anvin <hpa@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Herbert Xu [Sun, 2 Nov 2014 20:30:13 +0000 (04:30 +0800)]
tun: Fix csum_start with VLAN acceleration
commit
a8f9bfdf982e2b1fb9f094e4de9ab08c57f3d2fd upstream.
When VLAN acceleration is in use on the xmit path, we end up
setting csum_start to the wrong place. The result is that the
whoever ends up doing the checksum setting will corrupt the packet
instead of writing the checksum to the expected location, usually
this means writing the checksum with an offset of -4.
This patch fixes this by adjusting csum_start when VLAN acceleration
is detected.
Fixes:
6680ec68eff4 ("tuntap: hardware vlan tx support")
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Greg Kurz [Fri, 31 Oct 2014 06:50:11 +0000 (07:50 +0100)]
hwrng: pseries - port to new read API and fix stack corruption
commit
24c65bc7037e7d0f362c0df70d17dd72ee64b8b9 upstream.
The add_early_randomness() function in drivers/char/hw_random/core.c passes
a 16-byte buffer to pseries_rng_data_read(). Unfortunately, plpar_hcall()
returns four 64-bit values and trashes 16 bytes on the stack.
This bug has been lying around for a long time. It got unveiled by:
commit
d3cc7996473a7bdd33256029988ea690754e4e2a
Author: Amit Shah <amit.shah@redhat.com>
Date: Thu Jul 10 15:42:34 2014 +0530
hwrng: fetch randomness only after device init
It may trig a oops while loading or unloading the pseries-rng module for both
PowerVM and PowerKVM guests.
This patch does two things:
- pass an intermediate well sized buffer to plpar_hcall(). This is acceptalbe
since we're not on a hot path.
- move to the new read API so that we know the return buffer size for sure.
Signed-off-by: Greg Kurz <gkurz@linux.vnet.ibm.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cristian Stoica [Thu, 14 Aug 2014 10:51:56 +0000 (13:51 +0300)]
crypto: caam - remove duplicated sg copy functions
commit
307fd543f3d23f8f56850eca1b27b1be2fe71017 upstream.
Replace equivalent (and partially incorrect) scatter-gather functions
with ones from crypto-API.
The replacement is motivated by page-faults in sg_copy_part triggered
by successive calls to crypto_hash_update. The following fault appears
after calling crypto_ahash_update twice, first with 13 and then
with 285 bytes:
Unable to handle kernel paging request for data at address 0x00000008
Faulting instruction address: 0xf9bf9a8c
Oops: Kernel access of bad area, sig: 11 [#1]
SMP NR_CPUS=8 CoreNet Generic
Modules linked in: tcrypt(+) caamhash caam_jr caam tls
CPU: 6 PID: 1497 Comm: cryptomgr_test Not tainted
3.12.19-rt30-QorIQ-SDK-V1.6+g9fda9f2 #75
task:
e9308530 ti:
e700e000 task.ti:
e700e000
NIP:
f9bf9a8c LR:
f9bfcf28 CTR:
c0019ea0
REGS:
e700fb80 TRAP: 0300 Not tainted
(3.12.19-rt30-QorIQ-SDK-V1.6+g9fda9f2)
MSR:
00029002 <CE,EE,ME> CR:
44f92024 XER:
20000000
DEAR:
00000008, ESR:
00000000
GPR00:
f9bfcf28 e700fc30 e9308530 e70b1e55 00000000 ffffffdd e70b1e54 0bebf888
GPR08:
902c7ef5 c0e771e2 00000002 00000888 c0019ea0 00000000 00000000 c07a4154
GPR16:
c08d0000 e91a8f9c 00000001 e98fb400 00000100 e9c83028 e70b1e08 e70b1d48
GPR24:
e992ce10 e70b1dc8 f9bfe4f4 e70b1e55 ffffffdd e70b1ce0 00000000 00000000
NIP [
f9bf9a8c] sg_copy+0x1c/0x100 [caamhash]
LR [
f9bfcf28] ahash_update_no_ctx+0x628/0x660 [caamhash]
Call Trace:
[
e700fc30] [
f9bf9c50] sg_copy_part+0xe0/0x160 [caamhash] (unreliable)
[
e700fc50] [
f9bfcf28] ahash_update_no_ctx+0x628/0x660 [caamhash]
[
e700fcb0] [
f954e19c] crypto_tls_genicv+0x13c/0x300 [tls]
[
e700fd10] [
f954e65c] crypto_tls_encrypt+0x5c/0x260 [tls]
[
e700fd40] [
c02250ec] __test_aead.constprop.9+0x2bc/0xb70
[
e700fe40] [
c02259f0] alg_test_aead+0x50/0xc0
[
e700fe60] [
c02241e4] alg_test+0x114/0x2e0
[
e700fee0] [
c022276c] cryptomgr_test+0x4c/0x60
[
e700fef0] [
c004f658] kthread+0x98/0xa0
[
e700ff40] [
c000fd04] ret_from_kernel_thread+0x5c/0x64
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Cc: Cristian Stoica <cristian.stoica@freescale.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cristian Stoica [Thu, 30 Oct 2014 12:40:22 +0000 (14:40 +0200)]
crypto: caam - fix missing dma unmap on error path
commit
738459e3f88538f2ece263424dafe5d91799e46b upstream.
If dma mapping for dma_addr_out fails, the descriptor memory is freed
but the previous dma mapping for dma_addr_in remains.
This patch resolves the missing dma unmap and groups resource
allocations at function start.
Signed-off-by: Cristian Stoica <cristian.stoica@freescale.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Weijie Yang [Thu, 13 Nov 2014 23:19:05 +0000 (15:19 -0800)]
zram: avoid kunmap_atomic() of a NULL pointer
commit
c406515239376fc93a30d5d03192182160cbd3fb upstream.
zram could kunmap_atomic() a NULL pointer in a rare situation: a zram
page becomes a full-zeroed page after a partial write io. The current
code doesn't handle this case and performs kunmap_atomic() on a NULL
pointer, which panics the kernel.
This patch fixes this issue.
Signed-off-by: Weijie Yang <weijie.yang@samsung.com>
Cc: Sergey Senozhatsky <sergey.senozhatsky@gmail.com>
Cc: Dan Streetman <ddstreet@ieee.org>
Cc: Nitin Gupta <ngupta@vflare.org>
Cc: Weijie Yang <weijie.yang.kh@gmail.com>
Acked-by: Jerome Marchand <jmarchan@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>
Andreas Larsson [Wed, 5 Nov 2014 14:52:08 +0000 (15:52 +0100)]
sparc32: Implement xchg and atomic_xchg using ATOMIC_HASH locks
[ Upstream commit
1a17fdc4f4ed06b63fac1937470378a5441a663a ]
Atomicity between xchg and cmpxchg cannot be guaranteed when xchg is
implemented with a swap and cmpxchg is implemented with locks.
Without this, e.g. mcs_spin_lock and mcs_spin_unlock are broken.
Signed-off-by: Andreas Larsson <andreas@gaisler.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
David S. Miller [Fri, 7 Nov 2014 17:50:48 +0000 (09:50 -0800)]
sparc64: Do irq_{enter,exit}() around generic_smp_call_function*().
[ Upstream commit
ab5c780913bca0a5763ca05dd5c2cb5cb08ccb26 ]
Otherwise rcu_irq_{enter,exit}() do not happen and we get dumps like:
====================
[ 188.275021] ===============================
[ 188.309351] [ INFO: suspicious RCU usage. ]
[ 188.343737] 3.18.0-rc3-00068-g20f3963-dirty #54 Not tainted
[ 188.394786] -------------------------------
[ 188.429170] include/linux/rcupdate.h:883 rcu_read_lock() used
illegally while idle!
[ 188.505235]
other info that might help us debug this:
[ 188.554230]
RCU used illegally from idle CPU!
rcu_scheduler_active = 1, debug_locks = 0
[ 188.637587] RCU used illegally from extended quiescent state!
[ 188.690684] 3 locks held by swapper/7/0:
[ 188.721932] #0: (&x->wait#11){......}, at: [<
0000000000495de8>] complete+0x8/0x60
[ 188.797994] #1: (&p->pi_lock){-.-.-.}, at: [<
000000000048510c>] try_to_wake_up+0xc/0x400
[ 188.881343] #2: (rcu_read_lock){......}, at: [<
000000000048a910>] select_task_rq_fair+0x90/0xb40
[ 188.973043]stack backtrace:
[ 188.993879] CPU: 7 PID: 0 Comm: swapper/7 Not tainted 3.18.0-rc3-00068-g20f3963-dirty #54
[ 189.076187] Call Trace:
[ 189.089719] [
0000000000499360] lockdep_rcu_suspicious+0xe0/0x100
[ 189.147035] [
000000000048a99c] select_task_rq_fair+0x11c/0xb40
[ 189.202253] [
00000000004852d8] try_to_wake_up+0x1d8/0x400
[ 189.252258] [
000000000048554c] default_wake_function+0xc/0x20
[ 189.306435] [
0000000000495554] __wake_up_common+0x34/0x80
[ 189.356448] [
00000000004955b4] __wake_up_locked+0x14/0x40
[ 189.406456] [
0000000000495e08] complete+0x28/0x60
[ 189.448142] [
0000000000636e28] blk_end_sync_rq+0x8/0x20
[ 189.496057] [
0000000000639898] __blk_mq_end_request+0x18/0x60
[ 189.550249] [
00000000006ee014] scsi_end_request+0x94/0x180
[ 189.601286] [
00000000006ee334] scsi_io_completion+0x1d4/0x600
[ 189.655463] [
00000000006e51c4] scsi_finish_command+0xc4/0xe0
[ 189.708598] [
00000000006ed958] scsi_softirq_done+0x118/0x140
[ 189.761735] [
00000000006398ec] __blk_mq_complete_request_remote+0xc/0x20
[ 189.827383] [
00000000004c75d0] generic_smp_call_function_single_interrupt+0x150/0x1c0
[ 189.906581] [
000000000043e514] smp_call_function_single_client+0x14/0x40
====================
Based almost entirely upon a patch by Paul E. McKenney.
Reported-by: Meelis Roos <mroos@linux.ee>
Tested-by: Meelis Roos <mroos@linux.ee>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
David S. Miller [Sat, 1 Nov 2014 04:33:58 +0000 (00:33 -0400)]
sparc64: Fix crashes in schizo_pcierr_intr_other().
[ Upstream commit
7da89a2a3776442a57e918ca0b8678d1b16a7072 ]
Meelis Roos reports crashes during bootup on a V480 that look like
this:
====================
[ 61.300577] PCI: Scanning PBM /pci@9,600000
[ 61.304867] schizo
f009b070: PCI host bridge to bus 0003:00
[ 61.310385] pci_bus 0003:00: root bus resource [io 0x7ffe9000000-0x7ffe9ffffff] (bus address [0x0000-0xffffff])
[ 61.320515] pci_bus 0003:00: root bus resource [mem 0x7fb00000000-0x7fbffffffff] (bus address [0x00000000-0xffffffff])
[ 61.331173] pci_bus 0003:00: root bus resource [bus 00]
[ 61.385344] Unable to handle kernel NULL pointer dereference
[ 61.390970] tsk->{mm,active_mm}->context =
0000000000000000
[ 61.396515] tsk->{mm,active_mm}->pgd =
fff000b000002000
[ 61.401716] \|/ ____ \|/
[ 61.401716] "@'/ .. \`@"
[ 61.401716] /_| \__/ |_\
[ 61.401716] \__U_/
[ 61.416362] swapper/0(0): Oops [#1]
[ 61.419837] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 3.18.0-rc1-00422-g2cc9188-dirty #24
[ 61.427975] task:
fff000b0fd8e9c40 ti:
fff000b0fd928000 task.ti:
fff000b0fd928000
[ 61.435426] TSTATE:
0000004480e01602 TPC:
00000000004455e4 TNPC:
00000000004455e8 Y:
00000000 Not tainted
[ 61.445230] TPC: <schizo_pcierr_intr+0x104/0x560>
[ 61.449897] g0:
0000000000000000 g1:
0000000000000000 g2:
0000000000a10f78 g3:
000000000000000a
[ 61.458563] g4:
fff000b0fd8e9c40 g5:
fff000b0fdd82000 g6:
fff000b0fd928000 g7:
000000000000000a
[ 61.467229] o0:
000000000000003d o1:
0000000000000000 o2:
0000000000000006 o3:
fff000b0ffa5fc7e
[ 61.475894] o4:
0000000000060000 o5:
c000000000000000 sp:
fff000b0ffa5f3c1 ret_pc:
00000000004455cc
[ 61.484909] RPC: <schizo_pcierr_intr+0xec/0x560>
[ 61.489500] l0:
fff000b0fd8e9c40 l1:
0000000000a20800 l2:
0000000000000000 l3:
000000000119a430
[ 61.498164] l4:
0000000001742400 l5:
00000000011cfbe0 l6:
00000000011319c0 l7:
fff000b0fd8ea348
[ 61.506830] i0:
0000000000000000 i1:
fff000b0fdb34000 i2:
0000000320000000 i3:
0000000000000000
[ 61.515497] i4:
00060002010b003f i5:
0000040004e02000 i6:
fff000b0ffa5f481 i7:
00000000004a9920
[ 61.524175] I7: <handle_irq_event_percpu+0x40/0x140>
[ 61.529099] Call Trace:
[ 61.531531] [
00000000004a9920] handle_irq_event_percpu+0x40/0x140
[ 61.537681] [
00000000004a9a58] handle_irq_event+0x38/0x80
[ 61.543145] [
00000000004ac77c] handle_fasteoi_irq+0xbc/0x200
[ 61.548860] [
00000000004a9084] generic_handle_irq+0x24/0x40
[ 61.554500] [
000000000042be0c] handler_irq+0xac/0x100
====================
The problem is that pbm->pci_bus->self is NULL.
This code is trying to go through the standard PCI config space
interfaces to read the PCI controller's PCI_STATUS register.
This doesn't work, because we more often than not do not enumerate
the PCI controller as a bonafide PCI device during the OF device
node scan. Therefore bus->self remains NULL.
Existing common code for PSYCHO and PSYCHO-like PCI controllers
handles this properly, by doing the config space access directly.
Do the same here, pbm->pci_ops->{read,write}().
Reported-by: Meelis Roos <mroos@linux.ee>
Tested-by: Meelis Roos <mroos@linux.ee>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Dwight Engen [Thu, 30 Oct 2014 19:55:35 +0000 (15:55 -0400)]
sunvdc: don't call VD_OP_GET_VTOC
[ Upstream commit
85b0c6e62c48bb9179fd5b3e954f362fb346cbd5 ]
The VD_OP_GET_VTOC operation will succeed only if the vdisk backend has a
VTOC label, otherwise it will fail. In particular, it will return error
48 (ENOTSUP) if the disk has an EFI label. VTOC disk labels are already
handled by directly reading the disk in block/partitions/sun.c (enabled by
CONFIG_SUN_PARTITION which defaults to y on SPARC). Since port->label is
unused in the driver, remove the call and the field.
Signed-off-by: Dwight Engen <dwight.engen@oracle.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Dwight Engen [Fri, 19 Sep 2014 13:43:02 +0000 (09:43 -0400)]
vio: fix reuse of vio_dring slot
[ Upstream commit
d0aedcd4f14a22e23b313f42b7e6e6ebfc0fbc31 ]
vio_dring_avail() will allow use of every dring entry, but when the last
entry is allocated then dr->prod == dr->cons which is indistinguishable from
the ring empty condition. This causes the next allocation to reuse an entry.
When this happens in sunvdc, the server side vds driver begins nack'ing the
messages and ends up resetting the ldc channel. This problem does not effect
sunvnet since it checks for < 2.
The fix here is to just never allocate the very last dring slot so that full
and empty are not the same condition. The request start path was changed to
check for the ring being full a bit earlier, and to stop the blk_queue if
there is no space left. The blk_queue will be restarted once the ring is
only half full again. The number of ring entries was increased to 512 which
matches the sunvnet and Solaris vdc drivers, and greatly reduces the
frequency of hitting the ring full condition and the associated blk_queue
stop/starting. The checks in sunvent were adjusted to account for
vio_dring_avail() returning 1 less.
Orabug:
19441666
OraBZ: 14983
Signed-off-by: Dwight Engen <dwight.engen@oracle.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Dwight Engen [Fri, 19 Sep 2014 13:42:53 +0000 (09:42 -0400)]
sunvdc: limit each sg segment to a page
[ Upstream commit
5eed69ffd248c9f68f56c710caf07db134aef28b ]
ldc_map_sg() could fail its check that the number of pages referred to
by the sg scatterlist was <= the number of cookies.
This fixes the issue by doing a similar thing to the xen-blkfront driver,
ensuring that the scatterlist will only ever contain a segment count <=
port->ring_cookies, and each segment will be page aligned, and <= page
size. This ensures that the scatterlist is always mappable.
Orabug:
19347817
OraBZ: 15945
Signed-off-by: Dwight Engen <dwight.engen@oracle.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Allen Pais [Fri, 19 Sep 2014 13:42:26 +0000 (09:42 -0400)]
sunvdc: compute vdisk geometry from capacity
[ Upstream commit
de5b73f08468b4fc5e2f6d1505f650262622f78b ]
The LDom diskserver doesn't return reliable geometry data. In addition,
the types for all fields in the vio_disk_geom are u16, which were being
truncated in the cast into the u8's of the Linux struct hd_geometry.
Modify vdc_getgeo() to compute the geometry from the disk's capacity in a
manner consistent with xen-blkfront::blkif_getgeo().
Signed-off-by: Dwight Engen <dwight.engen@oracle.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Allen Pais [Fri, 19 Sep 2014 13:42:14 +0000 (09:42 -0400)]
sunvdc: add cdrom and v1.1 protocol support
[ Upstream commit
9bce21828d54a95143f1b74619705c2dd8e88b92 ]
Interpret the media type from v1.1 protocol to support CDROM/DVD.
For v1.0 protocol, a disk's size continues to be calculated from the
geometry returned by the vdisk server. The geometry returned by the server
can be less than the actual number of sectors available in the backing
image/device due to the rounding in the division used to compute the
geometry in the vdisk server.
In v1.1 protocol a disk's actual size in sectors is returned during the
handshake. Use this size when v1.1 protocol is negotiated. Since this size
will always be larger than the former geometry computed size, disks created
under v1.0 will be forwards compatible to v1.1, but not vice versa.
Signed-off-by: Dwight Engen <dwight.engen@oracle.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Enric Balletbo i Serra [Thu, 13 Nov 2014 08:14:34 +0000 (09:14 +0100)]
smsc911x: power-up phydev before doing a software reset.
[ Upstream commit
ccf899a27c08038db91765ff12bb0380dcd85887 ]
With commit
be9dad1f9f26604fb ("net: phy: suspend phydev when going
to HALTED"), the PHY device will be put in a low-power mode using
BMCR_PDOWN if the the interface is set down. The smsc911x driver does
a software_reset opening the device driver (ndo_open). In such case,
the PHY must be powered-up before access to any register and before
calling the software_reset function. Otherwise, as the PHY is powered
down the software reset fails and the interface can not be enabled
again.
This patch fixes this scenario that is easy to reproduce setting down
the network interface and setting up again.
$ ifconfig eth0 down
$ ifconfig eth0 up
ifconfig: SIOCSIFFLAGS: Input/output error
Signed-off-by: Enric Balletbo i Serra <eballetbo@iseebcn.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Daniel Borkmann [Mon, 10 Nov 2014 17:00:09 +0000 (18:00 +0100)]
net: sctp: fix memory leak in auth key management
[ Upstream commit
4184b2a79a7612a9272ce20d639934584a1f3786 ]
A very minimal and simple user space application allocating an SCTP
socket, setting SCTP_AUTH_KEY setsockopt(2) on it and then closing
the socket again will leak the memory containing the authentication
key from user space:
unreferenced object 0xffff8800837047c0 (size 16):
comm "a.out", pid 2789, jiffies
4296954322 (age 192.258s)
hex dump (first 16 bytes):
01 00 00 00 04 00 00 00 00 00 00 00 00 00 00 00 ................
backtrace:
[<
ffffffff816d7e8e>] kmemleak_alloc+0x4e/0xb0
[<
ffffffff811c88d8>] __kmalloc+0xe8/0x270
[<
ffffffffa0870c23>] sctp_auth_create_key+0x23/0x50 [sctp]
[<
ffffffffa08718b1>] sctp_auth_set_key+0xa1/0x140 [sctp]
[<
ffffffffa086b383>] sctp_setsockopt+0xd03/0x1180 [sctp]
[<
ffffffff815bfd94>] sock_common_setsockopt+0x14/0x20
[<
ffffffff815beb61>] SyS_setsockopt+0x71/0xd0
[<
ffffffff816e58a9>] system_call_fastpath+0x12/0x17
[<
ffffffffffffffff>] 0xffffffffffffffff
This is bad because of two things, we can bring down a machine from
user space when auth_enable=1, but also we would leave security sensitive
keying material in memory without clearing it after use. The issue is
that sctp_auth_create_key() already sets the refcount to 1, but after
allocation sctp_auth_set_key() does an additional refcount on it, and
thus leaving it around when we free the socket.
Fixes:
65b07e5d0d0 ("[SCTP]: API updates to suport SCTP-AUTH extensions.")
Signed-off-by: Daniel Borkmann <dborkman@redhat.com>
Cc: Vlad Yasevich <vyasevich@gmail.com>
Acked-by: Neil Horman <nhorman@tuxdriver.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Daniel Borkmann [Mon, 10 Nov 2014 16:54:26 +0000 (17:54 +0100)]
net: sctp: fix NULL pointer dereference in af->from_addr_param on malformed packet
[ Upstream commit
e40607cbe270a9e8360907cb1e62ddf0736e4864 ]
An SCTP server doing ASCONF will panic on malformed INIT ping-of-death
in the form of:
------------ INIT[PARAM: SET_PRIMARY_IP] ------------>
While the INIT chunk parameter verification dissects through many things
in order to detect malformed input, it misses to actually check parameters
inside of parameters. E.g. RFC5061, section 4.2.4 proposes a 'set primary
IP address' parameter in ASCONF, which has as a subparameter an address
parameter.
So an attacker may send a parameter type other than SCTP_PARAM_IPV4_ADDRESS
or SCTP_PARAM_IPV6_ADDRESS, param_type2af() will subsequently return 0
and thus sctp_get_af_specific() returns NULL, too, which we then happily
dereference unconditionally through af->from_addr_param().
The trace for the log:
BUG: unable to handle kernel NULL pointer dereference at
0000000000000078
IP: [<
ffffffffa01e9c62>] sctp_process_init+0x492/0x990 [sctp]
PGD 0
Oops: 0000 [#1] SMP
[...]
Pid: 0, comm: swapper Not tainted 2.6.32-504.el6.x86_64 #1 Bochs Bochs
RIP: 0010:[<
ffffffffa01e9c62>] [<
ffffffffa01e9c62>] sctp_process_init+0x492/0x990 [sctp]
[...]
Call Trace:
<IRQ>
[<
ffffffffa01f2add>] ? sctp_bind_addr_copy+0x5d/0xe0 [sctp]
[<
ffffffffa01e1fcb>] sctp_sf_do_5_1B_init+0x21b/0x340 [sctp]
[<
ffffffffa01e3751>] sctp_do_sm+0x71/0x1210 [sctp]
[<
ffffffffa01e5c09>] ? sctp_endpoint_lookup_assoc+0xc9/0xf0 [sctp]
[<
ffffffffa01e61f6>] sctp_endpoint_bh_rcv+0x116/0x230 [sctp]
[<
ffffffffa01ee986>] sctp_inq_push+0x56/0x80 [sctp]
[<
ffffffffa01fcc42>] sctp_rcv+0x982/0xa10 [sctp]
[<
ffffffffa01d5123>] ? ipt_local_in_hook+0x23/0x28 [iptable_filter]
[<
ffffffff8148bdc9>] ? nf_iterate+0x69/0xb0
[<
ffffffff81496d10>] ? ip_local_deliver_finish+0x0/0x2d0
[<
ffffffff8148bf86>] ? nf_hook_slow+0x76/0x120
[<
ffffffff81496d10>] ? ip_local_deliver_finish+0x0/0x2d0
[...]
A minimal way to address this is to check for NULL as we do on all
other such occasions where we know sctp_get_af_specific() could
possibly return with NULL.
Fixes:
d6de3097592b ("[SCTP]: Add the handling of "Set Primary IP Address" parameter to INIT")
Signed-off-by: Daniel Borkmann <dborkman@redhat.com>
Cc: Vlad Yasevich <vyasevich@gmail.com>
Acked-by: Neil Horman <nhorman@tuxdriver.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Marcelo Leitner [Thu, 13 Nov 2014 16:43:08 +0000 (14:43 -0200)]
vxlan: Do not reuse sockets for a different address family
[ Upstream commit
19ca9fc1445b76b60d34148f7ff837b055f5dcf3 ]
Currently, we only match against local port number in order to reuse
socket. But if this new vxlan wants an IPv6 socket and a IPv4 one bound
to that port, vxlan will reuse an IPv4 socket as IPv6 and a panic will
follow. The following steps reproduce it:
# ip link add vxlan6 type vxlan id 42 group 229.10.10.10 \
srcport 5000 6000 dev eth0
# ip link add vxlan7 type vxlan id 43 group ff0e::110 \
srcport 5000 6000 dev eth0
# ip link set vxlan6 up
# ip link set vxlan7 up
<panic>
[ 4.187481] BUG: unable to handle kernel NULL pointer dereference at
0000000000000058
...
[ 4.188076] Call Trace:
[ 4.188085] [<
ffffffff81667c4a>] ? ipv6_sock_mc_join+0x3a/0x630
[ 4.188098] [<
ffffffffa05a6ad6>] vxlan_igmp_join+0x66/0xd0 [vxlan]
[ 4.188113] [<
ffffffff810a3430>] process_one_work+0x220/0x710
[ 4.188125] [<
ffffffff810a33c4>] ? process_one_work+0x1b4/0x710
[ 4.188138] [<
ffffffff810a3a3b>] worker_thread+0x11b/0x3a0
[ 4.188149] [<
ffffffff810a3920>] ? process_one_work+0x710/0x710
So address family must also match in order to reuse a socket.
Reported-by: Jean-Tsung Hsiao <jhsiao@redhat.com>
Signed-off-by: Marcelo Ricardo Leitner <mleitner@redhat.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Steffen Klassert [Mon, 3 Nov 2014 08:19:30 +0000 (09:19 +0100)]
gre6: Move the setting of dev->iflink into the ndo_init functions.
[ Upstream commit
f03eb128e3f4276f46442d14f3b8f864f3775821 ]
Otherwise it gets overwritten by register_netdev().
Signed-off-by: Steffen Klassert <steffen.klassert@secunet.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Steffen Klassert [Mon, 3 Nov 2014 08:19:29 +0000 (09:19 +0100)]
sit: Use ipip6_tunnel_init as the ndo_init function.
[ Upstream commit
ebe084aafb7e93adf210e80043c9f69adf56820d ]
ipip6_tunnel_init() sets the dev->iflink via a call to
ipip6_tunnel_bind_dev(). After that, register_netdevice()
sets dev->iflink = -1. So we loose the iflink configuration
for ipv6 tunnels. Fix this by using ipip6_tunnel_init() as the
ndo_init function. Then ipip6_tunnel_init() is called after
dev->iflink is set to -1 from register_netdevice().
Signed-off-by: Steffen Klassert <steffen.klassert@secunet.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Steffen Klassert [Mon, 3 Nov 2014 08:19:28 +0000 (09:19 +0100)]
vti6: Use vti6_dev_init as the ndo_init function.
[ Upstream commit
16a0231bf7dc3fb37e9b1f1cb1a277dc220b5c5e ]
vti6_dev_init() sets the dev->iflink via a call to
vti6_link_config(). After that, register_netdevice()
sets dev->iflink = -1. So we loose the iflink configuration
for vti6 tunnels. Fix this by using vti6_dev_init() as the
ndo_init function. Then vti6_dev_init() is called after
dev->iflink is set to -1 from register_netdevice().
Signed-off-by: Steffen Klassert <steffen.klassert@secunet.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Steffen Klassert [Mon, 3 Nov 2014 08:19:27 +0000 (09:19 +0100)]
ip6_tunnel: Use ip6_tnl_dev_init as the ndo_init function.
[ Upstream commit
6c6151daaf2d8dc2046d9926539feed5f66bf74e ]
ip6_tnl_dev_init() sets the dev->iflink via a call to
ip6_tnl_link_config(). After that, register_netdevice()
sets dev->iflink = -1. So we loose the iflink configuration
for ipv6 tunnels. Fix this by using ip6_tnl_dev_init() as the
ndo_init function. Then ip6_tnl_dev_init() is called after
dev->iflink is set to -1 from register_netdevice().
Signed-off-by: Steffen Klassert <steffen.klassert@secunet.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Greg Kroah-Hartman [Fri, 14 Nov 2014 18:25:11 +0000 (10:25 -0800)]
Revert "drivers/net: Disable UFO through virtio"
This reverts commit
2b52d6c6beda6308ba95024a1eba1dfc9515ba32 which was
commit
3d0ad09412ffe00c9afa201d01effdb6023d09b4 upstream.
Ben writes:
Please drop this patch for 3.14 and 3.17. It causes problems
for migration of VMs and we're probably going to revert part of
this. The following patch ("drivers/net, ipv6: Select IPv6
fragment idents for virtio UFO packets") might no longer apply,
in which case you can drop that as well until we have this
sorted out upstream.
Cc: Ben Hutchings <ben@decadent.org.uk>
Cc: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Greg Kroah-Hartman [Fri, 14 Nov 2014 17:10:29 +0000 (09:10 -0800)]
Linux 3.14.24
Johannes Weiner [Thu, 2 Oct 2014 23:21:10 +0000 (16:21 -0700)]
mm: page_alloc: fix zone allocation fairness on UP
commit
abe5f972912d086c080be4bde67750630b6fb38b upstream.
The zone allocation batches can easily underflow due to higher-order
allocations or spills to remote nodes. On SMP that's fine, because
underflows are expected from concurrency and dealt with by returning 0.
But on UP, zone_page_state will just return a wrapped unsigned long,
which will get past the <= 0 check and then consider the zone eligible
until its watermarks are hit.
Commit
3a025760fc15 ("mm: page_alloc: spill to remote nodes before
waking kswapd") already made the counter-resetting use
atomic_long_read() to accomodate underflows from remote spills, but it
didn't go all the way with it.
Make it clear that these batches are expected to go negative regardless
of concurrency, and use atomic_long_read() everywhere.
Fixes:
81c0a2bb515f ("mm: page_alloc: fair zone allocator policy")
Reported-by: Vlastimil Babka <vbabka@suse.cz>
Reported-by: Leon Romanovsky <leon@leon.nu>
Signed-off-by: Johannes Weiner <hannes@cmpxchg.org>
Acked-by: Mel Gorman <mgorman@suse.de>
Cc: <stable@vger.kernel.org> [3.12+]
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>
Chris Mason [Tue, 4 Nov 2014 14:59:04 +0000 (06:59 -0800)]
Btrfs: fix kfree on list_head in btrfs_lookup_csums_range error cleanup
commit
6e5aafb27419f32575b27ef9d6a31e5d54661aca upstream.
If we hit any errors in btrfs_lookup_csums_range, we'll loop through all
the csums we allocate and free them. But the code was using list_entry
incorrectly, and ended up trying to free the on-stack list_head instead.
This bug came from commit
0678b6185
btrfs: Don't BUG_ON kzalloc error in btrfs_lookup_csums_range()
Signed-off-by: Chris Mason <clm@fb.com>
Reported-by: Erik Berg <btrfs@slipsprogrammoer.no>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Grant Likely [Mon, 3 Nov 2014 15:15:35 +0000 (15:15 +0000)]
of: Fix overflow bug in string property parsing functions
commit
a87fa1d81a9fb5e9adca9820e16008c40ad09f33 upstream.
The string property read helpers will run off the end of the buffer if
it is handed a malformed string property. Rework the parsers to make
sure that doesn't happen. At the same time add new test cases to make
sure the functions behave themselves.
The original implementations of of_property_read_string_index() and
of_property_count_strings() both open-coded the same block of parsing
code, each with it's own subtly different bugs. The fix here merges
functions into a single helper and makes the original functions static
inline wrappers around the helper.
One non-bugfix aspect of this patch is the addition of a new wrapper,
of_property_read_string_array(). The new wrapper is needed by the
device_properties feature that Rafael is working on and planning to
merge for v3.19. The implementation is identical both with and without
the new static inline wrapper, so it just got left in to reduce the
churn on the header file.
Signed-off-by: Grant Likely <grant.likely@linaro.org>
Cc: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Cc: Mika Westerberg <mika.westerberg@linux.intel.com>
Cc: Rob Herring <robh+dt@kernel.org>
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: Darren Hart <darren.hart@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Yijing Wang [Fri, 7 Nov 2014 04:05:49 +0000 (12:05 +0800)]
sysfs: driver core: Fix glue dir race condition by gdp_mutex
commit
e4a60d139060975eb956717e4f63ae348d4d8cc5 upstream.
There is a race condition when removing glue directory.
It can be reproduced in following test:
path 1: Add first child device
device_add()
get_device_parent()
/*find parent from glue_dirs.list*/
list_for_each_entry(k, &dev->class->p->glue_dirs.list, entry)
if (k->parent == parent_kobj) {
kobj = kobject_get(k);
break;
}
....
class_dir_create_and_add()
path2: Remove last child device under glue dir
device_del()
cleanup_device_parent()
cleanup_glue_dir()
kobject_put(glue_dir);
If path2 has been called cleanup_glue_dir(), but not
call kobject_put(glue_dir), the glue dir is still
in parent's kset list. Meanwhile, path1 find the glue
dir from the glue_dirs.list. Path2 may release glue dir
before path1 call kobject_get(). So kernel will report
the warning and bug_on.
This is a "classic" problem we have of a kref in a list
that can be found while the last instance could be removed
at the same time.
This patch reuse gdp_mutex to fix this race condition.
The following calltrace is captured in kernel 3.4, but
the latest kernel still has this bug.
-----------------------------------------------------
<4>[ 3965.441471] WARNING: at ...include/linux/kref.h:41 kobject_get+0x33/0x40()
<4>[ 3965.441474] Hardware name: Romley
<4>[ 3965.441475] Modules linked in: isd_iop(O) isd_xda(O)...
...
<4>[ 3965.441605] Call Trace:
<4>[ 3965.441611] [<
ffffffff8103717a>] warn_slowpath_common+0x7a/0xb0
<4>[ 3965.441615] [<
ffffffff810371c5>] warn_slowpath_null+0x15/0x20
<4>[ 3965.441618] [<
ffffffff81215963>] kobject_get+0x33/0x40
<4>[ 3965.441624] [<
ffffffff812d1e45>] get_device_parent.isra.11+0x135/0x1f0
<4>[ 3965.441627] [<
ffffffff812d22d4>] device_add+0xd4/0x6d0
<4>[ 3965.441631] [<
ffffffff812d0dbc>] ? dev_set_name+0x3c/0x40
....
<2>[ 3965.441912] kernel BUG at ..../fs/sysfs/group.c:65!
<4>[ 3965.441915] invalid opcode: 0000 [#1] SMP
...
<4>[ 3965.686743] [<
ffffffff811a677e>] sysfs_create_group+0xe/0x10
<4>[ 3965.686748] [<
ffffffff810cfb04>] blk_trace_init_sysfs+0x14/0x20
<4>[ 3965.686753] [<
ffffffff811fcabb>] blk_register_queue+0x3b/0x120
<4>[ 3965.686756] [<
ffffffff812030bc>] add_disk+0x1cc/0x490
....
-------------------------------------------------------
Signed-off-by: Yijing Wang <wangyijing@huawei.com>
Signed-off-by: Weng Meiling <wengmeiling.weng@huawei.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Wolfram Sang [Mon, 3 Nov 2014 20:16:16 +0000 (21:16 +0100)]
i2c: at91: don't account as iowait
commit
11cfbfb098b22d3e57f1f2be217cad20e2d48463 upstream.
iowait is for blkio [1]. I2C shouldn't use it.
[1] https://lkml.org/lkml/2014/11/3/317
Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
Acked-by: Ludovic Desroches <ludovic.desroches@atmel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Krzysztof Kozlowski [Mon, 3 Nov 2014 14:07:05 +0000 (15:07 +0100)]
regulator: max77693: Fix use of uninitialized regulator config
commit
ca0c37a0b489bb14bf3e1549e7a8d0c9a17f4919 upstream.
Driver allocated on stack struct regulator_config but didn't initialize
it fully. Few fields (driver_data, ena_gpio) were left untouched. This
lead to using random ena_gpio values as GPIOs for max77693 regulators.
On occasion these values could match real GPIO numbers leading to
interfering with other drivers and to unsuccessful enable/disable of
regulator.
Signed-off-by: Krzysztof Kozlowski <k.kozlowski@samsung.com>
Fixes:
80b022e29bfd ("regulator: max77693: Add max77693 regualtor driver.")
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Dan Streetman [Fri, 31 Oct 2014 19:41:34 +0000 (15:41 -0400)]
powerpc: use device_online/offline() instead of cpu_up/down()
commit
10ccaf178b2b961d8bca252d647ed7ed8aae2a20 upstream.
In powerpc pseries platform dlpar operations, use device_online() and
device_offline() instead of cpu_up() and cpu_down().
Calling cpu_up/down() directly does not update the cpu device offline
field, which is used to online/offline a cpu from sysfs. Calling
device_online/offline() instead keeps the sysfs cpu online value
correct. The hotplug lock, which is required to be held when calling
device_online/offline(), is already held when dlpar_online/offline_cpu()
are called, since they are called only from cpu_probe|release_store().
This patch fixes errors on phyp (PowerVM) systems that have cpu(s)
added/removed using dlpar operations; without this patch, the
/sys/devices/system/cpu/cpuN/online nodes do not correctly show the
online state of added/removed cpus.
Signed-off-by: Dan Streetman <ddstreet@ieee.org>
Cc: Nathan Fontenot <nfont@linux.vnet.ibm.com>
Fixes:
0902a9044fa5 ("Driver core: Use generic offline/online for CPU offline/online")
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
David Cohen [Tue, 14 Oct 2014 17:54:37 +0000 (10:54 -0700)]
pinctrl: baytrail: show output gpio state correctly on Intel Baytrail
commit
d90c33818967c5e5371961604ad98b4dea4fa3f4 upstream.
Even if a gpio pin is set to output, we still need to set INPUT_EN
functionality (by clearing INPUT_EN bit) to be able to read the pin's
level.
E.g. without this change, we'll always read low level state from sysfs.
Cc: Mathias Nyman <mathias.nyman@linux.intel.com>
Signed-off-by: David Cohen <david.a.cohen@linux.intel.com>
Reviewed-by: Felipe Balbi <balbi@ti.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Hans de Goede [Wed, 22 Oct 2014 14:06:38 +0000 (16:06 +0200)]
acer-wmi: Add acpi_backlight=video quirk for the Acer KAV80
commit
183fd8fcd7f8afb7ac5ec68f83194872f9fecc84 upstream.
The acpi-video backlight interface on the Acer KAV80 is broken, and worse
it causes the entire machine to slow down significantly after a suspend/resume.
Blacklist it, and use the acer-wmi backlight interface instead. Note that
the KAV80 is somewhat unique in that it is the only Acer model where we
fall back to acer-wmi after blacklisting, rather then using the native
(e.g. intel) backlight driver. This is done because there is no native
backlight interface on this model.
BugLink: https://bugzilla.redhat.com/show_bug.cgi?id=1128309
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Darren Hart <dvhart@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Jan Kara [Wed, 22 Oct 2014 07:17:24 +0000 (09:17 +0200)]
rbd: Fix error recovery in rbd_obj_read_sync()
commit
a8d4205623ae965e36c68629db306ca0695a2771 upstream.
When we fail to allocate page vector in rbd_obj_read_sync() we just
basically ignore the problem and continue which will result in an oops
later. Fix the problem by returning proper error.
CC: Yehuda Sadeh <yehuda@inktank.com>
CC: Sage Weil <sage@inktank.com>
CC: ceph-devel@vger.kernel.org
Coverity-id: 1226882
Signed-off-by: Jan Kara <jack@suse.cz>
Signed-off-by: Ilya Dryomov <idryomov@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Alex Deucher [Sun, 26 Oct 2014 19:18:42 +0000 (15:18 -0400)]
drm/radeon: remove invalid pci id
commit
8c3e434769b1707fd2d24de5a2eb25fedc634c4a upstream.
0x4c6e is a secondary device id so should not be used
by the driver.
Noticed-by: Mark Kettenis <mark.kettenis@xs4all.nl>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Alex Deucher [Mon, 13 Oct 2014 16:44:49 +0000 (12:44 -0400)]
drm/radeon/dpm: disable ulv support on SI
commit
6fa455935ab956248b165f150ec6ae9106210077 upstream.
Causes problems on some boards.
bug:
https://bugs.freedesktop.org/show_bug.cgi?id=82889
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>