An android-only patch to work around frozen KMI for android14 kernels
allows a dependency between hid and uhid if both modules are enabled:
if (IS_ENABLED(CONFIG_UHID) && parser->device->ll_driver == &uhid_hid_driver)
max_buffer_size = UHID_DATA_MAX;
For allmodconfig builds, both hid and uhid are modules so this creates
a cyclic dependancy and we see this error in kernelci tests:
ERROR: Cycle detected: hid -> uhid -> hid
Fix by changeing to IS_BUILTIN() instead of IS_ENABLED() since Android
builds always build uhid into the core kernel.
Fixes: 7668cef283 ("ANDROID: HID: Only utilise UHID provided exports if UHID is enabled")
Signed-off-by: Todd Kjos <tkjos@google.com>
Change-Id: I622466a42ad94e3606820cf506188bd679078cbf
GCC builds of fips140.ko all fail with these errors. This causes
allmodconfig builds to fail in kernelci.
aarch64-linux-gnu-objcopy: crypto/fips140.ko:
can't dump section '.rela.rodata'
- it does not exist: file format not recognized
Since the Android use-cases for fips140 are clang only, suppress
fips140.ko builds for GCC
Bug: 350087876
Signed-off-by: Todd Kjos <tkjos@google.com>
Change-Id: I742d19bc5172d43a19acd48a248bc2a194f67ca2
Running N CPU-bound tasks on an N CPUs platform:
- with asymmetric CPU capacity
- not being a DynamIq system (i.e. having a PKG level sched domain
without the SD_SHARE_PKG_RESOURCES flag set)
.. might result in a task placement where two tasks run on a big CPU
and none on a little CPU. This placement could be more optimal by
using all CPUs.
Testing platform:
Juno-r2:
- 2 big CPUs (1-2), maximum capacity of 1024
- 4 little CPUs (0,3-5), maximum capacity of 383
Testing workload ([1]):
Spawn 6 CPU-bound tasks. During the first 100ms (step 1), each tasks
is affine to a CPU, except for:
- one little CPU which is left idle.
- one big CPU which has 2 tasks affine.
After the 100ms (step 2), remove the cpumask affinity.
Behavior before the patch:
During step 2, the load balancer running from the idle CPU tags sched
domains as:
- little CPUs: 'group_has_spare'. Cf. group_has_capacity() and
group_is_overloaded(), 3 CPU-bound tasks run on a 4 CPUs
sched-domain, and the idle CPU provides enough spare capacity
regarding the imbalance_pct
- big CPUs: 'group_overloaded'. Indeed, 3 tasks run on a 2 CPUs
sched-domain, so the following path is used:
group_is_overloaded()
\-if (sgs->sum_nr_running <= sgs->group_weight) return true;
The following path which would change the migration type to
'migrate_task' is not taken:
calculate_imbalance()
\-if (env->idle != CPU_NOT_IDLE && env->imbalance == 0)
as the local group has some spare capacity, so the imbalance
is not 0.
The migration type requested is 'migrate_util' and the busiest
runqueue is the big CPU's runqueue having 2 tasks (each having a
utilization of 512). The idle little CPU cannot pull one of these
task as its capacity is too small for the task. The following path
is used:
detach_tasks()
\-case migrate_util:
\-if (util > env->imbalance) goto next;
After the patch:
As the number of failed balancing attempts grows (with
'nr_balance_failed'), progressively make it easier to migrate
a big task to the idling little CPU. A similar mechanism is
used for the 'migrate_load' migration type.
Improvement:
Running the testing workload [1] with the step 2 representing
a ~10s load for a big CPU:
Before patch: ~19.3s
After patch: ~18s (-6.7%)
Similar issue reported at:
https://lore.kernel.org/lkml/20230716014125.139577-1-qyousef@layalina.io/
Suggested-by: Vincent Guittot <vincent.guittot@linaro.org>
Signed-off-by: Pierre Gondois <pierre.gondois@arm.com>
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Reviewed-by: Vincent Guittot <vincent.guittot@linaro.org>
Reviewed-by: Dietmar Eggemann <dietmar.eggemann@arm.com>
Acked-by: Qais Yousef <qyousef@layalina.io>
Link: https://lore.kernel.org/r/20231206090043.634697-1-pierre.gondois@arm.com
(cherry picked from commit 3af7524b14198f5159a86692d57a9f28ec9375ce)
Change-Id: I916aa7e56af6addf0eb3a78ec77119324172d9d9
Signed-off-by: John Stultz <jstultz@google.com>
Apparently despite it being marked inline, the compiler
may not inline __down_write_common() which makes it difficult
to identify the cause of lock contention, as the wchan of the
blocked function will always be listed as __down_write_common().
So add __always_inline annotation to the common function (as
well as the inlined helper callers) to force it to be inlined
so a more useful blocking function will be listed (via wchan).
This mirrors commit 92cc5d00a4 ("locking/rwsem: Add
__always_inline annotation to __down_read_common() and inlined
callers") which did the same for __down_read_common.
I sort of worry that I'm playing wack-a-mole here, and talking
with compiler people, they tell me inline means nothing, which
makes me want to cry a little. So I'm wondering if we need to
replace all the inlines with __always_inline, or remove them
because either we mean something by it, or not.
Cc: Tim Murray <timmurray@google.com>
Cc: Nick Desaulniers <ndesaulniers@google.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: Will Deacon <will@kernel.org>
Cc: Waiman Long <longman@redhat.com>
Cc: Boqun Feng <boqun.feng@gmail.com>
Cc: kernel-team@android.com
Fixes: c995e638cc ("locking/rwsem: Fold __down_{read,write}*()")
Reported-by: Tim Murray <timmurray@google.com>
Acked-by: Waiman Long <longman@redhat.com>
Change-Id: I72b273149577b8125ea3a5053befbd5cf66bf8ad
Signed-off-by: John Stultz <jstultz@google.com>
Link: https://lore.kernel.org/lkml/20240620174204.1802235-1-jstultz@google.com/
Bug: 332722989
---
v2:
* Add ack tags & minor tweaks to commit message
gcc segfaults when compiling fips140-module.c because it doesn't like
__attribute__((__no_sanitize__("cfi"))) on fips140_init(). But since
Linux's CFI now uses the kcfi sanitizer instead of cfi, this no
attribute longer did anything anyway. Remove it.
fips140_init() does work with kcfi, though this relies on the initcall
function pointers being typed correctly. They were correct, but for
futureproofing also make it use initcall_t from <linux/init.h>.
Bug: 349612732
Change-Id: Ic5cfaef177b58abf21f1737579d75b4df4d0d09c
Signed-off-by: Eric Biggers <ebiggers@google.com>
These hooks are designed to set or clear OEM reserved pageflags when the
memory state may change.
Bug: 336964184
Change-Id: I9cb288ef6eef7a719d4f4748d6b71010645b7d50
Signed-off-by: Xiaofeng Yuan <yuanxiaofeng@vivo.com>
Add PG_oem_reserved_x pageflags for OEM on 64-bit platform.
These new flags can be used to indicate different states of page.
For example, we can use these pageflags to identify anonymous pages
at different ZRAM compression rates.
These flags will be used in conjunction with different Android
application states. Therefore, I think this is not a generic
modification for all Linux devices and is not suitable for upstream
submission.
Bug: 336964184
Change-Id: Ie68087248866af63ac516d96e3af85222e7a0b50
Signed-off-by: Xiaofeng Yuan <yuanxiaofeng@vivo.com>
This patch export a sys_exit tracepoint for
task state-tracking and performance tuning.
Bug: 339912146
Change-Id: I951ac6034e80691f092c0ba41b6af1fdaf8be49c
Signed-off-by: zhujingpeng <zhujingpeng@vivo.com>
(cherry picked from commit 53c7feb8b4829376b678b7cb8d501f48b2b47286)
Enable CONFIG_SYN_COOKIES to support SYN cookies against attack "SYN flooding".
This also makes GKI on arm64 consistent with GKI on x86.
According to kernel dev-team, this does not affect the KMI.
Bug: 349649090
Bug: 278043288
Change-Id: If43951b0ce3028e65799f9b6e68106ca98ee980e
Signed-off-by: Norihiko Hama <Norihiko.Hama@alpsalpine.com>
these hooks are required by the following features:
1.For rwsem readers, currently only the latest reader will be
recorded in sem->owner. We add hooks to record all readers which
have acquired the lock, once there are UX threads blocked in the
rwsem waiting list, these read_owners will be given high
priority in scheduling.
2.For rwsem writer, when a writer acquires the lock, we check
whether there are UX threads blocked in the rwsem wait list. If
so, we give this writer a high priority in scheduling so that it
can release the lock as soon as possible.
Both of these features can optimize the priority inversion
problem caused by rwsem and improve system responsiveness and
performance.
Bug: 335408185
Change-Id: I82a6fbb6acd2ce05d049e686b61e34e4d3b39a5e
Signed-off-by: zhujingpeng <zhujingpeng@vivo.com>
[jstultz: Rebased and resolved minor conflict]
Signed-off-by: John Stultz <jstultz@google.com>
(cherry picked from commit 188c41744ddcccef6daf6dcd4d6a444dabdc2f94)
wlan vendor propose a feature to check the refcnt of netdev when
interface register/unregister. Add `netdev_refcnt_read` into symbol
list.
Adding the following symbols:
- netdev_refcnt_read
Bug: 340118509
Change-Id: I6a2ad4bbfa13d01011729b764dfe92f4945a829e
Signed-off-by: Hsiu-Chang Chen <hsiuchangchen@google.com>
(cherry picked from commit 51cc4ca498)
When a writer has set sem->block and is waiting for active readers
to complete, we still allow some specific new readers to entry
the critical section, which can help prevent priority inversion
from impacting system responsiveness and performance.
Bug: 334851707
Change-Id: I9e2a7df1efb326763487423d64bcf74d8dec23f8
Signed-off-by: zhujingpeng <zhujingpeng@vivo.com>
(cherry picked from commit 458cdb59f7719f81504d392daa95a8c99c30c276)
This adds a special global buffer pool (in the end) for reserved pages.
Using a reserved pool for LZ4 decompression significantly reduces the
time spent on extra temporary page allocation for the extreme cases in
low memory scenarios.
The table below shows the reduction in time spent on page allocation for
LZ4 decompression when using a reserved pool. The results were obtained
from multi-app launch benchmarks on ARM64 Android devices running the
5.15 kernel with an 8-core CPU and 8GB of memory. In the benchmark, we
launched 16 frequently-used apps, and the camera app was the last one in
each round. The data in the table is the average time of camera app for
each round.
After using the reserved pool, there was an average improvement of 150ms
in the overall launch time of our camera app, which was obtained from
the systrace log.
+--------------+---------------+--------------+---------+
| | w/o page pool | w/ page pool | diff |
+--------------+---------------+--------------+---------+
| Average (ms) | 3434 | 21 | -99.38% |
+--------------+---------------+--------------+---------+
Based on the benchmark logs, 64 pages are sufficient for 95% of
scenarios. This value can be adjusted with a module parameter
`reserved_pages`. The default value is 0.
This pool is currently only used for the LZ4 decompressor, but it can be
applied to more decompressors if needed.
Signed-off-by: Chunhai Guo <guochunhai@vivo.com>
Reviewed-by: Gao Xiang <hsiangkao@linux.alibaba.com>
Link: https://lore.kernel.org/r/20240402131523.2703948-1-guochunhai@vivo.com
Signed-off-by: Gao Xiang <hsiangkao@linux.alibaba.com>
Bug: 348591003
Change-Id: I5ed7fe7de3f8dbf20c555b25129120ecc0f6fb54
(cherry picked from commit 0f6273ab46375b62c8dd5c987ce7c15877602831)
[Chunhai: Resolved minor conflict in fs/erofs/internal.h ]
Signed-off-by: Chunhai Guo <guochunhai@vivo.com>
It will cost more time if compressed buffers are allocated on demand for
low-latency algorithms (like lz4) so EROFS uses per-CPU buffers to keep
compressed data if in-place decompression is unfulfilled. While it is kind
of wasteful of memory for a device with hundreds of CPUs, and only a small
number of CPUs concurrently decompress most of the time.
This patch renames it as 'global buffer pool' and makes it configurable.
This allows two or more CPUs to share a common buffer to reduce memory
occupation.
Suggested-by: Gao Xiang <xiang@kernel.org>
Reviewed-by: Gao Xiang <hsiangkao@linux.alibaba.com>
Signed-off-by: Chunhai Guo <guochunhai@vivo.com>
Link: https://lore.kernel.org/r/20240402100036.2673604-1-guochunhai@vivo.com
Signed-off-by: Sandeep Dhavale <dhavale@google.com>
Link: https://lore.kernel.org/r/20240408215231.3376659-1-dhavale@google.com
Signed-off-by: Gao Xiang <hsiangkao@linux.alibaba.com>
Bug: 348591003
Change-Id: I319248d41ce346e840bd292a80b0a0a6bb2a7359
(cherry picked from commit f36f3010f67611a45d66e773bc91e4c66a9abab5)
[Chunhai: Resolved minor conflict in fs/erofs/Makefile,
fs/erofs/internal.h, fs/erofs/super.c, and fs/erofs/zutil.c ]
Signed-off-by: Chunhai Guo <guochunhai@vivo.com>
Currently, utils.c is only useful if CONFIG_EROFS_FS_ZIP is on.
So let's rename it to zutil.c as well as avoid its inclusion if
CONFIG_EROFS_FS_ZIP is explicitly disabled.
Signed-off-by: Chunhai Guo <guochunhai@vivo.com>
Reviewed-by: Gao Xiang <hsiangkao@linux.alibaba.com>
Link: https://lore.kernel.org/r/20240401135550.2550043-1-guochunhai@vivo.com
Signed-off-by: Gao Xiang <hsiangkao@linux.alibaba.com>
Bug: 348591003
Change-Id: Iace477719fb803084955218a3e5ace74338f5ec8
(cherry picked from commit cacd5b04e24c74a813c694ec7b26a1a370b5d666)
[Chunhai: Resolved minor conflict in fs/erofs/Makefile and
fs/erofs/utils.c ]
Signed-off-by: Chunhai Guo <guochunhai@vivo.com>
Even with inplace decompression, sometimes very few temporary buffers
may be still needed for a single decompression shot (e.g. 16 pages for
64k sliding window or 4 pages for 16k sliding window). In low-memory
scenarios, it would be better to try to allocate with GFP_NOWAIT on
readahead first. That can help reduce the time spent on page allocation
under durative memory pressure.
Here are detailed performance numbers under multi-app launch benchmark
workload [1] on ARM64 Android devices (8-core CPU and 8GB of memory)
running a 5.15 LTS kernel with EROFS of 4k pclusters:
+----------------------------------------------+
| LZ4 | vanilla | patched | diff |
|----------------+---------+---------+---------|
| Average (ms) | 3364 | 2684 | -20.21% | [64k sliding window]
|----------------+---------+---------+---------|
| Average (ms) | 2079 | 1610 | -22.56% | [16k sliding window]
+----------------------------------------------+
The total size of system images for 4k pclusters is almost unchanged:
(64k sliding window) 9,117,044 KB
(16k sliding window) 9,113,096 KB
Therefore, in addition to switch the sliding window from 64k to 16k,
after applying this patch, it can eventually save 52.14% (3364 -> 1610)
on average with no memory reservation. That is particularly useful for
embedded devices with limited resources.
[1] https://lore.kernel.org/r/20240109074143.4138783-1-guochunhai@vivo.com
Suggested-by: Gao Xiang <xiang@kernel.org>
Signed-off-by: Chunhai Guo <guochunhai@vivo.com>
Signed-off-by: Gao Xiang <hsiangkao@linux.alibaba.com>
Reviewed-by: Yue Hu <huyue2@coolpad.com>
Link: https://lore.kernel.org/r/20240126140142.201718-1-hsiangkao@linux.alibaba.com
Bug: 348591003
Change-Id: I84cf5b5dbccbd707b6f4339e525ca52efbcf167f
(cherry picked from commit d9281660ff3ffb4a05302b485cc59a87e709aefc)
[Chunhai: Resolved minor conflict in fs/erofs/zdata.c and remove
modification on fs/erofs/decompressor_deflate.c as it is not existed in
6.1 kernel ]
Signed-off-by: Chunhai Guo <guochunhai@vivo.com>
The padding VMA is never inserted into the VMA tree; therefore we
don't need to have the mmap lock in exclusive mode to modify it.
Test: v2/android-gki/ack_platform_integration_main_cf_arm64_boot_test
on kernel_virt_debug_aarch64
Bug: 346741763
Change-Id: I4ca3ed22dab45b6bb895cb41c5c6792344188b61
Signed-off-by: Kalesh Singh <kaleshsingh@google.com>
ufshcd_queuecommand() may be called two times in a row for a SCSI command
before it is completed. Hence make the following changes:
- In the functions that submit a command, do not check the old value of
lrbp->cmd nor clear lrbp->cmd in error paths.
- In ufshcd_release_scsi_cmd(), do not clear lrbp->cmd.
See also scsi_send_eh_cmnd().
This commit prevents that the following appears if a command times out:
WARNING: at drivers/ufs/core/ufshcd.c:2965 ufshcd_queuecommand+0x6f8/0x9a8
Call trace:
ufshcd_queuecommand+0x6f8/0x9a8
scsi_send_eh_cmnd+0x2c0/0x960
scsi_eh_test_devices+0x100/0x314
scsi_eh_ready_devs+0xd90/0x114c
scsi_error_handler+0x2b4/0xb70
kthread+0x16c/0x1e0
Fixes: 5a0b0cb9be ("[SCSI] ufs: Add support for sending NOP OUT UPIU")
Change-Id: Iebc077bc8ae8d8004519ebfc93a1c76a4807b6f2
Signed-off-by: Bart Van Assche <bvanassche@acm.org>
Link: https://lore.kernel.org/r/20230524203659.1394307-3-bvanassche@acm.org
Acked-by: Adrian Hunter <adrian.hunter@intel.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
(cherry picked from commit 549e91a9bb)
[Peter: Resolved minor conflict in drivers/ufs/core/ufshcd.c ]
Signed-off-by: Peter Wang <peter.wang@mediatek.com>
When the lock is owned by readers and there is no RWSEM_FLAG_HANDOFF set,
we allow some specific new readers to acquire the lock immediately
in this hook, event if there are some writer tasks in the wait_list.
This features can optimize the priority inversion problem caused by
rwsem and improve system responsiveness and
performance.
Bug: 348699619
Bug: 336506800
Change-Id: I7e8fded73579933d1f61faa9fb6e5f300ffd71bf
Signed-off-by: zhujingpeng <zhujingpeng@vivo.com>
[jstultz: rebased, resolved collision]
Signed-off-by: John Stultz <jstultz@google.com>
Add hooks to fuse queue request and request end so we can do boost
to those background tasks which block the UX related task.
Bug: 333220630
Change-Id: I9be59ed88675c5102c57ba9cbd26cf4df3d2fd7f
Signed-off-by: liliangliang <liliangliang@vivo.com>
(cherry picked from commit e520c2932df0d1bbf83ae45c82ac01fd41655d77)
HOSTCC is always wanted when building objtool. Setting CC to HOSTCC
happens after tools/scripts/Makefile.include is included, meaning
flags (like CFLAGS) are set assuming say CC is gcc, but then it can be
later set to HOSTCC which may be clang. tools/scripts/Makefile.include
is needed for host set up and common macros in objtool's
Makefile. Rather than override the CC variable to HOSTCC, just pass CC
as HOSTCC to the sub-makes of Makefile.build, the libsubcmd builds and
also to the linkage step.
Signed-off-by: Ian Rogers <irogers@google.com>
Link: https://lore.kernel.org/r/20230126190606.40739-4-irogers@google.com
Signed-off-by: Josh Poimboeuf <jpoimboe@kernel.org>
Bug: 336872347
Bug: 335829879
Test: build x86_64 kernel with glibc 2.38
Change-Id: I1d672d0bb64f72d3fc571537de5f75d4068e79cc
(cherry picked from commit cd955bdd6a)
Signed-off-by: Yifan Hong <elsk@google.com>
Including from tools/lib can create inadvertent dependencies. Install
libsubcmd in the objtool build and then include the headers from
there.
Signed-off-by: Ian Rogers <irogers@google.com>
Link: https://lore.kernel.org/r/20230126190606.40739-2-irogers@google.com
Signed-off-by: Josh Poimboeuf <jpoimboe@kernel.org>
Bug: 336872347
Bug: 335829879
Test: build x86_64 kernel with glibc 2.38
Change-Id: Id09c5b222519073214dbc01e151e59b18afb1ea8
(cherry picked from commit bdb8bf7d56)
Signed-off-by: Yifan Hong <elsk@google.com>
[ Upstream commit 22dd70eb2c3d754862964377a75abafd3167346b ]
Currently, we can read OOB data without MSG_OOB by using MSG_PEEK
when OOB data is sitting on the front row, which is apparently
wrong.
>>> from socket import *
>>> c1, c2 = socketpair(AF_UNIX, SOCK_STREAM)
>>> c1.send(b'a', MSG_OOB)
1
>>> c2.recv(1, MSG_PEEK | MSG_DONTWAIT)
b'a'
If manage_oob() is called when no data has been copied, we only
check if the socket enables SO_OOBINLINE or MSG_PEEK is not used.
Otherwise, the skb is returned as is.
However, here we should return NULL if MSG_PEEK is set and no data
has been copied.
Also, in such a case, we should not jump to the redo label because
we will be caught in the loop and hog the CPU until normal data
comes in.
Then, we need to handle skb == NULL case with the if-clause below
the manage_oob() block.
With this patch:
>>> from socket import *
>>> c1, c2 = socketpair(AF_UNIX, SOCK_STREAM)
>>> c1.send(b'a', MSG_OOB)
1
>>> c2.recv(1, MSG_PEEK | MSG_DONTWAIT)
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
BlockingIOError: [Errno 11] Resource temporarily unavailable
Bug: 342490466
Fixes: 314001f0bf ("af_unix: Add OOB support")
Signed-off-by: Kuniyuki Iwashima <kuniyu@amazon.com>
Link: https://lore.kernel.org/r/20240410171016.7621-3-kuniyu@amazon.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
(cherry picked from commit 022d81a709)
Signed-off-by: Lee Jones <joneslee@google.com>
Change-Id: I4728977f8f908c19dfa5c861c7381a50499b7fe0
[ Upstream commit b46f4eaa4f0ec38909fb0072eea3aeddb32f954e ]
syzkaller started to report deadlock of unix_gc_lock after commit
4090fa373f0e ("af_unix: Replace garbage collection algorithm."), but
it just uncovers the bug that has been there since commit 314001f0bf
("af_unix: Add OOB support").
The repro basically does the following.
from socket import *
from array import array
c1, c2 = socketpair(AF_UNIX, SOCK_STREAM)
c1.sendmsg([b'a'], [(SOL_SOCKET, SCM_RIGHTS, array("i", [c2.fileno()]))], MSG_OOB)
c2.recv(1) # blocked as no normal data in recv queue
c2.close() # done async and unblock recv()
c1.close() # done async and trigger GC
A socket sends its file descriptor to itself as OOB data and tries to
receive normal data, but finally recv() fails due to async close().
The problem here is wrong handling of OOB skb in manage_oob(). When
recvmsg() is called without MSG_OOB, manage_oob() is called to check
if the peeked skb is OOB skb. In such a case, manage_oob() pops it
out of the receive queue but does not clear unix_sock(sk)->oob_skb.
This is wrong in terms of uAPI.
Let's say we send "hello" with MSG_OOB, and "world" without MSG_OOB.
The 'o' is handled as OOB data. When recv() is called twice without
MSG_OOB, the OOB data should be lost.
>>> from socket import *
>>> c1, c2 = socketpair(AF_UNIX, SOCK_STREAM, 0)
>>> c1.send(b'hello', MSG_OOB) # 'o' is OOB data
5
>>> c1.send(b'world')
5
>>> c2.recv(5) # OOB data is not received
b'hell'
>>> c2.recv(5) # OOB date is skipped
b'world'
>>> c2.recv(5, MSG_OOB) # This should return an error
b'o'
In the same situation, TCP actually returns -EINVAL for the last
recv().
Also, if we do not clear unix_sk(sk)->oob_skb, unix_poll() always set
EPOLLPRI even though the data has passed through by previous recv().
To avoid these issues, we must clear unix_sk(sk)->oob_skb when dequeuing
it from recv queue.
The reason why the old GC did not trigger the deadlock is because the
old GC relied on the receive queue to detect the loop.
When it is triggered, the socket with OOB data is marked as GC candidate
because file refcount == inflight count (1). However, after traversing
all inflight sockets, the socket still has a positive inflight count (1),
thus the socket is excluded from candidates. Then, the old GC lose the
chance to garbage-collect the socket.
With the old GC, the repro continues to create true garbage that will
never be freed nor detected by kmemleak as it's linked to the global
inflight list. That's why we couldn't even notice the issue.
Bug: 342490466
Fixes: 314001f0bf ("af_unix: Add OOB support")
Reported-by: syzbot+7f7f201cc2668a8fd169@syzkaller.appspotmail.com
Closes: https://syzkaller.appspot.com/bug?extid=7f7f201cc2668a8fd169
Signed-off-by: Kuniyuki Iwashima <kuniyu@amazon.com>
Reviewed-by: Eric Dumazet <edumazet@google.com>
Link: https://lore.kernel.org/r/20240405221057.2406-1-kuniyu@amazon.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
(cherry picked from commit 601a89ea24)
Signed-off-by: Lee Jones <joneslee@google.com>
Change-Id: Ib4a11eed6b5710d9934d4f31cd29dfd4c7b3658f
The correct fragment is the one in build/kernel,
enabled by --page_size or kernel_build.page_size.
This fragment:
- Does not correctly enable incremental FS
- Does not correctly clear LOCALVERSION that
has 4k for the 4k build.
Bug: 347036722
Bug: 340631213
Bug: 338659380
Change-Id: I31cb004ca639d8ec3dd6201112391c7214971eba
Signed-off-by: Yifan Hong <elsk@google.com>
Recent changes to gki_defconfig enable CONFIG_MEMORY which results
in CONFIG_BRCMSTB_DPFE and CONFIG_BRCMSTB_MEMC being enabled as
builtin modules. Disable the two drivers as the Broadcom STB SoCs
expect them to be configured as loadable modules.
Bug: 346510475
Fixes: 974a6f430e ("ANDROID: gki_defconfig: Enable Tegra SoCs")
Change-Id: I80bf0ce419992d947468b7054327ba80f611d316
Signed-off-by: Danesh Petigara <danesh.petigara@broadcom.com>
Signed-off-by: Pierre Couillaud <pierre@broadcom.com>
Depending on the platform binary being executed, the linker
(interpreter) requested can be one of:
1) /system/bin/bootstrap/linker64
2) /system/bin/linker64
3) /apex/com.android.runtime/bin/linker64
Relax the check to the basename (linker64), instead of the path.
Bug: 330767927
Bug: 335584973
Change-Id: I4a1f95b7cecd126f85ad8cefd9ff10d272947f9e
Signed-off-by: Kalesh Singh <kaleshsingh@google.com>
Usually to modify vm_flags we need to take exclusive mmap_lock but here
only have the lock in read mode, to avoid all DONTNEED/DONTNEED_LOCKED
calls needing the write lock.
A race to the flags update can only happen with another MADV_DONTNEED on
the same process and same range (VMA).
In practice, this specific scenario is not possible because the action
that could cause it is usually performed at most once per VMA and only by the dynamic linker.
Forego protection for this case, to avoid penalties in the common cases.
Bug: 344634072
Change-Id: I54ac1f204e0445291f3df3872fbaa16b37722812
Signed-off-by: Kalesh Singh <kaleshsingh@google.com>
This introduces a new environment variable, KCPPFLAGS_COMPAT.
One use-case is to ensure -ffile-prefix-map is passed to the arm32
compiler to normalise compilation directory and make the ELF build ID
reproducible.
Bug: 345452375
Change-Id: I6ae1df58172f4dadeac1dbbee2e3241b704a9256
Signed-off-by: Giuliano Procida <gprocida@google.com>
