aboutsummaryrefslogtreecommitdiff
Commit message (Collapse)AuthorAgeFilesLines
...
* defconfig: remove WIFI_CONTROL_FUNCMister Oyster2017-04-111-1/+0
|
* Revert "net: wireless: Add CONFIG_WIFI_CONTROL_FUNC option"Amit Pundir2017-04-111-5/+0
| | | | | | | | | | | This reverts commit 9486c0aac41b5283add06b8b9e83f0073bcae5ec. WIFI_CONTROL_FUNC config is not used anywhere in android-3.10+ kernels. Its usage can be last tracked to BCMDHD wireless driver in android-3.4 kernel. Change-Id: I8092bf10b70dd84a9bb3aade4aca80891742d504 Signed-off-by: Amit Pundir <amit.pundir@linaro.org>
* defconfig: remove CONFIG_TIMER_STATSMister Oyster2017-04-111-1/+0
|
* time: Remove CONFIG_TIMER_STATSKees Cook2017-04-1110-663/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Currently CONFIG_TIMER_STATS exposes process information across namespaces: kernel/time/timer_list.c print_timer(): SEQ_printf(m, ", %s/%d", tmp, timer->start_pid); /proc/timer_list: #11: <0000000000000000>, hrtimer_wakeup, S:01, do_nanosleep, cron/2570 Given that the tracer can give the same information, this patch entirely removes CONFIG_TIMER_STATS. Change-Id: Ice26d74094d3ad563808342c1604ad444234844b Suggested-by: Thomas Gleixner <tglx@linutronix.de> Signed-off-by: Kees Cook <keescook@chromium.org> Acked-by: John Stultz <john.stultz@linaro.org> Cc: Nicolas Pitre <nicolas.pitre@linaro.org> Cc: linux-doc@vger.kernel.org Cc: Lai Jiangshan <jiangshanlai@gmail.com> Cc: Shuah Khan <shuah@kernel.org> Cc: Xing Gao <xgao01@email.wm.edu> Cc: Jonathan Corbet <corbet@lwn.net> Cc: Jessica Frazelle <me@jessfraz.com> Cc: kernel-hardening@lists.openwall.com Cc: Nicolas Iooss <nicolas.iooss_linux@m4x.org> Cc: "Paul E. McKenney" <paulmck@linux.vnet.ibm.com> Cc: Petr Mladek <pmladek@suse.com> Cc: Richard Cochran <richardcochran@gmail.com> Cc: Tejun Heo <tj@kernel.org> Cc: Michal Marek <mmarek@suse.com> Cc: Josh Poimboeuf <jpoimboe@redhat.com> Cc: Dmitry Vyukov <dvyukov@google.com> Cc: Oleg Nesterov <oleg@redhat.com> Cc: "Eric W. Biederman" <ebiederm@xmission.com> Cc: Olof Johansson <olof@lixom.net> Cc: Andrew Morton <akpm@linux-foundation.org> Cc: linux-api@vger.kernel.org Cc: Arjan van de Ven <arjan@linux.intel.com> Link: http://lkml.kernel.org/r/20170208192659.GA32582@beast Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
* net: diag: allow socket bytecode filters to match socket marksLorenzo Colitti2017-04-112-3/+35
| | | | | | | | | | | | | | | | | | | This allows a privileged process to filter by socket mark when dumping sockets via INET_DIAG_BY_FAMILY. This is useful on systems that use mark-based routing such as Android. The ability to filter socket marks requires CAP_NET_ADMIN, which is consistent with other privileged operations allowed by the SOCK_DIAG interface such as the ability to destroy sockets and the ability to inspect BPF filters attached to packet sockets. [backport of net-next a52e95abf772b43c9226e9a72d3c1353903ba96f] Change-Id: If4609026882ef283a619b8bf24c0127f1f18ce6a Tested: https://android-review.googlesource.com/261350 Signed-off-by: Lorenzo Colitti <lorenzo@google.com> Acked-by: David Ahern <dsa@cumulusnetworks.com> Signed-off-by: David S. Miller <davem@davemloft.net>
* UPSTREAM: l2tp: fix racy SOCK_ZAPPED flag check in l2tp_ip{,6}_bind()Guillaume Nault2017-04-112-4/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | (cherry picked from commit 32c231164b762dddefa13af5a0101032c70b50ef) Lock socket before checking the SOCK_ZAPPED flag in l2tp_ip6_bind(). Without lock, a concurrent call could modify the socket flags between the sock_flag(sk, SOCK_ZAPPED) test and the lock_sock() call. This way, a socket could be inserted twice in l2tp_ip6_bind_table. Releasing it would then leave a stale pointer there, generating use-after-free errors when walking through the list or modifying adjacent entries. BUG: KASAN: use-after-free in l2tp_ip6_close+0x22e/0x290 at addr ffff8800081b0ed8 Write of size 8 by task syz-executor/10987 CPU: 0 PID: 10987 Comm: syz-executor Not tainted 4.8.0+ #39 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.8.2-0-g33fbe13 by qemu-project.org 04/01/2014 ffff880031d97838 ffffffff829f835b ffff88001b5a1640 ffff8800081b0ec0 ffff8800081b15a0 ffff8800081b6d20 ffff880031d97860 ffffffff8174d3cc ffff880031d978f0 ffff8800081b0e80 ffff88001b5a1640 ffff880031d978e0 Call Trace: [<ffffffff829f835b>] dump_stack+0xb3/0x118 lib/dump_stack.c:15 [<ffffffff8174d3cc>] kasan_object_err+0x1c/0x70 mm/kasan/report.c:156 [< inline >] print_address_description mm/kasan/report.c:194 [<ffffffff8174d666>] kasan_report_error+0x1f6/0x4d0 mm/kasan/report.c:283 [< inline >] kasan_report mm/kasan/report.c:303 [<ffffffff8174db7e>] __asan_report_store8_noabort+0x3e/0x40 mm/kasan/report.c:329 [< inline >] __write_once_size ./include/linux/compiler.h:249 [< inline >] __hlist_del ./include/linux/list.h:622 [< inline >] hlist_del_init ./include/linux/list.h:637 [<ffffffff8579047e>] l2tp_ip6_close+0x22e/0x290 net/l2tp/l2tp_ip6.c:239 [<ffffffff850b2dfd>] inet_release+0xed/0x1c0 net/ipv4/af_inet.c:415 [<ffffffff851dc5a0>] inet6_release+0x50/0x70 net/ipv6/af_inet6.c:422 [<ffffffff84c4581d>] sock_release+0x8d/0x1d0 net/socket.c:570 [<ffffffff84c45976>] sock_close+0x16/0x20 net/socket.c:1017 [<ffffffff817a108c>] __fput+0x28c/0x780 fs/file_table.c:208 [<ffffffff817a1605>] ____fput+0x15/0x20 fs/file_table.c:244 [<ffffffff813774f9>] task_work_run+0xf9/0x170 [<ffffffff81324aae>] do_exit+0x85e/0x2a00 [<ffffffff81326dc8>] do_group_exit+0x108/0x330 [<ffffffff81348cf7>] get_signal+0x617/0x17a0 kernel/signal.c:2307 [<ffffffff811b49af>] do_signal+0x7f/0x18f0 [<ffffffff810039bf>] exit_to_usermode_loop+0xbf/0x150 arch/x86/entry/common.c:156 [< inline >] prepare_exit_to_usermode arch/x86/entry/common.c:190 [<ffffffff81006060>] syscall_return_slowpath+0x1a0/0x1e0 arch/x86/entry/common.c:259 [<ffffffff85e4d726>] entry_SYSCALL_64_fastpath+0xc4/0xc6 Object at ffff8800081b0ec0, in cache L2TP/IPv6 size: 1448 Allocated: PID = 10987 [ 1116.897025] [<ffffffff811ddcb6>] save_stack_trace+0x16/0x20 [ 1116.897025] [<ffffffff8174c736>] save_stack+0x46/0xd0 [ 1116.897025] [<ffffffff8174c9ad>] kasan_kmalloc+0xad/0xe0 [ 1116.897025] [<ffffffff8174cee2>] kasan_slab_alloc+0x12/0x20 [ 1116.897025] [< inline >] slab_post_alloc_hook mm/slab.h:417 [ 1116.897025] [< inline >] slab_alloc_node mm/slub.c:2708 [ 1116.897025] [< inline >] slab_alloc mm/slub.c:2716 [ 1116.897025] [<ffffffff817476a8>] kmem_cache_alloc+0xc8/0x2b0 mm/slub.c:2721 [ 1116.897025] [<ffffffff84c4f6a9>] sk_prot_alloc+0x69/0x2b0 net/core/sock.c:1326 [ 1116.897025] [<ffffffff84c58ac8>] sk_alloc+0x38/0xae0 net/core/sock.c:1388 [ 1116.897025] [<ffffffff851ddf67>] inet6_create+0x2d7/0x1000 net/ipv6/af_inet6.c:182 [ 1116.897025] [<ffffffff84c4af7b>] __sock_create+0x37b/0x640 net/socket.c:1153 [ 1116.897025] [< inline >] sock_create net/socket.c:1193 [ 1116.897025] [< inline >] SYSC_socket net/socket.c:1223 [ 1116.897025] [<ffffffff84c4b46f>] SyS_socket+0xef/0x1b0 net/socket.c:1203 [ 1116.897025] [<ffffffff85e4d685>] entry_SYSCALL_64_fastpath+0x23/0xc6 Freed: PID = 10987 [ 1116.897025] [<ffffffff811ddcb6>] save_stack_trace+0x16/0x20 [ 1116.897025] [<ffffffff8174c736>] save_stack+0x46/0xd0 [ 1116.897025] [<ffffffff8174cf61>] kasan_slab_free+0x71/0xb0 [ 1116.897025] [< inline >] slab_free_hook mm/slub.c:1352 [ 1116.897025] [< inline >] slab_free_freelist_hook mm/slub.c:1374 [ 1116.897025] [< inline >] slab_free mm/slub.c:2951 [ 1116.897025] [<ffffffff81748b28>] kmem_cache_free+0xc8/0x330 mm/slub.c:2973 [ 1116.897025] [< inline >] sk_prot_free net/core/sock.c:1369 [ 1116.897025] [<ffffffff84c541eb>] __sk_destruct+0x32b/0x4f0 net/core/sock.c:1444 [ 1116.897025] [<ffffffff84c5aca4>] sk_destruct+0x44/0x80 net/core/sock.c:1452 [ 1116.897025] [<ffffffff84c5ad33>] __sk_free+0x53/0x220 net/core/sock.c:1460 [ 1116.897025] [<ffffffff84c5af23>] sk_free+0x23/0x30 net/core/sock.c:1471 [ 1116.897025] [<ffffffff84c5cb6c>] sk_common_release+0x28c/0x3e0 ./include/net/sock.h:1589 [ 1116.897025] [<ffffffff8579044e>] l2tp_ip6_close+0x1fe/0x290 net/l2tp/l2tp_ip6.c:243 [ 1116.897025] [<ffffffff850b2dfd>] inet_release+0xed/0x1c0 net/ipv4/af_inet.c:415 [ 1116.897025] [<ffffffff851dc5a0>] inet6_release+0x50/0x70 net/ipv6/af_inet6.c:422 [ 1116.897025] [<ffffffff84c4581d>] sock_release+0x8d/0x1d0 net/socket.c:570 [ 1116.897025] [<ffffffff84c45976>] sock_close+0x16/0x20 net/socket.c:1017 [ 1116.897025] [<ffffffff817a108c>] __fput+0x28c/0x780 fs/file_table.c:208 [ 1116.897025] [<ffffffff817a1605>] ____fput+0x15/0x20 fs/file_table.c:244 [ 1116.897025] [<ffffffff813774f9>] task_work_run+0xf9/0x170 [ 1116.897025] [<ffffffff81324aae>] do_exit+0x85e/0x2a00 [ 1116.897025] [<ffffffff81326dc8>] do_group_exit+0x108/0x330 [ 1116.897025] [<ffffffff81348cf7>] get_signal+0x617/0x17a0 kernel/signal.c:2307 [ 1116.897025] [<ffffffff811b49af>] do_signal+0x7f/0x18f0 [ 1116.897025] [<ffffffff810039bf>] exit_to_usermode_loop+0xbf/0x150 arch/x86/entry/common.c:156 [ 1116.897025] [< inline >] prepare_exit_to_usermode arch/x86/entry/common.c:190 [ 1116.897025] [<ffffffff81006060>] syscall_return_slowpath+0x1a0/0x1e0 arch/x86/entry/common.c:259 [ 1116.897025] [<ffffffff85e4d726>] entry_SYSCALL_64_fastpath+0xc4/0xc6 Memory state around the buggy address: ffff8800081b0d80: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc ffff8800081b0e00: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc >ffff8800081b0e80: fc fc fc fc fc fc fc fc fb fb fb fb fb fb fb fb ^ ffff8800081b0f00: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ffff8800081b0f80: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ================================================================== The same issue exists with l2tp_ip_bind() and l2tp_ip_bind_table. Bug: 33753815 Change-Id: If62df53e2652e1ec3273c3bc2dbf03b448f92f61 Fixes: c51ce49735c1 ("l2tp: fix oops in L2TP IP sockets for connect() AF_UNSPEC case") Reported-by: Baozeng Ding <sploving1@gmail.com> Reported-by: Andrey Konovalov <andreyknvl@google.com> Tested-by: Baozeng Ding <sploving1@gmail.com> Signed-off-by: Guillaume Nault <g.nault@alphalink.fr> Signed-off-by: David S. Miller <davem@davemloft.net>
* net: diag: make udp_diag_destroy work for mapped addresses.Lorenzo Colitti2017-04-111-2/+2
| | | | | | | | | | | | | | | | udp_diag_destroy does look up the IPv4 UDP hashtable for mapped addresses, but it gets the IPv4 address to look up from the beginning of the IPv6 address instead of the end. [backport of net-next f95bf346226b9b79352e05508beececc807cc37a] Change-Id: I308f49786458a68eef0c61e6f8f3486cab8cbea6 Tested: https://android-review.googlesource.com/269874 Fixes: 5d77dca82839 ("net: diag: support SOCK_DESTROY for UDP sockets") Signed-off-by: Lorenzo Colitti <lorenzo@google.com> Acked-by: Eric Dumazet <edumazet@google.com> Acked-by: David Ahern <dsa@cumulusnetworks.com> Signed-off-by: David S. Miller <davem@davemloft.net>
* android: base-cfg: remove CONFIG_IP[6]_NF_TARGET_REJECT_SKERRLorenzo Colitti2017-04-111-2/+0
| | | | | | | The corresponding code is gone and the unit tests check for its absence. Change-Id: Ia1d63f3af21242e38418db208ec222e61e633615
* android: base-cfg: enable CONFIG_INET_DIAG_DESTROYLorenzo Colitti2017-04-111-0/+1
| | | | | | | As of Android N, this is required to close sockets when a network disconnects. Change-Id: I9fe81c5fc5224c17bfd8d9e236ea9e436b5971cb
* UPSTREAM: net: avoid signed overflows for SO_{SND|RCV}BUFFORCEEric Dumazet2017-04-111-2/+2
| | | | | | | | | | | | | | | | | | | | | | (cherry picked from commit b98b0bc8c431e3ceb4b26b0dfc8db509518fb290) CAP_NET_ADMIN users should not be allowed to set negative sk_sndbuf or sk_rcvbuf values, as it can lead to various memory corruptions, crashes, OOM... Note that before commit 82981930125a ("net: cleanups in sock_setsockopt()"), the bug was even more serious, since SO_SNDBUF and SO_RCVBUF were vulnerable. This needs to be backported to all known linux kernels. Again, many thanks to syzkaller team for discovering this gem. Signed-off-by: Eric Dumazet <edumazet@google.com> Reported-by: Andrey Konovalov <andreyknvl@google.com> Signed-off-by: David S. Miller <davem@davemloft.net> Change-Id: I2b621c28c02267af5b34a379b2970fe5fb61a4f6 Bug: 33363517
* ANDROID: android-base: Enable QUOTA related configsJin Qian2017-04-111-0/+4
| | | | | Bug: 33757366 Change-Id: Iec4f55c3ca4a16dbc8695054f481d9261c56d0f6
* UPSTREAM: proc: prevent accessing /proc/<PID>/environ until it's readyMathias Krause2017-04-111-1/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | (cherry picked from commit 8148a73c9901a8794a50f950083c00ccf97d43b3) If /proc/<PID>/environ gets read before the envp[] array is fully set up in create_{aout,elf,elf_fdpic,flat}_tables(), we might end up trying to read more bytes than are actually written, as env_start will already be set but env_end will still be zero, making the range calculation underflow, allowing to read beyond the end of what has been written. Fix this as it is done for /proc/<PID>/cmdline by testing env_end for zero. It is, apparently, intentionally set last in create_*_tables(). This bug was found by the PaX size_overflow plugin that detected the arithmetic underflow of 'this_len = env_end - (env_start + src)' when env_end is still zero. The expected consequence is that userland trying to access /proc/<PID>/environ of a not yet fully set up process may get inconsistent data as we're in the middle of copying in the environment variables. Fixes: https://forums.grsecurity.net/viewtopic.php?f=3&t=4363 Fixes: https://bugzilla.kernel.org/show_bug.cgi?id=116461 Signed-off-by: Mathias Krause <minipli@googlemail.com> Cc: Emese Revfy <re.emese@gmail.com> Cc: Pax Team <pageexec@freemail.hu> Cc: Al Viro <viro@zeniv.linux.org.uk> Cc: Mateusz Guzik <mguzik@redhat.com> Cc: Alexey Dobriyan <adobriyan@gmail.com> Cc: Cyrill Gorcunov <gorcunov@openvz.org> Cc: Jarod Wilson <jarod@redhat.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Change-Id: Ia2f58d48c15478ed4b6e237b63e704c70ff21e96 Bug: 30951939
* ANDROID: base-cfg: enable SECCOMP configYongqin Liu2017-04-111-0/+1
| | | | | | | | | | | | | | Enable seccomp config CONFIG_SECCOMP=y Otherwise we will get mediacode error like this on Android N: E /system/bin/mediaextractor: libminijail: prctl(PR_SET_SECCOMP, SECCOMP_MODE_FILTER): Invalid argument Change-Id: I2477b6a2cfdded5c0ebf6ffbb6150b0e5fe2ba12 Signed-off-by: Yongqin Liu <yongqin.liu@linaro.org> Signed-off-by: Amit Pundir <amit.pundir@linaro.org>
* android: base-cfg: enable CONFIG_QUOTARom Lemarchand2017-04-111-0/+1
| | | | | | Bug: 28032718 Change-Id: I7cb6b641f72085e69b90dca11d2ea68adcd02390 (cherry picked from commit e1b53a388e9cfcf870520a6899a37456cf1ae2c6)
* ANDROID: exec_domains: Disable request_module() call for personalitiesJohn Stultz2017-04-111-1/+8
| | | | | | | | | | | | | | | | | | | | | | | | With Android M, Android environments use a separate execution domain for 32bit processes. See: https://android-review.googlesource.com/#/c/122131/ This results in systems that use kernel modules to see selinux audit noise like: type=1400 audit(28.989:15): avc: denied { module_request } for pid=1622 comm="app_process32" kmod="personality-8" scontext=u:r:zygote:s0 tcontext=u:r:kernel:s0 tclass=system While using kernel modules is unadvised, some systems do require them. Thus to avoid developers adding sepolicy exceptions to allow for request_module calls, this patch disables the logic which tries to call request_module for the 32bit personality (ie: personality-8), which doesn't actually exist. Change-Id: I6885347e69d5778e69ad5312f56f389be7bb4883 Signed-off-by: John Stultz <john.stultz@linaro.org>
* ANDROID: android: base-cfg: disable CONFIG_SYSVIPCGreg Hackmann2017-04-111-1/+1
| | | | | | | | | | Android SELinux policies block SysV IPC. New kernels should not be built with it. Bug: 22300191 Change-Id: Ia4bcb179ff71825cab19eed603d4064a8d061a93 Signed-off-by: Greg Hackmann <ghackmann@google.com>
* UPSTREAM: ppp: defer netns reference release for ppp channelWANG Cong2017-04-111-2/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | (cherry pick from commit 205e1e255c479f3fd77446415706463b282f94e4) Matt reported that we have a NULL pointer dereference in ppp_pernet() from ppp_connect_channel(), i.e. pch->chan_net is NULL. This is due to that a parallel ppp_unregister_channel() could happen while we are in ppp_connect_channel(), during which pch->chan_net set to NULL. Since we need a reference to net per channel, it makes sense to sync the refcnt with the life time of the channel, therefore we should release this reference when we destroy it. Fixes: 1f461dcdd296 ("ppp: take reference on channels netns") Reported-by: Matt Bennett <Matt.Bennett@alliedtelesis.co.nz> Cc: Paul Mackerras <paulus@samba.org> Cc: linux-ppp@vger.kernel.org Cc: Guillaume Nault <g.nault@alphalink.fr> Cc: Cyrill Gorcunov <gorcunov@openvz.org> Signed-off-by: Cong Wang <xiyou.wangcong@gmail.com> Reviewed-by: Cyrill Gorcunov <gorcunov@openvz.org> Signed-off-by: David S. Miller <davem@davemloft.net> Fixes: Change-Id: Iee0015eca5bd181954bb4896a3720f7549c5ed0b ("UPSTREAM: ppp: take reference on channels netns") Signed-off-by: Amit Pundir <amit.pundir@linaro.org> Change-Id: I24d0bb6f349ab3829f63cfe935ed97b6913a3508
* netfilter: xt_quota2: make quota2_log work wellLiping Zhang2017-04-112-2/+20
| | | | | | | | | | | | | | | | | | | | In upstream commit 7200135bc1e61f1437dc326ae2ef2f310c50b4eb (netfilter: kill ulog targets) http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=7200135bc1e6 ipt_ULOG target was removed, meanwhile, the IP_NF_TARGET_ULOG Kconfig and ipt_ULOG.h header file were removed too. This causes we cannot enable QUOTA2_LOG, and netd complains this error: "Unable to open quota socket". So when we reach the quota2 limit, userspace will not be notified with this event. Since IP_NF_TARGET_ULOG was removed, we need not depend on "IP_NF_TARGET_ULOG=n", and for compatibility, add ulog_packet_msg_t related definitions copied from "ipt_ULOG.h". Change-Id: I38132efaabf52bea75dfd736ce734a1b9690e87e Reported-by: Samboo Shen <samboo.shen@spreadtrum.com> Signed-off-by: Liping Zhang <liping.zhang@spreadtrum.com>
* kasan: add kernel address sanitizer infrastructureAndrey Ryabinin2017-04-1112-0/+852
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Kernel Address sanitizer (KASan) is a dynamic memory error detector. It provides fast and comprehensive solution for finding use-after-free and out-of-bounds bugs. KASAN uses compile-time instrumentation for checking every memory access, therefore GCC > v4.9.2 required. v4.9.2 almost works, but has issues with putting symbol aliases into the wrong section, which breaks kasan instrumentation of globals. This patch only adds infrastructure for kernel address sanitizer. It's not available for use yet. The idea and some code was borrowed from [1]. Basic idea: The main idea of KASAN is to use shadow memory to record whether each byte of memory is safe to access or not, and use compiler's instrumentation to check the shadow memory on each memory access. Address sanitizer uses 1/8 of the memory addressable in kernel for shadow memory and uses direct mapping with a scale and offset to translate a memory address to its corresponding shadow address. Here is function to translate address to corresponding shadow address: unsigned long kasan_mem_to_shadow(unsigned long addr) { return (addr >> KASAN_SHADOW_SCALE_SHIFT) + KASAN_SHADOW_OFFSET; } where KASAN_SHADOW_SCALE_SHIFT = 3. So for every 8 bytes there is one corresponding byte of shadow memory. The following encoding used for each shadow byte: 0 means that all 8 bytes of the corresponding memory region are valid for access; k (1 <= k <= 7) means that the first k bytes are valid for access, and other (8 - k) bytes are not; Any negative value indicates that the entire 8-bytes are inaccessible. Different negative values used to distinguish between different kinds of inaccessible memory (redzones, freed memory) (see mm/kasan/kasan.h). To be able to detect accesses to bad memory we need a special compiler. Such compiler inserts a specific function calls (__asan_load*(addr), __asan_store*(addr)) before each memory access of size 1, 2, 4, 8 or 16. These functions check whether memory region is valid to access or not by checking corresponding shadow memory. If access is not valid an error printed. Historical background of the address sanitizer from Dmitry Vyukov: "We've developed the set of tools, AddressSanitizer (Asan), ThreadSanitizer and MemorySanitizer, for user space. We actively use them for testing inside of Google (continuous testing, fuzzing, running prod services). To date the tools have found more than 10'000 scary bugs in Chromium, Google internal codebase and various open-source projects (Firefox, OpenSSL, gcc, clang, ffmpeg, MySQL and lots of others): [2] [3] [4]. The tools are part of both gcc and clang compilers. We have not yet done massive testing under the Kernel AddressSanitizer (it's kind of chicken and egg problem, you need it to be upstream to start applying it extensively). To date it has found about 50 bugs. Bugs that we've found in upstream kernel are listed in [5]. We've also found ~20 bugs in out internal version of the kernel. Also people from Samsung and Oracle have found some. [...] As others noted, the main feature of AddressSanitizer is its performance due to inline compiler instrumentation and simple linear shadow memory. User-space Asan has ~2x slowdown on computational programs and ~2x memory consumption increase. Taking into account that kernel usually consumes only small fraction of CPU and memory when running real user-space programs, I would expect that kernel Asan will have ~10-30% slowdown and similar memory consumption increase (when we finish all tuning). I agree that Asan can well replace kmemcheck. We have plans to start working on Kernel MemorySanitizer that finds uses of unitialized memory. Asan+Msan will provide feature-parity with kmemcheck. As others noted, Asan will unlikely replace debug slab and pagealloc that can be enabled at runtime. Asan uses compiler instrumentation, so even if it is disabled, it still incurs visible overheads. Asan technology is easily portable to other architectures. Compiler instrumentation is fully portable. Runtime has some arch-dependent parts like shadow mapping and atomic operation interception. They are relatively easy to port." Comparison with other debugging features: ======================================== KMEMCHECK: - KASan can do almost everything that kmemcheck can. KASan uses compile-time instrumentation, which makes it significantly faster than kmemcheck. The only advantage of kmemcheck over KASan is detection of uninitialized memory reads. Some brief performance testing showed that kasan could be x500-x600 times faster than kmemcheck: $ netperf -l 30 MIGRATED TCP STREAM TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to localhost (127.0.0.1) port 0 AF_INET Recv Send Send Socket Socket Message Elapsed Size Size Size Time Throughput bytes bytes bytes secs. 10^6bits/sec no debug: 87380 16384 16384 30.00 41624.72 kasan inline: 87380 16384 16384 30.00 12870.54 kasan outline: 87380 16384 16384 30.00 10586.39 kmemcheck: 87380 16384 16384 30.03 20.23 - Also kmemcheck couldn't work on several CPUs. It always sets number of CPUs to 1. KASan doesn't have such limitation. DEBUG_PAGEALLOC: - KASan is slower than DEBUG_PAGEALLOC, but KASan works on sub-page granularity level, so it able to find more bugs. SLUB_DEBUG (poisoning, redzones): - SLUB_DEBUG has lower overhead than KASan. - SLUB_DEBUG in most cases are not able to detect bad reads, KASan able to detect both reads and writes. - In some cases (e.g. redzone overwritten) SLUB_DEBUG detect bugs only on allocation/freeing of object. KASan catch bugs right before it will happen, so we always know exact place of first bad read/write. [1] https://code.google.com/p/address-sanitizer/wiki/AddressSanitizerForKernel [2] https://code.google.com/p/address-sanitizer/wiki/FoundBugs [3] https://code.google.com/p/thread-sanitizer/wiki/FoundBugs [4] https://code.google.com/p/memory-sanitizer/wiki/FoundBugs [5] https://code.google.com/p/address-sanitizer/wiki/AddressSanitizerForKernel#Trophies Based on work by Andrey Konovalov. Signed-off-by: Andrey Ryabinin <a.ryabinin@samsung.com> Acked-by: Michal Marek <mmarek@suse.cz> Signed-off-by: Andrey Konovalov <adech.fo@gmail.com> Cc: Dmitry Vyukov <dvyukov@google.com> Cc: Konstantin Serebryany <kcc@google.com> Cc: Dmitry Chernenkov <dmitryc@google.com> Cc: Yuri Gribov <tetra2005@gmail.com> Cc: Konstantin Khlebnikov <koct9i@gmail.com> Cc: Sasha Levin <sasha.levin@oracle.com> Cc: Christoph Lameter <cl@linux.com> Cc: Joonsoo Kim <iamjoonsoo.kim@lge.com> Cc: Dave Hansen <dave.hansen@intel.com> Cc: Andi Kleen <andi@firstfloor.org> Cc: Ingo Molnar <mingo@elte.hu> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: "H. Peter Anvin" <hpa@zytor.com> Cc: Christoph Lameter <cl@linux.com> Cc: Pekka Enberg <penberg@kernel.org> Cc: David Rientjes <rientjes@google.com> Cc: Stephen Rothwell <sfr@canb.auug.org.au> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> [tsoni@codeaurora.org: trivial merge conflicts] Signed-off-by: David Keitel <dkeitel@codeaurora.org>
* Input: xpad - x360w: report dpad as buttons and axesPavel Rojtberg2017-04-111-2/+20
| | | | | | | | | | | | | | | | | | as discussed here[0], x360w is the only pad that maps dpad_to_button. This is bad for downstream developers as they have to differ between x360 and x360w which is not intuitive. This patch implements the suggested solution of exposing the dpad both as axes and as buttons. This retains backward compatibility with software already dealing with the difference while makes new software work as expected across x360/ x360w pads. [0] http://www.spinics.net/lists/linux-input/msg34421.html Signed-off-by: Pavel Rojtberg <rojtberg@gmail.com> Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com> Signed-off-by: Tim Clark <tim.clark.82@gmail.com>
* Input: xpad - factor out URB submission in xpad_play_effectPavel Rojtberg2017-04-111-71/+69
| | | | | | | | | | Move submission logic to a single point at the end of the function. This makes it easy to add locking/ queuing code later on. Signed-off-by: Pavel Rojtberg <rojtberg@gmail.com> Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com> Signed-off-by: Tim Clark <tim.clark.82@gmail.com>
* Input: xpad - remove needless bulk out URB used for LED setupPavel Rojtberg2017-04-111-78/+1
| | | | | | | | | | | | | | | | This code was probably wrong ever since and is redundant with xpad_send_led_command. Both try to send a similar command to the xbox360 controller. However xpad_send_led_command correctly uses the pad_nr instead of bInterfaceNumber to select the led and re-uses the irq_out URB instead of creating a new one. Note that this change only affects the two supported wireless controllers. Tested using the xbox360 wireless controller (PC). Signed-off-by: Pavel Rojtberg <rojtberg@gmail.com> Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com> Signed-off-by: Tim Clark <tim.clark.82@gmail.com>
* Input: xpad - use ida() for finding the pad_nrPavel Rojtberg2017-04-111-12/+20
| | | | | | | | | | | | | | | | | | | | | | The pad_nr corresponds to the lit up LED on the controller. Therefore there should be no gaps when enumerating. Currently a LED is only re-assigned after a controller is re-connected 4 times. This patch uses ida to track connected pads - this way we can re-assign freed up pad number immediately. Consider the following case: 1. pad A is connected and gets pad_nr = 0 2. pad B is connected and gets pad_nr = 1 3. pad A is disconnected 4. pad A is connected again using ida_simple_get() controller A now correctly gets pad_nr = 0 again. Signed-off-by: Pavel Rojtberg <rojtberg@gmail.com> Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com> Signed-off-by: Tim Clark <tim.clark.82@gmail.com>
* Input: xpad - clarify LED enumerationPavel Rojtberg2017-04-111-7/+9
| | | | | | | | | | Rename led_no -> pad_nr: the number stored there is not the LED number - it gets translated later on to a LED number in xpad_identify_controller; Signed-off-by: Pavel Rojtberg <rojtberg@gmail.com> Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com> Signed-off-by: Tim Clark <tim.clark.82@gmail.com>
* Input: xpad - fix Razer Atrox Arcade Stick button mappingDario Scarpa2017-04-111-1/+1
| | | | | | | | | | | | The "Razer Atrox Arcade Stick" features 10 buttons, and two of them (LT/RT) don't work properly. Change its definition in xpad_device[] (mapping field) to fix. Signed-off-by: Dario Scarpa <dario.scarpa@duskzone.it> Signed-off-by: Pavel Rojtberg <rojtberg@gmail.com> Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com> Signed-off-by: Tim Clark <tim.clark.82@gmail.com>
* Input: xpad - add Covert Forces edition of the Xbox One controllerErik Lundgren2017-04-111-0/+1
| | | | | | | | | It is identical to the Xbox One controller but has a different product ID. Signed-off-by: Pavel Rojtberg <rojtberg@gmail.com> Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com> Signed-off-by: Tim Clark <tim.clark.82@gmail.com>
* Input: xpad - re-send LED command on present eventPavel Rojtberg2017-04-111-8/+20
| | | | | | | | | | | The controller only receives commands when its present. So for the correct LED to be lit the LED command has to be sent on the present event. Signed-off-by: Pavel Rojtberg <rojtberg@gmail.com> Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com> Signed-off-by: Tim Clark <tim.clark.82@gmail.com>
* Input: xpad - set the LEDs properly on XBox Wireless controllersPierre-Loup A. Griffais2017-04-111-5/+45
| | | | | | | | | | | | | | | | | Based on Patch by Pierre-Loup A. Griffais <pgriffais@valvesoftware.com>: Add the logic to set the LEDs on XBox Wireless controllers. Command sequence found by sniffing the Windows data stream when plugging the device in. Updated based on comments on linux-input: unify codepaths in xpad_send_led_command for wired/ wireless controller. Also document command values for clarification. All values tested on Xbox 360 Wireless Controller. Signed-off-by: Pavel Rojtberg <rojtberg@gmail.com> Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com> Signed-off-by: Tim Clark <tim.clark.82@gmail.com>
* Input: xpad - add rumble support for Xbox One controllerMing-ting Yao Wei2017-04-111-0/+19
| | | | | | | | | This adds rumble support for Xbox One controller by sending continuous rumble command. Trigger button rumbling is not yet implemented. Signed-off-by: Ming-ting Yao Wei <mwei@lxde.org> Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com> Signed-off-by: Tim Clark <tim.clark.82@gmail.com>
* Input: initialize device counter variables with -1Aniroop Mathur2017-04-115-12/+12
| | | | | | | | | | | Let's initialize atomic_t variables keeping track of number of various devices created so far with -1 in order to avoid extra subtraction operation. Change-Id: I58bfb094ec24e4b4cab48b3318852a27a227dc9a Signed-off-by: Aniroop Mathur <aniroop.mathur@gmail.com> Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com> Signed-off-by: Tim Clark <tim.clark.82@gmail.com>
* Input: xpad - add Thrustmaster as Xbox 360 controller vendorTommi Rantala2017-04-111-0/+1
| | | | | | | | | Add Thrustmaster as Xbox 360 controller vendor. This is required for example to make the GP XID (044f:b326) gamepad work. Signed-off-by: Tommi Rantala <tt.rantala@gmail.com> Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com> Signed-off-by: Tim Clark <tim.clark.82@gmail.com>
* Input: xpad - add USB ID for Thrustmaster Ferrari 458 Racing WheelTommi Rantala2017-04-111-0/+1
| | | | | | | | Add the USB ID for the Xbox 360 Thrustmaster Ferrari 458 Racing Wheel. Signed-off-by: Tommi Rantala <tt.rantala@gmail.com> Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com> Signed-off-by: Tim Clark <tim.clark.82@gmail.com>
* Input: xpad - sync device IDs with xboxdrvBenjamin Valentin2017-04-111-0/+33
| | | | | | | | | | | The userspace xboxdrv driver knows some more device ids than the kernel. This patch adds the missing xbox gamepads from [1] to xpad.c [1] https://github.com/Grumbel/xboxdrv/blob/master/src/xpad_device.cpp Signed-off-by: Benjamin Valentin <benpicco@zedat.fu-berlin.de> Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com> Signed-off-by: Tim Clark <tim.clark.82@gmail.com>
* Input: xpad - add VID/PID for Razer SabertoothFrank Razenberg2017-04-111-0/+1
| | | | | | | | | | The xpad driver recognizes Razer Sabertooth controllers as generic xbox controller, while it is really a 360 controller. This patch adds pid/vid mappings for the controller so that it is correctly recognized. Signed-off-by: Frank Razenberg <frank@zzattack.org> Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com> Signed-off-by: Tim Clark <tim.clark.82@gmail.com>
* Input: xpad - add support for Xbox One controllersTed Mielczarek2017-04-111-17/+157
| | | | | | | | | | | | | | | | Xbox One controllers require an initialization message to start sending data, so xpad_init_output becomes a required function. The Xbox One controller does not have LEDs like the Xbox 360 controller, so that functionality is not implemented. The format of messages controlling rumble is currently undocumented, so rumble support is not yet implemented. Note that Xbox One controller advertises three interfaces with the same interface class, subclass and protocol, so we have to also match against interface number. Signed-off-by: Ted Mielczarek <ted@mielczarek.org> Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com> Signed-off-by: Tim Clark <tim.clark.82@gmail.com>
* Input: xpad - add new USB IDs for Logitech F310 and F710Petr Sebor2017-04-111-0/+2
| | | | | | | | | This enables the rumble force feedback on the F710 unit since it is no longer treated as XTYPE_UNKNOWN type. Signed-off-by: Petr Sebor <petr@scssoft.com> Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com> Signed-off-by: Tim Clark <tim.clark.82@gmail.com>
* Input: xpad - change D-PAD mapping on Razer devicesThomaz de Oliveira dos Reis2017-04-111-2/+2
| | | | | | | | | | | | | When using Razer Onza controller the dpad doesn't work in many games because D-PAD was mapped to buttons (useful for dance pads) and not to HAT0X/Y axis. ers who really want to have it mapped to buttons can restore previous behavior by using 'dpad_to_buttons' module option. Signed-off-by: Thomaz de Oliveira dos Reis <thor27@gmail.com> Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com> Signed-off-by: Tim Clark <tim.clark.82@gmail.com>
* lib: lz4: cleanup unaligned access efficiency detectionRui Salvaterra2017-04-111-3/+1
| | | | | | | | | | | | These identifiers are bogus. The interested architectures should define HAVE_EFFICIENT_UNALIGNED_ACCESS whenever relevant to do so. If this isn't true for some arch, it should be fixed in the arch definition. Signed-off-by: Rui Salvaterra <rsalvaterra@gmail.com> Reviewed-by: Sergey Senozhatsky <sergey.senozhatsky@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Pranav Vashi <neobuddy89@gmail.com> Signed-off-by: MOVZX <movzx@yahoo.com>
* lib: lz4: fixed zram with lz4 on big endian machinesRui Salvaterra2017-04-111-9/+12
| | | | | | | | | | | | | | | | | | | | | | Based on Sergey's test patch [1], this fixes zram with lz4 compression on big endian cpus. Note that the 64-bit preprocessor test is not a cleanup, it's part of the fix, since those identifiers are bogus (for example, __ppc64__ isn't defined anywhere else in the kernel, which means we'd fall into the 32-bit definitions on ppc64). Tested on ppc64 with no regression on x86_64. [1] http://marc.info/?l=linux-kernel&m=145994470805853&w=4 Cc: stable@vger.kernel.org Suggested-by: Sergey Senozhatsky <sergey.senozhatsky@gmail.com> Signed-off-by: Rui Salvaterra <rsalvaterra@gmail.com> Reviewed-by: Sergey Senozhatsky <sergey.senozhatsky@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Pranav Vashi <neobuddy89@gmail.com> Signed-off-by: MOVZX <movzx@yahoo.com>
* lz4: fix system halt at boot kernel on x86_64Krzysztof Kolasa2017-04-111-1/+11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | Sometimes, on x86_64, decompression fails with the following error: Decompressing Linux... Decoding failed -- System halted This condition is not needed for a 64bit kernel(from commit d5e7caf): if( ... || (op + COPYLENGTH) > oend) goto _output_error macro LZ4_SECURE_COPY() tests op and does not copy any data when op exceeds the value. added by analogy to lz4_uncompress_unknownoutputsize(...) Signed-off-by: Krzysztof Kolasa <kkolasa@winsoft.pl> Tested-by: Alexander Kuleshov <kuleshovmail@gmail.com> Tested-by: Caleb Jorden <cjorden@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Pranav Vashi <neobuddy89@gmail.com> Signed-off-by: MOVZX <movzx@yahoo.com>
* lib/lz4: Pull out constant tablesRasmus Villemoes2017-04-111-11/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | There's no reason to allocate the dec{32,64}table on the stack; it just wastes a bunch of instructions setting them up and, of course, also consumes quite a bit of stack. Using size_t for such small integers is a little excessive. $ scripts/bloat-o-meter /tmp/built-in.o lib/built-in.o add/remove: 2/2 grow/shrink: 2/0 up/down: 1304/-1548 (-244) function old new delta lz4_decompress_unknownoutputsize 55 718 +663 lz4_decompress 55 632 +577 dec64table - 32 +32 dec32table - 32 +32 lz4_uncompress 747 - -747 lz4_uncompress_unknownoutputsize 801 - -801 The now inlined lz4_uncompress functions used to have a stack footprint of 176 bytes (according to -fstack-usage); their inlinees have increased their stack use from 32 bytes to 48 and 80 bytes, respectively. Signed-off-by: Rasmus Villemoes <linux@rasmusvillemoes.dk> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Pranav Vashi <neobuddy89@gmail.com> Signed-off-by: MOVZX <movzx@yahoo.com>
* UPSTREAM: seccomp: cap SECCOMP_RET_ERRNO data to MAX_ERRNOKees Cook2017-04-111-1/+3
| | | | | | | | | | | | | | | | | | The value resulting from the SECCOMP_RET_DATA mask could exceed MAX_ERRNO when setting errno during a SECCOMP_RET_ERRNO filter action. This makes sure we have a reliable value being set, so that an invalid errno will not be ignored by userspace. Signed-off-by: Kees Cook <keescook@chromium.org> Reported-by: Dmitry V. Levin <ldv@altlinux.org> Cc: Andy Lutomirski <luto@amacapital.net> Cc: Will Drewry <wad@chromium.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> (cherry picked from commit 580c57f1076872ebc2427f898b927944ce170f2d) Signed-off-by: Kees Cook <keescook@google.com> Change-Id: If82aa1b5f4be6375e8ca301d317d3d2db88a66dd
* Security Vulnerability: I2C debug interfaceDavid Chu2017-04-111-1/+1
| | | | | | | | [Solution] Removed the debug device driver Bug: ALPS02943467 Change-Id: I4fd2751ed3832d09355457f104ae8f936f9c1240
* nf: xt_qtaguid: fix handling for cases where tunnels are used.JP Abgrall2017-04-111-81/+70
| | | | | | | | | | | | | | | | | | | | | | | | | | | * fix skb->dev vs par->in/out When there is some forwarding going on, it introduces extra state around devs associated with xt_action_param->in/out and sk_buff->dev. E.g. par->in and par->out are both set, or skb->dev and par->out are both set (and different) This would lead qtaguid to make the wrong assumption about the direction and update the wrong device stats. Now we rely more on par->in/out. * Fix handling when qtaguid is used as "owner" When qtaguid is used as an owner module, and sk_socket->file is not there (happens when tunnels are involved), it would incorrectly do a tag stats update. * Correct debug messages. Bug: 11687690 Change-Id: I2b1ff8bd7131969ce9e25f8291d83a6280b3ba7f Signed-off-by: JP Abgrall <jpa@google.com> Git-commit: 2b71479d6f5fe8f33b335f713380f72037244395 Git-repo: https://www.codeaurora.org/cgit/quic/la/kernel/mediatek [imaund@codeaurora.org: Resolved trivial context conflicts.] Signed-off-by: Ian Maund <imaund@codeaurora.org>
* random32: add prandom_u32_max and convert open coded usersDaniel Borkmann2017-04-111-0/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Many functions have open coded a function that returns a random number in range [0,N-1]. Under the assumption that we have a PRNG such as taus113 with being well distributed in [0, ~0U] space, we can implement such a function as uword t = (n*m')>>32, where m' is a random number obtained from PRNG, n the right open interval border and t our resulting random number, with n,m',t in u32 universe. Lets go with Joe and simply call it prandom_u32_max(), although technically we have an right open interval endpoint, but that we have documented. Other users can further be migrated to the new prandom_u32_max() function later on; for now, we need to make sure to migrate reciprocal_divide() users for the reciprocal_divide() follow-up fixup since their function signatures are going to change. Joint work with Hannes Frederic Sowa. Cc: Jakub Zawadzki <darkjames-ws@darkjames.pl> Cc: Eric Dumazet <eric.dumazet@gmail.com> Cc: linux-kernel@vger.kernel.org Signed-off-by: Hannes Frederic Sowa <hannes@stressinduktion.org> Signed-off-by: Daniel Borkmann <dborkman@redhat.com> Signed-off-by: David S. Miller <davem@davemloft.net> Conflicts: net/packet/af_packet.c
* random: sprinkle e/f/prandom in places that deplete entropy oftenimoseyon2017-04-111-1/+1
|
* random.h: declare erandom functionimoseyon2017-04-111-0/+2
|
* random32: use e/frandom for reseeding, and a merge fixupimoseyon2017-04-111-3/+2
|
* UKSM: Add Governors for Higher CPU usage (HighCPU) for more merging, and low ↵Joe Maples2017-04-111-4/+4
| | | | | | | | | | cpu usage (Battery) for less battery drain based on https://github.com/dorimanx/DORIMANX_LG_STOCK_LP_KERNEL/commit/2cce6f5b6ba057c4c75d75f001d522ed79d115da ^Note the sign off at the bottom of his commit. Pretty sure he kaned one of my commits from my d2 kernel Signed-off-by: Joe Maples <joe@frap129.org>
* uksm: use deferrable timerRyan Pennucci2017-04-111-4/+24
|
generated by cgit v1.2.3 (git 2.39.1) at 2026-03-28 01:03:33 +0000