Simple LMK's reclaim thread needs to run as quickly as possible to
reduce memory allocation latency when memory pressure is high. Run it
on fast, big cluster CPUs.
Signed-off-by: Sultan Alsawaf <sultan@kerneltoast.com>
Change-Id: I6fef904710722b89b19cf119bf92779c364b2c2e
When Simple LMK is enabled, the page allocator slowpath always thinks that
no OOM kill progress is made because out_of_memory() returns false. As a
result, spurious page allocation failures are observed when memory is low
and Simple LMK is killing tasks, simply because the page allocator slowpath
doesn't think that any OOM killing is taking place.
Fix this by simply making out_of_memory() always return true when Simple
LMK is enabled.
Signed-off-by: Sultan Alsawaf <sultan@kerneltoast.com>
Change-Id: Ib91e593e67b8d155bb8c1a1de807b524f9348d61
* Our camera HAL uses boot time for buffer timestamp, rather than
system monotonic time. This leads to issues as framework uses system
monotonic time as reference start time for timestamp adjustment.
* This patch is taken from stock kernel source.
Change-Id: Ia4fac1d48e2206a7befd0030585776371dd8c3a9
If we're using a refresh rate different from what the bootloader
initializes the display with, a panel reset is necessary for our custom
refresh rate to take effect.
After the first kickoff, request a panel reset from userspace using the
existing ESD recovery mechanism to update the refresh rate. Note that
this is only done if the target refresh rate is *not* 60 Hz because this
is redundant if we don't need a refresh rate update.
Signed-off-by: Danny Lin <danny@kdrag0n.dev>
Change-Id: Icb7170ad84a719fc89d94ac763e54d804410a894
* Needs to implement and register ops from TP driver
* Access them via /sys/touchpanel/*
* Export capacitive keys status
Change-Id: Iad0fdfc1c9a2b3daf8cf97b6a3a079bdfae05e10
Change subprocess arguments in kernel_headers.py
script so that it can include dirname to resolve the
compilation issues in the new build system.
Change-Id: I89bbe53aa8a8b50e2c98a795fa20a976f2792a3b
Signed-off-by: Bharat Pawar <c_bpawar@codeaurora.org>
Signed-off-by: Eruvaram Kumar Raja Reddy <erajared@codeaurora.org>
Tools used within the sandbox are now copied into the
sandbox, see aosp/1531944. This caused the modified
headers_install.sh, which is no longer installed, to
point to a non-existent location.
This change adds a level of indirection. The
gen-headers_install.sh module no longer uses unifdef as
a tool, but still modifies the headers_install.sh
script, but not to point to a particular location, but
to find the unifdef tool via an environment variable,
LOC_UNIFDEF.
Next, we modify qti_generate_kernel_headers_arm and
qti_generate_kernel_headers_arm64 to need the unifdef
tool (which is copied into the sandbox for these tools).
We add a new --unifdef option to the kernel_headers.py
script so that it can find the tool in the sandbox. The
kernel_headers.py script sets the LOC_UNIFDEF
environment variable before invoking the altered
headers_install.sh script (also copied into the
sandbox).
Finally, we generate gen_headers_arm.bp and
gen_headers_arm64.bp with all of these changes.
Bug: 178500203
Change-Id: Ie3b8c36b7d60bd950c28bac566e04f43de78cf98
Signed-off-by: Mohammed Athar <athar@codeaurora.org>
Signed-off-by: Shadab Naseem <snaseem@codeaurora.org>
Signed-off-by: Eruvaram Kumar Raja Reddy <erajared@codeaurora.org>
To avoid build failures in the newer Android build systems,
run the headers_install script explicitly under 'sh'.
Change-Id: If30d2bda653c6be443345a2594e9993d9780db21
Signed-off-by: Soumil Shah <soumshah@codeaurora.org>
Signed-off-by: Raghavendra Rao Ananta <rananta@codeaurora.org>
commit 6bfb56e93bcef41859c2d5ab234ffd80b691be35 upstream.
OpenSSL 3.0 deprecated the OpenSSL's ENGINE API. That is as may be, but
the kernel build host tools still use it. Disable the warning about
deprecated declarations until somebody who cares fixes it.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Change-Id: Ica9fdcbc6276bdb76b6e7a2f5cab7af608e97659
commit e3b03bf29d6b99fab7001fb20c33fe54928c157a upstream.
Commit 1c199f2878f6 ("kbuild: document recursive dependency limitation
/ resolution") probably intended to show a hint along with "recursive
dependency detected!" error, but it missed to add {...} guard, and the
hint is displayed in every loop of the dep_stack traverse, annoyingly.
This error was detected by GCC's -Wmisleading-indentation when switching
to build-time generation of lexer/parser.
scripts/kconfig/symbol.c: In function ‘sym_check_print_recursive’:
scripts/kconfig/symbol.c:1150:3: warning: this ‘if’ clause does not guard... [-Wmisleading-indentation]
if (stack->sym == last_sym)
^~
scripts/kconfig/symbol.c:1153:4: note: ...this statement, but the latter is misleadingly indented as if it were guarded by the ‘if’
fprintf(stderr, "For a resolution refer to Documentation/kbuild/kconfig-language.txt\n");
^~~~~~~
I could simply add {...} to surround the three fprintf(), but I rather
chose to move the hint after the loop to make the whole message readable.
Fixes: 1c199f2878f6 ("kbuild: document recursive dependency limitation / resolution"
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Acked-by: Luis R. Rodriguez <mcgrof@kernel.org>
Cc: Daniel Díaz <daniel.diaz@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Change-Id: I02f72a4d3c20248f8dc8502888511edaea56af7f
Starting with LLVM 16, this flag is deprecated, which means its presence
breaks the build:
Cannot use CONFIG_CC_STACKPROTECTOR_STRONG: -fstack-protector-strong not supported by compiler
make[2]: *** [../Makefile:1289: prepare-compiler-check] Error 1
clang-16: warning: the flag '-enable-trivial-auto-var-init-zero-knowing-it-will-be-removed-from-clang' has been deprecated and will be ignored [-Wunused-command-line-argument]
clang-16: warning: the flag '-enable-trivial-auto-var-init-zero-knowing-it-will-be-removed-from-clang' has been deprecated and will be ignored [-Wunused-command-line-argument]
Wrap this option in cc-option so that it only gets added to the list of
flags when it is supported. This is resolved properly upstream already
with commit 607e57c6c62c ("hardening: Remove Clang's enable flag for
-ftrivial-auto-var-init=zero") but that cannot be easily backported due
to lack of cc-option support in Kconfig, hence this downstream only
change.
Change-Id: Ie1f7bcdec23f01bf19c68b4dae460923aaa150c9
Fixes: a7eda6eddca5 ("BACKPORT: security: allow using Clang's zero initialization for stack variables")
Link: aef03c9b3b
Signed-off-by: Nathan Chancellor <nathan@kernel.org>
commit ec9d78070de986ecf581ea204fd322af4d2477ec upstream.
Commit 39d114ddc682 ("arm64: add KASAN support") added .weak directives to
arch/arm64/lib/mem*.S instead of changing the existing SYM_FUNC_START_PI
macros. This can lead to the assembly snippet `.weak memcpy ... .globl
memcpy` which will produce a STB_WEAK memcpy with GNU as but STB_GLOBAL
memcpy with LLVM's integrated assembler before LLVM 12. LLVM 12 (since
https://reviews.llvm.org/D90108) will error on such an overridden symbol
binding.
Use the appropriate SYM_FUNC_START_WEAK_PI instead.
Fixes: 39d114ddc682 ("arm64: add KASAN support")
Reported-by: Sami Tolvanen <samitolvanen@google.com>
Signed-off-by: Fangrui Song <maskray@google.com>
Tested-by: Sami Tolvanen <samitolvanen@google.com>
Tested-by: Nick Desaulniers <ndesaulniers@google.com>
Reviewed-by: Nick Desaulniers <ndesaulniers@google.com>
Cc: <stable@vger.kernel.org>
Link: https://lore.kernel.org/r/20201029181951.1866093-1-maskray@google.com
Signed-off-by: Will Deacon <will@kernel.org>
[nd: backport to adjust for missing:
commit 3ac0f4526dfb ("arm64: lib: Use modern annotations for assembly functions")
commit 35e61c77ef38 ("arm64: asm: Add new-style position independent function annotations")]
Signed-off-by: Nick Desaulniers <ndesaulniers@google.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Change-Id: I63c34385861c5a84cdf332a912f5ee53dedac3bd
* google/upstream-f2fs-stable-linux-4.14.y:
f2fs: use onstack pages instead of pvec
f2fs: intorduce f2fs_all_cluster_page_ready
f2fs: clean up f2fs_abort_atomic_write()
f2fs: handle decompress only post processing in softirq
f2fs: do not allow to decompress files have FI_COMPRESS_RELEASED
f2fs: do not set compression bit if kernel doesn't support
f2fs: remove device type check for direct IO
f2fs: fix null-ptr-deref in f2fs_get_dnode_of_data
f2fs: revive F2FS_IOC_ABORT_VOLATILE_WRITE
f2fs: fix fallocate to use file_modified to update permissions consistently
vfs: introduce file_modified() helper
f2fs: fix to do sanity check on segment type in build_sit_entries()
f2fs: obsolete unused MAX_DISCARD_BLOCKS
f2fs: fix to avoid use f2fs_bug_on() in f2fs_new_node_page()
f2fs: fix to remove F2FS_COMPR_FL and tag F2FS_NOCOMP_FL at the same time
f2fs: introduce sysfs atomic write statistics
f2fs: don't bother wait_ms by foreground gc
f2fs: invalidate meta pages only for post_read required inode
f2fs: allow compression of files without blocks
f2fs: fix to check inline_data during compressed inode conversion
f2fs: fix to invalidate META_MAPPING before DIO write
f2fs: adjust zone capacity when considering valid block count
f2fs: enforce single zone capacity
f2fs: remove redundant code for gc condition
f2fs: introduce memory mode
f2fs: initialize page_array_entry slab only if compression feature is on
f2fs: optimize error handling in redirty_blocks
f2fs: do not skip updating inode when retrying to flush node page
Revert "f2fs: run GCs synchronously given user requests"
"LA.UM.9.1.r1-12200-SMxxx0.QSSI13.0"
* tag 'LA.UM.9.1.r1-12200-SMxxx0.QSSI13.0' of https://git.codelinaro.org/clo/la/kernel/msm-4.14:
smcinvoke : file private data validation, which is sent by userspace
input: touchscreen: focaltech: queue touch suspend work on workqueue
input: touchscreen: focaltech: fix return value
haven: irq_lend: add support for IRQ notifications
haven: Add support for the MEM_ACCEPTED notification
msm: ADSPRPC: Restrict untrusted applications from attaching to GuestOS
msm: vidc: fix msm_comm_get_vidc_buffer fd race issue
msm: ipa: clear the ipa pipeline before any ep config
Deletion of timer and synchronization of the handler will happen
during del_timer, but in the issue case the timer got deleted and
before handler_sync should happen the timer is getting modified or
accessed which further leads to kernel panic.
Fix this by modifying del_timer to del_timer_sync so that the timer
is protected until synchronization happen.
Change-Id: If5dec66b9bbcb5369898536ba1c727b487a13018
Signed-off-by: Venkata Manasa Kakarla <venkka@codeaurora.org>
Signed-off-by: Pranav Vashi <neobuddy89@gmail.com>
Signed-off-by: azrim <mirzaspc@gmail.com>
In suspend just before stopping the channel possible to receive
the IEOB interrupt and xfer pointer will not be processed in this
mode but gsi stats are updated. In resume after starting the channel
will receive the IEOB interrupt and xfer pointer will be overwritten
because of this observing the gsi/sys len stats are not matching and
buffers won't be replinished properly leading to HW stall.
To avoid this process all data in polling context, gsi/sys len
stats are updated properly.
Bug: 158990845
Test: 1.build pass and can boot to home
2.Mobile data,VoLTE,WFC,MMS,MHS
Change-Id: Id665448165b6aa51b251cddd72573c6df64ee541
Signed-off-by: Ashok Vuyyuru <avuyyuru@codeaurora.org>
Signed-off-by: Pranav Vashi <neobuddy89@gmail.com>
Signed-off-by: azrim <mirzaspc@gmail.com>
Setting max freq which is not in the given cpu's freq table, the
target_freq is the same with max freq. When selecting the freq, it uses
CPUFREQ_RELATION_L, so the frequency round to the next. This is
reasonable for normal cases but the frequency should not run over the
max setting.
Bug: 158134249
Test: build and set max/min freq to check
Change-Id: I804454225c10b7a023b323c58e77b7bba1ec3576
Signed-off-by: Kyle Lin <kylelin@google.com>
Signed-off-by: azrim <mirzaspc@gmail.com>
Currently there is a chance of a schedutil cpufreq update request to be
dropped if there is a pending update request. This pending request can
be delayed if there is a scheduling delay of the irq_work and the wake
up of the schedutil governor kthread.
A very bad scenario is when a schedutil request was already just made,
such as to reduce the CPU frequency, then a newer request to increase
CPU frequency (even sched deadline urgent frequency increase requests)
can be dropped, even though the rate limits suggest that its Ok to
process a request. This is because of the way the work_in_progress flag
is used.
This patch improves the situation by allowing new requests to happen
even though the old one is still being processed. Note that in this
approach, if an irq_work was already issued, we just update next_freq
and don't bother to queue another request so there's no extra work being
done to make this happen.
Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
Acked-by: Juri Lelli <juri.lelli@redhat.com>
Signed-off-by: Joel Fernandes (Google) <joel@joelfernandes.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Adam W. Willis <return.of.octobot@gmail.com>
Signed-off-by: Yaroslav Furman <yaro330@gmail.com>
Signed-off-by: azrim <mirzaspc@gmail.com>
Got never update frequency if scheduled the irq
work on an offlined cpu and it will always pending.
Queue sugov irq work on any online cpu if current
cpu is offline.
Change-Id: I33fc691917b5866488b6aeb11ed902a2753130b2
Signed-off-by: Maria Yu <aiquny@codeaurora.org>
[clingutla@codeaurora.org: Resolved minor merge conflicts]
Signed-off-by: Lingutla Chandrasekhar <clingutla@codeaurora.org>
Signed-off-by: Adam W. Willis <return.of.octobot@gmail.com>
Signed-off-by: Yaroslav Furman <yaro330@gmail.com>
Signed-off-by: azrim <mirzaspc@gmail.com>
Declaration of struct node is required regardless. On UMA systems,
including compaction.h without preceding node.h shouldn't cause a build
error.
Link: http://lkml.kernel.org/r/20190208080437.253322-1-yuzhao@google.com
Signed-off-by: Yu Zhao <yuzhao@google.com>
Reviewed-by: Andrew Morton <akpm@linux-foundation.org>
Acked-by: Michal Hocko <mhocko@suse.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: UtsavBalar1231 <utsavbalar1231@gmail.com>
Change-Id: I37fda3050a67d55829f3433034f98483b7c9ad0b
Signed-off-by: azrim <mirzaspc@gmail.com>
A recent LTS change causes add_hwgenerator_randomness() to crash when
called from a non-kthread task. This shouldn't be a problem, since this
function should only be called by the HWRNG framework. However, on this
branch it is part of the KMI since a vendor module is using it
inappropriately by calling it during early init. (Note that
add_bootloader_randomness() would be a better fit for the use case.)
To prevent a crash in this case, restore support for
add_hwgenerator_randomness() being called from a non-kthread task.
This change isn't currently needed in 5.4 or newer kernels, as
add_hwgenerator_randomness() isn't part of the KMI there.
Bug: 238701371
Fixes: 8bc7018f08a9 ("random: do not use batches when !crng_ready()")
Change-Id: I0b86743deb30f54b8f838a36eea740b370a30a8b
Signed-off-by: Eric Biggers <ebiggers@google.com>
Signed-off-by: azrim <mirzaspc@gmail.com>
Patch series "mm: madvise: return correct bytes processed with
process_madvise", v2. With the process_madvise(), always choose to return
non zero processed bytes over an error. This can help the user to know on
which VMA, passed in the 'struct iovec' vector list, is failed to advise
thus can take the decission of retrying/skipping on that VMA.
This patch (of 2):
The process_madvise() system call returns error even after processing some
VMA's passed in the 'struct iovec' vector list which leaves the user
confused to know where to restart the advise next. It is also against
this syscall man page[1] documentation where it mentions that "return
value may be less than the total number of requested bytes, if an error
occurred after some iovec elements were already processed.".
Consider a user passed 10 VMA's in the 'struct iovec' vector list of which
9 are processed but one. Then it just returns the error caused on that
failed VMA despite the first 9 VMA's processed, leaving the user confused
about on which VMA it is failed. Returning the number of bytes processed
here can help the user to know which VMA it is failed on and thus can
retry/skip the advise on that VMA.
[1]https://man7.org/linux/man-pages/man2/process_madvise.2.html.
Link: https://lkml.kernel.org/r/cover.1647008754.git.quic_charante@quicinc.com
Link: https://lkml.kernel.org/r/125b61a0edcee5c2db8658aed9d06a43a19ccafc.1647008754.git.quic_charante@quicinc.com
Fixes: ecb8ac8b1f14("mm/madvise: introduce process_madvise() syscall: an external memory hinting API")
Signed-off-by: Charan Teja Kalla <quic_charante@quicinc.com>
Cc: Suren Baghdasaryan <surenb@google.com>
Cc: Vlastimil Babka <vbabka@suse.cz>
Cc: David Rientjes <rientjes@google.com>
Cc: Stephen Rothwell <sfr@canb.auug.org.au>
Cc: Minchan Kim <minchan@kernel.org>
Cc: Nadav Amit <nadav.amit@gmail.com>
Cc: Michal Hocko <mhocko@suse.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: UtsavBalar1231 <utsavbalar1231@gmail.com>
Change-Id: Id743a28f41e28f4867bb5265be6ae7ef58bbc394
Signed-off-by: azrim <mirzaspc@gmail.com>
The CPU idle driver's hrtimers need to be able to wake CPUs up from their
C-states using a timer interrupt. This doesn't work if the hrtimers are
instead queued into soft IRQ and run from there, so make them expire in
hard IRQ.
Signed-off-by: Sultan Alsawaf <sultan@kerneltoast.com>
Signed-off-by: Kazuki Hashimoto <kazukih@tuta.io>
Signed-off-by: azrim <mirzaspc@gmail.com>
