18 Oct, 2013
40 commits
-
commit f5c936c0f267ec58641451cf8b8d39b4c207ee4d upstream.
As now each semaphore has its own spinlock and parallel operations are
possible, give each semaphore its own cacheline.On a i3 laptop, this gives up to 28% better performance:
#semscale 10 | grep "interleave 2"
- before:
Cpus 1, interleave 2 delay 0: 36109234 in 10 secs
Cpus 2, interleave 2 delay 0: 55276317 in 10 secs
Cpus 3, interleave 2 delay 0: 62411025 in 10 secs
Cpus 4, interleave 2 delay 0: 81963928 in 10 secs-after:
Cpus 1, interleave 2 delay 0: 35527306 in 10 secs
Cpus 2, interleave 2 delay 0: 70922909 in 10 secs <<< + 28%
Cpus 3, interleave 2 delay 0: 80518538 in 10 secs
Cpus 4, interleave 2 delay 0: 89115148 in 10 secs <<< + 8.7%i3, with 2 cores and with hyperthreading enabled. Interleave 2 in order
use first the full cores. HT partially hides the delay from cacheline
trashing, thus the improvement is "only" 8.7% if 4 threads are running.Signed-off-by: Manfred Spraul
Cc: Rik van Riel
Cc: Davidlohr Bueso
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds
Cc: Mike Galbraith
Signed-off-by: Greg Kroah-Hartman -
commit 196aa0132fc7261f34b10ae1bfb44abc1bc69b3c upstream.
Enforce that ipc_rcu_alloc returns a cacheline aligned pointer on SMP.
Rationale:
The SysV sem code tries to move the main spinlock into a seperate
cacheline (____cacheline_aligned_in_smp). This works only if
ipc_rcu_alloc returns cacheline aligned pointers. vmalloc and kmalloc
return cacheline algined pointers, the implementation of ipc_rcu_alloc
breaks that.[akpm@linux-foundation.org: coding-style fixes]
Signed-off-by: Manfred Spraul
Cc: Rik van Riel
Cc: Davidlohr Bueso
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds
Cc: Mike Galbraith
Signed-off-by: Greg Kroah-Hartman -
commit 9ad66ae65fc8d3e7e3344310fb0aa835910264fe upstream.
We can now drop the msg_lock and msg_lock_check functions along with a
bogus comment introduced previously in semctl_down.Signed-off-by: Davidlohr Bueso
Cc: Andi Kleen
Cc: Rik van Riel
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds
Cc: Mike Galbraith
Signed-off-by: Greg Kroah-Hartman -
commit 41a0d523d0f626e9da0dc01de47f1b89058033cf upstream.
do_msgrcv() is the last msg queue function that abuses the ipc lock Take
it only when needed when actually updating msq.Signed-off-by: Davidlohr Bueso
Cc: Andi Kleen
Cc: Rik van Riel
Tested-by: Sedat Dilek
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds
Cc: Mike Galbraith
Signed-off-by: Greg Kroah-Hartman -
commit 3dd1f784ed6603d7ab1043e51e6371235edf2313 upstream.
do_msgsnd() is another function that does too many things with the ipc
object lock acquired. Take it only when needed when actually updating
msq.Signed-off-by: Davidlohr Bueso
Cc: Andi Kleen
Cc: Rik van Riel
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds
Cc: Mike Galbraith
Signed-off-by: Greg Kroah-Hartman -
commit ac0ba20ea6f2201a1589d6dc26ad1a4f0f967bb8 upstream.
While the INFO cmd doesn't take the ipc lock, the STAT commands do
acquire it unnecessarily. We can do the permissions and security checks
only holding the rcu lock.This function now mimics semctl_nolock().
Signed-off-by: Davidlohr Bueso
Cc: Andi Kleen
Cc: Rik van Riel
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds
Cc: Mike Galbraith
Signed-off-by: Greg Kroah-Hartman -
commit a5001a0d9768568de5d613c3b3a5b9c7721299da upstream.
Add msq_obtain_object() and msq_obtain_object_check(), which will allow
us to get the ipc object without acquiring the lock. Just as with
semaphores, these functions are basically wrappers around
ipc_obtain_object*().Signed-off-by: Davidlohr Bueso
Cc: Andi Kleen
Cc: Rik van Riel
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds
Cc: Mike Galbraith
Signed-off-by: Greg Kroah-Hartman -
commit 2cafed30f150f7314f98717b372df8173516cae0 upstream.
Similar to semctl, when calling msgctl, the *_INFO and *_STAT commands
can be performed without acquiring the ipc object.Add a msgctl_nolock() function and move the logic of *_INFO and *_STAT
out of msgctl(). This change still takes the lock and it will be
properly lockless in the next patchSigned-off-by: Davidlohr Bueso
Cc: Andi Kleen
Cc: Rik van Riel
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds
Cc: Mike Galbraith
Signed-off-by: Greg Kroah-Hartman -
commit 15724ecb7e9bab35fc694c666ad563adba820cc3 upstream.
Instead of holding the ipc lock for the entire function, use the
ipcctl_pre_down_nolock and only acquire the lock for specific commands:
RMID and SET.Signed-off-by: Davidlohr Bueso
Cc: Andi Kleen
Cc: Rik van Riel
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds
Cc: Mike Galbraith
Signed-off-by: Greg Kroah-Hartman -
commit 7b4cc5d8411bd4e9d61d8714f53859740cf830c2 upstream.
This function currently acquires both the rw_mutex and the rcu lock on
successful lookups, leaving the callers to explicitly unlock them,
creating another two level locking situation.Make the callers (including those that still use ipcctl_pre_down())
explicitly lock and unlock the rwsem and rcu lock.Signed-off-by: Davidlohr Bueso
Cc: Andi Kleen
Cc: Rik van Riel
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds
Cc: Mike Galbraith
Signed-off-by: Greg Kroah-Hartman -
commit cf9d5d78d05bca96df7618dfc3a5ee4414dcae58 upstream.
Signed-off-by: Davidlohr Bueso
Cc: Andi Kleen
Cc: Rik van Riel
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds
Cc: Mike Galbraith
Signed-off-by: Greg Kroah-Hartman -
commit 1ca7003ab41152d673d9e359632283d05294f3d6 upstream.
Simple helpers around the (kern_ipc_perm *)->lock spinlock.
Signed-off-by: Davidlohr Bueso
Cc: Andi Kleen
Cc: Rik van Riel
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds
Cc: Mike Galbraith
Signed-off-by: Greg Kroah-Hartman -
commit dbfcd91f06f0e2d5564b2fd184e9c2a43675f9ab upstream.
This patchset continues the work that began in the sysv ipc semaphore
scaling series, seehttps://lkml.org/lkml/2013/3/20/546
Just like semaphores used to be, sysv shared memory and msg queues also
abuse the ipc lock, unnecessarily holding it for operations such as
permission and security checks.This patchset mostly deals with mqueues, and while shared mem can be
done in a very similar way, I want to get these patches out in the open
first. It also does some pending cleanups, mostly focused on the two
level locking we have in ipc code, taking care of ipc_addid() and
ipcctl_pre_down_nolock() - yes there are still functions that need to be
updated as well.This patch:
Make all callers explicitly take and release the RCU read lock.
This addresses the two level locking seen in newary(), newseg() and
newqueue(). For the last two, explicitly unlock the ipc object and the
rcu lock, instead of calling the custom shm_unlock and msg_unlock
functions. The next patch will deal with the open coded locking for
->perm.lockSigned-off-by: Davidlohr Bueso
Cc: Andi Kleen
Cc: Rik van Riel
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds
Cc: Mike Galbraith
Signed-off-by: Greg Kroah-Hartman -
commit 50b8f5aec04ebec7dbdf2adb17220b9148c99e63 upstream.
They have 4 rather than 8.
Fixes:
https://bugs.freedesktop.org/show_bug.cgi?id=63599Signed-off-by: wojciech kapuscinski
Signed-off-by: Alex Deucher
Signed-off-by: Greg Kroah-Hartman -
commit aa3e146d04b6ae37939daeebaec060562b3db559 upstream.
Wrong bit offset for SRC endian swapping.
Signed-off-by: Alex Deucher
Signed-off-by: Greg Kroah-Hartman -
commit 89cd67b326fa95872cc2b4524cd807128db6071d upstream.
The error path does this:
for (--i; i >= 0; --i) {
which is a forever loop because "i" is unsigned.
Signed-off-by: Dan Carpenter
Signed-off-by: Alex Deucher
Signed-off-by: Greg Kroah-Hartman -
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] [] dump_stack+0x54/0x8d
[ 354.803101] [] warn_slowpath_common+0x73/0x90
[ 354.803103] [] warn_slowpath_fmt+0x47/0x50
[ 354.803109] [] ? intel_ddi_connector_get_hw_state+0x5e/0x110 [i915]
[ 354.803114] [] intel_modeset_check_state+0x764/0x770 [i915]
[ 354.803117] [] intel_connector_dpms+0x3b/0x60 [i915]
[ 354.803120] [] drm_fb_helper_dpms.isra.11+0x120/0x160 [drm_kms_helper]
[ 354.803122] [] drm_fb_helper_blank+0x3e/0x80 [drm_kms_helper]
[ 354.803123] [] fb_blank+0x52/0xc0
[ 354.803125] [] fbcon_blank+0x21b/0x2d0
[ 354.803127] [] ? update_rq_clock.part.74+0x13/0x30
[ 354.803129] [] ? lock_timer_base.isra.30+0x26/0x50
[ 354.803130] [] ? internal_add_timer+0x12/0x40
[ 354.803131] [] ? mod_timer+0xf8/0x1c0
[ 354.803133] [] do_unblank_screen+0xa1/0x1c0
[ 354.803134] [] poke_blanked_console+0xc7/0xd0
[ 354.803136] [] console_callback+0x13f/0x160
[ 354.803137] [] process_one_work+0x148/0x3d0
[ 354.803138] [] worker_thread+0x119/0x3a0
[ 354.803140] [] ? manage_workers.isra.30+0x2a0/0x2a0
[ 354.803141] [] kthread+0xbb/0xc0
[ 354.803142] [] ? kthread_create_on_node+0x120/0x120
[ 354.803144] [] ret_from_fork+0x7c/0xb0
[ 354.803145] [] ? kthread_create_on_node+0x120/0x120This regression goes back to the big modeset rework and the conversion
to the new dpms helpers which started with:commit 5ab432ef4997ce32c9406721b37ef6e97e57dae1
Author: Daniel Vetter
Date: Sat Jun 30 08:59:56 2012 +0200drm/i915/hdmi: convert to encoder->disable/enable
Fixes: igt/kms_flip/dpms-off-confusion
Reported-and-tested-by: Wakko Warner
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
[danvet: Add regression citation, mention the igt testcase this fixes
and slap a cc: stable on the patch.]
Signed-off-by: Daniel Vetter
Signed-off-by: Greg Kroah-Hartman -
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
Cc: Colin Cross
Signed-off-by: Greg Kroah-Hartman -
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
Signed-off-by: Takashi Iwai
Signed-off-by: Greg Kroah-Hartman -
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
Reported-by: Oleg Nesterov
Reported-by: Peter Zijlstra
Suggested-by: Jakub Jelinek
Reviewed-by: Richard Henderson
Cc: Linus Torvalds
Cc: Andrew Morton
Link: http://lkml.kernel.org/r/20131015062351.GA4666@gmail.com
Signed-off-by: Ingo Molnar
Signed-off-by: Greg Kroah-Hartman -
commit 8612ed0d97abcf1c016d34755b7cf2060de71963 upstream.
Calling the WDIOC_GETSTATUS & WDIOC_GETBOOTSTATUS and twice will cause a
interruptible deadlock.Signed-off-by: Dan Carpenter
Reviewed-by: Guenter Roeck
Signed-off-by: Wim Van Sebroeck
Cc: Jonghwan Choi
Signed-off-by: Greg Kroah-Hartman -
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
Signed-off-by: Vineet Gupta
Signed-off-by: Greg Kroah-Hartman -
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
Signed-off-by: Vineet Gupta
Signed-off-by: Greg Kroah-Hartman -
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, retryIn 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 again9. 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
Signed-off-by: Greg Kroah-Hartman -
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
Signed-off-by: Vineet Gupta
Signed-off-by: Greg Kroah-Hartman -
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
Signed-off-by: Vineet Gupta
Signed-off-by: Greg Kroah-Hartman -
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
Signed-off-by: Vineet Gupta
Signed-off-by: Greg Kroah-Hartman -
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
Signed-off-by: Noam Camus
Signed-off-by: Vineet Gupta
Signed-off-by: Linus Torvalds
Signed-off-by: Greg Kroah-Hartman -
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
Cc: Guenter Roeck
Signed-off-by: Greg Kroah-Hartman -
commit 1d0bbf428924f94867542d49d436cf254b9dbd06 upstream.
Signed-off-by: Russell King
Signed-off-by: Greg Kroah-Hartman
Cc: Colin Cross
Signed-off-by: Greg Kroah-Hartman -
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
Signed-off-by: John David Anglin
Signed-off-by: Helge Deller
Signed-off-by: Greg Kroah-Hartman -
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
Acked-by: Alexander Graf
Signed-off-by: Paolo Bonzini
Signed-off-by: Greg Kroah-Hartman -
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
Signed-off-by: "Theodore Ts'o"
Reviewed-by: Eric Sandeen
Signed-off-by: Greg Kroah-Hartman -
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 failbtrfs subvol create test1
btrfs subvol create test2
mv test1 test2.Thanks to Chris Murphy for catching this,
Reported-by: Chris Murphy
Signed-off-by: Josef Bacik
Signed-off-by: Chris Mason
Signed-off-by: Greg Kroah-Hartman -
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
Signed-off-by: Henrik Rydberg
Signed-off-by: Guenter Roeck
Signed-off-by: Greg Kroah-Hartman -
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
Signed-off-by: Taras Kondratiuk
Signed-off-by: Wolfram Sang
Signed-off-by: Greg Kroah-Hartman -
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: ольга крыжановская
Acked-by: Al Viro
Signed-off-by: Linus Torvalds
Signed-off-by: Greg Kroah-Hartman -
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"
Signed-off-by: Greg Kroah-Hartman -
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
Signed-off-by: Takashi Iwai
Signed-off-by: Greg Kroah-Hartman -
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
Signed-off-by: Greg Kroah-Hartman
