On 5/16/25 5:27 AM, Lijuan Gao wrote:
> Add a simple-mfd representing IMEM on QCS615 and define the PIL
> relocation info region as its child. The PIL region in IMEM is used to
> communicate load addresses of remoteproc to post mortem debug tools, so
> that these tools can coll
Add a simple-mfd representing IMEM on QCS615 and define the PIL
relocation info region as its child. The PIL region in IMEM is used to
communicate load addresses of remoteproc to post mortem debug tools, so
that these tools can collect ramdumps.
Signed-off-by: Lijuan Gao
---
arch/arm64/boot/dts
The ti_k3_m4_remoteproc.c driver previously hardcoded device memory
region addresses and names. Change this to use the k3_rproc_mem_data
structure to store memory information. This aligns with DSP and R5
drivers, and can be refactored out later.
Signed-off-by: Beleswar Padhi
Tested-by: Judith Men
The ti_k3_r5_remoteproc.c driver previously hardcoded device memory
region addresses and names. Change this to use the k3_r5_rproc_mem_data
structure to store memory information. This aligns with K3 DSP and M4
drivers, and can be refactored out later.
Signed-off-by: Beleswar Padhi
Reviewed-by: An
the PIL
relocation info region as its child. The PIL region in IMEM is used to
communicate load addresses of remoteproc to post mortem debug tools, so
that these tools can collect ramdumps.
Signed-off-by: Lijuan Gao
---
arch/arm64/boot/dts/qcom/qcs615.dtsi | 14 ++
1 file
;> Add a simple-mfd representing IMEM on QCS615 and define the PIL
>>>>> relocation info region as its child. The PIL region in IMEM is used to
>>>>> communicate load addresses of remoteproc to post mortem debug tools, so
>>>>> that these tools can col
在 5/9/2025 4:54 PM, Konrad Dybcio 写道:
On 5/9/25 9:37 AM, Lijuan Gao wrote:
在 5/8/2025 10:41 PM, Konrad Dybcio 写道:
On 5/7/25 12:26 PM, Lijuan Gao wrote:
Add a simple-mfd representing IMEM on QCS615 and define the PIL
relocation info region as its child. The PIL region in IMEM is used to
On 5/9/25 9:37 AM, Lijuan Gao wrote:
>
>
> 在 5/8/2025 10:41 PM, Konrad Dybcio 写道:
>> On 5/7/25 12:26 PM, Lijuan Gao wrote:
>>> Add a simple-mfd representing IMEM on QCS615 and define the PIL
>>> relocation info region as its child. The PIL region in IMEM is used
在 5/8/2025 10:41 PM, Konrad Dybcio 写道:
On 5/7/25 12:26 PM, Lijuan Gao wrote:
Add a simple-mfd representing IMEM on QCS615 and define the PIL
relocation info region as its child. The PIL region in IMEM is used to
communicate load addresses of remoteproc to post mortem debug tools, so
that
On 5/7/25 12:26 PM, Lijuan Gao wrote:
> Add a simple-mfd representing IMEM on QCS615 and define the PIL
> relocation info region as its child. The PIL region in IMEM is used to
> communicate load addresses of remoteproc to post mortem debug tools, so
> that these tools can coll
On Fri, Apr 25, 2025 at 04:11:07PM +0530, Beleswar Padhi wrote:
> The ti_k3_r5_remoteproc.c driver previously hardcoded device memory
> region addresses and names. Change this to use the k3_r5_rproc_mem_data
> structure to store memory information. This aligns with K3 DSP and M4
> drivers, and can
On Fri, Apr 25, 2025 at 04:11:10PM +0530, Beleswar Padhi wrote:
> The ti_k3_m4_remoteproc.c driver previously hardcoded device memory
> region addresses and names. Change this to use the k3_rproc_mem_data
> structure to store memory information. This aligns with DSP and R5
> drivers, and can be ref
On Fri, Apr 25, 2025 at 04:11:10PM +0530, Beleswar Padhi wrote:
> The ti_k3_m4_remoteproc.c driver previously hardcoded device memory
> region addresses and names. Change this to use the k3_rproc_mem_data
> structure to store memory information. This aligns with DSP and R5
> drivers, and can be ref
Add a simple-mfd representing IMEM on QCS615 and define the PIL
relocation info region as its child. The PIL region in IMEM is used to
communicate load addresses of remoteproc to post mortem debug tools, so
that these tools can collect ramdumps.
Signed-off-by: Lijuan Gao
---
arch/arm64/boot/dts
grep "${2}" | sed -n 's/.*\('"${1}"':\)\([0-9a-f:.]*\).*$/\2/p;q'
+ grep "${2}" 2>/dev/null |
+ sed -n 's/.*\('"${1}"':\)\([0-9a-f:.]*\).*$/\2/p;q'
+ # the ';q' at t
The ti_k3_m4_remoteproc.c driver previously hardcoded device memory
region addresses and names. Change this to use the k3_rproc_mem_data
structure to store memory information. This aligns with DSP and R5
drivers, and can be refactored out later.
Signed-off-by: Beleswar Padhi
Tested-by: Judith Men
The ti_k3_r5_remoteproc.c driver previously hardcoded device memory
region addresses and names. Change this to use the k3_r5_rproc_mem_data
structure to store memory information. This aligns with K3 DSP and M4
drivers, and can be refactored out later.
Signed-off-by: Beleswar Padhi
Reviewed-by: An
On 4/23/25 11:17 AM, Lijuan Gao wrote:
> Add a simple-mfd representing IMEM on QCS615 and define the PIL
> relocation info region, so that post mortem tools will be able
> to locate the loaded remoteprocs.
>
> Signed-off-by: Lijuan Gao
> ---
> arch/arm64/boot/dts/
Add a simple-mfd representing IMEM on QCS615 and define the PIL
relocation info region, so that post mortem tools will be able
to locate the loaded remoteprocs.
Signed-off-by: Lijuan Gao
---
arch/arm64/boot/dts/qcom/qcs615.dtsi | 14 ++
1 file changed, 14 insertions(+)
diff --git a
The ti_k3_m4_remoteproc.c driver previously hardcoded device memory
region addresses and names. Change this to use the k3_rproc_mem_data
structure to store memory information. This aligns with DSP and R5
drivers, and can be refactored out later.
Signed-off-by: Beleswar Padhi
---
v10: Changelog:
N
The ti_k3_r5_remoteproc.c driver previously hardcoded device memory
region addresses and names. Change this to use the k3_r5_rproc_mem_data
structure to store memory information. This aligns with K3 DSP and M4
drivers, and can be refactored out later.
Signed-off-by: Beleswar Padhi
Reviewed-by: An
Hi Andrew,
On 07/04/25 19:13, Andrew Davis wrote:
On 3/17/25 7:06 AM, Beleswar Padhi wrote:
The ti_k3_m4_remoteproc.c driver previously hardcoded device memory
region addresses and names. Change this to use the k3_rproc_mem_data
structure to store memory information. This aligns with DSP and R5
On 3/17/25 7:06 AM, Beleswar Padhi wrote:
The ti_k3_m4_remoteproc.c driver previously hardcoded device memory
region addresses and names. Change this to use the k3_rproc_mem_data
structure to store memory information. This aligns with DSP and R5
drivers, and can be refactored out later.
Signed-o
On 3/17/25 7:05 AM, Beleswar Padhi wrote:
The ti_k3_r5_remoteproc.c driver previously hardcoded device memory
region addresses and names. Change this to use the k3_r5_rproc_mem_data
structure to store memory information. This aligns with K3 DSP and M4
drivers, and can be refactored out later.
Si
On Mon, Aug 19, 2024 at 10:19:44AM -0500, Mike Christie wrote:
On 8/16/24 1:17 PM, Michael S. Tsirkin wrote:
On Fri, Aug 16, 2024 at 11:10:32AM -0700, Sean Christopherson wrote:
On Fri, Aug 16, 2024, syzbot wrote:
On Wed, May 29, 2024, syzbot wrote:
Hello,
syzbot found the following issue on
The ti_k3_m4_remoteproc.c driver previously hardcoded device memory
region addresses and names. Change this to use the k3_rproc_mem_data
structure to store memory information. This aligns with DSP and R5
drivers, and can be refactored out later.
Signed-off-by: Beleswar Padhi
---
drivers/remotepr
The ti_k3_r5_remoteproc.c driver previously hardcoded device memory
region addresses and names. Change this to use the k3_r5_rproc_mem_data
structure to store memory information. This aligns with K3 DSP and M4
drivers, and can be refactored out later.
Signed-off-by: Beleswar Padhi
---
drivers/re
On Tue, Feb 04, 2025 at 04:22:27PM -0800, Indu Bhagat wrote:
> > +++ b/arch/Kconfig
> > @@ -1736,4 +1736,12 @@ config ARCH_WANTS_PRE_LINK_VMLINUX
> > An architecture can select this if it provides
> > arch//tools/Makefile
> > with .arch.vmlinux.o target to be linked into vmlinux.
> > +
On 1/27/25 1:33 PM, Weinan Liu wrote:
Use the -Wa,--gsframe flags to build the code, so GAS will generate
a new .sframe section for the stack trace information.
Currently, the sframe format only supports arm64 and x86_64
architectures. Add this configuration on arm64 to enable sframe
unwinder in
On 28-01-2025 03:03, Weinan Liu wrote:
Use the -Wa,--gsframe flags to build the code, so GAS will generate
a new .sframe section for the stack trace information.
Currently, the sframe format only supports arm64 and x86_64
architectures. Add this configuration on arm64 to enable sframe
unwinder
.
Annotate CFI unwind info for assembly for interrupt and exception
handlers.
Signed-off-by: Weinan Liu
---
arch/arm64/kernel/entry.S | 10 ++
1 file changed, 10 insertions(+)
diff --git a/arch/arm64/kernel/entry.S b/arch/arm64/kernel/entry.S
index 5ae2a34b50bd..fe3e3e29ee5d 100644
--- a
Use the -Wa,--gsframe flags to build the code, so GAS will generate
a new .sframe section for the stack trace information.
Currently, the sframe format only supports arm64 and x86_64
architectures. Add this configuration on arm64 to enable sframe
unwinder in the future.
Signed-off-by: Weinan Liu
i
diff --git a/tools/testing/selftests/net/mptcp/mptcp_lib.sh
b/tools/testing/selftests/net/mptcp/mptcp_lib.sh
index
975d4d4c862afff2e685e86dc08a892dbd09d783..91a1d3b76e664bd95fc36310ac2e2c89bfba1aa1
100644
--- a/tools/testing/selftests/net/mptcp/mptcp_lib.sh
+++ b/tools/testing/selftes
The ti_k3_m4_remoteproc.c driver previously hardcoded device memory
region addresses and names. Change this to use the k3_rproc_mem_data
structure to store memory information. This aligns with
ti_k3_dsp_remoteproc.c driver, and can be refactored out later.
Signed-off-by: Beleswar Padhi
---
drive
g to the commit:
Reported-by: syzbot+f303608297c771a7d...@syzkaller.appspotmail.com
INFO: trying to register non-static key.
The code is fine but needs lockdep annotation, or maybe
you didn't initialize this object before use?
turning off the locking correctness validator.
CPU: 0 UID: 0 PID: 1
Adding Lucas DeMarchi to the thread after voicing an interest in the
modpost patch.
On Thu, Oct 31, 2024 at 12:49 AM Luis Chamberlain wrote:
>
> On Wed, Oct 30, 2024 at 10:06:12PM -0700, Matthew Maurer wrote:
> > On Wed, Oct 30, 2024 at 9:37 PM Luis Chamberlain wrote:
> > >
> > > On Thu, Oct 31,
On Wed, Oct 30, 2024 at 10:06:12PM -0700, Matthew Maurer wrote:
> On Wed, Oct 30, 2024 at 9:37 PM Luis Chamberlain wrote:
> >
> > On Thu, Oct 31, 2024 at 12:22:36PM +1100, Michael Ellerman wrote:
> > > Matthew Maurer writes:
> > > > Adds a new format for MODVERSIONS which stores each field in a s
On Wed, Oct 30, 2024 at 9:37 PM Luis Chamberlain wrote:
>
> On Thu, Oct 31, 2024 at 12:22:36PM +1100, Michael Ellerman wrote:
> > Matthew Maurer writes:
> > > Adds a new format for MODVERSIONS which stores each field in a separate
> > > ELF section. This initially adds support for variable length
On Thu, Oct 31, 2024 at 12:22:36PM +1100, Michael Ellerman wrote:
> Matthew Maurer writes:
> > Adds a new format for MODVERSIONS which stores each field in a separate
> > ELF section. This initially adds support for variable length names, but
> > could later be used to add additional fields to MOD
Matthew Maurer writes:
> Adds a new format for MODVERSIONS which stores each field in a separate
> ELF section. This initially adds support for variable length names, but
> could later be used to add additional fields to MODVERSIONS in a
> backwards compatible way if needed. Any new fields will be
dule/internal.h
@@ -86,6 +86,8 @@ struct load_info {
unsigned int vers;
unsigned int info;
unsigned int pcpu;
+ unsigned int vers_ext_crc;
+ unsigned int vers_ext_name;
} index;
};
@@ -389,6 +391,15 @@
Matthew Maurer writes:
>> Sorry I realise it's version 7, but although the above looks correct it's
>> kind of dense.
>>
>> I think the below would also work and is (I think) easier to follow, and
>> is more obviously similar to the existing code. I'm sure your version is
>> faster, but I don't th
> Sorry I realise it's version 7, but although the above looks correct it's
> kind of dense.
>
> I think the below would also work and is (I think) easier to follow, and
> is more obviously similar to the existing code. I'm sure your version is
> faster, but I don't think it's that performance crit
Matthew Maurer writes:
> Adds a new format for MODVERSIONS which stores each field in a separate
> ELF section. This initially adds support for variable length names, but
> could later be used to add additional fields to MODVERSIONS in a
> backwards compatible way if needed. Any new fields will be
On Wed, Oct 23, 2024 at 02:31:28AM +, Matthew Maurer wrote:
> Adds a new format for MODVERSIONS which stores each field in a separate
> ELF section. This initially adds support for variable length names, but
> could later be used to add additional fields to MODVERSIONS in a
> backwards compatib
/fill_link_info.c
@@ -417,6 +417,15 @@ verify_umulti_link_info(int fd, bool retprobe, __u64
*offsets,
if (!ASSERT_NEQ(err, -1, "readlink"))
return -1;
+ memset(&info, 0, sizeof(info));
+ err = bpf_link_get_info_by_fd(fd, &info, &len);
+
internal.h
@@ -86,6 +86,8 @@ struct load_info {
unsigned int vers;
unsigned int info;
unsigned int pcpu;
+ unsigned int vers_ext_crc;
+ unsigned int vers_ext_name;
} index;
};
@@ -389,6 +391,15 @@ void module_layout(struct module *mod, s
On Sat, Oct 19, 2024 at 01:45:35PM -0700, Luis Chamberlain wrote:
> On Thu, Oct 17, 2024 at 02:08:19PM +0200, Helge Deller wrote:
> > Hi Luis,
> >
> > On 10/17/24 01:21, Luis Chamberlain wrote:
> > > That sounds great. Yeah, the above would be great to test. A while ago
> > > I wrote a new modules
On Tue, Oct 15, 2024 at 11:18:57PM +, Matthew Maurer wrote:
> Adds a new format for MODVERSIONS which stores each field in a separate
> ELF section. This initially adds support for variable length names, but
> could later be used to add additional fields to MODVERSIONS in a
> backwards compatib
On Thu, Oct 17, 2024 at 02:08:19PM +0200, Helge Deller wrote:
> Hi Luis,
>
> On 10/17/24 01:21, Luis Chamberlain wrote:
> > That sounds great. Yeah, the above would be great to test. A while ago
> > I wrote a new modules selftests in order to test possible improvements
> > on find_symbol() but I a
Hi Luis,
On 10/17/24 01:21, Luis Chamberlain wrote:
That sounds great. Yeah, the above would be great to test. A while ago
I wrote a new modules selftests in order to test possible improvements
on find_symbol() but I also did this due to push the limits of the
numbers of symbols we could support
On 10/17/24 12:44, Andrew Morton wrote:
> On Thu, 17 Oct 2024 12:31:31 +0530 Anshuman Khandual
> wrote:
>
>> On 10/15/24 07:32, Nanyong Sun wrote:
>>> The mount option of tmpfs should be huge=advise, not madvise
>>> which is not supported and may mislead the users.
>> Agreed.
>>
>>> Fixes: 1b
On Thu, 17 Oct 2024 12:31:31 +0530 Anshuman Khandual
wrote:
> On 10/15/24 07:32, Nanyong Sun wrote:
> > The mount option of tmpfs should be huge=advise, not madvise
> > which is not supported and may mislead the users.
>
> Agreed.
>
> >
> > Fixes: 1b03d0d558a2 ("selftests/vm: add thp collapse
On 10/15/24 07:32, Nanyong Sun wrote:
> The mount option of tmpfs should be huge=advise, not madvise
> which is not supported and may mislead the users.
Agreed.
>
> Fixes: 1b03d0d558a2 ("selftests/vm: add thp collapse file and tmpfs testing")
But nothing is really broken here. This just fixes u
Le 17/10/2024 à 01:21, Luis Chamberlain a écrit :
On Tue, Oct 15, 2024 at 04:22:22PM -0700, Matthew Maurer wrote:
So, the basic things I can think of to test here are:
1. The kernel can still load the previous MODVERSIONS format
2. The kernel can load the new MODVERSIONS format
3. If we arti
On Tue, Oct 15, 2024 at 04:22:22PM -0700, Matthew Maurer wrote:
> So, the basic things I can think of to test here are:
>
> 1. The kernel can still load the previous MODVERSIONS format
> 2. The kernel can load the new MODVERSIONS format
> 3. If we artificially tweak a CRC in the previous format, i
On 10/15/24 5:25 PM, Florian Westphal wrote:
Tyrone Wu wrote:
This patch correctly populates the `bpf_link_info.netfilter.flags` field
when user passes the `BPF_F_NETFILTER_IP_DEFRAG` flag.
Indeed, thanks for fixing this.
Patch and testcase look good, but one nit:
Fixes: 84601d6ee68a ("bpf:
a ("bpf: add bpf_link support for BPF_NETFILTER programs")
> Signed-off-by: Tyrone Wu
> ---
> net/netfilter/nf_bpf_link.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
Here is the summary with links:
- [bpf,v1,1/2] bpf: fix link info netfilter flags to populate defr
So, the basic things I can think of to test here are:
1. The kernel can still load the previous MODVERSIONS format
2. The kernel can load the new MODVERSIONS format
3. If we artificially tweak a CRC in the previous format, it will fail to load.
4. If we artificially tweak a CRC in the new format,
The new version info format has a superset of symbols in the old format.
Since this is a tool for in-tree modules, we don't need to parse the old
one with this tool any longer.
Even if we build without CONFIG_EXTENDED_MODVERSIONS, these are still in
the `.mod.c` file. Their presence in the
f2be83902..59959c21b205 100644
--- a/kernel/module/internal.h
+++ b/kernel/module/internal.h
@@ -86,6 +86,8 @@ struct load_info {
unsigned int vers;
unsigned int info;
unsigned int pcpu;
+ unsigned int vers_ext_crc;
+
Tyrone Wu wrote:
> This patch correctly populates the `bpf_link_info.netfilter.flags` field
> when user passes the `BPF_F_NETFILTER_IP_DEFRAG` flag.
Indeed, thanks for fixing this.
Patch and testcase look good, but one nit:
> Fixes: 84601d6ee68a ("bpf: add bpf_link support for BPF_NETFILTER prog
On 2024/10/15 10:02, Nanyong Sun wrote:
The mount option of tmpfs should be huge=advise, not madvise
which is not supported and may mislead the users.
Fixes: 1b03d0d558a2 ("selftests/vm: add thp collapse file and tmpfs testing")
Signed-off-by: Nanyong Sun
LGTM.
Reviewed-by: Baolin Wang
The mount option of tmpfs should be huge=advise, not madvise
which is not supported and may mislead the users.
Fixes: 1b03d0d558a2 ("selftests/vm: add thp collapse file and tmpfs testing")
Signed-off-by: Nanyong Sun
---
tools/testing/selftests/mm/khugepaged.c | 2 +-
1 file changed, 1 insertion(
On Fri, Oct 11, 2024 at 04:45:25PM -0700, Luis Chamberlain wrote:
>
> Also, just as I asked Sami, coould you split this up into patch sets?
> One with all the cleanups and elf validation code shifts. And then the
> other code. That will let me pick up quickly the first patch set.
Oh and if you ca
Also, just as I asked Sami, coould you split this up into patch sets?
One with all the cleanups and elf validation code shifts. And then the
other code. That will let me pick up quickly the first patch set.
Luis
On Fri, Oct 11, 2024 at 03:27:30PM -0700, Matthew Maurer wrote:
> On Fri, Oct 11, 2024 at 3:22 PM Luis Chamberlain wrote:
> >
> > On Wed, Sep 25, 2024 at 11:38:29PM +, Matthew Maurer wrote:
> > > Adds a new format for MODVERSIONS which stores each field in a separate
> > > ELF section. This in
On Fri, Oct 11, 2024 at 3:22 PM Luis Chamberlain wrote:
>
> On Wed, Sep 25, 2024 at 11:38:29PM +, Matthew Maurer wrote:
> > Adds a new format for MODVERSIONS which stores each field in a separate
> > ELF section. This initially adds support for variable length names, but
> > could later be use
On Wed, Sep 25, 2024 at 11:38:29PM +, Matthew Maurer wrote:
> Adds a new format for MODVERSIONS which stores each field in a separate
> ELF section. This initially adds support for variable length names, but
> could later be used to add additional fields to MODVERSIONS in a
> backwards compatib
t;attach ipv6",
+ },
};
+static void verify_netfilter_link_info(struct bpf_link *link, const struct
nf_link_test nf_expected)
+{
+ struct bpf_link_info info;
+ __u32 len = sizeof(info);
+ int err, fd;
+
+ memset(&info, 0, len);
+
+ fd = bpf_link__fd(link);
link *link,
struct bpf_link_info *info)
{
struct bpf_nf_link *nf_link = container_of(link, struct bpf_nf_link,
link);
+ const struct nf_defrag_hook *hook = nf_link->defrag_hook;
info->netfilter.pf = nf_link->hook_ops.pf;
info
links:
- [bpf,v7,1/2] bpf: fix unpopulated name_len field in perf_event link info
https://git.kernel.org/bpf/bpf/c/4deecdd29cf2
- [bpf,v7,2/2] selftests/bpf: fix perf_event link info name_len assertion
https://git.kernel.org/bpf/bpf/c/4538a38f654a
You are awesome, thank you!
--
Deet-
Fix `name_len` field assertions in `bpf_link_info.perf_event` for
kprobe/uprobe/tracepoint to validate correct name size instead of 0.
Fixes: 23cf7aa539dc ("selftests/bpf: Add selftest for fill_link_info")
Signed-off-by: Tyrone Wu
Acked-by: Jiri Olsa
Acked-by: Yafang Shao
---
V6 -> V7: no chang
r = bpf_copy_to_user(uname, buf, ulen, len);
if (err)
return err;
@@ -3609,7 +3617,7 @@ static int bpf_perf_link_fill_kprobe(const struct
perf_event *event,
uname = u64_to_user_ptr(info->perf_event.kprobe.func_name);
ulen = info->perf_event.kprobe.name_le
rn 0;
> +
> if (buf) {
> - len = strlen(buf);
> - err = bpf_copy_to_user(uname, buf, ulen, len);
> + err = bpf_copy_to_user(uname, buf, input_len, len);
> if (err)
>
From: tyrone-wu
Fix `name_len` field assertions in `bpf_link_info.perf_event` for
kprobe/uprobe/tracepoint to validate correct name size instead of 0.
Link:
https://lore.kernel.org/bpf/cabvu1kxwqxhqqge0rtrr7eegtm6svw_kayzby16-yb0snzt...@mail.gmail.com/
Fixes: 23cf7aa539dc ("selftests/bpf: Add s
ser(uname, buf, ulen, len);
+ err = bpf_copy_to_user(uname, buf, input_len, len);
if (err)
return err;
} else {
@@ -3609,7 +3615,7 @@ static int bpf_perf_link_fill_kprobe(const struct
perf_event *event,
uname = u64_to_user_ptr(info->
On Sun, Oct 06, 2024 at 07:51:30PM +, tyrone-wu wrote:
> Previously when retrieving `bpf_link_info.perf_event` for
> kprobe/uprobe/tracepoint, the `name_len` field was not populated by the
> kernel, leaving it to reflect the value initially set by the user. This
> behavior was inconsistent with
On Mon, Oct 7, 2024 at 3:51 AM tyrone-wu wrote:
>
> Fix `name_len` field assertions in `bpf_link_info.perf_event` for
> kprobe/uprobe/tracepoint to validate correct name size instead of 0.
>
> Link:
> https://lore.kernel.org/bpf/cabvu1kxwqxhqqge0rtrr7eegtm6svw_kayzby16-yb0snzt...@mail.gmail.com/
if (uname) {
> + err = bpf_copy_to_user(uname, buf, input_len, len);
> + if (err)
> + return err;
> + }
> + } else if (uname) {
> + char zero = '\0';
>
Fix `name_len` field assertions in `bpf_link_info.perf_event` for
kprobe/uprobe/tracepoint to validate correct name size instead of 0.
Link:
https://lore.kernel.org/bpf/cabvu1kxwqxhqqge0rtrr7eegtm6svw_kayzby16-yb0snzt...@mail.gmail.com/
Fixes: 23cf7aa539dc ("selftests/bpf: Add selftest for fill_l
return err;
+ }
+ } else if (uname) {
+ char zero = '\0';
if (put_user(zero, uname))
return -EFAULT;
}
@@ -3609,7 +3612,7 @@ static int bpf_perf_link_fill_kprobe(const struct
perf_event *event,
uname = u64_to_
e NULL, so we should check it.
> + *ulen = len + 1;
> if (!uname)
> return 0;
> +
> if (buf) {
> - len = strlen(buf);
> - err = bpf_copy_to_user(uname, buf, ulen, len);
> + err = bpf_copy_
Fix `name_len` field assertions in `bpf_link_info.perf_event` for
kprobe/uprobe/tracepoint to validate correct name size instead of 0.
Link:
https://lore.kernel.org/bpf/cabvu1kxwqxhqqge0rtrr7eegtm6svw_kayzby16-yb0snzt...@mail.gmail.com/
Fixes: 23cf7aa539dc ("selftests/bpf: Add selftest for fill_l
nt bpf_perf_link_fill_kprobe(const struct
perf_event *event,
uname = u64_to_user_ptr(info->perf_event.kprobe.func_name);
ulen = info->perf_event.kprobe.name_len;
- err = bpf_perf_link_fill_common(event, uname, ulen, &offset, &addr,
+ err = bpf_pe
gt; return 0;
> +
> if (buf) {
> - len = strlen(buf);
> - err = bpf_copy_to_user(uname, buf, ulen, len);
> + err = bpf_copy_to_user(uname, buf, input_len, len);
> if (err)
>
lse {
@@ -3609,7 +3613,7 @@ static int bpf_perf_link_fill_kprobe(const struct
perf_event *event,
uname = u64_to_user_ptr(info->perf_event.kprobe.func_name);
ulen = info->perf_event.kprobe.name_len;
- err = bpf_perf_link_fill_common(event, uname, ulen, &offset, &
On Wed, Oct 02, 2024 at 09:38:39PM +, tyrone-wu wrote:
> Previously when retrieving `bpf_link_info.perf_event` for
> kprobe/uprobe/tracepoint, the `name_len` field was not populated by the
> kernel, leaving it to reflect the value initially set by the user. This
> behavior was inconsistent with
-assets/35f22e8643ee/bzImage-9852d85e.xz
IMPORTANT: if you fix the issue, please add the following tag to the commit:
Reported-by: syzbot+4d2bdddae2e386601...@syzkaller.appspotmail.com
rcu: INFO: rcu_preempt detected expedited stalls on CPUs/tasks: {
0-...D
} 2665 jiffies s: 1653 root: 0x1/.
rcu
return err;
} else {
@@ -3609,7 +3613,7 @@ static int bpf_perf_link_fill_kprobe(const struct
perf_event *event,
uname = u64_to_user_ptr(info->perf_event.kprobe.func_name);
ulen = info->perf_event.kprobe.name_len;
- err = bpf_perf_link_fill_common(even
if (err)
> return err;
> } else {
> @@ -3609,7 +3611,7 @@ static int bpf_perf_link_fill_kprobe(const struct
> perf_event *event,
>
> uname = u64_to_user_ptr(info->perf_event.kprobe.func_name);
> ulen = info->perf_event.kp
pf_copy_to_user(uname, buf, ulen, len);
+ err = bpf_copy_to_user(uname, buf, *ulen, len);
if (err)
return err;
} else {
@@ -3609,7 +3611,7 @@ static int bpf_perf_link_fill_kprobe(const struct
perf_event *event,
uname =
On Thu, Sep 26, 2024 at 5:22 AM Christophe Leroy
wrote:
>
>
>
> Le 26/09/2024 à 01:38, Matthew Maurer a écrit :
> > Adds a new format for MODVERSIONS which stores each field in a separate
> > ELF section. This initially adds support for variable length names, but
> > could later be used to add add
Le 26/09/2024 à 01:38, Matthew Maurer a écrit :
Adds a new format for MODVERSIONS which stores each field in a separate
ELF section. This initially adds support for variable length names, but
could later be used to add additional fields to MODVERSIONS in a
backwards compatible way if needed. A
t to me.
>
> Nit: might be cleaner in a single if statement though:
>
> /* Skip one leading dot */
> if (last == '\0' && str_seq[in] == '.')
> in++;
>
> > +void modversion_ext_start(const struct load_info *info,
&
The new version info format has a superset of symbols in the old format.
Since this is a tool for in-tree modules, we don't need to parse the old
one with this tool any longer.
Signed-off-by: Matthew Maurer
---
scripts/export_report.pl | 22 ++
1 file changed, 10 inser
f2be83902..59959c21b205 100644
--- a/kernel/module/internal.h
+++ b/kernel/module/internal.h
@@ -86,6 +86,8 @@ struct load_info {
unsigned int vers;
unsigned int info;
unsigned int pcpu;
+ unsigned int vers_ext_crc;
+
might be cleaner in a single if statement though:
/* Skip one leading dot */
if (last == '\0' && str_seq[in] == '.')
in++;
> +void modversion_ext_start(const struct load_info *info,
> + struct modversion_inf
b/kernel/module/internal.h
index daef2be83902..59959c21b205 100644
--- a/kernel/module/internal.h
+++ b/kernel/module/internal.h
@@ -86,6 +86,8 @@ struct load_info {
unsigned int vers;
unsigned int info;
unsigned int pcpu;
+ unsigned int
syzbot suspects this issue was fixed by commit:
commit e634134180885574d1fe7aa162777ba41e7fcd5b
Author: Vladimir Oltean
Date: Mon May 27 15:39:54 2024 +
net/sched: taprio: make q->picos_per_byte available to fill_sched_entry()
bisection log: https://syzkaller.appspot.com/x/bisect.txt
1 - 100 of 4942 matches
Mail list logo
