On Wed, Feb 14, 2024 at 02:42:55PM -0800, Ian Rogers wrote:
[...]
> Thanks Leo, this is great cleanup! Series:
> Reviewed-by: Ian Rogers
Thanks a lot for reviewing, Ian!
Leo
On Thu, 15 Feb 2024 08:45:52 +0900
Masami Hiramatsu (Google) wrote:
> > Hmm, the above is a fast path. I wonder if we should add a patch to make
> > that into:
> >
> > if (unlikely(size_bytes & (sizeof(long) - 1)))
> > data_size = DIV_ROUND_UP(size_bytes, sizeof(long));
> >
On Wed, 14 Feb 2024 13:04:09 -0500
Steven Rostedt wrote:
> On Wed, 7 Feb 2024 00:10:04 +0900
> "Masami Hiramatsu (Google)" wrote:
>
> > diff --git a/kernel/trace/fgraph.c b/kernel/trace/fgraph.c
> > index ae42de909845..323a74623543 100644
> > --- a/kernel/trace/fgraph.c
> > +++
On Wed, 14 Feb 2024 13:59:58 -0500
Steven Rostedt wrote:
> On Wed, 7 Feb 2024 00:11:01 +0900
> "Masami Hiramatsu (Google)" wrote:
>
> > From: Ste
> > +/**
> > + * fgraph_reserve_data - Reserve storage on the task's ret_stack
> > + * @idx: The index of fgraph_array
> > + * @size_bytes: The
Ira Weiny wrote:
> Jonathan Cameron wrote:
> > On Wed, 14 Feb 2024 10:23:10 -0500
> > Steven Rostedt wrote:
> >
> > > On Wed, 14 Feb 2024 12:11:53 +
> > > Jonathan Cameron wrote:
> > >
> > > > So I'm thinking this is a won't fix - wait for the printk rework to
> > > > land and
> > > >
On Wed, Feb 14, 2024 at 3:40 AM Leo Yan wrote:
>
> Currently, the perf building enables register parsing based on the
> target architecture has supported register feature.
>
> Furthermore, the perf building system needs to maintain a variable
> 'NO_PERF_REGS' and defines macro
On Wed, 14 Feb 2024 14:19:19 -0800
Ira Weiny wrote:
> > > Jonathan Cameron wrote:
> > >
> > > > So I'm thinking this is a won't fix - wait for the printk rework to
> > > > land and
> > > > assume this will be resolved as well?
> > >
> > > That pretty much sums up what I was about to
Jonathan Cameron wrote:
> On Wed, 14 Feb 2024 10:23:10 -0500
> Steven Rostedt wrote:
>
> > On Wed, 14 Feb 2024 12:11:53 +
> > Jonathan Cameron wrote:
> >
> > > So I'm thinking this is a won't fix - wait for the printk rework to land
> > > and
> > > assume this will be resolved as well?
Fix trace_string() by assigning the string length to the return variable
which got lost in commit ddeea494a16f ("tracing/synthetic: Use union
instead of casts") and caused trace_string() to always return 0.
Signed-off-by: Thorsten Blum
---
kernel/trace/trace_events_synth.c | 3 ++-
1 file
From: Matti Lehtimäki
Add watchdog for MSM8226 platform.
Signed-off-by: Matti Lehtimäki
Reviewed-by: Konrad Dybcio
Signed-off-by: Luca Weiss
---
Changes in v2:
- Rebase on qcom for-next
- Pick up tags
- Link to v1:
On 2/14/2024 5:03 AM, Huacai Chen wrote:
> Hi, Oreoluwa,
>
> On Sat, Feb 10, 2024 at 8:29 AM Oreoluwa Babatunde
> wrote:
>> The platform_init() function which is called during device bootup
>> contains a few calls to memblock_alloc().
>> This is an issue because these allocations are done
Jonathan Cameron wrote:
> On Wed, 14 Feb 2024 10:23:10 -0500
> Steven Rostedt wrote:
>
> > On Wed, 14 Feb 2024 12:11:53 +
> > Jonathan Cameron wrote:
> >
> > > So I'm thinking this is a won't fix - wait for the printk rework to land
> > > and
> > > assume this will be resolved as well?
On 2/14/2024 2:39 PM, Eugenio Perez Martin wrote:
> On Wed, Feb 14, 2024 at 6:50 PM Steven Sistare
> wrote:
>>
>> On 2/13/2024 11:10 AM, Eugenio Perez Martin wrote:
>>> On Mon, Feb 12, 2024 at 6:16 PM Steve Sistare
>>> wrote:
Flush to guarantee no workers are running when suspend
On Wed, Feb 14, 2024 at 6:50 PM Steven Sistare
wrote:
>
> On 2/13/2024 11:10 AM, Eugenio Perez Martin wrote:
> > On Mon, Feb 12, 2024 at 6:16 PM Steve Sistare
> > wrote:
> >>
> >> Flush to guarantee no workers are running when suspend returns.
> >>
> >> Signed-off-by: Steve Sistare
> >> ---
>
On Wed, 7 Feb 2024 00:11:01 +0900
"Masami Hiramatsu (Google)" wrote:
> From: Ste
> +/**
> + * fgraph_reserve_data - Reserve storage on the task's ret_stack
> + * @idx: The index of fgraph_array
> + * @size_bytes: The size in bytes to reserve
> + *
> + * Reserves space of up to
Steven Rostedt writes:
> From: "Steven Rostedt (Google)"
>
> The allocation of the struct saved_cmdlines_buffer structure changed from:
>
> s = kmalloc(sizeof(*s), GFP_KERNEL);
> s->saved_cmdlines = kmalloc_array(TASK_COMM_LEN, val, GFP_KERNEL);
>
> to:
>
> orig_size =
On Wed, 14 Feb 2024 10:23:10 -0500
Steven Rostedt wrote:
> On Wed, 14 Feb 2024 12:11:53 +
> Jonathan Cameron wrote:
>
> > So I'm thinking this is a won't fix - wait for the printk rework to land and
> > assume this will be resolved as well?
>
> That pretty much sums up what I was about
On Sun, 03 Dec 2023 23:38:16 +0100, Luca Weiss wrote:
> Add some nodes to bring up SMP on msm8226 SoC. Another commit to fix the
> sorting of the nodes is also included since the ordering is currently a
> bit all over the place.
>
>
Applied, thanks!
[1/2] ARM: dts: qcom: msm8226: Sort and
On Wed, 7 Feb 2024 00:10:04 +0900
"Masami Hiramatsu (Google)" wrote:
> diff --git a/kernel/trace/fgraph.c b/kernel/trace/fgraph.c
> index ae42de909845..323a74623543 100644
> --- a/kernel/trace/fgraph.c
> +++ b/kernel/trace/fgraph.c
> @@ -99,10 +99,44 @@ enum {
>
On Sat, 10 Feb 2024 17:45:40 +0100, Luca Weiss wrote:
> The qfprom actually is bigger than 0x1000, so adjust the reg.
>
> Note that the non-ECC-corrected qfprom can be found at 0xfc4b8000
> (-0x4000). The current reg points to the ECC-corrected qfprom block
> which should have equivalent values
On Sat, 10 Feb 2024 17:28:51 +0100, Luca Weiss wrote:
> Add some nodes to bring up SMP on msm8226 SoC. Another commit to fix the
> sorting of the nodes is also included since the ordering is currently a
> bit all over the place.
>
> The bindings patch depends on the following series:
>
User programs can now ask user_events to handle the synchronization of
multiple different formats for an event with the same name via the new
USER_EVENT_REG_MULTI_FORMAT flag.
Add a section for USER_EVENT_REG_MULTI_FORMAT that explains the intended
purpose and caveats of using it. Explain how
The current code for finding and deleting events assumes that there will
never be cases when user_events are registered with the same name, but
different formats. In the future this scenario will exist to ensure
user programs can be updated or modify their events and run different
versions of
Currently user_events supports 1 event with the same name and must have
the exact same format when referenced by multiple programs. This opens
an opportunity for malicous or poorly thought through programs to
create events that others use with different formats. Another scenario
is user programs
User_events now has multi-format events which allow for the same
register name, but with different formats. When this occurs, different
tracepoints are created with unique names.
Add a new test that ensures the same name can be used for two different
formats. Ensure they are isolated from each
Currently user_events supports 1 event with the same name and must have
the exact same format when referenced by multiple programs. This opens
an opportunity for malicous or poorly thought through programs to
create events that others use with different formats. Another scenario
is user programs
On 2/13/2024 11:10 AM, Eugenio Perez Martin wrote:
> On Mon, Feb 12, 2024 at 6:16 PM Steve Sistare
> wrote:
>>
>> Flush to guarantee no workers are running when suspend returns.
>>
>> Signed-off-by: Steve Sistare
>> ---
>> drivers/vdpa/vdpa_sim/vdpa_sim.c | 13 +
>> 1 file changed,
On 2/13/2024 10:58 AM, Eugenio Perez Martin wrote:
> On Mon, Feb 12, 2024 at 6:16 PM Steve Sistare
> wrote:
>>
>> Flush to guarantee no workers are running when suspend returns.
>>
>> Signed-off-by: Steve Sistare
>
> Acked-by: Eugenio Pérez
>
> Should this have a Fixes tag?
Sure, I will
On Wed, Feb 14, 2024 at 05:58:37PM +0100, Eric Dumazet wrote:
> On Wed, Feb 14, 2024 at 5:49 PM Breno Leitao wrote:
> >
> > On Wed, Feb 14, 2024 at 04:41:36PM +0100, Eric Dumazet wrote:
> > > On Wed, Feb 14, 2024 at 3:45 PM Breno Leitao wrote:
> > > >
> > > > On Tue, Feb 13, 2024 at 10:04:57AM
With the introduction of tee_remoteproc, the firmware has to be loaded
first before parsing the resource table. This constraint is linked to
the firmware authentication, that contains the resource table.
In OP-TEE, this authentication is correlated with the load of the
firmware (the loaded
Implement a new method to load a firmware and start the remote processor.
In this method the firmware is loaded first and then the loaded resource
table is obtained.
Signed-off-by: Arnaud Pouliquen
---
drivers/remoteproc/remoteproc_core.c | 86 +++-
The new TEE remoteproc device is used to manage remote firmware in a
secure, trusted context. The 'st,stm32mp1-m4-tee' compatibility is
introduced to delegate the loading of the firmware to the trusted
execution context. In such cases, the firmware should be signed and
adhere to the image format
To prepare for the support of TEE remoteproc, create sub-functions
that can be used in both cases, with and without TEE support.
Signed-off-by: Arnaud Pouliquen
---
drivers/remoteproc/stm32_rproc.c | 84 +++-
1 file changed, 51 insertions(+), 33 deletions(-)
diff
From: Arnaud Pouliquen
Add a remoteproc TEE (Trusted Execution Environment) driver
that will be probed by the TEE bus. If the associated Trusted
application is supported on secure part this device offers a client
interface to load a firmware in the secure part.
This firmware could be
Updates from the previous version [1]:
This version proposes another approach based on an alternate load and boot
of the coprocessor. Therefore, the constraint introduced by tee_remoteproc
is that the firmware has to be authenticated and loaded before the resource
table can be obtained.
The
The "st,stm32mp1-m4-tee" compatible is utilized in a system configuration
where the Cortex-M4 firmware is loaded by the Trusted execution Environment
(TEE).
For instance, this compatible is used in both the Linux and OP-TEE
device-tree:
- In OP-TEE, a node is defined in the device tree with the
Add a check on the optional rproc->cached_table to perform the memory
copy only if it is not null.
2 use cases to support:
- starting on boot, in which case rproc->cached_table can be null,
- starting on crash recovery, where the cached table is used to save
the resource table configuration on
Good morning,
On Tue, Feb 13, 2024 at 09:54:50AM -0800, Tanmay Shah wrote:
> ZynqMP TCM information was fixed in driver. Now ZynqMP TCM information
> is available in device-tree. Parse TCM information in driver
> as per new bindings.
>
> Signed-off-by: Tanmay Shah
> ---
>
> Changes in v10:
>
Ira Weiny wrote:
> Jonathan Cameron wrote:
> > On Tue, 06 Feb 2024 14:15:32 -0800
> > Ira Weiny wrote:
> >
> >
[snip]
> >
> > diff --git a/kernel/trace/trace.c b/kernel/trace/trace.c
> > index 9ff8a439d674..7ee45f22f56f 100644
> > --- a/kernel/trace/trace.c
> > +++ b/kernel/trace/trace.c
> >
On Wed, Feb 14, 2024 at 5:49 PM Breno Leitao wrote:
>
> On Wed, Feb 14, 2024 at 04:41:36PM +0100, Eric Dumazet wrote:
> > On Wed, Feb 14, 2024 at 3:45 PM Breno Leitao wrote:
> > >
> > > On Tue, Feb 13, 2024 at 10:04:57AM -0800, Jakub Kicinski wrote:
> > > > On Tue, 13 Feb 2024 14:57:49 +0100
Jonathan Cameron wrote:
> On Tue, 06 Feb 2024 14:15:32 -0800
> Ira Weiny wrote:
>
> > Smatch caught that cxl_cper_post_event() is called with a spinlock held
> > or preemption disabled.[1] The callback takes the device lock to
> > perform address translation and therefore might sleep. The
On Wed, Feb 14, 2024 at 04:41:36PM +0100, Eric Dumazet wrote:
> On Wed, Feb 14, 2024 at 3:45 PM Breno Leitao wrote:
> >
> > On Tue, Feb 13, 2024 at 10:04:57AM -0800, Jakub Kicinski wrote:
> > > On Tue, 13 Feb 2024 14:57:49 +0100 Eric Dumazet wrote:
> > > > Please note that adding other sysfs
On Wed, 14 Feb 2024 17:30:40 +0200
Kalle Valo wrote:
> Although the patch didn't apply for me as in my tree the functions are
> in kernel/trace/trace.c. I don't know what happened so as a quick hack I
> just manually added the three lines to my version of trace.c. Let me
> know if there's a git
From: "Steven Rostedt (Google)"
The allocation of the struct saved_cmdlines_buffer structure changed from:
s = kmalloc(sizeof(*s), GFP_KERNEL);
s->saved_cmdlines = kmalloc_array(TASK_COMM_LEN, val, GFP_KERNEL);
to:
orig_size = sizeof(*s) + val * TASK_COMM_LEN;
On Wed, 14 Feb 2024 17:30:40 +0200
Kalle Valo wrote:
> Although the patch didn't apply for me as in my tree the functions are
> in kernel/trace/trace.c. I don't know what happened so as a quick hack I
> just manually added the three lines to my version of trace.c. Let me
> know if there's a git
On Wed, Feb 14, 2024 at 3:45 PM Breno Leitao wrote:
>
> On Tue, Feb 13, 2024 at 10:04:57AM -0800, Jakub Kicinski wrote:
> > On Tue, 13 Feb 2024 14:57:49 +0100 Eric Dumazet wrote:
> > > Please note that adding other sysfs entries is expensive for workloads
> > > creating/deleting netdev and netns
On Wed, Feb 14, 2024 at 03:01:10PM +0100, Aiswarya Cyriac wrote:
> This commit fixes the following warning when building virtio_snd driver.
>
> "
> *** CID 1583619: Uninitialized variables (UNINIT)
> sound/virtio/virtio_kctl.c:294 in virtsnd_kctl_tlv_op()
> 288
> 289 break;
>
Steven Rostedt writes:
> On Wed, 14 Feb 2024 14:50:56 +0200
> Kalle Valo wrote:
>
>> Hi Steven,
>>
>> I upgraded our ath11k test setup to v6.8-rc4 and noticed a new kmemleak
>> warning in the log:
>
> Thanks for the report.
>
>>
>> unreferenced object 0x8881010c8000 (size 32760):
>>
From: "Steven Rostedt (Google)"
The allocation of the struct saved_cmdlines_buffer structure changed from:
s = kmalloc(sizeof(*s), GFP_KERNEL);
s->saved_cmdlines = kmalloc_array(TASK_COMM_LEN, val, GFP_KERNEL);
to:
orig_size = sizeof(*s) + val * TASK_COMM_LEN;
On Wed, 14 Feb 2024 12:11:53 +
Jonathan Cameron wrote:
> So I'm thinking this is a won't fix - wait for the printk rework to land and
> assume this will be resolved as well?
That pretty much sums up what I was about to say ;-)
tp_printk is more of a hack and not to be used sparingly. With
On Tue, Feb 13, 2024 at 10:04:57AM -0800, Jakub Kicinski wrote:
> On Tue, 13 Feb 2024 14:57:49 +0100 Eric Dumazet wrote:
> > Please note that adding other sysfs entries is expensive for workloads
> > creating/deleting netdev and netns often.
> >
> > I _think_ we should find a way for not creating
On Wed, 14 Feb 2024 14:50:56 +0200
Kalle Valo wrote:
> Hi Steven,
>
> I upgraded our ath11k test setup to v6.8-rc4 and noticed a new kmemleak
> warning in the log:
Thanks for the report.
>
> unreferenced object 0x8881010c8000 (size 32760):
> comm "swapper", pid 0, jiffies 4294667296
>
This commit fixes the following warning when building virtio_snd driver.
"
*** CID 1583619: Uninitialized variables (UNINIT)
sound/virtio/virtio_kctl.c:294 in virtsnd_kctl_tlv_op()
288
289 break;
290 }
291
292 kfree(tlv);
293
vvv CID 1583619:
On Tue, 13 Feb 2024 20:42:18 -0500
Steven Rostedt wrote:
> On Wed, 7 Feb 2024 00:09:21 +0900
> "Masami Hiramatsu (Google)" wrote:
>
> > From: Steven Rostedt (VMware)
> >
> > Pass the fgraph_ops structure to the function graph callbacks. This will
> > allow callbacks to add a descriptor to a
From: Masami Hiramatsu (Google)
Support accessing $argN in the return probe events. This will help users to
record entry data in function return (exit) event for simplfing the function
entry/exit information in one event, and record the result values (e.g.
allocated object/initialized object) at
From: Masami Hiramatsu (Google)
Instead of incrementing the trace_probe::nr_args, init it at trace_probe_init().
This is a cleanup, so the behavior is not changed.
Signed-off-by: Masami Hiramatsu (Google)
---
kernel/trace/trace_eprobe.c |2 +-
kernel/trace/trace_probe.c | 10 ++
From: Masami Hiramatsu (Google)
Cleanup traceprobe_parse_probe_arg_body() to split out the
type parser and post-processing part of fetch_insn.
This makes no functional change.
Signed-off-by: Masami Hiramatsu (Google)
---
kernel/trace/trace_probe.c | 230
From: Masami Hiramatsu (Google)
Despite the fprobe event, "Kretprobe" was commented. So fix it.
Signed-off-by: Masami Hiramatsu (Google)
---
kernel/trace/trace_fprobe.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/kernel/trace/trace_fprobe.c
From: Masami Hiramatsu (Google)
Fix to search a field from the structure which has anonymous union
correctly.
Since the reference `type` pointer was updated in the loop, the search
loop suddenly aborted where it hits an anonymous union. Thus it can not
find the field after the anonymous union.
Hi,
Here is a series of patches to support accessing function entry data from
function *return* probes (including kretprobe and fprobe-exit event).
This allows us to access the results of some functions, which returns the
error code and its results are passed via function parameter, such as an
On Wed, 14 Feb 2024 14:07:40 +0100,
Aiswarya Cyriac wrote:
>
>
> On Wed, 14 Feb 2024 12:30:19 +0100,
> Michael S. Tsirkin wrote:
> >>
> >> On Wed, Feb 14, 2024 at 09:08:26AM +, Aiswarya Cyriac wrote:
> >> > Hi Michael,
> >> >
> >> > Thank you for reviewing. I have updated my response inline
On Wed, 14 Feb 2024 12:30:19 +0100,
Michael S. Tsirkin wrote:
>>
>> On Wed, Feb 14, 2024 at 09:08:26AM +, Aiswarya Cyriac wrote:
>> > Hi Michael,
>> >
>> > Thank you for reviewing. I have updated my response inline
>> >
>> > On Tue, Feb 13, 2024 at 09:51:30AM +0100, Aiswarya Cyriac wrote:
>>
Hi, Oreoluwa,
On Sat, Feb 10, 2024 at 8:29 AM Oreoluwa Babatunde
wrote:
>
> The platform_init() function which is called during device bootup
> contains a few calls to memblock_alloc().
> This is an issue because these allocations are done before reserved
> memory regions are set aside in
Hi Steven,
I upgraded our ath11k test setup to v6.8-rc4 and noticed a new kmemleak
warning in the log:
unreferenced object 0x8881010c8000 (size 32760):
comm "swapper", pid 0, jiffies 4294667296
hex dump (first 32 bytes):
ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
On Tue, 06 Feb 2024 14:15:32 -0800
Ira Weiny wrote:
> Smatch caught that cxl_cper_post_event() is called with a spinlock held
> or preemption disabled.[1] The callback takes the device lock to
> perform address translation and therefore might sleep. The record data
> is released back to BIOS
The target is to allow the tool to always enable the perf register
feature for native parsing and cross parsing, and current code doesn't
depend on the macro 'HAVE_PERF_REGS_SUPPORT'.
This patch remove the variable 'NO_PERF_REGS' and the defined macro
'HAVE_PERF_REGS_SUPPORT' from the Makefile.
Every architecture can provide a register list for sampling. If an
architecture doesn't support register sampling, it won't define the data
structure 'sample_reg_masks'. Consequently, any code using this
structure must be protected by the macro 'HAVE_PERF_REGS_SUPPORT'.
This patch defines a weak
Currently, the macro HAVE_PERF_REGS_SUPPORT is used as a switch to turn
on or turn off the code of perf registers. If any architecture cannot
support perf register, it disables the perf register parsing, for both
the native parsing and cross parsing for other architectures.
To support both the
CONFIG_PERF_REGS is not used, remove it.
Signed-off-by: Leo Yan
---
tools/perf/Makefile.config | 4
1 file changed, 4 deletions(-)
diff --git a/tools/perf/Makefile.config b/tools/perf/Makefile.config
index aa55850fbc21..8b740c668ab7 100644
--- a/tools/perf/Makefile.config
+++
Currently, the perf building enables register parsing based on the
target architecture has supported register feature.
Furthermore, the perf building system needs to maintain a variable
'NO_PERF_REGS' and defines macro 'HAVE_PERF_REGS_SUPPORT' for statically
compiling the tool.
As a result, the
On Wed, 14 Feb 2024 12:30:19 +0100,
Michael S. Tsirkin wrote:
>
> On Wed, Feb 14, 2024 at 09:08:26AM +, Aiswarya Cyriac wrote:
> > Hi Michael,
> >
> > Thank you for reviewing. I have updated my response inline
> >
> > On Tue, Feb 13, 2024 at 09:51:30AM +0100, Aiswarya Cyriac wrote:
> > >>
On Wed, Feb 14, 2024 at 09:08:26AM +, Aiswarya Cyriac wrote:
> Hi Michael,
>
> Thank you for reviewing. I have updated my response inline
>
> On Tue, Feb 13, 2024 at 09:51:30AM +0100, Aiswarya Cyriac wrote:
> >> Fix the following warning when building virtio_snd driver.
> >>
> >> "
> >> ***
: ca185770db914869ff9fe773bac5e0e5e4165b83
patch link:
https://lore.kernel.org/r/20240213114945.3528801-3-vdonnefort%40google.com
patch subject: [PATCH v17 2/6] ring-buffer: Introducing ring-buffer mapping
functions
config: x86_64-randconfig-161-20240214
(https://download.01.org/0day-ci/archive/20240214/202402141856
This commit fixes the following warning when building virtio_snd driver.
"
*** CID 1583619: Uninitialized variables (UNINIT)
sound/virtio/virtio_kctl.c:294 in virtsnd_kctl_tlv_op()
288
289 break;
290 }
291
292 kfree(tlv);
293
vvv CID 1583619:
Hi Michael,
Thank you for reviewing. I have updated my response inline
On Tue, Feb 13, 2024 at 09:51:30AM +0100, Aiswarya Cyriac wrote:
>> Fix the following warning when building virtio_snd driver.
>>
>> "
>> *** CID 1583619: Uninitialized variables (UNINIT)
>> sound/virtio/virtio_kctl.c:294
75 matches
Mail list logo
