I suggest to append parentheses to the function name in the summary phrase.
> If traceprobe_parse_probe_arg_body() fails to allocate 'parg->fmt', it
> jumps to 'out' instead of 'fail' by mistake. In the result, in this
> case the 'tmp' buffer is not freed and leaks its memory.
>
> Fix it by jumpi
From: LuMingYin
If traceprobe_parse_probe_arg_body() fails to allocate 'parg->fmt', it
jumps to 'out' instead of 'fail' by mistake. In the result, in this
case the 'tmp' buffer is not freed and leaks its memory.
Fix it by jumping to 'fail' in that case.
Fixes: 032330abd08b ("tracing/probes: Cle
On Sat, 27 Apr 2024 at 04:03, Chris Lew wrote:
>
>
>
> On 4/24/2024 2:28 AM, Dmitry Baryshkov wrote:
> > diff --git a/drivers/remoteproc/qcom_q6v5_adsp.c
> > b/drivers/remoteproc/qcom_q6v5_adsp.c
> > index 1d24c9b656a8..02d0c626b03b 100644
> > --- a/drivers/remoteproc/qcom_q6v5_adsp.c
> > +++ b/d
On 4/24/2024 2:28 AM, Dmitry Baryshkov wrote:
diff --git a/drivers/remoteproc/qcom_q6v5_adsp.c
b/drivers/remoteproc/qcom_q6v5_adsp.c
index 1d24c9b656a8..02d0c626b03b 100644
--- a/drivers/remoteproc/qcom_q6v5_adsp.c
+++ b/drivers/remoteproc/qcom_q6v5_adsp.c
@@ -23,6 +23,7 @@
#include
#inc
On 4/24/2024 2:28 AM, Dmitry Baryshkov wrote:
+static int qcom_pdm_start(void)
+{
+ const struct of_device_id *match;
+ const struct qcom_pdm_domain_data * const *domains;
+ struct device_node *root;
+ int ret, i;
+
+ root = of_find_node_by_path("/");
+ if
On Fri, Apr 26, 2024 at 11:28:38AM +0300, Mike Rapoport wrote:
> From: "Mike Rapoport (IBM)"
>
> Hi,
>
> The patches are also available in git:
> https://git.kernel.org/pub/scm/linux/kernel/git/rppt/linux.git/log/?h=execmem/v6
>
> v6 changes:
> * restore patch "arm64: extend execmem_info for ge
On 26 Apr 9:19, David Hildenbrand wrote:
> A couple of points:
>
> a) Don't use page_mapcount(). Either folio_mapcount(), but likely you want
> to check PageAnonExclusive.
>
> b) If you're not following the can_follow_write_pte/_pmd model, you are
> doing something wrong :)
>
> c) The code was
From: Martyn Welch
The AM62x and AM64x SoCs of the TI K3 family has a Cortex M4F core in
the MCU domain. This core is typically used for safety applications in a
stand alone mode. However, some application (non safety related) may
want to use the M4F core as a generic remote processor with IPC to
Hello all,
This is the continuation of the M4F RProc support series from here[0].
I'm helping out with the upstream task for Hari and so this version(v8)
is a little different than the previous(v7) postings[0]. Most notable
change I've introduced being the patches factoring out common support
from
From: Hari Nagalla
The AM62x SoCs of the TI K3 family have a Cortex M4F core in the MCU
domain. This core can be used by non safety applications as a remote
processor. When used as a remote processor with virtio/rpmessage IPC,
two carveout reserved memory nodes are needed.
Disable by default as
From: Hari Nagalla
Some K3 platform devices (AM64x, AM62x) have a Cortex M4 core. Build
the M4 remote proc driver as a module for these platforms.
Signed-off-by: Hari Nagalla
Signed-off-by: Andrew Davis
---
arch/arm64/configs/defconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/
From: Hari Nagalla
K3 AM64x SoC has a Cortex M4F subsystem in the MCU voltage domain.
The remote processor's life cycle management and IPC mechanisms are
similar across the R5F and M4F cores from remote processor driver
point of view. However, there are subtle differences in image loading
and sta
From: Hari Nagalla
The AM62x SoCs of the TI K3 family have a Cortex M4F core in the MCU
domain. This core can be used by non safety applications as a remote
processor. When used as a remote processor with virtio/rpmessage IPC,
two carveout reserved memory nodes are needed. The first region is use
On Fri, Apr 26, 2024 at 1:30 AM Mike Rapoport wrote:
>
> From: "Mike Rapoport (IBM)"
>
> Extend execmem parameters to accommodate more complex overrides of
> module_alloc() by architectures.
>
> This includes specification of a fallback range required by arm, arm64
> and powerpc, EXECMEM_MODULE_D
On Fri, Apr 26, 2024 at 1:30 AM Mike Rapoport wrote:
>
> From: "Mike Rapoport (IBM)"
>
> Several architectures override module_alloc() only to define address
> range for code allocations different than VMALLOC address space.
>
> Provide a generic implementation in execmem that uses the parameters
On Fri, Apr 26, 2024 at 1:30 AM Mike Rapoport wrote:
>
> From: "Mike Rapoport (IBM)"
>
> module_alloc() is used everywhere as a mean to allocate memory for code.
>
> Beside being semantically wrong, this unnecessarily ties all subsystems
> that need to allocate code, such as ftrace, kprobes and B
On Fri, Apr 26, 2024 at 1:30 AM Mike Rapoport wrote:
>
> From: "Mike Rapoport (IBM)"
>
> Move the logic related to the memory allocation and freeing into
> module_memory_alloc() and module_memory_free().
>
> Signed-off-by: Mike Rapoport (IBM)
Acked-by: Song Liu
On Sun, Apr 21, 2024 at 12:43 PM Jiri Olsa wrote:
>
> Adding test that adds return uprobe inside 32 bit task
> and verify the return uprobe and attached bpf programs
> get properly executed.
>
> Signed-off-by: Jiri Olsa
> ---
> tools/testing/selftests/bpf/.gitignore| 1 +
> tools/testin
On Sun, Apr 21, 2024 at 12:43 PM Jiri Olsa wrote:
>
> Adding test to verify that when called from outside of the
> trampoline provided by kernel, the uretprobe syscall will cause
> calling process to receive SIGILL signal and the attached bpf
> program is no executed.
>
> Signed-off-by: Jiri Olsa
On Sun, Apr 21, 2024 at 12:42 PM Jiri Olsa wrote:
>
> Adding uretprobe syscall instead of trap to speed up return probe.
>
> At the moment the uretprobe setup/path is:
>
> - install entry uprobe
>
> - when the uprobe is hit, it overwrites probed function's return address
> on stack with ad
On Sun, Apr 21, 2024 at 12:42 PM Jiri Olsa wrote:
>
> Wiring up uretprobe system call, which comes in following changes.
> We need to do the wiring before, because the uretprobe implementation
> needs the syscall number.
>
> Note at the moment uretprobe syscall is supported only for native
> 64-bi
Good day,
On Wed, Apr 24, 2024 at 06:35:03PM +0530, Beleswar Padhi wrote:
> From: Apurva Nandan
>
> PSC controller has a limitation that it can only power-up the second core
> when the first core is in ON state. Power-state for core0 should be equal
> to or higher than core1, else the kernel is
On 4/26/24 07:18, Bojun Zhu wrote:
> for (c = 0 ; c < modp->length; c += PAGE_SIZE) {
> + if (sgx_check_signal_and_resched()) {
> + if (!c)
> + ret = -ERESTARTSYS;
> +
> + goto out;
> + }
This constru
On Thu, Apr 25, 2024 at 02:03:36PM -0500, Andrew Davis wrote:
> On 4/25/24 12:15 PM, Conor Dooley wrote:
> > On Wed, Apr 24, 2024 at 03:36:39PM -0500, Rob Herring wrote:
> > >
> > > On Wed, 24 Apr 2024 14:06:09 -0500, Andrew Davis wrote:
> > > > From: Hari Nagalla
> > > >
> > > > K3 AM64x SoC ha
…
>
> If traceprobe_parse_probe_arg_body() fails to allocate 'parg->fmt', it
> jumps to 'out' instead of 'fail' by mistake. In the result, in this
> case the 'tmp' buffer is not freed and leaks its memory.
>
> Fix it by jumping to 'fail' in that case.
>
…
How do you think about anoth
…
> Therefore, the program should jump to the fail label instead of the out
> label. This commit fixes this bug.
>
> Signed-off-by: LuMingYin <11570291+yin-lum...@user.noreply.gitee.com>
Please improve your patch attempt considerably.
See also:
https://kernelnewbies.org/FirstKernelPatch
Are th
Hi LuMingYin,
Thanks for finding the problem! But please make a commit message
following Documentation/process/submitting-patches.rst
On Fri, 26 Apr 2024 10:13:43 +0100
lumingyindet...@126.com wrote:
> From: LuMingYin <11570291+yin-lum...@user.noreply.gitee.com>
>
> At line 1408 of the file /l
From: Hou Tao
Hi,
The patch set aims to fix the warning related to an abnormal size
parameter of kmalloc() in virtiofs. Patch #1 fixes it by introducing
use_pages_for_kvec_io option in fuse_conn and enabling it in virtiofs.
Beside the abnormal size parameter for kmalloc, the gfp parameter is
als
From: Hou Tao
When trying to insert a 10MB kernel module kept in a virtio-fs with cache
disabled, the following warning was reported:
[ cut here ]
WARNING: CPU: 1 PID: 404 at mm/page_alloc.c:4551 ..
Modules linked in:
CPU: 1 PID: 404 Comm: insmod Not tainted 6
From: Hou Tao
When invoking virtio_fs_enqueue_req() through kworker, both the
allocation of the sg array and the bounce buffer still use GFP_ATOMIC.
Considering the size of the sg array may be greater than PAGE_SIZE, use
GFP_NOFS instead of GFP_ATOMIC to lower the possibility of memory
allocation
On 4/16/24 07:15, Jarkko Sakkinen wrote:
> On Tue Apr 16, 2024 at 8:42 AM EEST, Huang, Kai wrote:
> Yes, exactly. I'd take one week break and cycle the kselftest part
> internally a bit as I said my previous response. I'm sure that there
> is experise inside Intel how to implement it properly. I.e.
EDMM's ioctl()s support batch operations, which may be
time-consuming. Try to explicitly give up the CPU as the prefix
operation at the every begin of "for loop" in
sgx_enclave_{ modify_types | restrict_permissions | remove_pages}
to give other tasks a chance to run, and avoid softlockup warning.
Hi forks,
This is the second version of the patch to fix the softlockup in EDMM
iotcl()[1].
If we run an enclave equipped with large EPC(30G or greater on my platfrom)
on the Linux with kernel preemptions disabled(by configuring
"CONFIG_PREEMPT_NONE=y"), we will get the following softlockup warn
On 24.04.2024 12:27, Dmitry Baryshkov wrote:
Protection domain mapper is a QMI service providing mapping between
'protection domains' and services supported / allowed in these domains.
For example such mapping is required for loading of the WiFi firmware or
for properly starting up the UCSI /
On 24.04.2024 12:28, Dmitry Baryshkov wrote:
Existing userspace protection domain mapper implementation has several
issue. It doesn't play well with CONFIG_EXTRA_FIRMWARE, it doesn't
reread JSON files if firmware location is changed (or if firmware was
not available at the time pd-mapper was star
From: LuMingYin <11570291+yin-lum...@user.noreply.gitee.com>
At line 1408 of the file /linux/kernel/trace/trace_probe.c, pointer variables
named code and tmp are defined. At line 1437, a new dynamic memory area is
allocated using the function kcalloc. When the if statement at line 1467
evaluate
On Fri, Apr 26, 2024 at 10:47 AM wrote:
>
> From: Peilin He
>
> Introduce a tracepoint for icmp_send, which can help users to get more
> detail information conveniently when icmp abnormal events happen.
>
> 1. Giving an usecase example:
> =
> When an application experi
From: Peilin He
Introduce a tracepoint for icmp_send, which can help users to get more
detail information conveniently when icmp abnormal events happen.
1. Giving an usecase example:
=
When an application experiences packet loss due to an unreachable UDP
destination p
From: "Mike Rapoport (IBM)"
BPF just-in-time compiler depended on CONFIG_MODULES because it used
module_alloc() to allocate memory for the generated code.
Since code allocations are now implemented with execmem, drop dependency of
CONFIG_BPF_JIT on CONFIG_MODULES and make it select CONFIG_EXECME
From: "Mike Rapoport (IBM)"
kprobes depended on CONFIG_MODULES because it has to allocate memory for
code.
Since code allocations are now implemented with execmem, kprobes can be
enabled in non-modular kernels.
Add #ifdef CONFIG_MODULE guards for the code dealing with kprobes inside
modules, ma
From: "Mike Rapoport (IBM)"
There are places where CONFIG_MODULES guards the code that depends on
memory allocation being done with module_alloc().
Replace CONFIG_MODULES with CONFIG_EXECMEM in such places.
Signed-off-by: Mike Rapoport (IBM)
---
arch/powerpc/Kconfig | 2 +-
ar
From: "Mike Rapoport (IBM)"
Dynamic ftrace must allocate memory for code and this was impossible
without CONFIG_MODULES.
With execmem separated from the modules code, execmem_text_alloc() is
available regardless of CONFIG_MODULES.
Remove dependency of dynamic ftrace on CONFIG_MODULES and make
C
From: "Mike Rapoport (IBM)"
execmem does not depend on modules, on the contrary modules use
execmem.
To make execmem available when CONFIG_MODULES=n, for instance for
kprobes, split execmem_params initialization out from
arch/*/kernel/module.c and compile it when CONFIG_EXECMEM=y
Signed-off-by:
From: "Mike Rapoport (IBM)"
powerpc overrides kprobes::alloc_insn_page() to remove writable
permissions when STRICT_MODULE_RWX is on.
Add definition of EXECMEM_KRPOBES to execmem_params to allow using the
generic kprobes::alloc_insn_page() with the desired permissions.
As powerpc uses breakpoin
From: "Mike Rapoport (IBM)"
The memory allocations for kprobes and BPF on arm64 can be placed
anywhere in vmalloc address space and currently this is implemented with
overrides of alloc_insn_page() and bpf_jit_alloc_exec() in arm64.
Define EXECMEM_KPROBES and EXECMEM_BPF ranges in arm64::execmem
From: "Mike Rapoport (IBM)"
The memory allocations for kprobes and BPF on RISC-V are not placed in
the modules area and these custom allocations are implemented with
overrides of alloc_insn_page() and bpf_jit_alloc_exec().
Slightly reorder execmem_params initialization to support both 32 and 64
From: "Mike Rapoport (IBM)"
Extend execmem parameters to accommodate more complex overrides of
module_alloc() by architectures.
This includes specification of a fallback range required by arm, arm64
and powerpc, EXECMEM_MODULE_DATA type required by powerpc, support for
allocation of KASAN shadow
From: "Mike Rapoport (IBM)"
Several architectures override module_alloc() only to define address
range for code allocations different than VMALLOC address space.
Provide a generic implementation in execmem that uses the parameters for
address space ranges, required alignment and page protections
From: "Mike Rapoport (IBM)"
module_alloc() is used everywhere as a mean to allocate memory for code.
Beside being semantically wrong, this unnecessarily ties all subsystems
that need to allocate code, such as ftrace, kprobes and BPF to modules and
puts the burden of code allocation to the module
From: "Mike Rapoport (IBM)"
Move the logic related to the memory allocation and freeing into
module_memory_alloc() and module_memory_free().
Signed-off-by: Mike Rapoport (IBM)
---
kernel/module/main.c | 64 +++-
1 file changed, 39 insertions(+), 25 delet
From: "Mike Rapoport (IBM)"
Define MODULES_VADDR and MODULES_END as VMALLOC_START and VMALLOC_END
for 32-bit and reduce module_alloc() to
__vmalloc_node_range(size, 1, MODULES_VADDR, MODULES_END, ...)
as with the new defines the allocations becomes identical for both 32
and 64 bits.
Wh
From: "Mike Rapoport (IBM)"
nios2 uses kmalloc() to implement module_alloc() because CALL26/PCREL26
cannot reach all of vmalloc address space.
Define module space as 32MiB below the kernel base and switch nios2 to
use vmalloc for module allocations.
Suggested-by: Thomas Gleixner
Acked-by: Dinh
From: "Mike Rapoport (IBM)"
and MODULE_END to MODULES_END to match other architectures that define
custom address space for modules.
Signed-off-by: Mike Rapoport (IBM)
---
arch/mips/include/asm/pgtable-64.h | 4 ++--
arch/mips/kernel/module.c | 4 ++--
arch/mips/mm/fault.c
From: "Mike Rapoport (IBM)"
Since commit f6f37d9320a1 ("arm64: select KASAN_VMALLOC for SW/HW_TAGS
modes") KASAN_VMALLOC is always enabled when KASAN is on. This means
that allocations in module_alloc() will be tracked by KASAN protection
for vmalloc() and that kasan_alloc_module_shadow() will be
From: "Mike Rapoport (IBM)"
Hi,
The patches are also available in git:
https://git.kernel.org/pub/scm/linux/kernel/git/rppt/linux.git/log/?h=execmem/v6
v6 changes:
* restore patch "arm64: extend execmem_info for generated code
allocations" that disappeared in v5 rebase
* update execmem initia
"tracing_event_file" is at the risk of use-after-free due to the race of
two functions "tracing_open_file_tr" and "synth_event_release".
Specifically, it could be freed by synth_event_release before
tracing_open_file_tr has the opportunity to access its members.
It's easy to reproduced by first ex
On 26.04.24 02:09, Guillaume Morin wrote:
On 25 Apr 21:56, David Hildenbrand wrote:
On 25.04.24 17:19, Guillaume Morin wrote:
On 24 Apr 23:00, David Hildenbrand wrote:
One issue here is that FOLL_FORCE|FOLL_WRITE is not implemented for
hugetlb mappings. However this was also on my TODO and I
57 matches
Mail list logo
