libqti-perfd.so is accessing this sysfs entry but we deliberately
disabled this feature.
Show a bogus entry instead to avoid poor userspace handling.
Change-Id: I16c120122ea8a22b5b85b6fb8d5fad3c0d197396
Signed-off-by: Park Ju Hyung <qkrwngud825@gmail.com>
Signed-off-by: Richard Raya <rdxzv.dev@gmail.com>
The logcat spam from perfd when the kernel doesn't have everything it
wants destroys logcats and creates excessive logd overhead from the sheer
number of logs it prints.
Block perfd from writing to the logd socket so that it cannot write to
logcat at all. This way, all perfd attempts to write to logcat are
killed early on before they can incur overhead, which solves the excessive
logd overhead problem.
Change-Id: I9489c5eb8c041b998affd154d1beca82459b5fcc
Signed-off-by: Sultan Alsawaf <sultan@kerneltoast.com>
Signed-off-by: Richard Raya <rdxzv.dev@gmail.com>
Recently, there's been some compat ioctl cleanup, in which large
hardcoded lists were replaced with compat_ptr_ioctl. One of these
changes involved removing the random.c hardcoded list entries and adding
a compat ioctl function pointer to the random.c fops. In the process,
urandom was forgotten about, so this commit fixes that oversight.
Fixes: 5b6250bc43fa ("compat_ioctl: Remove /dev/random commands")
Link: https://lore.kernel.org/r/20191217172455.186395-1-Jason@zx2c4.com
Change-Id: Id9cdb89a957c34a9ccbb8b96386a77fcf67815e1
Cc: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Richard Raya <rdxzv.dev@gmail.com>
These are all handled by the random driver, so instead of listing
each ioctl, we can use the generic compat_ptr_ioctl() helper.
Change-Id: I3271ba0b0b3d6ae904cc87f983d7d3f99935e767
Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Richard Raya <rdxzv.dev@gmail.com>
Many drivers have ioctl() handlers that are completely compatible between
32-bit and 64-bit architectures, except for the argument that is passed
down from user space and may have to be passed through compat_ptr()
in order to become a valid 64-bit pointer.
Using ".compat_ptr = compat_ptr_ioctl" in file operations should let
us simplify a lot of those drivers to avoid #ifdef checks, and convert
additional drivers that don't have proper compat handling yet.
On most architectures, the compat_ptr_ioctl() just passes all arguments
to the corresponding ->ioctl handler. The exception is arch/s390, where
compat_ptr() clears the top bit of a 32-bit pointer value, so user space
pointers to the second 2GB alias the first 2GB, as is the case for native
32-bit s390 user space.
The compat_ptr_ioctl() function must therefore be used only with
ioctl functions that either ignore the argument or pass a pointer to a
compatible data type.
If any ioctl command handled by fops->unlocked_ioctl passes a plain
integer instead of a pointer, or any of the passed data types is
incompatible between 32-bit and 64-bit architectures, a proper handler
is required instead of compat_ptr_ioctl.
Change-Id: Ic216898976f9369d6f8a316bf75eb9d8a00386fe
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Richard Raya <rdxzv.dev@gmail.com>
The function close_fd_get_file is explicitly a variant of
__close_fd[1]. Now that __close_fd has been renamed close_fd, rename
close_fd_get_file to be consistent with close_fd.
When __alloc_fd, __close_fd and __fd_install were introduced the
double underscore indicated that the function took a struct
files_struct parameter. The function __close_fd_get_file never has so
the naming has always been inconsistent. This just cleans things up
so there are not any lingering mentions or references __close_fd left
in the code.
[1] 80cd795630d6 ("binder: fix use-after-free due to ksys_close() during fdget()")
Link: https://lkml.kernel.org/r/20201120231441.29911-23-ebiederm@xmission.com
Change-Id: I191f5fa6c99112d22e90566727433a9314d2bb00
Signed-off-by: Eric W. Biederman <ebiederm@xmission.com>
Signed-off-by: Tashfin Shakeer Rhythm <tashfinshakeerrhythm@gmail.com>
Signed-off-by: Richard Raya <rdxzv.dev@gmail.com>
Change-Id: I9fe7c84d1b81fd8e2ef0ad89361c615c62693593
Signed-off-by: Andrzej Perczak <linux@andrzejperczak.com>
Signed-off-by: Richard Raya <rdxzv.dev@gmail.com>
This reverts commit 0831006b9b90d3bf775cd785e5d94e0682217d45.
Change-Id: Id8203ad7313490cd440602346a1d48e811f60484
Signed-off-by: Richard Raya <rdxzv.dev@gmail.com>
* recent fw updates are causing adsp to crash randomly,
such as during calls with live caption enabled
* in this specific case per my testing, instead of panicking
kernel and rebooting device, subsystem restart works just
fine with only a temporary loss of call audio for 1-2s
* __subsystem_restart_dev() panics the kernel anyway if ssr
fails so it would never enter an infinite loop
Change-Id: Ic508b9b61d25d0163bd1c9c5fef645eca26679ee
Signed-off-by: Richard Raya <rdxzv.dev@gmail.com>
This reverts commit 20f762702f50d7410d59fe88b7187275d09cbb20.
Change-Id: I14453fc22f4c67fc5a918868fc3c87181af4f4fc
Signed-off-by: Richard Raya <rdxzv.dev@gmail.com>
This reverts commit 7835e1ac9fe9bc3a1d58644f3d289d187ba881c6.
Change-Id: Ideb0f921d30572bcf69a16d7565ba6b3621832f4
Signed-off-by: Richard Raya <rdxzv.dev@gmail.com>
4 MiB isn't a meaningful amount to reclaim. Bump the limit to 32 MiB
instead.
Change-Id: I92fc9b35d121e6b39bced13d549e59d9e8e668e8
Signed-off-by: Danny Lin <danny@kdrag0n.dev>
Signed-off-by: Richard Raya <rdxzv.dev@gmail.com>
Avoid passing tail pages to isolate_lru_page. In the case
process reclaim, since only lru pages are considered, this
is just to avoid a warning from isolate_lru_page.
Change-Id: I1f54dcec15f8c2d5ba16738657e79d2793d36c77
Signed-off-by: Vinayak Menon <vinmenon@codeaurora.org>
Signed-off-by: Richard Raya <rdxzv.dev@gmail.com>
BSPSYS-10620
This change includes:
- fix reclaim count calculation issue
- only reclaim un-shared pages
- avoid burning CPU when nr_to_reclaim pages
- export reclaim_pte_range() API for rtmm
Change-Id: I04e77a2811f5ac4cae6d261c3eaaf88e26eee2ce
Signed-off-by: fangqinwu <fangqinwu@xiaomi.com>
Signed-off-by: Richard Raya <rdxzv.dev@gmail.com>
Other userspace apps like AppCOmpaction would like to use this node,
so update permission.
Change-Id: Ied22bd6ad489bef4028cde943ac185d1354ab971
Signed-off-by: <laoyi@codeaurora.org>
Signed-off-by: Richard Raya <rdxzv.dev@gmail.com>
This reverts commit c4da2896278405a71e10a3abe9639aff9b121d78.
Change-Id: I2df812002f8b1c234f173f014417d7cc7ef6829d
Signed-off-by: Richard Raya <rdxzv.dev@gmail.com>
This reverts commit 3736be6732067d480b95402c4e07239ed5145518.
Change-Id: I45d63b2a84f26da5a346c10670ed6adf46e635d1
Signed-off-by: Richard Raya <rdxzv.dev@gmail.com>
This reverts commit 094480a0881f1ad67e38bf7a92173fe0d88951f0.
Change-Id: I5d022039dd506a1b6bae6bb60bffc19f545c9bcb
Signed-off-by: Richard Raya <rdxzv.dev@gmail.com>
Similar to what I've done on other devices, revert to normal grace
periods to reduce power usage. Expedited RCU hammers CPUs with IPIs to
reduce grace period durations and thus RCU latency, but that disrupts
busy CPUs and causes unnecessary wakeups while providing little to no
improvement in real-world performance.
Change-Id: I230dc7283da50108171937876c60c8f13e4ace4e
Signed-off-by: Danny Lin <danny@kdrag0n.dev>
Signed-off-by: Richard Raya <rdxzv.dev@gmail.com>
This reverts commit e17aedc1fa5020b943f8f557f4795668737e8362.
Change-Id: I880ad0558e2bdd26ffb86ac36380dfd5f132e0bc
Signed-off-by: Richard Raya <rdxzv.dev@gmail.com>
OEMs disable it to improve throughput.
Change-Id: I9116c008cffc78c08e812adca6794d07794171ef
Signed-off-by: minaripenguin <minaripenguin@users.noreply.github.com>
Signed-off-by: Richard Raya <rdxzv.dev@gmail.com>
Both the VM and EXT4 have a "commit to disk after X seconds" time.
Currently the EXT4 time is shorter than our VM time, which is a bit
suboptional,
it's better for performance to let the VM do the writeouts in bulk
rather than something deep in the journalling layer.
Change-Id: I0de7bcfa9487421954cb9ae7f2cab3159c663878
Signed-off-by: Arjan van de Ven <arjan@linux.intel.com>
Signed-off-by: Jose Carlos Venegas Munoz <jose.carlos.venegas.munoz@intel.com>
Signed-off-by: Richard Raya <rdxzv.dev@gmail.com>
Android will unset SD_LOAD_BALANCE for big cluster domain and
for some product it is true to have a big cluster and the MC
domain thus lacks the SD_LOAD_BALANCE flag. This will cause
select_task_rq_fair logic break and the task will spin forever
in that cluster.
Bug: 141334320
Fixes: 00bbe7d605a9 "ANDROID: sched: EAS & 'single cpu per cluster'/cpu hotplug interoperability"
Test: boot and see task on core7 scheduled correctly
Change-Id: I7c2845b1f7bc1d4051eb3ad6a5f9838fb0b1ba04
Signed-off-by: Wei Wang <wvw@google.com>
Signed-off-by: Richard Raya <rdxzv.dev@gmail.com>
If the task is pinned to a cpu, setting the misfit status means that
we'll unnecessarily continuously attempt to migrate the task but fail.
This continuous failure will cause the balance_interval to increase to
a high value, and eventually cause unnecessary significant delays in
balancing the system when real imbalance happens.
Caught while testing uclamp where rt-app calibration loop was pinned to
cpu 0, shortly after which we spawn another task with high util_clamp
value. The task was failing to migrate after over 40ms of runtime due to
balance_interval unnecessary expanded to a very high value from the
calibration loop.
Not done here, but it could be useful to extend the check for pinning to
verify that the affinity of the task has a cpu that fits. We could end
up in a similar situation otherwise.
Fixes: 3b1baa6496e6 ("sched/fair: Add 'group_misfit_task' load-balance type")
Change-Id: I18be95658c3c06faec02ff2fce77c89540e83ebc
Signed-off-by: Qais Yousef <qais.yousef@arm.com>
Signed-off-by: Richard Raya <rdxzv.dev@gmail.com>
App compaction can not be aborted due to current design,
it causes app get stuck for a while when it resume to foreground
if app is compacting by kernel. So now we add check in kernel
while loop to abort the compaction if adj is zero.
Change-Id: I16f36a08d1a5efcb36827e84f5058abfa0a7dae0
Signed-off-by: huangzq2 <huangzq2@motorola.com>
Reviewed-on: https://gerrit.mot.com/2014822
SME-Granted: SME Approvals Granted
SLTApproved: Slta Waiver
Tested-by: Jira Key
Reviewed-by: Xiangpo Zhao <zhaoxp3@motorola.com>
Submit-Approved: Jira Key
Signed-off-by: Richard Raya <rdxzv.dev@gmail.com>
Allow selecting only tasks with oom_score_adj >= 0.
Change-Id: Iebbb487c711da98b8fcb367ba838b5fe0b260d4f
Signed-off-by: Patrick Daly <pdaly@codeaurora.org>
Signed-off-by: Richard Raya <rdxzv.dev@gmail.com>
The proc file `compact_unevictable_allowed' should allow 0 and 1 only, the
`extra*' attribues have been set properly but without
proc_dointvec_minmax() as the `proc_handler' the limit will not be
enforced.
Use proc_dointvec_minmax() as the `proc_handler' to enfoce the valid
specified range.
Link: http://lkml.kernel.org/r/20200303202054.gsosv7fsx2ma3cic@linutronix.de
Change-Id: I7ba356dac5d11ef0c1bbf4509fa61459f35a0a8f
Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Reviewed-by: Andrew Morton <akpm@linux-foundation.org>
Acked-by: Vlastimil Babka <vbabka@suse.cz>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Luis Chamberlain <mcgrof@kernel.org>
Cc: Kees Cook <keescook@chromium.org>
Cc: Iurii Zaikin <yzaikin@google.com>
Cc: Mel Gorman <mgorman@techsingularity.net>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Richard Raya <rdxzv.dev@gmail.com>
This reverts commit dcd2f048585afbaf334fab83607d28cee2c1f1ed.
Change-Id: Ia6991c9093b516ae5b5915c06f468b3b47a6b8a7
Signed-off-by: Richard Raya <rdxzv.dev@gmail.com>
To turn the KMSG_DUMP_* reasons into a more ordered list, collapse
the redundant KMSG_DUMP_(RESTART|HALT|POWEROFF) reasons into
KMSG_DUMP_SHUTDOWN. The current users already don't meaningfully
distinguish between them, so there's no need to, as discussed here:
https://lore.kernel.org/lkml/CA+CK2bAPv5u1ih5y9t5FUnTyximtFCtDYXJCpuyjOyHNOkRdqw@mail.gmail.com/
Link: https://lore.kernel.org/lkml/20200515184434.8470-2-keescook@chromium.org/
Change-Id: I23f5d8ed4b16c2b506b1727abfe2b40bb9dc6db0
Acked-by: Michael Ellerman <mpe@ellerman.id.au> (powerpc)
Reviewed-by: Pavel Tatashin <pasha.tatashin@soleen.com>
Reviewed-by: Petr Mladek <pmladek@suse.com>
Signed-off-by: Kees Cook <keescook@chromium.org>
Signed-off-by: Alexander Winkowski <dereference23@outlook.com>
Signed-off-by: Richard Raya <rdxzv.dev@gmail.com>
Now that pstore_register() can correctly pass max_reason to the kmesg
dump facility, introduce a new "max_reason" module parameter and
"max-reason" Device Tree field.
The "dump_oops" module parameter and "dump-oops" Device
Tree field are now considered deprecated, but are now automatically
converted to their corresponding max_reason values when present, though
the new max_reason setting has precedence.
For struct ramoops_platform_data, the "dump_oops" member is entirely
replaced by a new "max_reason" member, with the only existing user
updated in place.
Additionally remove the "reason" filter logic from ramoops_pstore_write(),
as that is not specifically needed anymore, though technically
this is a change in behavior for any ramoops users also setting the
printk.always_kmsg_dump boot param, which will cause ramoops to behave as
if max_reason was set to KMSG_DUMP_MAX.
Link: https://lore.kernel.org/lkml/20200515184434.8470-6-keescook@chromium.org/
Change-Id: I563849afcc4975f36b616c2976202df92cfe4d14
Co-developed-by: Pavel Tatashin <pasha.tatashin@soleen.com>
Signed-off-by: Pavel Tatashin <pasha.tatashin@soleen.com>
Signed-off-by: Kees Cook <keescook@chromium.org>
Signed-off-by: Alexander Winkowski <dereference23@outlook.com>
Signed-off-by: Richard Raya <rdxzv.dev@gmail.com>
Add a new member to struct pstore_info for passing information about
kmesg dump maximum reason. This allows a finer control of what kmesg
dumps are sent to pstore storage backends.
Those backends that do not explicitly set this field (keeping it equal to
0), get the default behavior: store only Oopses and Panics, or everything
if the printk.always_kmsg_dump boot param is set.
Link: https://lore.kernel.org/lkml/20200515184434.8470-5-keescook@chromium.org/
Change-Id: Iedf5f428a0bdb38f1fe5effa6226292b7144bd95
Co-developed-by: Kees Cook <keescook@chromium.org>
Signed-off-by: Pavel Tatashin <pasha.tatashin@soleen.com>
Signed-off-by: Kees Cook <keescook@chromium.org>
Signed-off-by: Alexander Winkowski <dereference23@outlook.com>
Signed-off-by: Richard Raya <rdxzv.dev@gmail.com>
Refactor device tree size parsing routines to be able to pass a non-zero
default value for providing a configurable default for the coming
"max_reason" field. Also rename the helpers, since we're not always
parsing a size -- we're parsing a u32 and making sure it's not greater
than INT_MAX.
Link: https://lore.kernel.org/lkml/20200506211523.15077-4-keescook@chromium.org/
Link: https://lore.kernel.org/lkml/20200521205223.175957-1-tyhicks@linux.microsoft.com
Change-Id: If44ba60c12ecb5595d6c124ce9b44f886cd27018
Signed-off-by: Kees Cook <keescook@chromium.org>
Signed-off-by: Alexander Winkowski <dereference23@outlook.com>
Signed-off-by: Richard Raya <rdxzv.dev@gmail.com>
A couple module parameters had 0600 permissions, but changing them would
have no impact on ramoops, so switch these to 0400 to reflect reality.
Link: https://lore.kernel.org/lkml/20200506211523.15077-7-keescook@chromium.org/
Change-Id: Iab22b003fa4f7c9cb9b5fd26d3d176af37c7c454
Signed-off-by: Kees Cook <keescook@chromium.org>
Signed-off-by: Alexander Winkowski <dereference23@outlook.com>
Signed-off-by: Richard Raya <rdxzv.dev@gmail.com>
Since the header is a fixed small maximum size, just use a stack variable
to avoid memory allocation in the write path.
Change-Id: I9f8a09f0f95058a40647e1cd55238c80f95d5e4b
Signed-off-by: Kees Cook <keescook@chromium.org>
Signed-off-by: Alexander Winkowski <dereference23@outlook.com>
Signed-off-by: Richard Raya <rdxzv.dev@gmail.com>
If zero-length header happened in ramoops_write_kmsg_hdr(), that means
we will not be able to read back dmesg record later, since it will be
treated as invalid header in ramoops_pstore_read(). So we should not
execute the following code but return the error.
Change-Id: I86519a8fb83bacde9879b8149d80a34c37ace8a8
Signed-off-by: Yue Hu <huyue2@yulong.com>
Signed-off-by: Kees Cook <keescook@chromium.org>
Signed-off-by: Alexander Winkowski <dereference23@outlook.com>
Signed-off-by: Richard Raya <rdxzv.dev@gmail.com>
Since only one single ramoops area allowed at a time, other probes
(like device tree) are meaningless, as it will waste CPU resources.
So let's check for being already initialized first.
Change-Id: I37823492ff578d8b4485d2b762a1bcbbba2ddc49
Signed-off-by: Yue Hu <huyue2@yulong.com>
Signed-off-by: Kees Cook <keescook@chromium.org>
Signed-off-by: Alexander Winkowski <dereference23@outlook.com>
Signed-off-by: Richard Raya <rdxzv.dev@gmail.com>
Sometimes pstore_console_write() will write records with zero size
to persistent ram zone, which is unnecessary. It will only increase
resource consumption. Also adjust ramoops_write_kmsg_hdr() to have
same logic if memory allocation fails.
Change-Id: I66e5aa533774ce429feec697056e1eda5ef56b03
Signed-off-by: Yue Hu <huyue2@yulong.com>
Signed-off-by: Kees Cook <keescook@chromium.org>
Signed-off-by: Alexander Winkowski <dereference23@outlook.com>
Signed-off-by: Richard Raya <rdxzv.dev@gmail.com>
