The symbols exported by this commit were never used by external modules,
so just remove them as the exports are not needed (and cause merge
problems at times.)
Bug: 151050914
Bug: 203756332
Cc: Suren Baghdasaryan <surenb@google.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
Change-Id: I926ad3cc732ec1db97fc4711962bc3902105dd25
Cold files may be fragmented due to SSR, defragment is needed as
sequential reads are dominant scenarios of these files. FI_OPU_WRITE
should override FADVISE_COLD_BIT to avoid defragment fails.
Bug: 246903585
Signed-off-by: Weichao Guo <guoweichao@oppo.com>
Signed-off-by: Chao Yu <chao@kernel.org>
Signed-off-by: Jaegeuk Kim <jaegeuk@kernel.org>
Signed-off-by: Weichao Guo <guoweichao@oppo.corp-partner.google.com>
Link: https://lore.kernel.org/all/YxlTQ3H+PPKcvpyc@google.com/T/
Change-Id: I52ab86a15ec275772c5356bfc985803bbdde4408
In commit 731d2da95e ("ANDROID: usb: host: export xhci symbols for
ring management"), many xhci symbols were exported, but
xhci_get_endpoint_address was never actually used by any external
modules, so remove the export as it is unneeded.
Bug: 183761108
Bug: 203756332
Cc: Daehwan Jung <dh10.jung@samsung.com>
Fixes: 731d2da95e ("ANDROID: usb: host: export xhci symbols for ring management")
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
Change-Id: I08aab7192297c832f5a9dd559a016e6ff1140b86
Add an explicite check for ATTR_KILL_SUID and ATTR_MODE in incfs_setattr.
Both of these attributes can not be set at the same time, otherwise
notify_change() function will check it and invoke BUG(), crashing
the system.
Bug: 243394930
Signed-off-by: Tadeusz Struk <tadeusz.struk@linaro.org>
Change-Id: I91080d68efbd62f1441e20a5c02feef3d1b06e4e
Add hooks for support lookaround in memory reclamation.
add drivers/android/vendor_hooks.c for export tracepoint symbol
Bug: 241079328
Signed-off-by: Peifeng Li <lipeifeng@oppo.com>
Change-Id: Ia6e9fa0ae5708e88fa498c63cf63aad7c55e5f98
commit 4caae58406f8ceb741603eee460d79bacca9b1b5 upstream.
The device-mapper framework provides a mechanism to mark targets as
immutable (and hence fail table reloads that try to change the target
type). Add the DM_TARGET_IMMUTABLE flag to the dm-verity target's
feature flags to prevent switching the verity target with a different
target type.
Bug: 234475629
Fixes: a4ffc15219 ("dm: add verity target")
Cc: stable@vger.kernel.org
Signed-off-by: Sarthak Kukreti <sarthakkukreti@google.com>
Reviewed-by: Kees Cook <keescook@chromium.org>
Signed-off-by: Mike Snitzer <snitzer@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Lee Jones <joneslee@google.com>
Change-Id: Iaeec7fa3be98a646062439e4551f84242dacfb45
commit 189b0ddc245139af81198d1a3637cac74f96e13a upstream.
pipe_resize_ring() needs to take the pipe->rd_wait.lock spinlock to
prevent post_one_notification() from trying to insert into the ring
whilst the ring is being replaced.
The occupancy check must be done after the lock is taken, and the lock
must be taken after the new ring is allocated.
The bug can lead to an oops looking something like:
BUG: KASAN: use-after-free in post_one_notification.isra.0+0x62e/0x840
Read of size 4 at addr ffff88801cc72a70 by task poc/27196
...
Call Trace:
post_one_notification.isra.0+0x62e/0x840
__post_watch_notification+0x3b7/0x650
key_create_or_update+0xb8b/0xd20
__do_sys_add_key+0x175/0x340
__x64_sys_add_key+0xbe/0x140
do_syscall_64+0x5c/0xc0
entry_SYSCALL_64_after_hwframe+0x44/0xae
Reported by Selim Enes Karaduman @Enesdex working with Trend Micro Zero
Day Initiative.
Bug: 244395411
Fixes: c73be61ced ("pipe: Add general notification queue support")
Reported-by: zdi-disclosures@trendmicro.com # ZDI-CAN-17291
Signed-off-by: David Howells <dhowells@redhat.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Lee Jones <joneslee@google.com>
Change-Id: I129164eb9dba557d5a4370f4eca124b9916774a6
commit fee060cd52d69c114b62d1a2948ea9648b5131f9 upstream.
Whenever x86_decode_emulated_instruction() detects a breakpoint, it
returns the value that kvm_vcpu_check_breakpoint() writes into its
pass-by-reference second argument. Unfortunately this is completely
bogus because the expected outcome of x86_decode_emulated_instruction
is an EMULATION_* value.
Then, if kvm_vcpu_check_breakpoint() does "*r = 0" (corresponding to
a KVM_EXIT_DEBUG userspace exit), it is misunderstood as EMULATION_OK
and x86_emulate_instruction() is called without having decoded the
instruction. This causes various havoc from running with a stale
emulation context.
The fix is to move the call to kvm_vcpu_check_breakpoint() where it was
before commit 4aa2691dcbd3 ("KVM: x86: Factor out x86 instruction
emulation with decoding") introduced x86_decode_emulated_instruction().
The other caller of the function does not need breakpoint checks,
because it is invoked as part of a vmexit and the processor has already
checked those before executing the instruction that #GP'd.
This fixes CVE-2022-1852.
Bug: 235183128
Reported-by: Qiuhao Li <qiuhao@sysec.org>
Reported-by: Gaoning Pan <pgn@zju.edu.cn>
Reported-by: Yongkang Jia <kangel@zju.edu.cn>
Fixes: 4aa2691dcbd3 ("KVM: x86: Factor out x86 instruction emulation with decoding")
Cc: stable@vger.kernel.org
Signed-off-by: Sean Christopherson <seanjc@google.com>
Message-Id: <20220311032801.3467418-2-seanjc@google.com>
[Rewrote commit message according to Qiuhao's report, since a patch
already existed to fix the bug. - Paolo]
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Lee Jones <joneslee@google.com>
Change-Id: I3acbb7fc23566c4108f15960c420384af52c2703
commit 353f7988dd8413c47718f7ca79c030b6fb62cfe5 upstream.
When the pipe is closed, we mark the associated watchqueue defunct by
calling watch_queue_clear(). However, while that is protected by the
watchqueue lock, new watchqueue entries aren't actually added under that
lock at all: they use the pipe->rd_wait.lock instead, and looking up
that pipe happens without any locking.
The watchqueue code uses the RCU read-side section to make sure that the
wqueue entry itself hasn't disappeared, but that does not protect the
pipe_info in any way.
So make sure to actually hold the wqueue lock when posting watch events,
properly serializing against the pipe being torn down.
Bug: 235277737
Reported-by: Noam Rathaus <noamr@ssd-disclosure.com>
Cc: Greg KH <gregkh@linuxfoundation.org>
Cc: David Howells <dhowells@redhat.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Lee Jones <joneslee@google.com>
Change-Id: I42b0d56021be1d8950c3642ae0acc5cdccadb394
Relocate the pullups_connected check until after it is ensured that there
are no runtime PM transitions. If another context triggered the DWC3
core's runtime resume, it may have already enabled the Run/Stop. Do not
re-run the entire pullup sequence again, as it may issue a core soft
reset while Run/Stop is already set.
This patch depends on
commit 69e131d1ac4e ("usb: dwc3: gadget: Prevent repeat pullup()")
Fixes: 77adb8bdf422 ("usb: dwc3: gadget: Allow runtime suspend if UDC unbinded")
Cc: stable <stable@kernel.org>
Signed-off-by: Wesley Cheng <quic_wcheng@quicinc.com>
Link: https://lore.kernel.org/r/20220728020647.9377-1-quic_wcheng@quicinc.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Bug: 245440430
Change-Id: I8b819b4773420fbca3bd7a284d715401dcdd00c3
(cherry picked from commit 040f2dbd2010c43f33ad27249e6dac48456f4d99)
Signed-off-by: Prashanth K <quic_prashk@quicinc.com>
We found PPM will not send any notification after it report error status
and OPM issue GET_ERROR_STATUS command to read the details about error.
According UCSI spec, PPM may clear the Error Status Data after the OPM
has acknowledged the command completion.
This change add operation to acknowledge the command completion from PPM.
Fixes: bdc62f2bae (usb: typec: ucsi: Simplified registration and I/O API)
Cc: <stable@vger.kernel.org> # 5.10
Signed-off-by: Jack Pham <quic_jackp@quicinc.com>
Signed-off-by: Linyu Yuan <quic_linyyuan@quicinc.com>
Link: https://lore.kernel.org/r/1658817949-4632-1-git-send-email-quic_linyyuan@quicinc.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Bug: 241140735
Change-Id: I8447d618200163c6819f93f8d8b5b7f2bece5e13
(cherry picked from commit a7dc438b5e446afcd1b3b6651da28271400722f2)
Signed-off-by: Mayank Rana <quic_mrana@quicinc.com>
Signed-off-by: Prashanth K <quic_prashk@quicinc.com>
UFS devices are expected to clear fDeviceInit flag in single digit
milliseconds. Current values of 5 to 10 millisecond sleep add to increased
latency during the initialization and resume path. This CL lowers the sleep
range to 500 to 1000 microseconds.
Bug: 236993021
Link: https://lore.kernel.org/r/20220421002429.3136933-1-bvanassche@acm.org
Acked-by: Avri Altman <avri.altman@wdc.com>
Signed-off-by: Konstantin Vyshetsky <vkon@google.com>
Signed-off-by: Bart Van Assche <bvanassche@acm.org>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
(cherry picked from commit a4e6496fca3f32e997e8a3b5c44e2a1ae09d018e)
Change-Id: I3a9a01853e89ea73ff5e355007db4730fa853ea0
This patch increases the threshold that limits the reserved root space from 0.2%
to 12.5% by using simple shift operation.
Typically Android sets 128MB, but if the storage capacity is 32GB, 0.2% which is
around 64MB becomes too small. Let's relax it.
Bug: 243493735
Cc: stable@vger.kernel.org
Reported-by: Aran Dalton <arda@allwinnertech.com>
Signed-off-by: Jaegeuk Kim <jaegeuk@kernel.org>
Change-Id: Ia76ae8f9dd1c7a5f123a561f081bf5a4a29ac186
(cherry picked from commit cf42f1d7ab33ea2637f3c6b786a76302f719726b
https://git.kernel.org/pub/scm/linux/kernel/git/jaegeuk/f2fs.git dev)
Once F2FS_IPU_FORCE policy is enabled in some cases:
a) f2fs forces to use F2FS_IPU_FORCE in a small-sized volume
b) user sets F2FS_IPU_FORCE policy via sysfs
Then we may fail to defragment file due to IPU policy check, it doesn't
make sense, let's introduce a new IPU policy to allow OPU during file
defragmentation.
In small-sized volume, let's enable F2FS_IPU_HONOR_OPU_WRITE policy
by default.
Bug: 244657983
Signed-off-by: Chao Yu <chao@kernel.org>
Signed-off-by: Jaegeuk Kim <jaegeuk@kernel.org>
(cherry picked from commit 1018a5463a063715365784704c4e8cdf2eec4b04)
Change-Id: I05dfa5a07a6a17dcda68f50a8f4a8260c2612dcc
This reverts commit a719abf031.
The symbol was never used by any external module, 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
After commit e3b49ea36802 ("f2fs: invalidate META_MAPPING before
IPU/DIO write"), invalidate_mapping_pages() will be called to
avoid race condition in between IPU/DIO and readahead for GC.
However, readahead flow is only used for post_read required inode,
so this patch adds check condition to avoids unnecessary page cache
invalidating for non-post_read inode.
Bug: 243874214
Signed-off-by: Chao Yu <chao.yu@oppo.com>
Signed-off-by: Jaegeuk Kim <jaegeuk@kernel.org>
Signed-off-by: Chao Yu <chao@kernel.org>
(cherry picked from commit 0d5b9d8156396bbe1c982708b38ab9e188c45ec9)
Change-Id: I39a8da4183b59b34522f445d25d8ab9fd2d6319c
Quoted from commit e3b49ea36802 ("f2fs: invalidate META_MAPPING before
IPU/DIO write")
"
Encrypted pages during GC are read and cached in META_MAPPING.
However, due to cached pages in META_MAPPING, there is an issue where
newly written pages are lost by IPU or DIO writes.
Thread A - f2fs_gc() Thread B
/* phase 3 */
down_write(i_gc_rwsem)
ra_data_block() ---- (a)
up_write(i_gc_rwsem)
f2fs_direct_IO() :
- down_read(i_gc_rwsem)
- __blockdev_direct_io()
- get_data_block_dio_write()
- f2fs_dio_submit_bio() ---- (b)
- up_read(i_gc_rwsem)
/* phase 4 */
down_write(i_gc_rwsem)
move_data_block() ---- (c)
up_write(i_gc_rwsem)
(a) In phase 3 of f2fs_gc(), up-to-date page is read from storage and
cached in META_MAPPING.
(b) In thread B, writing new data by IPU or DIO write on same blkaddr as
read in (a). cached page in META_MAPPING become out-dated.
(c) In phase 4 of f2fs_gc(), out-dated page in META_MAPPING is copied to
new blkaddr. In conclusion, the newly written data in (b) is lost.
To address this issue, invalidating pages in META_MAPPING before IPU or
DIO write.
"
In previous commit, we missed to cover extent cache hit case, and passed
wrong value for parameter @end of invalidate_mapping_pages(), fix both
issues.
Bug: 243874214
Fixes: 6aa58d8ad2 ("f2fs: readahead encrypted block during GC")
Fixes: e3b49ea36802 ("f2fs: invalidate META_MAPPING before IPU/DIO write")
Cc: Hyeong-Jun Kim <hj514.kim@samsung.com>
Signed-off-by: Chao Yu <chao.yu@oppo.com>
Signed-off-by: Jaegeuk Kim <jaegeuk@kernel.org>
Signed-off-by: Chao Yu <chao@kernel.org>
(cherry picked from commit 67ca06872eb02944b4c6f92cffa9242e92c63109)
Change-Id: Icbfb0a0004172a0af9ab59ffabf92ee7c5f16791
Encrypted pages during GC are read and cached in META_MAPPING.
However, due to cached pages in META_MAPPING, there is an issue where
newly written pages are lost by IPU or DIO writes.
Thread A - f2fs_gc() Thread B
/* phase 3 */
down_write(i_gc_rwsem)
ra_data_block() ---- (a)
up_write(i_gc_rwsem)
f2fs_direct_IO() :
- down_read(i_gc_rwsem)
- __blockdev_direct_io()
- get_data_block_dio_write()
- f2fs_dio_submit_bio() ---- (b)
- up_read(i_gc_rwsem)
/* phase 4 */
down_write(i_gc_rwsem)
move_data_block() ---- (c)
up_write(i_gc_rwsem)
(a) In phase 3 of f2fs_gc(), up-to-date page is read from storage and
cached in META_MAPPING.
(b) In thread B, writing new data by IPU or DIO write on same blkaddr as
read in (a). cached page in META_MAPPING become out-dated.
(c) In phase 4 of f2fs_gc(), out-dated page in META_MAPPING is copied to
new blkaddr. In conclusion, the newly written data in (b) is lost.
To address this issue, invalidating pages in META_MAPPING before IPU or
DIO write.
Bug: 243874214
Fixes: 6aa58d8ad2 ("f2fs: readahead encrypted block during GC")
Signed-off-by: Hyeong-Jun Kim <hj514.kim@samsung.com>
Reviewed-by: Chao Yu <chao@kernel.org>
Signed-off-by: Jaegeuk Kim <jaegeuk@kernel.org>
Signed-off-by: Chao Yu <chao@kernel.org>
(cherry picked from commit e3b49ea36802053f312013fd4ccb6e59920a9f76)
Change-Id: I1c0af14c2d63c115b882bf38ba61ea7924a70bb1
Use page_ext_get/put() to work with the page extended information
without which the page extended information may not be valid.
Bug: 2129036
Change-Id: Ibfe036b9ecef0e2551b5d0da1011cacbb0a5c3e6
Signed-off-by: Charan Teja Kalla <quic_charante@quicinc.com>
The below is one path where race between page_ext and offline of the
respective memory blocks will cause use-after-free on the access of
page_ext structure.
process1 process2
--------- ---------
a)doing /proc/page_owner doing memory offline
through offline_pages.
b)PageBuddy check is failed
thus proceed to get the
page_owner information
through page_ext access.
page_ext = lookup_page_ext(page);
migrate_pages();
.................
Since all pages are successfully
migrated as part of the offline
operation,send MEM_OFFLINE notification
where for page_ext it calls:
offline_page_ext()-->
__free_page_ext()-->
free_page_ext()-->
vfree(ms->page_ext)
mem_section->page_ext = NULL
c) Check for the PAGE_EXT flags
in the page_ext->flags access
results into the use-after-free(leading
to the translation faults).
As mentioned above, there is really no synchronization between page_ext
access and its freeing in the memory_offline.
The memory offline steps(roughly) on a memory block is as below:
1) Isolate all the pages
2) while(1)
try free the pages to buddy.(->free_list[MIGRATE_ISOLATE])
3) delete the pages from this buddy list.
4) Then free page_ext.(Note: The struct page is still alive as it is
freed only during hot remove of the memory which frees the memmap, which
steps the user might not perform).
This design leads to the state where struct page is alive but the struct
page_ext is freed, where the later is ideally part of the former which
just representing the page_flags (check [3] for why this design is
chosen).
The above mentioned race is just one example __but the problem persists
in the other paths too involving page_ext->flags access(eg:
page_is_idle())__.
Fix all the paths where offline races with page_ext access by
maintaining synchronization with rcu lock and is achieved in 3 steps:
1) Invalidate all the page_ext's of the sections of a memory block by
storing a flag in the LSB of mem_section->page_ext.
2) Wait till all the existing readers to finish working with the
->page_ext's with synchronize_rcu(). Any parallel process that starts
after this call will not get page_ext, through lookup_page_ext(), for
the block parallel offline operation is being performed.
3) Now safely free all sections ->page_ext's of the block on which
offline operation is being performed.
Note: If synchronize_rcu() takes time then optimizations can be done in
this path through call_rcu()[2].
Thanks to David Hildenbrand for his views/suggestions on the initial
discussion[1] and Pavan kondeti for various inputs on this patch.
[1] https://lore.kernel.org/linux-mm/59edde13-4167-8550-86f0-11fc67882107@quicinc.com/
[2] https://lore.kernel.org/all/a26ce299-aed1-b8ad-711e-a49e82bdd180@quicinc.com/T/#u
[3] https://lore.kernel.org/all/6fa6b7aa-731e-891c-3efb-a03d6a700efa@redhat.com/
Bug: 236222283
Link: https://lore.kernel.org/all/1661496993-11473-1-git-send-email-quic_charante@quicinc.com/
Change-Id: Ib439ae19c61a557a5c70ea90e3c4b35a5583ba0d
Suggested-by: David Hildenbrand <david@redhat.com>
Suggested-by: Michal Hocko <mhocko@suse.com>
Signed-off-by: Charan Teja Kalla <quic_charante@quicinc.com>
(fixed merge conflicts and still exported lookup_page_ext)
This reverts commit e5b4949bfc.
The hook android_vh_tune_memcg_scan_type 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: 230450931
Cc: xiaofeng <xiaofeng5@xiaomi.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
Change-Id: I0e32c24d67a9ede087eca5005796512a9451c1e2
Fix a warning caused by ignoring the return value of kstrtobool:
mm/memblock.c: In function 'early_memblock_nomap':
>> mm/memblock.c:1910:9: warning: ignoring return value of 'kstrtobool' declared with attribute 'warn_unused_result' [-Wunused-result]
1910 | kstrtobool(str, &memblock_nomap_remove);
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Fixes: 3c2f107ad2 ("ANDROID: mm: memblock: avoid to create memmap for memblock nomap regions")
Bug: 227974747
Reported-by: kernel test robot <lkp@intel.com>
Signed-off-by: Suren Baghdasaryan <surenb@google.com>
Change-Id: I9cc1145492e47a6604b8204165058d8617c0aaaa
This reverts commit f06daa5a0b.
The hook android_vh_ra_tuning_max_page 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: 229839032
Cc: liang zhang <liang.zhang@transsion.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
Change-Id: Id9211dfd9e1fa19d2ccb14302c60f0d55579f59d
This reverts commit 8c3ac02bca.
The hook android_vh_mutex_start_check_new_owner 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: 231647361
Cc: Liujie Xie <xieliujie@oppo.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
Change-Id: I8c3bf787525d684f64b8d0654d379df78eb7b69e
The file android/abi_gki_aarch64_asus should not have execute
permissions set on it, so fix that up.
Fixes: 428d0bb762 ("ANDROID: Add initial ASUS symbol list")
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
Change-Id: I96b96ed6a93e4aa13de07e1f225de79a78a30867
Clearing trylock-bit of page shrinked by shrnk_page_list in advance
which avoids huge-page not to clear trylock-bit after shrink_page_list.
Fixes: 1f8f6d59a2 ("ANDROID: vendor_hook: Add hook to not be stuck ro rmap lock in kswapd or direct_reclaim")
Bug: 240003372
Signed-off-by: Peifeng Li <lipeifeng@oppo.com>
Change-Id: Iac4d60ec3497d9bb7ba1f001a5c08a604daf4f5a
If an important task is going to sleep through do_futex(),
find out it's futex-owner by the pid comes from userspace,
and boost the owner by some means to shorten the sleep time.
How to boost? Depends on these hooks:
53e8099784 ("ANDROID: vendor_hooks: Add hooks for scheduler")
Bug: 243110112
Signed-off-by: xieliujie <xieliujie@oppo.com>
Change-Id: I9a315cfb414fd34e0ef7a2cf9d57df50d4dd984f
This 'commit 86588296acbf ("fdt: Properly handle "no-map" field in the
memory region")' is keeping the no-map regions in memblock.memory with
MEMBLOCK_NOMAP flag set to use no-map memory for EFI using memblock
api's, but during the initialization sparse_init mark all memblock.memory
as present using for_each_mem_pfn_range, which is creating the memmap for
no-map memblock regions.
Upstream has suggested to make use of bootloader to pass this as not a
memory,but because of possibility that some bootloaders might not support
this and also due to time constraints in evaluating this approach on 5.10,
Use command line parameter as a temporary solution. Get in the appropriate
solution later after further discussion with upstream.
Add kernel param "android12_only.will_be_removed_soon.memblock_nomap_remove"
which when enabled will remove page structs for these regions using memblock_remove.
With this change we will be able to save ~11MB memory for ~612MB carve out.
android12_only.will_be_removed_soon.memblock_nomap_remove=true:
[ 0.000000] memblock_alloc_exact_nid_raw: 115343360 bytes
align=0x200000 nid=0 from=0x0000000080000000 max_addr=0x0000000000000000
sparse_buffer_init+0x60/0x8c
[ 0.000000] memblock_reserve: [0x0000000932c00000-0x00000009399fffff]
memblock_alloc_range_nid+0xbc/0x1a0
[ 0.000000] On node 0 totalpages: 1627824
[ 0.000000] DMA32 zone: 5383 pages used for memmap
[ 0.000000] Normal zone: 20052 pages used for memmap
Default or android12_only.will_be_removed_soon.memblock_nomap_remove=false:
[ 0.000000] memblock_alloc_exact_nid_raw: 117440512 bytes
align=0x200000 nid=0 from=0x0000000080000000 max_addr=0x0000000000000000
sparse_buffer_init+0x60/0x8c
[ 0.000000] memblock_reserve: [0x0000000932a00000-0x00000009399fffff]
memblock_alloc_range_nid+0xbc/0x1a0
[ 0.000000] On node 0 totalpages: 1788416
[ 0.000000] DMA32 zone: 8192 pages used for memmap
[ 0.000000] Normal zone: 20052 pages used for memmap.
Change-Id: I34a7d46f02a6df7c769af3e53e44e49d6fc515af
Bug: 227974747
Link: https://lore.kernel.org/all/20210115172949.GA1495225@robh.at.kernel.org
Signed-off-by: Faiyaz Mohammed <quic_faiyazm@quicinc.com>
Signed-off-by: Vijayanand Jitta <quic_vjitta@quicinc.com>
Add vendor hook to thermal to allow vendor to selectively disable
thermal cooling device stats feature based on requirement. It helps
vendor to optimize memory footprint due to this feature especially
for low memory devices.
Bug: 218825214
Change-Id: I2ec72505f03575e09229c54765584614b16a3904
Signed-off-by: Manaf Meethalavalappu Pallikunhi <quic_manafm@quicinc.com>
(cherry picked from commit f6e47fd00f24d5e814d316b03974e970dd87879e)
Sync the latest fragment file.
Bug: 239396464
Signed-off-by: Kever Yang <kever.yang@rock-chips.com>
Change-Id: I2e0afd0c4ff7a60b712e642cbe8a914c4407602d
Bringing up a CPU may involve creating and destroying tasks which requires
read-locking threadgroup_rwsem, so threadgroup_rwsem nests inside
cpus_read_lock(). However, cpuset's ->attach(), which may be called with
thredagroup_rwsem write-locked, also wants to disable CPU hotplug and
acquires cpus_read_lock(), leading to a deadlock.
Fix it by guaranteeing that ->attach() is always called with CPU hotplug
disabled and removing cpus_read_lock() call from cpuset_attach().
Bug: 242685775
Change-Id: Ib14746f8e361eac8a1cfb88ae920488d1155d904
Signed-off-by: Tejun Heo <tj@kernel.org>
Reviewed-and-tested-by: Imran Khan <imran.f.khan@oracle.com>
Reported-and-tested-by: Xuewen Yan <xuewen.yan@unisoc.com>
Fixes: 05c7b7a92cc8 ("cgroup/cpuset: Fix a race between cpuset_attach() and cpu hotplug")
Cc: stable@vger.kernel.org # v5.17+
Link: https://lore.kernel.org/lkml/YvrWaml3F+x9Dk+T@slm.duckdns.org/
Link: https://lore.kernel.org/lkml/20220705123705.764-1-xuewen.yan@unisoc.com/
(cherry picked from commit 4f7e7236435ca0abe005c674ebd6892c6e83aeb3
https://git.kernel.org/pub/scm/linux/kernel/git/tj/cgroup.git for-6.0-fixes)
Signed-off-by: Mukesh Ojha <quic_mojha@quicinc.com>
cgroup_update_dfl_csses() write-lock the threadgroup_rwsem as updating the
csses can trigger process migrations. However, if the subtree doesn't
contain any tasks, there aren't gonna be any cgroup migrations. This
condition can be trivially detected by testing whether
mgctx.preloaded_src_csets is empty. Elide write-locking threadgroup_rwsem if
the subtree is empty.
After this optimization, the usage pattern of creating a cgroup, enabling
the necessary controllers, and then seeding it with CLONE_INTO_CGROUP and
then removing the cgroup after it becomes empty doesn't need to write-lock
threadgroup_rwsem at all.
Bug: 242685775
Change-Id: Ifc96030fc7b0655ecd85ef19c52c9ed97e910ffb
Signed-off-by: Tejun Heo <tj@kernel.org>
Cc: Christian Brauner <brauner@kernel.org>
Cc: Michal Koutný <mkoutny@suse.com>
(cherry picked from commit 671c11f0619e5ccb380bcf0f062f69ba95fc974a
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git master)
Signed-off-by: Mukesh Ojha <quic_mojha@quicinc.com>
