When you failed to allocate memroy for ctrlcmd_data, previous code didn't
unlock the mutex. So after that, msm_cam_server counldn't acquire the mutex.
You should release the mutex when you failed to allocate the memory for
ctrlcmd_data.
Change-Id: I6e933ad241514971651ec40f54fd32957ac0aada
Possible to invoke the camera focus from userspace before configuring
the actuator or after power down. It causes a kernel crash due to access
the null pointer in that case. This avoids to access the uninitialized table.
Change-Id: Ib38f0f6a2af7d1caa19e0d3f632f1597e8c3571c
Possible buffer overflow when the crash log is stored
in crash_dump_log->buffer. You should check the buffer size before
storing the crash log.
Change-Id: Icfe8010d9825f2db1165de8dd3683cd7b53749b3
dev_set_drvdata() sets the device specific driver data at
dev->p->driver_data. However, dev is destroyed and has it's
context memory freed in device_destroy(). As a result, calling
dev_set_drvdata() causes a fault when accessing dev->p.
Change-Id: I4b1e6d17db52d0e31caf9b52e59979ff9cbb0c12
Signed-off-by: Deva Ramasubramanian <dramasub@codeaurora.org>
HSIC HW can operate at SVS digital voltage when it is active.
Currently HSIC is voting for 120Mhz SFAB and 64Mhz DFAB clock
frequencies. Clock frequencies are directly proportional to SVS
voltage. If DFAB is running at 64Mhz or SFAB is running at 120Mhz
or higher SVS is not possible even though HSIC votes for it. Hence
do not vote for SFAB clock frequency and only vote for 32Mhz for
DFAB in order to allow SVS to happen. Voting for SVS voltage reduces
current consumption by 3mA in HSDPA network.
Change-Id: Ic76f0c8346e3387b1647f41f77eb06babbd9a422
Signed-off-by: Iliyan Malchev <malchev@google.com>
HSIC generates interrupt at 4ms interval. If idle power collapse
is enabled when HSIC is active, krait keeps on going into idle
power collapse requesting RPM to handle the sleep set requirement.
If HSIC interrupt comes after 4ms interval, krait comes out of idle
power collapse and it again ask RPM to handle this request therefore
keeps RPM busy handling requests due to frequent idle power collapse.
This has a power impact. Hence only allow standalone power collapse
when HSIC is active to avoid RPM involvement in assisting kraits to
power collapse. Vote for idle power collapse when HSIC goes to low
power mode.
Change-Id: I12d877b1489f26fea32b6e2026aaffea6b5858a9
Signed-off-by: Iliyan Malchev <malchev@google.com>
HSIC controller should send SOF with in 3 msec after completing
the resume signal. If processor is in idle sleep state, the timer
interrupt generated by HSIC controller to indicate resume completion
gets delayed. If the interrupt handler is not run with in 3msec
after resume, the resume sequence is repeated. Disallow processor
idle sleep to avoid multiple resume cycles.
CRs-Fixed: 397154
Change-Id: Ie2c6f60b3a36f46f8246e2e0f41a64675df632a5
Signed-off-by: Iliyan Malchev <malchev@google.com>
Kernel should not use the memory of userspace directly. In msm actuator,
there is wrong use case of using the memory of userspace
in msm_actuator_move_focus. It might cause a kernel crash.
use copy_from_user to avoid that issue.
Change-Id: Icb0852a2358e708741f10c64b0ac429db08b536e
Signed-off-by: Iliyan Malchev <malchev@google.com>
The device might fall in abnormal state in slimport with power on.
The slimport couldn't detect the cable correctly at that time.
We make a sure that the slimport is in power off before turning it on
to avoid that issue.
Change-Id: I119f17e3767221582d1d4330fdfa913552b84503
In the past the iface_stat_fmt would only show global bytes/packets
for the skb-based numbers.
For stall detection in userspace, distinguishing tcp vs other protocols
makes it easier.
Now we report
ifname total_skb_rx_bytes total_skb_rx_packets total_skb_tx_bytes
total_skb_tx_packets {rx,tx}_{tcp,udp,ohter}_{bytes,packets}
Bug: 6818637
Signed-off-by: JP Abgrall <jpa@google.com>
qtaguid limits what can be done with /ctrl and /stats based on group
membership.
This changes removes AID_NET_BW_STATS and AID_NET_BW_ACCT, and picks
up the groups from the gid of the matching proc entry files.
Signed-off-by: JP Abgrall <jpa@google.com>
Change-Id: I42e477adde78a12ed5eb58fbc0b277cdaadb6f94
When the driver is removed from the kernel, you should nullify the
anx7808_client to avoid wrong detecting the slimport cable.
Because it is used in slimport_is_connected().
Change-Id: Ia9cc580e0463e30008493e628a1d3ea9cb07377c
Possible to use the wake_lock in the interrupt handler before initializing
the wake lock. So you should initialize the wake_lock before using it.
Change-Id: I73c1de326403e24c5ba3dae9654cf6bc06f8ea93
enable_irq_wake is a wrapper function of irq_set_irq_wake(). So you don't need
to use irq_set_irq_wake().
Change-Id: I68ceeda1468b449ba32de63430e45dad5ebfeb15
There are wrong error handling in probe(). For example, if you failed to
request the irq, you don't need to free the irq at that time. You just need
to free the irq after you requested the irq successfully.
Change-Id: I353e0cf79b71af760ba4d478fb39ab888e633d0a
- refactor the driver
- Add a VGA Dongle into RX_VGA (00 22 b9 73 69 76 61)
- recovery when backuped dongle type != current dongle type
Change-Id: I3e4dbaac6085308b1997b6b871a5a52fd91c6972
In ext4_nonda_switch(), if the file system is getting full we used to
call writeback_inodes_sb_if_idle(). The problem is that we can be
holding i_mutex already, and this causes a potential deadlock when
writeback_inodes_sb_if_idle() when it tries to take s_umount. (See
lockdep output below).
As it turns out we don't need need to hold s_umount; the fact that we
are in the middle of the write(2) system call will keep the superblock
pinned. Unfortunately writeback_inodes_sb() checks to make sure
s_umount is taken, and the VFS uses a different mechanism for making
sure the file system doesn't get unmounted out from under us. The
simplest way of dealing with this is to just simply grab s_umount
using a trylock, and skip kicking the writeback flusher thread in the
very unlikely case that we can't take a read lock on s_umount without
blocking.
Also, we now check the cirteria for kicking the writeback thread
before we decide to whether to fall back to non-delayed writeback, so
if there are any outstanding delayed allocation writes, we try to get
them resolved as soon as possible.
[ INFO: possible circular locking dependency detected ]
3.6.0-rc1-00042-gce894ca #367 Not tainted
-------------------------------------------------------
dd/8298 is trying to acquire lock:
(&type->s_umount_key#18){++++..}, at: [<c02277d4>] writeback_inodes_sb_if_idle+0x28/0x46
but task is already holding lock:
(&sb->s_type->i_mutex_key#8){+.+...}, at: [<c01ddcce>] generic_file_aio_write+0x5f/0xd3
which lock already depends on the new lock.
2 locks held by dd/8298:
#0: (sb_writers#2){.+.+.+}, at: [<c01ddcc5>] generic_file_aio_write+0x56/0xd3
#1: (&sb->s_type->i_mutex_key#8){+.+...}, at: [<c01ddcce>] generic_file_aio_write+0x5f/0xd3
stack backtrace:
Pid: 8298, comm: dd Not tainted 3.6.0-rc1-00042-gce894ca #367
Call Trace:
[<c015b79c>] ? console_unlock+0x345/0x372
[<c06d62a1>] print_circular_bug+0x190/0x19d
[<c019906c>] __lock_acquire+0x86d/0xb6c
[<c01999db>] ? mark_held_locks+0x5c/0x7b
[<c0199724>] lock_acquire+0x66/0xb9
[<c02277d4>] ? writeback_inodes_sb_if_idle+0x28/0x46
[<c06db935>] down_read+0x28/0x58
[<c02277d4>] ? writeback_inodes_sb_if_idle+0x28/0x46
[<c02277d4>] writeback_inodes_sb_if_idle+0x28/0x46
[<c026f3b2>] ext4_nonda_switch+0xe1/0xf4
[<c0271ece>] ext4_da_write_begin+0x27/0x193
[<c01dcdb0>] generic_file_buffered_write+0xc8/0x1bb
[<c01ddc47>] __generic_file_aio_write+0x1dd/0x205
[<c01ddce7>] generic_file_aio_write+0x78/0xd3
[<c026d336>] ext4_file_write+0x480/0x4a6
[<c0198c1d>] ? __lock_acquire+0x41e/0xb6c
[<c0180944>] ? sched_clock_cpu+0x11a/0x13e
[<c01967e9>] ? trace_hardirqs_off+0xb/0xd
[<c018099f>] ? local_clock+0x37/0x4e
[<c0209f2c>] do_sync_write+0x67/0x9d
[<c0209ec5>] ? wait_on_retry_sync_kiocb+0x44/0x44
[<c020a7b9>] vfs_write+0x7b/0xe6
[<c020a9a6>] sys_write+0x3b/0x64
[<c06dd4bd>] syscall_call+0x7/0xb
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
Cc: stable@vger.kernel.org
Commit 080399aaaf ("block: don't mark buffers beyond end of disk as
mapped") exposed a bug in __getblk_slow that causes mount to hang as it
loops infinitely waiting for a buffer that lies beyond the end of the
disk to become uptodate.
The problem was initially reported by Torsten Hilbrich here:
https://lkml.org/lkml/2012/6/18/54
and also reported independently here:
http://www.sysresccd.org/forums/viewtopic.php?f=13&t=4511
and then Richard W.M. Jones and Marcos Mello noted a few separate
bugzillas also associated with the same issue. This patch has been
confirmed to fix:
https://bugzilla.redhat.com/show_bug.cgi?id=835019
The main problem is here, in __getblk_slow:
for (;;) {
struct buffer_head * bh;
int ret;
bh = __find_get_block(bdev, block, size);
if (bh)
return bh;
ret = grow_buffers(bdev, block, size);
if (ret < 0)
return NULL;
if (ret == 0)
free_more_memory();
}
__find_get_block does not find the block, since it will not be marked as
mapped, and so grow_buffers is called to fill in the buffers for the
associated page. I believe the for (;;) loop is there primarily to
retry in the case of memory pressure keeping grow_buffers from
succeeding. However, we also continue to loop for other cases, like the
block lying beond the end of the disk. So, the fix I came up with is to
only loop when grow_buffers fails due to memory allocation issues
(return value of 0).
The attached patch was tested by myself, Torsten, and Rich, and was
found to resolve the problem in call cases.
Signed-off-by: Jeff Moyer <jmoyer@redhat.com>
Reported-and-Tested-by: Torsten Hilbrich <torsten.hilbrich@secunet.com>
Tested-by: Richard W.M. Jones <rjones@redhat.com>
Reviewed-by: Josh Boyer <jwboyer@redhat.com>
Cc: Stable <stable@vger.kernel.org> # 3.0+
[ Jens is on vacation, taking this directly - Linus ]
--
Stable Notes: this patch requires backport to 3.0, 3.2 and 3.3.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Commit a76d7bd96d ("ARM: 7467/1: mutex: use generic xchg-based
implementation for ARMv6+") removed the barrier-less, ARM-specific
mutex implementation in favour of the generic xchg-based code.
Since then, a bug was uncovered in the xchg code when running on SMP
platforms, due to interactions between the locking paths and the
MUTEX_SPIN_ON_OWNER code. This was fixed in 0bce9c46bf ("mutex: place
lock in contended state after fastpath_lock failure"), however, the
atomic_dec-based mutex algorithm is now marginally more efficient for
ARM (~0.5% improvement in hackbench scores on dual A15).
This patch moves ARMv6+ platforms to the atomic_dec-based mutex code.
Acked-by: Nicolas Pitre <nico@linaro.org>
Signed-off-by: Will Deacon <will.deacon@arm.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
ARM recently moved to asm-generic/mutex-xchg.h for its mutex
implementation after the previous implementation was found to be missing
some crucial memory barriers. However, this has revealed some problems
running hackbench on SMP platforms due to the way in which the
MUTEX_SPIN_ON_OWNER code operates.
The symptoms are that a bunch of hackbench tasks are left waiting on an
unlocked mutex and therefore never get woken up to claim it. This boils
down to the following sequence of events:
Task A Task B Task C Lock value
0 1
1 lock() 0
2 lock() 0
3 spin(A) 0
4 unlock() 1
5 lock() 0
6 cmpxchg(1,0) 0
7 contended() -1
8 lock() 0
9 spin(C) 0
10 unlock() 1
11 cmpxchg(1,0) 0
12 unlock() 1
At this point, the lock is unlocked, but Task B is in an uninterruptible
sleep with nobody to wake it up.
This patch fixes the problem by ensuring we put the lock into the
contended state if we fail to acquire it on the fastpath, ensuring that
any blocked waiters are woken up when the mutex is released.
Signed-off-by: Will Deacon <will.deacon@arm.com>
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: Chris Mason <chris.mason@fusionio.com>
Cc: Ingo Molnar <mingo@elte.hu>
Cc: <stable@vger.kernel.org>
Reviewed-by: Nicolas Pitre <nico@linaro.org>
Signed-off-by: Peter Zijlstra <a.p.zijlstra@chello.nl>
Link: http://lkml.kernel.org/n/tip-6e9lrw2avczr0617fzl5vqb8@git.kernel.org
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
The open-coded mutex implementation for ARMv6+ cores suffers from a
severe lack of barriers, so in the uncontended case we don't actually
protect any accesses performed during the critical section.
Furthermore, the code is largely a duplication of the ARMv6+ atomic_dec
code but optimised to remove a branch instruction, as the mutex fastpath
was previously inlined. Now that this is executed out-of-line, we can
reuse the atomic access code for the locking (in fact, we use the xchg
code as this produces shorter critical sections).
This patch uses the generic xchg based implementation for mutexes on
ARMv6+, which introduces barriers to the lock/unlock operations and also
has the benefit of removing a fair amount of inline assembly code.
Cc: <stable@vger.kernel.org>
Acked-by: Arnd Bergmann <arnd@arndb.de>
Acked-by: Nicolas Pitre <nico@linaro.org>
Reported-by: Shan Kang <kangshan0910@gmail.com>
Signed-off-by: Will Deacon <will.deacon@arm.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
If lock refcount is negative, lock will be always failed. To fix this
issue, do not set the lock refcount as negative value.
Change-Id: Ic89f393b60a0ff15313e91566a5055f620752452
Synopsys USB3 Controller (DWC3) has a restriction where size
of OUT requests (TRB) queued to the controller must be aligned
with the endpoint's max packet size.
Since, request buffer is already allocated with the size of
ADB_BULK_BUFFER_SIZE, hence, request this much data from the
controller.
Change-Id: Ibba1a627c9e34b92ddcb44ee2260a004a2b78dfc
Signed-off-by: Ido Shayevitz <idos@codeaurora.org>
Signed-off-by: Manu Gautam <mgautam@codeaurora.org>
It is possible to use the wakelock before initializing wakelock.
In this case, wakelock error occurs. To avoid this issue, early initialize
the wakelock in init()
Change-Id: I8fb5450005efa6dbcee6c27b5a3fa551a0adb4dc
If you use the parameter 'maxcpus=n', restrict boot time cpus to n.
To initialize the ETM on cpu, the cpus should be online. So if you restrict
boot time cpus, you can not enable the ETM on cpu which is rectriced(not
enabled). Skip the initialization of the ETM.
Change-Id: Idccf537ff4dce0ae5d1b60ecc1631180ad323fb8
When being completely charged in the offmode charging and pulling out TA
from sleep condition, I gave 1 sec. delay until entering sleep condition again,
in order to prevent the phenomenon that a device doesn't turn off.
We need sometime for an userspace application to handle the usb disconnection
events. There is no effect of power consumption.
Change-Id: I0851cc2b47c3780fd68d3e8965fd0d6f5b7e8312
In off-mode charging, hsic host driver never release wake_lock.
Due to this, system cannot enter the suspend during off-mode
charging. This patch disable the hsic host driver and mdm
driver in off-mode charging to reduce power consumption.
Change-Id: I8580af1d5a9d754982b198c9bd47a98e4b69c725
The interrupts added to the ringbuffer on PTFLUSH and TLBUPDATE
were causing a major increase in the number of interrupts from the GPU.
This was leading to increase in power and loss of performance. Add a check
to turn off IOMMU clocks when going to SLEEP.
Change-Id: I41617dd3b7b3f7d9622523f2a1407b912dbd989e
Signed-off-by: Shubhraprakash Das <sadas@codeaurora.org>
Signed-off-by: Jeff Boody <jboody@codeaurora.org>
Remove ts_notifier_list from the driver since it is not being
used and is causing extra work to be done in the interrupt
handlers for A2XX, A3XX and Z180.
Change-Id: I5512e36f1e807f3a3e62aeac54cfd3075d4cf7a4
Signed-off-by: Carter Cooper <ccooper@codeaurora.org>
Signed-off-by: Jeff Boody <jboody@codeaurora.org>
This reverts commit de86e6482897db0006151ae9154f181e75f5ab2c.
Commit 7c8527ce ("PM: Prevent runtime suspend during system resume")
fixes the general issue of a parent device being prematurely
runtime suspended before a child device is resumed. It does so
by moving the pm_runtime_put_sync() call from the device_resume()
stage to device_complete(), which happens to act on the devices
in reverse (children before parent) order.
Thus when usb_resume() is called by device_resume(), we know its
parent will be runtime PM enabled and its usage counter is still
non-zero. This obviates the need to do an additional
pm_runtime_get_sync() before calling usb_resume_both() as the
device and its interfaces now have the opportunity to increment
the parent's power.child_count if necessary without fear of
having a runtime suspended parent.
CRs-fixed: 396041
Change-Id: I793ddfbb9bd88634f45f0c1e570a5d616248e3a8
Signed-off-by: Jack Pham <jackp@codeaurora.org>
git://codeaurora.org/external/wlan/prima.git
8cfd26d wlan: Release 3.2.1.13
148c518 Update csrRoamInitGlobals() to support static linking
fff59a1 Send EDCA Parameters After Reassoc
c7f1b8f Populate Correct Scan Mode for Roam
c9990e6 Fix driver hang in csrRoamRoamingStateDisassocRspProcessor
d1ef85b Remove call to palStopTimer for preauth
a31968f Insure that LFR BG scanning is not performed for any non-Infra association
96a9106 Only flush non-P2P results from scan cache prior to LFR scan
ac37d9d De-register lookup UP indication during pre-auth
def1bff Improve convergence of LFR roam candidate scan algorithm
3774f3b Dump neighbor state info when scan is not allowed
524cf61 wlan: Release 3.2.1.12
70e619c Conditionally invoke driver restart API
556271d Notify the Kernel suspend to WCNSS
8aef3d0 Update restart driver API to support statically linked WLAN driver
f9f6457 wlan: Release 3.2.1.11i
d5b0e74 Post proper response to SME when reassoc is rejected
e6c5a60 wlan: Release 3.2.1.11i
bd2182f Post proper response to SME when reassoc is rejected
Signed-off-by: Iliyan Malchev <malchev@google.com>
commit 9ab4233dd0 upstream.
Otherwise the code races with munmap (causing a use-after-free
of the vma) or with close (causing a use-after-free of the struct
file).
The bug was introduced by commit 90ed52ebe4 ("[PATCH] holepunch: fix
mmap_sem i_mutex deadlock")
Cc: Hugh Dickins <hugh@veritas.com>
Cc: Miklos Szeredi <mszeredi@suse.cz>
Cc: Badari Pulavarty <pbadari@us.ibm.com>
Cc: Nick Piggin <npiggin@suse.de>
Signed-off-by: Andy Lutomirski <luto@amacapital.net>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
[bwh: Backported to 3.2:
- Adjust context
- madvise_remove() calls vmtruncate_range(), not do_fallocate()]
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
In the normal case, when the device is turned off, lcd off function doesn't
work. However, we still need to turn off the panel and DSV convertor. This
patch adds an LCD turn-off function and calls it on device shut down.
Change-Id: I5526f0f08567190050527121d7e0890c05607a68
Signed-off-by: Iliyan Malchev <malchev@google.com>
commit 8a5bdaf3 never allow the runtime suspend if prepare is failed.
The complete phase is invoked when calling __device_suspend.
It allows the runtime suspend again. But if prepare is failed,
__device_suspend won't be called and the complete phase won't also
called. Thus this runtime suspend will be blocked forever.
If prepare is failed, you should allow the runtime suspend again.
Change-Id: I57c7c04609299244a042f2524e1c65dbbdd91ae3
mako does not need loadable kernel modules; disabling support for them reduces
the attack surface on the kernel
Signed-off-by: Iliyan Malchev <malchev@google.com>
In the case which is below,
1. acquire slab for cpu partial list
2. free object to it by remote cpu
3. page->freelist = t
then memory leak is occurred.
Change acquire_slab() not to zap freelist when it works for cpu partial list.
I think it is a sufficient solution for fixing a memory leak.
Below is output of 'slabinfo -r kmalloc-256'
when './perf stat -r 30 hackbench 50 process 4000 > /dev/null' is done.
***Vanilla***
Sizes (bytes) Slabs Debug Memory
------------------------------------------------------------------------
Object : 256 Total : 468 Sanity Checks : Off Total: 3833856
SlabObj: 256 Full : 111 Redzoning : Off Used : 2004992
SlabSiz: 8192 Partial: 302 Poisoning : Off Loss : 1828864
Loss : 0 CpuSlab: 55 Tracking : Off Lalig: 0
Align : 8 Objects: 32 Tracing : Off Lpadd: 0
***Patched***
Sizes (bytes) Slabs Debug Memory
------------------------------------------------------------------------
Object : 256 Total : 300 Sanity Checks : Off Total: 2457600
SlabObj: 256 Full : 204 Redzoning : Off Used : 2348800
SlabSiz: 8192 Partial: 33 Poisoning : Off Loss : 108800
Loss : 0 CpuSlab: 63 Tracking : Off Lalig: 0
Align : 8 Objects: 32 Tracing : Off Lpadd: 0
Total and loss number is the impact of this patch.
Cc: <stable@vger.kernel.org>
Acked-by: Christoph Lameter <cl@linux.com>
Signed-off-by: Joonsoo Kim <js1304@gmail.com>
Signed-off-by: Pekka Enberg <penberg@kernel.org>
Memory allocated by kstrdup should be freed,
when kmalloc(kmem_size, GFP_KERNEL) is failed.
Acked-by: Christoph Lameter <cl@linux.com>
Acked-by: David Rientjes <rientjes@google.com>
Signed-off-by: Joonsoo Kim <js1304@gmail.com>
Signed-off-by: Pekka Enberg <penberg@kernel.org>
