Add hook to get cpufreq policy data after registering and unregistering
cpufreq thermal for platform thermal requirement.
Bug: 228423762
Signed-off-by: Jeson Gao <jeson.gao@unisoc.com>
Signed-off-by: Di Shen <di.shen@unisoc.com>
Change-Id: I9c6bc88f348f252c428560427bd8bca91092edfa
(cherry picked from commit fbe6f8708d)
Kfence only needs its pool to be mapped as page granularity, if it is
inited early. Previous judgement was a bit over protected. From [1], Mark
suggested to "just map the KFENCE region a page granularity". So I
decouple it from judgement and do page granularity mapping for kfence
pool only. Need to be noticed that late init of kfence pool still requires
page granularity mapping.
Page granularity mapping in theory cost more(2M per 1GB) memory on arm64
platform. Like what I've tested on QEMU(emulated 1GB RAM) with
gki_defconfig, also turning off rodata protection:
Before:
[root@liebao ]# cat /proc/meminfo
MemTotal: 999484 kB
After:
[root@liebao ]# cat /proc/meminfo
MemTotal: 1001480 kB
To implement this, also relocate the kfence pool allocation before the
linear mapping setting up, arm64_kfence_alloc_pool is to allocate phys
addr, __kfence_pool is to be set after linear mapping set up.
LINK: [1] https://lore.kernel.org/linux-arm-kernel/Y+IsdrvDNILA59UN@FVFF77S0Q05N/
Suggested-by: Mark Rutland <mark.rutland@arm.com>
Signed-off-by: Zhenhua Huang <quic_zhenhuah@quicinc.com>
Reviewed-by: Kefeng Wang <wangkefeng.wang@huawei.com>
Reviewed-by: Marco Elver <elver@google.com>
Link: https://lore.kernel.org/r/1679066974-690-1-git-send-email-quic_zhenhuah@quicinc.com
Signed-off-by: Will Deacon <will@kernel.org>
BUG: 284812202
Change-Id: I8e7c565d3f4d6349a028a6a060259d62cf5beee7
(cherry picked from commit bfa7965b33)
Signed-off-by: Zhenhua Huang <quic_zhenhuah@quicinc.com>
commit 1007843a91 upstream.
syzbot is reporting circular locking dependency which involves
zonelist_update_seq seqlock [1], for this lock is checked by memory
allocation requests which do not need to be retried.
One deadlock scenario is kmalloc(GFP_ATOMIC) from an interrupt handler.
CPU0
----
__build_all_zonelists() {
write_seqlock(&zonelist_update_seq); // makes zonelist_update_seq.seqcount odd
// e.g. timer interrupt handler runs at this moment
some_timer_func() {
kmalloc(GFP_ATOMIC) {
__alloc_pages_slowpath() {
read_seqbegin(&zonelist_update_seq) {
// spins forever because zonelist_update_seq.seqcount is odd
}
}
}
}
// e.g. timer interrupt handler finishes
write_sequnlock(&zonelist_update_seq); // makes zonelist_update_seq.seqcount even
}
This deadlock scenario can be easily eliminated by not calling
read_seqbegin(&zonelist_update_seq) from !__GFP_DIRECT_RECLAIM allocation
requests, for retry is applicable to only __GFP_DIRECT_RECLAIM allocation
requests. But Michal Hocko does not know whether we should go with this
approach.
Another deadlock scenario which syzbot is reporting is a race between
kmalloc(GFP_ATOMIC) from tty_insert_flip_string_and_push_buffer() with
port->lock held and printk() from __build_all_zonelists() with
zonelist_update_seq held.
CPU0 CPU1
---- ----
pty_write() {
tty_insert_flip_string_and_push_buffer() {
__build_all_zonelists() {
write_seqlock(&zonelist_update_seq);
build_zonelists() {
printk() {
vprintk() {
vprintk_default() {
vprintk_emit() {
console_unlock() {
console_flush_all() {
console_emit_next_record() {
con->write() = serial8250_console_write() {
spin_lock_irqsave(&port->lock, flags);
tty_insert_flip_string() {
tty_insert_flip_string_fixed_flag() {
__tty_buffer_request_room() {
tty_buffer_alloc() {
kmalloc(GFP_ATOMIC | __GFP_NOWARN) {
__alloc_pages_slowpath() {
zonelist_iter_begin() {
read_seqbegin(&zonelist_update_seq); // spins forever because zonelist_update_seq.seqcount is odd
spin_lock_irqsave(&port->lock, flags); // spins forever because port->lock is held
}
}
}
}
}
}
}
}
spin_unlock_irqrestore(&port->lock, flags);
// message is printed to console
spin_unlock_irqrestore(&port->lock, flags);
}
}
}
}
}
}
}
}
}
write_sequnlock(&zonelist_update_seq);
}
}
}
This deadlock scenario can be eliminated by
preventing interrupt context from calling kmalloc(GFP_ATOMIC)
and
preventing printk() from calling console_flush_all()
while zonelist_update_seq.seqcount is odd.
Since Petr Mladek thinks that __build_all_zonelists() can become a
candidate for deferring printk() [2], let's address this problem by
disabling local interrupts in order to avoid kmalloc(GFP_ATOMIC)
and
disabling synchronous printk() in order to avoid console_flush_all()
.
As a side effect of minimizing duration of zonelist_update_seq.seqcount
being odd by disabling synchronous printk(), latency at
read_seqbegin(&zonelist_update_seq) for both !__GFP_DIRECT_RECLAIM and
__GFP_DIRECT_RECLAIM allocation requests will be reduced. Although, from
lockdep perspective, not calling read_seqbegin(&zonelist_update_seq) (i.e.
do not record unnecessary locking dependency) from interrupt context is
still preferable, even if we don't allow calling kmalloc(GFP_ATOMIC)
inside
write_seqlock(&zonelist_update_seq)/write_sequnlock(&zonelist_update_seq)
section...
Link: https://lkml.kernel.org/r/8796b95c-3da3-5885-fddd-6ef55f30e4d3@I-love.SAKURA.ne.jp
Fixes: 3d36424b3b ("mm/page_alloc: fix race condition between build_all_zonelists and page allocation")
Link: https://lkml.kernel.org/r/ZCrs+1cDqPWTDFNM@alley [2]
Reported-by: syzbot <syzbot+223c7461c58c58a4cb10@syzkaller.appspotmail.com>
Link: https://syzkaller.appspot.com/bug?extid=223c7461c58c58a4cb10 [1]
Change-Id: Ifc0c6ed9be6d36166367811ad412bedc66ed713e
Signed-off-by: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
Acked-by: Michal Hocko <mhocko@suse.com>
Acked-by: Mel Gorman <mgorman@techsingularity.net>
Cc: Petr Mladek <pmladek@suse.com>
Cc: David Hildenbrand <david@redhat.com>
Cc: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Cc: John Ogness <john.ogness@linutronix.de>
Cc: Patrick Daly <quic_pdaly@quicinc.com>
Cc: Sergey Senozhatsky <senozhatsky@chromium.org>
Cc: Steven Rostedt <rostedt@goodmis.org>
Cc: <stable@vger.kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
(cherry picked from commit b528537d13)
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
commit 4d73ba5fa7 upstream.
A bug was reported by Yuanxi Liu where allocating 1G pages at runtime is
taking an excessive amount of time for large amounts of memory. Further
testing allocating huge pages that the cost is linear i.e. if allocating
1G pages in batches of 10 then the time to allocate nr_hugepages from
10->20->30->etc increases linearly even though 10 pages are allocated at
each step. Profiles indicated that much of the time is spent checking the
validity within already existing huge pages and then attempting a
migration that fails after isolating the range, draining pages and a whole
lot of other useless work.
Commit eb14d4eefd ("mm,page_alloc: drop unnecessary checks from
pfn_range_valid_contig") removed two checks, one which ignored huge pages
for contiguous allocations as huge pages can sometimes migrate. While
there may be value on migrating a 2M page to satisfy a 1G allocation, it's
potentially expensive if the 1G allocation fails and it's pointless to try
moving a 1G page for a new 1G allocation or scan the tail pages for valid
PFNs.
Reintroduce the PageHuge check and assume any contiguous region with
hugetlbfs pages is unsuitable for a new 1G allocation.
The hpagealloc test allocates huge pages in batches and reports the
average latency per page over time. This test happens just after boot
when fragmentation is not an issue. Units are in milliseconds.
hpagealloc
6.3.0-rc6 6.3.0-rc6 6.3.0-rc6
vanilla hugeallocrevert-v1r1 hugeallocsimple-v1r2
Min Latency 26.42 ( 0.00%) 5.07 ( 80.82%) 18.94 ( 28.30%)
1st-qrtle Latency 356.61 ( 0.00%) 5.34 ( 98.50%) 19.85 ( 94.43%)
2nd-qrtle Latency 697.26 ( 0.00%) 5.47 ( 99.22%) 20.44 ( 97.07%)
3rd-qrtle Latency 972.94 ( 0.00%) 5.50 ( 99.43%) 20.81 ( 97.86%)
Max-1 Latency 26.42 ( 0.00%) 5.07 ( 80.82%) 18.94 ( 28.30%)
Max-5 Latency 82.14 ( 0.00%) 5.11 ( 93.78%) 19.31 ( 76.49%)
Max-10 Latency 150.54 ( 0.00%) 5.20 ( 96.55%) 19.43 ( 87.09%)
Max-90 Latency 1164.45 ( 0.00%) 5.53 ( 99.52%) 20.97 ( 98.20%)
Max-95 Latency 1223.06 ( 0.00%) 5.55 ( 99.55%) 21.06 ( 98.28%)
Max-99 Latency 1278.67 ( 0.00%) 5.57 ( 99.56%) 22.56 ( 98.24%)
Max Latency 1310.90 ( 0.00%) 8.06 ( 99.39%) 26.62 ( 97.97%)
Amean Latency 678.36 ( 0.00%) 5.44 * 99.20%* 20.44 * 96.99%*
6.3.0-rc6 6.3.0-rc6 6.3.0-rc6
vanilla revert-v1 hugeallocfix-v2
Duration User 0.28 0.27 0.30
Duration System 808.66 17.77 35.99
Duration Elapsed 830.87 18.08 36.33
The vanilla kernel is poor, taking up to 1.3 second to allocate a huge
page and almost 10 minutes in total to run the test. Reverting the
problematic commit reduces it to 8ms at worst and the patch takes 26ms.
This patch fixes the main issue with skipping huge pages but leaves the
page_count() out because a page with an elevated count potentially can
migrate.
BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=217022
Link: https://lkml.kernel.org/r/20230414141429.pwgieuwluxwez3rj@techsingularity.net
Fixes: eb14d4eefd ("mm,page_alloc: drop unnecessary checks from pfn_range_valid_contig")
Change-Id: I552f0631f15e41038219e207c994fa7702b269fa
Signed-off-by: Mel Gorman <mgorman@techsingularity.net>
Reported-by: Yuanxi Liu <y.liu@naruida.com>
Acked-by: Vlastimil Babka <vbabka@suse.cz>
Reviewed-by: David Hildenbrand <david@redhat.com>
Acked-by: Michal Hocko <mhocko@suse.com>
Reviewed-by: Oscar Salvador <osalvador@suse.de>
Cc: Matthew Wilcox <willy@infradead.org>
Cc: <stable@vger.kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
(cherry picked from commit 059f24aff6)
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
While exercising the unbind path, with the current implementation
the functionfs_unbind would be calling which waits for the ffs->mutex
to be available, however within the same time ffs_ep0_read is invoked
& if no setup packets are pending, it will invoke function
wait_event_interruptible_exclusive_locked_irq which by definition waits
for the ev.count to be increased inside the same mutex for which
functionfs_unbind is waiting.
This creates deadlock situation because the functionfs_unbind won't
get the lock until ev.count is increased which can only happen if
the caller ffs_func_unbind can proceed further.
Following is the illustration:
CPU1 CPU2
ffs_func_unbind() ffs_ep0_read()
mutex_lock(ffs->mutex)
wait_event(ffs->ev.count)
functionfs_unbind()
mutex_lock(ffs->mutex)
mutex_unlock(ffs->mutex)
ffs_event_add()
<deadlock>
Fix this by moving the event unbind before functionfs_unbind
to ensure the ev.count is incrased properly.
Fixes: 6a19da1110 ("usb: gadget: f_fs: Prevent race during ffs_ep0_queue_wait")
Cc: stable <stable@kernel.org>
Signed-off-by: Uttkarsh Aggarwal <quic_uaggarwa@quicinc.com>
Link: https://lore.kernel.org/r/20230525092854.7992-1-quic_uaggarwa@quicinc.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Bug: 285072336
(cherry picked from commit efb6b53520)
Change-Id: I1a001606f62f1966825d47809cd1c887e3d6fb71
Signed-off-by: Uttkarsh Aggarwal <quic_uaggarwa@quicinc.com>
This reverts commit b9bb33b73c.
Reason: This patch breaks any USB gadget function that deactivates the
gadget on bind (by setting bind_deactivated = true).
Bug: 285019584
Change-Id: I2885819dd75e9d65de8258b7d2f6fc5d98de6c68
Signed-off-by: Avichal Rakesh <arakesh@google.com>
When servicemanager process added service proxy from other process
register the service, we want to know the matching relation between
handle in the process and service name. When binder transaction
happened, We want to know what process calls what method on what service.
Bug: 186604985
Signed-off-by: zhengding chen <chenzhengding@oppo.com>
Change-Id: I813d1cde10294d8665f899f7fef0d444ec1f1f5e
commit 24bf08c437 upstream.
Looks like what we fixed for hugetlb in commit 44f86392bd ("mm/hugetlb:
fix uffd-wp handling for migration entries in
hugetlb_change_protection()") similarly applies to THP.
Setting/clearing uffd-wp on THP migration entries is not implemented
properly. Further, while removing migration PMDs considers the uffd-wp
bit, inserting migration PMDs does not consider the uffd-wp bit.
We have to set/clear independently of the migration entry type in
change_huge_pmd() and properly copy the uffd-wp bit in
set_pmd_migration_entry().
Verified using a simple reproducer that triggers migration of a THP, that
the set_pmd_migration_entry() no longer loses the uffd-wp bit.
Link: https://lkml.kernel.org/r/20230405160236.587705-2-david@redhat.com
Fixes: f45ec5ff16 ("userfaultfd: wp: support swap and page migration")
Change-Id: I263a9fd8a6695f546fe5c5279a439f4f1c151c48
Signed-off-by: David Hildenbrand <david@redhat.com>
Reviewed-by: Peter Xu <peterx@redhat.com>
Cc: <stable@vger.kernel.org>
Cc: Muhammad Usama Anjum <usama.anjum@collabora.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
(cherry picked from commit cc647e05db)
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
commit dd47ac428c upstream.
Khugepaged collapse an anonymous thp in two rounds of scans. The 2nd
round done in __collapse_huge_page_isolate() after
hpage_collapse_scan_pmd(), during which all the locks will be released
temporarily. It means the pgtable can change during this phase before 2nd
round starts.
It's logically possible some ptes got wr-protected during this phase, and
we can errornously collapse a thp without noticing some ptes are
wr-protected by userfault. e1e267c792 wanted to avoid it but it only
did that for the 1st phase, not the 2nd phase.
Since __collapse_huge_page_isolate() happens after a round of small page
swapins, we don't need to worry on any !present ptes - if it existed
khugepaged will already bail out. So we only need to check present ptes
with uffd-wp bit set there.
This is something I found only but never had a reproducer, I thought it
was one caused a bug in Muhammad's recent pagemap new ioctl work, but it
turns out it's not the cause of that but an userspace bug. However this
seems to still be a real bug even with a very small race window, still
worth to have it fixed and copy stable.
Link: https://lkml.kernel.org/r/20230405155120.3608140-1-peterx@redhat.com
Fixes: e1e267c792 ("khugepaged: skip collapse if uffd-wp detected")
Change-Id: Iab7f0ac5b9b6d055485ca244b2fa1e13f0dbc570
Signed-off-by: Peter Xu <peterx@redhat.com>
Reviewed-by: David Hildenbrand <david@redhat.com>
Reviewed-by: Yang Shi <shy828301@gmail.com>
Cc: Andrea Arcangeli <aarcange@redhat.com>
Cc: Axel Rasmussen <axelrasmussen@google.com>
Cc: Mike Rapoport <rppt@linux.vnet.ibm.com>
Cc: Nadav Amit <nadav.amit@gmail.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
(cherry picked from commit 519dbe737f)
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
commit ccc031e26a upstream.
The previous commit df8629af29 ("fuse: always revalidate if exclusive
create") ensures that the dentries are revalidated on O_EXCL creates. This
commit complements it by also performing revalidation for rename target
dentries. Otherwise, a rename target file that only exists in kernel
dentry cache but not in the filesystem will result in EEXIST if
RENAME_NOREPLACE flag is used.
Change-Id: I3500c168b37469e0fcf5664a3deb4d54e45b926d
Signed-off-by: Jiachen Zhang <zhangjiachen.jaycee@bytedance.com>
Signed-off-by: Zhang Tianci <zhangtianci.1997@bytedance.com>
Signed-off-by: Miklos Szeredi <mszeredi@redhat.com>
Signed-off-by: Yang Bo <yb203166@antfin.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
(cherry picked from commit 7ca973d830)
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
On Android app cycle workloads, MGLRU showed a significant reduction in
workingset refaults although pgpgin/pswpin remained relatively unchanged.
This indicated MGLRU may be undercounting workingset refaults.
This has impact on userspace programs, like Android's LMKD, that monitor
workingset refault statistics to detect thrashing.
It was found that refaults were only accounted if the MGLRU shadow entry
was for a recently evicted folio. However, recently evicted folios should
be accounted as workingset activation, and refaults should be accounted
regardless of recency.
Fix MGLRU's workingset refault and activation accounting to more closely
match that of the conventional active/inactive LRU.
Link: https://lkml.kernel.org/r/20230523205922.3852731-1-kaleshsingh@google.com
Fixes: ac35a49023 ("mm: multi-gen LRU: minimal implementation")
Signed-off-by: Kalesh Singh <kaleshsingh@google.com>
Reported-by: Charan Teja Kalla <quic_charante@quicinc.com>
Acked-by: Yu Zhao <yuzhao@google.com>
Cc: Brian Geffon <bgeffon@google.com>
Cc: Jan Alexander Steffens (heftig) <heftig@archlinux.org>
Cc: Oleksandr Natalenko <oleksandr@natalenko.name>
Cc: Suren Baghdasaryan <surenb@google.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
(cherry picked from commit 02ad728453d2ddb09d7ce5e59854ebb27544d488 https://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm.git mm-unstable)
Bug: 284043217
[ Kalesh Singh - Fix conflicts in mm/workingset.c ]
Signed-off-by: Kalesh Singh <kaleshsingh@google.com>
Change-Id: I6d42cca9064e66099fbbc20aa2143961f84b2003
In dw_pcie_host_init() regardless of whether the link has been
started or not, the code waits for the link to come up. Even in
cases where start_link() is not defined the code ends up spinning
in a loop for 1 second. Since in some systems dw_pcie_host_init()
gets called during probe, this one second loop for each pcie
interface instance ends up extending the boot time.
Wait for the link up in only if the start_link() is defined.
Bug: 270085637
Link: https://lore.kernel.org/r/20230412093425.3659088-1-ajayagarwal@google.com
Tested-by: Will McVicker <willmcvicker@google.com>
Signed-off-by: Sajid Dalvi <sdalvi@google.com>
Signed-off-by: Ajay Agarwal <ajayagarwal@google.com>
Signed-off-by: Lorenzo Pieralisi <lpieralisi@kernel.org>
(cherry picked from commit da56a1bfbahttps://git.kernel.org/pub/scm/linux/kernel/git/pci/pci.git controller/dwc)
[willmcvicker: fixed trivial merge conflicts]
Signed-off-by: Will McVicker <willmcvicker@google.com>
Change-Id: Ia4d9b41b2a15cb077025f6250d8fa07c495a17a9
A vendor hook is added in post_init_entity_util_avg before
a new cfs task's util is attached to cfs_rq's util so that
vendors can gather and modify se's information to modify
scheduling behavior and DVFS as they want.
trace_android_rvh_new_task_stats is not a proper hook because
it is called after the task's util is attached to cfs_rq's util,
which means updating cfs_rq's sched_avg and DVFS request are done.
Bug: 184219858
Signed-off-by: Choonghoon Park <choong.park@samsung.com>
Change-Id: I2deaa93297f8464895978496c9838cdffaa35b7f
(cherry picked from commit 1eea1cbdd3)
Disable CONFIG_ARM64_BTI_KERNEL since significant overhead has been observed
on systems that don't have BTI/PAC hardware support due to increased number
of NOPs added by these features.
BTI is not as important in kernels that have CFI enabled because the protection
these features offer overlap.
Keep PAC enabled and also enable dynamic SCS (CONFIG_UNWIND_PATCH_PAC_INTO_SCS)
which is available starting in v6.2. This removes SCS overhead on systems that
support PAC, and PAC overhead on systems that need SCS instead. This feature uses
runtime code patching, so it won't have the overhead of additional NOPs.
Bug: 267119345
Change-Id: Ifc7d5e502940bd15d13e7f89c5facd10b6c7b8a8
Signed-off-by: Todd Kjos <tkjos@google.com>
Implement dynamic shadow call stack support on Clang, by parsing the
unwind tables at init time to locate all occurrences of PACIASP/AUTIASP
instructions, and replacing them with the shadow call stack push and pop
instructions, respectively.
This is useful because the overhead of the shadow call stack is
difficult to justify on hardware that implements pointer authentication
(PAC), and given that the PAC instructions are executed as NOPs on
hardware that doesn't, we can just replace them without breaking
anything. As PACIASP/AUTIASP are guaranteed to be paired with respect to
manipulations of the return address, replacing them 1:1 with shadow call
stack pushes and pops is guaranteed to result in the desired behavior.
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
Reviewed-by: Sami Tolvanen <samitolvanen@google.com>
Tested-by: Sami Tolvanen <samitolvanen@google.com>
Link: https://lore.kernel.org/r/20221027155908.1940624-4-ardb@kernel.org
Signed-off-by: Will Deacon <will@kernel.org>
(cherry picked from commit 3b619e22c4)
Bug: 283954062
Change-Id: Idca66f03315191a9fb18ed17d5b79c5bfacc51b8
Signed-off-by: Sami Tolvanen <samitolvanen@google.com>
In order to allow arches to use code patching to conditionally emit the
shadow stack pushes and pops, rather than always taking the performance
hit even on CPUs that implement alternatives such as stack pointer
authentication on arm64, add a Kconfig symbol that can be set by the
arch to omit the SCS codegen itself, without otherwise affecting how
support code for SCS and compiler options (for register reservation, for
instance) are emitted.
Also, add a static key and some plumbing to omit the allocation of
shadow call stack for dynamic SCS configurations if SCS is disabled at
runtime.
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
Reviewed-by: Nick Desaulniers <ndesaulniers@google.com>
Reviewed-by: Kees Cook <keescook@chromium.org>
Reviewed-by: Sami Tolvanen <samitolvanen@google.com>
Tested-by: Sami Tolvanen <samitolvanen@google.com>
Link: https://lore.kernel.org/r/20221027155908.1940624-3-ardb@kernel.org
Signed-off-by: Will Deacon <will@kernel.org>
(cherry picked from commit 9beccca098)
Bug: 283954062
Change-Id: I71ed23533124b071bd6bf5ab91b2af3bbf03b42b
Signed-off-by: Sami Tolvanen <samitolvanen@google.com>
Enable asynchronous unwind table generation for both the core kernel as
well as modules, and emit the resulting .eh_frame sections as init code
so we can use the unwind directives for code patching at boot or module
load time.
This will be used by dynamic shadow call stack support, which will rely
on code patching rather than compiler codegen to emit the shadow call
stack push and pop instructions.
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
Reviewed-by: Nick Desaulniers <ndesaulniers@google.com>
Reviewed-by: Sami Tolvanen <samitolvanen@google.com>
Tested-by: Sami Tolvanen <samitolvanen@google.com>
Link: https://lore.kernel.org/r/20221027155908.1940624-2-ardb@kernel.org
Signed-off-by: Will Deacon <will@kernel.org>
(cherry picked from commit 68c76ad4a9)
Bug: 283954062
Change-Id: I2e17c7171295dc3859ff385b11a10048f6c87ec5
Signed-off-by: Sami Tolvanen <samitolvanen@google.com>
Export is_ashmem_file function which will be used
by the minidump module to get ashmem info.
Bug: 193397560
Change-Id: I5b7816ad4775e5cf2c4f41c28b1c8dacc2c85b7e
Signed-off-by: liuhailong <liuhailong@oppo.com>
Signed-off-by: Liujie Xie <xieliujie@oppo.com>
(cherry picked from commit 7bcfde2601)
(cherry picked from commit 77064627fb)
Add vendors hooks for recording memory used
Vendor modules allocate and manages the memory itself.
These memories might not be included in kernel memory
statistics. Also, detailed references and vendor-specific
information are managed only inside modules. When
various problems such as memory leaks occurs, these
information should be showed in real-time.
Bug: 182443489
Bug: 234407991
Bug: 277799025
Signed-off-by: Liujie Xie <xieliujie@oppo.com>
Change-Id: I62d8bb2b6650d8b187b433f97eb833ef0b784df1
Signed-off-by: Hyesoo Yu <hyesoo.yu@samsung.com>
Add hooks to init oem data of mutex.
Bug: 231527236
Signed-off-by: Dezhi Huang <huangdezhi@hihonor.com>
Change-Id: Id0aeac168e81bd3d88051657c32ba709c329dbdd
1. android_vh_dm_bufio_shrink_scan_bypass
To adjust dm_bufio-buffer shrinker's policy in some cases.
2. cleanup_old_buffers_bypass
To adjust the policy of dm_bufio-buffer periodic eviction
in some cases.
Bug: 281467813
Signed-off-by: Peifeng Li <lipeifeng@oppo.com>
Change-Id: I29a9d91d18d2e279170533db83b59cfc3b17ebe2
following symbols are added to abi symbol list.
sysfs_update_group
Symbols added:
sysfs_update_group
Bug: 281970901
Change-Id: I045fd322d8ae8d590105351ab19ea25776d4e345
Signed-off-by: Harsh Jain <quic_harshj@quicinc.com>
The hook function: trace_android_vh_do_shrink_slab is added inside
of the function do_shrink_slab() to changed the numbers of page to
be reclaimed from kernel.
Bug: 279793370
Change-Id: I7c0b955be97f841c69bc99a152b59ed9823707ed
Signed-off-by: Dezhi Huang <huangdezhi@hihonor.com>
Trace_android_vh_shrink_slab_bypass is added in the beginning of
the function shrink_slab() to bypass kernel page reclaim in some
conditons.
Bug: 279793370
Change-Id: I6d5c8be28addf43d6fc9d07b5133135641590c3a
Signed-off-by: Dezhi Huang <huangdezhi@hihonor.com>
When work in gadget mode, currently driver doesn't update software level
link_state correctly as link state change event is not enabled for most
devices, in function dwc3_gadget_suspend_interrupt(), it will only pass
suspend event to UDC core when software level link state changes, so when
interrupt generated in sequences of suspend -> reset -> conndone ->
suspend, link state is not updated during reset and conndone, so second
suspend interrupt event will not pass to UDC core.
Remove link_state compare in dwc3_gadget_suspend_interrupt() and add a
suspended flag to replace the compare function.
Fixes: 799e9dc829 ("usb: dwc3: gadget: conditionally disable Link State change events")
Cc: stable <stable@kernel.org>
Acked-by: Thinh Nguyen <Thinh.Nguyen@synopsys.com>
Signed-off-by: Linyu Yuan <quic_linyyuan@quicinc.com>
Link: https://lore.kernel.org/r/20230512004524.31950-1-quic_linyyuan@quicinc.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Bug: 283221152
(cherry picked from commit 4e8ef34e36https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git/ usb-linus)
[prashk: Didn't add suspended flag in dwc3_gadget_func_wakeup() & dwc3_gadget_linksts_change_interrupt()]
Signed-off-by: Prashanth K <quic_prashk@quicinc.com>
Change-Id: Iaaf34456136e873f1ce5a8fa573f40e22873f2c4
Set KMI_GENERATION=7 for 5/24 KMI update
3 function symbol(s) removed
'int mmu_interval_notifier_insert(struct mmu_interval_notifier*, struct mm_struct*, unsigned long, unsigned long, const struct mmu_interval_notifier_ops*)'
'void mmu_interval_notifier_remove(struct mmu_interval_notifier*)'
'unsigned long mmu_interval_read_begin(struct mmu_interval_notifier*)'
function symbol changed from 'int gh_rm_call(struct gh_rm*, u32, void*, size_t, void**, size_t*)' to 'int gh_rm_call(void*, u32, const void*, size_t, void**, size_t*)'
CRC changed from 0xfef4ce1d to 0xaa8c9d60
type changed from 'int(struct gh_rm*, u32, void*, size_t, void**, size_t*)' to 'int(void*, u32, const void*, size_t, void**, size_t*)'
parameter 1 type changed from 'struct gh_rm*' to 'void*'
pointed-to type changed from 'struct gh_rm' to 'void'
parameter 3 type changed from 'void*' to 'const void*'
pointed-to type changed from 'void' to 'const void'
qualifier const added
function symbol changed from 'int gh_rm_notifier_register(struct gh_rm*, struct notifier_block*)' to 'int gh_rm_notifier_register(void*, struct notifier_block*)'
CRC changed from 0x412fac09 to 0xd5a6a3c9
type changed from 'int(struct gh_rm*, struct notifier_block*)' to 'int(void*, struct notifier_block*)'
parameter 1 type changed from 'struct gh_rm*' to 'void*'
pointed-to type changed from 'struct gh_rm' to 'void'
function symbol changed from 'int gh_rm_notifier_unregister(struct gh_rm*, struct notifier_block*)' to 'int gh_rm_notifier_unregister(void*, struct notifier_block*)'
CRC changed from 0xf4d771f8 to 0x2c865d28
type changed from 'int(struct gh_rm*, struct notifier_block*)' to 'int(void*, struct notifier_block*)'
parameter 1 type changed from 'struct gh_rm*' to 'void*'
pointed-to type changed from 'struct gh_rm' to 'void'
function symbol 'int ___pskb_trim(struct sk_buff*, unsigned int)' changed
CRC changed from 0x6c6bbe0a to 0xaf3987c4
function symbol 'struct sk_buff* __alloc_skb(unsigned int, gfp_t, int, int)' changed
CRC changed from 0xd9823116 to 0xa873df72
function symbol 'void __balance_callbacks(struct rq*)' changed
CRC changed from 0x6537022 to 0xec0d081
... 1278 omitted; 1281 symbols have only CRC changes
type 'struct sock' changed
byte size changed from 768 to 776
member 'u64 android_oem_data1' was added
type 'struct freq_qos_request' changed
byte size changed from 56 to 64
member 'u64 android_oem_data1' was added
type 'struct dev_pm_qos_request' changed
byte size changed from 72 to 80
member 'union { struct plist_node pnode; struct pm_qos_flags_request flr; struct freq_qos_request freq; } data' changed
type 'union { struct plist_node pnode; struct pm_qos_flags_request flr; struct freq_qos_request freq; }' changed
byte size changed from 56 to 64
member 'struct device* dev' changed
offset changed by 64
type 'struct devfreq' changed
byte size changed from 1720 to 1736
member 'struct dev_pm_qos_request user_max_freq_req' changed
offset changed by 64
11 members ('unsigned long scaling_min_freq' .. 'struct notifier_block nb_max') changed
offset changed by 128
type 'struct gh_rm_platform_ops' changed
byte size changed from 16 to 48
member changed from 'int(* pre_mem_share)(struct gh_rm*, struct gh_rm_mem_parcel*)' to 'int(* pre_mem_share)(void*, struct gh_rm_mem_parcel*)'
type changed from 'int(*)(struct gh_rm*, struct gh_rm_mem_parcel*)' to 'int(*)(void*, struct gh_rm_mem_parcel*)'
pointed-to type changed from 'int(struct gh_rm*, struct gh_rm_mem_parcel*)' to 'int(void*, struct gh_rm_mem_parcel*)'
parameter 1 type changed from 'struct gh_rm*' to 'void*'
pointed-to type changed from 'struct gh_rm' to 'void'
member changed from 'int(* post_mem_reclaim)(struct gh_rm*, struct gh_rm_mem_parcel*)' to 'int(* post_mem_reclaim)(void*, struct gh_rm_mem_parcel*)'
type changed from 'int(*)(struct gh_rm*, struct gh_rm_mem_parcel*)' to 'int(*)(void*, struct gh_rm_mem_parcel*)'
pointed-to type changed from 'int(struct gh_rm*, struct gh_rm_mem_parcel*)' to 'int(void*, struct gh_rm_mem_parcel*)'
parameter 1 type changed from 'struct gh_rm*' to 'void*'
pointed-to type changed from 'struct gh_rm' to 'void'
member 'u64 android_backport_reserved1' was added
member 'u64 android_backport_reserved2' was added
member 'u64 android_backport_reserved3' was added
member 'u64 android_backport_reserved4' was added
type 'struct nf_conn' changed
byte size changed from 248 to 256
member 'u64 android_oem_data1' was added
type 'struct tipc_sock' changed
byte size changed from 1008 to 1016
31 members ('u32 max_pkt' .. 'u8 conn_addrtype') changed
offset changed by 64
type 'struct vsock_sock' changed
byte size changed from 1224 to 1232
25 members ('const struct vsock_transport* transport' .. 'void* trans') changed
offset changed by 64
type 'struct gh_rm_mem_parcel' changed
byte size changed from 48 to 112
member 'u64 android_backport_reserved1' was added
member 'u64 android_backport_reserved2' was added
member 'u64 android_backport_reserved3' was added
member 'u64 android_backport_reserved4' was added
member 'u64 android_backport_reserved5' was added
member 'u64 android_backport_reserved6' was added
member 'u64 android_backport_reserved7' was added
member 'u64 android_backport_reserved8' was added
type 'struct gh_rm_mem_entry' changed
member '__le64 phys_addr' was added
member '__le64 ipa_base' was removed
Bug: 283322303
Change-Id: I62859d103cd2151a8417a09b639cadc658314263
Signed-off-by: Carlos Llamas <cmllamas@google.com>
Add KABI reservations in KMI-tracked Gunyah structures which aren't part
of the hypervisor ABI itself.
function symbol 'int devm_gh_rm_register_platform_ops(struct device*, struct gh_rm_platform_ops*)' changed
CRC changed from 0x51bb297d to 0x1f3ae551
function symbol 'int gh_rm_register_platform_ops(struct gh_rm_platform_ops*)' changed
CRC changed from 0xf2b08039 to 0xc34a7803
function symbol 'void gh_rm_unregister_platform_ops(struct gh_rm_platform_ops*)' changed
CRC changed from 0x41e9ce79 to 0xc1f09d18
type 'struct gh_rm_platform_ops' changed
byte size changed from 16 to 48
member 'u64 android_backport_reserved1' was added
member 'u64 android_backport_reserved2' was added
member 'u64 android_backport_reserved3' was added
member 'u64 android_backport_reserved4' was added
type 'struct gh_rm_mem_parcel' changed
byte size changed from 48 to 112
member 'u64 android_backport_reserved1' was added
member 'u64 android_backport_reserved2' was added
member 'u64 android_backport_reserved3' was added
member 'u64 android_backport_reserved4' was added
member 'u64 android_backport_reserved5' was added
member 'u64 android_backport_reserved6' was added
member 'u64 android_backport_reserved7' was added
member 'u64 android_backport_reserved8' was added
Bug: 282937940
Change-Id: I5abcb52630747f85d1b9cab51ff23b5d0c595da2
Signed-off-by: Elliot Berman <quic_eberman@quicinc.com>
Sync with latest Gunyah patches:
https://lore.kernel.org/all/20230509204801.2824351-7-quic_eberman@quicinc.com/https://lore.kernel.org/all/20230509204801.2824351-10-quic_eberman@quicinc.com/
function symbol changed from 'int gh_rm_call(void*, u32, void*, size_t, void**, size_t*)' to 'int gh_rm_call(void*, u32, const void*, size_t, void**, size_t*)'
CRC changed from 0x162db09d to 0xaa8c9d60
type changed from 'int(void*, u32, void*, size_t, void**, size_t*)' to 'int(void*, u32, const void*, size_t, void**, size_t*)'
parameter 3 type changed from 'void*' to 'const void*'
pointed-to type changed from 'void' to 'const void'
qualifier const added
function symbol 'int devm_gh_rm_register_platform_ops(struct device*, struct gh_rm_platform_ops*)' changed
CRC changed from 0xa6a1478a to 0x51bb297d
function symbol 'int gh_rm_register_platform_ops(struct gh_rm_platform_ops*)' changed
CRC changed from 0x110877e8 to 0xf2b08039
function symbol 'void gh_rm_unregister_platform_ops(struct gh_rm_platform_ops*)' changed
CRC changed from 0x2e3c1910 to 0x41e9ce79
type 'struct gh_rm_mem_entry' changed
member '__le64 phys_addr' was added
member '__le64 ipa_base' was removed
Bug: 279506910
Change-Id: I50b0c67b9fcc33612e278de76feec6e4c85ac74a
Signed-off-by: Elliot Berman <quic_eberman@quicinc.com>
struct gh_rm is an opaque pointer to everyone not the Gunyah Resource
Manager itself (drivers/virt/gunyah/rsc_mgr.c). The resource manager
provides functions (gh_rm_call, gh_rm_{un}register_notifier) for
entities to communicate with the resource manager. An opaque pointer is
provided to those entities and passed back in when making those calls.
Although Linux CRCs would be unaffected by internal changes to struct
gh_rm, Android KMI tracking unrolls the definition of struct gh_rm it
finds in drivers/virt/gunyah/rsc_mgr.c and would be subject to KMI
freeze. Since this is a private structure not accessible to vendor/OEM
drivers, replace the "struct gh_rm *" with "void *" on any KMI-tracked
symbol.
function symbol changed from 'int gh_rm_call(struct gh_rm*, u32, void*, size_t, void**, size_t*)' to 'int gh_rm_call(void*, u32, void*, size_t, void**, size_t*)'
CRC changed from 0xfef4ce1d to 0x162db09d
type changed from 'int(struct gh_rm*, u32, void*, size_t, void**, size_t*)' to 'int(void*, u32, void*, size_t, void**, size_t*)'
parameter 1 type changed from 'struct gh_rm*' to 'void*'
pointed-to type changed from 'struct gh_rm' to 'void'
function symbol changed from 'int gh_rm_notifier_register(struct gh_rm*, struct notifier_block*)' to 'int gh_rm_notifier_register(void*, struct notifier_block*)'
CRC changed from 0x412fac09 to 0xd5a6a3c9
type changed from 'int(struct gh_rm*, struct notifier_block*)' to 'int(void*, struct notifier_block*)'
parameter 1 type changed from 'struct gh_rm*' to 'void*'
pointed-to type changed from 'struct gh_rm' to 'void'
function symbol changed from 'int gh_rm_notifier_unregister(struct gh_rm*, struct notifier_block*)' to 'int gh_rm_notifier_unregister(void*, struct notifier_block*)'
CRC changed from 0xf4d771f8 to 0x2c865d28
type changed from 'int(struct gh_rm*, struct notifier_block*)' to 'int(void*, struct notifier_block*)'
parameter 1 type changed from 'struct gh_rm*' to 'void*'
pointed-to type changed from 'struct gh_rm' to 'void'
function symbol 'int devm_gh_rm_register_platform_ops(struct device*, struct gh_rm_platform_ops*)' changed
CRC changed from 0xb51b6569 to 0xa6a1478a
function symbol 'int gh_rm_register_platform_ops(struct gh_rm_platform_ops*)' changed
CRC changed from 0xa577ae43 to 0x110877e8
function symbol 'void gh_rm_unregister_platform_ops(struct gh_rm_platform_ops*)' changed
CRC changed from 0x5759f053 to 0x2e3c1910
type 'struct gh_rm_platform_ops' changed
member changed from 'int(* pre_mem_share)(struct gh_rm*, struct gh_rm_mem_parcel*)' to 'int(* pre_mem_share)(void*, struct gh_rm_mem_parcel*)'
type changed from 'int(*)(struct gh_rm*, struct gh_rm_mem_parcel*)' to 'int(*)(void*, struct gh_rm_mem_parcel*)'
pointed-to type changed from 'int(struct gh_rm*, struct gh_rm_mem_parcel*)' to 'int(void*, struct gh_rm_mem_parcel*)'
parameter 1 type changed from 'struct gh_rm*' to 'void*'
pointed-to type changed from 'struct gh_rm' to 'void'
member changed from 'int(* post_mem_reclaim)(struct gh_rm*, struct gh_rm_mem_parcel*)' to 'int(* post_mem_reclaim)(void*, struct gh_rm_mem_parcel*)'
type changed from 'int(*)(struct gh_rm*, struct gh_rm_mem_parcel*)' to 'int(*)(void*, struct gh_rm_mem_parcel*)'
pointed-to type changed from 'int(struct gh_rm*, struct gh_rm_mem_parcel*)' to 'int(void*, struct gh_rm_mem_parcel*)'
parameter 1 type changed from 'struct gh_rm*' to 'void*'
pointed-to type changed from 'struct gh_rm' to 'void'
Bug: 282937940
Change-Id: Ie775c668c95bee0d1c91862eebf8fd0f606ff309
Signed-off-by: Elliot Berman <quic_eberman@quicinc.com>
This reverts commit 509a7a32a5.
Qualcomm is reporting that internal debugging tools in addition to
Lauterbach Trace32 (T32) debugger (vLT_20230509_159359) are having
issues with DWARFv5.
Since the change to the DWARF debug info format was made after the
Android Feature Complete deadline, revert it from android14-* kernel
branches. We'll leave DWARFv5 for android-mainline and try again next
release in android15-*.
Bug: 281863640
Reported-by: Satya Durga Srinivasu Prabhala <quic_satyap@quicinc.com>
Change-Id: I5a1657bdf6785d23f3492dc12e6f3df0954b8deb
Signed-off-by: Nick Desaulniers <ndesaulniers@google.com>
Some vendors want to add a field when a 'sruct sock' is added so give a
hook to handle this. Any memory allocated when
trace_android_rvh_sk_alloc() is called needs to be freed when
trace_android_rvh_sk_free() is called.
Note, if trace_android_rvh_sk_alloc() fails, be sure to be able to
handle this in trace_android_rvh_sk_free(), but that should not be an
issue as that needs to be addressed in vendor code that runs for 'struct
sock' objects that have been created before the vendor code is loaded no
matter what.
Bug: 171013716
Signed-off-by: Vignesh Saravanaperumal <vignesh1.s@samsung.com>
Change-Id: I108a2f31d2dcc228f46159816deee6235afafbbd
Some vendors want to add a field when a 'sruct nf_conn' is added so give a
hook to handle this. Any memory allocated when
trace_android_rvh_nf_conn_alloc() is called needs to be freed when
trace_android_rvh_nf_conn_free() is called.
Note, if trace_android_rvh_nf_conn_alloc() fails, be sure to be able to
handle this in trace_android_rvh_nf_conn_free(), but that should not be
an issue as that needs to be addressed in vendor code that runs for
'struct nf_conn' objects that have been created before the vendor code
is loaded no matter what.
Bug: 171013716
Signed-off-by: Vignesh Saravanaperumal <vignesh1.s@samsung.com>
Change-Id: I4d2b025196a3df7ba4adec313c90483811cac728
