On Wed, 1 May 2024 23:56:26 +0900
Masami Hiramatsu (Google) wrote:
> Looks good to me.
>
> Reviewed-by: Masami Hiramatsu (Google)
Thanks Masami,
Although Tze-nan pointed out a issue with this patch.
I just published v2, can you review that one too?
Thanks,
-- Steve
From: "Steven Rostedt (Google)"
Synthetic events create and destroy tracefs files when they are created
and removed. The tracing subsystem has its own file descriptor
representing the state of the events attached to the tracefs files.
There's a race between the eventfs file
On Thu, 2 May 2024 03:10:24 +
Tze-nan Wu (吳澤南) wrote:
> >
> Sorry for my late reply, I'm testing the patch on my machine now.
> Test will be done in four hours.
>
> There's something I'm worrying about in the patch,
> what I'm worrying about is commented in the code below.
>
> /kernel/t
From: "Steven Rostedt (Google)"
The events directory gets its permissions from the root inode. But this
can cause an inconsistency if the instances directory changes its
permissions, as the permissions of the created directories under it should
inherit the permissions of the instances
From: "Steven Rostedt (Google)"
Treat the events directory the same as other directories when it comes to
permissions. The events directory was considered different because it's
dentry is persistent, whereas the other directory dentries are created
when accessed. But the way trace
From: "Steven Rostedt (Google)"
The toplevel events directory is really no different than the events
directory of instances. Having the two be different caused
inconsistencies and made it harder to fix the permissions bugs.
Make all events directories act the same.
Cc: sta...@vger.
From: "Steven Rostedt (Google)"
If the instances directory's permissions were never change, then have it
and its children use the mount point permissions as the default.
Currently, the permissions of instance directories are determined by the
instance directory's permission
.
Steven Rostedt (Google) (5):
tracefs: Reset permissions on remount if permissions are options
tracefs: Still use mount point as default permissions for instances
eventfs: Do not differentiate the toplevel events directory
eventfs: Do not treat events directory different than
From: "Steven Rostedt (Google)"
There's an inconsistency with the way permissions are handled in tracefs.
Because the permissions are generated when accessed, they default to the
root inode's permission if they were never set by the user. If the user
sets the permissions, th
From: "Steven Rostedt (Google)"
Synthetic events create and destroy tracefs files when they are created
and removed. The tracing subsystem has its own file descriptor
representing the state of the events attached to the tracefs files.
There's a race between the eventfs file
On Sun, 28 Apr 2024 20:28:37 -0400
Steven Rostedt wrote:
> > Looking for any suggestion or solution, appreciate.
>
> Yeah, I do not think eventfs should be involved in this. It needs to be
> protected at a higher level (in the synthetic/dynamic event code).
>
> I
On Fri, 26 Apr 2024 15:34:08 +0800
Tze-nan wu wrote:
> "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 opportun
On Thu, 25 Apr 2024 13:31:53 -0700
Andrii Nakryiko wrote:
I'm just coming back from Japan (work and then a vacation), and
catching up on my email during the 6 hour layover in Detroit.
> Hey Masami,
>
> I can't really review most of that code as I'm completely unfamiliar
> with all those inner w
On Tue, 23 Apr 2024 12:04:15 -0400
"Liam R. Howlett" wrote:
> > Nit: For all labels, please add a space before them. Otherwise, diffs will
> > show "unlock" as the function and not "ring_buffer_map", making it harder
> > to find where the change is.
> >
>
> Isn't the inclusion of a space befo
On Mon, 15 Apr 2024 21:50:20 +0900
"Masami Hiramatsu (Google)" wrote:
> @@ -27,23 +28,157 @@
>
> #define FGRAPH_RET_SIZE sizeof(struct ftrace_ret_stack)
> #define FGRAPH_RET_INDEX DIV_ROUND_UP(FGRAPH_RET_SIZE, sizeof(long))
> +
> +/*
> + * On entry to a function (via function_graph_enter()),
[36/36] Add new flag to skip timestamp recording.
> >
> > Overview
> >
> > This series does major 2 changes, enable multiple function-graphs on
> > the ftrace (e.g. allow function-graph on sub instances) and rewrite the
> > fprobe on this function-graph.
&
On Thu, 18 Apr 2024 09:55:55 +0300
Mike Rapoport wrote:
Hi Mike,
Thanks for doing this review!
> > +/**
> > + * struct trace_buffer_meta - Ring-buffer Meta-page description
> > + * @meta_page_size:Size of this meta-page.
> > + * @meta_struct_len: Size of this structure.
> > + * @s
On Mon, 15 Apr 2024 18:40:23 +0900
"Masami Hiramatsu (Google)" wrote:
> Check the number of probe target symbols in the target module when
> the module is loaded. If the probe is not on the unique name symbols
> in the module, it will be rejected at that point.
>
> Note that the symbol which has
() to convert it to its value:
(((REC->path_dir) == 1) ? "->" : "<-")
So that user space tools, such as perf and trace-cmd, can parse it
correctly.
Reported-by: Luca Ceresoli
Fixes: 6e588a0d839b5 ("ASoC: dapm: Consolidate path trace events")
Signed-off-by:
On Tue, 16 Apr 2024 04:08:46 +0200
Luca Ceresoli wrote:
> Thanks for the insight. I'm definitely trying to fix this based on your
> hint as soon as I get my hand on a board.
I have a patch I forgot to send out. Let me do that now.
-- Steve
On Mon, 18 Mar 2024 16:43:07 +0100
Luca Ceresoli wrote:
> However the arrows are still reversed.
This requires a kernel change. The problem is that the print fmt has:
print fmt: "%c%s %s %s %s %s", (int) REC->path_node && (int) REC->path_connect
? '*' : ' ', __get_str(wname), (((REC->path_dir)
On Sat, 13 Apr 2024 12:53:38 +0200
Peter Zijlstra wrote:
> On Fri, Apr 12, 2024 at 09:37:24AM -0700, Beau Belgrave wrote:
>
> > > Anyway, since we typically run stuff from NMI context, accessing user
> > > data is 'interesting'. As such I would really like to make this work
> > > depend on the c
On Thu, 11 Apr 2024 08:15:05 -0700
Kees Cook wrote:
> This looks good to me. If tracing wants to take it:
>
> Acked-by: Kees Cook
>
> If not, I can take it in my tree if I get a tracing Ack. :)
You can take it.
Acked-by: Steven Rostedt (Google)
-- Steve
From: "Steven Rostedt (Google)"
For a persistent ring buffer that is saved across boots, if function
tracing was performed in the previous boot, it only saves the address of
the functions and uses "%pS" to print their names. But the current boot,
those functions may be in
From: "Steven Rostedt (Google)"
Use the saved text_delta and data_delta of a persistent memory mapped ring
buffer that was saved from a previous boot, and use the delta in the trace
event print output so that strings and functions show up normally.
That is, for an event like tra
From: "Steven Rostedt (Google)"
If an instance is mapped to memory on boot up, create a new file called
"last_boot_info" that will hold information that can be used to properly
parse the raw data in the ring buffer.
It will export the delta of the addresses for text and d
From: "Steven Rostedt (Google)"
When a ring buffer is mapped to a specific address, save the address of a
text function and some data. This will be used to determine the delta
between the last boot and the current boot for pointers to functions as
well as to data.
Signed-off-by: Stev
From: "Steven Rostedt (Google)"
Make sure all the events in each of the sub-buffers that were mapped in a
memory region are valid. This moves the code that walks the buffers for
time-stamp validation out of the CONFIG_RING_BUFFER_VALIDATE_TIME_DELTAS
ifdef block and is used to va
From: "Steven Rostedt (Google)"
Add a test against the ring buffer memory range to see if it has valid
data. The ring_buffer_meta structure is given a new field called
"first_buffer" which holds the address of the first sub-buffer. This is
used to both determine if the other
From: "Steven Rostedt (Google)"
Add a buffer_meta per-cpu file for the trace instance that is mapped to
boot memory. This shows the current meta-data and can be used by user
space tools to record off the current mappings to help reconstruct the
ring buffer after a reboot.
It does not
From: "Steven Rostedt (Google)"
Allow for creating a new instance by passing in an address and size to map
the ring buffer for the instance to.
This will allow features like a pstore memory mapped region to be used for
an tracing instance ring buffer that can be retrieved from one b
From: "Steven Rostedt (Google)"
Populate the ring_buffer_meta array. It holds the pointer to the
head_buffer (next to read), the commit_buffer (next to write) the size of
the sub-buffers, number of sub-buffers and an array that keeps track of
the order of the sub-buffers.
This inform
.
This is no longer a POC as it seems to be working as expected.
This is based on top of Vincent Donnefort's ring buffer user space mapping code:
https://lore.kernel.org/linux-trace-kernel/20240406173649.3210836-1-vdonnef...@google.com/
Enjoy...
Steven Rostedt (Google) (11):
From: "Steven Rostedt (Google)"
In preparation for having the ring buffer mapped to a dedicated location,
which will have the same restrictions as user space memory mapped buffers,
allow it to use the "mapped" field of the ring_buffer_per_cpu structure
without having the
From: "Steven Rostedt (Google)"
In preparation to allowing the trace ring buffer to be allocated in a
range of memory that is persistent across reboots, add
ring_buffer_alloc_range(). It takes a contiguous range of memory and will
split it up evening for the per CPU ring buffers.
If t
On Wed, 10 Apr 2024 13:07:20 -0400
Chuck Lever wrote:
> Well I guess I could test it for you. I'll take it for nfsd v6.9-rc.
Thanks!
-- Steve
Hi Andrew, et.al.
Linus said it's a hard requirement that this code gets an Acked-by (or
Reviewed-by) from the memory sub-maintainers before he will accept it.
He was upset that we faulted in pages one at a time instead of mapping it
in one go:
https://lore.kernel.org/all/CAHk-=wh5wWeib7+kVH
On Sat, 6 Apr 2024 18:36:46 +0100
Vincent Donnefort wrote:
> +int ring_buffer_map(struct trace_buffer *buffer, int cpu,
> + struct vm_area_struct *vma)
> +{
> + struct ring_buffer_per_cpu *cpu_buffer;
> + unsigned long flags, *subbuf_ids;
> + int err = 0;
> +
> +
Hi Vincent,
Thanks for sending this. Nit: Subject should start with a capital:
ring-buffer: Allocate sub-buffers with __GFP_COMP
-- Steve
On Sat, 6 Apr 2024 18:36:45 +0100
Vincent Donnefort wrote:
> In preparation for the ring-buffer memory mapping, allocate compound
> pages for the rin
On Wed, 10 Apr 2024 12:38:53 -0400
Chuck Lever wrote:
> On Wed, Apr 10, 2024 at 12:38:13PM -0400, Steven Rostedt wrote:
> > From: "Steven Rostedt (Google)"
> >
> > The rpcgss_context trace event acceptor field is a dynamically sized
> > string that r
From: "Steven Rostedt (Google)"
The rpcgss_context trace event acceptor field is a dynamically sized
string that records the "data" parameter. But this parameter is also
dependent on the "len" field to determine the size of the data.
It needs to use __string_len()
On Mon, 1 Apr 2024 20:55:43 +0800
Zheng Yejian wrote:
> KASAN reports a bug:
>
> BUG: KASAN: use-after-free in ftrace_location+0x90/0x120
> Read of size 8 at addr 888141d40010 by task insmod/424
> CPU: 8 PID: 424 Comm: insmod Tainted: GW 6.9.0-rc2+ #213
> [...]
> C
On Wed, 10 Apr 2024 08:44:00 +0900
Masami Hiramatsu (Google) wrote:
> Looks good to me.
>
> Acked-by: Masami Hiramatsu (Google)
Thanks.
>
> BTW, isn't this a real bugfix, because the page_touched can be
> bigger than nr_pages without this fix?
Yes, I simply forgot to add the Cc stable.
--
From: "Steven Rostedt (Google)"
The "buffer_percent" logic that is used by the ring buffer splice code to
only wake up the tasks when there's no data after the buffer is filled to
the percentage of the "buffer_percent" file is dependent on three
variables tha
On Mon, 8 Apr 2024 16:58:17 +0200
Michal Koutný wrote:
> @@ -294,7 +295,7 @@ static void __trace_find_cmdline(int pid, char comm[])
> return;
> }
>
> - tpid = pid & (PID_MAX_DEFAULT - 1);
> + tpid = pid % PID_MAP_SIZE;
Does that compile to the same? This is a fast
On Mon, 8 Apr 2024 11:01:54 +0200
Marco Elver wrote:
> Add "new_exec" tracepoint, which is run right after the point of no
> return but before the current task assumes its new exec identity.
>
> Unlike the tracepoint "sched_process_exec", the "new_exec" tracepoint
> runs before flushing the old
On Wed, 3 Apr 2024 11:53:14 -0700
"Paul E. McKenney" wrote:
> @@ -5366,6 +5366,13 @@ static void remove_direct_functions_hash(struct
> ftrace_hash *hash, unsigned long
> }
> }
>
> +static void register_ftrace_direct_cb(struct rcu_head *rhp)
> +{
> + struct ftrace_hash *fhp = contain
On Wed, 3 Apr 2024 15:39:44 +0100
Vincent Donnefort wrote:
> > Do you plan on sending out a v20 series?
>
> Of course, let me spin that this week! Got also few typos to fix in the doc
> and
> I believe an include missing for riscv.
No rush, I'll be on PTO until next Tuesday, and will not get
On Fri, 29 Mar 2024 14:40:55 -0400
Steven Rostedt wrote:
> > +static vm_fault_t tracing_buffers_mmap_fault(struct vm_fault *vmf)
> > +{
> > + return VM_FAULT_SIGBUS;
> > +}
>
> If this is all it does, I don't believe it's needed.
>
> > +
&g
On Tue, 26 Mar 2024 10:08:28 +
Vincent Donnefort wrote:
> Currently, user-space extracts data from the ring-buffer via splice,
> which is handy for storage or network sharing. However, due to splice
> limitations, it is imposible to do real-time analysis without a copy.
>
> A solution for th
On Wed, 27 Mar 2024 16:50:57 +0800
Tio Zhang wrote:
> By doing this, we are able to filter tasks by tgid while we are
> tracing wakeup events by ebpf or other methods.
>
> For example, when we care about tracing a user space process (which has
> uncertain number of LWPs, i.e, pids) to monitor it
On Tue, 26 Mar 2024 15:53:38 +0100
Arnd Bergmann wrote:
> -const char *
> +int
> ftrace_mod_address_lookup(unsigned long addr, unsigned long *size,
> unsigned long *off, char **modname, char *sym)
> {
> struct ftrace_mod_map *mod_map;
> - const char *ret = NULL;
> +
On Tue, 12 Mar 2024 13:42:28 +
Mark Rutland wrote:
> There are ways around that, but they're complicated and/or expensive, e.g.
>
> * Use a sequence of multiple patches, starting with replacing the JALR with an
> exception-generating instruction with a fixup handler, which is sort-of what
On Fri, 22 Mar 2024 00:28:05 +0900
Masami Hiramatsu (Google) wrote:
> On Fri, 22 Mar 2024 00:07:59 +0900
> Masami Hiramatsu (Google) wrote:
>
> > > What would be really useful is if we had a way to expose BTF here.
> > > Something like:
> > >
> > > "%pB::"
> > >
> > > The "%pB" would mean t
On Fri, 22 Mar 2024 00:07:59 +0900
Masami Hiramatsu (Google) wrote:
> > What would be really useful is if we had a way to expose BTF here.
> > Something like:
> >
> > "%pB::"
> >
> > The "%pB" would mean to look up the struct/field offsets and types via BTF,
> > and create the appropriate com
On Tue, 12 Mar 2024 13:42:28 +
Mark Rutland wrote:
> > It would be interesting to see how the per-call performance would
> > improve on x86 with CALL_OPS! ;-)
>
> Heh. ;)
But this would require adding -fpatchable-function-entry on x86, which
would increase the size of text, which could po
On Wed, 20 Mar 2024 21:29:20 +0800
Ye Bin wrote:
> Support print type '%pd' for print dentry's name.
>
The above is not a very detailed change log. A change log should state not
only what the change is doing, but also why.
Having examples of before and after would be useful in the change log.
On Thu, 21 Mar 2024 10:45:00 +0800
Jason Xing wrote:
> The format of the whole patch looks strange... Did you send this patch
> by using 'git send-email' instead of pasting the text and sending?
Yeah, it's uuencoded.
Subject:
=?UTF-8?B?wqBbUEFUQ0ggdjNdIG5ldC9pcHY0OiBhZGQgdHJhY2Vwb2ludCBmb3IgaW
On Wed, 20 Mar 2024 20:46:11 -0400
Waiman Long wrote:
> I have no objection to that. However, there are now 2 function call
> overhead in each iteration if either CONFIG_IRQSOFF_TRACER or
> CONFIG_PREEMPT_TRACER is on. Is it possible to do it with just one
> function call? IOW, make restart_cr
On Wed, 20 Mar 2024 13:15:39 -0400
Mathieu Desnoyers wrote:
> > I would like to introduce restart_critical_timings() and place it in
> > locations that have this behavior.
>
> Is there any way you could move this to need_resched() rather than
> sprinkle those everywhere ?
Because need_resched
From: Steven Rostedt (Google)
I'm debugging some latency issues on a Chromebook and the preemptirqsoff
tracer hit this:
# tracer: preemptirqsoff
#
# preemptirqsoff latency trace v1.1.5 on 5.15.148-21853-g165fd2387469-
On Wed, 20 Mar 2024 13:41:12 +0100
Daniel Bristot de Oliveira wrote:
> On 3/20/24 00:02, Steven Rostedt wrote:
> > On Mon, 18 Mar 2024 18:41:13 +0100
> > Daniel Bristot de Oliveira wrote:
> >
> >> Steven,
> >>
> >> Tracing tooling updates
On Sat, 9 Mar 2024 12:40:51 -0800
Kees Cook wrote:
> The part I'd like to get wired up sanely is having pstore find the
> nvdimm area automatically, but it never quite happened:
> https://lore.kernel.org/lkml/CAGXu5jLtmb3qinZnX3rScUJLUFdf+pRDVPjy=cs4kutw9tl...@mail.gmail.com/
The automatic detec
On Tue, 19 Mar 2024 17:30:41 -0700
Justin Stitt wrote:
> > diff --git a/include/trace/stages/stage6_event_callback.h
> > b/include/trace/stages/stage6_event_callback.h
> > index 83da83a0c14f..56a4eea5a48e 100644
> > --- a/include/trace/stages/stage6_event_callback.h
> > +++ b/include/trace/stag
On Mon, 18 Mar 2024 18:41:13 +0100
Daniel Bristot de Oliveira wrote:
> Steven,
>
> Tracing tooling updates for 6.9
>
> Tracing:
> - Update makefiles for latency-collector and RTLA,
> using tools/build/ makefiles like perf does, inheriting
> its benefits. For example,
On Tue, 19 Mar 2024 09:07:51 -0700
Nathan Chancellor wrote:
> Hi all,
>
> This series fully resolves the new instance of -Wstring-compare from
> within the __assign_str() macro. The first patch resolves a build
> failure with GCC that would be seen with just the second patch applied.
> The secon
From: "Steven Rostedt (Google)"
As __assign_str() no longer uses its "src" parameter, there's a check to
make sure nothing depends on it being different than what was passed to
__string(). It originally just compared the pointer passed to __string()
with the pointer
On Tue, 19 Mar 2024 20:13:52 +0800 (CST)
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 applicatio
On Mon, 18 Mar 2024 16:43:07 +0100
Luca Ceresoli wrote:
> Indeed I was on an older version, apologies.
>
> I upgraded both libtraceevent and trace-cmd to master and applied your
> patch, now the %c is formatted correctly.
>
> However the arrows are still reversed.
>
> Is this what you were exp
On Fri, 15 Mar 2024 19:03:12 +0100
Luca Ceresoli wrote:
> > >
> > > I've come across an unexpected behaviour in the kernel tracing
> > > infrastructure that looks like a bug, or maybe two.
> > >
> > > Cc-ing ASoC maintainers for as it appeared using ASoC traces, but it
> > > does not look ASoC-
On Fri, 15 Mar 2024 17:49:00 +0100
Luca Ceresoli wrote:
> Hello Linux tracing maintainers,
Hi Luca!
>
> I've come across an unexpected behaviour in the kernel tracing
> infrastructure that looks like a bug, or maybe two.
>
> Cc-ing ASoC maintainers for as it appeared using ASoC traces, but it
From: "Steven Rostedt (Google)"
The default behavior of ring_buffer_wait() when passed a NULL "cond"
parameter is to exit the function the first time it is woken up. The
current implementation uses a counter that starts at zero and when it is
greater t
From: "Steven Rostedt (Google)"
The __string() helper macro of the TRACE_EVENT() macro is used to
determine how much of the ring buffer needs to be allocated to fit the
given source string. Some trace events have a string that is dependent on
another variable that could be NULL, an
On Thu, 14 Mar 2024 15:39:28 +0100
Paolo Abeni wrote:
> On Wed, 2024-03-13 at 09:34 -0400, Steven Rostedt wrote:
> > From: "Steven Rostedt (Google)"
> >
> > [
> >Note, I need to take this patch through my tree, so I'm looking for
> > acks.
On Wed, 13 Mar 2024 13:45:50 -0400
Steven Rostedt wrote:
> Let me test to make sure that when src is a string "like this" that it does
> the strcmp(). Otherwise, we may have to always do the strcmp(), which I
> really would like to avoid.
I added the below patch and enabled
On Wed, 13 Mar 2024 09:59:03 -0700
Nathan Chancellor wrote:
> > Reported-by: kernel test robot
> > Closes:
> > https://lore.kernel.org/oe-kbuild-all/202402292111.kidexylu-...@intel.com/
> > Fixes: 433e1d88a3be ("tracing: Add warning if string in __assign_str() does
> > not match __string()")
From: "Steven Rostedt (Google)"
[
Note, I need to take this patch through my tree, so I'm looking for acks.
This causes the build to fail when I add the __assign_str() check, which
I was about to push to Linus, but it breaks allmodconfig due to this error.
]
The
From: "Steven Rostedt (Google)"
While testing libtracefs on the mmapped ring buffer, the test that checks
if missed events are accounted for failed when using the mapped buffer.
This is because the mapped page does not update the missed events that
were dropped because the writer fil
From: "Steven Rostedt (Google)"
The rb_watermark_hit() checks if the amount of data in the ring buffer is
above the percentage level passed in by the "full" variable. If it is, it
returns true.
But it also sets the "shortest_full" field of the cpu_buffer that in
On Wed, 13 Mar 2024 00:38:42 +0900
Masami Hiramatsu (Google) wrote:
> On Tue, 12 Mar 2024 09:19:21 -0400
> Steven Rostedt wrote:
>
> > From: "Steven Rostedt (Google)"
> >
> > The check for knowing if the poll should wait or not is basically the
> >
On Wed, 13 Mar 2024 00:22:10 +0900
Masami Hiramatsu (Google) wrote:
> On Tue, 12 Mar 2024 09:19:20 -0400
> Steven Rostedt wrote:
>
> > From: "Steven Rostedt (Google)"
> >
> > If a reader of the ring buffer is doing a poll, and waiting for the ring
&
From: "Steven Rostedt (Google)"
The WARN_ON() check in __assign_str() to catch where the source variable
to the macro doesn't match the source variable to __string() gives an
error in clang:
>> include/trace/events/sunrpc.h:703:4: warning: result of comparison against a
From: "Steven Rostedt (Google)"
If a reader of the ring buffer is doing a poll, and waiting for the ring
buffer to hit a specific watermark, there could be a case where it gets
into an infinite ping-pong loop.
The poll code has:
rbwork->full_waiters_pending = true;
if
ull wakeups. But since poll uses the same logic for
full wakeups it can just call that function with full set.
Changes since v1:
https://lore.kernel.org/all/20240312115455.666920...@goodmis.org/
- Removed unused 'flags' in ring_buffer_poll_wait() as the spin_lock
is now in rb_watermark_hit(
From: "Steven Rostedt (Google)"
The check for knowing if the poll should wait or not is basically the
exact same logic as rb_watermark_hit(). The only difference is that
rb_watermark_hit() also handles the !full case. But for the full case, the
logic is the same. Just call that
From: "Steven Rostedt (Google)"
When the trace_pipe_raw file is closed, there should be no new readers on
the file descriptor. This is mostly handled with the waking and wait_index
fields of the iterator. But there's still a slight race.
CPU 0
:
https://lore.kernel.org/lkml/20240308183816.676883...@goodmis.org/
- My tests triggered a warning about calling a mutex_lock() after a
prepare_to_wait() that changed the task's state. Convert the affected
mutex over to a spinlock.
Steven Rostedt (Google) (2):
ring-buffer: Use
From: "Steven Rostedt (Google)"
Convert ring_buffer_wait() over to wait_event_interruptible(). The default
condition is to execute the wait loop inside __wait_event() just once.
This does not change the ring_buffer_wait() prototype yet, but
restructures the code so that it can take a
From: "Steven Rostedt (Google)"
When the trace_pipe_raw file is closed, there should be no new readers on
the file descriptor. This is mostly handled with the waking and wait_index
fields of the iterator. But there's still a slight race.
CPU 0
ng a mutex_lock() after a
prepare_to_wait() that changed the task's state. Convert the affected
mutex over to a spinlock.
Steven Rostedt (Google) (2):
ring-buffer: Use wait_event_interruptible() in ring_buffer_wait()
tracing/ring-buffer: Fix wait_on_pipe() race
incl
From: "Steven Rostedt (Google)"
Convert ring_buffer_wait() over to wait_event_interruptible(). The default
condition is to execute the wait loop inside __wait_event() just once.
This does not change the ring_buffer_wait() prototype yet, but
restructures the code so that it can take a
From: "Steven Rostedt (Google)"
The check for knowing if the poll should wait or not is basically the
exact same logic as rb_watermark_hit(). The only difference is that
rb_watermark_hit() also handles the !full case. But for the full case, the
logic is the same. Just call that
From: "Steven Rostedt (Google)"
If a reader of the ring buffer is doing a poll, and waiting for the ring
buffer to hit a specific watermark, there could be a case where it gets
into an infinite ping-pong loop.
The poll code has:
rbwork->full_waiters_pending = true;
if
ull wakeups. But since poll uses the same logic for
full wakeups it can just call that function with full set.
Steven Rostedt (Google) (2):
ring-buffer: Fix full_waiters_pending in poll
ring-buffer: Reuse rb_watermark_hit() for the poll logic
kernel/trace/ring_buffer.c | 30 +++---
1 file changed, 19 insertions(+), 11 deletions(-)
On Fri, 8 Mar 2024 13:41:59 -0800
Linus Torvalds wrote:
> On Fri, 8 Mar 2024 at 13:39, Linus Torvalds
> wrote:
> >
> > So the above "complexity" is *literally* just changing the
> >
> > (new = atomic_read_acquire(&my->seq)) != old
> >
> > condition to
> >
> >
On Sat, 9 Mar 2024 10:27:47 -0800
Kees Cook wrote:
> On Tue, Mar 05, 2024 at 08:59:10PM -0500, Steven Rostedt wrote:
> > This is a way to map a ring buffer instance across reboots.
>
> As mentioned on Fedi, check out the persistent storage subsystem
> (pstore)[1]. It alread
On Fri, 8 Mar 2024 12:39:10 -0800
Linus Torvalds wrote:
> On Fri, 8 Mar 2024 at 10:38, Steven Rostedt wrote:
> >
> > A patch was sent to "fix" the wait_index variable that is used to help with
> > waking of waiters on the ring buffer. The patch was rejecte
From: "Steven Rostedt (Google)"
When the trace_pipe_raw file is closed, there should be no new readers on
the file descriptor. This is mostly handled with the waking and wait_index
fields of the iterator. But there's still a slight race.
CPU 0
From: "Steven Rostedt (Google)"
The ring_buffer_wait() needs to be broken into three functions for proper
synchronization from the context of the callers:
ring_buffer_prepare_to_wait()
ring_buffer_wait()
ring_buffer_finish_wait()
To simplify the process, pull out the logic f
From: "Steven Rostedt (Google)"
When the tracing_pipe_raw file is closed, if there are readers still
blocked on it, they need to be woken up. Currently a wait_index is used.
When the readers need to be woken, the index is updated and they are all
woken up.
But there is a race where a
401 - 500 of 8096 matches
Mail list logo