Now decompression is being handled in workqueue and it makes read I/O
latency non-deterministic, because of the non-deterministic scheduling
nature of workqueues. So, I made it handled in softirq context only if
possible, not in low memory devices, since this modification will
maintain decompresion related memory a little longer.
Bug: 232003054
Signed-off-by: Daeho Jeong <daehojeong@google.com>
Reviewed-by: Chao Yu <chao@kernel.org>
Signed-off-by: Jaegeuk Kim <jaegeuk@kernel.org>
Change-Id: I1a7c642e05c2f8544d475039b733403181de641e
(cherry picked from commit 9ef8cd45d7)
Introduce memory mode to supports "normal" and "low" memory modes.
"low" mode is to support low memory devices. Because of the nature of
low memory devices, in this mode, f2fs will try to save memory sometimes
by sacrificing performance. "normal" mode is the default mode and same
as before.
Bug: 232003054
Signed-off-by: Daeho Jeong <daehojeong@google.com>
Signed-off-by: Jaegeuk Kim <jaegeuk@kernel.org>
(cherry picked from commit 60f60d1fd8)
Change-Id: I7cb719b18f0002d7af47f7a18e8ec2f4c534bdd9
This reverts commit 6c997d153d.
The symbols exported by it were never used by any external modules, so
remove the unneeded exports.
Bug: 203756332
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
Change-Id: I338313c0c2ad1ec83f452db910a6ef9b5ee32b7d
This reverts commit a719abf031.
The symbol exported was never used by any external modules, so remove
the unneeded export.
Bug: 158067689
Bug: 203756332
Cc: Abhilasha Rao <abhilasha.hv@samsung.corp-partner.google.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
Change-Id: I13b65fd0620faf08784dabc7130f199dfa5cf053
This reverts most of commit 292f430816.
Only a small number of the original hooks in this commit were ever used,
so remove all of the unused ones. The hooks removed are:
android_rvh_try_to_wake_up
android_rvh_try_to_wake_up_success
android_rvh_wake_up_new_task
android_rvh_new_task_stats
android_rvh_flush_task
android_rvh_tick_entry
android_rvh_schedule
android_rvh_sched_cpu_starting
android_rvh_sched_cpu_dying
android_rvh_account_irq
android_rvh_place_entity
android_rvh_update_cpu_capacity
android_rvh_update_misfit_status
If these are needed by any real user, it can easily be reverted to add it
back and then the symbols must be added to the abi list at the same time
to prevent it from being removed again later.
Bug: 203756332
Bug: 173725277
Cc: Shaleen Agrawal <shalagra@codeaurora.org>
Cc: Pavankumar Kondeti <pkondeti@codeaurora.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
Change-Id: Icc24ed128fe1034ad663b749caa3bc2e2d0efac0
'allnoconfig' builds failed with:
kernel/sched/sched.h:1203:50: error: ‘struct rq’ has no member named ‘cpu’
rq->cpu needs to be replaced with cpu_of(rq) for !CONFIG_SMP builds
Fixes: 4442801a43 ("ANDROID: sched: Introducing PELT multiplier")
Signed-off-by: Todd Kjos <tkjos@google.com>
Change-Id: Iceb439dc3bba27516b5ecd2c18c9835c23e5a39a
The new sysctl sched_pelt_multiplier allows a user to set a clock
multiplier x2 or x4 (x1 being the default). This clock multiplier
artificially speed-up PELT ramp up/down similarly to a faster half-life.
Indeed, if we write PELT as a first order filter:
y(t) = G * (1 - exp(t/tau))
Then we can see that multiplying the time by a constant X, is the same
as
dividing the time constant tau by X.
y(t) = G * (1 - exp((t*X)/tau))
y(t) = G * (1 - exp(t/(tau/X)))
Tau being half-life*ln(2), multiplying the PELT time is the same as
dividing the half-life:
- x1: 32ms half-life
- x2: 16ms half-life
- x4: 8ms half-life
Internally, a new clock is created: rq->clock_task_mult. It sits in the
clock hierarchy between rq->clock_task and rq->clock_pelt.
Bug: 177593580
Bug: 237219700
Change-Id: I67e6ca7994bebea22bf75732ee11d2b10e0d6b7e
Suggested-by: Morten Rasmussen <morten.rasmussen@arm.com>
Signed-off-by: Vincent Donnefort <vincent.donnefort@arm.com>
Signed-off-by: JianMin Liu <jian-min.liu@mediatek.com>
(cherry picked from commit 4442801a43)
This reverts commit 74555f3992.
The hook android_vh_is_fpsimd_save is not used by any vendor, so remove
it to help with merge issues with future LTS releases.
If this is needed by any real user, it can easily be reverted to add it
back and then the symbol should be added to the abi list at the same
time to prevent it from being removed again later.
Bug: 203756332
Bug: 149632552
Cc: Wooyeon Kim <wooy88.kim@samsung.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
Change-Id: Idecd20a8791c5e4497f8d2222cc54cc42b2ebdff
This reverts commit e909fe79d2.
The symbols exported in it were never used by any external modules, so
remove the exports as they are not needed.
Bug: 203756332
Bug: 140294230
Cc: Sudarshan Rajagopalan <sudaraja@codeaurora.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
Change-Id: Ib3315ba129773256398a71ffe4c3acb55075b012
The purpose of these symbols are used for getting counter and metrics of long running irq. Currently we only have symbols for irq_handler_entry and irq_handler_exit.
Bug: 227809911
Signed-off-by: Ziyi Cui <ziyic@google.com>
Change-Id: Idf4ccdede5232689b2752283539aee54a5f67866
This change ensures that all nested XFRM packets have their policy
checked before decryption of the next layer, so that policies are
verified at each intermediate step of the decryption process.
Notably, raw ESP/AH packets do not perform policy checks inherently,
whereas all other encapsulated packets (UDP, TCP encapsulated) do policy
checks after calling xfrm_input handling in the respective encapsulation
layer.
This is necessary especially for nested tunnels, as the IP addresses,
protocol and ports may all change, thus not matching the previous
policies. In order to ensure that packets match the relevant inbound
templates, the xfrm_policy_check should be done before handing off to
the inner XFRM protocol to decrypt and decapsulate.
In order to prevent double-checking packets both here and in the
encapsulation layers, this check is currently limited to nested
tunnel-mode transforms and checked prior to decapsulation of inner
tunnel layers (prior to hitting a nested tunnel's xfrm_input, there
is no great way to detect a nested tunnel). This is primarily a
performance consideration, as a general blanket check at the end of
xfrm_input would suffice, but may result in multiple policy checks.
Bug: 236423446
Test: Tested against Android Kernel Unit Tests
Link: https://lore.kernel.org/netdev/20220824221252.4130836-3-benedictwong@google.com/
Signed-off-by: Benedict Wong <benedictwong@google.com>
Change-Id: I20c5abf39512d7f6cf438c0921a78a84e281b4e9
This change fixes a bug where inbound packets to nested IPsec tunnels
fails to pass policy checks due to the inner tunnel's policy checks
not having a reference to the outer policy/template. This causes the
policy check to fail, since the first entries in the secpath correlate
to the outer tunnel, while the templates being verified are for the
inner tunnel.
In order to ensure that the appropriate policy and template context is
searchable, the policy checks must be done incrementally between each
decryption step. As such, this marks secpath entries as having been
successfully matched, skipping them (treating as optional) on subsequent
policy checks
By skipping the immediate error return in the case where the secpath
entry had previously been validated, this change allows secpath entries
that matched a policy/template previously, while still requiring that
each searched template find a match in the secpath.
For security:
- All templates must have matching secpath entries
- Unchanged by current patch; templates that do not match any secpath
entry still return -1. This patch simply allows skipping earlier
blocks of verified secpath entries
- All entries (except trailing transport mode entries) must have a
matching template
- Unvalidated entries, including transport-mode entries still return
the errored index if it does not match the correct template.
Bug: 236423446
Test: Tested against Android Kernel Unit Tests
Link: https://lore.kernel.org/netdev/20220824221252.4130836-2-benedictwong@google.com/
[benedictwong: fixed minor style issues]
Signed-off-by: Benedict Wong <benedictwong@google.com>
Change-Id: Ic32831cb00151d0de2e465f18ec37d5f7b680e54
This reverts commit 444a0b7752.
The hook android_vh_vmpressure is not used by any vendor, so remove it
to help with merge issues with future LTS releases.
If this is needed by any real user, it can easily be reverted to add it
back and then the symbol should be added to the abi list at the same
time to prevent it from being removed again later.
Bug: 203756332
Bug: 191534577
Cc: Liangliang Li <liliangliang@vivo.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
Change-Id: I63d2a210dc6a6ded20ea8779af719d70f368ce0f
This reverts commit 4d63efb9ae.
The hooks android_vh_set_module_permit_before_init and
android_vh_set_module_permit_after_init is not used by any vendor, so
remove it to help with merge issues with future LTS releases.
If this is needed by any real user, it can easily be reverted to add it
back and then the symbol should be added to the abi list at the same
time to prevent it from being removed again later.
Bug: 203756332
Bug: 181639260
Cc: Kuan-Ying Lee <Kuan-Ying.Lee@mediatek.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
Change-Id: I3bbc5d4190d9fbf34469d2c5c1386dcbf998fb4b
The rmap locks(i_mmap_rwsem and anon_vma->root->rwsem) could be contended
under memory pressure if processes keep working on their vmas(e.g., fork,
mmap, munmap). It makes reclaim path stuck. In our real workload traces,
we see kswapd is waiting the lock for 300ms+(worst case, a sec) and it
makes other processes entering direct reclaim, which were also stuck on
the lock.
This patch makes lru aging path try_lock mode like shink_page_list so the
reclaim context will keep working with next lru pages without being stuck.
if it found the rmap lock contended, it rotates the page back to head of
lru in both active/inactive lrus to make them consistent behavior, which
is basic starting point rather than adding more heristic.
Since this patch introduces a new "contended" field as out-param along
with try_lock in-param in rmap_walk_control, it's not immutable any longer
if the try_lock is set so remove const keywords on rmap related functions.
Since rmap walking is already expensive operation, I doubt the const
would help sizable benefit( And we didn't have it until 5.17).
In a heavy app workload in Android, trace shows following statistics. It
almost removes rmap lock contention from reclaim path.
Martin Liu reported:
Before:
max_dur(ms) min_dur(ms) max-min(dur)ms avg_dur(ms) sum_dur(ms) count blocked_function
1632 0 1631 151.542173 31672 209 page_lock_anon_vma_read
601 0 601 145.544681 28817 198 rmap_walk_file
After:
max_dur(ms) min_dur(ms) max-min(dur)ms avg_dur(ms) sum_dur(ms) count blocked_function
NaN NaN NaN NaN NaN 0.0 NaN
0 0 0 0.127645 1 12 rmap_walk_file
[minchan@kernel.org: add comment, per Matthew]
Link: https://lkml.kernel.org/r/YnNqeB5tUf6LZ57b@google.com
Link: https://lkml.kernel.org/r/20220510215423.164547-1-minchan@kernel.org
Signed-off-by: Minchan Kim <minchan@kernel.org>
Acked-by: Johannes Weiner <hannes@cmpxchg.org>
Cc: Suren Baghdasaryan <surenb@google.com>
Cc: Michal Hocko <mhocko@suse.com>
Cc: John Dias <joaodias@google.com>
Cc: Tim Murray <timmurray@google.com>
Cc: Matthew Wilcox <willy@infradead.org>
Cc: Vladimir Davydov <vdavydov.dev@gmail.com>
Cc: Martin Liu <liumartin@google.com>
Cc: Minchan Kim <minchan@kernel.org>
Cc: Matthew Wilcox <willy@infradead.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Conflicts:
folio->page
(cherry picked from commit 6d4675e601)
Bug: 239681156
Signed-off-by: Minchan Kim <minchan@google.com>
Change-Id: I0c63e0291120c8a1b5f2d83b8a7b210cb56c27a2
The purpose of this vendor hook is to trace early resume latency.
Bug: 241946090
Signed-off-by: Ziyi Cui <ziyic@google.com>
Change-Id: I508f5a34fd3210178af0cb142461baf814196b9f
Add vendor hook when detecting process status through
pidfd_open.
Bug: 238725692
Change-Id: I565988cb8bf6dd44ab4dc15c410c2dcf50703def
Signed-off-by: xiaofeng <xiaofeng5@xiaomi.com>
If kernel doesn't have CONFIG_F2FS_FS_COMPRESSION, a file having FS_COMPR_FL via
ioctl(FS_IOC_SETFLAGS) is unaccessible due to f2fs_is_compress_backend_ready().
Let's avoid it.
Bug: 240921972
Signed-off-by: Jaegeuk Kim <jaegeuk@kernel.org>
(cherry picked from commit 376523b97c005fa57bb2f8e70f61ab965f16e160)
Change-Id: Ieb0f8945175ea5ccb0060690e882f054360fb8f0
Otherwise, we can get a wrong cp_error mark.
Bug: 239451498
Cc: <stable@vger.kernel.org>
Fixes: a7b8618aa2 ("f2fs: avoid infinite loop to flush node pages")
Signed-off-by: Jaegeuk Kim <jaegeuk@kernel.org>
(cherry picked from commit 1a81f1ba6f9e0e7ab72b32bbd8184892319f1583)
Change-Id: Ic28a139341e96cb6fb0eca9f614895ae14e96946
The patchset in [1] exported some definitions to binder_internal.h in
order to make the debugfs entries such as 'stats' and 'transaction_log'
available in a binderfs instance. However, the DEFINE_SHOW_ATTRIBUTE
macro expands into a static function/variable pair, which in turn get
redefined each time a source file includes this internal header.
This problem was made evident after a report from the kernel test robot
<lkp@intel.com> where several W=1 build warnings are seen in downstream
kernels. See the following example:
include/../drivers/android/binder_internal.h:111:23: warning: 'binder_stats_fops' defined but not used [-Wunused-const-variable=]
111 | DEFINE_SHOW_ATTRIBUTE(binder_stats);
| ^~~~~~~~~~~~
include/linux/seq_file.h:174:37: note: in definition of macro 'DEFINE_SHOW_ATTRIBUTE'
174 | static const struct file_operations __name ## _fops = { \
| ^~~~~~
This patch fixes the above issues by moving back the definitions into
binder.c and instead creates an array of the debugfs entries which is
more convenient to share with binderfs and iterate through.
[1] https://lore.kernel.org/all/20190903161655.107408-1-hridya@google.com/
Fixes: 0e13e452da ("binder: Add stats, state and transactions files")
Fixes: 03e2e07e38 ("binder: Make transaction_log available in binderfs")
Reported-by: kernel test robot <lkp@intel.com>
Signed-off-by: Carlos Llamas <cmllamas@google.com>
Link: https://lore.kernel.org/r/20220701182041.2134313-1-cmllamas@google.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Bug: 240404657
(cherry picked from commit b7e241bbff)
Signed-off-by: Carlos Llamas <cmllamas@google.com>
Change-Id: I7e9ca1ab1f3a5a4a272e50f24d404c17cad55d32
commit b40a6ab2cf upstream.
amdgpu_amdkfd_gpuvm_alloc_memory_of_gpu needs the drm_priv to allow mmap
to access the BO through the corresponding file descriptor. The VM can
also be extracted from drm_priv, so drm_priv can replace the vm parameter
in the kfd2kgd interface.
Bug: 225381233
Signed-off-by: Felix Kuehling <Felix.Kuehling@amd.com>
Reviewed-by: Philip Yang <philip.yang@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
[This is a partial cherry-pick of the upstream commit.]
Signed-off-by: Lee Jones <lee.jones@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Lee Jones <joneslee@google.com>
Change-Id: I49c141ce1727fd5822f0ce09b2dc4887caa65766
commit 9f46c187e2 upstream.
With shadow paging enabled, the INVPCID instruction results in a call
to kvm_mmu_invpcid_gva. If INVPCID is executed with CR0.PG=0, the
invlpg callback is not set and the result is a NULL pointer dereference.
Fix it trivially by checking for mmu->invlpg before every call.
There are other possibilities:
- check for CR0.PG, because KVM (like all Intel processors after P5)
flushes guest TLB on CR0.PG changes so that INVPCID/INVLPG are a
nop with paging disabled
- check for EFER.LMA, because KVM syncs and flushes when switching
MMU contexts outside of 64-bit mode
All of these are tricky, go for the simple solution. This is CVE-2022-1789.
Bug: 235691682
Reported-by: Yongkang Jia <kangel@zju.edu.cn>
Cc: stable@vger.kernel.org
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
[fix conflict due to missing b9e5603c2a]
Signed-off-by: Vegard Nossum <vegard.nossum@oracle.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Lee Jones <joneslee@google.com>
Change-Id: If558163c4ddd4606274b456324278ed3fb5b093c
commit d0be8347c6 upstream.
This fixes the following trace which is caused by hci_rx_work starting up
*after* the final channel reference has been put() during sock_close() but
*before* the references to the channel have been destroyed, so instead
the code now rely on kref_get_unless_zero/l2cap_chan_hold_unless_zero to
prevent referencing a channel that is about to be destroyed.
refcount_t: increment on 0; use-after-free.
BUG: KASAN: use-after-free in refcount_dec_and_test+0x20/0xd0
Read of size 4 at addr ffffffc114f5bf18 by task kworker/u17:14/705
CPU: 4 PID: 705 Comm: kworker/u17:14 Tainted: G S W
4.14.234-00003-g1fb6d0bd49a4-dirty #28
Hardware name: Qualcomm Technologies, Inc. SM8150 V2 PM8150
Google Inc. MSM sm8150 Flame DVT (DT)
Workqueue: hci0 hci_rx_work
Call trace:
dump_backtrace+0x0/0x378
show_stack+0x20/0x2c
dump_stack+0x124/0x148
print_address_description+0x80/0x2e8
__kasan_report+0x168/0x188
kasan_report+0x10/0x18
__asan_load4+0x84/0x8c
refcount_dec_and_test+0x20/0xd0
l2cap_chan_put+0x48/0x12c
l2cap_recv_frame+0x4770/0x6550
l2cap_recv_acldata+0x44c/0x7a4
hci_acldata_packet+0x100/0x188
hci_rx_work+0x178/0x23c
process_one_work+0x35c/0x95c
worker_thread+0x4cc/0x960
kthread+0x1a8/0x1c4
ret_from_fork+0x10/0x18
Bug: 165329981
Cc: stable@kernel.org
Reported-by: Lee Jones <lee.jones@linaro.org>
Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
Tested-by: Lee Jones <lee.jones@linaro.org>
Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Lee Jones <joneslee@google.com>
Change-Id: I6efae55d8014740aebc8c3534846c2d249068b29
Lee reports that there's a use-after-free of the process file table.
There's an assumption that we don't need the file table for some
variants of statx invocation, but that turns out to be false and we
end up with not grabbing a reference for the request even if the
deferred execution uses it.
Get rid of the REQ_F_NO_FILE_TABLE optimization for statx, and always
grab that reference.
This issues doesn't exist upstream since the native workers got
introduced with 5.12.
Bug: 220738351
Link: https://lore.kernel.org/io-uring/YoOJ%2FT4QRKC+fAZE@google.com/
Reported-by: Lee Jones <lee.jones@linaro.org>
Signed-off-by: Jens Axboe <axboe@kernel.dk>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
(cherry picked from commit 3c48558be5)
Signed-off-by: Lee Jones <joneslee@google.com>
Change-Id: Ife51536d95368bffdc393ad2a5e737a0e6ddf18f
This issue is conceptually identical to the one fixed in 29f077d070
("io_uring: always use original task when preparing req identity"), so
rather than reinvent the wheel, I'm shamelessly quoting the commit
message from that patch - thanks Jens:
"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: 238177383
Cc: Jens Axboe <axboe@kernel.dk>
Cc: Pavel Begunkov <asml.silence@gmail.com>
Cc: Alexander Viro <viro@zeniv.linux.org.uk>
Cc: io-uring@vger.kernel.org
Cc: linux-fsdevel@vger.kernel.org
Fixes: 5c3462cfd1 ("io_uring: store io_identity in io_uring_task")
Signed-off-by: Lee Jones <lee@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
(cherry picked from commit 2ee0cab11f
git: //git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git linux-5.10.y)
Signed-off-by: Lee Jones <joneslee@google.com>
Change-Id: I98adc653dbe03f8e9d214d9430fe50d351a45910
A transaction of type BINDER_TYPE_WEAK_HANDLE can fail to increment the
reference for a node. In this case, the target proc normally releases
the failed reference upon close as expected. However, if the target is
dying in parallel the call will race with binder_deferred_release(), so
the target could have released all of its references by now leaving the
cleanup of the new failed reference unhandled.
The transaction then ends and the target proc gets released making the
ref->proc now a dangling pointer. Later on, ref->node is closed and we
attempt to take spin_lock(&ref->proc->inner_lock), which leads to the
use-after-free bug reported below. Let's fix this by cleaning up the
failed reference on the spot instead of relying on the target to do so.
==================================================================
BUG: KASAN: use-after-free in _raw_spin_lock+0xa8/0x150
Write of size 4 at addr ffff5ca207094238 by task kworker/1:0/590
CPU: 1 PID: 590 Comm: kworker/1:0 Not tainted 5.19.0-rc8 #10
Hardware name: linux,dummy-virt (DT)
Workqueue: events binder_deferred_func
Call trace:
dump_backtrace.part.0+0x1d0/0x1e0
show_stack+0x18/0x70
dump_stack_lvl+0x68/0x84
print_report+0x2e4/0x61c
kasan_report+0xa4/0x110
kasan_check_range+0xfc/0x1a4
__kasan_check_write+0x3c/0x50
_raw_spin_lock+0xa8/0x150
binder_deferred_func+0x5e0/0x9b0
process_one_work+0x38c/0x5f0
worker_thread+0x9c/0x694
kthread+0x188/0x190
ret_from_fork+0x10/0x20
Signed-off-by: Carlos Llamas <cmllamas@google.com>
Acked-by: Christian Brauner (Microsoft) <brauner@kernel.org>
Bug: 239630375
Link: https://lore.kernel.org/all/20220801182511.3371447-1-cmllamas@google.com/
Signed-off-by: Carlos Llamas <cmllamas@google.com>
Change-Id: I5085dd0dc805a780a64c057e5819f82dd8f02868
(cherry picked from commit ae3fa5d16a02ba7c7b170e0e1ab56d6f0ba33964)
When calling binder_do_set_priority() with the same policy and priority
values as the current task, we exit early since there is nothing to do.
However, the BINDER_PRIO_PENDING state might be set and in this case we
fail to update it. A subsequent call to binder_transaction_priority()
will then read an incorrect state and save the wrong priority. Fix this
by setting thread->prio_state to BINDER_PRIO_SET on our way out.
Bug: 199309216
Fixes: cac827f261 ("ANDROID: binder: fix race in priority restore")
Signed-off-by: Carlos Llamas <cmllamas@google.com>
Change-Id: I21e906cf4b2ebee908af41fe101ecd458ae1991c
(cherry picked from commit 72193be6d4)
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>
