Chris Wilson [Sun, 29 Sep 2013 18:15:07 +0000 (19:15 +0100)]
drm/i915: Only apply DPMS to the encoder if enabled
commit
c9976dcf55c8aaa7037427b239f15e5acfc01a3a upstream.
The current test for an attached enabled encoder fails if we have
multiple connectors aliased to the same encoder - both connectors
believe they own the enabled encoder and so we attempt to both enable
and disable DPMS on the encoder, leading to hilarity and an OOPs:
[ 354.803064] WARNING: CPU: 0 PID: 482 at
/usr/src/linux/dist/3.11.2/drivers/gpu/drm/i915/intel_display.c:3869 intel_modeset_check_state+0x764/0x770 [i915]()
[ 354.803064] wrong connector dpms state
[ 354.803084] Modules linked in: nfsd auth_rpcgss oid_registry exportfs nfs lockd sunrpc xt_nat iptable_nat nf_nat_ipv4 nf_nat xt_limit xt_LOG xt_tcpudp nf_conntrack_ipv4 nf_defrag_ipv4 ipt_REJECT ipv6 xt_recent xt_conntrack nf_conntrack iptable_filter ip_tables x_tables snd_hda_codec_realtek snd_hda_codec_hdmi x86_pkg_temp_thermal snd_hda_intel coretemp kvm_intel snd_hda_codec i915 kvm snd_hwdep snd_pcm_oss snd_mixer_oss crc32_pclmul snd_pcm crc32c_intel e1000e intel_agp igb ghash_clmulni_intel intel_gtt aesni_intel cfbfillrect aes_x86_64 cfbimgblt lrw cfbcopyarea drm_kms_helper ptp video thermal processor gf128mul snd_page_alloc drm snd_timer glue_helper 8250_pci snd pps_core ablk_helper agpgart cryptd sg soundcore fan i2c_algo_bit sr_mod thermal_sys 8250 i2c_i801 serial_core
hwmon cdrom i2c_core evdev button
[ 354.803086] CPU: 0 PID: 482 Comm: kworker/0:1 Not tainted 3.11.2 #1
[ 354.803087] Hardware name: Supermicro X10SAE/X10SAE, BIOS 1.00 05/03/2013 [ 354.803091] Workqueue: events console_callback
[ 354.803092]
0000000000000009 ffff88023611db48 ffffffff814048ac ffff88023611db90
[ 354.803093]
ffff88023611db80 ffffffff8103d4e3 ffff880230d82800 ffff880230f9b800
[ 354.803094]
ffff880230f99000 ffff880230f99448 ffff8802351c0e00 ffff88023611dbe0
[ 354.803094] Call Trace:
[ 354.803098] [<
ffffffff814048ac>] dump_stack+0x54/0x8d
[ 354.803101] [<
ffffffff8103d4e3>] warn_slowpath_common+0x73/0x90
[ 354.803103] [<
ffffffff8103d547>] warn_slowpath_fmt+0x47/0x50
[ 354.803109] [<
ffffffffa089f1be>] ? intel_ddi_connector_get_hw_state+0x5e/0x110 [i915]
[ 354.803114] [<
ffffffffa0896974>] intel_modeset_check_state+0x764/0x770 [i915]
[ 354.803117] [<
ffffffffa08969bb>] intel_connector_dpms+0x3b/0x60 [i915]
[ 354.803120] [<
ffffffffa037e1d0>] drm_fb_helper_dpms.isra.11+0x120/0x160 [drm_kms_helper]
[ 354.803122] [<
ffffffffa037e24e>] drm_fb_helper_blank+0x3e/0x80 [drm_kms_helper]
[ 354.803123] [<
ffffffff812116c2>] fb_blank+0x52/0xc0
[ 354.803125] [<
ffffffff8121e04b>] fbcon_blank+0x21b/0x2d0
[ 354.803127] [<
ffffffff81062243>] ? update_rq_clock.part.74+0x13/0x30
[ 354.803129] [<
ffffffff81047486>] ? lock_timer_base.isra.30+0x26/0x50
[ 354.803130] [<
ffffffff810472b2>] ? internal_add_timer+0x12/0x40
[ 354.803131] [<
ffffffff81047f48>] ? mod_timer+0xf8/0x1c0
[ 354.803133] [<
ffffffff81266d61>] do_unblank_screen+0xa1/0x1c0
[ 354.803134] [<
ffffffff81268087>] poke_blanked_console+0xc7/0xd0
[ 354.803136] [<
ffffffff812681cf>] console_callback+0x13f/0x160
[ 354.803137] [<
ffffffff81053258>] process_one_work+0x148/0x3d0
[ 354.803138] [<
ffffffff81053f19>] worker_thread+0x119/0x3a0
[ 354.803140] [<
ffffffff81053e00>] ? manage_workers.isra.30+0x2a0/0x2a0
[ 354.803141] [<
ffffffff8105994b>] kthread+0xbb/0xc0
[ 354.803142] [<
ffffffff81059890>] ? kthread_create_on_node+0x120/0x120
[ 354.803144] [<
ffffffff8140b32c>] ret_from_fork+0x7c/0xb0
[ 354.803145] [<
ffffffff81059890>] ? kthread_create_on_node+0x120/0x120
This regression goes back to the big modeset rework and the conversion
to the new dpms helpers which started with:
commit
5ab432ef4997ce32c9406721b37ef6e97e57dae1
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date: Sat Jun 30 08:59:56 2012 +0200
drm/i915/hdmi: convert to encoder->disable/enable
Fixes: igt/kms_flip/dpms-off-confusion
Reported-and-tested-by: Wakko Warner <wakko@animx.eu.org>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=68030
Link: http://lkml.kernel.org/r/
20130928185023.GA21672@animx.eu.org
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
[danvet: Add regression citation, mention the igt testcase this fixes
and slap a cc: stable on the patch.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Al Viro [Sat, 24 Aug 2013 16:08:17 +0000 (12:08 -0400)]
cope with potentially long ->d_dname() output for shmem/hugetlb
commit
118b23022512eb2f41ce42db70dc0568d00be4ba upstream.
dynamic_dname() is both too much and too little for those - the
output may be well in excess of 64 bytes dynamic_dname() assumes
to be enough (thanks to ashmem feeding really long names to
shmem_file_setup()) and vsnprintf() is an overkill for those
guys.
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
Cc: Colin Cross <ccross@google.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
David Henningsson [Mon, 7 Oct 2013 08:39:59 +0000 (10:39 +0200)]
ALSA: hda - Fix mono speakers and headset mic on Dell Vostro 5470
This is a backport for stable. The original commit SHA is
338cae565c53755de9f87d6a801517940d2d56f7.
On this machine, DAC on node 0x03 seems to give mono output.
Also, it needs additional patches for headset mic support.
It supports CTIA style headsets only.
Alsa-info available at the bug link below.
BugLink: https://bugs.launchpad.net/bugs/1236228
Signed-off-by: David Henningsson <david.henningsson@canonical.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Ingo Molnar [Thu, 10 Oct 2013 08:16:30 +0000 (10:16 +0200)]
compiler/gcc4: Add quirk for 'asm goto' miscompilation bug
commit
3f0116c3238a96bc18ad4b4acefe4e7be32fa861 upstream.
Fengguang Wu, Oleg Nesterov and Peter Zijlstra tracked down
a kernel crash to a GCC bug: GCC miscompiles certain 'asm goto'
constructs, as outlined here:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58670
Implement a workaround suggested by Jakub Jelinek.
Reported-and-tested-by: Fengguang Wu <fengguang.wu@intel.com>
Reported-by: Oleg Nesterov <oleg@redhat.com>
Reported-by: Peter Zijlstra <a.p.zijlstra@chello.nl>
Suggested-by: Jakub Jelinek <jakub@redhat.com>
Reviewed-by: Richard Henderson <rth@twiddle.net>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Andrew Morton <akpm@linux-foundation.org>
Link: http://lkml.kernel.org/r/20131015062351.GA4666@gmail.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Dan Carpenter [Fri, 23 Aug 2013 08:40:59 +0000 (11:40 +0300)]
watchdog: ts72xx_wdt: locking bug in ioctl
commit
8612ed0d97abcf1c016d34755b7cf2060de71963 upstream.
Calling the WDIOC_GETSTATUS & WDIOC_GETBOOTSTATUS and twice will cause a
interruptible deadlock.
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Reviewed-by: Guenter Roeck <linux@roeck-us.net>
Signed-off-by: Wim Van Sebroeck <wim@iguana.be>
Cc: Jonghwan Choi <jhbird.choi@samsung.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Vineet Gupta [Thu, 10 Oct 2013 14:03:57 +0000 (19:33 +0530)]
ARC: Ignore ptrace SETREGSET request for synthetic register "stop_pc"
commit
5b24282846c064ee90d40fcb3a8f63b8e754fd28 upstream.
ARCompact TRAP_S insn used for breakpoints, commits before exception is
taken (updating architectural PC). So ptregs->ret contains next-PC and
not the breakpoint PC itself. This is different from other restartable
exceptions such as TLB Miss where ptregs->ret has exact faulting PC.
gdb needs to know exact-PC hence ARC ptrace GETREGSET provides for
@stop_pc which returns ptregs->ret vs. EFA depending on the
situation.
However, writing stop_pc (SETREGSET request), which updates ptregs->ret
doesn't makes sense stop_pc doesn't always correspond to that reg as
described above.
This was not an issue so far since user_regs->ret / user_regs->stop_pc
had same value and both writing to ptregs->ret was OK, needless, but NOT
broken, hence not observed.
With gdb "jump", they diverge, and user_regs->ret updating ptregs is
overwritten immediately with stop_pc, which this patch fixes.
Reported-by: Anton Kolesov <akolesov@synopsys.com>
Signed-off-by: Vineet Gupta <vgupta@synopsys.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Christian Ruppert [Wed, 2 Oct 2013 09:13:38 +0000 (11:13 +0200)]
ARC: Fix signal frame management for SA_SIGINFO
commit
10469350e345599dfef3fa78a7c19fb230e674c1 upstream.
Previously, when a signal was registered with SA_SIGINFO, parameters 2
and 3 of the signal handler were written to registers r1 and r2 before
the register set was saved. This led to corruption of these two
registers after returning from the signal handler (the wrong values were
restored).
With this patch, registers are now saved before any parameters are
passed, thus maintaining the processor state from before signal entry.
Signed-off-by: Christian Ruppert <christian.ruppert@abilis.com>
Signed-off-by: Vineet Gupta <vgupta@synopsys.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Vineet Gupta [Wed, 25 Sep 2013 11:23:32 +0000 (16:53 +0530)]
ARC: Workaround spinlock livelock in SMP SystemC simulation
commit
6c00350b573c0bd3635436e43e8696951dd6e1b6 upstream.
Some ARC SMP systems lack native atomic R-M-W (LLOCK/SCOND) insns and
can only use atomic EX insn (reg with mem) to build higher level R-M-W
primitives. This includes a SystemC based SMP simulation model.
So rwlocks need to use a protecting spinlock for atomic cmp-n-exchange
operation to update reader(s)/writer count.
The spinlock operation itself looks as follows:
mov reg, 1 ; 1=locked, 0=unlocked
retry:
EX reg, [lock] ; load existing, store 1, atomically
BREQ reg, 1, rety ; if already locked, retry
In single-threaded simulation, SystemC alternates between the 2 cores
with "N" insn each based scheduling. Additionally for insn with global
side effect, such as EX writing to shared mem, a core switch is
enforced too.
Given that, 2 cores doing a repeated EX on same location, Linux often
got into a livelock e.g. when both cores were fiddling with tasklist
lock (gdbserver / hackbench) for read/write respectively as the
sequence diagram below shows:
core1 core2
-------- --------
1. spin lock [EX r=0, w=1] - LOCKED
2. rwlock(Read) - LOCKED
3. spin unlock [ST 0] - UNLOCKED
spin lock [EX r=0,w=1] - LOCKED
-- resched core 1----
5. spin lock [EX r=1] - ALREADY-LOCKED
-- resched core 2----
6. rwlock(Write) - READER-LOCKED
7. spin unlock [ST 0]
8. rwlock failed, retry again
9. spin lock [EX r=0, w=1]
-- resched core 1----
10 spinlock locked in #9, retry #5
11. spin lock [EX gets 1]
-- resched core 2----
...
...
The fix was to unlock using the EX insn too (step 7), to trigger another
SystemC scheduling pass which would let core1 proceed, eliding the
livelock.
Signed-off-by: Vineet Gupta <vgupta@synopsys.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Vineet Gupta [Thu, 26 Sep 2013 13:20:40 +0000 (18:50 +0530)]
ARC: Fix 32-bit wrap around in access_ok()
commit
0752adfda15f0eca9859a76da3db1800e129ad43 upstream.
Anton reported
| LTP tests syscalls/process_vm_readv01 and process_vm_writev01 fail
| similarly in one testcase test_iov_invalid -> lvec->iov_base.
| Testcase expects errno EFAULT and return code -1,
| but it gets return code 1 and ERRNO is 0 what means success.
Essentially test case was passing a pointer of -1 which access_ok()
was not catching. It was doing [@addr + @sz <= TASK_SIZE] which would
pass for @addr == -1
Fixed that by rewriting as [@addr <= TASK_SIZE - @sz]
Reported-by: Anton Kolesov <Anton.Kolesov@synopsys.com>
Signed-off-by: Vineet Gupta <vgupta@synopsys.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Mischa Jonker [Thu, 26 Sep 2013 13:44:56 +0000 (15:44 +0200)]
ARC: Handle zero-overhead-loop in unaligned access handler
commit
c11eb222fd7d4db91196121dbf854178505d2751 upstream.
If a load or store is the last instruction in a zero-overhead-loop, and
it's misaligned, the loop would execute only once.
This fixes that problem.
Signed-off-by: Mischa Jonker <mjonker@synopsys.com>
Signed-off-by: Vineet Gupta <vgupta@synopsys.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Mischa Jonker [Fri, 30 Aug 2013 09:56:25 +0000 (11:56 +0200)]
ARC: Fix __udelay calculation
commit
7efd0da2d17360e1cef91507dbe619db0ee2c691 upstream.
Cast usecs to u64, to ensure that the (usecs * 4295 * HZ)
multiplication is 64 bit.
Initially, the (usecs * 4295 * HZ) part was done as a 32 bit
multiplication, with the result casted to 64 bit. This led to some bits
falling off, causing a "DMA initialization error" in the stmmac Ethernet
driver, due to a premature timeout.
Signed-off-by: Mischa Jonker <mjonker@synopsys.com>
Signed-off-by: Vineet Gupta <vgupta@synopsys.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Noam Camus [Thu, 12 Sep 2013 07:37:39 +0000 (13:07 +0530)]
ARC: SMP failed to boot due to missing IVT setup
commit
c3567f8a359b7917dcffa442301f88ed0a75211f upstream.
Commit
05b016ecf5e7a "ARC: Setup Vector Table Base in early boot" moved
the Interrupt vector Table setup out of arc_init_IRQ() which is called
for all CPUs, to entry point of boot cpu only, breaking booting of others.
Fix by adding the same to entry point of non-boot CPUs too.
read_arc_build_cfg_regs() printing IVT Base Register didn't help the
casue since it prints a synthetic value if zero which is totally bogus,
so fix that to print the exact Register.
[vgupta: Remove the now stale comment from header of arc_init_IRQ and
also added the commentary for halt-on-reset]
Cc: Gilad Ben-Yossef <gilad@benyossef.com>
Signed-off-by: Noam Camus <noamc@ezchip.com>
Signed-off-by: Vineet Gupta <vgupta@synopsys.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Vineet Gupta [Mon, 17 Jun 2013 12:57:23 +0000 (18:27 +0530)]
ARC: Setup Vector Table Base in early boot
commit
05b016ecf5e7a8c24409d8e9effb5d2ec9107708 upstream.
Otherwise early boot exceptions such as instructions errors due to
configuration mismatch between kernel and hardware go off to la-la land,
as opposed to hitting the handler and panic()'ing properly.
Signed-off-by: Vineet Gupta <vgupta@synopsys.com>
Cc: Guenter Roeck <linux@roeck-us.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Russell King [Tue, 6 Aug 2013 08:49:14 +0000 (09:49 +0100)]
ARM: Fix the world famous typo with is_gate_vma()
commit
1d0bbf428924f94867542d49d436cf254b9dbd06 upstream.
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Colin Cross <ccross@google.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Helge Deller [Tue, 1 Oct 2013 19:54:46 +0000 (21:54 +0200)]
parisc: fix interruption handler to respect pagefault_disable()
commit
59b33f148cc08fb33cbe823fca1e34f7f023765e upstream.
Running an "echo t > /proc/sysrq-trigger" crashes the parisc kernel. The
problem is, that in print_worker_info() we try to read the workqueue info via
the probe_kernel_read() functions which use pagefault_disable() to avoid
crashes like this:
probe_kernel_read(&pwq, &worker->current_pwq, sizeof(pwq));
probe_kernel_read(&wq, &pwq->wq, sizeof(wq));
probe_kernel_read(name, wq->name, sizeof(name) - 1);
The problem here is, that the first probe_kernel_read(&pwq) might return zero
in pwq and as such the following probe_kernel_reads() try to access contents of
the page zero which is read protected and generate a kernel segfault.
With this patch we fix the interruption handler to call parisc_terminate()
directly only if pagefault_disable() was not called (in which case
preempt_count()==0). Otherwise we hand over to the pagefault handler which
will try to look up the faulting address in the fixup tables.
Signed-off-by: Helge Deller <deller@gmx.de>
Signed-off-by: John David Anglin <dave.anglin@bell.net>
Signed-off-by: Helge Deller <deller@gmx.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Paul Mackerras [Fri, 20 Sep 2013 23:53:28 +0000 (09:53 +1000)]
KVM: PPC: Book3S HV: Fix typo in saving DSCR
commit
cfc860253abd73e1681696c08ea268d33285a2c4 upstream.
This fixes a typo in the code that saves the guest DSCR (Data Stream
Control Register) into the kvm_vcpu_arch struct on guest exit. The
effect of the typo was that the DSCR value was saved in the wrong place,
so changes to the DSCR by the guest didn't persist across guest exit
and entry, and some host kernel memory got corrupted.
Signed-off-by: Paul Mackerras <paulus@samba.org>
Acked-by: Alexander Graf <agraf@suse.de>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Dave Jones [Fri, 11 Oct 2013 00:05:35 +0000 (20:05 -0400)]
ext4: fix memory leak in xattr
commit
6e4ea8e33b2057b85d75175dd89b93f5e26de3bc upstream.
If we take the 2nd retry path in ext4_expand_extra_isize_ea, we
potentionally return from the function without having freed these
allocations. If we don't do the return, we over-write the previous
allocation pointers, so we leak either way.
Spotted with Coverity.
[ Fixed by tytso to set is and bs to NULL after freeing these
pointers, in case in the retry loop we later end up triggering an
error causing a jump to cleanup, at which point we could have a double
free bug. -- Ted ]
Signed-off-by: Dave Jones <davej@fedoraproject.org>
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
Reviewed-by: Eric Sandeen <sandeen@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Josef Bacik [Wed, 9 Oct 2013 16:24:04 +0000 (12:24 -0400)]
Btrfs: use right root when checking for hash collision
commit
4871c1588f92c6c13f4713a7009f25f217055807 upstream.
btrfs_rename was using the root of the old dir instead of the root of the new
dir when checking for a hash collision, so if you tried to move a file into a
subvol it would freak out because it would see the file you are trying to move
in its current root. This fixes the bug where this would fail
btrfs subvol create test1
btrfs subvol create test2
mv test1 test2.
Thanks to Chris Murphy for catching this,
Reported-by: Chris Murphy <lists@colorremedies.com>
Signed-off-by: Josef Bacik <jbacik@fusionio.com>
Signed-off-by: Chris Mason <chris.mason@fusionio.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Henrik Rydberg [Wed, 2 Oct 2013 17:15:03 +0000 (19:15 +0200)]
hwmon: (applesmc) Always read until end of data
commit
25f2bd7f5add608c1d1405938f39c96927b275ca upstream.
The crash reported and investigated in commit 5f4513 turned out to be
caused by a change to the read interface on newer (2012) SMCs.
Tests by Chris show that simply reading the data valid line is enough
for the problem to go away. Additional tests show that the newer SMCs
no longer wait for the number of requested bytes, but start sending
data right away. Apparently the number of bytes to read is no longer
specified as before, but instead found out by reading until end of
data. Failure to read until end of data confuses the state machine,
which eventually causes the crash.
As a remedy, assuming bit0 is the read valid line, make sure there is
nothing more to read before leaving the read function.
Tested to resolve the original problem, and runtested on MBA3,1,
MBP4,1, MBP8,2, MBP10,1, MBP10,2. The patch seems to have no effect on
machines before 2012.
Tested-by: Chris Murphy <chris@cmurf.com>
Signed-off-by: Henrik Rydberg <rydberg@euromail.se>
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Taras Kondratiuk [Mon, 7 Oct 2013 10:41:59 +0000 (13:41 +0300)]
i2c: omap: Clear ARDY bit twice
commit
4cdbf7d346e7461c3b93a26707c852e2c9db3753 upstream.
Initially commit
cb527ede1bf6ff2008a025606f25344b8ed7b4ac
"i2c-omap: Double clear of ARDY status in IRQ handler"
added a workaround for undocumented errata ProDB0017052.
But then commit
1d7afc95946487945cc7f5019b41255b72224b70
"i2c: omap: ack IRQ in parts" refactored code and missed
one of ARDY clearings. So current code violates errata.
It causes often i2c bus timeouts on my Pandaboard.
This patch adds a second clearing in place.
Signed-off-by: Grygorii Strashko <grygorii.strashko@ti.com>
Signed-off-by: Taras Kondratiuk <taras.kondratiuk@linaro.org>
Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Linus Torvalds [Mon, 30 Sep 2013 15:35:10 +0000 (08:35 -0700)]
vfs: allow O_PATH file descriptors for fstatfs()
commit
9d05746e7b16d8565dddbe3200faa1e669d23bbf upstream.
Olga reported that file descriptors opened with O_PATH do not work with
fstatfs(), found during further development of ksh93's thread support.
There is no reason to not allow O_PATH file descriptors here (fstatfs is
very much a path operation), so use "fdget_raw()". See commit
55815f70147d ("vfs: make O_PATH file descriptors usable for 'fstat()'")
for a very similar issue reported for fstat() by the same team.
Reported-and-tested-by: ольга крыжановская <olga.kryzhanovska@gmail.com>
Acked-by: Al Viro <viro@zeniv.linux.org.uk>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Theodore Ts'o [Tue, 10 Sep 2013 14:52:35 +0000 (10:52 -0400)]
random: run random_int_secret_init() run after all late_initcalls
commit
47d06e532e95b71c0db3839ebdef3fe8812fca2c upstream.
The some platforms (e.g., ARM) initializes their clocks as
late_initcalls for some unknown reason. So make sure
random_int_secret_init() is run after all of the late_initcalls are
run.
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
David Henningsson [Fri, 11 Oct 2013 08:18:45 +0000 (10:18 +0200)]
ALSA: hda - Fix microphone for Sony VAIO Pro 13 (Haswell model)
commit
88cfcf86aa3ada84d97195bcad74f4dadb4ae23b upstream.
The external mic showed up with a precense detect of "always present",
essentially disabling the internal mic. Therefore turn off presence
detection for this pin.
Note: The external mic seems not yet working, but an internal mic is
certainly better than no mic at all.
BugLink: https://bugs.launchpad.net/bugs/1227093
Signed-off-by: David Henningsson <david.henningsson@canonical.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Takashi Iwai [Tue, 8 Oct 2013 17:57:50 +0000 (19:57 +0200)]
ALSA: hda - Add fixup for ASUS N56VZ
commit
c6cc3d58b4042f5cadae653ff8d3df26af1a0169 upstream.
ASUS N56VZ needs a fixup for the bass speaker pin, which was already
provided via model=asus-mode4.
Bugzilla: https://bugzilla.novell.com/show_bug.cgi?id=841645
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Anssi Hannula [Mon, 7 Oct 2013 16:24:52 +0000 (19:24 +0300)]
ALSA: hda - hdmi: Fix channel map switch not taking effect
commit
39edac70e9aedf451fccaa851b273ace9fcca0bd upstream.
Currently hdmi_setup_audio_infoframe() reprograms the HDA channel
mapping only when the infoframe is not up-to-date or the non-PCM flag
has changed.
However, when just the channel map has been changed, the infoframe may
still be up-to-date and non-PCM flag may not have changed, so the new
channel map is not actually programmed into the HDA codec.
Notably, this failing case is also always triggered when the device is
already in a prepared state and a new channel map is configured while
changing only the channel positions (for example, plain
"speaker-test -c2 -m FR,FL").
Fix that by always programming the channel map in
hdmi_setup_audio_infoframe(). Tested on Intel HDMI.
Signed-off-by: Anssi Hannula <anssi.hannula@iki.fi>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Daniel Mack [Wed, 2 Oct 2013 15:49:50 +0000 (17:49 +0200)]
ALSA: snd-usb-usx2y: remove bogus frame checks
commit
a9d14bc0b188a822e42787d01e56c06fe9750162 upstream.
The frame check in i_usX2Y_urb_complete() and
i_usX2Y_usbpcm_urb_complete() is bogus and produces false positives as
described in this LAU thread:
http://linuxaudio.org/mailarchive/lau/2013/5/20/200177
This patch removes the check code entirely.
Cc: fzu@wemgehoertderstaat.de
Reported-by: Dr Nicholas J Bailey <nicholas.bailey@glasgow.ac.uk>
Suggested-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Daniel Mack <zonque@gmail.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Greg Kroah-Hartman [Sun, 13 Oct 2013 23:08:56 +0000 (16:08 -0700)]
Linux 3.10.16
Kent Overstreet [Fri, 11 Oct 2013 00:31:15 +0000 (17:31 -0700)]
bcache: Fix a null ptr deref regression
commit
2fe80d3bbf1c8bd9efc5b8154207c8dd104e7306 upstream.
Commit
c0f04d88e46d ("bcache: Fix flushes in writeback mode") was fixing
a reported data corruption bug, but it seems some last minute
refactoring or rebasing introduced a null pointer deref.
Signed-off-by: Kent Overstreet <kmo@daterainc.com>
Reported-by: Gabriel de Perthuis <g2p.code@gmail.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Bjørn Mork [Tue, 10 Sep 2013 13:06:20 +0000 (15:06 +0200)]
net: qmi_wwan: add new Qualcomm devices
commit
0470667caa8261beb8a9141102b04a5357dd45b5 upstream.
Adding the device list from the Windows driver description files
included with a new Qualcomm MDM9615 based device, "Alcatel-sbell
ASB TL131 TDD LTE", from China Mobile. This device is tested
and verified to work. The others are assumed to work based on
using the same Windows driver.
Many of these devices support multiple QMI/wwan ports, requiring
multiple interface matching entries. All devices are composite,
providing a mix of one or more serial, storage or Android Debug
Brigde functions in addition to the wwan function.
This device list included an update of one previously known device,
which was incorrectly assumed to have a Gobi 2K layout. This is
corrected.
Reported-by: 王康 <scateu@gmail.com>
Signed-off-by: Bjørn Mork <bjorn@mork.no>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
David Herrmann [Mon, 9 Sep 2013 16:33:54 +0000 (18:33 +0200)]
HID: uhid: allocate static minor
commit
19872d20c890073c5207d9e02bb8f14d451a11eb upstream.
udev has this nice feature of creating "dead" /dev/<node> device-nodes if
it finds a devnode:<node> modalias. Once the node is accessed, the kernel
automatically loads the module that provides the node. However, this
requires udev to know the major:minor code to use for the node. This
feature was introduced by:
commit
578454ff7eab61d13a26b568f99a89a2c9edc881
Author: Kay Sievers <kay.sievers@vrfy.org>
Date: Thu May 20 18:07:20 2010 +0200
driver core: add devname module aliases to allow module on-demand auto-loading
However, uhid uses dynamic minor numbers so this doesn't actually work. We
need to load uhid to know which minor it's going to use.
Hence, allocate a static minor (just like uinput does) and we're good
to go.
Reported-by: Tom Gundersen <teg@jklm.no>
Signed-off-by: David Herrmann <dh.herrmann@gmail.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Marcel Holtmann [Sun, 1 Sep 2013 18:02:46 +0000 (11:02 -0700)]
HID: uhid: add devname module alias
commit
60cbd53e4bf623fe978e6f23a6da642e730fde3a upstream.
For simple device node creation, add the devname module alias.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Reviewed-by: David Herrmann <dh.herrmann@gmail.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Stefan Achatz [Fri, 30 Aug 2013 12:10:07 +0000 (14:10 +0200)]
HID: roccat: add support for KonePureOptical v2
commit
a4be0ed39f2b1ea990804ea54e39bc42d17ed5a5 upstream.
KonePureOptical is a KonePure with different sensor.
Signed-off-by: Stefan Achatz <erazor_de@users.sourceforge.net>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Josef Bacik [Thu, 22 Aug 2013 21:03:29 +0000 (17:03 -0400)]
Btrfs: remove ourselves from the cluster list under lock
commit
b8d0c69b9469ffd33df30fee3e990f2d4aa68a09 upstream.
A user was reporting weird warnings from btrfs_put_delayed_ref() and I noticed
that we were doing this list_del_init() on our head ref outside of
delayed_refs->lock. This is a problem if we have people still on the list, we
could end up modifying old pointers and such. Fix this by removing us from the
list before we do our run_delayed_ref on our head ref. Thanks,
Signed-off-by: Josef Bacik <jbacik@fusionio.com>
Signed-off-by: Chris Mason <chris.mason@fusionio.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Josef Bacik [Mon, 12 Aug 2013 14:56:14 +0000 (10:56 -0400)]
Btrfs: skip subvol entries when checking if we've created a dir already
commit
a05254143cd183b18002cbba7759a1e4629aa762 upstream.
We have logic to see if we've already created a parent directory by check to see
if an inode inside of that directory has a lower inode number than the one we
are currently processing. The logic is that if there is a lower inode number
then we would have had to made sure the directory was created at that previous
point. The problem is that subvols inode numbers count from the lowest objectid
in the root tree, which may be less than our current progress. So just skip if
our dir item key is a root item. This fixes the original test and the xfstest
version I made that added an extra subvol create. Thanks,
Reported-by: Emil Karlson <jekarlson@gmail.com>
Signed-off-by: Josef Bacik <jbacik@fusionio.com>
Signed-off-by: Chris Mason <chris.mason@fusionio.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Josef Bacik [Tue, 30 Jul 2013 20:30:30 +0000 (16:30 -0400)]
Btrfs: change how we queue blocks for backref checking
commit
b6c60c8018c4e9beb2f83fc82c09f9d033766571 upstream.
Previously we only added blocks to the list to have their backrefs checked if
the level of the block is right above the one we are searching for. This is
because we want to make sure we don't add the entire path up to the root to the
lists to make sure we process things one at a time. This assumes that if any
blocks in the path to the root are going to be not checked (shared in other
words) then they will be in the level right above the current block on up. This
isn't quite right though since we can have blocks higher up the list that are
shared because they are attached to a reloc root. But we won't add this block
to be checked and then later on we will BUG_ON(!upper->checked). So instead
keep track of wether or not we've queued a block to be checked in this current
search, and if we haven't go ahead and queue it to be checked. This patch fixed
the panic I was seeing where we BUG_ON(!upper->checked). Thanks,
Signed-off-by: Josef Bacik <jbacik@fusionio.com>
Signed-off-by: Chris Mason <chris.mason@fusionio.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Martin Schwidefsky [Fri, 27 Sep 2013 13:24:38 +0000 (15:24 +0200)]
s390: fix system call restart after inferior call
commit
dbbfe487e5f3fc00c9fe5207d63309859704d12f upstream.
Git commit
616498813b11ffef "s390: system call path micro optimization"
introduced a regression in regard to system call restarting and inferior
function calls via the ptrace interface. The pointer to the system call
table needs to be loaded in sysc_sigpending if do_signal returns with
TIF_SYSCALl set after it restored a system call context.
Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Chris Metcalf [Thu, 26 Sep 2013 17:24:53 +0000 (13:24 -0400)]
tile: use a more conservative __my_cpu_offset in CONFIG_PREEMPT
commit
f862eefec0b68e099a9fa58d3761ffb10bad97e1 upstream.
It turns out the kernel relies on barrier() to force a reload of the
percpu offset value. Since we can't easily modify the definition of
barrier() to include "tp" as an output register, we instead provide a
definition of __my_cpu_offset as extended assembly that includes a fake
stack read to hazard against barrier(), forcing gcc to know that it
must reread "tp" and recompute anything based on "tp" after a barrier.
This fixes observed hangs in the slub allocator when we are looping
on a percpu cmpxchg_double.
A similar fix for ARMv7 was made in June in change
509eb76ebf97.
Signed-off-by: Chris Metcalf <cmetcalf@tilera.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Takashi Iwai [Mon, 30 Sep 2013 10:13:44 +0000 (12:13 +0200)]
ALSA: hda - Fix GPIO for Acer Aspire 3830TG
commit
4a4370442c996be0fd08234a167c8a127c2488bb upstream.
Acer Aspire 3830TG seems requiring GPIO bit 0 as the primary mute
control. When a machine is booted after Windows 8, the GPIO pin is
turned off and it results in the silent output.
This patch adds the manual fixup of GPIO bit 0 for this model.
Reported-by: Christopher <DIDI2002@web.de>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Ben Skeggs [Tue, 10 Sep 2013 02:11:01 +0000 (12:11 +1000)]
drm/nouveau/bios/init: stub opcode 0xaa
commit
5495e39fb3695182b9f2a72fe4169056cada37a1 upstream.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Mark Tinguely [Mon, 23 Sep 2013 17:18:58 +0000 (12:18 -0500)]
xfs: fix node forward in xfs_node_toosmall
commit
997def25e4b9cee3b01609e18a52f926bca8bd2b upstream.
Commit
f5ea1100 cleans up the disk to host conversions for
node directory entries, but because a variable is reused in
xfs_node_toosmall() the next node is not correctly found.
If the original node is small enough (<= 3/8 of the node size),
this change may incorrectly cause a node collapse when it should
not. That will cause an assert in xfstest generic/319:
Assertion failed: first <= last && last < BBTOB(bp->b_length),
file: /root/newest/xfs/fs/xfs/xfs_trans_buf.c, line: 569
Keep the original node header to get the correct forward node.
(When a node is considered for a merge with a sibling, it overwrites the
sibling pointers of the original incore nodehdr with the sibling's
pointers. This leads to loop considering the original node as a merge
candidate with itself in the second pass, and so it incorrectly
determines a merge should occur.)
[v3: added Dave Chinner's (slightly modified) suggestion to the commit header,
cleaned up whitespace. -bpm]
Signed-off-by: Mark Tinguely <tinguely@sgi.com>
Reviewed-by: Ben Myers <bpm@sgi.com>
Signed-off-by: Ben Myers <bpm@sgi.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Lv Zheng [Fri, 13 Sep 2013 05:13:23 +0000 (13:13 +0800)]
ACPI / IPMI: Fix atomic context requirement of ipmi_msg_handler()
commit
06a8566bcf5cf7db9843a82cde7a33c7bf3947d9 upstream.
This patch fixes the issues indicated by the test results that
ipmi_msg_handler() is invoked in atomic context.
BUG: scheduling while atomic: kipmi0/18933/0x10000100
Modules linked in: ipmi_si acpi_ipmi ...
CPU: 3 PID: 18933 Comm: kipmi0 Tainted: G AW 3.10.0-rc7+ #2
Hardware name: QCI QSSC-S4R/QSSC-S4R, BIOS QSSC-S4R.QCI.01.00.0027.
070120100606 07/01/2010
ffff8838245eea00 ffff88103fc63c98 ffffffff814c4a1e ffff88103fc63ca8
ffffffff814bfbab ffff88103fc63d28 ffffffff814c73e0 ffff88103933cbd4
0000000000000096 ffff88103fc63ce8 ffff88102f618000 ffff881035c01fd8
Call Trace:
<IRQ> [<
ffffffff814c4a1e>] dump_stack+0x19/0x1b
[<
ffffffff814bfbab>] __schedule_bug+0x46/0x54
[<
ffffffff814c73e0>] __schedule+0x83/0x59c
[<
ffffffff81058853>] __cond_resched+0x22/0x2d
[<
ffffffff814c794b>] _cond_resched+0x14/0x1d
[<
ffffffff814c6d82>] mutex_lock+0x11/0x32
[<
ffffffff8101e1e9>] ? __default_send_IPI_dest_field.constprop.0+0x53/0x58
[<
ffffffffa09e3f9c>] ipmi_msg_handler+0x23/0x166 [ipmi_si]
[<
ffffffff812bf6e4>] deliver_response+0x55/0x5a
[<
ffffffff812c0fd4>] handle_new_recv_msgs+0xb67/0xc65
[<
ffffffff81007ad1>] ? read_tsc+0x9/0x19
[<
ffffffff814c8620>] ? _raw_spin_lock_irq+0xa/0xc
[<
ffffffffa09e1128>] ipmi_thread+0x5c/0x146 [ipmi_si]
...
Also Tony Camuso says:
We were getting occasional "Scheduling while atomic" call traces
during boot on some systems. Problem was first seen on a Cisco C210
but we were able to reproduce it on a Cisco c220m3. Setting
CONFIG_LOCKDEP and LOCKDEP_SUPPORT to 'y' exposed a lockdep around
tx_msg_lock in acpi_ipmi.c struct acpi_ipmi_device.
=================================
[ INFO: inconsistent lock state ]
2.6.32-415.el6.x86_64-debug-splck #1
---------------------------------
inconsistent {SOFTIRQ-ON-W} -> {IN-SOFTIRQ-W} usage.
ksoftirqd/3/17 [HC0[0]:SC1[1]:HE1:SE0] takes:
(&ipmi_device->tx_msg_lock){+.?...}, at: [<
ffffffff81337a27>] ipmi_msg_handler+0x71/0x126
{SOFTIRQ-ON-W} state was registered at:
[<
ffffffff810ba11c>] __lock_acquire+0x63c/0x1570
[<
ffffffff810bb0f4>] lock_acquire+0xa4/0x120
[<
ffffffff815581cc>] __mutex_lock_common+0x4c/0x400
[<
ffffffff815586ea>] mutex_lock_nested+0x4a/0x60
[<
ffffffff8133789d>] acpi_ipmi_space_handler+0x11b/0x234
[<
ffffffff81321c62>] acpi_ev_address_space_dispatch+0x170/0x1be
The fix implemented by this change has been tested by Tony:
Tested the patch in a boot loop with lockdep debug enabled and never
saw the problem in over 400 reboots.
Reported-and-tested-by: Tony Camuso <tcamuso@redhat.com>
Signed-off-by: Lv Zheng <lv.zheng@intel.com>
Reviewed-by: Huang Ying <ying.huang@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Cc: Jonghwan Choi <jhbird.choi@samsung.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Michael Grzeschik [Tue, 17 Sep 2013 13:56:06 +0000 (15:56 +0200)]
dmaengine: imx-dma: fix slow path issue in prep_dma_cyclic
commit
edc530fe7ee5a562680615d2e7cd205879c751a7 upstream.
When perparing cyclic_dma buffers by the sound layer, it will dump the
following lockdep trace. The leading snd_pcm_action_single get called
with read_lock_irq called. To fix this, we change the kcalloc call from
GFP_KERNEL to GFP_ATOMIC.
WARNING: at kernel/lockdep.c:2740 lockdep_trace_alloc+0xcc/0x114()
DEBUG_LOCKS_WARN_ON(irqs_disabled_flags(flags))
Modules linked in:
CPU: 0 PID: 832 Comm: aplay Not tainted 3.11.0-
20130823+ #903
Backtrace:
[<
c000b98c>] (dump_backtrace+0x0/0x10c) from [<
c000bb28>] (show_stack+0x18/0x1c)
r6:
c004c090 r5:
00000009 r4:
c2e0bd18 r3:
00404000
[<
c000bb10>] (show_stack+0x0/0x1c) from [<
c02f397c>] (dump_stack+0x20/0x28)
[<
c02f395c>] (dump_stack+0x0/0x28) from [<
c001531c>] (warn_slowpath_common+0x54/0x70)
[<
c00152c8>] (warn_slowpath_common+0x0/0x70) from [<
c00153dc>] (warn_slowpath_fmt+0x38/0x40)
r8:
00004000 r7:
a3b90000 r6:
000080d0 r5:
60000093 r4:
c2e0a000 r3:
00000009
[<
c00153a4>] (warn_slowpath_fmt+0x0/0x40) from [<
c004c090>] (lockdep_trace_alloc+0xcc/0x114)
r3:
c03955d8 r2:
c03907db
[<
c004bfc4>] (lockdep_trace_alloc+0x0/0x114) from [<
c008f16c>] (__kmalloc+0x34/0x118)
r6:
000080d0 r5:
c3800120 r4:
000080d0 r3:
c040a0f8
[<
c008f138>] (__kmalloc+0x0/0x118) from [<
c019c95c>] (imxdma_prep_dma_cyclic+0x64/0x168)
r7:
a3b90000 r6:
00000004 r5:
c39d8420 r4:
c3847150
[<
c019c8f8>] (imxdma_prep_dma_cyclic+0x0/0x168) from [<
c024618c>] (snd_dmaengine_pcm_trigger+0xa8/0x160)
[<
c02460e4>] (snd_dmaengine_pcm_trigger+0x0/0x160) from [<
c0241fa8>] (soc_pcm_trigger+0x90/0xb4)
r8:
c058c7b0 r7:
c3b8140c r6:
c39da560 r5:
00000001 r4:
c3b81000
[<
c0241f18>] (soc_pcm_trigger+0x0/0xb4) from [<
c022ece4>] (snd_pcm_do_start+0x2c/0x38)
r7:
00000000 r6:
00000003 r5:
c058c7b0 r4:
c3b81000
[<
c022ecb8>] (snd_pcm_do_start+0x0/0x38) from [<
c022e958>] (snd_pcm_action_single+0x40/0x6c)
[<
c022e918>] (snd_pcm_action_single+0x0/0x6c) from [<
c022ea64>] (snd_pcm_action_lock_irq+0x7c/0x9c)
r7:
00000003 r6:
c3b810f0 r5:
c3b810f0 r4:
c3b81000
[<
c022e9e8>] (snd_pcm_action_lock_irq+0x0/0x9c) from [<
c023009c>] (snd_pcm_common_ioctl1+0x7f8/0xfd0)
r8:
c3b7f888 r7:
005407b8 r6:
c2c991c0 r5:
c3b81000 r4:
c3b81000 r3:
00004142
[<
c022f8a4>] (snd_pcm_common_ioctl1+0x0/0xfd0) from [<
c023117c>] (snd_pcm_playback_ioctl1+0x464/0x488)
[<
c0230d18>] (snd_pcm_playback_ioctl1+0x0/0x488) from [<
c02311d4>] (snd_pcm_playback_ioctl+0x34/0x40)
r8:
c3b7f888 r7:
00004142 r6:
00000004 r5:
c2c991c0 r4:
005407b8
[<
c02311a0>] (snd_pcm_playback_ioctl+0x0/0x40) from [<
c00a14a4>] (vfs_ioctl+0x30/0x44)
[<
c00a1474>] (vfs_ioctl+0x0/0x44) from [<
c00a1fe8>] (do_vfs_ioctl+0x55c/0x5c0)
[<
c00a1a8c>] (do_vfs_ioctl+0x0/0x5c0) from [<
c00a208c>] (SyS_ioctl+0x40/0x68)
[<
c00a204c>] (SyS_ioctl+0x0/0x68) from [<
c0009380>] (ret_fast_syscall+0x0/0x44)
r8:
c0009544 r7:
00000036 r6:
bedeaa58 r5:
00000000 r4:
000000c0
Signed-off-by: Michael Grzeschik <m.grzeschik@pengutronix.de>
Signed-off-by: Vinod Koul <vinod.koul@intel.com>
Cc: Jonghwan Choi <jhbird.choi@samsung.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Michael Grzeschik [Tue, 17 Sep 2013 13:56:08 +0000 (15:56 +0200)]
dmaengine: imx-dma: fix callback path in tasklet
commit
fcaaba6c7136fe47e5a13352f99a64b019b6d2c5 upstream.
We need to free the ld_active list head before jumping into the callback
routine. Otherwise the callback could run into issue_pending and change
our ld_active list head we just going to free. This will run the channel
list into an currupted and undefined state.
Signed-off-by: Michael Grzeschik <m.grzeschik@pengutronix.de>
Signed-off-by: Vinod Koul <vinod.koul@intel.com>
Cc: Jonghwan Choi <jhbird.choi@samsung.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Michael Grzeschik [Tue, 17 Sep 2013 13:56:07 +0000 (15:56 +0200)]
dmaengine: imx-dma: fix lockdep issue between irqhandler and tasklet
commit
5a276fa6bdf82fd442046969603968c83626ce0b upstream.
The tasklet and irqhandler are using spin_lock while other routines are
using spin_lock_irqsave/restore. This leads to lockdep issues as
described bellow. This patch is changing the code to use
spinlock_irq_save/restore in both code pathes.
As imxdma_xfer_desc always gets called with spin_lock_irqsave lock held,
this patch also removes the spare call inside the routine to avoid
double locking.
[ 403.358162] =================================
[ 403.362549] [ INFO: inconsistent lock state ]
[ 403.366945] 3.10.0-
20130823+ #904 Not tainted
[ 403.371331] ---------------------------------
[ 403.375721] inconsistent {IN-HARDIRQ-W} -> {HARDIRQ-ON-W} usage.
[ 403.381769] swapper/0 [HC0[0]:SC1[1]:HE1:SE0] takes:
[ 403.386762] (&(&imxdma->lock)->rlock){?.-...}, at: [<
c019d77c>] imxdma_tasklet+0x20/0x134
[ 403.395201] {IN-HARDIRQ-W} state was registered at:
[ 403.400108] [<
c004b264>] mark_lock+0x2a0/0x6b4
[ 403.404798] [<
c004d7c8>] __lock_acquire+0x650/0x1a64
[ 403.410004] [<
c004f15c>] lock_acquire+0x94/0xa8
[ 403.414773] [<
c02f74e4>] _raw_spin_lock+0x54/0x8c
[ 403.419720] [<
c019d094>] dma_irq_handler+0x78/0x254
[ 403.424845] [<
c0061124>] handle_irq_event_percpu+0x38/0x1b4
[ 403.430670] [<
c00612e4>] handle_irq_event+0x44/0x64
[ 403.435789] [<
c0063a70>] handle_level_irq+0xd8/0xf0
[ 403.440903] [<
c0060a20>] generic_handle_irq+0x28/0x38
[ 403.446194] [<
c0009cc4>] handle_IRQ+0x68/0x8c
[ 403.450789] [<
c0008714>] avic_handle_irq+0x3c/0x48
[ 403.455811] [<
c0008f84>] __irq_svc+0x44/0x74
[ 403.460314] [<
c0040b04>] cpu_startup_entry+0x88/0xf4
[ 403.465525] [<
c02f00d0>] rest_init+0xb8/0xe0
[ 403.470045] [<
c03e07dc>] start_kernel+0x28c/0x2d4
[ 403.474986] [<
a0008040>] 0xa0008040
[ 403.478709] irq event stamp: 50854
[ 403.482140] hardirqs last enabled at (50854): [<
c001c6b8>] tasklet_action+0x38/0xdc
[ 403.489954] hardirqs last disabled at (50853): [<
c001c6a0>] tasklet_action+0x20/0xdc
[ 403.497761] softirqs last enabled at (50850): [<
c001bc64>] _local_bh_enable+0x14/0x18
[ 403.505741] softirqs last disabled at (50851): [<
c001c268>] irq_exit+0x88/0xdc
[ 403.513026]
[ 403.513026] other info that might help us debug this:
[ 403.519593] Possible unsafe locking scenario:
[ 403.519593]
[ 403.525548] CPU0
[ 403.528020] ----
[ 403.530491] lock(&(&imxdma->lock)->rlock);
[ 403.534828] <Interrupt>
[ 403.537474] lock(&(&imxdma->lock)->rlock);
[ 403.541983]
[ 403.541983] *** DEADLOCK ***
[ 403.541983]
[ 403.547951] no locks held by swapper/0.
[ 403.551813]
[ 403.551813] stack backtrace:
[ 403.556222] CPU: 0 PID: 0 Comm: swapper Not tainted 3.10.0-
20130823+ #904
[ 403.563039] Backtrace:
[ 403.565581] [<
c000b98c>] (dump_backtrace+0x0/0x10c) from [<
c000bb28>] (show_stack+0x18/0x1c)
[ 403.574054] r6:
00000000 r5:
c05c51d8 r4:
c040bd58 r3:
00200000
[ 403.579872] [<
c000bb10>] (show_stack+0x0/0x1c) from [<
c02f398c>] (dump_stack+0x20/0x28)
[ 403.587955] [<
c02f396c>] (dump_stack+0x0/0x28) from [<
c02f29c8>] (print_usage_bug.part.28+0x224/0x28c)
[ 403.597340] [<
c02f27a4>] (print_usage_bug.part.28+0x0/0x28c) from [<
c004b404>] (mark_lock+0x440/0x6b4)
[ 403.606682] r8:
c004a41c r7:
00000000 r6:
c040bd58 r5:
c040c040 r4:
00000002
[ 403.613566] [<
c004afc4>] (mark_lock+0x0/0x6b4) from [<
c004d844>] (__lock_acquire+0x6cc/0x1a64)
[ 403.622244] [<
c004d178>] (__lock_acquire+0x0/0x1a64) from [<
c004f15c>] (lock_acquire+0x94/0xa8)
[ 403.631010] [<
c004f0c8>] (lock_acquire+0x0/0xa8) from [<
c02f74e4>] (_raw_spin_lock+0x54/0x8c)
[ 403.639614] [<
c02f7490>] (_raw_spin_lock+0x0/0x8c) from [<
c019d77c>] (imxdma_tasklet+0x20/0x134)
[ 403.648434] r6:
c3847010 r5:
c040e890 r4:
c38470d4
[ 403.653194] [<
c019d75c>] (imxdma_tasklet+0x0/0x134) from [<
c001c70c>] (tasklet_action+0x8c/0xdc)
[ 403.662013] r8:
c0599160 r7:
00000000 r6:
00000000 r5:
c040e890 r4:
c3847114 r3:
c019d75c
[ 403.670042] [<
c001c680>] (tasklet_action+0x0/0xdc) from [<
c001bd4c>] (__do_softirq+0xe4/0x1f0)
[ 403.678687] r7:
00000101 r6:
c0402000 r5:
c059919c r4:
00000001
[ 403.684498] [<
c001bc68>] (__do_softirq+0x0/0x1f0) from [<
c001c268>] (irq_exit+0x88/0xdc)
[ 403.692652] [<
c001c1e0>] (irq_exit+0x0/0xdc) from [<
c0009cc8>] (handle_IRQ+0x6c/0x8c)
[ 403.700514] r4:
00000030 r3:
00000110
[ 403.704192] [<
c0009c5c>] (handle_IRQ+0x0/0x8c) from [<
c0008714>] (avic_handle_irq+0x3c/0x48)
[ 403.712664] r5:
c0403f28 r4:
c0593ebc
[ 403.716343] [<
c00086d8>] (avic_handle_irq+0x0/0x48) from [<
c0008f84>] (__irq_svc+0x44/0x74)
[ 403.724733] Exception stack(0xc0403f28 to 0xc0403f70)
[ 403.729841] 3f20:
00000001 00000004 00000000 20000013 c0402000 c04104a8
[ 403.738078] 3f40:
00000002 c0b69620 a0004000 41069264 a03fb5f4 c0403f7c c0403f40 c0403f70
[ 403.746301] 3f60:
c004b92c c0009e74 20000013 ffffffff
[ 403.751383] r6:
ffffffff r5:
20000013 r4:
c0009e74 r3:
c004b92c
[ 403.757210] [<
c0009e30>] (arch_cpu_idle+0x0/0x4c) from [<
c0040b04>] (cpu_startup_entry+0x88/0xf4)
[ 403.766161] [<
c0040a7c>] (cpu_startup_entry+0x0/0xf4) from [<
c02f00d0>] (rest_init+0xb8/0xe0)
[ 403.774753] [<
c02f0018>] (rest_init+0x0/0xe0) from [<
c03e07dc>] (start_kernel+0x28c/0x2d4)
[ 403.783051] r6:
c03fc484 r5:
ffffffff r4:
c040a0e0
[ 403.787797] [<
c03e0550>] (start_kernel+0x0/0x2d4) from [<
a0008040>] (0xa0008040)
Signed-off-by: Michael Grzeschik <m.grzeschik@pengutronix.de>
Signed-off-by: Vinod Koul <vinod.koul@intel.com>
Cc: Jonghwan Choi <jhbird.choi@samsung.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Rafał Miłecki [Thu, 10 Oct 2013 05:56:07 +0000 (07:56 +0200)]
Revert "drm/radeon: add missing hdmi callbacks for rv6xx"
This reverts commit
b2a9484006875ecd7d94582e7bcb72a02682be92.
Commit
99d79aa2f3b7729e7290e8bda5d0dd8b0240ec62 (backported by
b2a9484006875ecd7d94582e7bcb72a02682be92) was supposed to fix rv6xx_asic
struct.
In kernel 3.10 we didn't have that struct yet, so the original patch
should never be backported to the 3.10. Accidentally it has applied and
modified different struct (r520_asic) that shouldn't have any HDMI
callbacks at all.
Signed-off-by: Rafał Miłecki <zajec5@gmail.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Frederic Weisbecker [Mon, 23 Sep 2013 22:50:25 +0000 (00:50 +0200)]
irq: Force hardirq exit's softirq processing on its own stack
commit
ded797547548a5b8e7b92383a41e4c0e6b0ecb7f upstream.
The commit
facd8b80c67a3cf64a467c4a2ac5fb31f2e6745b
("irq: Sanitize invoke_softirq") converted irq exit
calls of do_softirq() to __do_softirq() on all architectures,
assuming it was only used there for its irq disablement
properties.
But as a side effect, the softirqs processed in the end
of the hardirq are always called on the inline current
stack that is used by irq_exit() instead of the softirq
stack provided by the archs that override do_softirq().
The result is mostly safe if the architecture runs irq_exit()
on a separate irq stack because then softirqs are processed
on that same stack that is near empty at this stage (assuming
hardirq aren't nesting).
Otherwise irq_exit() runs in the task stack and so does the softirq
too. The interrupted call stack can be randomly deep already and
the softirq can dig through it even further. To add insult to the
injury, this softirq can be interrupted by a new hardirq, maximizing
the chances for a stack overrun as reported in powerpc for example:
do_IRQ: stack overflow: 1920
CPU: 0 PID: 1602 Comm: qemu-system-ppc Not tainted 3.10.4-300.1.fc19.ppc64p7 #1
Call Trace:
[
c0000000050a8740] .show_stack+0x130/0x200 (unreliable)
[
c0000000050a8810] .dump_stack+0x28/0x3c
[
c0000000050a8880] .do_IRQ+0x2b8/0x2c0
[
c0000000050a8930] hardware_interrupt_common+0x154/0x180
--- Exception: 501 at .cp_start_xmit+0x3a4/0x820 [8139cp]
LR = .cp_start_xmit+0x390/0x820 [8139cp]
[
c0000000050a8d40] .dev_hard_start_xmit+0x394/0x640
[
c0000000050a8e00] .sch_direct_xmit+0x110/0x260
[
c0000000050a8ea0] .dev_queue_xmit+0x260/0x630
[
c0000000050a8f40] .br_dev_queue_push_xmit+0xc4/0x130 [bridge]
[
c0000000050a8fc0] .br_dev_xmit+0x198/0x270 [bridge]
[
c0000000050a9070] .dev_hard_start_xmit+0x394/0x640
[
c0000000050a9130] .dev_queue_xmit+0x428/0x630
[
c0000000050a91d0] .ip_finish_output+0x2a4/0x550
[
c0000000050a9290] .ip_local_out+0x50/0x70
[
c0000000050a9310] .ip_queue_xmit+0x148/0x420
[
c0000000050a93b0] .tcp_transmit_skb+0x4e4/0xaf0
[
c0000000050a94a0] .__tcp_ack_snd_check+0x7c/0xf0
[
c0000000050a9520] .tcp_rcv_established+0x1e8/0x930
[
c0000000050a95f0] .tcp_v4_do_rcv+0x21c/0x570
[
c0000000050a96c0] .tcp_v4_rcv+0x734/0x930
[
c0000000050a97a0] .ip_local_deliver_finish+0x184/0x360
[
c0000000050a9840] .ip_rcv_finish+0x148/0x400
[
c0000000050a98d0] .__netif_receive_skb_core+0x4f8/0xb00
[
c0000000050a99d0] .netif_receive_skb+0x44/0x110
[
c0000000050a9a70] .br_handle_frame_finish+0x2bc/0x3f0 [bridge]
[
c0000000050a9b20] .br_nf_pre_routing_finish+0x2ac/0x420 [bridge]
[
c0000000050a9bd0] .br_nf_pre_routing+0x4dc/0x7d0 [bridge]
[
c0000000050a9c70] .nf_iterate+0x114/0x130
[
c0000000050a9d30] .nf_hook_slow+0xb4/0x1e0
[
c0000000050a9e00] .br_handle_frame+0x290/0x330 [bridge]
[
c0000000050a9ea0] .__netif_receive_skb_core+0x34c/0xb00
[
c0000000050a9fa0] .netif_receive_skb+0x44/0x110
[
c0000000050aa040] .napi_gro_receive+0xe8/0x120
[
c0000000050aa0c0] .cp_rx_poll+0x31c/0x590 [8139cp]
[
c0000000050aa1d0] .net_rx_action+0x1dc/0x310
[
c0000000050aa2b0] .__do_softirq+0x158/0x330
[
c0000000050aa3b0] .irq_exit+0xc8/0x110
[
c0000000050aa430] .do_IRQ+0xdc/0x2c0
[
c0000000050aa4e0] hardware_interrupt_common+0x154/0x180
--- Exception: 501 at .bad_range+0x1c/0x110
LR = .get_page_from_freelist+0x908/0xbb0
[
c0000000050aa7d0] .list_del+0x18/0x50 (unreliable)
[
c0000000050aa850] .get_page_from_freelist+0x908/0xbb0
[
c0000000050aa9e0] .__alloc_pages_nodemask+0x21c/0xae0
[
c0000000050aaba0] .alloc_pages_vma+0xd0/0x210
[
c0000000050aac60] .handle_pte_fault+0x814/0xb70
[
c0000000050aad50] .__get_user_pages+0x1a4/0x640
[
c0000000050aae60] .get_user_pages_fast+0xec/0x160
[
c0000000050aaf10] .__gfn_to_pfn_memslot+0x3b0/0x430 [kvm]
[
c0000000050aafd0] .kvmppc_gfn_to_pfn+0x64/0x130 [kvm]
[
c0000000050ab070] .kvmppc_mmu_map_page+0x94/0x530 [kvm]
[
c0000000050ab190] .kvmppc_handle_pagefault+0x174/0x610 [kvm]
[
c0000000050ab270] .kvmppc_handle_exit_pr+0x464/0x9b0 [kvm]
[
c0000000050ab320] kvm_start_lightweight+0x1ec/0x1fc [kvm]
[
c0000000050ab4f0] .kvmppc_vcpu_run_pr+0x168/0x3b0 [kvm]
[
c0000000050ab9c0] .kvmppc_vcpu_run+0xc8/0xf0 [kvm]
[
c0000000050aba50] .kvm_arch_vcpu_ioctl_run+0x5c/0x1a0 [kvm]
[
c0000000050abae0] .kvm_vcpu_ioctl+0x478/0x730 [kvm]
[
c0000000050abc90] .do_vfs_ioctl+0x4ec/0x7c0
[
c0000000050abd80] .SyS_ioctl+0xd4/0xf0
[
c0000000050abe30] syscall_exit+0x0/0x98
Since this is a regression, this patch proposes a minimalistic
and low-risk solution by blindly forcing the hardirq exit processing of
softirqs on the softirq stack. This way we should reduce significantly
the opportunities for task stack overflow dug by softirqs.
Longer term solutions may involve extending the hardirq stack coverage to
irq_exit(), etc...
Reported-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Acked-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Frederic Weisbecker <fweisbec@gmail.com>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: Paul Mackerras <paulus@au1.ibm.com>
Cc: Ingo Molnar <mingo@kernel.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: H. Peter Anvin <hpa@zytor.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Paul Mackerras <paulus@au1.ibm.com>
Cc: James Hogan <james.hogan@imgtec.com>
Cc: James E.J. Bottomley <jejb@parisc-linux.org>
Cc: Helge Deller <deller@gmx.de>
Cc: Martin Schwidefsky <schwidefsky@de.ibm.com>
Cc: Heiko Carstens <heiko.carstens@de.ibm.com>
Cc: David S. Miller <davem@davemloft.net>
Cc: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Eric W. Biederman [Sat, 5 Oct 2013 20:15:30 +0000 (13:15 -0700)]
net: Update the sysctl permissions handler to test effective uid/gid
commit
2433c8f094a008895e66f25bd1773cdb01c91d01 upstream.
Modify the code to use current_euid(), and in_egroup_p, as in done
in fs/proc/proc_sysctl.c:test_perm()
Reviewed-by: Eric Sandeen <sandeen@redhat.com>
Reported-by: Eric Sandeen <sandeen@redhat.com>
Signed-off-by: "Eric W. Biederman" <ebiederm@xmission.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Nicholas Bellinger [Thu, 3 Oct 2013 20:37:21 +0000 (13:37 -0700)]
iscsi-target: Only perform wait_for_tasks when performing shutdown
commit
e255a28598e8e63070322fc89bd34189dd660a89 upstream.
This patch changes transport_generic_free_cmd() to only wait_for_tasks
when shutdown=true is passed to iscsit_free_cmd().
With the advent of >= v3.10 iscsi-target code using se_cmd->cmd_kref,
the extra wait_for_tasks with shutdown=false is unnecessary, and may
end up causing an extra context switch when releasing WRITEs.
Signed-off-by: Nicholas Bellinger <nab@linux-iscsi.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Rafael Aquini [Mon, 30 Sep 2013 20:45:16 +0000 (13:45 -0700)]
mm: avoid reinserting isolated balloon pages into LRU lists
commit
117aad1e9e4d97448d1df3f84b08bd65811e6d6a upstream.
Isolated balloon pages can wrongly end up in LRU lists when
migrate_pages() finishes its round without draining all the isolated
page list.
The same issue can happen when reclaim_clean_pages_from_list() tries to
reclaim pages from an isolated page list, before migration, in the CMA
path. Such balloon page leak opens a race window against LRU lists
shrinkers that leads us to the following kernel panic:
BUG: unable to handle kernel NULL pointer dereference at
0000000000000028
IP: [<
ffffffff810c2625>] shrink_page_list+0x24e/0x897
PGD
3cda2067 PUD
3d713067 PMD 0
Oops: 0000 [#1] SMP
CPU: 0 PID: 340 Comm: kswapd0 Not tainted 3.12.0-rc1-22626-g4367597 #87
Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011
RIP: shrink_page_list+0x24e/0x897
RSP: 0000:
ffff88003da499b8 EFLAGS:
00010286
RAX:
0000000000000000 RBX:
ffff88003e82bd60 RCX:
00000000000657d5
RDX:
0000000000000000 RSI:
000000000000031f RDI:
ffff88003e82bd40
RBP:
ffff88003da49ab0 R08:
0000000000000001 R09:
0000000081121a45
R10:
ffffffff81121a45 R11:
ffff88003c4a9a28 R12:
ffff88003e82bd40
R13:
ffff88003da0e800 R14:
0000000000000001 R15:
ffff88003da49d58
FS:
0000000000000000(0000) GS:
ffff88003fc00000(0000) knlGS:
0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0:
0000000080050033
CR2:
00000000067d9000 CR3:
000000003ace5000 CR4:
00000000000407b0
Call Trace:
shrink_inactive_list+0x240/0x3de
shrink_lruvec+0x3e0/0x566
__shrink_zone+0x94/0x178
shrink_zone+0x3a/0x82
balance_pgdat+0x32a/0x4c2
kswapd+0x2f0/0x372
kthread+0xa2/0xaa
ret_from_fork+0x7c/0xb0
Code: 80 7d 8f 01 48 83 95 68 ff ff ff 00 4c 89 e7 e8 5a 7b 00 00 48 85 c0 49 89 c5 75 08 80 7d 8f 00 74 3e eb 31 48 8b 80 18 01 00 00 <48> 8b 74 0d 48 8b 78 30 be 02 00 00 00 ff d2 eb
RIP [<
ffffffff810c2625>] shrink_page_list+0x24e/0x897
RSP <
ffff88003da499b8>
CR2:
0000000000000028
---[ end trace
703d2451af6ffbfd ]---
Kernel panic - not syncing: Fatal exception
This patch fixes the issue, by assuring the proper tests are made at
putback_movable_pages() & reclaim_clean_pages_from_list() to avoid
isolated balloon pages being wrongly reinserted in LRU lists.
[akpm@linux-foundation.org: clarify awkward comment text]
Signed-off-by: Rafael Aquini <aquini@redhat.com>
Reported-by: Luiz Capitulino <lcapitulino@redhat.com>
Tested-by: Luiz Capitulino <lcapitulino@redhat.com>
Cc: Mel Gorman <mel@csn.ul.ie>
Cc: Rik van Riel <riel@redhat.com>
Cc: Hugh Dickins <hughd@google.com>
Cc: Johannes Weiner <hannes@cmpxchg.org>
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>
Christian Lamparter [Tue, 24 Sep 2013 19:56:46 +0000 (21:56 +0200)]
p54usb: add USB ID for Corega WLUSB2GTST USB adapter
commit
1e43692cdb7cc445d6347d8a5207d9cef0c71434 upstream.
Added USB ID for Corega WLUSB2GTST USB adapter.
Reported-by: Joerg Kalisch <the_force@gmx.de>
Signed-off-by: Christian Lamparter <chunkeey@googlemail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Larry Finger [Thu, 19 Sep 2013 02:21:35 +0000 (21:21 -0500)]
rtlwifi: Align private space in rtl_priv struct
commit
60ce314d1750fef843e9db70050e09e49f838b69 upstream.
The private array at the end of the rtl_priv struct is not aligned.
On ARM architecture, this causes an alignment trap and is fixed by aligning
that array with __align(sizeof(void *)). That should properly align that
space according to the requirements of all architectures.
Reported-by: Jason Andrews <jasona@cadence.com>
Tested-by: Jason Andrews <jasona@cadence.com>
Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Jack Wang [Mon, 30 Sep 2013 08:09:05 +0000 (10:09 +0200)]
ib_srpt: always set response for task management
commit
c807f64340932e19f0d2ac9b30c8381e1f60663a upstream.
The SRP specification requires:
"Response data shall be provided in any SRP_RSP response that is sent in
response to an SRP_TSK_MGMT request (see 6.7). The information in the
RSP_CODE field (see table 24) shall indicate the completion status of
the task management function."
So fix this to avoid the SRP initiator interprets task management functions
that succeeded as failed.
Signed-off-by: Jack Wang <jinpu.wang@profitbricks.com>
Signed-off-by: Nicholas Bellinger <nab@linux-iscsi.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Nicholas Bellinger [Wed, 18 Sep 2013 19:48:27 +0000 (12:48 -0700)]
ib_srpt: Destroy cm_id before destroying QP.
commit
0b41d6ca616ddeb3b6c0a80e8770b6f53cd42806 upstream.
This patch fixes a bug where ib_destroy_cm_id() was incorrectly being called
after srpt_destroy_ch_ib() had destroyed the active QP.
This would result in the following failed SRP_LOGIN_REQ messages:
Received SRP_LOGIN_REQ with i_port_id 0x0:0x2590ffff1762bd, t_port_id 0x2c903009f8f40:0x2c903009f8f40 and it_iu_len 260 on port 1 (guid=0xfe80000000000000:0x2c903009f8f41)
Received SRP_LOGIN_REQ with i_port_id 0x0:0x2590ffff1758f9, t_port_id 0x2c903009f8f40:0x2c903009f8f40 and it_iu_len 260 on port 2 (guid=0xfe80000000000000:0x2c903009f8f42)
Received SRP_LOGIN_REQ with i_port_id 0x0:0x2590ffff175941, t_port_id 0x2c903009f8f40:0x2c903009f8f40 and it_iu_len 260 on port 2 (guid=0xfe80000000000000:0x2c90300a3cfb2)
Received SRP_LOGIN_REQ with i_port_id 0x0:0x2590ffff176299, t_port_id 0x2c903009f8f40:0x2c903009f8f40 and it_iu_len 260 on port 1 (guid=0xfe80000000000000:0x2c90300a3cfb1)
mlx4_core 0000:84:00.0: command 0x19 failed: fw status = 0x9
rejected SRP_LOGIN_REQ because creating a new RDMA channel failed.
Received SRP_LOGIN_REQ with i_port_id 0x0:0x2590ffff176299, t_port_id 0x2c903009f8f40:0x2c903009f8f40 and it_iu_len 260 on port 1 (guid=0xfe80000000000000:0x2c90300a3cfb1)
mlx4_core 0000:84:00.0: command 0x19 failed: fw status = 0x9
rejected SRP_LOGIN_REQ because creating a new RDMA channel failed.
Received SRP_LOGIN_REQ with i_port_id 0x0:0x2590ffff176299, t_port_id 0x2c903009f8f40:0x2c903009f8f40 and it_iu_len 260 on port 1 (guid=0xfe80000000000000:0x2c90300a3cfb1)
Reported-by: Navin Ahuja <navin.ahuja@saratoga-speed.com>
Signed-off-by: Nicholas Bellinger <nab@linux-iscsi.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
David Vrabel [Tue, 1 Oct 2013 18:00:49 +0000 (19:00 +0100)]
xen/hvc: allow xenboot console to be used again
commit
a9fbf4d591da6cd1d3eaab826c7c15f77fc8f6a3 upstream.
Commit
d0380e6c3c0f6edb986d8798a23acfaf33d5df23 (early_printk:
consolidate random copies of identical code) added in 3.10 introduced
a check for con->index == -1 in early_console_register().
Initialize index to -1 for the xenboot console so earlyprintk=xen
works again.
Signed-off-by: David Vrabel <david.vrabel@citrix.com>
Cc: Jiri Slaby <jslaby@suse.cz>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Michal Malý [Sat, 28 Sep 2013 17:50:27 +0000 (19:50 +0200)]
USB: serial: option: Ignore card reader interface on Huawei E1750
commit
eb2addd4044b4b2ce77693bde5bc810536dd96ee upstream.
Hi,
my Huawei 3G modem has an embedded Smart Card reader which causes
trouble when the modem is being detected (a bunch of "<warn> (ttyUSBx):
open blocked by driver for more than 7 seconds!" in messages.log). This
trivial patch corrects the problem for me. The modem identifies itself
as "12d1:1406 Huawei Technologies Co., Ltd. E1750" in lsusb although the
description on the body says "Model E173u-1"
Signed-off-by: Michal Malý <madcatxster@prifuk.cz>
Cc: Bjørn Mork <bjorn@mork.no>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Bing Zhao [Sat, 21 Sep 2013 02:56:45 +0000 (19:56 -0700)]
mwifiex: fix PCIe hs_cfg cancel cmd timeout
commit
b7be1522def9a9988b67afd0be999c50a96394b5 upstream.
For pcie8897, the hs_cfg cancel command (0xe5) times out when host
comes out of suspend. This is caused by an incompleted host sleep
handshake between driver and firmware.
Like SDIO interface, PCIe also needs to go through firmware power
save events to complete the handshake for host sleep configuration.
Only USB interface doesn't require power save events for hs_cfg.
Signed-off-by: Bing Zhao <bzhao@marvell.com>
Signed-off-by: Amitkumar Karwar <akarwar@marvell.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Amitkumar Karwar [Wed, 25 Sep 2013 02:31:24 +0000 (19:31 -0700)]
mwifiex: fix hang issue for USB chipsets
commit
bd1c6142edce787b8ac1be15635f845aa9905333 upstream.
Bug 60815 - Interface hangs in mwifiex_usb
https://bugzilla.kernel.org/show_bug.cgi?id=60815
We have 4 bytes of interface header for packets delivered to SDIO
and PCIe, but not for USB interface.
In Tx AMSDU case, currently 4 bytes of garbage data is unnecessarily
appended for USB packets. This sometimes leads to a firmware hang,
because it may not interpret the data packet correctly.
Problem is fixed by removing this redundant headroom for USB.
Tested-by: Dmitry Khromov <icechrome@gmail.com>
Signed-off-by: Amitkumar Karwar <akarwar@marvell.com>
Signed-off-by: Bing Zhao <bzhao@marvell.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Bing Zhao [Wed, 25 Sep 2013 02:31:25 +0000 (19:31 -0700)]
mwifiex: fix NULL pointer dereference in usb suspend handler
commit
346ece0b7ba2730b4d633b9e371fe55488803102 upstream.
Bug 60815 - Interface hangs in mwifiex_usb
https://bugzilla.kernel.org/show_bug.cgi?id=60815
[ 2.883807] BUG: unable to handle kernel NULL pointer dereference
at
0000000000000048
[ 2.883813] IP: [<
ffffffff815a65e0>] pfifo_fast_enqueue+0x90/0x90
[ 2.883834] CPU: 1 PID: 3220 Comm: kworker/u8:90 Not tainted
3.11.1-monotone-l0 #6
[ 2.883834] Hardware name: Microsoft Corporation Surface with
Windows 8 Pro/Surface with Windows 8 Pro,
BIOS 1.03.0450 03/29/2013
On Surface Pro, suspend to ram gives a NULL pointer dereference in
pfifo_fast_enqueue(). The stack trace reveals that the offending
call is clearing carrier in mwifiex_usb suspend handler.
Since commit 1499d9f "mwifiex: don't drop carrier flag over suspend"
has removed the carrier flag handling over suspend/resume in SDIO
and PCIe drivers, I'm removing it in USB driver too. This also fixes
the bug for Surface Pro.
Tested-by: Dmitry Khromov <icechrome@gmail.com>
Signed-off-by: Bing Zhao <bzhao@marvell.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Trond Myklebust [Thu, 26 Sep 2013 18:08:36 +0000 (14:08 -0400)]
NFSv4.1: nfs4_fl_prepare_ds - fix bugs when the connect attempt fails
commit
52b26a3e1bb3e065c32b3febdac1e1f117d88e15 upstream.
- Fix an Oops when nfs4_ds_connect() returns an error.
- Always check the device status after waiting for a connect to complete.
Reported-by: Andy Adamson <andros@netapp.com>
Reported-by: Jeff Layton <jlayton@redhat.com>
Signed-off-by: Trond Myklebust <Trond.Myklebust@netapp.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Ian Abbott [Wed, 2 Oct 2013 13:57:51 +0000 (14:57 +0100)]
staging: comedi: ni_65xx: (bug fix) confine insn_bits to one subdevice
commit
677a31565692d596ef42ea589b53ba289abf4713 upstream.
The `insn_bits` handler `ni_65xx_dio_insn_bits()` has a `for` loop that
currently writes (optionally) and reads back up to 5 "ports" consisting
of 8 channels each. It reads up to 32 1-bit channels but can only read
and write a whole port at once - it needs to handle up to 5 ports as the
first channel it reads might not be aligned on a port boundary. It
breaks out of the loop early if the next port it handles is beyond the
final port on the card. It also breaks out early on the 5th port in the
loop if the first channel was aligned. Unfortunately, it doesn't check
that the current port it is dealing with belongs to the comedi subdevice
the `insn_bits` handler is acting on. That's a bug.
Redo the `for` loop to terminate after the final port belonging to the
subdevice, changing the loop variable in the process to simplify things
a bit. The `for` loop could now try and handle more than 5 ports if the
subdevice has more than 40 channels, but the test `if (bitshift >= 32)`
ensures it will break out early after 4 or 5 ports (depending on whether
the first channel is aligned on a port boundary). (`bitshift` will be
between -7 and 7 inclusive on the first iteration, increasing by 8 for
each subsequent operation.)
Signed-off-by: Ian Abbott <abbotti@mev.co.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Darrick J. Wong [Mon, 30 Sep 2013 20:45:09 +0000 (13:45 -0700)]
mm/bounce.c: fix a regression where MS_SNAP_STABLE (stable pages snapshotting) was ignored
commit
83b2944fd2532b92db099cb3ada12df32a05b368 upstream.
The "force" parameter in __blk_queue_bounce was being ignored, which
means that stable page snapshots are not always happening (on ext3).
This of course leads to DIF disks reporting checksum errors, so fix this
regression.
The regression was introduced in commit
6bc454d15004 ("bounce: Refactor
__blk_queue_bounce to not use bi_io_vec")
Reported-by: Mel Gorman <mgorman@suse.de>
Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com>
Cc: Kent Overstreet <koverstreet@google.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
David Miller [Wed, 2 Oct 2013 18:25:09 +0000 (14:25 -0400)]
mm: Fix generic hugetlb pte check return type.
[ Upstream commit
26794942461f438a6bc725ec7294b08a6bd782c4 ]
The include/asm-generic/hugetlb.h stubs that just vector huge_pte_*()
calls to the pte_*() implementations won't work in certain situations.
x86 and sparc, for example, return "unsigned long" from the bit
checks, and just go "return pte_val(pte) & PTE_BIT_FOO;"
But since huge_pte_*() returns 'int', if any high bits on 64-bit are
relevant, they get chopped off.
The net effect is that we can loop forever trying to COW a huge page,
because the huge_pte_write() check signals false all the time.
Reported-by: Gurudas Pai <gurudas.pai@oracle.com>
Tested-by: Gurudas Pai <gurudas.pai@oracle.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Acked-by: David Rientjes <rientjes@google.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Kirill Tkhai [Thu, 25 Jul 2013 21:17:15 +0000 (01:17 +0400)]
sparc32: Fix exit flag passed from traced sys_sigreturn
[ Upstream commit
7a3b0f89e3fea680f93932691ca41a68eee7ab5e ]
Pass 1 in %o1 to indicate that syscall_trace accounts exit.
Signed-off-by: Kirill Tkhai <tkhai@yandex.ru>
CC: David Miller <davem@davemloft.net>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Kirill Tkhai [Fri, 26 Jul 2013 13:21:12 +0000 (17:21 +0400)]
sparc64: Fix not SRA'ed %o5 in 32-bit traced syscall
[ Upstream commit
ab2abda6377723e0d5fbbfe5f5aa16a5523344d1 ]
(From v1 to v2: changed comment)
On the way linux_sparc_syscall32->linux_syscall_trace32->goto 2f,
register %o5 doesn't clear its second 32-bit.
Fix that.
Signed-off-by: Kirill Tkhai <tkhai@yandex.ru>
CC: David Miller <davem@davemloft.net>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
David S. Miller [Thu, 22 Aug 2013 23:38:46 +0000 (16:38 -0700)]
sparc64: Fix off by one in trampoline TLB mapping installation loop.
[ Upstream commit
63d499662aeec1864ec36d042aca8184ea6a938e ]
Reported-by: Kirill Tkhai <tkhai@yandex.ru>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Kees Cook [Wed, 2 Oct 2013 05:13:34 +0000 (22:13 -0700)]
sparc: fix ldom_reboot buffer overflow harder
[ Upstream commit
20928bd3f08afb036c096d9559d581926b895918 ]
The length argument to strlcpy was still wrong. It could overflow the end of
full_boot_str by 5 bytes. Instead of strcat and strlcpy, just use snprint.
Reported-by: Brad Spengler <spender@grsecurity.net>
Signed-off-by: Kees Cook <keescook@chromium.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
David S. Miller [Fri, 27 Sep 2013 20:46:04 +0000 (13:46 -0700)]
sparc64: Fix buggy strlcpy() conversion in ldom_reboot().
[ Upstream commit
2bd161a605f1f84a5fc8a4fe8410113a94f79355 ]
Commit
117a0c5fc9c2d06045bd217385b2b39ea426b5a6 ("sparc: kernel: using
strlcpy() instead of strcpy()") added a bug to ldom_reboot in
arch/sparc/kernel/ds.c
- strcpy(full_boot_str + strlen("boot "), boot_command);
+ strlcpy(full_boot_str + strlen("boot "), boot_command,
+ sizeof(full_boot_str + strlen("boot ")));
That last sizeof() expression evaluates to sizeof(size_t) which is
not what was intended.
Also even the corrected:
sizeof(full_boot_str) + strlen("boot ")
is not right as the destination buffer length is just plain
"sizeof(full_boot_str)" and that's what the final argument
should be.
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Kirill Tkhai [Mon, 12 Aug 2013 12:02:24 +0000 (16:02 +0400)]
sparc64: Remove RWSEM export leftovers
[ Upstream commit
61d9b9355b0d427bd1e732bd54628ff9103e496f ]
The functions
__down_read
__down_read_trylock
__down_write
__down_write_trylock
__up_read
__up_write
__downgrade_write
are implemented inline, so remove corresponding EXPORT_SYMBOLs
(They lead to compile errors on RT kernel).
Signed-off-by: Kirill Tkhai <tkhai@yandex.ru>
CC: David Miller <davem@davemloft.net>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Kirill Tkhai [Fri, 2 Aug 2013 15:23:18 +0000 (19:23 +0400)]
sparc64: Fix ITLB handler of null page
[ Upstream commit
1c2696cdaad84580545a2e9c0879ff597880b1a9 ]
1)Use kvmap_itlb_longpath instead of kvmap_dtlb_longpath.
2)Handle page #0 only, don't handle page #1: bleu -> blu
(KERNBASE is 0x400000, so #1 does not exist too. But everything
is possible in the future. Fix to not to have problems later.)
3)Remove unused kvmap_itlb_nonlinear.
Signed-off-by: Kirill Tkhai <tkhai@yandex.ru>
CC: David Miller <davem@davemloft.net>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
David S. Miller [Fri, 2 Aug 2013 01:08:34 +0000 (18:08 -0700)]
esp_scsi: Fix tag state corruption when autosensing.
[ Upstream commit
21af8107f27878813d0364733c0b08813c2c192a ]
Meelis Roos reports a crash in esp_free_lun_tag() in the presense
of a disk which has died.
The issue is that when we issue an autosense command, we do so by
hijacking the original command that caused the check-condition.
When we do so we clear out the ent->tag[] array when we issue it via
find_and_prep_issuable_command(). This is so that the autosense
command is forced to be issued non-tagged.
That is problematic, because it is the value of ent->tag[] which
determines whether we issued the original scsi command as tagged
vs. non-tagged (see esp_alloc_lun_tag()).
And that, in turn, is what trips up the sanity checks in
esp_free_lun_tag(). That function needs the original ->tag[] values
in order to free up the tag slot properly.
Fix this by remembering the original command's tag values, and
having esp_alloc_lun_tag() and esp_free_lun_tag() use them.
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>
Vyacheslav Dubeyko [Mon, 30 Sep 2013 20:45:12 +0000 (13:45 -0700)]
nilfs2: fix issue with race condition of competition between segments for dirty blocks
commit
7f42ec3941560f0902fe3671e36f2c20ffd3af0a upstream.
Many NILFS2 users were reported about strange file system corruption
(for example):
NILFS: bad btree node (blocknr=185027): level = 0, flags = 0x0, nchildren = 768
NILFS error (device sda4): nilfs_bmap_last_key: broken bmap (inode number=11540)
But such error messages are consequence of file system's issue that takes
place more earlier. Fortunately, Jerome Poulin <jeromepoulin@gmail.com>
and Anton Eliasson <devel@antoneliasson.se> were reported about another
issue not so recently. These reports describe the issue with segctor
thread's crash:
BUG: unable to handle kernel paging request at
0000000000004c83
IP: nilfs_end_page_io+0x12/0xd0 [nilfs2]
Call Trace:
nilfs_segctor_do_construct+0xf25/0x1b20 [nilfs2]
nilfs_segctor_construct+0x17b/0x290 [nilfs2]
nilfs_segctor_thread+0x122/0x3b0 [nilfs2]
kthread+0xc0/0xd0
ret_from_fork+0x7c/0xb0
These two issues have one reason. This reason can raise third issue
too. Third issue results in hanging of segctor thread with eating of
100% CPU.
REPRODUCING PATH:
One of the possible way or the issue reproducing was described by
Jermoe me Poulin <jeromepoulin@gmail.com>:
1. init S to get to single user mode.
2. sysrq+E to make sure only my shell is running
3. start network-manager to get my wifi connection up
4. login as root and launch "screen"
5. cd /boot/log/nilfs which is a ext3 mount point and can log when NILFS dies.
6. lscp | xz -9e > lscp.txt.xz
7. mount my snapshot using mount -o cp=3360839,ro /dev/vgUbuntu/root /mnt/nilfs
8. start a screen to dump /proc/kmsg to text file since rsyslog is killed
9. start a screen and launch strace -f -o find-cat.log -t find
/mnt/nilfs -type f -exec cat {} > /dev/null \;
10. start a screen and launch strace -f -o apt-get.log -t apt-get update
11. launch the last command again as it did not crash the first time
12. apt-get crashes
13. ps aux > ps-aux-crashed.log
13. sysrq+W
14. sysrq+E wait for everything to terminate
15. sysrq+SUSB
Simplified way of the issue reproducing is starting kernel compilation
task and "apt-get update" in parallel.
REPRODUCIBILITY:
The issue is reproduced not stable [60% - 80%]. It is very important to
have proper environment for the issue reproducing. The critical
conditions for successful reproducing:
(1) It should have big modified file by mmap() way.
(2) This file should have the count of dirty blocks are greater that
several segments in size (for example, two or three) from time to time
during processing.
(3) It should be intensive background activity of files modification
in another thread.
INVESTIGATION:
First of all, it is possible to see that the reason of crash is not valid
page address:
NILFS [nilfs_segctor_complete_write]:2100 bh->b_count 0, bh->b_blocknr
13895680, bh->b_size
13897727, bh->b_page
0000000000001a82
NILFS [nilfs_segctor_complete_write]:2101 segbuf->sb_segnum 6783
Moreover, value of b_page (0x1a82) is 6786. This value looks like segment
number. And b_blocknr with b_size values look like block numbers. So,
buffer_head's pointer points on not proper address value.
Detailed investigation of the issue is discovered such picture:
[-----------------------------SEGMENT 6783-------------------------------]
NILFS [nilfs_segctor_do_construct]:2310 nilfs_segctor_begin_construction
NILFS [nilfs_segctor_do_construct]:2321 nilfs_segctor_collect
NILFS [nilfs_segctor_do_construct]:2336 nilfs_segctor_assign
NILFS [nilfs_segctor_do_construct]:2367 nilfs_segctor_update_segusage
NILFS [nilfs_segctor_do_construct]:2371 nilfs_segctor_prepare_write
NILFS [nilfs_segctor_do_construct]:2376 nilfs_add_checksums_on_logs
NILFS [nilfs_segctor_do_construct]:2381 nilfs_segctor_write
NILFS [nilfs_segbuf_submit_bio]:464 bio->bi_sector
111149024, segbuf->sb_segnum 6783
[-----------------------------SEGMENT 6784-------------------------------]
NILFS [nilfs_segctor_do_construct]:2310 nilfs_segctor_begin_construction
NILFS [nilfs_segctor_do_construct]:2321 nilfs_segctor_collect
NILFS [nilfs_lookup_dirty_data_buffers]:782 bh->b_count 1, bh->b_page
ffffea000709b000, page->index 0, i_ino 1033103, i_size
25165824
NILFS [nilfs_lookup_dirty_data_buffers]:783 bh->b_assoc_buffers.next
ffff8802174a6798, bh->b_assoc_buffers.prev
ffff880221cffee8
NILFS [nilfs_segctor_do_construct]:2336 nilfs_segctor_assign
NILFS [nilfs_segctor_do_construct]:2367 nilfs_segctor_update_segusage
NILFS [nilfs_segctor_do_construct]:2371 nilfs_segctor_prepare_write
NILFS [nilfs_segctor_do_construct]:2376 nilfs_add_checksums_on_logs
NILFS [nilfs_segctor_do_construct]:2381 nilfs_segctor_write
NILFS [nilfs_segbuf_submit_bh]:575 bh->b_count 1, bh->b_page
ffffea000709b000, page->index 0, i_ino 1033103, i_size
25165824
NILFS [nilfs_segbuf_submit_bh]:576 segbuf->sb_segnum 6784
NILFS [nilfs_segbuf_submit_bh]:577 bh->b_assoc_buffers.next
ffff880218a0d5f8, bh->b_assoc_buffers.prev
ffff880218bcdf50
NILFS [nilfs_segbuf_submit_bio]:464 bio->bi_sector
111150080, segbuf->sb_segnum 6784, segbuf->sb_nbio 0
[----------] ditto
NILFS [nilfs_segbuf_submit_bio]:464 bio->bi_sector
111164416, segbuf->sb_segnum 6784, segbuf->sb_nbio 15
[-----------------------------SEGMENT 6785-------------------------------]
NILFS [nilfs_segctor_do_construct]:2310 nilfs_segctor_begin_construction
NILFS [nilfs_segctor_do_construct]:2321 nilfs_segctor_collect
NILFS [nilfs_lookup_dirty_data_buffers]:782 bh->b_count 2, bh->b_page
ffffea000709b000, page->index 0, i_ino 1033103, i_size
25165824
NILFS [nilfs_lookup_dirty_data_buffers]:783 bh->b_assoc_buffers.next
ffff880219277e80, bh->b_assoc_buffers.prev
ffff880221cffc88
NILFS [nilfs_segctor_do_construct]:2367 nilfs_segctor_update_segusage
NILFS [nilfs_segctor_do_construct]:2371 nilfs_segctor_prepare_write
NILFS [nilfs_segctor_do_construct]:2376 nilfs_add_checksums_on_logs
NILFS [nilfs_segctor_do_construct]:2381 nilfs_segctor_write
NILFS [nilfs_segbuf_submit_bh]:575 bh->b_count 2, bh->b_page
ffffea000709b000, page->index 0, i_ino 1033103, i_size
25165824
NILFS [nilfs_segbuf_submit_bh]:576 segbuf->sb_segnum 6785
NILFS [nilfs_segbuf_submit_bh]:577 bh->b_assoc_buffers.next
ffff880218a0d5f8, bh->b_assoc_buffers.prev
ffff880222cc7ee8
NILFS [nilfs_segbuf_submit_bio]:464 bio->bi_sector
111165440, segbuf->sb_segnum 6785, segbuf->sb_nbio 0
[----------] ditto
NILFS [nilfs_segbuf_submit_bio]:464 bio->bi_sector
111177728, segbuf->sb_segnum 6785, segbuf->sb_nbio 12
NILFS [nilfs_segctor_do_construct]:2399 nilfs_segctor_wait
NILFS [nilfs_segbuf_wait]:676 segbuf->sb_segnum 6783
NILFS [nilfs_segbuf_wait]:676 segbuf->sb_segnum 6784
NILFS [nilfs_segbuf_wait]:676 segbuf->sb_segnum 6785
NILFS [nilfs_segctor_complete_write]:2100 bh->b_count 0, bh->b_blocknr
13895680, bh->b_size
13897727, bh->b_page
0000000000001a82
BUG: unable to handle kernel paging request at
0000000000001a82
IP: [<
ffffffffa024d0f2>] nilfs_end_page_io+0x12/0xd0 [nilfs2]
Usually, for every segment we collect dirty files in list. Then, dirty
blocks are gathered for every dirty file, prepared for write and
submitted by means of nilfs_segbuf_submit_bh() call. Finally, it takes
place complete write phase after calling nilfs_end_bio_write() on the
block layer. Buffers/pages are marked as not dirty on final phase and
processed files removed from the list of dirty files.
It is possible to see that we had three prepare_write and submit_bio
phases before segbuf_wait and complete_write phase. Moreover, segments
compete between each other for dirty blocks because on every iteration
of segments processing dirty buffer_heads are added in several lists of
payload_buffers:
[SEGMENT 6784]: bh->b_assoc_buffers.next
ffff880218a0d5f8, bh->b_assoc_buffers.prev
ffff880218bcdf50
[SEGMENT 6785]: bh->b_assoc_buffers.next
ffff880218a0d5f8, bh->b_assoc_buffers.prev
ffff880222cc7ee8
The next pointer is the same but prev pointer has changed. It means
that buffer_head has next pointer from one list but prev pointer from
another. Such modification can be made several times. And, finally, it
can be resulted in various issues: (1) segctor hanging, (2) segctor
crashing, (3) file system metadata corruption.
FIX:
This patch adds:
(1) setting of BH_Async_Write flag in nilfs_segctor_prepare_write()
for every proccessed dirty block;
(2) checking of BH_Async_Write flag in
nilfs_lookup_dirty_data_buffers() and
nilfs_lookup_dirty_node_buffers();
(3) clearing of BH_Async_Write flag in nilfs_segctor_complete_write(),
nilfs_abort_logs(), nilfs_forget_buffer(), nilfs_clear_dirty_page().
Reported-by: Jerome Poulin <jeromepoulin@gmail.com>
Reported-by: Anton Eliasson <devel@antoneliasson.se>
Cc: Paul Fertser <fercerpav@gmail.com>
Cc: ARAI Shun-ichi <hermes@ceres.dti.ne.jp>
Cc: Piotr Szymaniak <szarpaj@grubelek.pl>
Cc: Juan Barry Manuel Canham <Linux@riotingpacifist.net>
Cc: Zahid Chowdhury <zahid.chowdhury@starsolutions.com>
Cc: Elmer Zhang <freeboy6716@gmail.com>
Cc: Kenneth Langga <klangga@gmail.com>
Signed-off-by: Vyacheslav Dubeyko <slava@dubeyko.com>
Acked-by: Ryusuke Konishi <konishi.ryusuke@lab.ntt.co.jp>
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>
Johan Hedberg [Fri, 13 Sep 2013 05:58:18 +0000 (08:58 +0300)]
Bluetooth: Fix rfkill functionality during the HCI setup stage
commit
bf5430360ebe4b2d0c51d91f782e649107b502eb upstream.
We need to let the setup stage complete cleanly even when the HCI device
is rfkilled. Otherwise the HCI device will stay in an undefined state
and never get notified to user space through mgmt (even when it gets
unblocked through rfkill).
This patch makes sure that hci_dev_open() can be called in the HCI_SETUP
stage, that blocking the device doesn't abort the setup stage, and that
the device gets proper powered down as soon as the setup stage completes
in case it was blocked meanwhile.
The bug that this patch fixed can be very easily reproduced using e.g.
the rfkill command line too. By running "rfkill block all" before
inserting a Bluetooth dongle the resulting HCI device goes into a state
where it is never announced over mgmt, not even when "rfkill unblock all"
is run.
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Acked-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Johan Hedberg [Fri, 13 Sep 2013 05:58:17 +0000 (08:58 +0300)]
Bluetooth: Introduce a new HCI_RFKILLED flag
commit
5e130367d43ff22836bbae380d197d600fe8ddbb upstream.
This makes it more convenient to check for rfkill (no need to check for
dev->rfkill before calling rfkill_blocked()) and also avoids potential
races if the RFKILL state needs to be checked from within the rfkill
callback.
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Acked-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Raphael Kubo da Costa [Mon, 2 Sep 2013 11:57:51 +0000 (14:57 +0300)]
Bluetooth: Add support for BCM20702A0 [0b05, 17cb]
commit
38a172bef8c93ecbfd69715fd88396988e4073fd upstream.
Yet another vendor specific ID for this chipset; this one for the ASUS
USB-BT400 Bluetooth 4.0 adapter.
T: Bus=03 Lev=02 Prnt=02 Port=01 Cnt=01 Dev#= 6 Spd=12 MxCh= 0
D: Ver= 2.00 Cls=ff(vend.) Sub=01 Prot=01 MxPS=64 #Cfgs= 1
P: Vendor=0b05 ProdID=17cb Rev=01.12
S: Manufacturer=Broadcom Corp
S: Product=BCM20702A0
S: SerialNumber=
000272C64400
C: #Ifs= 4 Cfg#= 1 Atr=a0 MxPwr=100mA
I: If#= 0 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=01 Prot=01 Driver=(none)
I: If#= 1 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=01 Prot=01 Driver=(none)
I: If#= 2 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=(none)
I: If#= 3 Alt= 0 #EPs= 0 Cls=fe(app. ) Sub=01 Prot=01 Driver=(none)
Signed-off-by: Raphael Kubo da Costa <rakuco@FreeBSD.org>
Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Peng Chen [Fri, 30 Aug 2013 09:41:40 +0000 (17:41 +0800)]
Bluetooth: Add a new PID/VID 0cf3/e005 for AR3012.
commit
0a3658cccdf5326ea508efeb1879b0e2508bb0c3 upstream.
usb device info:
T: Bus=06 Lev=01 Prnt=01 Port=01 Cnt=01 Dev#= 15 Spd=12 MxCh= 0
D: Ver= 1.10 Cls=e0(wlcon) Sub=01 Prot=01 MxPS=64 #Cfgs= 1
P: Vendor=0cf3 ProdID=e005 Rev= 0.02
C:* #Ifs= 2 Cfg#= 1 Atr=e0 MxPwr=100mA
I:* If#= 0 Alt= 0 #EPs= 3 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E: Ad=81(I) Atr=03(Int.) MxPS= 16 Ivl=1ms
E: Ad=82(I) Atr=02(Bulk) MxPS= 64 Ivl=0ms
E: Ad=02(O) Atr=02(Bulk) MxPS= 64 Ivl=0ms
I:* If#= 1 Alt= 0 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E: Ad=83(I) Atr=01(Isoc) MxPS= 0 Ivl=1ms
E: Ad=03(O) Atr=01(Isoc) MxPS= 0 Ivl=1ms
Signed-off-by: Peng Chen <pengchen@qca.qualcomm.com>
Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Andre Guedes [Wed, 31 Jul 2013 19:25:29 +0000 (16:25 -0300)]
Bluetooth: Fix encryption key size for peripheral role
commit
89cbb4da0abee2f39d75f67f9fd57f7410c8b65c upstream.
This patch fixes the connection encryption key size information when
the host is playing the peripheral role. We should set conn->enc_key_
size in hci_le_ltk_request_evt, otherwise it is left uninitialized.
Signed-off-by: Andre Guedes <andre.guedes@openbossa.org>
Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Andre Guedes [Wed, 31 Jul 2013 19:25:28 +0000 (16:25 -0300)]
Bluetooth: Fix security level for peripheral role
commit
f8776218e8546397be64ad2bc0ebf4748522d6e3 upstream.
While playing the peripheral role, the host gets a LE Long Term Key
Request Event from the controller when a connection is established
with a bonded device. The host then informs the LTK which should be
used for the connection. Once the link is encrypted, the host gets
an Encryption Change Event.
Therefore we should set conn->pending_sec_level instead of conn->
sec_level in hci_le_ltk_request_evt. This way, conn->sec_level is
properly updated in hci_encrypt_change_evt.
Moreover, since we have a LTK associated to the device, we have at
least BT_SECURITY_MEDIUM security level.
Signed-off-by: Andre Guedes <andre.guedes@openbossa.org>
Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Arend van Spriel [Wed, 25 Sep 2013 10:11:01 +0000 (12:11 +0200)]
brcmfmac: obtain platform data upon module initialization
commit
db4efbbeb457b6f9f4d8c4b090d1170d12f026e1 upstream.
The driver uses platform_driver_probe() to obtain platform data
if any. However, that function is placed in the .init section so
it must be called upon driver module initialization.
The problem was reported by Fenguang Wu resulting in a kernel
oops because the .init section was already freed.
[ 48.966342] Switched to clocksource tsc
[ 48.970002] kernel tried to execute NX-protected page - exploit attempt? (uid: 0)
[ 48.970851] BUG: unable to handle kernel paging request at
ffffffff82196446
[ 48.970957] IP: [<
ffffffff82196446>] classes_init+0x26/0x26
[ 48.970957] PGD 1e76067 PUD 1e77063 PMD f388063 PTE
8000000002196163
[ 48.970957] Oops: 0011 [#1]
[ 48.970957] CPU: 0 PID: 17 Comm: kworker/0:1 Not tainted 3.11.0-rc7-00444-gc52dd7f #23
[ 48.970957] Workqueue: events brcmf_driver_init
[ 48.970957] task:
ffff8800001d2000 ti:
ffff8800001d4000 task.ti:
ffff8800001d4000
[ 48.970957] RIP: 0010:[<
ffffffff82196446>] [<
ffffffff82196446>] classes_init+0x26/0x26
[ 48.970957] RSP: 0000:
ffff8800001d5d40 EFLAGS:
00000286
[ 48.970957] RAX:
0000000000000001 RBX:
ffffffff820c5620 RCX:
0000000000000000
[ 48.970957] RDX:
0000000000000001 RSI:
ffffffff816f7380 RDI:
ffffffff820c56c0
[ 48.970957] RBP:
ffff8800001d5d50 R08:
ffff8800001d2508 R09:
0000000000000002
[ 48.970957] R10:
0000000000000000 R11:
0001f7ce298c5620 R12:
ffff8800001c76b0
[ 48.970957] R13:
ffffffff81e91d40 R14:
0000000000000000 R15:
ffff88000e0ce300
[ 48.970957] FS:
0000000000000000(0000) GS:
ffffffff81e84000(0000) knlGS:
0000000000000000
[ 48.970957] CS: 0010 DS: 0000 ES: 0000 CR0:
000000008005003b
[ 48.970957] CR2:
ffffffff82196446 CR3:
0000000001e75000 CR4:
00000000000006b0
[ 48.970957] DR0:
0000000000000000 DR1:
0000000000000000 DR2:
0000000000000000
[ 48.970957] DR3:
0000000000000000 DR6:
0000000000000000 DR7:
0000000000000000
[ 48.970957] Stack:
[ 48.970957]
ffffffff816f7df8 ffffffff820c5620 ffff8800001d5d60 ffffffff816eeec9
[ 48.970957]
ffff8800001d5de0 ffffffff81073dc5 ffffffff81073d68 ffff8800001d5db8
[ 48.970957]
0000000000000086 ffffffff820c5620 ffffffff824f7fd0 0000000000000000
[ 48.970957] Call Trace:
[ 48.970957] [<
ffffffff816f7df8>] ? brcmf_sdio_init+0x18/0x70
[ 48.970957] [<
ffffffff816eeec9>] brcmf_driver_init+0x9/0x10
[ 48.970957] [<
ffffffff81073dc5>] process_one_work+0x1d5/0x480
[ 48.970957] [<
ffffffff81073d68>] ? process_one_work+0x178/0x480
[ 48.970957] [<
ffffffff81074188>] worker_thread+0x118/0x3a0
[ 48.970957] [<
ffffffff81074070>] ? process_one_work+0x480/0x480
[ 48.970957] [<
ffffffff8107aa17>] kthread+0xe7/0xf0
[ 48.970957] [<
ffffffff810829f7>] ? finish_task_switch.constprop.57+0x37/0xd0
[ 48.970957] [<
ffffffff8107a930>] ? __kthread_parkme+0x80/0x80
[ 48.970957] [<
ffffffff81a6923a>] ret_from_fork+0x7a/0xb0
[ 48.970957] [<
ffffffff8107a930>] ? __kthread_parkme+0x80/0x80
[ 48.970957] Code: cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc
cc cc cc cc cc cc <cc> cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc
[ 48.970957] RIP [<
ffffffff82196446>] classes_init+0x26/0x26
[ 48.970957] RSP <
ffff8800001d5d40>
[ 48.970957] CR2:
ffffffff82196446
[ 48.970957] ---[ end trace
62980817cd525f14 ]---
Reported-by: Fengguang Wu <fengguang.wu@intel.com>
Reviewed-by: Hante Meuleman <meuleman@broadcom.com>
Reviewed-by: Pieter-Paul Giesberts <pieterpg@broadcom.com>
Tested-by: Fengguang Wu <fengguang.wu@intel.com>
Signed-off-by: Arend van Spriel <arend@broadcom.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Maxim Patlasov [Fri, 13 Sep 2013 15:20:16 +0000 (19:20 +0400)]
fuse: fix fallocate vs. ftruncate race
commit
0ab08f576b9e6a6b689fc6b4e632079b978e619b upstream.
A former patch introducing FUSE_I_SIZE_UNSTABLE flag provided detailed
description of races between ftruncate and anyone who can extend i_size:
> 1. As in the previous scenario fuse_dentry_revalidate() discovered that i_size
> changed (due to our own fuse_do_setattr()) and is going to call
> truncate_pagecache() for some 'new_size' it believes valid right now. But by
> the time that particular truncate_pagecache() is called ...
> 2. fuse_do_setattr() returns (either having called truncate_pagecache() or
> not -- it doesn't matter).
> 3. The file is extended either by write(2) or ftruncate(2) or fallocate(2).
> 4. mmap-ed write makes a page in the extended region dirty.
This patch adds necessary bits to fuse_file_fallocate() to protect from that
race.
Signed-off-by: Maxim Patlasov <mpatlasov@parallels.com>
Signed-off-by: Miklos Szeredi <mszeredi@suse.cz>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Maxim Patlasov [Fri, 13 Sep 2013 15:19:54 +0000 (19:19 +0400)]
fuse: wait for writeback in fuse_file_fallocate()
commit
bde52788bdb755b9e4b75db6c434f30e32a0ca0b upstream.
The patch fixes a race between mmap-ed write and fallocate(PUNCH_HOLE):
1) An user makes a page dirty via mmap-ed write.
2) The user performs fallocate(2) with mode == PUNCH_HOLE|KEEP_SIZE
and <offset, size> covering the page.
3) Before truncate_pagecache_range call from fuse_file_fallocate,
the page goes to write-back. The page is fully processed by fuse_writepage
(including end_page_writeback on the page), but fuse_flush_writepages did
nothing because fi->writectr < 0.
4) truncate_pagecache_range is called and fuse_file_fallocate is finishing
by calling fuse_release_nowrite. The latter triggers processing queued
write-back request which will write stale data to the hole soon.
Changed in v2 (thanks to Brian for suggestion):
- Do not truncate page cache until FUSE_FALLOCATE succeeded. Otherwise,
we can end up in returning -ENOTSUPP while user data is already punched
from page cache. Use filemap_write_and_wait_range() instead.
Changed in v3 (thanks to Miklos for suggestion):
- fuse_wait_on_writeback() is prone to livelocks; use fuse_set_nowrite()
instead. So far as we need a dirty-page barrier only, fuse_sync_writes()
should be enough.
- rebased to for-linus branch of fuse.git
Signed-off-by: Maxim Patlasov <mpatlasov@parallels.com>
Signed-off-by: Miklos Szeredi <mszeredi@suse.cz>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Paul E. McKenney [Tue, 1 Oct 2013 07:11:35 +0000 (17:11 +1000)]
powerpc: Restore registers on error exit from csum_partial_copy_generic()
commit
8f21bd0090052e740944f9397e2be5ac7957ded7 upstream.
The csum_partial_copy_generic() function saves the PowerPC non-volatile
r14, r15, and r16 registers for the main checksum-and-copy loop.
Unfortunately, it fails to restore them upon error exit from this loop,
which results in silent corruption of these registers in the presumably
rare event of an access exception within that loop.
This commit therefore restores these register on error exit from the loop.
Signed-off-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
Signed-off-by: Anton Blanchard <anton@samba.org>
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Madhavan Srinivasan [Tue, 1 Oct 2013 19:04:10 +0000 (00:34 +0530)]
powerpc/sysfs: Disable writing to PURR in guest mode
commit
d1211af3049f4c9c1d8d4eb8f8098cc4f4f0d0c7 upstream.
arch/powerpc/kernel/sysfs.c exports PURR with write permission.
This may be valid for kernel in phyp mode. But writing to
the file in guest mode causes crash due to a priviledge violation
Signed-off-by: Madhavan Srinivasan <maddy@linux.vnet.ibm.com>
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Paul E. McKenney [Tue, 1 Oct 2013 06:54:05 +0000 (16:54 +1000)]
powerpc: Fix parameter clobber in csum_partial_copy_generic()
commit
d9813c3681a36774b254c0cdc9cce53c9e22c756 upstream.
The csum_partial_copy_generic() uses register r7 to adjust the remaining
bytes to process. Unfortunately, r7 also holds a parameter, namely the
address of the flag to set in case of access exceptions while reading
the source buffer. Lacking a quantum implementation of PowerPC, this
commit instead uses register r9 to do the adjusting, leaving r7's
pointer uncorrupted.
Signed-off-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
Signed-off-by: Anton Blanchard <anton@samba.org>
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Prarit Bhargava [Mon, 23 Sep 2013 13:33:36 +0000 (09:33 -0400)]
powerpc/vio: Fix modalias_show return values
commit
e82b89a6f19bae73fb064d1b3dd91fcefbb478f4 upstream.
modalias_show() should return an empty string on error, not -ENODEV.
This causes the following false and annoying error:
> find /sys/devices -name modalias -print0 | xargs -0 cat >/dev/null
cat: /sys/devices/vio/4000/modalias: No such device
cat: /sys/devices/vio/4001/modalias: No such device
cat: /sys/devices/vio/4002/modalias: No such device
cat: /sys/devices/vio/4004/modalias: No such device
cat: /sys/devices/vio/modalias: No such device
Signed-off-by: Prarit Bhargava <prarit@redhat.com>
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Michael Neuling [Thu, 26 Sep 2013 03:29:09 +0000 (13:29 +1000)]
powerpc/tm: Switch out userspace PPR and DSCR sooner
commit
e9bdc3d6143d1c4b8d8ce5231fc958268331f983 upstream.
When we do a treclaim or trecheckpoint we end up running with userspace
PPR and DSCR values. Currently we don't do anything special to avoid
running with user values which could cause a severe performance
degradation.
This patch moves the PPR and DSCR save and restore around treclaim and
trecheckpoint so that we run with user values for a much shorter period.
More care is taken with the PPR as it's impact is greater than the DSCR.
This is similar to user exceptions, where we run HTM_MEDIUM early to
ensure that we don't run with a userspace PPR values in the kernel.
Signed-off-by: Michael Neuling <mikey@neuling.org>
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Michael Ellerman [Wed, 2 Oct 2013 08:04:06 +0000 (18:04 +1000)]
powerpc/perf: Fix handling of FAB events
commit
a53b27b3abeef406de92a2bb0ceb6fb4c3fb8fc4 upstream.
Commit 4df4899 "Add power8 EBB support" included a bug in the handling
of the FAB_CRESP_MATCH and FAB_TYPE_MATCH fields.
These values are pulled out of the event code using EVENT_THR_CTL_SHIFT,
however we were then or'ing that value directly into MMCR1.
This meant we were failing to set the FAB fields correctly, and also
potentially corrupting the value for PMC4SEL. Leading to no counts for
the FAB events and incorrect counts for PMC4.
The fix is simply to shift left the FAB value correctly before or'ing it
with MMCR1.
Reported-by: Sooraj Ravindran Nair <soonair3@in.ibm.com>
Signed-off-by: Michael Ellerman <michael@ellerman.id.au>
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Nishanth Aravamudan [Tue, 1 Oct 2013 21:04:53 +0000 (14:04 -0700)]
powerpc/iommu: Use GFP_KERNEL instead of GFP_ATOMIC in iommu_init_table()
commit
1cf389df090194a0976dc867b7fffe99d9d490cb upstream.
Under heavy (DLPAR?) stress, we tripped this panic() in
arch/powerpc/kernel/iommu.c::iommu_init_table():
page = alloc_pages_node(nid, GFP_ATOMIC, get_order(sz));
if (!page)
panic("iommu_init_table: Can't allocate %ld bytes\n", sz);
Before the panic() we got a page allocation failure for an order-2
allocation. There appears to be memory free, but perhaps not in the
ATOMIC context. I looked through all the call-sites of
iommu_init_table() and didn't see any obvious reason to need an ATOMIC
allocation. Most call-sites in fact have an explicit GFP_KERNEL
allocation shortly before the call to iommu_init_table(), indicating we
are not in an atomic context. There is some indirection for some paths,
but I didn't see any locks indicating that GFP_KERNEL is inappropriate.
With this change under the same conditions, we have not been able to
reproduce the panic.
Signed-off-by: Nishanth Aravamudan <nacc@us.ibm.com>
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Dan Carpenter [Fri, 13 Sep 2013 07:53:36 +0000 (10:53 +0300)]
ASoC: ab8500-codec: info leak in anc_status_control_put()
commit
d63733aed90b432e5cc489ddfa28e342f91b4652 upstream.
If the user passes an invalid value it leads to an info leak when we
print the error message or it could oops. This is called with user
supplied data from snd_ctl_elem_write().
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Mark Brown <broonie@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Dan Carpenter [Fri, 13 Sep 2013 07:52:49 +0000 (10:52 +0300)]
ASoC: 88pm860x: array overflow in snd_soc_put_volsw_2r_st()
commit
d967967e8d1116fb38bad25e58714b5dddd03cca upstream.
This is called from snd_ctl_elem_write() with user supplied data so we
need to add some bounds checking.
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Mark Brown <broonie@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Dan Carpenter [Fri, 13 Sep 2013 07:52:14 +0000 (10:52 +0300)]
ASoC: max98095: a couple array underflows
commit
f8d7b13e14357ed19d2ca2799539600418dc3939 upstream.
The ->put() function are called from snd_ctl_elem_write() with user
supplied data. The limit checks here could underflow leading to a
crash.
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Mark Brown <broonie@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Javier Martinez Canillas [Wed, 25 Sep 2013 00:36:54 +0000 (02:36 +0200)]
gpio/omap: auto-setup a GPIO when used as an IRQ
commit
fac7fa162a19100298d5d91359960037dc5bfca9 upstream.
The OMAP GPIO controller HW requires a pin to be configured in GPIO
input mode in order to operate as an interrupt input. Since drivers
should not be aware of whether an interrupt pin is also a GPIO or not,
the HW should be fully configured/enabled as an IRQ if a driver solely
uses IRQ APIs such as request_irq(), and never calls any GPIO-related
APIs. As such, add the missing HW setup to the OMAP GPIO controller's
irq_chip driver.
Since this bypasses the GPIO subsystem we have to ensure that another
driver won't be able to request the same GPIO pin that is used as an
IRQ and set its direction as output. Requesting the GPIO and setting
its direction as input is allowed though.
This fixes smsc911x ethernet support for tobi and igep OMAP3 boards
and OMAP4 SDP SPI based ethernet that use a GPIO as an interrupt line.
Acked-by: Stephen Warren <swarren@nvidia.com>
Tested-by: George Cherian <george.cherian@ti.com>
Tested-by: Aaro Koskinen <aaro.koskinen@iki.fi>
Tested-by: Lars Poeschel <poeschel@lemonage.de>
Reviewed-by: Kevin Hilman <khilman@linaro.org>
Tested-by: Kevin Hilman <khilman@linaro.org>
Acked-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
Acked-by: Tony Lindgren <tony@atomide.com>
Signed-off-by: Javier Martinez Canillas <javier.martinez@collabora.co.uk>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Javier Martinez Canillas [Wed, 25 Sep 2013 00:36:52 +0000 (02:36 +0200)]
gpio/omap: maintain GPIO and IRQ usage separately
commit
fa365e4d729065b5e85165df3dc9699ed47489cc upstream.
The GPIO OMAP controller pins can be used as IRQ and GPIO
independently so is necessary to keep track GPIO pins and
IRQ lines usage separately to make sure that the bank will
always be enabled while being used.
Also move gpio_is_input() definition in preparation for the
next patch that setups the controller's irq_chip driver when
a caller requests an interrupt line.
Acked-by: Stephen Warren <swarren@nvidia.com>
Tested-by: George Cherian <george.cherian@ti.com>
Tested-by: Aaro Koskinen <aaro.koskinen@iki.fi>
Tested-by: Lars Poeschel <poeschel@lemonage.de>
Reviewed-by: Kevin Hilman <khilman@linaro.org>
Tested-by: Kevin Hilman <khilman@linaro.org>
Acked-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
Acked-by: Tony Lindgren <tony@atomide.com>
Signed-off-by: Javier Martinez Canillas <javier.martinez@collabora.co.uk>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Dan Aloni [Mon, 30 Sep 2013 20:45:02 +0000 (13:45 -0700)]
fs/binfmt_elf.c: prevent a coredump with a large vm_map_count from Oopsing
commit
72023656961b8c81a168a7a6762d589339d0d7ec upstream.
A high setting of max_map_count, and a process core-dumping with a large
enough vm_map_count could result in an NT_FILE note not being written,
and the kernel crashing immediately later because it has assumed
otherwise.
Reproduction of the oops-causing bug described here:
https://lkml.org/lkml/2013/8/30/50
Rge ussue originated in commit
2aa362c49c31 ("coredump: extend core dump
note section to contain file names of mapped file") from Oct 4, 2012.
This patch make that section optional in that case. fill_files_note()
should signify the error, and also let the info struct in
elf_core_dump() be zero-initialized so that we can check for the
optionally written note.
[akpm@linux-foundation.org: avoid abusing E2BIG, remove a couple of not-really-needed local variables]
[akpm@linux-foundation.org: fix sparse warning]
Signed-off-by: Dan Aloni <alonid@stratoscale.com>
Cc: Al Viro <viro@zeniv.linux.org.uk>
Cc: Denys Vlasenko <vda.linux@googlemail.com>
Reported-by: Martin MOKREJS <mmokrejs@gmail.com>
Tested-by: Martin MOKREJS <mmokrejs@gmail.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>
Gabor Juhos [Wed, 25 Sep 2013 13:32:35 +0000 (15:32 +0200)]
avr32: fix clockevents kernel warning
commit
1b0135b5e20c56b2edae29e92b91c0b12c983432 upstream.
Since commit
01426478df3a8791ff5c8b6b82d409e699cfaf38
(avr32: Use generic idle loop) the kernel throws the
following warning on avr32:
WARNING: at
900322e4 [verbose debug info unavailable]
Modules linked in:
CPU: 0 PID: 0 Comm: swapper Not tainted 3.12.0-rc2 #117
task:
901c3ecc ti:
901c0000 task.ti:
901c0000
PC is at cpu_idle_poll_ctrl+0x1c/0x38
LR is at comparator_mode+0x3e/0x40
pc : [<
900322e4>] lr : [<
90014882>] Not tainted
sp :
901c1f74 r12:
00000000 r11:
901c74a0
r10:
901d2510 r9 :
00000001 r8 :
901db4de
r7 :
901c74a0 r6 :
00000001 r5 :
00410020 r4 :
901db574
r3 :
00410024 r2 :
90206fe0 r1 :
00000000 r0 :
007f0000
Flags: qvnzc
Mode bits: hjmde....G
CPU Mode: Supervisor
Call trace:
[<
90039ede>] clockevents_set_mode+0x16/0x2e
[<
90039f00>] clockevents_shutdown+0xa/0x1e
[<
9003a078>] clockevents_exchange_device+0x58/0x70
[<
9003a78c>] tick_check_new_device+0x38/0x54
[<
9003a1a2>] clockevents_register_device+0x32/0x90
[<
900035c4>] time_init+0xa8/0x108
[<
90000520>] start_kernel+0x128/0x23c
When the 'avr32_comparator' clockevent device is registered,
the clockevent core sets the mode of that clockevent device
to CLOCK_EVT_MODE_SHUTDOWN. Due to this, the 'comparator_mode'
function calls the 'cpu_idle_poll_ctrl' to disables idle poll.
This results in the aforementioned warning because the polling
is not enabled yet.
Change the code to only disable idle poll if it is enabled by
the same function to avoid the warning.
Signed-off-by: Gabor Juhos <juhosg@openwrt.org>
Acked-by: Hans-Christian Egtvedt <egtvedt@samfundet.no>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Nicolas Dichtel [Tue, 1 Oct 2013 16:05:00 +0000 (18:05 +0200)]
ip6tnl: allow to use rtnl ops on fb tunnel
[ Upstream commit
bb8140947a247b9aa15652cc24dc555ebb0b64b0 ]
rtnl ops where introduced by
c075b13098b3 ("ip6tnl: advertise tunnel param via
rtnl"), but I forget to assign rtnl ops to fb tunnels.
Now that it is done, we must remove the explicit call to
unregister_netdevice_queue(), because the fallback tunnel is added to the queue
in ip6_tnl_destroy_tunnels() when checking rtnl_link_ops of all netdevices (this
is valid since commit
0bd8762824e7 ("ip6tnl: add x-netns support")).
Signed-off-by: Nicolas Dichtel <nicolas.dichtel@6wind.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Nicolas Dichtel [Tue, 1 Oct 2013 16:04:59 +0000 (18:04 +0200)]
sit: allow to use rtnl ops on fb tunnel
[ Upstream commit
205983c43700ac3a81e7625273a3fa83cd2759b5 ]
rtnl ops where introduced by
ba3e3f50a0e5 ("sit: advertise tunnel param via
rtnl"), but I forget to assign rtnl ops to fb tunnels.
Now that it is done, we must remove the explicit call to
unregister_netdevice_queue(), because the fallback tunnel is added to the queue
in sit_destroy_tunnels() when checking rtnl_link_ops of all netdevices (this
is valid since commit
5e6700b3bf98 ("sit: add support of x-netns")).
Signed-off-by: Nicolas Dichtel <nicolas.dichtel@6wind.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Steffen Klassert [Tue, 1 Oct 2013 09:33:59 +0000 (11:33 +0200)]
ip_tunnel: Fix a memory corruption in ip_tunnel_xmit
[ Upstream commit
3e08f4a72f689c6296d336c2aab4bddd60c93ae2 ]
We might extend the used aera of a skb beyond the total
headroom when we install the ipip header. Fix this by
calling skb_cow_head() unconditionally.
Bug was introduced with commit
c544193214
("GRE: Refactor GRE tunneling code.")
Cc: Pravin Shelar <pshelar@nicira.com>
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>
Ricardo Ribalda [Tue, 1 Oct 2013 06:17:10 +0000 (08:17 +0200)]
ll_temac: Reset dma descriptors indexes on ndo_open
[ Upstream commit
7167cf0e8cd10287b7912b9ffcccd9616f382922 ]
The dma descriptors indexes are only initialized on the probe function.
If a packet is on the buffer when temac_stop is called, the dma
descriptors indexes can be left on a incorrect state where no other
package can be sent.
So an interface could be left in an usable state after ifdow/ifup.
This patch makes sure that the descriptors indexes are in a proper
status when the device is open.
Signed-off-by: Ricardo Ribalda Delgado <ricardo.ribalda@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Salam Noureddine [Sun, 29 Sep 2013 20:41:34 +0000 (13:41 -0700)]
ipv6 mcast: use in6_dev_put in timer handlers instead of __in6_dev_put
[ Upstream commit
9260d3e1013701aa814d10c8fc6a9f92bd17d643 ]
It is possible for the timer handlers to run after the call to
ipv6_mc_down so use in6_dev_put instead of __in6_dev_put in the
handler function in order to do proper cleanup when the refcnt
reaches 0. Otherwise, the refcnt can reach zero without the
inet6_dev being destroyed and we end up leaking a reference to
the net_device and see messages like the following,
unregister_netdevice: waiting for eth0 to become free. Usage count = 1
Tested on linux-3.4.43.
Signed-off-by: Salam Noureddine <noureddine@aristanetworks.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Salam Noureddine [Sun, 29 Sep 2013 20:39:42 +0000 (13:39 -0700)]
ipv4 igmp: use in_dev_put in timer handlers instead of __in_dev_put
[ Upstream commit
e2401654dd0f5f3fb7a8d80dad9554d73d7ca394 ]
It is possible for the timer handlers to run after the call to
ip_mc_down so use in_dev_put instead of __in_dev_put in the handler
function in order to do proper cleanup when the refcnt reaches 0.
Otherwise, the refcnt can reach zero without the in_device being
destroyed and we end up leaking a reference to the net_device and
see messages like the following,
unregister_netdevice: waiting for eth0 to become free. Usage count = 1
Tested on linux-3.4.43.
Signed-off-by: Salam Noureddine <noureddine@aristanetworks.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>