The current implementation of the mark_victim tracepoint provides only the
process ID (pid) of the victim process. This limitation poses challenges
for userspace tools requiring real-time OOM analysis and intervention.
Although this information is available from the kernel logs, it’s not
the appropriate format to provide OOM notifications. In Android, BPF
programs are used with the mark_victim trace events to notify userspace of
an OOM kill. For consistency, update the trace event to include the same
information about the OOMed victim as the kernel logs.
- UID
In Android each installed application has a unique UID. Including
the `uid` assists in correlating OOM events with specific apps.
- Process Name (comm)
Enables identification of the affected process.
- OOM Score
Will allow userspace to get additional insight of the relative kill
priority of the OOM victim. In Android, the oom_score_adj is used to
categorize app state (foreground, background, etc.), which aids in
analyzing user-perceptible impacts of OOM events [1].
- Total VM, RSS Stats, and pgtables
Amount of memory used by the victim that will, potentially, be freed up
by killing it.
[1] 246dc8fc95:frameworks/base/services/core/java/com/android/server/am/ProcessList.java;l=188-283
Signed-off-by: Carlos Galo <carlosgalo@google.com>
Reviewed-by: Steven Rostedt <rostedt@goodmis.org>
Cc: Suren Baghdasaryan <surenb@google.com>
Cc: Michal Hocko <mhocko@suse.com>
Cc: "Masami Hiramatsu (Google)" <mhiramat@kernel.org>
Cc: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Bug: 331214192
(cherry picked from commit 72ba14deb40a9e9668ec5e66a341ed657e5215c2)
[ carlosgalo: Manually added struct cred change in mark_oom_victim function ]
Link: https://lore.kernel.org/all/20240223173258.174828-1-carlosgalo@google.com/
Change-Id: I24f503ceca04b83f8abf42fcd04a3409e17be6b5
This reverts commit 6b4c816d17.
Reason for revert: b/331214192
Change-Id: I9f4f56de7d65cee19c7015b0cb1bda339d82a5f5
Signed-off-by: Carlos Galo <carlosgalo@google.com>
Export two functions to help memory reclaim.
Bug: 323406883
Change-Id: I099d414c9b3648224ab077b9929c6622b2d4228a
Signed-off-by: Minchan Kim <minchan@google.com>
This patch adds two exported functions to set/get reclaim parameters.
Bug: 323406883
Change-Id: I8c29073dba3e77cb5db7f45b640518deae04b8a9
Signed-off-by: Minchan Kim <minchan@google.com>
commit 16603605b667b70da974bea8216c93e7db043bf1 upstream.
Anonymous sets are never used with timeout from userspace, reject this.
Exception to this rule is NFT_SET_EVAL to ensure legacy meters still work.
Bug: 329055463
Cc: stable@vger.kernel.org
Fixes: 761da2935d ("netfilter: nf_tables: add set timeout API support")
Reported-by: lonial con <kongln9170@gmail.com>
Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
(cherry picked from commit 72c1efe3f247a581667b7d368fff3bd9a03cd57a)
Signed-off-by: Lee Jones <joneslee@google.com>
Change-Id: I8c1c818e3d155d5edefee0b741568104081efb38
This file should only exist in android-mainline.
Bug: 333350072
Change-Id: I6350acb9d187f94a67c34c2e72b607a9599269b0
Signed-off-by: Giuliano Procida <gprocida@google.com>
This commit fixes the following warning when building virtio_snd driver.
"
*** CID 1583619: Uninitialized variables (UNINIT)
sound/virtio/virtio_kctl.c:294 in virtsnd_kctl_tlv_op()
288
289 break;
290 }
291
292 kfree(tlv);
293
vvv CID 1583619: Uninitialized variables (UNINIT)
vvv Using uninitialized value "rc".
294 return rc;
295 }
296
297 /**
298 * virtsnd_kctl_get_enum_items() - Query items for the ENUMERATED element type.
299 * @snd: VirtIO sound device.
"
This warning is caused by the absence of the "default" branch in the
switch-block, and is a false positive because the kernel calls
virtsnd_kctl_tlv_op() only with values for op_flag processed in
this block.
Also, this commit unifies the cleanup path for all possible control
paths in the callback function.
Signed-off-by: Anton Yakovlev <anton.yakovlev@opensynergy.com>
Signed-off-by: Aiswarya Cyriac <aiswarya.cyriac@opensynergy.com>
Reported-by: coverity-bot <keescook+coverity-bot@chromium.org>
Addresses-Coverity-ID: 1583619 ("Uninitialized variables")
Fixes: d6568e3de42d ("ALSA: virtio: add support for audio controls")
Acked-by: Michael S. Tsirkin <mst@redhat.com>
Link: https://lore.kernel.org/r/20240216100643.688590-1-aiswarya.cyriac@opensynergy.com
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Bug: 330891925
Change-Id: I6fb999ed48457baddcde95a3539daf010d505296
(cherry picked from commit ba00e413fa1515e4d0890803c01ebc555f500f15)
Signed-off-by: Marcin Radomski <dextero@google.com>
Implementation of support for audio controls in accordance with the
extension of the virtio sound device specification [1] planned for
virtio-v1.3-cs01.
The device can announce the VIRTIO_SND_F_CTLS feature. If the feature is
negotiated, then an additional field appears in the configuration space:
struct virtio_snd_config {
...
/* number of available control elements */
__le32 controls;
};
The driver can send the following requests to manage audio controls:
enum {
...
/* control element request types */
VIRTIO_SND_R_CTL_INFO = 0x0300,
VIRTIO_SND_R_CTL_ENUM_ITEMS,
VIRTIO_SND_R_CTL_READ,
VIRTIO_SND_R_CTL_WRITE,
VIRTIO_SND_R_CTL_TLV_READ,
VIRTIO_SND_R_CTL_TLV_WRITE,
VIRTIO_SND_R_CTL_TLV_COMMAND,
...
};
And the device can send the following audio control event notification:
enum {
...
/* control element event types */
VIRTIO_SND_EVT_CTL_NOTIFY = 0x1200,
...
};
See additional details in [1].
[1] https://lists.oasis-open.org/archives/virtio-comment/202104/msg00013.html
Signed-off-by: Anton Yakovlev <anton.yakovlev@opensynergy.com>
Signed-off-by: Aiswarya Cyriac <aiswarya.cyriac@opensynergy.com>
Link: https://lore.kernel.org/r/20240115133654.576068-2-aiswarya.cyriac@opensynergy.com
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Bug: 330891925
Change-Id: I4c70787a920bc4a7cf82b8115fc9f0a6c77b4859
(cherry picked from commit d6568e3de42dd971a1356f7ba581e6600d53f0a0)
Signed-off-by: Marcin Radomski <dextero@google.com>
Added just symbols reported as required by:
tools/bazel run //common-modules/virtual-device:virtual_device_aarch64_dist
because the virtual_device_aarch64_abi_update_symbol_list tool
introduces a ton of unrelated changes - not just trivial reordering, but
also adds some extra symbols.
Bug: 330891925
Test: Build dist packages on the entire commit chain:
Test: tools/bazel run //common-modules/virtual-device:virtual_device_x86_64_dist
Test: tools/bazel run //common-modules/virtual-device:virtual_device_aarch64_dist
Change-Id: I26abf56b3cb9b3cc3f179647ce229aa85a3dd7c8
Signed-off-by: Marcin Radomski <dextero@google.com>
The extern declaration ended up at the end of rt.c instead of sched.h by
mistake.
Bug: 332629555
Fixes: dcdec80d6b ("ANDROID: Export cpu_busy_with_softirqs()")
Signed-off-by: Qais Yousef <qyousef@google.com>
Change-Id: Id95a1c2261134c4d4f589ec51d350fc5eb2724f9
__alloc_pages_direct_reclaim() is called from slowpath allocation where
high atomic reserves can be unreserved after there is a progress in
reclaim and yet no suitable page is found. Later should_reclaim_retry()
gets called from slow path allocation to decide if the reclaim needs to be
retried before OOM kill path is taken.
should_reclaim_retry() checks the available(reclaimable + free pages)
memory against the min wmark levels of a zone and returns:
a) true, if it is above the min wmark so that slow path allocation will
do the reclaim retries.
b) false, thus slowpath allocation takes oom kill path.
should_reclaim_retry() can also unreserves the high atomic reserves **but
only after all the reclaim retries are exhausted.**
In a case where there are almost none reclaimable memory and free pages
contains mostly the high atomic reserves but allocation context can't use
these high atomic reserves, makes the available memory below min wmark
levels hence false is returned from should_reclaim_retry() leading the
allocation request to take OOM kill path. This can turn into a early oom
kill if high atomic reserves are holding lot of free memory and
unreserving of them is not attempted.
(early)OOM is encountered on a VM with the below state:
[ 295.998653] Normal free:7728kB boost:0kB min:804kB low:1004kB
high:1204kB reserved_highatomic:8192KB active_anon:4kB inactive_anon:0kB
active_file:24kB inactive_file:24kB unevictable:1220kB writepending:0kB
present:70732kB managed:49224kB mlocked:0kB bounce:0kB free_pcp:688kB
local_pcp:492kB free_cma:0kB
[ 295.998656] lowmem_reserve[]: 0 32
[ 295.998659] Normal: 508*4kB (UMEH) 241*8kB (UMEH) 143*16kB (UMEH)
33*32kB (UH) 7*64kB (UH) 0*128kB 0*256kB 0*512kB 0*1024kB 0*2048kB
0*4096kB = 7752kB
Per above log, the free memory of ~7MB exist in the high atomic reserves
is not freed up before falling back to oom kill path.
Fix it by trying to unreserve the high atomic reserves in
should_reclaim_retry() before __alloc_pages_direct_reclaim() can fallback
to oom kill path.
Bug: 332219324
Link: https://lkml.kernel.org/r/1700823445-27531-1-git-send-email-quic_charante@quicinc.com
Fixes: 0aaa29a56e ("mm, page_alloc: reserve pageblocks for high-order atomic allocations on demand")
(cherry picked from commit ac3f3b0a55518056bc80ed32a41931c99e1f7d81)
Change-Id: I432d4ac4864d401a4413f6b2ef902625766f8070
Signed-off-by: Charan Teja Kalla <quic_charante@quicinc.com>
Reported-by: Chris Goldsworthy <quic_cgoldswo@quicinc.com>
Suggested-by: Michal Hocko <mhocko@suse.com>
Acked-by: Michal Hocko <mhocko@suse.com>
Acked-by: David Rientjes <rientjes@google.com>
Cc: Chris Goldsworthy <quic_cgoldswo@quicinc.com>
Cc: David Hildenbrand <david@redhat.com>
Cc: Johannes Weiner <hannes@cmpxchg.org>
Cc: Mel Gorman <mgorman@techsingularity.net>
Cc: Pavankumar Kondeti <quic_pkondeti@quicinc.com>
Cc: Vlastimil Babka <vbabka@suse.cz>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Highatomic reserves are set to roughly 1% of zone for maximum and a
pageblock size for minimum. Encountered a system with the below
configuration:
Normal free:7728kB boost:0kB min:804kB low:1004kB high:1204kB
reserved_highatomic:8192KB managed:49224kB
On such systems, even a single pageblock makes highatomic reserves are set
to ~8% of the zone memory. This high value can easily exert pressure on
the zone.
Per discussion with Michal and Mel, it is not much useful to reserve the
memory for highatomic allocations on such small systems[1]. Since the
minimum size for high atomic reserves is always going to be a pageblock
size and if 1% of zone managed pages is going to be below pageblock size,
don't reserve memory for high atomic allocations. Thanks Michal for this
suggestion[2].
Since no memory is being reserved for high atomic allocations and if
respective allocation failures are seen, this patch can be reverted.
[1] https://lore.kernel.org/linux-mm/20231117161956.d3yjdxhhm4rhl7h2@techsingularity.net/
[2] https://lore.kernel.org/linux-mm/ZVYRJMUitykepLRy@tiehlicka/
Bug: 332219324
Link: https://lkml.kernel.org/r/c3a2a48e2cfe08176a80eaf01c110deb9e918055.1700821416.git.quic_charante@quicinc.com
Change-Id: Id059b63bd6ee68b3a2cd1c4b44613234a42d0a46
(cherry picked from commit 9cd20f3fe045af95a8fe7a12328b21bfd2f3b8bf)
Signed-off-by: Charan Teja Kalla <quic_charante@quicinc.com>
Acked-by: David Rientjes <rientjes@google.com>
Cc: David Hildenbrand <david@redhat.com>
Cc: Johannes Weiner <hannes@cmpxchg.org>
Cc: Mel Gorman <mgorman@techsingularity.net>
Cc: Michal Hocko <mhocko@suse.com>
Cc: Pavankumar Kondeti <quic_pkondeti@quicinc.com>
Cc: Vlastimil Babka <vbabka@suse.cz>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Patch series "mm: page_alloc: fixes for high atomic reserve
caluculations", v3.
The state of the system where the issue exposed shown in oom kill logs:
[ 295.998653] Normal free:7728kB boost:0kB min:804kB low:1004kB high:1204kB reserved_highatomic:8192KB active_anon:4kB inactive_anon:0kB active_file:24kB inactive_file:24kB unevictable:1220kB writepending:0kB present:70732kB managed:49224kB mlocked:0kB bounce:0kB free_pcp:688kBlocal_pcp:492kB free_cma:0kB
[ 295.998656] lowmem_reserve[]: 0 32
[ 295.998659] Normal: 508*4kB (UMEH) 241*8kB (UMEH) 143*16kB (UMEH)
33*32kB (UH) 7*64kB (UH) 0*128kB 0*256kB 0*512kB 0*1024kB 0*2048kB 0*4096kB = 7752kB
From the above, it is seen that ~16MB of memory reserved for high atomic
reserves against the expectation of 1% reserves which is fixed in the 1st
patch.
Don't reserve the high atomic page blocks if 1% of zone memory size is
below a pageblock size.
This patch (of 2):
reserve_highatomic_pageblock() aims to reserve the 1% of the managed pages
of a zone, which is used for the high order atomic allocations.
It uses the below calculation to reserve:
static void reserve_highatomic_pageblock(struct page *page, ....) {
.......
max_managed = (zone_managed_pages(zone) / 100) + pageblock_nr_pages;
if (zone->nr_reserved_highatomic >= max_managed)
goto out;
zone->nr_reserved_highatomic += pageblock_nr_pages;
set_pageblock_migratetype(page, MIGRATE_HIGHATOMIC);
move_freepages_block(zone, page, MIGRATE_HIGHATOMIC, NULL);
out:
....
}
Since we are always appending the 1% of zone managed pages count to
pageblock_nr_pages, the minimum it is turning into 2 pageblocks as the
nr_reserved_highatomic is incremented/decremented in pageblock sizes.
Encountered a system(actually a VM running on the Linux kernel) with the
below zone configuration:
Normal free:7728kB boost:0kB min:804kB low:1004kB high:1204kB
reserved_highatomic:8192KB managed:49224kB
The existing calculations making it to reserve the 8MB(with pageblock size
of 4MB) i.e. 16% of the zone managed memory. Reserving such high amount
of memory can easily exert memory pressure in the system thus may lead
into unnecessary reclaims till unreserving of high atomic reserves.
Since high atomic reserves are managed in pageblock size granules, as
MIGRATE_HIGHATOMIC is set for such pageblock, fix the calculations for
high atomic reserves as, minimum is pageblock size , maximum is
approximately 1% of the zone managed pages.
Bug: 332219324
Link: https://lkml.kernel.org/r/cover.1700821416.git.quic_charante@quicinc.com
Link: https://lkml.kernel.org/r/1660034138397b82a0a8b6ae51cbe96bd583d89e.1700821416.git.quic_charante@quicinc.com
Change-Id: Icc15fb88ef6166f691f5aa14311bc45bff972b99
(cherry picked from commit d68e39fc45f70e35eb74df2128d315c1d91e4dc4)
Signed-off-by: Charan Teja Kalla <quic_charante@quicinc.com>
Acked-by: Mel Gorman <mgorman@techsingularity.net>
Acked-by: David Rientjes <rientjes@google.com>
Cc: David Hildenbrand <david@redhat.com>
Cc: Johannes Weiner <hannes@cmpxchg.org>
Cc: Michal Hocko <mhocko@suse.com>
Cc: Pavankumar Kondeti <quic_pkondeti@quicinc.com>
Cc: Vlastimil Babka <vbabka@suse.cz>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
This function used to be called task_may_not_preempt() in older versions
and used by modules that have their extension to RT. Export it to allow
users to continue to use it.
Bug: 332629555
Signed-off-by: Qais Yousef <qyousef@google.com>
Change-Id: I04affb8e9e6258f9fb36ebab4d7956a265e9e299
The attribute writing should return the number of bytes used from the
buffer on success.
Fixes: a7cff92f06 ("usb: typec: USB Power Delivery helpers for ports and partners")
Cc: stable@vger.kernel.org
Signed-off-by: Kyle Tso <kyletso@google.com>
Reviewed-by: Guenter Roeck <linux@roeck-us.net>
Reviewed-by: Heikki Krogerus <heikki.krogerus@linux.intel.com>
Link: https://lore.kernel.org/r/20240319074309.3306579-1-kyletso@google.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Bug: 206108037
(cherry picked from commit 53f5094fdf5deacd99b8655df692e9278506724d)
Change-Id: If5ad5cd3b82a81480a5dbe488e49482ab4836ab8
Signed-off-by: Kyle Tso <kyletso@google.com>
The PD of Type-C port needs to be updated in pd_set. Unlink the Type-C
port device to the old PD before linking it to a new one.
Fixes: cd099cde4ed2 ("usb: typec: tcpm: Support multiple capabilities")
Cc: stable@vger.kernel.org
Signed-off-by: Kyle Tso <kyletso@google.com>
Acked-by: Heikki Krogerus <heikki.krogerus@linux.intel.com>
Link: https://lore.kernel.org/r/20240311172306.3911309-1-kyletso@google.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Bug: 206108037
(cherry picked from commit 17af5050dead6cbcca12c1fcd17e0bb8bb284eae)
Change-Id: I84e6735181e2ab7fd37432533ab6b91b0b560c1e
Signed-off-by: Kyle Tso <kyletso@google.com>
This reverts commit 6bad1052c2, it is the
LTS merge that had to previously get reverted due to being merged too
early.
Cc: Todd Kjos <tkjos@google.com>
Change-Id: I31b7d660bd833cf022ac4870f6d01e723fda5182
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
This reverts commit 75266774b9.
It conflicts with the LTS merge revert and will be brought back after
that is properly merged.
Bug: 308663717
Bug: 319125789
Cc: Bart Van Assche <bvanassche@acm.org>
Cc: Juan Yescas <jyescas@google.com>
Change-Id: Ieb275cba965a604019aa51e174e52082959c8872
This reverts commit 7932afa9bb.
It broke the Android kernel ABI and can be brought back in the future
in an ABI-safe way if needed.
Bug: 332277393
Change-Id: I10abcbf5237536b0ee382d3db16a5ebd82b3222c
Signed-off-by: Giuliano Procida <gprocida@google.com>
Commit 6d98eb95b4 ("binder: avoid potential data leakage when copying
txn") introduced changes to how binder objects are copied. In doing so,
it unintentionally removed an offset alignment check done through calls
to binder_alloc_copy_from_buffer() -> check_buffer().
These calls were replaced in binder_get_object() with copy_from_user(),
so now an explicit offset alignment check is needed here. This avoids
later complications when unwinding the objects gets harder.
It is worth noting this check existed prior to commit 7a67a39320
("binder: add function to copy binder object from buffer"), likely
removed due to redundancy at the time.
Fixes: 6d98eb95b4 ("binder: avoid potential data leakage when copying txn")
Cc: <stable@vger.kernel.org>
Acked-by: Todd Kjos <tkjos@google.com>
Signed-off-by: Carlos Llamas <cmllamas@google.com>
Bug: 320661088
Link: https://lore.kernel.org/all/20240330190115.1877819-1-cmllamas@google.com/
Signed-off-by: Carlos Llamas <cmllamas@google.com>
Change-Id: Iaddabaa28de7ba7b7d35dbb639d38ca79dbc5077
Add symbol list for Nothing at the first time
1 Added function:
[A] 'function int __traceiter_android_vh_thermal_pm_notify_suspend(void*, thermal_zone_device*, int*)'
1 Added variable:
[A] 'tracepoint __tracepoint_android_vh_thermal_pm_notify_suspend'
Bug: 332221925
Change-Id: I07b727a5c340f8f1cc7fb72e16a1c47881aa348b
Signed-off-by: Dylan Chang <dylan.chang@nothing.tech>
Currently, most of the thermal_zones are IRQ capable and they do not need
to be updated while resuming. To improve the system performance and reduce
the resume time. Add a vendor function to check if the thermal_zone is
not IRQ capable and needs to be updated.
Bug: 170905417
Bug: 332221925
Test: boot and vendor function worked properly.
Change-Id: I9389985bba29b551a7a20b55e1ed26b6c4da9b3d
Signed-off-by: David Chao <davidchao@google.com>
Signed-off-by: Dylan Chang <dylan.chang@nothing.tech>
This reverts commit 8a2f432fcb.
It conflicts with the LTS merge revert and will be brought back after
that is properly merged.
Bug: 308663717
Bug: 319125789
Cc: Bart Van Assche <bvanassche@acm.org>
Cc: Juan Yescas <jyescas@google.com>
Change-Id: I764adf995cae6b485d4d98e410c78128a88647e0
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
to make sure trace_android_vh_binder_has_special_work_ilocked will be called
in any case in android native logic
(here just fix is:
binder_thread_read (non_block case) ->
| binder_wait_for_work ->
| if(binder_has_work_ilocked(...)) ->
| fase: schedule true: break ->
),
if binder_has_work_ilocked do not deal with trace_android_vh_binder_has_special_work_ilocked
vip thread maybe return true because proc->todo list is not empty but it has not vip work
(special work with special binder_transaction:flag)
fix it by: move trace_android_vh_binder_has_special_work_ilocked for binder_has_work
to binder_has_work_ilocked
Fixs: 24bb8fc82e60("ANDROID: vendor_hooks: add hooks in driver/android/binder.c")
| https://android-review.googlesource.com/c/kernel/common/+/2897624
Bug: 318782978
Change-Id: I8ced722c71c82942e626f04dce950e8df580ae95
Signed-off-by: songfeng <songfeng@oppo.com>
kthread_park and wait_woken have a similar race that
kthread_stop and wait_woken used to have before it was fixed in
commit cb6538e740 ("sched/wait: Fix a kthread race with
wait_woken()"). Extend that fix to also cover kthread_park.
[jstultz: Made changes suggested by Peter to optimize
memory loads]
Change-Id: Idd1381e297efb1f2493deedcc0fc0288f0027fef
Signed-off-by: Arve Hjønnevåg <arve@android.com>
Signed-off-by: John Stultz <jstultz@google.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Reviewed-by: Valentin Schneider <vschneid@redhat.com>
Link: https://lore.kernel.org/r/20230602212350.535358-1-jstultz@google.com
(cherry picked from commit ef73d6a4ef0b35524125c3cfc6deafc26a0c966a)
Wnen coalescing a table into a block, the break-before-make sequence
must invalidate the whole range of addresses translated by the entry in
order to avoid the possibility of a TLB conflict.
Fix the coalescing post-table walker so that the whole range of the old
table is invalidated, rather than just the first address, since a
refcount of 1 on the child page is not sufficient to ensure the absence
of any valid mappings.
Cc: Sebastian Ene <sebastianene@google.com>
Reported-by: Mostafa Saleh <smostafa@google.com>
Fixes: 9e7e5db52c ("ANDROID: KVM: arm64: Coalesce host stage2 entries on ownership reclaim")
Bug: 331232642
Signed-off-by: Will Deacon <willdeacon@google.com>
Change-Id: I4c94f552e4385599ad88b1be50b69ffbafa64a9b
There are no new symbols to be added to GKI symbol list.
We simply update our symbol list.
Bug: 330957400
Change-Id: I5a6420884a82ccc1aa2c4aa149554e910fe0701e
Signed-off-by: Youngmin Nam <youngmin.nam@samsung.com>
Simply clean up symbol order to recognize changes easily.
There are no changes on symbol.
Bug: 330635812
Change-Id: I10a83b2ceb56c34bad57068bab58e48e7e753991
Signed-off-by: Youngmin Nam <youngmin.nam@samsung.com>
The hyp event host_hcall was missing when a custom HVC runs.
Bug: 278749606
Bug: 244543039
Bug: 244373730
Change-Id: I760cab4fbd36a13ad262842880d9ec484f23fd22
Signed-off-by: Vincent Donnefort <vdonnefort@google.com>
(cherry picked from commit a1836ffbea9fcb70fa9d49af7382b9343285036f)
Adding the following symbols:
- blk_queue_max_segment_size
Bug: 269652215
Change-Id: Ie599f23056fd0f6641df6dba57e48413b144fa1b
Signed-off-by: Robin Peng <robinpeng@google.com>
LPM feature of DWC2 module integrated in Rockchip SoCs doesn't work
properly or needs some additional handling, so disable it for now.
Without disabling LPM feature, the USB ADB communication fail with
the following error log:
dwc2 ff580000.usb: new address 27
dwc2 ff580000.usb: Failed to exit L1 sleep state in 200us.
dwc2 ff580000.usb: dwc2_hsotg_send_reply: cannot queue req
dwc2 ff580000.usb: dwc2_hsotg_process_req_status: failed to send reply
dwc2 ff580000.usb: dwc2_hsotg_enqueue_setup: failed queue (-11)
dwc2 ff580000.usb: Failed to exit L1 sleep state in 200us.
[diff vs vendor kernel: added lpm_clock_gating, besl and
hird_threshold_en settings as seen in commit 53febc9569 ("usb: dwc2:
disable Link Power Management on STM32MP15 HS OTG")]
Bug: 300024866
Change-Id: Ib8ae241dce5993e34b6cf8e83254b2730effe009
Signed-off-by: William Wu <william.wu@rock-chips.com>
Signed-off-by: Frank Wang <frank.wang@rock-chips.com>
Signed-off-by: Quentin Schulz <quentin.schulz@theobroma-systems.com>
Link: https://lore.kernel.org/r/20221206-dwc2-gadget-dual-role-v1-1-36515e1092cd@theobroma-systems.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
(cherry picked from commit 42a317d076b58f08413219b1679d211783c2e5f3)
This reverts commit fa6c89a93f.
Reason for revert: Only reverting the prerequisite CL. Will revert the dependent aosp/3007694 once it's safe.
Bug: 324290965
Test: tools/bazel run //common-modules/virtual-device:virtual_device_aarch64_dist
Change-Id: I4f4caf7916e8030b6fe4f407c41a593c4916f43f
Signed-off-by: Istvan Nador <istvannador@google.com>
The tail pages in a THP can have swap entry information stored in their
private field. When migrating to a new page, all tail pages of the new
page need to update ->private to avoid future data corruption.
This fix is stable-only, since after commit 07e09c483cbe ("mm/huge_memory:
work on folio->swap instead of page->private when splitting folio"),
subpages of a swapcached THP no longer requires the maintenance.
Adding THPs to the swapcache was introduced in commit
38d8b4e6bd ("mm, THP, swap: delay splitting THP during swap out"),
where each subpage of a THP added to the swapcache had its own swapcache
entry and required the ->private field to point to the correct swapcache
entry. Later, when THP migration functionality was implemented in commit
616b837153 ("mm: thp: enable thp migration in generic path"),
it initially did not handle the subpages of swapcached THPs, failing to
update their ->private fields or replace the subpage pointers in the
swapcache. Subsequently, commit e71769ae52 ("mm: enable thp migration
for shmem thp") addressed the swapcache update aspect. This patch fixes
the update of subpage ->private fields.
Bug: 324818390
Fixes: 616b837153 ("mm: thp: enable thp migration in generic path")
Link: https://lore.kernel.org/linux-mm/20240306155217.118467-1-zi.yan@sent.com/
Reported-and-tested-by: Charan Teja Kalla <quic_charante@quicinc.com>
Change-Id: Ia4603cd58b76dc6ff46a2c53a735942a87221419
Signed-off-by: Zi Yan <ziy@nvidia.com>
Acked-by: David Hildenbrand <david@redhat.com>
Closes: https://lore.kernel.org/linux-mm/1707814102-22682-1-git-send-email-quic_charante@quicinc.com/
Signed-off-by: Charan Teja Kalla <quic_charante@quicinc.com>
Gunyah resource manager has limited internal buffering to send messages
to VMs and it is possible to fill the buffer and cause RM to drop
replies. Prevent the "drop" scenario by serializing the entire
send/receive RPC flow.
Bug: 330201551
Change-Id: I65f2f6daf495eb24e1bc120a6a4d0b84c966e3cc
Signed-off-by: Elliot Berman <quic_eberman@quicinc.com>
Add support for configuring the maximum segment size.
Add support for segments smaller than the page size.
This patch enables testing segments smaller than the page size with a
driver that does not call blk_rq_map_sg().
Bug: 308663717
Bug: 319125789
Change-Id: Idd7094e9f773c295017b44377d2a3f10abea95cf
Signed-off-by: Bart Van Assche <bvanassche@acm.org>
Signed-off-by: Juan Yescas <jyescas@google.com>
Add a kernel module parameter for configuring the maximum segment size.
This patch enables testing SCSI support for segments smaller than the
page size.
Bug: 308663717
Bug: 319125789
Change-Id: I1d9f1714876de72630cbf3150e7082b988dd7322
Signed-off-by: Bart Van Assche <bvanassche@acm.org>
Signed-off-by: Juan Yescas <jyescas@google.com>