Now that we're murder-synchronous, this code path will never be
called (and if it does, it doesn't tell us anything useful other
than we killed a task that was already being killed by somebody
else but hadn't gotten its' signal yet)
Signed-off-by: San Mehat <san@google.com>
As it turns out, the CONFIG_PROFILING interfaces leak a
task struct if the notifier chain returns NOTIFY_OK.. doh.
This patch reworks lowmemkiller to use the new generic task
free notifier chain.
Signed-off-by: San Mehat <san@google.com>
This patch adds a notifier which can be used by subsystems that may
be interested in when a task has completely died and is about to
have it's last resource freed.
The Android lowmemory killer uses this to determine when a task
it has killed has finally given up its goods.
Signed-off-by: San Mehat <san@google.com>
binder_deferred_release was not unmapping the page from the buffer
before freeing it, causing memory corruption. This only happened
when page(s) had not been freed by binder_update_page_range, which
properly unmaps the pages.
This only happens on architectures with VIPT aliasing.
To reproduce, create a program which opens, mmaps, munmaps, then closes
the binder very quickly. This should leave a page allocated when the
binder is released. When binder_deferrred_release is called on the
close, the page will remain mapped to the address in the linear
proc->buffer. Later, we may map the same physical page to a different
virtual address that has different coloring, and this may cause
aliasing to occur.
PAGE_POISONING will greatly increase your chances of noticing any
problems.
Change-Id: I6941bf212881b8bf846bdfda43d3609c7ae4892e
Signed-off-by: Christopher Lais <chris+android@zenthought.org>
This patch optimizes lowmemkiller to not do any work when it has an outstanding
kill-request. This greatly reduces the pressure on the task_list lock
(improving interactivity), as well as improving the vmscan performance
when under heavy memory pressure (by up to 20x in tests).
Note: For this enhancement to work, you need CONFIG_PROFILING
Signed-off-by: San Mehat <san@google.com>
We can't be holding the mmap_sem while calling flush_cache_user_range
because the flush can fault. If we fault on a user address, the
page fault handler will try to take mmap_sem again. Since both places
acquire the read lock, most of the time it succeeds. However, if another
thread tries to acquire the write lock on the mmap_sem (e.g. mmap) in
between the call to flush_cache_user_range and the fault, the down_read
in do_page_fault will deadlock.
Also, since we really can't be holding the mmap_sem while calling
flush_cache_user_range AND vma is actually unused by the flush itself,
get rid of vma as an argument.
Change-Id: If55409bde41ad1060fa4fe7cbd4ac530d4d9a106
Signed-off-by: Dima Zavin <dima@android.com>
As part of formating the mass storage device, Host sends the INQUIRY
scsi command. As per the standard, the command length for this
command should be 6 bytes, whereas the Vista host sends 12 bytes.
When the command length of the command is not equal to the standard
length, the device sends a phase error as part of the status phase.
When the host receives a phase error, it re-enumerates, hence the
error.
If the command is INQUIRY, and the command length is 12 bytes,
treating this as a good command and not sending the phase error
to the host fixes this issue.
Signed-off-by: Velempati Chiranjeevi <c_cvelem@qualcomm.com>
Signed-off-by: Mike Lockwood <lockwood@android.com>
Under certain circumstances, a process can take awhile to
handle a sig-kill (especially if it's in a scheduler group with
a very low share ratio). When this occurs, lowmemkiller returns
to vmscan indicating the process memory has been freed - even
though the process is still waiting to die. Since the memory
hasn't actually freed, lowmemkiller is called again shortly after,
and picks the same process to die; regardless of the fact that
it has already been 'scheduled' to die and the memory has already
been reported to vmscan as having been freed.
Solution is to check fatal_signal_pending() on the selected
task, and if it's already pending destruction return; indicating
to vmscan that no resources were freed on this pass.
Signed-off-by: San Mehat <san@google.com>
Some drivers flush the global workqueue when closed. This would deadlock if
the last reference to the file was released from the binder.
Change-Id: Ifdabc0b383fecb20836d1bbb9786c632402a14e1
Signed-off-by: Arve Hjønnevåg <arve@android.com>
In initial design, walk_page_range() was designed just for walking page
table and it didn't require mmap_sem. Now, find_vma() etc.. are used
in walk_page_range() and we need mmap_sem around it.
This patch adds mmap_sem around walk_page_range().
Because /proc/<pid>/pagemap's callback routine use put_user(), we have
to get rid of it to do sane fix.
Changelog: 2010/Apr/2
- fixed start_vaddr and end overflow
Changelog: 2010/Apr/1
- fixed start_vaddr calculation
- removed unnecessary cast.
- removed unnecessary change in smaps.
- use GFP_TEMPORARY instead of GFP_KERNEL
Signed-off-by: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
Cc: Matt Mackall <mpm@selenic.com>
Cc: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
Cc: Brian Swetland <swetland@google.com>
Cc: Dave Hansen <haveblue@us.ibm.com>
Cc: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: San Mehat <san@google.com>
[ Fixed kmalloc failure return code as per Matt ]
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
The timed output device never previously checked the return value of sscanf,
resulting in an uninitialized int being passed to enable() if input value
was invalid.
Signed-off-by: Mike Lockwood <lockwood@android.com>
Pulling in some code from file_storage.c, we now handle interface changes
in do_set_config(), which is now not called until any pending requests have
been successfully completed or cancelled.
This fixes a race condition that resulted in usb_ep_free_request() being called
while the request is still busy.
Signed-off-by: Mike Lockwood <lockwood@android.com>
This avoids the S305 panic during incoming connection.
S305 sends PSM 25 L2CAP connection request before the L2CAP info response.
When we receive that info response we crash on null pointer here.
Bug: 2127637
Change-Id: Ib637516251f46fa9a9c87ac015dc2f27df5a27fd
Signed-off-by: Nick Pelly <npelly@google.com>
The old code did not allways disable interrupts when called from thread
context, but tried to lock the same spinlock from interrupt context.
This was merged from a change to drivers/usb/function/mass_storage.c
in the android-msm-2.6.29 branch.
Signed-off-by: Arve Hjønnevåg <arve@android.com>
Signed-off-by: Mike Lockwood <lockwood@android.com>
