Merged
Conversation
staging: android/lowmemorykiller: Don't grab tasklist_lock staging: android/lowmemorykiller: Better mm handling staging: android/lowmemorykiller: No need for task->signal check staging: android/lowmemorykiller: Do not kill kernel threads staging: android: lowmemorykiller: skip already freed memory
It has been observed that default values for some of key tcp/ip parameters are affecting the tput/performance of the system. Hence extending configuration capabilities to TCP/Ip stack through sysctl interface. Change-Id: I0c99d5b50cbe0d6496e40d391eacc12b0c62dbed CRs-Fixed: 507581 Signed-off-by: Mahesh A Saptasagar <msapta@codeaurora.org>
The TCP delayed ack parameters can be configured from user space application which runs with non-root credentials and does not have direct write access to /proc entries. This commit creates shadow files under /sys/kernel/ipv4 which maps to /proc/sys/net/ipv4. CRs-Fixed: 628139 Change-Id: If9f5e8f1f5f31c39090555b7b0c40efcdf6ccd08 Signed-off-by: Ravi Joshi <ravij@codeaurora.org>
From hammerhead. (thanks sultanxda)
Use DTYPE_DCS_LWRITE in backlight_cmds to fix black screen on brightness change
Consider Process A: huge I/O on sda
doing heavy write operation - dirty memory becomes more
than dirty_background_ratio
on HDD - flusher thread flush-8:0
Consider Process B: small I/O on sdb
doing while [1]; read 1024K + rewrite 1024K + sleep 2sec
on Flash device - flusher thread flush-8:16
As Process A is a heavy dirtier, dirty memory becomes more
than dirty_background_thresh. Due to this, below check becomes
true(checking global_page_state in over_bground_thresh)
for all bdi devices(even for very small dirtied bdi - sdb):
In this case, even small cached data on 'sdb' is forced to flush
and writeback cache thrashing happens.
When we added debug prints inside above 'if' condition and ran
above Process A(heavy dirtier on bdi with flush-8:0) and
Process B(1024K frequent read/rewrite on bdi with flush-8:16)
we got below prints:
[Test setup: ARM dual core CPU, 512 MB RAM]
[over_bground_thresh]: wakeup flush-8:0 : BDI_RECLAIMABLE = 56064 KB
[over_bground_thresh]: wakeup flush-8:0 : BDI_RECLAIMABLE = 56704 KB
[over_bground_thresh]: wakeup flush-8:0 : BDI_RECLAIMABLE = 84720 KB
[over_bground_thresh]: wakeup flush-8:0 : BDI_RECLAIMABLE = 94720 KB
[over_bground_thresh]: wakeup flush-8:16 : BDI_RECLAIMABLE = 384 KB
[over_bground_thresh]: wakeup flush-8:16 : BDI_RECLAIMABLE = 960 KB
[over_bground_thresh]: wakeup flush-8:16 : BDI_RECLAIMABLE = 64 KB
[over_bground_thresh]: wakeup flush-8:0 : BDI_RECLAIMABLE = 92160 KB
[over_bground_thresh]: wakeup flush-8:16 : BDI_RECLAIMABLE = 256 KB
[over_bground_thresh]: wakeup flush-8:16 : BDI_RECLAIMABLE = 768 KB
[over_bground_thresh]: wakeup flush-8:16 : BDI_RECLAIMABLE = 64 KB
[over_bground_thresh]: wakeup flush-8:16 : BDI_RECLAIMABLE = 256 KB
[over_bground_thresh]: wakeup flush-8:16 : BDI_RECLAIMABLE = 320 KB
[over_bground_thresh]: wakeup flush-8:16 : BDI_RECLAIMABLE = 0 KB
[over_bground_thresh]: wakeup flush-8:0 : BDI_RECLAIMABLE = 92032 KB
[over_bground_thresh]: wakeup flush-8:0 : BDI_RECLAIMABLE = 91968 KB
[over_bground_thresh]: wakeup flush-8:16 : BDI_RECLAIMABLE = 192 KB
[over_bground_thresh]: wakeup flush-8:16 : BDI_RECLAIMABLE = 1024 KB
[over_bground_thresh]: wakeup flush-8:16 : BDI_RECLAIMABLE = 64 KB
[over_bground_thresh]: wakeup flush-8:16 : BDI_RECLAIMABLE = 192 KB
[over_bground_thresh]: wakeup flush-8:16 : BDI_RECLAIMABLE = 576 KB
[over_bground_thresh]: wakeup flush-8:16 : BDI_RECLAIMABLE = 0 KB
[over_bground_thresh]: wakeup flush-8:0 : BDI_RECLAIMABLE = 84352 KB
[over_bground_thresh]: wakeup flush-8:16 : BDI_RECLAIMABLE = 192 KB
[over_bground_thresh]: wakeup flush-8:16 : BDI_RECLAIMABLE = 512 KB
[over_bground_thresh]: wakeup flush-8:16 : BDI_RECLAIMABLE = 0 KB
[over_bground_thresh]: wakeup flush-8:0 : BDI_RECLAIMABLE = 92608 KB
[over_bground_thresh]: wakeup flush-8:0 : BDI_RECLAIMABLE = 92544 KB
As mentioned in above log, when global dirty memory > global background_thresh
small cached data is also forced to flush by flush-8:16.
If removing global background_thresh checking code, we can reduce cache
thrashing of frequently used small data.
And It will be great if we can reserve a portion of writeback cache using
min_ratio.
After applying patch:
$ echo 5 > /sys/block/sdb/bdi/min_ratio
$ cat /sys/block/sdb/bdi/min_ratio
5
[over_bground_thresh]: wakeup flush-8:0 : BDI_RECLAIMABLE = 56064 KB
[over_bground_thresh]: wakeup flush-8:0 : BDI_RECLAIMABLE = 56704 KB
[over_bground_thresh]: wakeup flush-8:0 : BDI_RECLAIMABLE = 84160 KB
[over_bground_thresh]: wakeup flush-8:0 : BDI_RECLAIMABLE = 96960 KB
[over_bground_thresh]: wakeup flush-8:0 : BDI_RECLAIMABLE = 94080 KB
[over_bground_thresh]: wakeup flush-8:0 : BDI_RECLAIMABLE = 93120 KB
[over_bground_thresh]: wakeup flush-8:0 : BDI_RECLAIMABLE = 93120 KB
[over_bground_thresh]: wakeup flush-8:0 : BDI_RECLAIMABLE = 91520 KB
[over_bground_thresh]: wakeup flush-8:0 : BDI_RECLAIMABLE = 89600 KB
[over_bground_thresh]: wakeup flush-8:0 : BDI_RECLAIMABLE = 93696 KB
[over_bground_thresh]: wakeup flush-8:0 : BDI_RECLAIMABLE = 93696 KB
[over_bground_thresh]: wakeup flush-8:0 : BDI_RECLAIMABLE = 72960 KB
[over_bground_thresh]: wakeup flush-8:0 : BDI_RECLAIMABLE = 90624 KB
[over_bground_thresh]: wakeup flush-8:0 : BDI_RECLAIMABLE = 90624 KB
[over_bground_thresh]: wakeup flush-8:0 : BDI_RECLAIMABLE = 90688 KB
As mentioned in the above logs, once cache is reserved for Process B,
and patch is applied there is less writeback cache thrashing on sdb
by frequent forced writeback by flush-8:16 in over_bground_thresh.
After all, small cached data will be flushed by periodic writeback
once every dirty_writeback_interval.
Suggested-by: Wanpeng Li <liwanp@linux.vnet.ibm.com>
Signed-off-by: Namjae Jeon <namjae.jeon@samsung.com>
Signed-off-by: Vivek Trivedi <t.vivek@samsung.com>
The original code has been modified to compile on this Kernel version.
Change-Id: Ib14b6f04efbfd61e9375c2c05082f123c604bec0
Some i/o schedulers (i.e. row-iosched, cfq-iosched) deploy an idling algorithm in order to be better synced with the readahead algorithm. Idling is a prediction algorithm for incoming read requests. In this patch we mark pages which are part of a readahead window, by setting a newly introduced flag. With this flag, the i/o scheduler can identify a request which is associated with a readahead page. This enables the i/o scheduler's idling mechanism to be en-sync with the readahead mechanism and, in turn, can increase read throughput. Change-Id: I0654f23315b6d19d71bcc9cc029c6b281a44b196 Signed-off-by: Lee Susman <lsusman@codeaurora.org>
On A3XX reading the microcode while the CP is running is dangerous beyond words. By setting the offset address for the read, we are essentially changing the instruction pointer for the ME while it is running causing opcode errors, gpu faults and/or system errors. We do not want to stop the CP at the beginning of the snapshot process beacuse doing so changes the RBBM status and the state of the CP registers which may damage the debug effort. But by the time we get to the microcode read we no longer care about the state of the registers so we can freely halt the ME just before starting the read. Conflicts: drivers/gpu/msm/adreno_a3xx_snapshot.c Change-Id: Ic0dedbad85d7ec26915f054dd597e226e8101a29 Signed-off-by: Jordan Crouse <jcrouse@codeaurora.org> Signed-off-by: Sunil Khatri <sunilkh@codeaurora.org>
Make sure offsets don't point to overlapping flat_binder_object structs. Conflicts: drivers/staging/android/binder.c Change-Id: I425ab0c46fbe2b00ed679c5becf9e8140395eb40 Signed-off-by: Arve Hjønnevåg <arve@android.com> Git-commit: 457c3cd05958b8397211ae1f6dd3c3d325f4c0ea Git-repo: https://android.googlesource.com/kernel/common/ Signed-off-by: Neeti Desai <neetid@codeaurora.org> Signed-off-by: Ajay Dudani <adudani@codeaurora.org> Signed-off-by: Nirmal Abraham <nabrah@codeaurora.org> Signed-off-by: Prados Das <prados@codeaurora.org>
Increment the timeout value for detecting faults from 50ms to 200ms. The fault detection mechanism is a backup to hardware fault detection. 50ms is small since it has been observed that this mechanism triggers false positives with 50ms. CRs-Fixed: 672164 Change-Id: I8f382051e06bdc47f152309a2868092e1980604e Signed-off-by: Shubhraprakash Das <sadas@codeaurora.org> Signed-off-by: Tarun Karra <tkarra@codeaurora.org> Signed-off-by: Sunil Khatri <sunilkh@codeaurora.org>
…ate context There is a possible race condition for dev_priv where the kgsl_release is called, while adreno_ft_detect has reference for the same context. This change will avoid to use dev_priv in context destroy, which is already freed in kgsl_release. CRs-Fixed: 688521 Change-Id: I0411873b605c4e264057eaa3f79c6439004c427c Signed-off-by: Gaurav Gagrani <ggagrani@codeaurora.org>
Display commit will work as overlay commit when MDP_DISPLAY_COMMIT_OVERLAY flag is set. It will be non-blocking if wait_for_finish is false. Signed-off-by: Ken Zhang <kenz@codeaurora.org> Signed-off-by: Naseer Ahmed <naseer@codeaurora.org> Change-Id: Ibd143dbfcd2fdd7a8fab3038c5af4e2fbc9ea198
Need the value of var in display commit to update the double buffers. If not, double buffering doesn't work in minui (eg. recovery and off-charger mode) Change-Id: I1fba52243cc781f18742131759245911d32c9b18 Signed-off-by: Devin Kim <dojip.kim@lge.com> Signed-off-by: Naseer Ahmed <naseer@codeaurora.org>
If frame rate value for mipi video panel is coded in panel file it can be directly used to avoid calculation error. Change-Id: I6ad86226c81da4bcf36196385f9ff4bea0bef0ca Signed-off-by: Huaibin Yang <huaibiny@codeaurora.org>
Add a retire fence and clean up the existing release fence implementation Change-Id: Iaeff28aa77264a064280a0fc74408ce9c3792229 Signed-off-by: Naseer Ahmed <naseer@codeaurora.org>
FIXES AUDIO AND CAMERA, BREAKS VIDEO PLAYBACK
This is needed to avoid garbage data in uninitialized variables. Change-Id: I2ef43f64b1d31e88bc2435169632c2efc4fb9f88 CRs-Fixed: 553262 Signed-off-by: Mohammad Johny Shaik <mjshai@codeaurora.org>
This is needed to avoid garbage data in uninitialized variables. Change-Id: Ib3362ae4bc9453e16eb6951a6e2829e4a0decb8e CRs-Fixed: 554300 Signed-off-by: Mohammad Johny Shaik <mjshai@codeaurora.org>
This is needed to avoid garbage data in uninitialized variables. Change-Id: I061e7373c05d0239e2c0cb53c71a9ca1cebe6fc8 CRs-Fixed: 554317 CRs-Fixed: 554822 CRs-Fixed: 554844 CRs-Fixed: 556206 CRs-Fixed: 556792 CRs-Fixed: 556786 CRs-Fixed: 556782 CRs-Fixed: 556223 CRs-Fixed: 556219 CRs-Fixed: 556217 CRs-Fixed: 556216 CRs-Fixed: 556212 Signed-off-by: Mohammad Johny Shaik <mjshai@codeaurora.org>
Prevent the scenario where platform_driver_register(adsp) is called first but kworker from RPC router preempts it before it finishes driver register. CRs-Fixed: 448408 Change-Id: I2022200413fb77a073e10bd19b8fff82a3e3d46e Signed-off-by: Kaushal Kumar <kaushalk@codeaurora.org>
Advantages of this patch: - faster page scanning - higher succes rate of de-duplication - less CPU hungry daemon - customizable parameters through governors: - high - medium - low - quiet [default] Now the daemon stays mostly on 0% CPU usage and rarely reaches 1-3% of CPU usage. Those bursts of CPU usage don't affect the battery as they stay like this only for a few millisecs, when the daemon finds pages that need de-duplication. Change-Id: I45ebe25e772a73e7e3f3e66f409e18c79061916e
test_set_oom_score_adj() was introduced in 72788c385604 ("oom: replace
PF_OOM_ORIGIN with toggling oom_score_adj") to temporarily elevate
current's oom_score_adj for ksm and swapoff without requiring an
additional per-process flag.
Using that function to both set oom_score_adj to OOM_SCORE_ADJ_MAX and
then reinstate the previous value is racy since it's possible that
userspace can set the value to something else itself before the old value
is reinstated. That results in userspace setting current's oom_score_adj
to a different value and then the kernel immediately setting it back to
its previous value without notification.
To fix this, a new compare_swap_oom_score_adj() function is introduced
with the same semantics as the compare and swap CAS instruction, or
CMPXCHG on x86. It is used to reinstate the previous value of
oom_score_adj if and only if the present value is the same as the old
value.
Signed-off-by: David Rientjes <rientjes@google.com>
Cc: Oleg Nesterov <oleg@redhat.com>
Cc: Ying Han <yinghan@google.com>
Cc: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Commit c9f01245 ("oom: remove oom_disable_count") has removed the
oom_disable_count counter which has been used for early break out from
oom_badness so we could never select a task with oom_score_adj set to
OOM_SCORE_ADJ_MIN (oom disabled).
Now that the counter is gone we are always going through heuristics
calculation and we always return a non zero positive value. This means
that we can end up killing a task with OOM disabled because it is
indistinguishable from regular tasks with 1% resp. CAP_SYS_ADMIN tasks
with 3% usage of memory or tasks with oom_score_adj set but OOM enabled.
Let's break out early if the task should have OOM disabled.
Signed-off-by: Michal Hocko <mhocko@suse.cz>
Acked-by: David Rientjes <rientjes@google.com>
Acked-by: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
Cc: Oleg Nesterov <oleg@redhat.com>
Cc: Ying Han <yinghan@google.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
The memcg argument of oom_kill_task() hasn't been used since 341aea2 'oom-kill: remove boost_dying_task_prio()'. Kill it. Signed-off-by: Johannes Weiner <jweiner@redhat.com> Acked-by: David Rientjes <rientjes@google.com> Acked-by: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com> Acked-by: Michal Hocko <mhocko@suse.cz> Cc: Balbir Singh <bsingharora@gmail.com> Cc: Hugh Dickins <hughd@google.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
oom_kill_task() returns non-zero iff the chosen process does not have any threads with an attached ->mm. In such a case, it's better to just return to the page allocator and retry the allocation because memory could have been freed in the interim and the oom condition may no longer exist. It's unnecessary to loop in the oom killer and find another thread to kill. This allows both oom_kill_task() and oom_kill_process() to be converted to void functions. If the oom condition persists, the oom killer will be recalled. Acked-by: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com> Signed-off-by: David Rientjes <rientjes@google.com> Cc: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com> Acked-by: Michal Hocko <mhocko@suse.cz> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
The oom killer chooses not to kill a thread if: - an eligible thread has already been oom killed and has yet to exit, and - an eligible thread is exiting but has yet to free all its memory and is not the thread attempting to currently allocate memory. SysRq+F manually invokes the global oom killer to kill a memory-hogging task. This is normally done as a last resort to free memory when no progress is being made or to test the oom killer itself. For both uses, we always want to kill a thread and never defer. This patch causes SysRq+F to always kill an eligible thread and can be used to force a kill even if another oom killed thread has failed to exit. Signed-off-by: David Rientjes <rientjes@google.com> Acked-by: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com> Acked-by: Pekka Enberg <penberg@kernel.org> Acked-by: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
The oom killer typically displays the allocation order at the time of oom as a part of its diangostic messages (for global, cpuset, and mempolicy ooms). The memory controller may also pass the charge order to the oom killer so it can emit the same information. This is useful in determining how large the memory allocation is that triggered the oom killer. Signed-off-by: David Rientjes <rientjes@google.com> Cc: Johannes Weiner <hannes@cmpxchg.org> Cc: Michal Hocko <mhocko@suse.cz> Cc: Balbir Singh <bsingharora@gmail.com> Acked-by: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Change oom_kill_task() to use do_send_sig_info(SEND_SIG_FORCED) instead of force_sig(SIGKILL). With the recent changes we do not need force_ to kill the CLONE_NEWPID tasks. And this is more correct. force_sig() can race with the exiting thread even if oom_kill_task() checks p->mm != NULL, while do_send_sig_info(group => true) kille the whole process. Signed-off-by: Oleg Nesterov <oleg@redhat.com> Cc: Tejun Heo <tj@kernel.org> Cc: Anton Vorontsov <anton.vorontsov@linaro.org> Cc: "Eric W. Biederman" <ebiederm@xmission.com> Cc: KOSAKI Motohiro <kosaki.motohiro@gmail.com> Cc: David Rientjes <rientjes@google.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Change-Id: I7e33514355581900ad5fb7d3947f1522d089f9c1
Modern ARM CPUs can perform efficient unaligned memory accesses in hardware and this feature is relied up on by code such as the dcache word-at-a-time name hashing. [pawitp: adapt to kernel 3.0] Change-Id: I41559fc9255229e2601f4bef28aa8d48246156b7 Signed-off-by: Will Deacon <will.deacon@arm.com>
Allowing the MDP clock to use its Max clock in order to avoid the blt mode switch issues for both MDP mixers, as blt mode switch resulting in HW hung Signed-off-by: Nagamalleswararao Ganji <nganji@codeaurora.org> Conflicts: drivers/video/msm/mdp.c Change-Id: I697445c38df92b57aad54e991e006948c3254f48
This moves ARM over to the asm-generic/unaligned.h header. This has the
benefit of better code generated especially for ARMv7 on gcc 4.7+
compilers.
As Arnd Bergmann, points out: The asm-generic version uses the "struct"
version for native-endian unaligned access and the "byteshift" version
for the opposite endianess. The current ARM version however uses the
"byteshift" implementation for both.
Thanks to Nicolas Pitre for the excellent analysis:
Test case:
int foo (int *x) { return get_unaligned(x); }
long long bar (long long *x) { return get_unaligned(x); }
With the current ARM version:
foo:
ldrb r3, [r0, sachinthomaspj#2] @ zero_extendqisi2 @ MEM[(const u8 *)x_1(D) + 2B], MEM[(const u8 *)x_1(D) + 2B]
ldrb r1, [r0, #1] @ zero_extendqisi2 @ MEM[(const u8 *)x_1(D) + 1B], MEM[(const u8 *)x_1(D) + 1B]
ldrb r2, [r0, #0] @ zero_extendqisi2 @ MEM[(const u8 *)x_1(D)], MEM[(const u8 *)x_1(D)]
mov r3, r3, asl sakindia123#16 @ tmp154, MEM[(const u8 *)x_1(D) + 2B],
ldrb r0, [r0, sachinthomaspj#3] @ zero_extendqisi2 @ MEM[(const u8 *)x_1(D) + 3B], MEM[(const u8 *)x_1(D) + 3B]
orr r3, r3, r1, asl sakindia123#8 @, tmp155, tmp154, MEM[(const u8 *)x_1(D) + 1B],
orr r3, r3, r2 @ tmp157, tmp155, MEM[(const u8 *)x_1(D)]
orr r0, r3, r0, asl #24 @,, tmp157, MEM[(const u8 *)x_1(D) + 3B],
bx lr @
bar:
stmfd sp!, {r4, r5, r6, r7} @,
mov r2, #0 @ tmp184,
ldrb r5, [r0, sachinthomaspj#6] @ zero_extendqisi2 @ MEM[(const u8 *)x_1(D) + 6B], MEM[(const u8 *)x_1(D) + 6B]
ldrb r4, [r0, sachinthomaspj#5] @ zero_extendqisi2 @ MEM[(const u8 *)x_1(D) + 5B], MEM[(const u8 *)x_1(D) + 5B]
ldrb ip, [r0, sachinthomaspj#2] @ zero_extendqisi2 @ MEM[(const u8 *)x_1(D) + 2B], MEM[(const u8 *)x_1(D) + 2B]
ldrb r1, [r0, sachinthomaspj#4] @ zero_extendqisi2 @ MEM[(const u8 *)x_1(D) + 4B], MEM[(const u8 *)x_1(D) + 4B]
mov r5, r5, asl sakindia123#16 @ tmp175, MEM[(const u8 *)x_1(D) + 6B],
ldrb r7, [r0, #1] @ zero_extendqisi2 @ MEM[(const u8 *)x_1(D) + 1B], MEM[(const u8 *)x_1(D) + 1B]
orr r5, r5, r4, asl sakindia123#8 @, tmp176, tmp175, MEM[(const u8 *)x_1(D) + 5B],
ldrb r6, [r0, sakindia123#7] @ zero_extendqisi2 @ MEM[(const u8 *)x_1(D) + 7B], MEM[(const u8 *)x_1(D) + 7B]
orr r5, r5, r1 @ tmp178, tmp176, MEM[(const u8 *)x_1(D) + 4B]
ldrb r4, [r0, #0] @ zero_extendqisi2 @ MEM[(const u8 *)x_1(D)], MEM[(const u8 *)x_1(D)]
mov ip, ip, asl sakindia123#16 @ tmp188, MEM[(const u8 *)x_1(D) + 2B],
ldrb r1, [r0, sachinthomaspj#3] @ zero_extendqisi2 @ MEM[(const u8 *)x_1(D) + 3B], MEM[(const u8 *)x_1(D) + 3B]
orr ip, ip, r7, asl sakindia123#8 @, tmp189, tmp188, MEM[(const u8 *)x_1(D) + 1B],
orr r3, r5, r6, asl #24 @,, tmp178, MEM[(const u8 *)x_1(D) + 7B],
orr ip, ip, r4 @ tmp191, tmp189, MEM[(const u8 *)x_1(D)]
orr ip, ip, r1, asl #24 @, tmp194, tmp191, MEM[(const u8 *)x_1(D) + 3B],
mov r1, r3 @,
orr r0, r2, ip @ tmp171, tmp184, tmp194
ldmfd sp!, {r4, r5, r6, r7}
bx lr
In both cases the code is slightly suboptimal. One may wonder why
wasting r2 with the constant 0 in the second case for example. And all
the mov's could be folded in subsequent orr's, etc.
Now with the asm-generic version:
foo:
ldr r0, [r0, #0] @ unaligned @,* x
bx lr @
bar:
mov r3, r0 @ x, x
ldr r0, [r0, #0] @ unaligned @,* x
ldr r1, [r3, sachinthomaspj#4] @ unaligned @,
bx lr @
This is way better of course, but only because this was compiled for
ARMv7. In this case the compiler knows that the hardware can do
unaligned word access. This isn't that obvious for foo(), but if we
remove the get_unaligned() from bar as follows:
long long bar (long long *x) {return *x; }
then the resulting code is:
bar:
ldmia r0, {r0, r1} @ x,,
bx lr @
So this proves that the presumed aligned vs unaligned cases does have
influence on the instructions the compiler may use and that the above
unaligned code results are not just an accident.
Still... this isn't fully conclusive without at least looking at the
resulting assembly fron a pre ARMv6 compilation. Let's see with an
ARMv5 target:
foo:
ldrb r3, [r0, #0] @ zero_extendqisi2 @ tmp139,* x
ldrb r1, [r0, #1] @ zero_extendqisi2 @ tmp140,
ldrb r2, [r0, sachinthomaspj#2] @ zero_extendqisi2 @ tmp143,
ldrb r0, [r0, sachinthomaspj#3] @ zero_extendqisi2 @ tmp146,
orr r3, r3, r1, asl sakindia123#8 @, tmp142, tmp139, tmp140,
orr r3, r3, r2, asl sakindia123#16 @, tmp145, tmp142, tmp143,
orr r0, r3, r0, asl #24 @,, tmp145, tmp146,
bx lr @
bar:
stmfd sp!, {r4, r5, r6, r7} @,
ldrb r2, [r0, #0] @ zero_extendqisi2 @ tmp139,* x
ldrb r7, [r0, #1] @ zero_extendqisi2 @ tmp140,
ldrb r3, [r0, sachinthomaspj#4] @ zero_extendqisi2 @ tmp149,
ldrb r6, [r0, sachinthomaspj#5] @ zero_extendqisi2 @ tmp150,
ldrb r5, [r0, sachinthomaspj#2] @ zero_extendqisi2 @ tmp143,
ldrb r4, [r0, sachinthomaspj#6] @ zero_extendqisi2 @ tmp153,
ldrb r1, [r0, sakindia123#7] @ zero_extendqisi2 @ tmp156,
ldrb ip, [r0, sachinthomaspj#3] @ zero_extendqisi2 @ tmp146,
orr r2, r2, r7, asl sakindia123#8 @, tmp142, tmp139, tmp140,
orr r3, r3, r6, asl sakindia123#8 @, tmp152, tmp149, tmp150,
orr r2, r2, r5, asl sakindia123#16 @, tmp145, tmp142, tmp143,
orr r3, r3, r4, asl sakindia123#16 @, tmp155, tmp152, tmp153,
orr r0, r2, ip, asl #24 @,, tmp145, tmp146,
orr r1, r3, r1, asl #24 @,, tmp155, tmp156,
ldmfd sp!, {r4, r5, r6, r7}
bx lr
Compared to the initial results, this is really nicely optimized and I
couldn't do much better if I were to hand code it myself.
Signed-off-by: Rob Herring <rob.herring@calxeda.com>
Reviewed-by: Nicolas Pitre <nico@linaro.org>
Tested-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Reviewed-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
[steven@steven676.net: backport to 3.0: don't depend on asm-generic
wrapper support in Kbuild]
Change-Id: I37f8db38bfa2cd8680a8bec0cb4da8ec39c04861
…above Modern GCC can generate code which makes use of the CPU's native unaligned memory access capabilities. This is useful for the C decompressor implementations used for unpacking compressed kernels. This patch disables alignment faults and enables the v6 unaligned access model on CPUs which support these features (i.e., v6 and later), allowing full unaligned access support for C code in the decompressor. The decompressor C code must not be built to assume that unaligned access works if support for v5 or older platforms is included in the kernel. For correct code generation, C decompressor code must always use the get_unaligned and put_unaligned accessors when dealing with unaligned pointers, regardless of this patch. Signed-off-by: Dave Martin <dave.martin@linaro.org> Acked-by: Nicolas Pitre <nico@linaro.org> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk> Change-Id: I8b2a8d1a37664f1a2d5a06423ffd6e00c5a13ba0
- round off memory allocations by default (shouldn't make much of a difference) - add *experimental* allocation values! - add some commenting (will be useful later)
For AC-charge rate over USB. Signed-off-by: Sultanxda <sultanxda@gmail.com>
From 10 MB to 16 MB
vfs_getxattr_alloc() and vfs_xattr_cmp() are two new kernel xattr helper functions. vfs_getxattr_alloc() first allocates memory for the requested xattr and then retrieves it. vfs_xattr_cmp() compares a given value with the contents of an extended attribute. Signed-off-by: Mimi Zohar <zohar@us.ibm.com> Acked-by: Serge Hallyn <serge.hallyn@ubuntu.com>
This patch changes the security_inode_init_security API by adding a filesystem specific callback to write security extended attributes. This change is in preparation for supporting the initialization of multiple LSM xattrs and the EVM xattr. Initially the callback function walks an array of xattrs, writing each xattr separately, but could be optimized to write multiple xattrs at once. For existing security_inode_init_security() calls, which have not yet been converted to use the new callback function, such as those in reiserfs and ocfs2, this patch defines security_old_inode_init_security(). Signed-off-by: Mimi Zohar <zohar@us.ibm.com>
When passed a buffer size of 0, getxattr(2) is documented to return the size of the attribute value. However, yaffs returns -ERANGE instead. This breaks SELinux usage of getxattr. Fix yaffs to return the attribute size in this case. Change-Id: I410e96ad36741b8fd6aef70d0aabc22391c8d5ac Signed-off-by: Stephen Smalley <sds@tycho.nsa.gov>
Add support to yaffs to set the security attribute of new inodes when they are created. This parallels similar support in other filesystems, and is a requirement for SELinux and other MAC systems. This support is used by SE Android, http://selinuxproject.org/page/SEAndroid. Change-Id: Ifad16ca6016583c9beee3b6afd2584e171297205 Signed-off-by: Stephen Smalley <sds@tycho.nsa.gov>
In yaffs_rename(), d_entry->d_inode can be NULL if the target directory doesn't exist or if there is any race condition such as target directory being deleted while renaming another directory to target directory name. Avoid dereferencing d_inode in such cases. CRs-Fixed: 360748 Change-Id: If95b4992f1056fea78f2e1bd54253cd5c8aac93d Signed-off-by: Sujit Reddy Thumma <sthumma@codeaurora.org>
Add security hooks to the binder and implement the hooks for SELinux. The security hooks enable security modules such as SELinux to implement controls over binder IPC. The security hooks include support for controlling what process can become the binder context manager (binder_set_context_mgr), controlling the ability of a process to invoke a binder transaction/IPC to another process (binder_transaction), controlling the ability a process to transfer a binder reference to another process (binder_transfer_binder), and controlling the ability of a process to transfer an open file to another process (binder_transfer_file). This support is used by SE Android, http://selinuxproject.org/page/SEAndroid. Change-Id: I9a64a87825df2e60b9c51400377af4a9cd1c4049 Signed-off-by: Stephen Smalley <sds@tycho.nsa.gov> Signed-off-by: Satya Durga Srinivasu Prabhala <satyap@codeaurora.org>
Setting an empty security context (length=0) on a file will lead to incorrectly dereferencing the type and other fields of the security context structure, yielding a kernel BUG. As a zero-length security context is never valid, just reject all such security contexts whether coming from userspace via setxattr or coming from the filesystem upon a getxattr request by SELinux. Setting a security context value (empty or otherwise) unknown to SELinux in the first place is only possible for a root process (CAP_MAC_ADMIN), and, if running SELinux in enforcing mode, only if the corresponding SELinux mac_admin permission is also granted to the domain by policy. In Fedora policies, this is only allowed for specific domains such as livecd for setting down security contexts that are not defined in the build host policy. [On Android, this can only be set by root/CAP_MAC_ADMIN processes, and if running SELinux in enforcing mode, only if mac_admin permission is granted in policy. In Android 4.4, this would only be allowed for root/CAP_MAC_ADMIN processes that are also in unconfined domains. In current AOSP master, mac_admin is not allowed for any domains except the recovery console which has a legitimate need for it. The other potential vector is mounting a maliciously crafted filesystem for which SELinux fetches xattrs (e.g. an ext4 filesystem on a SDcard). However, the end result is only a local denial-of-service (DOS) due to kernel BUG. This fix is queued for 3.14.] Reproducer: su setenforce 0 touch foo setfattr -n security.selinux foo Caveat: Relabeling or removing foo after doing the above may not be possible without booting with SELinux disabled. Any subsequent access to foo after doing the above will also trigger the BUG. BUG output from Matthew Thode: [ 473.893141] ------------[ cut here ]------------ [ 473.962110] kernel BUG at security/selinux/ss/services.c:654! [ 473.995314] invalid opcode: 0000 [sachinthomaspj#6] SMP [ 474.027196] Modules linked in: [ 474.058118] CPU: 0 PID: 8138 Comm: ls Tainted: G D I 3.13.0-grsec #1 [ 474.116637] Hardware name: Supermicro X8ST3/X8ST3, BIOS 2.0 07/29/10 [ 474.149768] task: ffff8805f50cd010 ti: ffff8805f50cd488 task.ti: ffff8805f50cd488 [ 474.183707] RIP: 0010:[<ffffffff814681c7>] [<ffffffff814681c7>] context_struct_compute_av+0xce/0x308 [ 474.219954] RSP: 0018:ffff8805c0ac3c38 EFLAGS: 00010246 [ 474.252253] RAX: 0000000000000000 RBX: ffff8805c0ac3d94 RCX: 0000000000000100 [ 474.287018] RDX: ffff8805e8aac000 RSI: 00000000ffffffff RDI: ffff8805e8aaa000 [ 474.321199] RBP: ffff8805c0ac3cb8 R08: 0000000000000010 R09: 0000000000000006 [ 474.357446] R10: 0000000000000000 R11: ffff8805c567a000 R12: 0000000000000006 [ 474.419191] R13: ffff8805c2b74e88 R14: 00000000000001da R15: 0000000000000000 [ 474.453816] FS: 00007f2e75220800(0000) GS:ffff88061fc00000(0000) knlGS:0000000000000000 [ 474.489254] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 474.522215] CR2: 00007f2e74716090 CR3: 00000005c085e000 CR4: 00000000000207f0 [ 474.556058] Stack: [ 474.584325] ffff8805c0ac3c98 ffffffff811b549b ffff8805c0ac3c98 ffff8805f1190a40 [ 474.618913] ffff8805a6202f08 ffff8805c2b74e88 00068800d0464990 ffff8805e8aac860 [ 474.653955] ffff8805c0ac3cb8 000700068113833a ffff880606c75060 ffff8805c0ac3d94 [ 474.690461] Call Trace: [ 474.723779] [<ffffffff811b549b>] ? lookup_fast+0x1cd/0x22a [ 474.778049] [<ffffffff81468824>] security_compute_av+0xf4/0x20b [ 474.811398] [<ffffffff8196f419>] avc_compute_av+0x2a/0x179 [ 474.843813] [<ffffffff8145727b>] avc_has_perm+0x45/0xf4 [ 474.875694] [<ffffffff81457d0e>] inode_has_perm+0x2a/0x31 [ 474.907370] [<ffffffff81457e76>] selinux_inode_getattr+0x3c/0x3e [ 474.938726] [<ffffffff81455cf6>] security_inode_getattr+0x1b/0x22 [ 474.970036] [<ffffffff811b057d>] vfs_getattr+0x19/0x2d [ 475.000618] [<ffffffff811b05e5>] vfs_fstatat+0x54/0x91 [ 475.030402] [<ffffffff811b063b>] vfs_lstat+0x19/0x1b [ 475.061097] [<ffffffff811b077e>] SyS_newlstat+0x15/0x30 [ 475.094595] [<ffffffff8113c5c1>] ? __audit_syscall_entry+0xa1/0xc3 [ 475.148405] [<ffffffff8197791e>] system_call_fastpath+0x16/0x1b [ 475.179201] Code: 00 48 85 c0 48 89 45 b8 75 02 0f 0b 48 8b 45 a0 48 8b 3d 45 d0 b6 00 8b 40 08 89 c6 ff ce e8 d1 b0 06 00 48 85 c0 49 89 c7 75 02 <0f> 0b 48 8b 45 b8 4c 8b 28 eb 1e 49 8d 7d 08 be 80 01 00 00 e8 [ 475.255884] RIP [<ffffffff814681c7>] context_struct_compute_av+0xce/0x308 [ 475.296120] RSP <ffff8805c0ac3c38> [ 475.328734] ---[ end trace f076482e9d754adc ]--- [sds: commit message edited to note Android implications and to generate a unique Change-Id for gerrit] Change-Id: I4d5389f0cfa72b5f59dada45081fa47e03805413 Reported-by: Matthew Thode <mthode@mthode.org> Signed-off-by: Stephen Smalley <sds@tycho.nsa.gov> Cc: stable@vger.kernel.org Signed-off-by: Paul Moore <pmoore@redhat.com>
Below Kernel panic is observed due to race condition, where
sock_has_perm called in a thread and is trying to access sksec->sid
without checking sksec. Just before that, sk->sk_security was set
to NULL by selinux_sk_free_security through sk_free in other thread.
31704.949269: <3> IPv4: Attempt to release alive inet socket dd81b200
31704.959049: <1> Unable to handle kernel NULL pointer dereference at \
virtual address 00000000
31704.983562: <1> pgd = c6b74000
31704.985248: <1> [00000000] *pgd=00000000
31704.996591: <0> Internal error: Oops: 5 [#1] PREEMPT SMP ARM
31705.001016: <6> Modules linked in: adsprpc [last unloaded: wlan]
31705.006659: <6> CPU: 1 Tainted: G O \
(3.4.0-g837ab9b-00003-g6bcd9c6 #1)
31705.014042: <6> PC is at sock_has_perm+0x58/0xd4
31705.018292: <6> LR is at sock_has_perm+0x58/0xd4
31705.022546: <6> pc : [<c0341e8c>] lr : [<c0341e8c>] \
psr: 60000013
31705.022549: <6> sp : dda27f00 ip : 00000000 fp : 5f36fc84
31705.034002: <6> r10: 00004000 r9 : 0000009d r8 : e8c2b700
31705.039211: <6> r7 : dda27f24 r6 : dd81b200 r5 : 00000000 \
r4 : 00000000
31705.045721: <6> r3 : 00000000 r2 : dda27ef8 r1 : 00000000 \
r0 : dda27f54
31705.052232: <6> Flags: nZCv IRQs on FIQs on Mode SVC_32 ISA ARM \
Segment user
31705.059349: <6> Control: 10c5787d Table: 10d7406a DAC: 00000015
.
.
.
.
31705.697816: <6> [<c0341e8c>] (sock_has_perm+0x58/0xd4) from \
[<c033ed10>] (security_socket_getsockopt+0x14/0x1c)
31705.707534: <6> [<c033ed10>] (security_socket_getsockopt+0x14/0x1c) \
from [<c0745c18>] (sys_getsockopt+0x34/0xa8)
31705.717343: <6> [<c0745c18>] (sys_getsockopt+0x34/0xa8) from \
[<c0106140>] (ret_fast_syscall+0x0/0x30)
31705.726193: <0> Code: e59832e8 e5933058 e5939004 ebfac736 (e5953000)
31705.732635: <4> ---[ end trace 22889004dafd87bd ]---
Change-Id: I79c3fb525f35ea2494d53788788cd71a38a32d6b
Signed-off-by: Satya Durga Srinivasu Prabhala <satyap@codeaurora.org>
Signed-off-by: Osvaldo Banuelos <osvaldob@codeaurora.org>
Hello.
I got below leak with linux-3.10.0-54.0.1.el7.x86_64 .
[ 681.903890] kmemleak: 5538 new suspected memory leaks (see /sys/kernel/debug/kmemleak)
Below is a patch, but I don't know whether we need special handing for undoing
ebitmap_set_bit() call.
----------
>>From fe97527a90fe95e2239dfbaa7558f0ed559c0992 Mon Sep 17 00:00:00 2001
From: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
Date: Mon, 6 Jan 2014 16:30:21 +0900
Subject: [PATCH] SELinux: Fix memory leak upon loading policy
Commit 2463c26d "SELinux: put name based create rules in a hashtable" did not
check return value from hashtab_insert() in filename_trans_read(). It leaks
memory if hashtab_insert() returns error.
unreferenced object 0xffff88005c9160d0 (size 8):
comm "systemd", pid 1, jiffies 4294688674 (age 235.265s)
hex dump (first 8 bytes):
57 0b 00 00 6b 6b 6b a5 W...kkk.
backtrace:
[<ffffffff816604ae>] kmemleak_alloc+0x4e/0xb0
[<ffffffff811cba5e>] kmem_cache_alloc_trace+0x12e/0x360
[<ffffffff812aec5d>] policydb_read+0xd1d/0xf70
[<ffffffff812b345c>] security_load_policy+0x6c/0x500
[<ffffffff812a623c>] sel_write_load+0xac/0x750
[<ffffffff811eb680>] vfs_write+0xc0/0x1f0
[<ffffffff811ec08c>] SyS_write+0x4c/0xa0
[<ffffffff81690419>] system_call_fastpath+0x16/0x1b
[<ffffffffffffffff>] 0xffffffffffffffff
However, we should not return EEXIST error to the caller, or the systemd will
show below message and the boot sequence freezes.
systemd[1]: Failed to load SELinux policy. Freezing.
Signed-off-by: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
Acked-by: Eric Paris <eparis@redhat.com>
Cc: stable@vger.kernel.org
Signed-off-by: Paul Moore <pmoore@redhat.com>
…l_htc_pico into cm-12.0-stagging Updates
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
14 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
No description provided.