Fix the position of the trace point.
Bug: 241946090
Fixes: 737a5314c9 ("ANDROID: power: Add vendor hook for suspend")
Signed-off-by: Ziyi Cui <ziyic@google.com>
Change-Id: I8bf231ee35e0c0ebcb35722f4c527ab61116901e
To avoid changing the visibiliy of data types when including
hook definition headers remove header file inclusions from
the hook definition header files.
Instead, the hook definition headers should just have forward
declarations that don't require full definition.
To provide full definitions of the types for the KMI, the
headers that define the types should be included by the
source file that instantiates the hooks - normally
vendor_hooks.c.
Since the KMI is frozen, some of the inclusions are still
required to preserve the CRC associated with symbols. Keep
these inclusions under #ifdef __GENKSYMS__.
This patch results in 17 fewer opaque types in the KMI
(80 vs 97). Of the remaining 80 opaque types, 50 are
defined in C files (and therefore are truly opaque and
cannot be used by vendor modules). That leaves 30
types that still need definition in the KMI.
Bug: 233047575
Signed-off-by: Todd Kjos <tkjos@google.com>
Change-Id: Ibc1173eb4b07fcec21c7abd8e0ab1950b3fb5b34
Remove the obsolete use of CONFIG_TRACEPOINTS in hook definition
header files. The !CONFIG_TRACEPOINTS case is correctly handled
by the included trace header files.
Bug: 233047575
Signed-off-by: Todd Kjos <tkjos@google.com>
Change-Id: I957649bcfef375284f2885cf732ff2960c303837
commit 353f7988dd upstream.
When the pipe is closed, we mark the associated watchqueue defunct by
calling watch_queue_clear(). However, while that is protected by the
watchqueue lock, new watchqueue entries aren't actually added under that
lock at all: they use the pipe->rd_wait.lock instead, and looking up
that pipe happens without any locking.
The watchqueue code uses the RCU read-side section to make sure that the
wqueue entry itself hasn't disappeared, but that does not protect the
pipe_info in any way.
So make sure to actually hold the wqueue lock when posting watch events,
properly serializing against the pipe being torn down.
Bug: 235277737
Reported-by: Noam Rathaus <noamr@ssd-disclosure.com>
Cc: Greg KH <gregkh@linuxfoundation.org>
Cc: David Howells <dhowells@redhat.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Lee Jones <joneslee@google.com>
Change-Id: I42b0d56021be1d8950c3642ae0acc5cdccadb394
1 symbol(s) added
'void __bitmap_xor(unsigned long int *, const unsigned long int *, const unsigned long int *, unsigned int)'
Bug: 228779790
Signed-off-by: Jack Diver <diverj@google.com>
Change-Id: Ia7622941d313214eaf1aaf26aba64e0e149fa7ca
UFS devices are expected to clear fDeviceInit flag in single digit
milliseconds. Current values of 5 to 10 millisecond sleep add to increased
latency during the initialization and resume path. This CL lowers the sleep
range to 500 to 1000 microseconds.
Bug: 236993021
Link: https://lore.kernel.org/r/20220421002429.3136933-1-bvanassche@acm.org
Acked-by: Avri Altman <avri.altman@wdc.com>
Signed-off-by: Konstantin Vyshetsky <vkon@google.com>
Signed-off-by: Bart Van Assche <bvanassche@acm.org>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
(cherry picked from commit a4e6496fca)
Change-Id: I3a9a01853e89ea73ff5e355007db4730fa853ea0
This patch increases the threshold that limits the reserved root space from 0.2%
to 12.5% by using simple shift operation.
Typically Android sets 128MB, but if the storage capacity is 32GB, 0.2% which is
around 64MB becomes too small. Let's relax it.
Bug: 243493735
Cc: stable@vger.kernel.org
Reported-by: Aran Dalton <arda@allwinnertech.com>
Signed-off-by: Jaegeuk Kim <jaegeuk@kernel.org>
Change-Id: Ia76ae8f9dd1c7a5f123a561f081bf5a4a29ac186
(cherry picked from commit cf42f1d7ab33ea2637f3c6b786a76302f719726b
https://git.kernel.org/pub/scm/linux/kernel/git/jaegeuk/f2fs.git dev)
Now decompression is being handled in workqueue and it makes read I/O
latency non-deterministic, because of the non-deterministic scheduling
nature of workqueues. So, I made it handled in softirq context only if
possible, not in low memory devices, since this modification will
maintain decompresion related memory a little longer.
Bug: 232003054
Signed-off-by: Daeho Jeong <daehojeong@google.com>
Reviewed-by: Chao Yu <chao@kernel.org>
Signed-off-by: Jaegeuk Kim <jaegeuk@kernel.org>
Change-Id: I1a7c642e05c2f8544d475039b733403181de641e
(cherry picked from commit 9ef8cd45d7)
Introduce memory mode to supports "normal" and "low" memory modes.
"low" mode is to support low memory devices. Because of the nature of
low memory devices, in this mode, f2fs will try to save memory sometimes
by sacrificing performance. "normal" mode is the default mode and same
as before.
Bug: 232003054
Signed-off-by: Daeho Jeong <daehojeong@google.com>
Signed-off-by: Jaegeuk Kim <jaegeuk@kernel.org>
(cherry picked from commit 60f60d1fd8)
Change-Id: I7cb719b18f0002d7af47f7a18e8ec2f4c534bdd9
This reverts commit 6c997d153d.
The symbols exported by it were never used by any external modules, so
remove the unneeded exports.
Bug: 203756332
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
Change-Id: I338313c0c2ad1ec83f452db910a6ef9b5ee32b7d
This reverts commit a719abf031.
The symbol exported was never used by any external modules, so remove
the unneeded export.
Bug: 158067689
Bug: 203756332
Cc: Abhilasha Rao <abhilasha.hv@samsung.corp-partner.google.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
Change-Id: I13b65fd0620faf08784dabc7130f199dfa5cf053
This reverts most of commit 292f430816.
Only a small number of the original hooks in this commit were ever used,
so remove all of the unused ones. The hooks removed are:
android_rvh_try_to_wake_up
android_rvh_try_to_wake_up_success
android_rvh_wake_up_new_task
android_rvh_new_task_stats
android_rvh_flush_task
android_rvh_tick_entry
android_rvh_schedule
android_rvh_sched_cpu_starting
android_rvh_sched_cpu_dying
android_rvh_account_irq
android_rvh_place_entity
android_rvh_update_cpu_capacity
android_rvh_update_misfit_status
If these are needed by any real user, it can easily be reverted to add it
back and then the symbols must be added to the abi list at the same time
to prevent it from being removed again later.
Bug: 203756332
Bug: 173725277
Cc: Shaleen Agrawal <shalagra@codeaurora.org>
Cc: Pavankumar Kondeti <pkondeti@codeaurora.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
Change-Id: Icc24ed128fe1034ad663b749caa3bc2e2d0efac0
'allnoconfig' builds failed with:
kernel/sched/sched.h:1203:50: error: ‘struct rq’ has no member named ‘cpu’
rq->cpu needs to be replaced with cpu_of(rq) for !CONFIG_SMP builds
Fixes: 4442801a43 ("ANDROID: sched: Introducing PELT multiplier")
Signed-off-by: Todd Kjos <tkjos@google.com>
Change-Id: Iceb439dc3bba27516b5ecd2c18c9835c23e5a39a
The new sysctl sched_pelt_multiplier allows a user to set a clock
multiplier x2 or x4 (x1 being the default). This clock multiplier
artificially speed-up PELT ramp up/down similarly to a faster half-life.
Indeed, if we write PELT as a first order filter:
y(t) = G * (1 - exp(t/tau))
Then we can see that multiplying the time by a constant X, is the same
as
dividing the time constant tau by X.
y(t) = G * (1 - exp((t*X)/tau))
y(t) = G * (1 - exp(t/(tau/X)))
Tau being half-life*ln(2), multiplying the PELT time is the same as
dividing the half-life:
- x1: 32ms half-life
- x2: 16ms half-life
- x4: 8ms half-life
Internally, a new clock is created: rq->clock_task_mult. It sits in the
clock hierarchy between rq->clock_task and rq->clock_pelt.
Bug: 177593580
Bug: 237219700
Change-Id: I67e6ca7994bebea22bf75732ee11d2b10e0d6b7e
Suggested-by: Morten Rasmussen <morten.rasmussen@arm.com>
Signed-off-by: Vincent Donnefort <vincent.donnefort@arm.com>
Signed-off-by: JianMin Liu <jian-min.liu@mediatek.com>
(cherry picked from commit 4442801a43)
This reverts commit 74555f3992.
The hook android_vh_is_fpsimd_save is not used by any vendor, so remove
it to help with merge issues with future LTS releases.
If this is needed by any real user, it can easily be reverted to add it
back and then the symbol should be added to the abi list at the same
time to prevent it from being removed again later.
Bug: 203756332
Bug: 149632552
Cc: Wooyeon Kim <wooy88.kim@samsung.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
Change-Id: Idecd20a8791c5e4497f8d2222cc54cc42b2ebdff
This reverts commit e909fe79d2.
The symbols exported in it were never used by any external modules, so
remove the exports as they are not needed.
Bug: 203756332
Bug: 140294230
Cc: Sudarshan Rajagopalan <sudaraja@codeaurora.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
Change-Id: Ib3315ba129773256398a71ffe4c3acb55075b012
The purpose of these symbols are used for getting counter and metrics of long running irq. Currently we only have symbols for irq_handler_entry and irq_handler_exit.
Bug: 227809911
Signed-off-by: Ziyi Cui <ziyic@google.com>
Change-Id: Idf4ccdede5232689b2752283539aee54a5f67866
This change ensures that all nested XFRM packets have their policy
checked before decryption of the next layer, so that policies are
verified at each intermediate step of the decryption process.
Notably, raw ESP/AH packets do not perform policy checks inherently,
whereas all other encapsulated packets (UDP, TCP encapsulated) do policy
checks after calling xfrm_input handling in the respective encapsulation
layer.
This is necessary especially for nested tunnels, as the IP addresses,
protocol and ports may all change, thus not matching the previous
policies. In order to ensure that packets match the relevant inbound
templates, the xfrm_policy_check should be done before handing off to
the inner XFRM protocol to decrypt and decapsulate.
In order to prevent double-checking packets both here and in the
encapsulation layers, this check is currently limited to nested
tunnel-mode transforms and checked prior to decapsulation of inner
tunnel layers (prior to hitting a nested tunnel's xfrm_input, there
is no great way to detect a nested tunnel). This is primarily a
performance consideration, as a general blanket check at the end of
xfrm_input would suffice, but may result in multiple policy checks.
Bug: 236423446
Test: Tested against Android Kernel Unit Tests
Link: https://lore.kernel.org/netdev/20220824221252.4130836-3-benedictwong@google.com/
Signed-off-by: Benedict Wong <benedictwong@google.com>
Change-Id: I20c5abf39512d7f6cf438c0921a78a84e281b4e9
This change fixes a bug where inbound packets to nested IPsec tunnels
fails to pass policy checks due to the inner tunnel's policy checks
not having a reference to the outer policy/template. This causes the
policy check to fail, since the first entries in the secpath correlate
to the outer tunnel, while the templates being verified are for the
inner tunnel.
In order to ensure that the appropriate policy and template context is
searchable, the policy checks must be done incrementally between each
decryption step. As such, this marks secpath entries as having been
successfully matched, skipping them (treating as optional) on subsequent
policy checks
By skipping the immediate error return in the case where the secpath
entry had previously been validated, this change allows secpath entries
that matched a policy/template previously, while still requiring that
each searched template find a match in the secpath.
For security:
- All templates must have matching secpath entries
- Unchanged by current patch; templates that do not match any secpath
entry still return -1. This patch simply allows skipping earlier
blocks of verified secpath entries
- All entries (except trailing transport mode entries) must have a
matching template
- Unvalidated entries, including transport-mode entries still return
the errored index if it does not match the correct template.
Bug: 236423446
Test: Tested against Android Kernel Unit Tests
Link: https://lore.kernel.org/netdev/20220824221252.4130836-2-benedictwong@google.com/
[benedictwong: fixed minor style issues]
Signed-off-by: Benedict Wong <benedictwong@google.com>
Change-Id: Ic32831cb00151d0de2e465f18ec37d5f7b680e54
This reverts commit 444a0b7752.
The hook android_vh_vmpressure is not used by any vendor, so remove it
to help with merge issues with future LTS releases.
If this is needed by any real user, it can easily be reverted to add it
back and then the symbol should be added to the abi list at the same
time to prevent it from being removed again later.
Bug: 203756332
Bug: 191534577
Cc: Liangliang Li <liliangliang@vivo.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
Change-Id: I63d2a210dc6a6ded20ea8779af719d70f368ce0f
This reverts commit 4d63efb9ae.
The hooks android_vh_set_module_permit_before_init and
android_vh_set_module_permit_after_init is not used by any vendor, so
remove it to help with merge issues with future LTS releases.
If this is needed by any real user, it can easily be reverted to add it
back and then the symbol should be added to the abi list at the same
time to prevent it from being removed again later.
Bug: 203756332
Bug: 181639260
Cc: Kuan-Ying Lee <Kuan-Ying.Lee@mediatek.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
Change-Id: I3bbc5d4190d9fbf34469d2c5c1386dcbf998fb4b
The rmap locks(i_mmap_rwsem and anon_vma->root->rwsem) could be contended
under memory pressure if processes keep working on their vmas(e.g., fork,
mmap, munmap). It makes reclaim path stuck. In our real workload traces,
we see kswapd is waiting the lock for 300ms+(worst case, a sec) and it
makes other processes entering direct reclaim, which were also stuck on
the lock.
This patch makes lru aging path try_lock mode like shink_page_list so the
reclaim context will keep working with next lru pages without being stuck.
if it found the rmap lock contended, it rotates the page back to head of
lru in both active/inactive lrus to make them consistent behavior, which
is basic starting point rather than adding more heristic.
Since this patch introduces a new "contended" field as out-param along
with try_lock in-param in rmap_walk_control, it's not immutable any longer
if the try_lock is set so remove const keywords on rmap related functions.
Since rmap walking is already expensive operation, I doubt the const
would help sizable benefit( And we didn't have it until 5.17).
In a heavy app workload in Android, trace shows following statistics. It
almost removes rmap lock contention from reclaim path.
Martin Liu reported:
Before:
max_dur(ms) min_dur(ms) max-min(dur)ms avg_dur(ms) sum_dur(ms) count blocked_function
1632 0 1631 151.542173 31672 209 page_lock_anon_vma_read
601 0 601 145.544681 28817 198 rmap_walk_file
After:
max_dur(ms) min_dur(ms) max-min(dur)ms avg_dur(ms) sum_dur(ms) count blocked_function
NaN NaN NaN NaN NaN 0.0 NaN
0 0 0 0.127645 1 12 rmap_walk_file
[minchan@kernel.org: add comment, per Matthew]
Link: https://lkml.kernel.org/r/YnNqeB5tUf6LZ57b@google.com
Link: https://lkml.kernel.org/r/20220510215423.164547-1-minchan@kernel.org
Signed-off-by: Minchan Kim <minchan@kernel.org>
Acked-by: Johannes Weiner <hannes@cmpxchg.org>
Cc: Suren Baghdasaryan <surenb@google.com>
Cc: Michal Hocko <mhocko@suse.com>
Cc: John Dias <joaodias@google.com>
Cc: Tim Murray <timmurray@google.com>
Cc: Matthew Wilcox <willy@infradead.org>
Cc: Vladimir Davydov <vdavydov.dev@gmail.com>
Cc: Martin Liu <liumartin@google.com>
Cc: Minchan Kim <minchan@kernel.org>
Cc: Matthew Wilcox <willy@infradead.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Conflicts:
folio->page
(cherry picked from commit 6d4675e601)
Bug: 239681156
Signed-off-by: Minchan Kim <minchan@google.com>
Change-Id: I0c63e0291120c8a1b5f2d83b8a7b210cb56c27a2
The purpose of this vendor hook is to trace early resume latency.
Bug: 241946090
Signed-off-by: Ziyi Cui <ziyic@google.com>
Change-Id: I508f5a34fd3210178af0cb142461baf814196b9f
Add vendor hook when detecting process status through
pidfd_open.
Bug: 238725692
Change-Id: I565988cb8bf6dd44ab4dc15c410c2dcf50703def
Signed-off-by: xiaofeng <xiaofeng5@xiaomi.com>
If kernel doesn't have CONFIG_F2FS_FS_COMPRESSION, a file having FS_COMPR_FL via
ioctl(FS_IOC_SETFLAGS) is unaccessible due to f2fs_is_compress_backend_ready().
Let's avoid it.
Bug: 240921972
Signed-off-by: Jaegeuk Kim <jaegeuk@kernel.org>
(cherry picked from commit 376523b97c005fa57bb2f8e70f61ab965f16e160)
Change-Id: Ieb0f8945175ea5ccb0060690e882f054360fb8f0
Otherwise, we can get a wrong cp_error mark.
Bug: 239451498
Cc: <stable@vger.kernel.org>
Fixes: a7b8618aa2 ("f2fs: avoid infinite loop to flush node pages")
Signed-off-by: Jaegeuk Kim <jaegeuk@kernel.org>
(cherry picked from commit 1a81f1ba6f9e0e7ab72b32bbd8184892319f1583)
Change-Id: Ic28a139341e96cb6fb0eca9f614895ae14e96946
The patchset in [1] exported some definitions to binder_internal.h in
order to make the debugfs entries such as 'stats' and 'transaction_log'
available in a binderfs instance. However, the DEFINE_SHOW_ATTRIBUTE
macro expands into a static function/variable pair, which in turn get
redefined each time a source file includes this internal header.
This problem was made evident after a report from the kernel test robot
<lkp@intel.com> where several W=1 build warnings are seen in downstream
kernels. See the following example:
include/../drivers/android/binder_internal.h:111:23: warning: 'binder_stats_fops' defined but not used [-Wunused-const-variable=]
111 | DEFINE_SHOW_ATTRIBUTE(binder_stats);
| ^~~~~~~~~~~~
include/linux/seq_file.h:174:37: note: in definition of macro 'DEFINE_SHOW_ATTRIBUTE'
174 | static const struct file_operations __name ## _fops = { \
| ^~~~~~
This patch fixes the above issues by moving back the definitions into
binder.c and instead creates an array of the debugfs entries which is
more convenient to share with binderfs and iterate through.
[1] https://lore.kernel.org/all/20190903161655.107408-1-hridya@google.com/
Fixes: 0e13e452da ("binder: Add stats, state and transactions files")
Fixes: 03e2e07e38 ("binder: Make transaction_log available in binderfs")
Reported-by: kernel test robot <lkp@intel.com>
Signed-off-by: Carlos Llamas <cmllamas@google.com>
Link: https://lore.kernel.org/r/20220701182041.2134313-1-cmllamas@google.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Bug: 240404657
(cherry picked from commit b7e241bbff)
Signed-off-by: Carlos Llamas <cmllamas@google.com>
Change-Id: I7e9ca1ab1f3a5a4a272e50f24d404c17cad55d32
commit b40a6ab2cf upstream.
amdgpu_amdkfd_gpuvm_alloc_memory_of_gpu needs the drm_priv to allow mmap
to access the BO through the corresponding file descriptor. The VM can
also be extracted from drm_priv, so drm_priv can replace the vm parameter
in the kfd2kgd interface.
Bug: 225381233
Signed-off-by: Felix Kuehling <Felix.Kuehling@amd.com>
Reviewed-by: Philip Yang <philip.yang@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
[This is a partial cherry-pick of the upstream commit.]
Signed-off-by: Lee Jones <lee.jones@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Lee Jones <joneslee@google.com>
Change-Id: I49c141ce1727fd5822f0ce09b2dc4887caa65766
commit 9f46c187e2 upstream.
With shadow paging enabled, the INVPCID instruction results in a call
to kvm_mmu_invpcid_gva. If INVPCID is executed with CR0.PG=0, the
invlpg callback is not set and the result is a NULL pointer dereference.
Fix it trivially by checking for mmu->invlpg before every call.
There are other possibilities:
- check for CR0.PG, because KVM (like all Intel processors after P5)
flushes guest TLB on CR0.PG changes so that INVPCID/INVLPG are a
nop with paging disabled
- check for EFER.LMA, because KVM syncs and flushes when switching
MMU contexts outside of 64-bit mode
All of these are tricky, go for the simple solution. This is CVE-2022-1789.
Bug: 235691682
Reported-by: Yongkang Jia <kangel@zju.edu.cn>
Cc: stable@vger.kernel.org
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
[fix conflict due to missing b9e5603c2a]
Signed-off-by: Vegard Nossum <vegard.nossum@oracle.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Lee Jones <joneslee@google.com>
Change-Id: If558163c4ddd4606274b456324278ed3fb5b093c
