The inclusion of the internal drivers/usb/typec/tcpm/tcpci.h header
broke some androidci builds.
Bug: 233047575
Fixes: f677cbf076 ("ANDROID: GKI: include more type definitions in vendor hooks")
Signed-off-by: Robin Peng <robinpeng@google.com>
Change-Id: I59f2f19889d2646fc5169506df1fba8cfeda305e
The following warning is generated with CONFIG_CONTIG_ALLOC=n build:
include/trace/hooks/mm.h:54:25: warning: 'struct acr_info' declared inside parameter list will not be visible outside of this definition or declaration
Fix this by adding struct acr_info forward declaration.
Fixes: 45cb58e134 ("ANDROID: vendor_hooks: add vendor hoook to report acr_info in cma_alloc()")
Signed-off-by: Suren Baghdasaryan <surenb@google.com>
Change-Id: I88f3f41e65f7239a8ab199bed27f33418566387d
In protected mode, shadow VM structures are created at EL2. They include
shadow vCPUs and their memcache where some pages donated by the host might
be temporarily stored. They need to be freed on VM teardown to not get
lost. Pages found there have not been used for anything by the hypervisor.
Clearing is therefore not necessary.
Bug: 237506543
Change-Id: Ic37d794ac33e9f844fa6ae1b4943febcdad5b033
Signed-off-by: Vincent Donnefort <vdonnefort@google.com>
In an effort to improve ABI coverage, type definitions are now pulled
into vendor hook by #including public and internal kernel headers
where possible.
Exceptional cases (due to build breakage):
* `struct cgroup_taskset` remains forward declared
* `struct uclamp_se` is available in public header but only
conditionally, so it is forward declared as well
Note the changes are all conditional on ! __GENKSYMS__ so that
MODVERSIONS symbol CRCs remain the same.
Bug: 233047575
Change-Id: I8d11b9afb0136fe006772f07affa993e9a8d23d3
Signed-off-by: Giuliano Procida <gprocida@google.com>
fuse bpf
Readdir plus is potentially dangerous place because
this leads us to allocate fuse inodes. If we have
problems with inode allocation and discovery we may
end up with inode conflict which may cause backing_fd
losing.
We currently have this problem and this test clearly
reproduce it.
More information about the problem:
go/fuse-loosing-inode-with-backing
Fixes for this problem:
https://android-review.googlesource.com/c/kernel/common/+/2135866https://android-review.googlesource.com/c/kernel/common/+/2135457
Bug: 219958836
Test: Currently it’s fairly failed, after applying patches from
above it passed.
Co-developed-by: Paul Lawrence <paullawrence@google.com>
Change-Id: I8afb535605faffc9facf626d0c7d0f244dc8d28e
Signed-off-by: Dmitrii Merkurev <dimorinny@google.com>
commit d270453a0d upstream.
There are destructive operations such as nfcmrvl_fw_dnld_abort and
gpio_free in nfcmrvl_nci_unregister_dev. The resources such as firmware,
gpio and so on could be destructed while the upper layer functions such as
nfcmrvl_fw_dnld_start and nfcmrvl_nci_recv_frame is executing, which leads
to double-free, use-after-free and null-ptr-deref bugs.
There are three situations that could lead to double-free bugs.
The first situation is shown below:
(Thread 1) | (Thread 2)
nfcmrvl_fw_dnld_start |
... | nfcmrvl_nci_unregister_dev
release_firmware() | nfcmrvl_fw_dnld_abort
kfree(fw) //(1) | fw_dnld_over
| release_firmware
... | kfree(fw) //(2)
| ...
The second situation is shown below:
(Thread 1) | (Thread 2)
nfcmrvl_fw_dnld_start |
... |
mod_timer |
(wait a time) |
fw_dnld_timeout | nfcmrvl_nci_unregister_dev
fw_dnld_over | nfcmrvl_fw_dnld_abort
release_firmware | fw_dnld_over
kfree(fw) //(1) | release_firmware
... | kfree(fw) //(2)
The third situation is shown below:
(Thread 1) | (Thread 2)
nfcmrvl_nci_recv_frame |
if(..->fw_download_in_progress)|
nfcmrvl_fw_dnld_recv_frame |
queue_work |
|
fw_dnld_rx_work | nfcmrvl_nci_unregister_dev
fw_dnld_over | nfcmrvl_fw_dnld_abort
release_firmware | fw_dnld_over
kfree(fw) //(1) | release_firmware
| kfree(fw) //(2)
The firmware struct is deallocated in position (1) and deallocated
in position (2) again.
The crash trace triggered by POC is like below:
BUG: KASAN: double-free or invalid-free in fw_dnld_over
Call Trace:
kfree
fw_dnld_over
nfcmrvl_nci_unregister_dev
nci_uart_tty_close
tty_ldisc_kill
tty_ldisc_hangup
__tty_hangup.part.0
tty_release
...
What's more, there are also use-after-free and null-ptr-deref bugs
in nfcmrvl_fw_dnld_start. If we deallocate firmware struct, gpio or
set null to the members of priv->fw_dnld in nfcmrvl_nci_unregister_dev,
then, we dereference firmware, gpio or the members of priv->fw_dnld in
nfcmrvl_fw_dnld_start, the UAF or NPD bugs will happen.
This patch reorders destructive operations after nci_unregister_device
in order to synchronize between cleanup routine and firmware download
routine.
The nci_unregister_device is well synchronized. If the device is
detaching, the firmware download routine will goto error. If firmware
download routine is executing, nci_unregister_device will wait until
firmware download routine is finished.
Bug: 234690530
Fixes: 3194c68701 ("NFC: nfcmrvl: add firmware download support")
Signed-off-by: Duoming Zhou <duoming@zju.edu.cn>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
Change-Id: I8cc1f6450c7fecf5f5994033931da1d23a522282
Usage of uninitialized boolean is potentially can cause annoying
and “hard to catch” types of problems. Currently we have 1
case where we use uninitialized boolean:
int fuse_readdir(struct file *file, struct dir_context *ctx)
And I constantly see that every userspace readdir operation
causes an infinite cycle inside the Kernel for my QEMU tests
(gcc).
This problem isn’t reproducible inside cuttlefish, probably
because we use clang toolchain.
Bug: 219958836
Test: atest ScopedStorageDeviceTest
Test: selftests
Change-Id: I2c38056448cd2910e0cb20da5839d7db9ebd26b9
Signed-off-by: Dmitrii Merkurev <dimorinny@google.com>
for regular FUSE fuse_iget
Currently, when we’re trying to find inode based on their
backing inode we strictly checking on nodeid == 0, so
basically we’re not supporting nodeid != 0 for inode,
which is backed by another one. Alongside with this, we’re
using backing_inode as a hash for inode which make this inode
not reachable for regular FUSE fuse_iget that as a result
causing backing_inode losing because instead of getting
existent one (with backing inode) we create a new one as
a part of readdirplus.
For more details please check: go/fuse-loosing-inode-with-backing
Bug: 219958836
Test: Manually checked that /data and /obb inodes
always have inode numbers configured.
Co-developed-by: Paul Lawrence <paullawrence@google.com>
Change-Id: If6a5fb340561ac6320d3c4e86215f1bcd4c2c10c
Signed-off-by: Dmitrii Merkurev <dimorinny@google.com>
commit ee1fee9005 upstream.
Setting PTRACE_O_SUSPEND_SECCOMP is supposed to be a highly privileged
operation because it allows the tracee to completely bypass all seccomp
filters on kernels with CONFIG_CHECKPOINT_RESTORE=y. It is only supposed to
be settable by a process with global CAP_SYS_ADMIN, and only if that
process is not subject to any seccomp filters at all.
However, while these permission checks were done on the PTRACE_SETOPTIONS
path, they were missing on the PTRACE_SEIZE path, which also sets
user-specified ptrace flags.
Move the permissions checks out into a helper function and let both
ptrace_attach() and ptrace_setoptions() call it.
Bug: 233438137
Cc: stable@kernel.org
Fixes: 13c4a90119 ("seccomp: add ptrace options for suspend/resume")
Signed-off-by: Jann Horn <jannh@google.com>
Link: https://lkml.kernel.org/r/20220319010838.1386861-1-jannh@google.com
Signed-off-by: Eric W. Biederman <ebiederm@xmission.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
Change-Id: Ic2f98b220f24ff2f27b1d4aadd5c6d6dca2678ed
This patch adds __sched attributes to a few missing places
to show blocked function rather than locking function
in get_wchan.
Signed-off-by: Minchan Kim <minchan@kernel.org>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Link: https://lkml.kernel.org/r/20220115231657.84828-1-minchan@kernel.org
Conflicts:
kernel/locking/percpu-rwsem.c
1. conflict <linux/sched/debug.h>
Bug: 228243692
Change-Id: Ifb50c13cfdd7484269d9a291a8da515e1cce6a7b
(cherry picked from commit c441e934b6)
Signed-off-by: Minchan Kim <minchan@google.com>
commit 69534c48ba upstream.
We have no protection against concurrent PCM buffer preallocation
changes via proc files, and it may potentially lead to UAF or some
weird problem. This patch applies the PCM open_mutex to the proc
write operation for avoiding the racy proc writes and the PCM stream
open (and further operations).
Bug: 232293337
Cc: <stable@vger.kernel.org>
Reviewed-by: Jaroslav Kysela <perex@perex.cz>
Link: https://lore.kernel.org/r/20220322170720.3529-5-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
Change-Id: I52d0347c440b87c700b28e082eee9ab9d3ec4910
commit 3c3201f8c7 upstream.
Like the previous fixes to hw_params and hw_free ioctl races, we need
to paper over the concurrent prepare ioctl calls against hw_params and
hw_free, too.
This patch implements the locking with the existing
runtime->buffer_mutex for prepare ioctls. Unlike the previous case
for snd_pcm_hw_hw_params() and snd_pcm_hw_free(), snd_pcm_prepare() is
performed to the linked streams, hence the lock can't be applied
simply on the top. For tracking the lock in each linked substream, we
modify snd_pcm_action_group() slightly and apply the buffer_mutex for
the case stream_lock=false (formerly there was no lock applied)
there.
Bug: 232293337
Cc: <stable@vger.kernel.org>
Reviewed-by: Jaroslav Kysela <perex@perex.cz>
Link: https://lore.kernel.org/r/20220322170720.3529-4-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
Change-Id: Idcb26b8b178b9617e44443f2ca093074b76068b0
commit dca947d4d2 upstream.
In the current PCM design, the read/write syscalls (as well as the
equivalent ioctls) are allowed before the PCM stream is running, that
is, at PCM PREPARED state. Meanwhile, we also allow to re-issue
hw_params and hw_free ioctl calls at the PREPARED state that may
change or free the buffers, too. The problem is that there is no
protection against those mix-ups.
This patch applies the previously introduced runtime->buffer_mutex to
the read/write operations so that the concurrent hw_params or hw_free
call can no longer interfere during the operation. The mutex is
unlocked before scheduling, so we don't take it too long.
Bug: 232293337
Cc: <stable@vger.kernel.org>
Reviewed-by: Jaroslav Kysela <perex@perex.cz>
Link: https://lore.kernel.org/r/20220322170720.3529-3-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
Change-Id: I4ec9ab14347e88de6b51025b845d13514ac289e9
A portion of the fix for CVE-2022-1048, commit 0f6947f5f5 ("ALSA: pcm:
Fix races among concurrent hw_params and hw_free calls"), caused an ABI
break by adding a new field to struct snd_pcm_runtime. Because we have
to keep this new addition, it is safe to move it to the end of the
structure because this is only ever created by the sound core, and
referenced as a pointer everywhere else.
This does require a .xml update also to handle the increased structure
size:
Leaf changes summary: 1 artifact changed
Changed leaf types summary: 1 leaf type changed
Removed/Changed/Added functions summary: 0 Removed, 0 Changed, 0 Added function
Removed/Changed/Added variables summary: 0 Removed, 0 Changed, 0 Added variable
'struct snd_pcm_runtime at pcm.h:344:1' changed:
type size changed from 6144 to 6528 (in bits)
1 data member insertion:
'mutex buffer_mutex', at offset 6144 (in bits) at pcm.h:432:1
72 impacted interfaces
Bug: 161946584
Fixes: 0f6947f5f5 ("ALSA: pcm: Fix races among concurrent hw_params and hw_free calls")
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
[Lee: Update XML files for this branch]
Signed-off-by: Lee Jones <lee.jones@linaro.org>
Change-Id: I20340387fbe85fb82676517a93bb0184c8c1eb65
commit 92ee3c60ec upstream.
Currently we have neither proper check nor protection against the
concurrent calls of PCM hw_params and hw_free ioctls, which may result
in a UAF. Since the existing PCM stream lock can't be used for
protecting the whole ioctl operations, we need a new mutex to protect
those racy calls.
This patch introduced a new mutex, runtime->buffer_mutex, and applies
it to both hw_params and hw_free ioctl code paths. Along with it, the
both functions are slightly modified (the mmap_count check is moved
into the state-check block) for code simplicity.
Bug: 5d95acffca
Reported-by: Hu Jiahui <kirin.say@gmail.com>
Cc: <stable@vger.kernel.org>
Reviewed-by: Jaroslav Kysela <perex@perex.cz>
Link: https://lore.kernel.org/r/20220322170720.3529-2-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
Change-Id: I33b5ed3d1f38904e215692a236fe39e8b3ee1f15
to execute backing revalidate"
This reverts commit b610eff230.
Reason for revert: I broke BPF calling logic with this one. Possible
fix is here:
https://android-review.googlesource.com/c/kernel/common/+/2132134 but
we're still discussing possible way to go there:
go/fuse-bpf-revalidate-problem
Change-Id: I517941a2c341999dc8133b93cf045ec67bcf8a9e
Signed-off-by: Dmitrii Merkurev <dimorinny@google.com>
__ffa_host_{un}share_ranges() returns the number of {un}shared pages,
and not 0 upon success, so make sure to check for that in the error path
of ffa_host_{un}share_ranges().
Bug: 236751556
Signed-off-by: Quentin Perret <qperret@google.com>
Change-Id: Ie122e394f1bc4ce79fcbb24d2a5c58cd53b3c146
Setting CONFIG_PM_ADVANCED_DEBUG=y to expose device async fields
to userspace, allowing to fine-tune the suspend/resume path.
Bug: 235135485
Change-Id: I75060e88ce0c1e199aa8740f446a2c0f8167f3d7
Signed-off-by: Vincent Palomares <paillon@google.com>
Made iostat related locks safe to be called from irq context again.
Bug: 233000474
Cc: <stable@vger.kernel.org>
Fixes: a1e09b03e6 ("f2fs: use iomap for direct I/O")
Signed-off-by: Daeho Jeong <daehojeong@google.com>
Reviewed-by: Stanley Chu <stanley.chu@mediatek.com>
Tested-by: Eddie Huang <eddie.huang@mediatek.com>
Signed-off-by: Jaegeuk Kim <jaegeuk@kernel.org>
(cherry picked from commit f8ed39ad779fbc5d37d08e83643384fc06e4bae4 git://git.kernel.org/pub/scm/linux/kernel/git/jaegeuk/f2fs.git dev)
Change-Id: I8f6288b1fa80ba80be316d6f248216a260461e2f
Recently, we noticed an issue where a process went into direct reclaim
while holding the kernfs rw semaphore for sysfs in write (exclusive)
mode. This caused processes who were doing DMA-BUF exports and releases
to go into uninterruptible sleep since they needed to acquire the same
semaphore for the DMA-BUF sysfs entry creation/deletion. In order to avoid
blocking DMA-BUF export for an indeterminate amount of time while
another process is holding the sysfs rw semaphore in exclusive mode,
this patch moves the per-buffer sysfs file creation to the default work
queue. Note that this can lead to a short-term inaccuracy in the dmabuf
sysfs statistics, but this is a tradeoff to prevent the hot path from
being blocked. A work_struct is added to dma_buf to achieve this, but as
it is unioned with the kobject in the sysfs_entry, dma_buf does not
increase in size.
Fixes: bdb8d06dfe ("dmabuf: Add the capability to expose DMA-BUF stats in sysfs")
Originally-by: Hridya Valsaraju <hridya@google.com>
Signed-off-by: T.J. Mercier <tjmercier@google.com>
Bug: 206979019
Link: https://lore.kernel.org/lkml/CABdmKX2dNYhgOYdrrJU6-jt6F=LjCidbKhR6t4F7yaa0SPr+-A@mail.gmail.com/T/
Conflicts:
include/linux/dma-buf.h
1. The android13-5.10 KMI is frozen, and the modification to struct
dma_buf_sysfs_entry in the original patch triggers ABI check
failures. Instead of an anonymous union, use the existing struct
kobject directly as a work_struct with type punning.
(cherry picked from commit b78809ea5239174f9282b6a8e323baa7c5c231c0
https://android.git.corp.google.com/kernel/common android13-5.15)
Signed-off-by: T.J. Mercier <tjmercier@google.com>
Change-Id: Ic0386849b6b248b0a72215633fc1a50782455bac
By this vh, you can made your policy of ALLOC_CMA.
ex: skip __GFP_CMA to allow file-backed memory on CMA area
Bug: 234498088
Signed-off-by: Edward Wu <edwardwu@realtek.com>
Change-Id: Ief8de1f82885abeddbb6c0b625f7deca9fd74f6b
Add android_vh_cma_alloc_busy_info vh after EBUSY not only useful
for profiling but also pinned page handling.
Bug: 234498088
Signed-off-by: Edward Wu <edwardwu@realtek.com>
Change-Id: If1de7b63c431a79889e932ff3363314199175cce
This locks down OWNERS approval to a small group to guard against
unintentional breakages.
Bug: 235646184
Signed-off-by: Steve Muckle <smuckle@google.com>
Change-Id: I58ca467b1e7786e1ad0f6ad67c7a7a5845a91ec6
We've recently added a .data section for the hypervisor, which kmemleak
is eager to parse. This clearly doesn't go well, so add the section to
kmemleak's block list.
Bug: 235903024
Signed-off-by: Quentin Perret <qperret@google.com>
Change-Id: I29d81cb1246c590bd5203d560ea369e5f29d59b0
Degradation of write speed caused by frequent disk access for cluster
bitmap update on every cluster allocation could be improved by
selective syncing bitmap buffer. Change to flush bitmap buffer only
for the directory related operations.
Signed-off-by: Hyeongseok Kim <hyeongseok@gmail.com>
Acked-by: Sungjong Seo <sj1557.seo@samsung.com>
Signed-off-by: Namjae Jeon <namjae.jeon@samsung.com>
Change-Id: I660931d6da488880337a33dd03b48cb0be0bb26c
Signed-off-by: Howard Chen <howardsoc@google.com>
(cherry picked from commit 23befe490b)
Bug: 233712676
Prevent that both the interrupt handler and the reset handler try to
complete a request at the same time. This patch is the result of an
analysis of the following crash:
Unable to handle kernel NULL pointer dereference at virtual address 0000000000000120
CPU: 0 PID: 0 Comm: swapper/0 Tainted: G OE 5.10.107-android13-4-00051-g1e48e8970cca-ab8664745 #1
pc : ufshcd_release_scsi_cmd+0x30/0x46c
lr : __ufshcd_transfer_req_compl+0x4fc/0x9c0
Call trace:
ufshcd_release_scsi_cmd+0x30/0x46c
__ufshcd_transfer_req_compl+0x4fc/0x9c0
ufshcd_poll+0xf0/0x208
ufshcd_sl_intr+0xb8/0xf0
ufshcd_intr+0x168/0x2f4
__handle_irq_event_percpu+0xa0/0x30c
handle_irq_event+0x84/0x178
handle_fasteoi_irq+0x150/0x2e8
__handle_domain_irq+0x114/0x1e4
gic_handle_irq.31846+0x58/0x300
el1_irq+0xe4/0x1c0
cpuidle_enter_state+0x3ac/0x8c4
do_idle+0x2fc/0x55c
cpu_startup_entry+0x84/0x90
kernel_init+0x0/0x310
start_kernel+0x0/0x608
start_kernel+0x4ec/0x608
Signed-off-by: Bart Van Assche <bvanassche@acm.org>
Bug: 235425408
Link: https://lore.kernel.org/all/20220613214442.212466-4-bvanassche@acm.org/
Change-Id: I94c325581929e11cfb6beb2be868e510adfd2410
Signed-off-by: Bart Van Assche <bvanassche@google.com>
Modify ufshcd_clear_cmd() such that it supports clearing multiple
commands at once instead of one command at a time. This change will be
used in a later patch to reduce the time spent in the reset handler.
Signed-off-by: Bart Van Assche <bvanassche@acm.org>
Bug: 235425408
Link: https://lore.kernel.org/all/20220613214442.212466-3-bvanassche@acm.org/
Change-Id: I18ad8e5f2e5cb6792339cceb606dd1f1c9012ce1
Signed-off-by: Bart Van Assche <bvanassche@google.com>
This adds <10 seconds for a LTO=thin build, while the original
build time is about ~250 seconds on a build machine with 48 2.60 GHz
processors and 64GB RAM.
Within the 10 seconds, ~3 seconds spent on building Image.gz,
~5 seconds for packing Image.gz as boot-gz.img and <1 second for
including the boot-gz.img into the boot-img.tar.gz.
Bug: 233352819
Test: LTO=thin BUILD_CONFIG=common/build.config.gki.aarch64 build/build.sh
Signed-off-by: Bowgo Tsai <bowgotsai@google.com>
Change-Id: I283ef004d1233d2e175573b893379e0d68221353
(cherry picked from commit 2ad997b4d1)
Do not defer softirq processing when RT throttling.
Otherwise softirq process would be deferred indefinitely.
Bug: 234597245
Test: Trigger RT Throttling and check RT & softirq behavior
Fixes: "ANDROID: softirq: defer softirq processing to ksoftirqd if CPU is busy with RT"
Signed-off-by: Luke Chang <lukechang@google.com>
Change-Id: I76df270c39ce8c0633b914c3354a27d6e559ec94
During a reply, the target gets woken up and then the priority of the
replier is restored. The order is such to allow the target to process
the reply ASAP. Otherwise, we risk the sender getting scheduled out
before the wakeup happens. This strategy reduces transaction latency.
However, a subsequent transaction from the same target could be started
before the priority of the replier gets restored. At this point we save
the wrong priority and it gets reinstated at the end of the transaction.
This patch allows the incoming transaction to detect the race condition
and save the correct next priority. Additionally, the replier will abort
its pending priority restore which allows the new transaction to always
run at the desired priority.
Bug: 148101660
Signed-off-by: Carlos Llamas <cmllamas@google.com>
Change-Id: I6fec41ae1a1342023f78212ab1f984e26f068221
(cherry picked from commit cac827f261)
[cmllamas: fixed trivial merge conflict]
Refactor binder priority functions to take in 'struct binder_thread *'
instead of just 'struct task_struct *'. This allows access to other
thread fields used in subsequent patches. In any case, the same task
reference is still available under thread->task.
There is no functional impact from this patch.
Bug: 148101660
Signed-off-by: Carlos Llamas <cmllamas@google.com>
Change-Id: I67b599884580d957d776500e467827e5035c99f6
(cherry picked from commit 759d98484b)
Avoid making unnecessary stack copies of struct binder_priority and pass
the argument by reference instead. Rename 'desired_prio' to 'desired' to
match the usage in other priority functions.
There is no functional impact from this patch.
Bug: 148101660
Signed-off-by: Carlos Llamas <cmllamas@google.com>
Change-Id: I66ff5305296e7b9dba56ed265236f2af518f66e0
(cherry picked from commit 52d85f8a16)
[cmllamas: fixed conflict with vendor hook patch]
The setup of node_prio is always the same, so just fold this logic into
binder_transaction_priority() to avoid duplication. Let's pass the node
reference instead, which also gives access to node->inherit_rt.
There is no functional impact from this patch.
Bug: 148101660
Signed-off-by: Carlos Llamas <cmllamas@google.com>
Change-Id: Ib390204556e69c4bc8492cd9cd873773f9cdce42
(cherry picked from commit 498bf715b7)
[cmllamas: fixed conflict with vendor hook patch]
Vendor may have the need to implement their cpu distribution functions.
Bug: 233279911
Signed-off-by: chungkai <chungkai@google.com>
Change-Id: I46f4be9570819d170d6e0bd82cf3a2cac68c96ef
commit e677edbcab upstream.
io_flush_timeouts() assumes the timeout isn't in progress of triggering
or being removed/canceled, so it unconditionally removes it from the
timeout list and attempts to cancel it.
Leave it on the list and let the normal timeout cancelation take care
of it.
Bug: 231494876
Cc: stable@vger.kernel.org # 5.5+
Signed-off-by: Jens Axboe <axboe@kernel.dk>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
Change-Id: Ie7dba41da32732391f8a85526fe20168bd431be8
When handling host stage-2 faults the hypervisor currently updates the
CPU _and_ IOMMUs page-tables. However, since we currently proactively
map accessible PA ranges into IOMMUs, updating them during stage-2
faults is unnecessary -- it only needs to be done during ownership
transitions. Optimize this by skipping the IOMMU updates from the host
memory abort path, which also reduces contention on the host stage-2
lock during boot and saves up to 1.1 sec of boot time on Pixel 6.
Bug: 232879742
Change-Id: I71f439311fe9573005efcc9529a2be53f21993a4
Signed-off-by: Quentin Perret <qperret@google.com>
The boot.img will be used for GKI testing.
Also removing BUILD_GKI_CERTIFICATION_TOOLS=1, because
we only need to certify GKI boot-*.img for aarch64.
Bug: 232906147
Test: BUILD_CONFIG=common/build.config.gki.x86_64 build/build.sh
Signed-off-by: Bowgo Tsai <bowgotsai@google.com>
Change-Id: Ia6790dc9faddce7c616411d7ec5c1f60a12aea44
(cherry picked from commit a80c9ffa86)
Add vendor hook for compaction begin/end. The first use would be
to measure compaction durations.
Bug: 229927848
Test: local kernel build test
Signed-off-by: Robin Hsu <robinhsu@google.com>
Change-Id: I3d95434bf49b37199056dc9ddfc36a59a7de17b7
Without initialization, it will be random data and hard for
vendor hook to decide.
Bug: 207739506
Change-Id: I278772d87eea38c03a40d4f0bef20ac8644e2ecd
Signed-off-by: Maria Yu <quic_aiquny@quicinc.com>
(cherry picked from commit 898e7ec950)
One may want to have DF set on large packets to support discovering
path mtu and limiting the size of generated packets (hence not
setting the XFRM_STATE_NOPMTUDISC tunnel flag), while still
supporting networks that are incapable of carrying even minimal
sized IPv6 frames (post encapsulation).
Having IPv4 Don't Frag bit set on encapsulated IPv6 frames that
are not larger than the minimum IPv6 mtu of 1280 isn't useful,
because the resulting ICMP Fragmentation Required error isn't
actionable (even assuming you receive it) because IPv6 will not
drop it's path mtu below 1280 anyway. While the IPv4 stack
could prefrag the packets post encap, this requires the ICMP
error to be successfully delivered and causes a loss of the
original IPv6 frame (thus requiring a retransmit and latency
hit). Luckily with IPv4 if we simply don't set the DF flag,
we'll just make further fragmenting the packets some other
router's problems.
We'll still learn the correct IPv4 path mtu through encapsulation
of larger IPv6 frames.
I'm still not convinced this patch is entirely sufficient to make
everything happy... but I don't see how it could possibly
make things worse.
See also recent:
4ff2980b6b 'xfrm: fix tunnel model fragmentation behavior'
and friends
Cc: Lorenzo Colitti <lorenzo@google.com>
Cc: Eric Dumazet <edumazet@google.com>
Cc: Lina Wang <lina.wang@mediatek.com>
Cc: Steffen Klassert <steffen.klassert@secunet.com>
Signed-off-by: Maciej Zenczykowski <maze@google.com>
Signed-off-by: Steffen Klassert <steffen.klassert@secunet.com>
(cherry picked from commit 6821ad8770https://git.kernel.org/pub/scm/linux/kernel/git/klassert/ipsec.git master)
Bug: 203183943
Test: TreeHugger
Signed-off-by: Maciej Żenczykowski <maze@google.com>
Change-Id: Ie7701ebc63b1e2a974114538befd278154eb3bc6
If the ring is setup with IORING_SETUP_IOPOLL and we have more than
one task doing submissions on a ring, we can up in a situation where
we assign the context from the current task rather than the request
originator.
Always use req->task rather than assume it's the same as current.
No upstream patch exists for this issue, as only older kernels with
the non-native workers have this problem.
Bug: 233078742
Reported-by: Kyle Zeng <zengyhkyle@gmail.com>
Signed-off-by: Jens Axboe <axboe@kernel.dk>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Akilesh Kailash <akailash@google.com>
(cherry picked from commit 29f077d070
from linux-5.10.y stable branch)
Change-Id: I4cc543950a95e1df201fa9867c5e9c272fd54b6f
