aosp/2215503 remove inclusions from hook definition headers
and build breakage detected on pixel device.
include/trace/hooks/mm.h:80:40: error: declaration of 'struct vm_unmapped_area_info' will not be visible outside of this function
Fix this by adding struct vm_unmapped_area_info forward declaration.
Fixes: 7108d9d0e5 ("ANDROID: remove inclusions from hook definition headers")
Bug: 233047575
Signed-off-by: Robin Peng <robinpeng@google.com>
Change-Id: I8989ba78977a26e13c79f9efb156bf8317c1010e
commit 4caae58406 upstream.
The device-mapper framework provides a mechanism to mark targets as
immutable (and hence fail table reloads that try to change the target
type). Add the DM_TARGET_IMMUTABLE flag to the dm-verity target's
feature flags to prevent switching the verity target with a different
target type.
Bug: 234475629
Fixes: a4ffc15219 ("dm: add verity target")
Cc: stable@vger.kernel.org
Signed-off-by: Sarthak Kukreti <sarthakkukreti@google.com>
Reviewed-by: Kees Cook <keescook@chromium.org>
Signed-off-by: Mike Snitzer <snitzer@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Lee Jones <joneslee@google.com>
Change-Id: Iaeec7fa3be98a646062439e4551f84242dacfb45
commit 189b0ddc24 upstream.
pipe_resize_ring() needs to take the pipe->rd_wait.lock spinlock to
prevent post_one_notification() from trying to insert into the ring
whilst the ring is being replaced.
The occupancy check must be done after the lock is taken, and the lock
must be taken after the new ring is allocated.
The bug can lead to an oops looking something like:
BUG: KASAN: use-after-free in post_one_notification.isra.0+0x62e/0x840
Read of size 4 at addr ffff88801cc72a70 by task poc/27196
...
Call Trace:
post_one_notification.isra.0+0x62e/0x840
__post_watch_notification+0x3b7/0x650
key_create_or_update+0xb8b/0xd20
__do_sys_add_key+0x175/0x340
__x64_sys_add_key+0xbe/0x140
do_syscall_64+0x5c/0xc0
entry_SYSCALL_64_after_hwframe+0x44/0xae
Reported by Selim Enes Karaduman @Enesdex working with Trend Micro Zero
Day Initiative.
Bug: 244395411
Fixes: c73be61ced ("pipe: Add general notification queue support")
Reported-by: zdi-disclosures@trendmicro.com # ZDI-CAN-17291
Signed-off-by: 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: I129164eb9dba557d5a4370f4eca124b9916774a6
commit fee060cd52 upstream.
Whenever x86_decode_emulated_instruction() detects a breakpoint, it
returns the value that kvm_vcpu_check_breakpoint() writes into its
pass-by-reference second argument. Unfortunately this is completely
bogus because the expected outcome of x86_decode_emulated_instruction
is an EMULATION_* value.
Then, if kvm_vcpu_check_breakpoint() does "*r = 0" (corresponding to
a KVM_EXIT_DEBUG userspace exit), it is misunderstood as EMULATION_OK
and x86_emulate_instruction() is called without having decoded the
instruction. This causes various havoc from running with a stale
emulation context.
The fix is to move the call to kvm_vcpu_check_breakpoint() where it was
before commit 4aa2691dcb ("KVM: x86: Factor out x86 instruction
emulation with decoding") introduced x86_decode_emulated_instruction().
The other caller of the function does not need breakpoint checks,
because it is invoked as part of a vmexit and the processor has already
checked those before executing the instruction that #GP'd.
This fixes CVE-2022-1852.
Bug: 235183128
Reported-by: Qiuhao Li <qiuhao@sysec.org>
Reported-by: Gaoning Pan <pgn@zju.edu.cn>
Reported-by: Yongkang Jia <kangel@zju.edu.cn>
Fixes: 4aa2691dcb ("KVM: x86: Factor out x86 instruction emulation with decoding")
Cc: stable@vger.kernel.org
Signed-off-by: Sean Christopherson <seanjc@google.com>
Message-Id: <20220311032801.3467418-2-seanjc@google.com>
[Rewrote commit message according to Qiuhao's report, since a patch
already existed to fix the bug. - Paolo]
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Lee Jones <joneslee@google.com>
Change-Id: I3acbb7fc23566c4108f15960c420384af52c2703
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
