On Tue, 26 Sep 2023 11:38:14 +0100
Christian Loehle wrote:
> >> @@ -191,7 +191,7 @@ of ftrace. Here is a list of some of the key files:
> >> A few extra pages may be allocated to accommodate buffer management
> >> meta-data. If the last page allocated has room for more bytes
> >>
On Tue, 5 Dec 2023 09:25:17 +0530
Bhaskar Chowdhury wrote:
> Thought this might help people to see the entire source tree on browser and
> explore.
>
> Signed-off-by: Bhaskar Chowdhury
> ---
> Documentation/trace/ftrace.rst | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/Documenta
From: "Steven Rostedt (Google)"
When the buffer_percent file was added to the kernel, the documentation
should have been updated to document what that file does.
Fixes: 03329f9939781 ("tracing: Add tracefs file buffer_percentage")
Signed-off-by: Steven Rostedt (Google)
---
Jon,
I was about to ask if you can take this through your tree, but then I did a
self edit :-p
On Tue, 26 Dec 2023 12:35:25 -0500
Steven Rostedt wrote:
> From: "Steven Rostedt (Google)"
>
> When the buffer_percent file was added to the kernel, the documentation
> sh
From: "Steven Rostedt (Google)"
When the buffer_percent file was added to the kernel, the documentation
should have been updated to document what that file does.
Fixes: 03329f9939781 ("tracing: Add tracefs file buffer_percentage")
Signed-off-by: Steven Rostedt (Google)
From: "Steven Rostedt (Google)"
When the buffer_percent file was added to the kernel, the documentation
should have been updated to document what that file does.
Acked-by: Masami Hiramatsu (Google)
Fixes: 03329f9939781 ("tracing: Add tracefs file buffer_percentage")
S
On Wed, 03 Jan 2024 14:15:30 -0700
Jonathan Corbet wrote:
> Steven Rostedt writes:
>
> > From: "Steven Rostedt (Google)"
> >
> > When the buffer_percent file was added to the kernel, the documentation
> > should have been updated to document what that
On Thu, 4 Jan 2024 04:39:45 +
Al Viro wrote:
> On Wed, Jan 03, 2024 at 09:25:06PM -0500, Steven Rostedt wrote:
> > On Thu, 4 Jan 2024 01:48:37 +
> > Al Viro wrote:
> >
> > > On Wed, Jan 03, 2024 at 08:32:46PM -0500, Steven Rostedt wrote:
> > >
On Thu, 4 Jan 2024 18:25:02 +
Al Viro wrote:
> On Thu, Jan 04, 2024 at 10:05:44AM -0500, Steven Rostedt wrote:
>
> > This is the "tribal knowledge" I'm talking about. I really didn't know how
> > the root dentry parent worked. I guess that makes
On Thu, 4 Jan 2024 18:25:02 +
Al Viro wrote:
> Unfortunately, the terms are clumsy as hell - POSIX ends up with
> "file descriptor" (for numbers) vs. "file description" (for IO
> channels), which is hard to distinguish when reading and just
> as hard to distinguish when listening. "Opened fi
On Fri, 19 Jan 2024 16:08:24 +0800
Huang Yiwei wrote:
> - ftrace_dump_on_oops[=orig_cpu]
> + ftrace_dump_on_oops[=orig_cpu | =]
I wonder if we should have it be:
ftrace_dump_on_oops[=orig_cpu | = | =:orig_cpu ]
Then last would be to only print out a specific CPU trace of the gi
On Tue, 23 Jan 2024 18:23:58 +0800
Huang Yiwei wrote:
> > And if we really want to be fancy!
> >
> > ftrace_dump_on_opps[=orig_cpu | = | =orig_cpu:
> > ][, | ,:orig_cpu]
> >
> Yeah, I agree to make the parameter more flexible.
>
> "=orig_cpu:" means to dump global and another instance?
On Tue, 23 Jan 2024 09:49:00 -0500
Steven Rostedt wrote:
> On Tue, 23 Jan 2024 18:23:58 +0800
> Huang Yiwei wrote:
>
> > > And if we really want to be fancy!
> > >
> > > ftrace_dump_on_opps[=orig_cpu | = | =orig_cpu:
> > > ][, | ,:orig_
On Wed, 7 Feb 2024 05:24:58 -0500
Joel Fernandes wrote:
> Btw, hopefully the "trace off on warning" and related boot parameters also
> apply
> to instances, I haven't personally checked but I often couple those with the
> dump-on-oops ones.
Currently they do not. It would require an updated int
On Thu, 8 Feb 2024 04:26:30 -0500
Joel Fernandes wrote:
> > And for this patchset, shall I fix the typo and resend again? Thanks.
>
> That is fine with me but it is up to tracing maintainers. ;-)
The rest of the patch looks good to me. Please send a v5 with the typo
fix and I'll try to get it
On Thu, 8 Feb 2024 21:18:14 +0800
Huang Yiwei wrote:
> Currently ftrace only dumps the global trace buffer on an OOPs. For
> debugging a production usecase, instance trace will be helpful to
> check specific problems since global trace buffer may be used for
> other purposes.
>
> This patch exte
On Wed, 21 Feb 2024 01:59:53 +
Dmitry Safonov wrote:
> On 2/20/24 21:00, Dmitry Safonov wrote:
> [..]
> > diff --git a/Documentation/trace/ftrace.rst b/Documentation/trace/ftrace.rst
> > index 7e7b8ec17934..c79a6bcef3c9 100644
> > --- a/Documentation/trace/ftrace.rst
> > +++ b/Documentation/t
On Thu, 8 Feb 2024 21:18:14 +0800
Huang Yiwei wrote:
> Currently ftrace only dumps the global trace buffer on an OOPs. For
> debugging a production usecase, instance trace will be helpful to
> check specific problems since global trace buffer may be used for
> other purposes.
>
> This patch exte
On Mon, 26 Feb 2024 08:51:58 +0900
Masami Hiramatsu (Google) wrote:
> On Thu, 8 Feb 2024 21:18:14 +0800
> Huang Yiwei wrote:
>
> > Currently ftrace only dumps the global trace buffer on an OOPs. For
> > debugging a production usecase, instance trace will be helpful to
> > check specific problem
On Thu, 8 Feb 2024 21:18:14 +0800
Huang Yiwei wrote:
> Currently ftrace only dumps the global trace buffer on an OOPs. For
> debugging a production usecase, instance trace will be helpful to
> check specific problems since global trace buffer may be used for
> other purposes.
>
> This patch exte
On Thu, 29 Feb 2024 17:11:49 +0800
Huang Yiwei wrote:
> > And you can add here as well:
> >
> >
> > ftrace_dump_on_oops[=[<0|1|2|orig_cpu>,][[=<1|2|orig_cpu>][,...]]
> >
> >
> > Thanks,
> >
> > --Steve
> >
> The explanation is below, I think it's correct?
> - "ftrace_dump_on_oops," m
On Thu, 28 Dec 2023 18:51:46 +0800
Yi-De Wu wrote:
> Add tracepoints for hypervisor calls and VCPU exit reasons in GenieZone
> driver. It aids performance debugging by providing more information
> about hypervisor operations and VCPU behavior.
>
> Command Usage:
> echo geniezone:* >> /sys/kernel
On Thu, 25 Jan 2024 06:50:21 +
Sicheng Liu wrote:
Sorry for the late reply, this got missed in a flood of other patches, not
to mention it was sent when I was very behind and probably just skipped it
for "todo later". Well, it's later ;-)
> Stack filter can be used to filter event call stack
On Thu, 14 Mar 2024 15:41:36 +0100
Ali Zahraee wrote:
> The format of the sched_wakeup event is used as an example in the
> documentation. But the given format is obsolete. This patch updates the
> format in the example to match the current format of this event.
>
> Signed-off-by: Ali Zahraee
>
On Tue, 18 Jun 2024 12:42:11 -0400
Konstantin Ryabitsev wrote:
>
> diff --git a/Documentation/process/maintainer-tip.rst
> b/Documentation/process/maintainer-tip.rst
> index 64739968afa6..57ffa553c21e 100644
> --- a/Documentation/process/maintainer-tip.rst
> +++ b/Documentation/process/maintain
that?
Whenever I do the second one, it has nothing to do with the tag, but
what I have done to the patch/commit.
Signed-off-by: Random Developer
[ Fixed formatting ]
Signed-off-by: Steven Rostedt (Google)
That is, if I do any modification of the original submission, I
document it this
From: "Steven Rostedt (Google)"
To prevent conflicts with other ioctl numbers to allow strace to have an
idea of what is happening, add the rang of ioctls for the trace buffer
mapping from _IO("T", 0x1) to the range of "R" 0x20 - 0x2F.
Link:
https://lore
On Tue, 2 Jul 2024 15:38:10 -0400
Mathieu Desnoyers wrote:
> On 2024-07-02 15:33, Steven Rostedt wrote:
> > From: "Steven Rostedt (Google)"
> >
> > To prevent conflicts with other ioctl numbers to allow strace to have an
> > idea of what is happening,
On Wed, 19 Jun 2024 14:24:05 -0400
Konstantin Ryabitsev wrote:
> - drops the recommendation to use /r/ subpaths in lore.kernel.org links
> (it has been unnecessary for a number of years)
> - adds some detail on how to reference specific Link trailers from
> inside the commit message
>
> Some of
On Sat, 27 Jul 2024 19:45:54 -0300
Marcos Paulo de Souza wrote:
> Since commit d19ad0775dcd ("ftrace: Have the callbacks receive a struct
> ftrace_regs instead of pt_regs") the callback function receives a
> ftrace_regs argument, and not a pt_regs anymore. Change the
> documentation to reflect th
x92920008,
> GZVM_EXIT_SHUTDOWN = 0x92920009,
> GZVM_EXIT_GZ = 0x9292000a,
> };
>
> Signed-off-by: Yi-De Wu
> Signed-off-by: Liju Chen
From a tracing POV, I don't see any issues with this patch.
Reviewed-by: Steven Rostedt (Google)
-- Steve
From: Steven Rostedt
For some reason my finger always hits the 'r' after typing "reserve".
Fix the typo in the Documentation example.
Fixes: d9d814eebb1ae ("pstore/ramoops: Add ramoops.mem_name= command line
option")
Signed-off-by: Steven Rostedt (Google)
---
No
I figured it's about time
to start adding it to the Documentation directory. I created a debugging.rst
file in Documentation/trace, that is the start of adding techniques in using
tracing to debug your kernel.
[1] https://lore.kernel.org/all/20240821160316.02c03...@gandalf.local.home/
These patches are ba
From: Steven Rostedt
Currently, trace_printk() just goes to the top level ring buffer. But
there may be times that it should go to one of the instances created by
the kernel command line.
Add a new trace_instance flag: traceprintk (also can use "printk" or
"trace_printk&quo
From: Steven Rostedt
Add a "flags" delimiter (^) to the "trace_instance" kernel command line
parameter, and add the "traceoff" flag. The format is:
trace_instance=[^[^]][@][,]
The code allows for more than one flag to be added, but currently only
"traceo
From: Steven Rostedt
If the persistent boot mapped ring buffer is used for trace_printk(),
force it to not use the binary versions. trace_printk() by default uses
bin_printf() that only saves the pointer to the format and not the format
itself inside the ring buffer. But for a persistent buffer
From: Steven Rostedt
Add a new document Documentation/trace/debugging.rst that will hold
various ways to debug tracing.
This initial version mentions trace_printk and how to create persistent
buffers that can last across bootups.
Signed-off-by: Steven Rostedt (Google)
---
.../admin-guide
From: Steven Rostedt
Add a option "trace_printk_dest" that will make the tracing instance the
location that trace_printk() will go to. This is useful if the
trace_printk or one of the top level tracers is too noisy and there's a
need to separate the two. Then an instance can
On Tue, 16 Jul 2019 16:20:05 +0200
Peter Zijlstra wrote:
> On Tue, Jul 16, 2019 at 10:08:18PM +0800, Changbin Du wrote:
> > On Mon, Jul 15, 2019 at 12:12:31PM +0200, Peter Zijlstra wrote:
>
> > > Alternatively, we can have recordmcount (or objtool) mark all functions
> > > with a return value
On Mon, 12 Aug 2019 09:03:10 -0400
Joel Fernandes wrote:
> > > drivers/base/core.c | 6 +-
> > > 1 file changed, 5 insertions(+), 1 deletion(-)
> > >
> > > diff --git a/drivers/base/core.c b/drivers/base/core.c
> > > index 32cf83d1c744..fe25cf690562 100644
> > > --- a/drivers/base/core.c
On Mon, 12 Aug 2019 16:01:25 -0400
Joel Fernandes wrote:
> > some/header/file.h:
> >
> > #ifdef CONFIG_DEBUG_LOCK_ALLOC
> > # define CHECK_DEVICE_LINKS_READ_LOCK_HELD()
> > WARN_ON_ONCE(!defice_links_read_lock_held())
> > #else
> > # define CHECK_DEVICE_LINKS_READ_LOCK_HELD() do { } while (0)
>
On Sun, 25 Aug 2019 21:23:20 +0800
Changbin Du wrote:
> Move ftrace tools to its own directory. We will add another tool later.
>
> Cc: John F. Reiser
> Signed-off-by: Changbin Du
> ---
> scripts/.gitignore | 1 -
> scripts/Makefile | 2 +-
> scripts/Ma
On Fri, 23 Aug 2019 00:48:23 +0100
Peter Wu wrote:
> The current text could mislead the user into believing that only read()
> disables tracing. Clarify that any open() call that requests read access
> disables tracing.
>
> Link:
> https://lkml.kernel.org/r/CAADnVQ+hU6QOC_dPmpjnuv=9g4SQEeaMEMqX
VQ+hU6QOC_dPmpjnuv=9g4SQEeaMEMqXOS2WpMj=q=l...@mail.gmail.com
> Signed-off-by: Peter Wu
Acked-by: Steven Rostedt (VMware)
Jon care to take this in your tree?
Thanks!
-- Steve
> ---
> v2: fix typo s/trace_file/trace_pipe/ (spotted by Steven)
> ---
> Documentation/trace/ftrace.rst | 13 +
nandes (Google)
> Cc: Steven Rostedt
Perhaps it should have been:
Suggested-by: Steven Rostedt (VMware)
As the wording is what I suggested ;-)
-- Steve
> ---
> v2: fix description using words suggested by Steven Rostedt
>
> Documentation/admin-guide/kernel-parameter
On Tue, 21 May 2019 21:30:00 +0900
Masanari Iida wrote:
> This patch fixes some spelling typos in histogram.rst
Acked-by: Steven Rostedt (VMware)
Jon,
Care to take this in your tree?
-- Steve
>
> Signed-off-by: Masanari Iida
> ---
On Tue, 21 May 2019 17:42:28 +0800
Zhenzhong Duan wrote:
> On 2019/5/15 3:21, Steven Rostedt wrote:
> > On Sun, 12 May 2019 11:35:27 +0800
> > Zhenzhong Duan wrote:
> >
> >> The default behavior of hardlockup depends on the config of
> >> CONFIG_BOOTPA
On Tue, 21 May 2019 16:56:16 +0900
Masami Hiramatsu wrote:
> Note that 'trace_event=' option enables trace event at very early
> timing, but the events added by 'kprobe_event=' are enabled right
> before enabling device drivers at this point. It is enough for
> tracing device driver initializatio
t; kernel/power/power.h | 2 +-
> kernel/sched/core.c | 2 +-
> kernel/trace/trace.h | 14 +++---
Acked-by: Steven Rostedt (VMware)
-- Steve
> 5 files changed, 11 insertions(+), 11 deletions(-)
ggested-by: Steven Rostedt (VMware)
> Signed-off-by: Zhenzhong Duan
> Reviewed-by: Joel Fernandes (Google)
> Acked-by: Ingo Molnar
> Acked-by: Steven Rostedt (VMware)
> Cc: Thomas Gleixner
> Cc: Kees Cook
> Cc: Greg Kroah-Hartman
> Cc: linux-doc@vger.kernel.org
> -
On Fri, 24 May 2019 19:49:28 -0400
"Joel Fernandes (Google)" wrote:
> The series removes users of the following APIs, and the APIs themselves, since
> the regular non - _notrace variants don't do any tracing anyway.
> * hlist_for_each_entry_rcu_notrace
> * rcu_dereference_raw_notrace
>
I gues
On Sat, 25 May 2019 04:14:44 -0400
Joel Fernandes wrote:
> > I guess the difference between the _raw_notrace and just _raw variants
> > is that _notrace ones do a rcu_check_sparse(). Don't we want to keep
> > that check?
>
> This is true.
>
> Since the users of _raw_notrace are very few, is i
On Tue, 28 May 2019 14:23:43 +0200
Anders Roxell wrote:
> On Wed, 22 May 2019 at 10:32, Masami Hiramatsu wrote:
> >
> > Add kprobe_event= boot parameter to define kprobe events
> > at boot time.
> > The definition syntax is similar to tracefs/kprobe_events
> > interface, but use ',' and ';' inst
On Wed, 29 May 2019 11:31:23 +0200
Thomas Preisner wrote:
> The "oneshot" tracer records every address (ip, parent_ip) exactly once.
> As a result, "oneshot" can be used to efficiently create kernel function
> coverage/usage reports such as in undertaker-tailor[0].
>
> In order to provide this f
On Wed, 5 Jun 2019 16:30:10 -0400
"George G. Davis" wrote:
> Fix a couple of s/poped/popped/ typos.
>
> Cc: Jiri Kosina
> Signed-off-by: George G. Davis
Acked-by: Steven Rostedt (VMware)
-- Steve
> ---
> Documentation/arm/mem_alignment | 2 +-
> arch
On Tue, 18 Jun 2019 15:51:18 -0300
Mauro Carvalho Chehab wrote:
> Sphinx expects a blank line after a literal block markup.
>
> Signed-off-by: Mauro Carvalho Chehab
For the two tracing patches (1 and 2).
Acked-by: Steven Rostedt (VMware)
-- Steve
> ---
> Docu
On Thu, 27 Jun 2019 08:34:43 -0600
Jonathan Corbet wrote:
> On Wed, 26 Jun 2019 15:07:01 -0500
> Jiunn Chang wrote:
>
> > RCU basic concepts reST markup.
> >
> > Signed-off-by: Jiunn Chang
> > Reviewed-by: Joel Fernandes (Google)
>
> So this is a little detail but ... your signoff should
On Thu, 27 Jun 2019 15:10:45 -0700
"Paul E. McKenney" wrote:
> On Thu, Jun 27, 2019 at 04:01:35PM -0600, Shuah Khan wrote:
> > On 6/27/19 3:01 PM, Jiunn Chang wrote:
> > >The UP.rst file calls for locks acquired within RCU callback functions
> > >to use _irq variants (spin_lock_irqsave() or sim
"[PATCH v1]" I like your confidence, or lack of, that there isn't going
to be a v2 or v3 ;-)
Masami, what do you think of this?
-- Steve
On Tue, 28 Mar 2017 15:52:22 +0200
Alban Crequy wrote:
> When a kretprobe is installed on a kernel function, there is a maximum
> limit of how many calls i
On Wed, 29 Mar 2017 00:23:35 +0900
Masami Hiramatsu wrote:
> > @@ -598,8 +601,10 @@ static int create_trace_kprobe(int argc, char **argv)
> > {
> > /*
> > * Argument syntax:
> > -* - Add kprobe: p[:[GRP/]EVENT] [MOD:]KSYM[+OFFS]|KADDR [FETCHARGS]
> > -* - Add kretprobe: r[:[GR
(test bug): 0
>
> BugLink: https://github.com/iovisor/bcc/issues/1072
> Signed-off-by: Alban Crequy
>
> ---
>
> Changes since v1:
> - Remove "(*)" from documentation. (Review from Masami Hiramatsu)
> - Fix support for "r100" without the event name
On Tue, 4 Apr 2017 20:24:59 +0900
Masami Hiramatsu wrote:
> On Mon, 3 Apr 2017 12:36:22 +0200
> Alban Crequy wrote:
>
> > From: Alban Crequy
> >
> > When a kretprobe is installed on a kernel function, there is a maximum
> > limit of how many calls in parallel it can catch (aka "maxactive").
ck")
> and priority list 'plist' changed to rbtree. So the documents are far
> late of real code.
Yes it needs some loving.
>
> So update it to latest code and make it meaningful.
>
> Signed-off-by: Alex Shi
> Cc: Steven Rostedt
> Cc: Sebastian Siewior
>
On Thu, 13 Apr 2017 22:02:52 +0800
Alex Shi wrote:
> The rt-mutex documents didn't gotten meaningful update from its first
> version. Even after owner's pending bit was removed in commit 8161239a8bcc
> ("rtmutex: Simplify PI algorithm and make highest prio task get lock")
> and priority list 'pli
On Fri, 14 Apr 2017 16:52:11 +0800
Alex Shi wrote:
> >> -Plist
> >> --
> >> -
> >> -Before I go further and talk about how the PI chain is stored through
> >> lists
> >> -on both mutexes and processes, I'll explain the plist. This is similar to
> >> -the struct list_head functionality that
On Tue, 20 Jun 2017 08:22:52 +0800
Alex Shi wrote:
> On 05/25/2017 01:26 PM, Alex Shi wrote:
> >
> > Author: Steven Rostedt
> > +Updated: Alex Shi - 5/20/2017
> >
> > Reviewers: Ingo Molnar, Thomas Gleixner, Thomas Duetsch, and Randy Dunlap
>
prio task get lock")
> and priority list 'plist' changed to rbtree. And Peter Zijlstra did some
> clean up and fix for deadline task changes on tip tree.
>
> So update it to latest code and make it meaningful.
>
> Signed-off-by: Alex Shi
> Cc: Steven Rostedt
> Cc
ers, since you are author already. :)
Actually, I probably should be. Comment below.
>
>
> Best regards
> Alex
>
>
> On 07/04/2017 02:49 AM, Steven Rostedt wrote:
> >> +In the first case, the task will try again to acquire the lock. If it
> >
> > H
riginal
entry of the rtmutex.c (23f78d4a0). Looking at even that version, I
don't see the purpose of adjusting the task prio here. It is done
before anything changes in the task.
Reviewed-by: Steven Rostedt (VMware)
-- Steve
> > waiter->task = task;
> > waiter-
allback
> can be called outside the protective scope of RCU.
>
> -The ftrace infrastructure has some protections agains recursions and RCU
> +The ftrace infrastructure has some protections against recursions and RCU
> but one must still be very careful how they use the callbacks.
>
noisy build, but the 'not
> included' WARNING will be stay:
>
> - trace/ftrace-uses.rst: WARNING: document isn't included in any toctree
>
> Signed-off-by: Markus Heiser
Acked-by: Steven Rostedt (VMware)
-- Steve
--
To unsubscribe from this list: send t
On Fri, 16 Feb 2018 11:12:18 +0800
changbin...@intel.com wrote:
> From: Changbin Du
>
> Signed-off-by: Changbin Du
> ---
> .../trace/{ftrace-design.txt => ftrace-design.rst} | 248
> +++--
> Documentation/trace/index.rst | 2 +
> 2 files changed, 137 ins
On Fri, 16 Feb 2018 17:07:26 +0800
"Du, Changbin" wrote:
> > This document is out of date, and I rather have it updated before we
> > make it more "available" elsewhere.
> >
> Got you. I plan to convert below docs. Are they out of date, too?
>
> events-msr.txt, events.txt, mmiotrace.txt, stm.
On Fri, 16 Feb 2018 05:49:52 -0700
Jonathan Corbet wrote:
> On Thu, 15 Feb 2018 22:57:05 -0500
> Steven Rostedt wrote:
>
> > This document is out of date, and I rather have it updated before we
> > make it more "available" elsewhere.
>
> Imagine t
On Tue, 20 Feb 2018 21:27:00 +0800
"Du, Changbin" wrote:
> > > @@ -0,0 +1,3332 @@
> > > +
> > > +ftrace - Function Tracer
> > > +
> > > +
> > > +Copyright 2008 Red Hat Inc.
> >
On Tue, 27 Feb 2018 17:34:22 +0800
"Du, Changbin" wrote:
> Hello Steven and Corbet,
> Ten days past, will you accept this serias? Thank you!
>
> On Sat, Feb 17, 2018 at 01:39:33PM +0800, changbin...@intel.com wrote:
> > From: Changbin Du
> >
> > Hi All,
> > The linux tracers are so useful that
On Wed, 7 Mar 2018 10:46:49 -0700
Jonathan Corbet wrote:
> Anyway, with that, the patch series is applied. Thanks for helping to
> improve the docs, and my apologies for taking so long to get to this.
Thanks for doing this Jon. I'm going to have to find some time to
revisit all the documentatio
On Tue, 13 Mar 2018 18:26:00 +0530
Ravi Bangoria wrote:
> include/linux/uprobes.h | 2 +
> kernel/events/uprobes.c | 6 ++
> kernel/trace/trace_uprobe.c | 172
> +++-
I'm currently traveling, but I'll try to look at it in a week or two.
-- St
On Tue, 13 Mar 2018 18:25:56 +0530
Ravi Bangoria wrote:
> No functionality changes.
Please add a detailed explanation why this patch is needed. All commits
should be self sufficient and stand on their own. If I were to come up
to this patch via a git blame, I would be clueless to why it was done
On Tue, 13 Mar 2018 18:25:57 +0530
Ravi Bangoria wrote:
> No functionality changes.
Again, please add an explanation to why this patch is done.
-- Steve
>
> Signed-off-by: Ravi Bangoria
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord
On Tue, 13 Mar 2018 18:25:59 +0530
Ravi Bangoria wrote:
> These exported data structure and functions will be used by other
> files in later patches.
I'm reluctantly OK with the above.
>
> No functionality changes.
Please remove this line. There are functionality changes. Turning a
static inl
On Tue, 13 Mar 2018 18:25:58 +0530
Ravi Bangoria wrote:
> -static inline struct map_info *free_map_info(struct map_info *info)
> +static inline struct uprobe_map_info *
> +uprobe_free_map_info(struct uprobe_map_info *info)
> {
> - struct map_info *next = info->next;
> + struct uprobe_map_
On Tue, 13 Mar 2018 18:26:00 +0530
Ravi Bangoria wrote:
> +static void sdt_increment_ref_ctr(struct trace_uprobe *tu)
> +{
> + struct uprobe_map_info *info;
> + struct vm_area_struct *vma;
> + unsigned long vaddr;
> +
> + uprobe_start_dup_mmap();
Please add a comment here that th
l unabridged graph recursion.
I didn't realize that the documentation doesn't state this. I mention
it in all my talks that talk about function and function_graph tracer
and set_ftrace_filter.
>
> Signed-off-by: Steffen Maier
> Cc: Steven Rostedt
> Cc: Ingo Molnar
>
l unabridged graph recursion.
>
> Signed-off-by: Steffen Maier
> Cc: Steven Rostedt
Looks good.
Reviewed-by: Steven Rostedt (VMware)
> Cc: Ingo Molnar
> Cc: Jonathan Corbet
Jon, you want to take it in your tree?
-- Steve
> Cc: linux-doc@vger.kernel.org
> ---
>
>
On Fri, 30 Nov 2018 20:39:01 +
Abuse wrote:
> On Friday, 30 November 2018 20:35:07 GMT David Miller wrote:
> > From: Jens Axboe
> > Date: Fri, 30 Nov 2018 13:12:26 -0700
> >
> > > On 11/30/18 12:56 PM, Davidlohr Bueso wrote:
> > >> On Fri, 30 Nov 2018, Kees Cook wrote:
> > >>
> > >>>
On Fri, 30 Nov 2018 12:55:21 -0800
Jarkko Sakkinen wrote:
> On Fri, Nov 30, 2018 at 11:56:52AM -0800, Davidlohr Bueso wrote:
> > On Fri, 30 Nov 2018, Kees Cook wrote:
> >
> > > On Fri, Nov 30, 2018 at 11:27 AM Jarkko Sakkinen
> > > wrote:
> > > >
> > > > In order to comply with the CoC, re
On Sat, 12 Jan 2019 12:05:33 +0800
Changbin Du wrote:
> Hi Steven, Have you checked this serias yet? :)
>
Not yet, I'll try to do it today.
-- Steve
On Sat, 12 Jan 2019 14:57:01 +0800
Changbin Du wrote:
> This patch adds a new trace option 'funcgraph-retval' and is disabled by
> default. When this option is enabled, fgraph tracer will show the return
> value of each function. This is useful to find/analyze a original error
> source in a call
On Tue, 1 Jan 2019 23:46:13 +0800
Changbin Du wrote:
> This align the behavior of wakeup tracers with irqsoff latency tracer
> that we record stacktrace at the beginning and end of waking up. The
> stacktrace shows us what is happening in the kernel.
OK, so I've applied (locally) all of the pat
On Thu, 17 Jan 2019 00:02:49 +0800
Changbin Du wrote:
> This align the behavior of wakeup tracers with irqsoff latency tracer
> that we record stacktrace at the beginning and end of waking up. The
> stacktrace shows us what is happening in the kernel.
>
> Signed-off-by: Changbin Du
I've applie
On Thu, 7 Feb 2019 16:11:01 -0500
"Joel Fernandes (Google)" wrote:
> +
> +# Build a list of in-kernel headers for building kernel modules
> +# Any other files will be stored in IKH_EXTRA variable.
> +ikh_file_list := include/
> +ikh_file_list += arch/$(ARCH)/Makefile
> +ikh_file_list += arch/$(A
On Thu, 7 Feb 2019 18:39:02 -0500
Joel Fernandes wrote:
> > > +
> > > +spath="$(dirname "$(readlink -f "$0")")"
> > > +
> > > +rm -rf $1.tmp
> > > +mkdir $1.tmp
> > > +
> > > +for f in "${@:2}";
> > > + do find "$f" ! -name "*.c" ! -name "*.o" ! -name "*.cmd" ! -name ".*";
> >
> > I wonder if i
On Thu, 28 Feb 2019 16:45:13 +0100
Greg KH wrote:
> On Thu, Feb 28, 2019 at 10:37:41AM -0500, Joel Fernandes wrote:
> > In any case, it is not practical to provide headers for every kernel
> > version on
> > the system image and maintain them, it will take up too much space and has
> > to
> > b
Thomas Gleixner, Thomas Duetsch, and Randy
> >>> Dunlap
> >>> +Original Reviewers: Ingo Molnar, Thomas Gleixner, Thomas Duetsch, and
> >>> + Randy Dunlap
> >>> +Update (7/6/2017) Reviewers: Steven Rostedt and Sebastian Siewior
> >>
On Thu, 24 Aug 2017 13:39:14 -0600
Jonathan Corbet wrote:
> On Tue, 15 Aug 2017 12:00:25 -0400
> Steven Rostedt wrote:
>
> > > Sorry for skip you here. Yes, if you like to pick them, please go ahead!
> >
> > Agreed, Jon's tree is the best path.
>
On Fri, 25 Aug 2017 10:46:21 -0400
Prarit Bhargava wrote:
> np. I'm going to copy the code for
>
> u64 notrace ktime_get_boot_fast_ns(void)
>
> but I'm unsure why the function is marked "notrace", and if
> __ktime_get_real_fast_ns_unsafe() must be as well? I don't see anything in
> the
> gi
On Fri, 3 Nov 2017 13:00:05 +0100
Petr Mladek wrote:
> On Thu 2017-09-28 17:43:55, Calvin Owens wrote:
> > This patch introduces a new per-console loglevel setting, and changes
> > console_unlock() to use max(global_level, per_console_level) when
> > deciding whether or not to emit a given log me
1 - 100 of 133 matches
Mail list logo
