Now that the branch is used to create production GKI
images, need to institute ACK DrNo for all commits.
The DrNo approvers are in the android-mainline branch
at /OWNERS_DrNo.
Bug: 240999246
Signed-off-by: Todd Kjos <tkjos@google.com>
Change-Id: Id5bb83d7add5f314df6816c1c51b4bf2d8018e79
kernelci reported the following error when !CONFIG_FUSE_BPF:
fs/fuse/dir.c:269:40: error: no member named 'backing_inode' in 'struct fuse_inode'
Fixed by wrapping that new code in #ifdef CONFIG_FUSE_BPF.
Fixes: 094905c877 ("ANDROID: fuse-bpf: Always call revalidate for
backing")
Signed-off-by: Todd Kjos <tkjos@google.com>
Change-Id: I08760f340cebf21d3084ca84ac1792bc70f311ff
We recently noticed an issue where freezing of user space tasks
is failed due to a process being in uninterruptible sleep state.
Currently, the logging of unfrozen tasks is disabled by default.
Although it can be enabled for debugging via a adb command, it's
usually hard to reproduce the issue. So we want to add a vendor
hook to log unfrozen tasks.
Bug: 240091483
Test: all presubmit tests passed
Change-Id: Ief3d4196ea7220d4897c00a37ab96f456dbf2259
Signed-off-by: Darren Hsu <darrenhsu@google.com>
094905c877 ("ANDROID: fuse-bpf: Always call revalidate for backing")
called dget_parent/dput improperly within an RCU context. Additionally,
it failed to free/put some references.
Fixes: 094905c877 ("ANDROID: fuse-bpf: Always call revalidate for backing")
Signed-off-by: Daniel Rosenberg <drosen@google.com>
Change-Id: Iedeee7550ff88366bc5310eedece285019336814
If 'dirsync' is enabled, when zeroing a cluster, submitting
sector by sector will generate many block requests, will
cause the block device to not fully perform its performance.
This commit makes the sectors in a cluster to be submitted in
once, it will reduce the number of block requests. This will
make the block device to give full play to its performance.
Test create 1000 directories on SD card with:
$ time (for ((i=0;i<1000;i++)); do mkdir dir${i}; done)
Performance has been improved by more than 73% on imx6q-sabrelite.
Cluster size Before After Improvement
64 KBytes 3m34.036s 0m56.052s 73.8%
128 KBytes 6m2.644s 1m13.354s 79.8%
256 KBytes 11m22.202s 1m39.451s 85.4%
imx6q-sabrelite:
- CPU: 792 MHz x4
- Memory: 1GB DDR3
- SD Card: SanDisk 8GB Class 4
Bug: 239500767
Signed-off-by: Yuezhang Mo <Yuezhang.Mo@sony.com>
Reviewed-by: Andy Wu <Andy.Wu@sony.com>
Reviewed-by: Aoyama Wataru <wataru.aoyama@sony.com>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Acked-by: Sungjong Seo <sj1557.seo@samsung.com>
(cherry picked from commit 1b61383854)
Signed-off-by: Namjae Jeon <linkinjeon@kernel.org>
Signed-off-by: liujinbao1 <liujinbao1@xiaomi.com>
Change-Id: Ie9ed20fb90caed2fce2692f7fb81272cf647faa7
emulation_proc_handler() changes table->data for proc_dointvec_minmax
and can generate the following Oops if called concurrently with itself:
| Unable to handle kernel NULL pointer dereference at virtual address 0000000000000010
| Internal error: Oops: 96000006 [#1] SMP
| Call trace:
| update_insn_emulation_mode+0xc0/0x148
| emulation_proc_handler+0x64/0xb8
| proc_sys_call_handler+0x9c/0xf8
| proc_sys_write+0x18/0x20
| __vfs_write+0x20/0x48
| vfs_write+0xe4/0x1d0
| ksys_write+0x70/0xf8
| __arm64_sys_write+0x20/0x28
| el0_svc_common.constprop.0+0x7c/0x1c0
| el0_svc_handler+0x2c/0xa0
| el0_svc+0x8/0x200
To fix this issue, keep the table->data as &insn->current_mode and
use container_of() to retrieve the insn pointer. Another mutex is
used to protect against the current_mode update but not for retrieving
insn_emulation as table->data is no longer changing.
Bug: 237540956
Co-developed-by: hewenliang <hewenliang4@huawei.com>
Signed-off-by: hewenliang <hewenliang4@huawei.com>
Signed-off-by: Haibin Zhang <haibinzhang@tencent.com>
Reviewed-by: Catalin Marinas <catalin.marinas@arm.com>
Link: https://lore.kernel.org/r/20220128090324.2727688-1-hewenliang4@huawei.com
Link: https://lore.kernel.org/r/9A004C03-250B-46C5-BF39-782D7551B00E@tencent.com
Signed-off-by: Will Deacon <will@kernel.org>
[Lee: Added Fixes: tag]
(cherry picked from commit af483947d4
git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux.git for-next/core)
Fixes: 587064b610 ("arm64: Add framework for legacy instruction emulation")
Signed-off-by: Lee Jones <joneslee@google.com>
Change-Id: If9b96bb79c79903f9d8292e719b06fdef57ef1c5
If a completion happens after wait_for_completion_timeout() times out
and before ufshcd_clear_cmds() is called then the completion code
may crash on the complete() call in __ufshcd_transfer_req_compl(). This
patch fixes the following crash:
Unable to handle kernel NULL pointer dereference at virtual address 0000000000000008
Call trace:
complete+0x64/0x178
__ufshcd_transfer_req_compl+0x30c/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
efi_header_end+0x110/0x680
__irq_exit_rcu+0x108/0x124
__handle_domain_irq+0x118/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
Bug: 238156478
Link: https://lore.kernel.org/linux-scsi/20220713184008.2232094-1-bvanassche@acm.org/T/#u
Change-Id: Icf646e1e536e2d4918e5625574117f6f42e1ff7d
Signed-off-by: Bart Van Assche <bvanassche@google.com>
Add memcg support for hooks in the reclaim path
Bug: 230450931
Change-Id: Ia3e6949985d915c8640139fbb93800d91e1e46f8
Signed-off-by: xiaofeng <xiaofeng5@xiaomi.com>
As it turns out, the kernel's DMA code doesn't enforce the
SG_MAX_SEGMENTS limit on the number of elements in an sglist, which can
confuse the pKVM FF-A proxy which has a buffer sized to contain a
descriptor of at most SG_MAX_SEGMENTS constituents.
As the number of elements in an sglist doesn't seem to have an actual
upper bound, let's paper over the issue for now by increasing the size
of the pKVM buffer based on empirical 'measurements'. Longer term we
might need to make this value configurable on the kernel's cmdline, or
to rework the FF-A proxy to sanely handle large descriptors, although
this is not clear how at the time of writing.
Bug: 221256863
Signed-off-by: Quentin Perret <qperret@google.com>
Change-Id: If252f01bec8ae71c0fe1f7007a3ca7b037924c84
If we have a backing dentry, we must call it's revalidate always, or we
may end up using an invalid lower dentry. Revalidate is called for
dentries, not inodes, and the dentry may be negative. This goes against
all of the macro conventions, so we're just calling the backing function
directly.
Signed-off-by: Daniel Rosenberg <drosen@google.com>
Bug: 219958836
Test: fuse_test
Change-Id: Ia28da5bd2ce42b40466c577137d5440d9f2f6600
Cleaned up some args, and adjusted so we can choose to not update the
actual values for the next patch.
Test: fuse_test
Bug: 219958836
Change-Id: I025b7026357b119e2cd588f25f0976f5d4b68090
Signed-off-by: Daniel Rosenberg <drosen@google.com>
Currently we have 2 different problems
1. Every revalidate considered as a error because of added
args->out_argvar = true; inside fuse_lookup_init which makes
fuse_simple_request return out argument size which is
considered as an error by revalidate code.
2. We’re ignoring backing_fd and bpf_program set by daemon
lookup code called by revalidate.
Problem 1 makes any revalidate (lookup to userspace) useless and any result
lead us to the full lookup because it was interpreted as an error.
This CL fixes both and introducing revalidate test case which makes sure:
1. We’re receiving only one lookup as a part of revalidate
2. We’re setting backing_fd as a part of revalidate’s lookup result
Test is failed before the fix and passed after.
Bug: 219958836
Test: Booted device 5 times to make sure we’re not receiving redundant
lookups anymore.
Test: selftests
Signed-off-by: Dmitrii Merkurev <dimorinny@google.com>
Change-Id: Ifa62e56b42ca5580b25682eb5f16b5c91826cf49
If we have a nodeid of 0, we've probably got a backing inode, and a
regular getattr will be fast. Otherwise, userspace is likely ill suited
to properly handle a readdirplus anyways.
Test: fuse_test
Bug: 219958836
Signed-off-by: Daniel Rosenberg <drosen@google.com>
Change-Id: I02f031d87dcc5fcbe1e080e4f8ec92187b00fe2d
get_fuse_inode uses container_of, which results in a strange result if
the inode is NULL. We should check if the inode is NULL instead.
Fixes: 4ad093cae1 ("ANDROID: fuse-bpf: Make inodes with backing_fd reachable")
Bug: 219958836
Change-Id: I386c4641edaa4dbc8d8e02f592c959c206851eda
Signed-off-by: Daniel Rosenberg <drosen@google.com>
It is observed that certain file accesses are failing when
speculative file faults are enabled via "allow_file_spec_access".
This is because of not unlocking the page on error in
filemap_map_pages, and the locked page causes endless retry of
fault.
Bug: 199706590
Fixes: 35eacb5c87 ("ANDROID: mm: allow vmas with vm_ops to be speculatively handled")
Change-Id: Ic7643ea8188aa281754318866fde09eea094c5da
Signed-off-by: Vinayak Menon <vinmenon@codeaurora.org>
(cherry picked from commit 4d9d866fe5)
The purpose of this vendor hook is to calculating
the total resume latency for device, CPU and
console, etc. Current vendor hook only supports
individual resume latency for device, each individual
CPU, etc, but lacking of the total resume latency tracing.
Bug: 232541623
Signed-off-by: Sophia Wang <yodagump@google.com>
Change-Id: Idd7c999dcd822cc0f7747baa11ec200eed5f5172
When the target process is busy, incoming oneway transactions are
queued in the async_todo list. If the clients continue sending extra
oneway transactions while the target process is frozen, this queue can
become too large to accommodate new transactions. That's why binder
driver introduced ONEWAY_SPAM_DETECTION to detect this situation. It's
helpful to debug the async binder buffer exhausting issue, but the
issue itself isn't solved directly.
In real cases applications are designed to send oneway transactions
repeatedly, delivering updated inforamtion to the target process.
Typical examples are Wi-Fi signal strength and some real time sensor
data. Even if the apps might only care about the lastet information,
all outdated oneway transactions are still accumulated there until the
frozen process is thawed later. For this kind of situations, there's
no existing method to skip those outdated transactions and deliver the
latest one only.
This patch introduces a new transaction flag TF_UPDATE_TXN. To use it,
use apps can set this new flag along with TF_ONE_WAY. When such an
oneway transaction is to be queued into the async_todo list of a frozen
process, binder driver will check if any previous pending transactions
can be superseded by comparing their code, flags and target node. If
such an outdated pending transaction is found, the latest transaction
will supersede that outdated one. This effectively prevents the async
binder buffer running out and saves unnecessary binder read workloads.
Acked-by: Todd Kjos <tkjos@google.com>
Signed-off-by: Li Li <dualli@google.com>
Link: https://lore.kernel.org/r/20220526220018.3334775-2-dualli@chromium.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Bug: 231624308
Test: manually check async binder buffer size of frozen apps
Test: stress test with kernel 4.14/4.19/5.10/5.15
(cherry picked from commit 9864bb4801
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc.git
char-misc-next)
Change-Id: I1c4bff1eda1ca15aaaad5bf696c8fc00be743176
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)
