../techpack/dataipa/drivers/platform/msm/ipa/ipa_v3/rmnet_ipa.c:510:41: warning: implicit conversion from enumeration type 'enum ipa_ip_type_enum_v01' to different enumeration type 'enum ipa_ip_type' [-Wenum-conversion]
q6_ul_flt_rule_ptr->ip = flt_spec_ptr->ip_type;
~ ~~~~~~~~~~~~~~^~~~~~~
../techpack/dataipa/drivers/platform/msm/ipa/ipa_v3/rmnet_ipa.c:511:45: warning: implicit conversion from enumeration type 'enum ipa_filter_action_enum_v01' to different enumeration type 'enum ipa_flt_action' [-Wenum-conversion]
q6_ul_flt_rule_ptr->action = flt_spec_ptr->filter_action;
~ ~~~~~~~~~~~~~~^~~~~~~~~~~~~
Change-Id: I0eb68d707151cd103676a30659ab81bf6fced131
Ensures that no new warnings are introduced to the build.
Bug: 141372918
Change-Id: I4107af91f5c1ddd655037823350e005e8362d588
Signed-off-by: Chenglu Lin <chenglulin@google.com>
Add configuration option CONFIG_CC_WERROR to prevent warnings
from creeping in.
Bug: 141372918
Change-Id: Ie2d067c0177d8f13e9aaa9a78867998e390f89ee
Signed-off-by: Chenglu Lin <chenglulin@google.com>
When CONFIG_CFI_CLANG and CONFIG_DYNAMIC_FTRACE are enabled, LLVM will
generate a jump function named ftrace_call.cfi_jt for ftrace_call, which
makes "&ftrace_call" in ftrace_update_ftrace_func() actually the address
of ftrace_call.cfi_jt. As a result, the tracer can't be really enabled
through runtime modification. Use __va_function() to get the actual address
of ftrace_call to fix the issue.
Bug: 184105181
Signed-off-by: Ben Dai <ben.dai@unisoc.com>
Change-Id: Ic9272cd4ab447b3b145d8e397e5c9010c49f7a12
After the switch to non-canonical CFI jump tables, the jump table
sections were placed after the .text section. Merge these sections
into .text to fix issues with error injection and kallsyms.
Bug: 225079388
Bug: 190422440
Change-Id: I6c81b3e4dbba62739f7fc5f6b45271c54f278c8f
Signed-off-by: Sami Tolvanen <samitolvanen@google.com>
Handle error return value from copy_to_user() in ioctls to avoid
following compilation failure.
"error: ignoring return value of function declared with 'warn_unused_result'
attribute".
Change-Id: I92944ade7fb88e0543ca4254fab226da5777def7
Signed-off-by: Jeevan Shriram <quic_jshriram@quicinc.com>
It never hurts to know if drivers have some flaws.
Change-Id: Iba3acda0eeec9448fc907def5b3d25f117bc818b
Signed-off-by: Alexander Winkowski <dereference23@outlook.com>
This flag is specific to clang, where it is only used by the 32-bit and
64-bit ARM backends. In certain situations, the presence of this flag
will cause a warning, as shown by commit 6580c5c18fb3 ("um: clang: Strip
out -mno-global-merge from USER_CFLAGS").
Since commit 61163efae0 ("kbuild: LLVMLinux: Add Kbuild support for
building kernel with Clang") that added this flag back in 2014, there
have been quite a few changes to the GlobalMerge pass in LLVM. Building
several different ARCH=arm and ARCH=arm64 configurations with LLVM 11
(minimum) and 15 (current main version) with this flag removed (i.e.,
with the default of '-mglobal-merge') reveals no modpost warnings, so it
is likely that the issue noted in the comment is no longer relevant due
to changes in LLVM or modpost, meaning this flag can be removed.
If any new warnings show up that are a result of the removal of this
flag, it can be added back under arch/arm{,64}/Makefile to avoid
warnings on other architectures.
Signed-off-by: Nathan Chancellor <nathan@kernel.org>
Tested-by: David Gow <davidgow@google.com>
Reviewed-by: Kees Cook <keescook@chromium.org>
Tested-by: Sedat Dilek <sedat.dilek@gmail.com>
Reviewed-by: Sedat Dilek <sedat.dilek@gmail.com>
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
(cherry picked from commit cf300b83c793c25c6b485fdaf7a4447d8ea4c655)
Change-Id: Ice39a960619319828b83c8091798fe383395a2b0
Signed-off-by: Alexander Winkowski <dereference23@outlook.com>
strlen(swr_dmic_name_prefix_of) + 1 bytes are allocated for prefix_name just above
techpack/audio/asoc/codecs/swr-dmic.c:685:11: error: size argument in 'strlcpy' call appears to be size of the source; expected the size of the destination [-Werror,-Wstrlcpy-strlcat-size]
strlen(swr_dmic_name_prefix_of) + 1);
~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~
1 error generated.
Change-Id: I808b4f135d42fc50587eeb9348848f7e0a3561cc
Signed-off-by: Alexander Winkowski <dereference23@outlook.com>
The size is checked just above.
../drivers/hwtracing/coresight/coresight-tmc.c:423:26: warning: 'sscanf' may overflow; destination buffer in argument 3 has size 10, but the corresponding specifier may require size 11 [-Wfortify-source]
423 | if (sscanf(buf, "%10s", str) != 1)
| ^
../drivers/hwtracing/coresight/coresight-tmc.c:464:26: warning: 'sscanf' may overflow; destination buffer in argument 3 has size 10, but the corresponding specifier may require size 11 [-Wfortify-source]
464 | if (sscanf(buf, "%10s", str) != 1)
| ^
2 warnings generated.
Change-Id: I5db199a85ba0c7dfc15fae5d62c9c4d8c550d3e7
Signed-off-by: Alexander Winkowski <dereference23@outlook.com>
Extracted from I54b58226e3d6de0b674ac4ca1407138d1c9707e8
../drivers/soc/qcom/msm_minidump.c:521:39: warning: size argument in 'strlcpy' call appears to be size of the source; expected the size of the destination [-Wstrlcpy-strlcat-size]
521 | strlcpy(banner, linux_banner, strlen(linux_banner) + 1);
| ~~~~~~~^~~~~~~~~~~~~~~~~
1 warning generated.
Change-Id: I43fa5006150dd402405f8c942571f08da0eb714a
Signed-off-by: Alexander Winkowski <dereference23@outlook.com>
Only 19 characters out of total 20 can be used due to the '\0' terminator.
Change-Id: I34883be26f97a16fdcb5ff97ff326d98f4d93c18
Signed-off-by: Alexander Winkowski <dereference23@outlook.com>
CAF cherry-picked an obsolete LLVMLinux patch from 2014 in commit
a2a31f1ddc that introduced this
unnecessary flag. Now that the functions used by Clang's libcall
optimizations have been implemented, we can allow Clang to perform said
optimizations for a minor performance bump in certain code paths.
Change-Id: Ifa6b731c9702973be2c656d341e33a6186ed7cf2
Signed-off-by: Danny Lin <danny@kdrag0n.dev>
This reverts commit 1210d2329b.
Unnecessary with Clang 6.0+.
Change-Id: I6f29ca050566e9027e51605e64bf6893602344ef
Signed-off-by: Danny Lin <danny@kdrag0n.dev>
We don't need to know that PM notifiers are working. Silence the entry/exit
log spam in ipa_pm_notify().
Change-Id: I9bae89fa5e27b8835683ec1423ecc751491ea13c
Signed-off-by: Sultan Alsawaf <sultan@osomprivacy.com>
After commit 1248f43abe ("arm64: Move the LSE gas support detection to Kconfig")
CONFIG_ARM64_USE_LSE_ATOMICS should be used to disable LSE atomics usage.
Change-Id: Ibb1abef274883b74b3d6151cc0fbe1647d5b9076
Signed-off-by: Alexander Winkowski <dereference23@outlook.com>
The conditional was mistakenly removed in e4e5585516.
Change-Id: If8fdb03cbda21a75b2c6ad00cee268f1a1c3ebe1
Signed-off-by: Alexander Winkowski <dereference23@outlook.com>
Do not mark MPM as wake irq. Break s2idle suspend when MPM irq
is pending.
Change-Id: Ia455c589fdadcaa3be6084a68990887a2d4c3517
Signed-off-by: Maulik Shah <quic_mkshah@quicinc.com>
Add IRQCHIP_SET_TYPE_MASKED flag for gpio and gic irqchips.
Change-Id: Ie6bf76ab2c98e4bc40ad4adfb13da9c9b69734c9
Signed-off-by: Maulik Shah <quic_mkshah@quicinc.com>
As mpm irq is not expected to fire during the suspend phase,
so irq set with IRQF_NO_SUSPEND is not required.
This patch removes the IRQF_NO_SUSPEND flag from mpm irq
request.
Change-Id: I546968efa093e14f056c245648c2409e88a1bc45
Signed-off-by: Raghavendra Kakarla <quic_rkakarla@quicinc.com>
https://source.android.com/docs/security/bulletin/2024-05-01
CVE-2023-4622
* tag 'ASB-2024-05-05_11-5.4' of https://android.googlesource.com/kernel/common:
ANDROID: 16K: Fix show maps CFI failure
ANDROID: 16K: Handle pad VMA splits and merges
ANDROID: 16K: madvise_vma_pad_pages: Remove filemap_fault check
ANDROID: 16K: Only madvise padding from dynamic linker context
ANDROID: 16K: Separate padding from ELF LOAD segment mappings
ANDROID: 16K: Exclude ELF padding for fault around range
ANDROID: 16K: Use MADV_DONTNEED to save VMA padding pages.
ANDROID: 16K: Introduce ELF padding representation for VMAs
ANDROID: 16K: Introduce /sys/kernel/mm/pgsize_miration/enabled
ANDROID: GKI: add snd_compr_stop_error to Xiaomi_abi
UPSTREAM: netfilter: nf_tables: release mutex after nft_gc_seq_end from abort path
UPSTREAM: netfilter: nf_tables: release batch on table validation from abort path
UPSTREAM: netfilter: nf_tables: mark set as dead when unbinding anonymous set with timeout
Conflicts:
mm/Makefile
mm/mlock.c
mm/mprotect.c
Change-Id: I559d13f0370fd2ede446df61fd1ce0550fa45155
If the kernel is built CONFIG_CFI_CLANG=y, reading smaps
may cause a panic. This is due to a failed CFI check; which
is triggered becuase the signature of the function pointer for
printing smaps padding VMAs does not match exactly with that
for show_smap().
Fix this by casting the function pointer to the expected type
based on whether printing maps or smaps padding.
Bug: 330117029
Bug: 327600007
Bug: 330767927
Bug: 328266487
Bug: 329803029
Change-Id: I65564a547dacbc4131f8557344c8c96e51f90cd5
Signed-off-by: Kalesh Singh <kaleshsingh@google.com>
In some cases a VMA with padding representation may be split, and
therefore the padding flags must be updated accordingly.
There are 3 cases to handle:
Given:
| DDDDPPPP |
where:
- D represents 1 page of data;
- P represents 1 page of padding;
- | represents the boundaries (start/end) of the VMA
1) Split exactly at the padding boundary
| DDDDPPPP | --> | DDDD | PPPP |
- Remove padding flags from the first VMA.
- The second VMA is all padding
2) Split within the padding area
| DDDDPPPP | --> | DDDDPP | PP |
- Subtract the length of the second VMA from the first VMA's
padding.
- The second VMA is all padding, adjust its padding length (flags)
3) Split within the data area
| DDDDPPPP | --> | DD | DDPPPP |
- Remove padding flags from the first VMA.
- The second VMA is has the same padding as from before the split.
To simplify the semantics merging of padding VMAs is not allowed.
If a split produces a VMA that is entirely padding, show_[s]maps()
only outputs the padding VMA entry (as the data entry is of length 0).
Bug: 330117029
Bug: 327600007
Bug: 330767927
Bug: 328266487
Bug: 329803029
Change-Id: Ie2628ced5512e2c7f8af25fabae1f38730c8bb1a
Signed-off-by: Kalesh Singh <kaleshsingh@google.com>
Some file systems like F2FS use a custom filemap_fault ops. Remove this
check, as checking vm_file is sufficient.
Bug: 330117029
Bug: 327600007
Bug: 330767927
Bug: 328266487
Bug: 329803029
Change-Id: Id6a584d934f06650c0a95afd1823669fc77ba2c2
Signed-off-by: Kalesh Singh <kaleshsingh@google.com>
Only preform padding advise from the execution context on bionic's
dynamic linker. This ensures that madvise() doesn't have unwanted
side effects.
Also rearrange the order of fail checks in madvise_vma_pad_pages()
in order of ascending cost.
Bug: 330117029
Bug: 327600007
Bug: 330767927
Bug: 328266487
Bug: 329803029
Change-Id: I3e05b8780c6eda78007f86b613f8c11dd18ac28f
Signed-off-by: Kalesh Singh <kaleshsingh@google.com>
Userspace apps often analyze memory consumption by the use of mm
rss_stat counters -- via the kmem/rss_stat trace event or from
/proc/<pid>/statm.
rss_stat counters are only updated when the PTEs are updated. What this
means is that pages can be present in the page cache from readahead but
not visible to userspace (not attributed to the app) as there is no
corresponding VMA (PTEs) for the respective page cache pages.
A side effect of the loader now extending ELF LOAD segments to be
contiguously mapped in the virtual address space, means that the VMA is
extended to cover the padding pages.
When filesystems, such as f2fs and ext4, that implement
vm_ops->map_pages() attempt to perform a do_fault_around() the extent of
the fault around is restricted by the area of the enclosing VMA. Since
the loader extends LOAD segment VMAs to be contiguously mapped, the extent
of the fault around is also increased. The result of which, is that the
PTEs corresponding to the padding pages are updated and reflected in the
rss_stat counters.
It is not common that userspace application developers be aware of this
nuance in the kernel's memory accounting. To avoid apparent regressions
in memory usage to userspace, restrict the fault around range to only
valid data pages (i.e. exclude the padding pages at the end of the VMA).
Bug: 330117029
Bug: 327600007
Bug: 330767927
Bug: 328266487
Bug: 329803029
Change-Id: I2c7a39ec1b040be2b9fb47801f95042f5dbf869d
Signed-off-by: Kalesh Singh <kaleshsingh@google.com>
When performing LOAD segment extension, the dynamic linker knows what
portion of the VMA is padding. In order for the kernel to implement
mitigations that ensure app compatibility, the extent of the padding
must be made available to the kernel.
To achieve this, reuse MADV_DONTNEED on single VMAs to hint the padding
range to the kernel. This information is then stored in vm_flag bits.
This allows userspace (dynamic linker) to set the padding pages on the
VMA without a need for new out-of-tree UAPI.
Bug: 330117029
Bug: 327600007
Bug: 330767927
Bug: 328266487
Bug: 329803029
Change-Id: I3421de32ab38ad3cb0fbce73ecbd8f7314287cde
Signed-off-by: Kalesh Singh <kaleshsingh@google.com>
The dynamic linker may extend ELF LOAD segment mappings to be contiguous
in memory when loading a 16kB compatible ELF on a 4kB page-size system.
This is done to reduce the use of unreclaimable VMA slab memory for the
otherwise necessary "gap" VMAs. The extended portion of the mapping
(VMA) can be viewed as "padding", meaning that the mapping in that range
corresponds to an area of the file that does not contain contents of the
respective segments (maybe zero's depending on how the ELF is built).
For some compatibility mitigations, the region of a VMA corresponding to
these padding sections need to be known.
In order to represent such regions without adding addtional overhead or
breaking ABI, some upper bits of vm_flags are used.
Add the VMA padding pages representation and the necessary APIs to
manipulate it.
Bug: 330117029
Bug: 327600007
Bug: 330767927
Bug: 328266487
Bug: 329803029
Change-Id: Ieb9fa98e30ec9b0bec62256624f14e3ed6062a75
Signed-off-by: Kalesh Singh <kaleshsingh@google.com>
Migrating from 4kB to 16kB page-size in Android requires first making
the platform page-agnostic, which involves increasing Android-ELFs'
max-page-size (p_align) from 4kB to 16kB.
Increasing the ELF max-page-size was found to cause compatibility issues
in apps that use obfuscation or depend on the ELF segments being mapped
based on 4kB-alignment.
Working around these compatibility issues involves both kernel and
userspace (dynamic linker) changes.
Introduce a knob for userspace (dynamic linker) to determine whether the
kernel supports the mitigations needed for page-size migration compatibility.
The knob also allows for userspace to turn on or off these mitigations
by writing 1 or 0 to /sys/kernel/mm/pgsize_miration/enabled:
echo 1 > /sys/kernel/mm//pgsize_miration/enabled # Enable
echo 0 > /sys/kernel/mm//pgsize_miration/enabled # Disable
Bug: 330117029
Bug: 327600007
Bug: 330767927
Bug: 328266487
Bug: 329803029
Change-Id: I9ac1d15d397b8226b27827ecffa30502da91e10e
Signed-off-by: Kalesh Singh <kaleshsingh@google.com>
https://source.android.com/docs/security/bulletin/2024-04-01
* tag 'ASB-2024-04-05_11-5.4' of https://android.googlesource.com/kernel/common:
FROMLIST: binder: check offset alignment in binder_get_object()
BACKPORT: f2fs: expose # of overprivision segments
ANDROID: GKI: Update symbol list for Zebra
ANDROID: GKI: db845c: Update symbols list and ABI
UPSTREAM: drm/msm/dsi: Enable runtime PM
UPSTREAM: PM: runtime: Have devm_pm_runtime_enable() handle pm_runtime_dont_use_autosuspend()
UPSTREAM: PM: runtime: add devm_pm_runtime_enable helper
Change-Id: Ie646a1c4ae01dacb93625c5ef26283c0d9f5df33
commit 3c12466b6b7bf1e56f9b32c366a3d83d87afb4de upstream.
Currently EROFS can map another compressed buffer for inplace
decompression, that was used to handle the cases that some pages of
compressed data are actually not in-place I/O.
However, like most simple LZ77 algorithms, LZ4 expects the compressed
data is arranged at the end of the decompressed buffer and it
explicitly uses memmove() to handle overlapping:
__________________________________________________________
|_ direction of decompression --> ____ |_ compressed data _|
Although EROFS arranges compressed data like this, it typically maps two
individual virtual buffers so the relative order is uncertain.
Previously, it was hardly observed since LZ4 only uses memmove() for
short overlapped literals and x86/arm64 memmove implementations seem to
completely cover it up and they don't have this issue. Juhyung reported
that EROFS data corruption can be found on a new Intel x86 processor.
After some analysis, it seems that recent x86 processors with the new
FSRM feature expose this issue with "rep movsb".
Let's strictly use the decompressed buffer for lz4 inplace
decompression for now. Later, as an useful improvement, we could try
to tie up these two buffers together in the correct order.
Reported-and-tested-by: Juhyung Park <qkrwngud825@gmail.com>
Closes: https://lore.kernel.org/r/CAD14+f2AVKf8Fa2OO1aAUdDNTDsVzzR6ctU_oJSmTyd6zSYR2Q@mail.gmail.com
Fixes: 0ffd71bcc3 ("staging: erofs: introduce LZ4 decompression inplace")
Fixes: 598162d05080 ("erofs: support decompress big pcluster for lz4 backend")
Cc: stable <stable@vger.kernel.org> # 5.4+
Tested-by: Yifan Zhao <zhaoyifan@sjtu.edu.cn>
Change-Id: Ib7a578283e33f0329ae2133223878ddf0738aba4
Signed-off-by: Gao Xiang <hsiangkao@linux.alibaba.com>
Link: https://lore.kernel.org/r/20231206045534.3920847-1-hsiangkao@linux.alibaba.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
[mkbestas: Adapt for android <=5.4 kernel which contains backports that
caused various conflicts]
Signed-off-by: Michael Bestas <mkbestas@lineageos.org>
Using per-cpu thread pool we can reduce the scheduling latency compared
to workqueue implementation. With this patch scheduling latency and
variation is reduced as per-cpu threads are high priority kthread_workers.
The results were evaluated on arm64 Android devices running 5.10 kernel.
The table below shows resulting improvements of total scheduling latency
for the same app launch benchmark runs with 50 iterations. Scheduling
latency is the latency between when the task (workqueue kworker vs
kthread_worker) became eligible to run to when it actually started
running.
+-------------------------+-----------+----------------+---------+
| | workqueue | kthread_worker | diff |
+-------------------------+-----------+----------------+---------+
| Average (us) | 15253 | 2914 | -80.89% |
| Median (us) | 14001 | 2912 | -79.20% |
| Minimum (us) | 3117 | 1027 | -67.05% |
| Maximum (us) | 30170 | 3805 | -87.39% |
| Standard deviation (us) | 7166 | 359 | |
+-------------------------+-----------+----------------+---------+
Background: Boot times and cold app launch benchmarks are very
important to the Android ecosystem as they directly translate to
responsiveness from user point of view. While EROFS provides
a lot of important features like space savings, we saw some
performance penalty in cold app launch benchmarks in few scenarios.
Analysis showed that the significant variance was coming from the
scheduling cost while decompression cost was more or less the same.
Having per-cpu thread pool we can see from the above table that this
variation is reduced by ~80% on average. This problem was discussed
at LPC 2022. Link to LPC 2022 slides and talk at [1]
[1] https://lpc.events/event/16/contributions/1338/
[ Gao Xiang: At least, we have to add this until WQ_UNBOUND workqueue
issue [2] on many arm64 devices is resolved. ]
[2] https://lore.kernel.org/r/CAJkfWY490-m6wNubkxiTPsW59sfsQs37Wey279LmiRxKt7aQYg@mail.gmail.com
Bug: 271636421
Bug: 278520205
Test: launch_cvd
Change-Id: I9dce2bfd6f40ec6a210161b80cee7c0417b4edb3
Signed-off-by: Sandeep Dhavale <dhavale@google.com>
Signed-off-by: Gao Xiang <hsiangkao@linux.alibaba.com>
Link: https://lore.kernel.org/r/20230208093322.75816-1-hsiangkao@linux.alibaba.com
(cherry picked from commit 3fffb589b9a6e331e39cb75373ee7691acd7b109)
[dhavale: Fixed minor conflict as upstream now has zdata.h folded in
zdata.c]
Signed-off-by: Sandeep Dhavale <dhavale@google.com>
(cherry picked from commit 566a7f6c6b3f5f13b766fe749bbdb45918b029ac)
[dhavale: Fixed minor conflicts in Kconfig and zdata.c]
(cherry picked from commit 2de95f5d183c2174c9380a902919c8e59e380293)
SCHED_FIFO (or any static priority scheduler) is a broken scheduler
model; it is fundamentally incapable of resource management, the one
thing an OS is actually supposed to do.
It is impossible to compose static priority workloads. One cannot take
two well designed and functional static priority workloads and mash
them together and still expect them to work.
Therefore it doesn't make sense to expose the priority field; the
kernel is fundamentally incapable of setting a sensible value, it
needs systems knowledge that it doesn't have.
Take away sched_setschedule() / sched_setattr() from modules and
replace them with:
- sched_set_fifo(p); create a FIFO task (at prio 50)
- sched_set_fifo_low(p); create a task higher than NORMAL,
which ends up being a FIFO task at prio 1.
- sched_set_normal(p, nice); (re)set the task to normal
This stops the proliferation of randomly chosen, and irrelevant, FIFO
priorities that dont't really mean anything anyway.
The system administrator/integrator, whoever has insight into the
actual system design and requirements (userspace) can set-up
appropriate priorities if and when needed.
Cc: airlied@redhat.com
Cc: alexander.deucher@amd.com
Cc: awalls@md.metrocast.net
Cc: axboe@kernel.dk
Cc: broonie@kernel.org
Cc: daniel.lezcano@linaro.org
Cc: gregkh@linuxfoundation.org
Cc: hannes@cmpxchg.org
Cc: herbert@gondor.apana.org.au
Cc: hverkuil@xs4all.nl
Cc: john.stultz@linaro.org
Cc: nico@fluxnic.net
Cc: paulmck@kernel.org
Cc: rafael.j.wysocki@intel.com
Cc: rmk+kernel@arm.linux.org.uk
Cc: sudeep.holla@arm.com
Cc: tglx@linutronix.de
Cc: ulf.hansson@linaro.org
Cc: wim@linux-watchdog.org
Change-Id: I52ed4f1253e82ba3e8f40f3aa1aff62580163f25
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Reviewed-by: Ingo Molnar <mingo@kernel.org>
Tested-by: Paul E. McKenney <paulmck@kernel.org>
[ Upstream commit 57bbeacdbee72a54eb97d56b876cf9c94059fc34 ]
We observed the following deadlock in the stress test under low
memory scenario:
Thread A Thread B
- erofs_shrink_scan
- erofs_try_to_release_workgroup
- erofs_workgroup_try_to_freeze -- A
- z_erofs_do_read_page
- z_erofs_collection_begin
- z_erofs_register_collection
- erofs_insert_workgroup
- xa_lock(&sbi->managed_pslots) -- B
- erofs_workgroup_get
- erofs_wait_on_workgroup_freezed -- A
- xa_erase
- xa_lock(&sbi->managed_pslots) -- B
To fix this, it needs to hold xa_lock before freezing the workgroup
since xarray will be touched then. So let's hold the lock before
accessing each workgroup, just like what we did with the radix tree
before.
[ Gao Xiang: Jianhua Hao also reports this issue at
https://lore.kernel.org/r/b10b85df30694bac8aadfe43537c897a@xiaomi.com ]
Link: https://lore.kernel.org/r/20211118135844.3559-1-huangjianan@oppo.com
Fixes: 64094a04414f ("erofs: convert workstn to XArray")
Reviewed-by: Chao Yu <chao@kernel.org>
Reviewed-by: Gao Xiang <hsiangkao@linux.alibaba.com>
Change-Id: I40fe8b5aaf319915e9a71282f3007d5e9d57675d
Signed-off-by: Huang Jianan <huangjianan@oppo.com>
Reported-by: Jianhua Hao <haojianhua1@xiaomi.com>
Signed-off-by: Gao Xiang <xiang@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
If the 1st NONHEAD lcluster of a pcluster isn't CBLKCNT lcluster type
rather than a HEAD or PLAIN type instead, which means its pclustersize
_must_ be 1 lcluster (since its uncompressed size < 2 lclusters),
as illustrated below:
HEAD HEAD / PLAIN lcluster type
____________ ____________
|_:__________|_________:__| file data (uncompressed)
. .
.____________.
|____________| pcluster data (compressed)
Such on-disk case was explained before [1] but missed to be handled
properly in the runtime implementation.
It can be observed if manually generating 1 lcluster-sized pcluster
with 2 lclusters (thus CBLKCNT doesn't exist.) Let's fix it now.
[1] https://lore.kernel.org/r/20210407043927.10623-1-xiang@kernel.org
Link: https://lore.kernel.org/r/20210510064715.29123-1-xiang@kernel.org
Fixes: cec6e93beadf ("erofs: support parsing big pcluster compress indexes")
Reviewed-by: Chao Yu <yuchao0@huawei.com>
Signed-off-by: Gao Xiang <xiang@kernel.org>
Bug: 201372112
Change-Id: I7e46baa993790f8908287ac36e19d32e536116db
(cherry picked from commit 0852b6ca941ef3ff75076e85738877bd3271e1cd)
Signed-off-by: Huang Jianan <huangjianan@oppo.com>
Prior to big pcluster, there was only one compressed page so it'd
easy to map this. However, when big pcluster is enabled, more work
needs to be done to handle multiple compressed pages. In detail,
- (maptype 0) if there is only one compressed page + no need
to copy inplace I/O, just map it directly what we did before;
- (maptype 1) if there are more compressed pages + no need to
copy inplace I/O, vmap such compressed pages instead;
- (maptype 2) if inplace I/O needs to be copied, use per-CPU
buffers for decompression then.
Another thing is how to detect inplace decompression is feasable or
not (it's still quite easy for non big pclusters), apart from the
inplace margin calculation, inplace I/O page reusing order is also
needed to be considered for each compressed page. Currently, if the
compressed page is the xth page, it shouldn't be reused as [0 ...
nrpages_out - nrpages_in + x], otherwise a full copy will be triggered.
Although there are some extra optimization ideas for this, I'd like
to make big pcluster work correctly first and obviously it can be
further optimized later since it has nothing with the on-disk format
at all.
Link: https://lore.kernel.org/r/20210407043927.10623-10-xiang@kernel.org
Acked-by: Chao Yu <yuchao0@huawei.com>
Signed-off-by: Gao Xiang <hsiangkao@redhat.com>
Bug: 201372112
Change-Id: I8e8b90bd0a401850ea81d895dc55e5d8a2772ed7
(cherry picked from commit 598162d050801e556750defff4ddab499e5d76ed)
Signed-off-by: Huang Jianan <huangjianan@oppo.com>
Different from non-compact indexes, several lclusters are packed
as the compact form at once and an unique base blkaddr is stored for
each pack, so each lcluster index would take less space on avarage
(e.g. 2 bytes for COMPACT_2B.) btw, that is also why BIG_PCLUSTER
switch should be consistent for compact head0/1.
Prior to big pcluster, the size of all pclusters was 1 lcluster.
Therefore, when a new HEAD lcluster was scanned, blkaddr would be
bumped by 1 lcluster. However, that way doesn't work anymore for
big pcluster since we actually don't know the compressed size of
pclusters in advance (before reading CBLKCNT lcluster).
So, instead, let blkaddr of each pack be the first pcluster blkaddr
with a valid CBLKCNT, in detail,
1) if CBLKCNT starts at the pack, this first valid pcluster is
itself, e.g.
_____________________________________________________________
|_CBLKCNT0_|_NONHEAD_| .. |_HEAD_|_CBLKCNT1_| ... |_HEAD_| ...
^ = blkaddr base ^ += CBLKCNT0 ^ += CBLKCNT1
2) if CBLKCNT doesn't start at the pack, the first valid pcluster
is the next pcluster, e.g.
_________________________________________________________
| NONHEAD_| .. |_HEAD_|_CBLKCNT0_| ... |_HEAD_|_HEAD_| ...
^ = blkaddr base ^ += CBLKCNT0
^ += 1
When a CBLKCNT is found, blkaddr will be increased by CBLKCNT
lclusters, or a new HEAD is found immediately, bump blkaddr by 1
instead (see the picture above.)
Also noted if CBLKCNT is the end of the pack, instead of storing
delta1 (distance of the next HEAD lcluster) as normal NONHEADs,
it still uses the compressed block count (delta0) since delta1
can be calculated indirectly but the block count can't.
Adjust decoding logic to fit big pcluster compact indexes as well.
Link: https://lore.kernel.org/r/20210407043927.10623-9-xiang@kernel.org
Acked-by: Chao Yu <yuchao0@huawei.com>
Signed-off-by: Gao Xiang <hsiangkao@redhat.com>
Bug: 201372112
Change-Id: I09d6bb4c9d390dc6169cb9dd4efbc7fd6b3be5d0
(cherry picked from commit b86269f43892316ef5a177d7180d09d101a46f22)
Signed-off-by: Huang Jianan <huangjianan@oppo.com>
When INCOMPAT_BIG_PCLUSTER sb feature is enabled, legacy compress indexes
will also have the same on-disk header compact indexes to keep per-file
configurations instead of leaving it zeroed.
If ADVISE_BIG_PCLUSTER is set for a file, CBLKCNT will be loaded for each
pcluster in this file by parsing 1st non-head lcluster.
Link: https://lore.kernel.org/r/20210407043927.10623-8-xiang@kernel.org
Acked-by: Chao Yu <yuchao0@huawei.com>
Signed-off-by: Gao Xiang <hsiangkao@redhat.com>
Bug: 201372112
Change-Id: I97b8d1cc54e057789d22f1cdfafc21ed6a69b149
(cherry picked from commit cec6e93beadfd145758af2c0854fcc2abb8170cb)
Signed-off-by: Huang Jianan <huangjianan@oppo.com>
Big pcluster indicates the size of compressed data for each physical
pcluster is no longer fixed as block size, but could be more than 1
block (more accurately, 1 logical pcluster)
When big pcluster feature is enabled for head0/1, delta0 of the 1st
non-head lcluster index will keep block count of this pcluster in
lcluster size instead of 1. Or, the compressed size of pcluster
should be 1 lcluster if pcluster has no non-head lcluster index.
Also note that BIG_PCLUSTER feature reuses COMPR_CFGS feature since
it depends on COMPR_CFGS and will be released together.
Link: https://lore.kernel.org/r/20210407043927.10623-6-xiang@kernel.org
Acked-by: Chao Yu <yuchao0@huawei.com>
Signed-off-by: Gao Xiang <hsiangkao@redhat.com>
Bug: 201372112
Change-Id: Ibd33f2764f4420f370f9293ed325efdba9ea70a7
(cherry picked from commit 5404c33010cb8ee063c05376d4a2eba129872281)
Signed-off-by: Huang Jianan <huangjianan@oppo.com>
