this hook will allow to account tick in every third of more ticks
to save cpu time for accounting
Bug: 279549765
Change-Id: I5d18e0167fdce076d13aecc653dcf6387bcb25f2
Signed-off-by: Liujie Xie <xieliujie@oppo.com>
Add hook in try_to_unmap_one() to trace this function for debug memory
swap bugs.
Bug: 198385827
Change-Id: I1fdbe60e09bb491b949e06a07133710453ecca03
Signed-off-by: Jiewen Wang <jiewen.wang@vivo.com>
(cherry picked from commit 5a70133febf92e1269f98b533ce9f188c2e3b135)
Add hook in mmap_region() to record the vma and address information
of monitored processes.
Bug: 198385827
Change-Id: I0bde29113b47ca7f4a9f5d42a54188e791ca3b7e
Signed-off-by: Jiewen Wang <jiewen.wang@vivo.com>
(cherry picked from commit 73c9d4a9d575107b90a6d9f415fa56f963264d06)
This is a partial revert of commit 444b34b83a in order to fix booting
this kernel on devices that don't support FEAT_FGT due to direct
accesses of HFGWTR_EL2 being UNDEFINED. We are retaining the KMI part of
the commit until the next KMI breakage window.
Bug: 282917063
Change-Id: I6c156ef40a5584dc41e4d9d09c80736e30348802
Signed-off-by: Will McVicker <willmcvicker@google.com>
Add the vendor hook to freezer.c so that OEM's logic can be executed
when the process is about to be frozen. We need to clear the flag for
some tasks and rebind task dependencies for optimization purposes.
Bug: 187458531
Bug: 281920779
Signed-off-by: heshuai1 <heshuai1@xiaomi.com>
Change-Id: Iea42fd9604d6b33ccd6502425416f0dd28eecebb
(cherry picked from commit a1580311c3)
Exporting the symbol freezer_cgrp_subsys, in that vendor module can
add can_attach & cancel_attach member function. It is vendor-specific
tuning.
Bug: 182496370
Bug: 281920779
Signed-off-by: Zhuguangqing <zhuguangqing@xiaomi.com>
Change-Id: I153682b9d1015eed3f048b45ea6495ebb8f3c261
(cherry picked from commit ee3f4d2821)
(cherry picked from commit 8a90e4d4e555dd5484213c6fec5061958016a194)
Add some hooks in the binder module so that we can do task dependency analysis and statistical work in OEM's module for further optimization.
Bug: 235925535
Bug: 281920779
Signed-off-by: Zhuguangqing <zhuguangqing@xiaomi.com>
Change-Id: Id47e59c4e3ccd07b26eef758ada147b98cd1964e
Signed-off-by: heshuai1 <heshuai1@xiaomi.com>
Signed-off-by: Carlos Llamas <cmllamas@google.com>
[ cmllamas: don't export complete private definition struct binder_alloc
in vendor hooks, instead just pass member alloc->free_async_space as
implemented by heshuai1 and squashed here ]
(cherry picked from commit 254fb1f4034fde523378ee58a501d212a59047b7)
This hook will allow us to get signal messages so that we can set
limitations for certain tasks and restore them when receiving important signals.
Bug: 184898838
Bug: 281920779
Signed-off-by: Zhuguangqing <zhuguangqing@xiaomi.com>
Change-Id: I83a28b0a6eb413976f4c57f2314d008ad792fa0d
(cherry picked from commit 58e3f869fc)
There is a race window between page_pinner_inited set and the pp_buffer
initialization which cause accessing the pp_buffer->lock. Avoid this by
moving the pp_buffer initialization to page_ext_ops->init() which sets
the page_pinner_inited only after the pp_buffer is initialized.
Race scenario:
1) init_page_pinner is called --> page_pinner_inited is set.
2) __alloc_contig_migrate_range --> __page_pinner_failure_detect()
accesses the pp_buffer->lock(yet to be initialized).
3) Then the pp_buffer is allocated and initialized.
Below is the issue call stack:
spin_bug+0x0
_raw_spin_lock_irqsave+0x3c
__page_pinner_failure_detect+0x110
__alloc_contig_migrate_range+0x1c4
alloc_contig_range+0x130
cma_alloc+0x170
dma_alloc_contiguous+0xa0
__dma_direct_alloc_pages+0x16c
dma_direct_alloc+0x88
Bug: 259024332
Change-Id: I6849ac4d944498b9a431b47cad7adc7903c9bbaa
Signed-off-by: Charan Teja Kalla <quic_charante@quicinc.com>
If page_pinner is configured with page_pinner_enabled=false and
failure_tracking=true, pp_buffer will be accessed without being
initialized. Prevent this by adding page_pinner_inited checks in
functions that access it.
Fixes: 898cfbf094a2 ("ANDROID: mm: introduce page_pinner")
Bug: 259024332
Bug: 260179017
Change-Id: I8f612cae3e74d36e8a4eee5edec25281246cbe5e
Signed-off-by: Suren Baghdasaryan <surenb@google.com>
Signed-off-by: Richard Chang <richardycc@google.com>
(cherry picked from commit 23fb3111f63e5fe239a769668275c20493a5849c)
For CMA allocation, it's really critical to migrate a page but
sometimes it fails. One of the reasons is some driver holds a
page refcount for a long time so VM couldn't migrate the page
at that time.
The concern here is there is no way to find the who hold the
refcount of the page effectively. This patch introduces feature
to keep tracking page's pinner. All get_page sites are vulnerable
to pin a page for a long time but the cost to keep track it would
be significat since get_page is the most frequent kernel operation.
Furthermore, the page could be not user page but kernel page which
is not related to the page migration failure.
Thus, this patch keeps tracks of only migration failed pages to
reduce runtime cost. Once page migration fails in CMA allocation
path, those pages are marked as "migration failure" and every
put_page operation against those pages, callstack of the put
are recorded into page_pinner buffer. Later, admin can see
what pages were failed and who released the refcount since the
failure. It really helps effectively to find out longtime refcount
holder to prevent the page migration.
note: page_pinner doesn't guarantee attributing/unattributing are
atomic if they happen at the same time. It's just best effort so
false-positive could happen.
Bug: 183414571
BUg: 240196534
Signed-off-by: Minchan Kim <minchan@kernel.org>
Signed-off-by: Minchan Kim <minchan@google.com>
Change-Id: I603d0c0122734c377db6b1eb95848a6f734173a0
(cherry picked from commit 898cfbf094a2fc13c67fab5b5d3c916f0139833a)
From commit 80dfafb2b9b6 ("ANDROID: gunyah: Sync with latest "firmware:
qcom_scm: Register Gunyah platform ops""), the QCOM platform extensions
now use gh_rm_(un)register_platform_ops instead of the devm_ equivalent
because the platform extensions are no longer directly backed by a
device.
2 function symbol(s) added
'int gh_rm_register_platform_ops(struct gh_rm_platform_ops*)'
'void gh_rm_unregister_platform_ops(struct gh_rm_platform_ops*)'
Bug: 279506910
Change-Id: I7ad36387a9d254691ecf9b769e058d972bd41c42
Signed-off-by: Elliot Berman <quic_eberman@quicinc.com>
The srcvm parameter of qcom_scm_assign_mem is a pointer to a bitfield of
VMIDs. The bitfield is updated with which VMIDs have permissions
after the qcom_scm_assign_mem call. This makes it simpler for clients to
make qcom_scm_assign_mem calls later, they always pass in same srcvm
bitfield and do not need to closely track whether memory was originally
shared.
When restoring permissions to HLOS, fastrpc is incorrectly using the
first VMID directly -- neither the BIT nor the other possible VMIDs the
memory was already assigned to. We already have a field intended for
this purpose: "perms" in the struct fastrpc_channel_ctx, but it was
never used. Start using the perms field.
Cc: Abel Vesa <abel.vesa@linaro.org>
Cc: Vamsi Krishna Gattupalli <quic_vgattupa@quicinc.com>
Cc: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
Fixes: e90d911906 ("misc: fastrpc: Add support to secure memory map")
Fixes: 0871561055 ("misc: fastrpc: Add support for audiopd")
Fixes: 532ad70c6d ("misc: fastrpc: Add mmap request assigning for static PD pool")
Tested-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
Signed-off-by: Elliot Berman <quic_eberman@quicinc.com>
drivers/misc/fastrpc.c | 15 ++++++---------
1 file changed, 6 insertions(+), 9 deletions(-)
Link: https://lore.kernel.org/r/20230112182313.521467-1-quic_eberman@quicinc.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Bug: 279506910
(cherry picked from commit aaca766c77)
[eberman: Drop modifications to qcom_scm_assign_mem not in 14-6.1]
Change-Id: I9eff564504fa277519245a446eb6fcad41a0ee42
Signed-off-by: Elliot Berman <quic_eberman@quicinc.com>
Align Gunyah memory parcel to Gunyah v12 patches posted to kernel.org.
We deviate from a perfect copy from kernel.org because:
- in pages_are_mergeable, zone_device_pages_have_same_pgmap is not
present in 6.1. Drop this check.
https://lore.kernel.org/all/20230509204801.2824351-11-quic_eberman@quicinc.com/
Bug: 279506910
Change-Id: I90ec2ac416b24bcc65635f27cae7665ce879783f
Signed-off-by: Elliot Berman <quic_eberman@quicinc.com>
Implement a robust overflows_type() macro to test if a variable or
constant value would overflow another variable or type. This can be
used as a constant expression for static_assert() (which requires a
constant expression[1][2]) when used on constant values. This must be
constructed manually, since __builtin_add_overflow() does not produce
a constant expression[3].
Additionally adds castable_to_type(), similar to __same_type(), but for
checking if a constant value would overflow if cast to a given type.
Add unit tests for overflows_type(), __same_type(), and castable_to_type()
to the existing KUnit "overflow" test:
[16:03:33] ================== overflow (21 subtests) ==================
...
[16:03:33] [PASSED] overflows_type_test
[16:03:33] [PASSED] same_type_test
[16:03:33] [PASSED] castable_to_type_test
[16:03:33] ==================== [PASSED] overflow =====================
[16:03:33] ============================================================
[16:03:33] Testing complete. Ran 21 tests: passed: 21
[16:03:33] Elapsed time: 24.022s total, 0.002s configuring, 22.598s building, 0.767s running
[1] https://en.cppreference.com/w/c/language/_Static_assert
[2] C11 standard (ISO/IEC 9899:2011): 6.7.10 Static assertions
[3] https://gcc.gnu.org/onlinedocs/gcc/Integer-Overflow-Builtins.html
6.56 Built-in Functions to Perform Arithmetic with Overflow Checking
Built-in Function: bool __builtin_add_overflow (type1 a, type2 b,
Cc: Luc Van Oostenryck <luc.vanoostenryck@gmail.com>
Cc: Nathan Chancellor <nathan@kernel.org>
Cc: Nick Desaulniers <ndesaulniers@google.com>
Cc: Tom Rix <trix@redhat.com>
Cc: Daniel Latypov <dlatypov@google.com>
Cc: Vitor Massaru Iha <vitor@massaru.org>
Cc: "Gustavo A. R. Silva" <gustavoars@kernel.org>
Cc: Jani Nikula <jani.nikula@intel.com>
Cc: Mauro Carvalho Chehab <mchehab@kernel.org>
Cc: linux-hardening@vger.kernel.org
Cc: llvm@lists.linux.dev
Co-developed-by: Gwan-gyeong Mun <gwan-gyeong.mun@intel.com>
Signed-off-by: Gwan-gyeong Mun <gwan-gyeong.mun@intel.com>
Signed-off-by: Kees Cook <keescook@chromium.org>
Link: https://lore.kernel.org/r/20221024201125.1416422-1-gwan-gyeong.mun@intel.com
Bug: 279506910
(cherry picked from commit 4b21d25bf5)
Change-Id: I20aff9de6b82a2f5203367d30555f904681a5b7b
Signed-off-by: Elliot Berman <quic_eberman@quicinc.com>
commit c8b5a95b57 upstream.
[Why]
After gpu-reset, sometimes the driver fails to enable vblank irq,
causing flip_done timed out and the desktop freezed.
During gpu-reset, we disable and enable vblank irq in dm_suspend() and
dm_resume(). Later on in amdgpu_irq_gpu_reset_resume_helper(), we check
irqs' refcount and decide to enable or disable the irqs again.
However, we have 2 sets of API for controling vblank irq, one is
dm_vblank_get/put() and another is amdgpu_irq_get/put(). Each API has
its own refcount and flag to store the state of vblank irq, and they
are not synchronized.
In drm we use the first API to control vblank irq but in
amdgpu_irq_gpu_reset_resume_helper() we use the second set of API.
The failure happens when vblank irq was enabled by dm_vblank_get()
before gpu-reset, we have vblank->enabled true. However, during
gpu-reset, in amdgpu_irq_gpu_reset_resume_helper() vblank irq's state
checked from amdgpu_irq_update() is DISABLED. So finally it disables
vblank irq again. After gpu-reset, if there is a cursor plane commit,
the driver will try to enable vblank irq by calling drm_vblank_enable(),
but the vblank->enabled is still true, so it fails to turn on vblank
irq and causes flip_done can't be completed in vblank irq handler and
desktop become freezed.
[How]
Combining the 2 vblank control APIs by letting drm's API finally calls
amdgpu_irq's API, so the irq's refcount and state of both APIs can be
synchronized. Also add a check to prevent refcount from being less then
0 in amdgpu_irq_put().
v2:
- Add warning in amdgpu_irq_enable() if the irq is already disabled.
- Call dc_interrupt_set() in dm_set_vblank() to avoid refcount change
if it is in gpu-reset.
v3:
- Improve commit message and code comments.
Change-Id: I44a9569645ce40ea1cf98fce4741c9e683160220
Signed-off-by: Alan Liu <HaoPing.Liu@amd.com>
Reviewed-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
(cherry picked from commit bef774effb)
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
commit 86a24e99c9 upstream.
dma_request_slave_channel() may return NULL which will lead to
NULL pointer dereference error in 'tmp_chan->private'.
Correct this behaviour by, first, switching from deprecated function
dma_request_slave_channel() to dma_request_chan(). Secondly, enable
sanity check for the resuling value of dma_request_chan().
Also, fix description that follows the enacted changes and that
concerns the use of dma_request_slave_channel().
Fixes: 706e2c8811 ("ASoC: fsl_asrc_dma: Reuse the dma channel if available in Back-End")
Co-developed-by: Natalia Petrova <n.petrova@fintech.ru>
Change-Id: I2ae5ca9cbb40afd7c5f066e8ed984cf4f35c832e
Signed-off-by: Nikita Zhandarovich <n.zhandarovich@fintech.ru>
Acked-by: Shengjiu Wang <shengjiu.wang@gmail.com>
Link: https://lore.kernel.org/r/20230417133242.53339-1-n.zhandarovich@fintech.ru
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
(cherry picked from commit 6cb818ed5f)
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
commit 0b186bb061 upstream.
With PCI if the device was suspended it is brought back to full
power and then suspended again.
This doesn't happen when device is described via DT.
We need to make sure that we tear down pipelines only if the device
was previously active (thus the pipelines were setup).
Otherwise, we can break the use_count:
[ 219.009743] sof-audio-of-imx8m 3b6e8000.dsp:
sof_ipc3_tear_down_all_pipelines: widget PIPELINE.2.SAI3.IN is still in use: count -1
and after this everything stops working.
Fixes: d185e0689a ("ASoC: SOF: pm: Always tear down pipelines before DSP suspend")
Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Reviewed-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com>
Change-Id: Ic7f724954ede17a021a486dba6c9eed9e3354438
Signed-off-by: Daniel Baluta <daniel.baluta@nxp.com>
Link: https://lore.kernel.org/r/20230405092655.19587-1-daniel.baluta@oss.nxp.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
(cherry picked from commit 7a6593b5d7)
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
commit dc70eb868b upstream.
The current code path can lead to warnings because of uninitialized device,
which contains, as a consequence, uninitialized kobject. The uninitialized
device is passed to of_platform_populate, which will at some point, while
creating child device, try to get a reference on uninitialized parent,
resulting in the following warning:
kobject: '(null)' ((ptrval)): is not initialized, yet kobject_get() is
being called.
The warning is observed after migrating a kernel 5.10.x to 6.1.x.
Reverting commit 0d70af3c25 ("fpga: bridge: Use standard dev_release for
class driver") seems to remove the warning.
This commit aggregates device_initialize() and device_add() into
device_register() but this new call is done AFTER of_platform_populate
Fixes: 0d70af3c25 ("fpga: bridge: Use standard dev_release for class driver")
Change-Id: I4726f74122c2755c1b14b66f40250306b1a796b2
Signed-off-by: Alexis Lothoré <alexis.lothore@bootlin.com>
Acked-by: Xu Yilun <yilun.xu@intel.com>
Link: https://lore.kernel.org/r/20230404133102.2837535-2-alexis.lothore@bootlin.com
Signed-off-by: Xu Yilun <yilun.xu@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
(cherry picked from commit 71b6df69f1)
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
commit 0da6e5fd6c upstream.
We started disabling '-Warray-bounds' for gcc-12 originally on s390,
because it resulted in some warnings that weren't realistically fixable
(commit 8b202ee218: "s390: disable -Warray-bounds").
That s390-specific issue was then found to be less common elsewhere, but
generic (see f0be87c42c: "gcc-12: disable '-Warray-bounds' universally
for now"), and then later expanded the version check was expanded to
gcc-11 (5a41237ad1: "gcc: disable -Warray-bounds for gcc-11 too").
And it turns out that I was much too optimistic in thinking that it's
all going to go away, and here we are with gcc-13 showing all the same
issues. So instead of expanding this one version at a time, let's just
disable it for gcc-11+, and put an end limit to it only when we actually
find a solution.
Yes, I'm sure some of this is because the kernel just does odd things
(like our "container_of()" use, but also knowingly playing games with
things like linker tables and array layouts).
And yes, some of the warnings are likely signs of real bugs, but when
there are hundreds of false positives, that doesn't really help.
Oh well.
Change-Id: Ie09553dec193c593f34169f835a876ea81b7cb6d
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
(cherry picked from commit a93c20f583)
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
commit 6431b0f6ff upstream.
After commit d38afeec26 ("tcp/udp: Call inet6_destroy_sock()
in IPv6 sk->sk_destruct()."), we call inet6_destroy_sock() in
sk->sk_destruct() by setting inet6_sock_destruct() to it to make
sure we do not leak inet6-specific resources.
SCTP sets its own sk->sk_destruct() in the sctp_init_sock(), and
SCTPv6 socket reuses it as the init function.
To call inet6_sock_destruct() from SCTPv6 sk->sk_destruct(), we
set sctp_v6_destruct_sock() in a new init function.
Change-Id: Ie3beb7e182e26def3fb7b50fef029fd5a8c94fc7
Signed-off-by: Kuniyuki Iwashima <kuniyu@amazon.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Ziyang Xuan <william.xuanziyang@huawei.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
(cherry picked from commit a09b9383b7)
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
commit 1651951ebe upstream.
After commit d38afeec26 ("tcp/udp: Call inet6_destroy_sock()
in IPv6 sk->sk_destruct()."), we call inet6_destroy_sock() in
sk->sk_destruct() by setting inet6_sock_destruct() to it to make
sure we do not leak inet6-specific resources.
DCCP sets its own sk->sk_destruct() in the dccp_init_sock(), and
DCCPv6 socket shares it by calling the same init function via
dccp_v6_init_sock().
To call inet6_sock_destruct() from DCCPv6 sk->sk_destruct(), we
export it and set dccp_v6_sk_destruct() in the init function.
Change-Id: I1aa8f30c780796bb5d446874bb44113783d6460a
Signed-off-by: Kuniyuki Iwashima <kuniyu@amazon.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Ziyang Xuan <william.xuanziyang@huawei.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
(cherry picked from commit a530b33fe9)
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
commit c1592a8994 upstream.
Toggle deleted anonymous sets as inactive in the next generation, so
users cannot perform any update on it. Clear the generation bitmask
in case the transaction is aborted.
The following KASAN splat shows a set element deletion for a bound
anonymous set that has been already removed in the same transaction.
[ 64.921510] ==================================================================
[ 64.923123] BUG: KASAN: wild-memory-access in nf_tables_commit+0xa24/0x1490 [nf_tables]
[ 64.924745] Write of size 8 at addr dead000000000122 by task test/890
[ 64.927903] CPU: 3 PID: 890 Comm: test Not tainted 6.3.0+ #253
[ 64.931120] Call Trace:
[ 64.932699] <TASK>
[ 64.934292] dump_stack_lvl+0x33/0x50
[ 64.935908] ? nf_tables_commit+0xa24/0x1490 [nf_tables]
[ 64.937551] kasan_report+0xda/0x120
[ 64.939186] ? nf_tables_commit+0xa24/0x1490 [nf_tables]
[ 64.940814] nf_tables_commit+0xa24/0x1490 [nf_tables]
[ 64.942452] ? __kasan_slab_alloc+0x2d/0x60
[ 64.944070] ? nf_tables_setelem_notify+0x190/0x190 [nf_tables]
[ 64.945710] ? kasan_set_track+0x21/0x30
[ 64.947323] nfnetlink_rcv_batch+0x709/0xd90 [nfnetlink]
[ 64.948898] ? nfnetlink_rcv_msg+0x480/0x480 [nfnetlink]
Bug: 282877000
Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Lee Jones <joneslee@google.com>
Change-Id: I536b7fbec55a5b37a57546023891a3dcfeb2c24b
