On Thu, 30 May 2024 17:05:46 +0200, Luca Weiss wrote:
> This series adds support for Type-C Port Management on the Fairphone 4
> which enables USB role switching and orientation switching.
>
> This enables a user for example to plug in a USB stick or a USB keyboard
> to the Type-C port.
>
> To:
On Fri, 29 Mar 2024 13:26:18 +0100, Luca Weiss wrote:
> This series adds support for Type-C Port Management on the Fairphone 4
> which enables USB role switching and orientation switching.
>
> This enables a user for example to plug in a USB stick or a USB keyboard
> to the Type-C port.
>
> To:
On Fri, 31 May 2024 14:05:59 +0200, David Wronek wrote:
> It looks like "cdsp_mem" was pasted in the license header by accident.
> Fix the typo by removing it.
>
>
Applied, thanks!
[1/1] arm64: dts: qcom: sm8550-samsung-q5q: fix typo
commit: a5c84d2dde8089ece5e13f264359c6117ea3186b
Bes
On Sat, 01 Jun 2024 23:37:44 -0400
Steven Rostedt wrote:
> hanges since v1:
> https://lore.kernel.org/linux-trace-kernel/20240525023652.903909...@goodmis.org/
>
> - Added ftrace helpers to allow an ftrace_ops to be a subop of a
> managing ftrace_op. That is, the managing ftrace_op will enable
From: "Steven Rostedt (Google)"
In most cases function graph is used by a single user. Instead of calling
a loop to call function graph callbacks in this case, call the function
return callback directly.
Use the static_key that is set when the function graph tracer has less
than 2 callbacks regi
From: "Steven Rostedt (Google)"
Instead of iterating through the entire fgraph_array[] and seeing if one
of the bitmap bits are set to know to call the array's retfunc() function,
use for_each_set_bit() on the bitmap itself. This will only iterate for
the number of set bits.
Signed-off-by: Steve
From: "Steven Rostedt (Google)"
In most cases function graph is used by a single user. Instead of calling
a loop to call function graph callbacks in this case, call the function
entry callback directly.
Add a static_key that will be used to set the function graph logic to
either do the loop (whe
From: "Steven Rostedt (Google)"
Instead of looping through all the elements of fgraph_array[] to see if
there's an gops attached to one and then calling its gops->func(). Create
a fgraph_array_bitmask that sets bits when an index in the array is
reserved (via the simple lru algorithm). Then only
From: "Masami Hiramatsu (Google)"
Add a selftest for multiple function graph tracer with storage on a same
function. In this case, the shadow stack entry will be shared among those
fgraph with different data storage. So this will ensure the fgraph will
not mixed those storage data.
Link:
https:
From: "Steven Rostedt (VMware)"
Add boot up selftest that passes variables from a function entry to a
function exit, and make sure that they do get passed around.
Co-developed with Masami Hiramatsu:
Link:
https://lore.kernel.org/linux-trace-kernel/171509110271.162236.11047551496319744627.stgit@
From: "Steven Rostedt (VMware)"
Added functions that can be called by a fgraph_ops entryfunc and retfunc to
store state between the entry of the function being traced to the exit of
the same function. The fgraph_ops entryfunc() may call
fgraph_reserve_data() to store up to 32 words onto the task'
From: "Steven Rostedt (VMware)"
The use of the task->trace_recursion for the logic used for the function
graph no-trace was a bit of an abuse of that variable. Now that there
exists global vars that are per stack for registered graph traces, use
that instead.
Link:
https://lore.kernel.org/linux
From: "Steven Rostedt (VMware)"
The use of the task->trace_recursion for the logic used for the function
graph depth was a bit of an abuse of that variable. Now that there
exists global vars that are per stack for registered graph traces, use that
instead.
Link:
https://lore.kernel.org/linux-tr
From: "Steven Rostedt (VMware)"
The use of the task->trace_recursion for the logic used for the
set_graph_function was a bit of an abuse of that variable. Now that there
exists global vars that are per stack for registered graph traces, use that
instead.
Link:
https://lore.kernel.org/linux-trac
From: "Steven Rostedt (VMware)"
Allow for instances to have their own ftrace_ops part of the fgraph_ops
that makes the funtion_graph tracer filter on the set_ftrace_filter file
of the instance and not the top instance.
This uses the new ftrace_startup_subops(), by using graph_ops as the
"manager
From: "Steven Rostedt (VMware)"
There are cases where a single system will use a single function callback
to handle multiple users. For example, to allow function_graph tracer to
have multiple users where each can trace their own set of functions, it is
useful to only have one ftrace_ops register
From: "Steven Rostedt (VMware)"
Add a "task variables" array on the tasks shadow ret_stack that is the
size of longs for each possible registered fgraph_ops. That's a total
of 16, taking up 8 * 16 = 128 bytes (out of a page size 4k).
This will allow for fgraph_ops to do specific features on a pe
From: "Steven Rostedt (Google)"
Now that the function_graph has a main callback that handles the function
graph subops tracing, it no longer honors the pid filtering of ftrace. Add
back this logic in the function_graph code to update the gops callback for
the entry function to test if it should t
From: "Masami Hiramatsu (Google)"
Since the fgraph_array index is used for the bitmap on the shadow
stack, it may leave some entries after a function_graph instance is
removed. Thus if another instance reuses the fgraph_array index soon
after releasing it, the fgraph may confuse to call the newer
From: "Steven Rostedt (Google)"
The subops filters use a "manager" ops to enable and disable its filters.
The manager ops can handle more than one subops, and its filter is what
controls what functions get set. Add a ftrace_hash_move_and_update_subops()
function that will update the manager ops w
From: "Steven Rostedt (VMware)"
Some of the flags for ftrace_startup() may be exposed even when
CONFIG_DYNAMIC_FTRACE is not configured in. This is fine as the difference
between dynamic ftrace and static ftrace is done within the internals of
ftrace itself. No need to have use cases fail to comp
From: "Steven Rostedt (VMware)"
Pass the fgraph_ops structure to the function graph callbacks. This will
allow callbacks to add a descriptor to a fgraph_ops private field that wil
be added in the future and use it for the callbacks. This will be useful
when more than one callback can be registere
From: "Steven Rostedt (VMware)"
Now that function graph tracing can handle more than one user, allow it to
be enabled in the ftrace instances. Note, the filtering of the functions is
still joined by the top level set_ftrace_filter and friends, as well as the
graph and nograph files.
Co-developed
From: "Steven Rostedt (VMware)"
The function pointers ftrace_graph_entry and ftrace_graph_return are no
longer called via the function_graph tracer. Instead, an array structure is
now used that will allow for multiple users of the function_graph
infrastructure. The variables are still used by the
From: "Masami Hiramatsu (Google)"
For the tail-call, there would be 2 or more ftrace_ret_stacks on the
ret_stack, which records "return_to_handler" as the return address except
for the last one. But on the real stack, there should be 1 entry because
tail-call reuses the return address on the sta
From: "Steven Rostedt (VMware)"
Allow for multiple users to attach to function graph tracer at the same
time. Only 16 simultaneous users can attach to the tracer. This is because
there's an array that stores the pointers to the attached fgraph_ops. When
a function being traced is entered, each of
From: "Steven Rostedt (VMware)"
Add an array structure that will eventually allow the function graph tracer
to have up to 16 simultaneous callbacks attached. It's an array of 16
fgraph_ops pointers, that is assigned when one is registered. On entry of a
function the entry of the first item in the
From: "Steven Rostedt (VMware)"
Instead of using "ALIGN()", use BUILD_BUG_ON() as the structures should
always be divisible by sizeof(long).
Co-developed with Masami Hiramatsu:
Link:
https://lore.kernel.org/linux-trace-kernel/171509093949.162236.14518699447151894536.stgit@devnote2
Link:
http:/
From: "Steven Rostedt (VMware)"
In order to make it possible to have multiple callbacks registered with the
function_graph tracer, the retstack needs to be converted from an array of
ftrace_ret_stack structures to an array of longs. This will allow to store
the list of callbacks on the stack for
This is a continuation of the function graph multi user code.
I wrote a proof of concept back in 2019 of this code[1] and
Masami started cleaning it up. I started from Masami's work v10
that can be found here:
https://lore.kernel.org/linux-trace-kernel/171509088006.162236.7227326999861366050.s
On 6/1/2024 8:01 PM, Masami Hiramatsu (Google) wrote:
> On Sat, 1 Jun 2024 15:19:39 -0700
> Jeff Johnson wrote:
>
>> make allmodconfig && make W=1 C=1 reports for lib/test_*.ko:
>> WARNING: modpost: missing MODULE_DESCRIPTION() in lib/test_hexdump.o
>> WARNING: modpost: missing MODULE_DESCRIPTION
On Thu, 30 May 2024 23:50:32 -0700
syzbot wrote:
> Hello trace maintainers/developers,
>
> This is a 31-day syzbot report for the trace subsystem.
> All related reports/information can be found at:
> https://syzkaller.appspot.com/upstream/s/trace
>
> During the period, 1 new issues were detecte
On Sat, 1 Jun 2024 15:19:39 -0700
Jeff Johnson wrote:
> make allmodconfig && make W=1 C=1 reports for lib/test_*.ko:
> WARNING: modpost: missing MODULE_DESCRIPTION() in lib/test_hexdump.o
> WARNING: modpost: missing MODULE_DESCRIPTION() in lib/test_dhry.o
> WARNING: modpost: missing MODULE_DESCRI
On Fri, 31 May 2024 18:49:10 -0400
Steven Rostedt wrote:
> On Fri, 31 May 2024 23:50:23 +0900
> Masami Hiramatsu (Google) wrote:
>
> > So is it similar to the fprobe/kprobe, use shared signle ftrace_ops,
> > but keep each fgraph has own hash table?
>
> Sort of.
>
> I created helper functions
)
> +MODULE_DESCRIPTION("sample kernel module showing the use of return probes");
> MODULE_LICENSE("GPL");
>
> ---
> base-commit: b050496579632f86ee1ef7e7501906db579f3457
> change-id: 20240601-md-samples-kprobes-efb32cbcc8dd
>
--
Masami Hiramatsu (Google)
+MODULE_DESCRIPTION("sample kernel module showing the use of return probes");
MODULE_LICENSE("GPL");
---
base-commit: b050496579632f86ee1ef7e7501906db579f3457
change-id: 20240601-md-samples-kprobes-efb32cbcc8dd
On Thu, 30 May 2024 16:06:17 +0530 Sarannya S wrote:
> -static int service_announce_del(struct sockaddr_qrtr *dest,
> +static void service_announce_del(struct sockaddr_qrtr *dest,
> struct qrtr_server *srv)
nit: please realign the continuation line
On 05/31/24 08:30, Sebastian Andrzej Siewior wrote:
> On 2024-05-30 12:10:44 [+0100], Qais Yousef wrote:
> > > This is not consistent because IMHO the clock setup & slack should be
> > > handled equally. So I am asking the sched folks for a policy and I am
> > > leaning towards looking at task-poli
ODULE_AUTHOR("Luis R. Rodriguez ");
+MODULE_DESCRIPTION("proc sysctl test driver");
MODULE_LICENSE("GPL");
diff --git a/lib/test_user_copy.c b/lib/test_user_copy.c
index 5ff04d8fe971..9cfef46fa2d2 100644
--- a/lib/test_user_copy.c
+++ b/lib/test_user_copy.c
@@ -328,4 +328,5 @@ static void __exit test_user_copy_exit(void)
module_exit(test_user_copy_exit);
MODULE_AUTHOR("Kees Cook ");
+MODULE_DESCRIPTION("Kernel module for testing copy_to/from_user
infrastructure");
MODULE_LICENSE("GPL");
---
base-commit: b050496579632f86ee1ef7e7501906db579f3457
change-id: 20240601-md-lib-test-16083d9d77e2
rt_task() checks if a task has RT priority. But depends on your
dictionary, this could mean it belongs to RT class, or is a 'realtime'
task, which includes RT and DL classes.
Since this has caused some confusion already on discussion [1], it
seemed a clean up is due.
I define the usage of rt_task
{rt, realtime, dl}_{task, prio}() functions return value is actually
a bool. Convert their return type to reflect that.
Suggested-by: Steven Rostedt (Google)
Signed-off-by: Qais Yousef
---
include/linux/sched/deadline.h | 8
include/linux/sched/rt.h | 16
2 fil
Make rt_task() return true only for RT class and add new realtime_task() to
return true for RT and DL classes to avoid some confusion the old API can
cause.
No functional changes intended in patch 1. Patch 2 cleans up the return type as
suggested by Steve.
Changes since v3:
* Make sure t
On 5/31/24 6:43 PM, Alexei Starovoitov wrote:
> On Fri, May 31, 2024 at 2:33 AM Vlastimil Babka wrote:
>> might_alloc(flags);
>>
>> - if (unlikely(should_failslab(s, flags)))
>> - return NULL;
>> + if (static_branch_unlikely(&should_failslab_active)) {
>> +
On 6/1/24 1:39 AM, Roman Gushchin wrote:
> On Fri, May 31, 2024 at 11:33:31AM +0200, Vlastimil Babka wrote:
>> Incomplete, help needed from ftrace/kprobe and bpf folks.
>>
>> As previously mentioned by myself [1] and others [2] the functions
>> designed for error injection can bring visible overhe
On 5/31/24 5:31 PM, Mark Rutland wrote:
> Hi,
>
> On Fri, May 31, 2024 at 11:33:31AM +0200, Vlastimil Babka wrote:
>> Incomplete, help needed from ftrace/kprobe and bpf folks.
>
>> - the generic error injection using kretprobes with
>> override_function_with_return is handled in patch 2. The
>>
On Fri, 31 May 2024 18:49:10 -0400
Steven Rostedt wrote:
> I'm just cleaning it up. I'll post it tomorrow (your today).
It's going to take a little longer. I found that the rewrite broke
updating the filters while tracing is enabled. Working on fixing that
now.
-- Steve
From: Masami Hiramatsu (Google)
Add a test case for tracepoint events on modules. This checks if it can add
and remove the events correctly.
Signed-off-by: Masami Hiramatsu (Google)
---
tools/testing/selftests/ftrace/config |1 +
.../test.d/dynevent/add_remove_tprobe_module.tc
From: Masami Hiramatsu (Google)
Support raw tracepoint event on module by fprobe events.
Since it only uses for_each_kernel_tracepoint() to find a tracepoint,
the tracepoints on modules are not handled. Thus if user specified a
tracepoint on a module, it shows an error.
This adds new for_each_mod
From: Masami Hiramatsu (Google)
Add for_each_module_tracepoint() for iterating over tracepoints
on modules. This is similar to the for_each_kernel_tracepoint()
but only for the tracepoints on modules (not including kernel
built-in tracepoints).
Signed-off-by: Masami Hiramatsu (Google)
---
incl
On Mon, May 27, 2024 at 08:59:37PM +0300, Julian Anastasov wrote:
>
> Hello,
>
> On Thu, 23 May 2024, Ismael Luceno wrote:
>
> > In the context of the SCTP SNAT/DNAT handler, these calls can only
> > return true.
> >
> > Ref: e10d3ba4d434 ("ipvs: Fix checksumming on GSO of SCTP packets")
Hi,
This series implements the tracepoint events on modules.
This version separates a patch for tracepoint subsystem from
fprobe-event patch, and adds a selftests for tracepoint
events on modules.
Thank you,
---
Masami Hiramatsu (Google) (3):
tracepoint: Support iterating over tracepoints
51 matches
Mail list logo
