On Thu, 20 Aug 2020 23:04:59 -0400
Steven Rostedt wrote:
> On Thu, 20 Aug 2020 19:49:59 -0700
> Joe Perches wrote:
>
> > Perhaps make trace_printk dependent on #define DEBUG?
>
> This is basically what Nicolas's patch series does in this very patch!
>
> And
On Thu, 20 Aug 2020 19:49:59 -0700
Joe Perches wrote:
> Perhaps make trace_printk dependent on #define DEBUG?
This is basically what Nicolas's patch series does in this very patch!
And no, I hate it. We are currently discussing ways of not having to
modify the config in order to allow trace_pri
On Fri, 21 Aug 2020 10:39:02 +0800
Nicolas Boichat wrote:
> I'm not sure how that helps? I mean, the use case you have in mind is
> somebody reusing a distro/random config and not being able to use
> trace_printk, right? If that config has CONFIG_DISABLE_TRACE_PRINTK=y,
> then the developer will
On Thu, 20 Aug 2020 19:36:19 -0700
Joe Perches wrote:
> On Thu, 2020-08-20 at 21:57 -0400, Steven Rostedt wrote:
> > On Fri, 21 Aug 2020 09:39:19 +0800
> > Nicolas Boichat wrote:
> []
> > > Some other approaches/ideas:
> > > 1. Filter all lkml message
On Fri, 21 Aug 2020 09:39:19 +0800
Nicolas Boichat wrote:
> On Fri, Aug 21, 2020 at 8:36 AM Steven Rostedt wrote:
> >
> > On Fri, 21 Aug 2020 08:13:00 +0800
> > Nicolas Boichat wrote:
> >
> > > On Thu, Aug 20, 2020 at 10:23 PM Steven Rostedt
> >
On Fri, 21 Aug 2020 08:13:00 +0800
Nicolas Boichat wrote:
> On Thu, Aug 20, 2020 at 10:23 PM Steven Rostedt wrote:
> >
> > On Thu, 20 Aug 2020 17:14:12 +0800
> > Nicolas Boichat wrote:
> >
> > > Technically, we could only initialize the trace_printk
On Thu, 20 Aug 2020 17:14:12 +0800
Nicolas Boichat wrote:
> Technically, we could only initialize the trace_printk buffers
> when the print env is switched, to avoid the build error and
> unconditional boot-time warning, but I assume this printing
> framework will eventually get removed when the
On Fri, 31 Jul 2020 20:15:38 +0200
pet...@infradead.org wrote:
> On Thu, Jul 30, 2020 at 09:35:43PM +0800, Dongdong Yang wrote:
> > diff --git a/kernel/sched/cpufreq_schedutil.c
> > b/kernel/sched/cpufreq_schedutil.c
> > index 7fbaee2..7bc3429 100644
> > --- a/kernel/sched/cpufreq_schedutil.c
> >
On Thu, 30 Jul 2020 21:35:43 +0800
Dongdong Yang wrote:
I'll let others decide the value of this, but I have some comments.
>
> Signed-off-by: Dongdong Yang
> Signed-off-by: Jun Tao
> Signed-off-by: Qiwu Huang
> Signed-off-by: Geliang Tang
> Signed-off-by: Peng Wang
Why all the signed-off
On Mon, 22 Jul 2019 23:33:53 +0800
Gao Xiang wrote:
> Hi Steven,
>
> On 2019/7/22 ????10:40, Steven Rostedt wrote:
> >>> and I'm not sure Al could accept __fdget conversion (I just wanted to
> >>> give a example then...)
> >>>
> >>
On Mon, 22 Jul 2019 09:16:22 +0300
Amir Goldstein wrote:
> CC kernel/trace maintainers for RB_PAGE_HEAD/RB_PAGE_UPDATE
> and kernel/locking maintainers for RT_MUTEX_HAS_WAITERS
Interesting.
>
> > (Is there some use scenerios in overlayfs and fanotify?...)
>
> We had one in overlayfs once. I
On Wed, 15 May 2019 11:52:57 -0700
Sultan Alsawaf wrote:
> On Wed, May 15, 2019 at 02:32:48PM -0400, Steven Rostedt wrote:
> > I'm confused why you did this?
>
> Oleg said that debug_locks_off() could've been called and thus prevented
> lockdep complaints about s
On Wed, 15 May 2019 10:27:28 -0700
Sultan Alsawaf wrote:
> On Wed, May 15, 2019 at 04:58:32PM +0200, Oleg Nesterov wrote:
> > Could you explain in detail what exactly did you do and what do you see in
> > dmesg?
> >
> > Just in case, lockdep complains only once, print_circular_bug() does
> > d
On Mon, 13 May 2019 09:45:55 -0700
Sultan Alsawaf wrote:
> On Fri, May 10, 2019 at 05:10:25PM +0200, Oleg Nesterov wrote:
> > I am starting to think I am ;)
> >
> > If you have task1 != task2 this code
> >
> > task_lock(task1);
> > task_lock(task2);
> >
> > should trigger print_deadloc
On Thu, 14 Mar 2019 21:36:43 -0700
Daniel Colascione wrote:
> On Thu, Mar 14, 2019 at 8:16 PM Steven Rostedt wrote:
> >
> > On Thu, 14 Mar 2019 13:49:11 -0700
> > Sultan Alsawaf wrote:
> >
> > > Perhaps I'm missing something, but if you want to know w
On Thu, 14 Mar 2019 13:49:11 -0700
Sultan Alsawaf wrote:
> Perhaps I'm missing something, but if you want to know when a process has died
> after sending a SIGKILL to it, then why not just make the SIGKILL optionally
> block until the process has died completely? It'd be rather trivial to just
>
on/trace/tracepoints.txt) can be used without
> +Tracepoints (see Documentation/trace/tracepoints.rst) can be used without
> creating custom kernel modules to register probe functions using the event
> tracing infrastructure.
>
Acked-by: Steven Rostedt (VMware)
-- Ste
acepoint.h
> @@ -4,7 +4,7 @@
> /*
> * Kernel Tracepoint API.
> *
> - * See Documentation/trace/tracepoints.txt.
> + * See Documentation/trace/tracepoints.rst.
> *
> * Copyright (C) 2008-2014 Mathieu Desnoyers
> *
Acked-by: Steven Rostedt
On Mon, 15 Jan 2018 18:18:10 -0800
Deepa Dinamani wrote:
> diff --git a/arch/x86/include/asm/ftrace.h b/arch/x86/include/asm/ftrace.h
> index 09ad88572746..db25aa15b705 100644
> --- a/arch/x86/include/asm/ftrace.h
> +++ b/arch/x86/include/asm/ftrace.h
Acked-by: Steven Ros
ce_int3_handler(struct pt_regs *regs);
> #if !defined(__ASSEMBLY__) && !defined(COMPILE_OFFSETS)
>
> #if defined(CONFIG_FTRACE_SYSCALLS) && defined(CONFIG_IA32_EMULATION)
> -#include
> +#include
>
Acked-by: Steven Rostedt (VMware)
-- Steve
On Tue, 31 Oct 2017 13:48:00 +0100
Greg KH wrote:
> > I don't see how that information can be extracted easily without a
> > tracepoint here. Am I missing something?
>
> Wasn't one of the outcomes of the conference last week the fact that for
> ftrace + ebpf we could get access to the structur
On Mon, 30 Oct 2017 11:32:20 +0100
Greg KH wrote:
> On Mon, Oct 30, 2017 at 11:07:01AM +0100, Vitaly Kuznetsov wrote:
> > Greg KH writes:
> >
> > > On Mon, Oct 30, 2017 at 09:16:19AM +0100, Vitaly Kuznetsov wrote:
> > >> Greg KH writes:
> > >>
> > >> > On Sun, Oct 29, 2017 at 12:21:09PM
On Mon, 2 Oct 2017 08:18:50 +0800
kbuild test robot wrote:
> Hi Vitaly,
>
> [auto build test WARNING on linus/master]
> [also build test WARNING on v4.14-rc3 next-20170929]
> [if your patch is applied to the wrong git tree, please drop us a note to
> help improve the system]
>
> url:
> htt
On Wed, 20 Sep 2017 19:21:53 +0200
Vitaly Kuznetsov wrote:
> diff --git a/drivers/hv/hv_trace.h b/drivers/hv/hv_trace.h
> index 9a29ef55477d..72911dfc9682 100644
> --- a/drivers/hv/hv_trace.h
> +++ b/drivers/hv/hv_trace.h
> @@ -14,6 +14,14 @@ TRACE_EVENT(vmbus_on_msg_dpc,
> TP_printk("m
viewed-by: Stephen Hemminger
Reviewed-by: Steven Rostedt (VMware)
(comment below)
> ---
> MAINTAINERS | 1 +
> arch/x86/hyperv/mmu.c | 7 +++
> arch/x86/include/asm/trace/hyperv.h | 40
> +
> 3 files
On Fri, 09 Jun 2017 20:53:53 +0200
Paul Bolle wrote:
> On Fri, 2017-06-09 at 14:32 -0400, Steven Rostedt wrote:
> > I'm sure it works, but it just adds one more way of doing the same
> > thing. I thought that was what perl was always criticized for, and why
> > pe
On Fri, 9 Jun 2017 21:23:52 +0300
Andy Shevchenko wrote:
> On Fri, Jun 9, 2017 at 9:04 PM, Steven Rostedt wrote:
> > On Fri, 9 Jun 2017 15:27:36 +0200
> > Vitaly Kuznetsov wrote:
>
>
> >> +#if IS_ENABLED(CONFIG_HYPERV)
> >
> > Hmm, this i
On Fri, 9 Jun 2017 15:27:36 +0200
Vitaly Kuznetsov wrote:
> Add Hyper-V tracing subsystem and trace hyperv_mmu_flush_tlb_others().
> Tracing is done the same way we do xen_mmu_flush_tlb_others().
>
> Signed-off-by: Vitaly Kuznetsov
> ---
> MAINTAINERS | 1 +
> arch/x8
On Mon, 05 Jun 2017 18:19:08 +0200
Vitaly Kuznetsov wrote:
> Steven Rostedt writes:
>
> > On Wed, 24 May 2017 14:04:05 +0200
> > Vitaly Kuznetsov wrote:
> >
> >> Add Hyper-V tracing subsystem and trace hyperv_mmu_flush_tlb_others().
> &
On Wed, 24 May 2017 14:04:05 +0200
Vitaly Kuznetsov wrote:
> Add Hyper-V tracing subsystem and trace hyperv_mmu_flush_tlb_others().
> Tracing is done the same way we do xen_mmu_flush_tlb_others().
>
> Signed-off-by: Vitaly Kuznetsov
> Acked-by: K. Y. Srinivasan
> Tested-by: Simon Xiao
> Teste
On Sat, 27 May 2017 20:43:58 +0300
Andy Shevchenko wrote:
> On Wed, May 24, 2017 at 3:03 PM, Vitaly Kuznetsov wrote:
> > Max virtual processor will be needed for 'extended' hypercalls supporting
> > more than 64 vCPUs. While on it, unify on 'Hyper-V' in mshyperv.c as we
> > currently have a mix,
trace_hwlat
> and all the corresponding implementations.
>
> diff --git a/kernel/trace/trace_output.c b/kernel/trace/trace_output.c
> index 02a4aeb..08f9bab 100644
> --- a/kernel/trace/trace_output.c
> +++ b/kernel/trace/trace_output.c
> @@ -4,7 +4,6 @@
> * Copy
On Fri, 7 Apr 2017 13:27:01 +0200
Vitaly Kuznetsov wrote:
> Add Hyper-V tracing subsystem and trace hyperv_mmu_flush_tlb_others().
> Tracing is done the same way we do xen_mmu_flush_tlb_others().
>
> Signed-off-by: Vitaly Kuznetsov
> ---
> MAINTAINERS | 1 +
> arch/x86/hype
his laptop. (RMS?)
What needs to be done to make this a "proper" driver? I can try to
support it, although I have no idea how it works :-)
This reverts commit dc93c85235efa5201e9a3c116bc3fbd1afc1a182.
Signed-off-by: Steven Rostedt
---
drivers/staging/Kconfig |2 +
driv
On Thu, 24 Jul 2014 10:30:51 -0700
Harvey Harrison wrote:
> On Thu, Jul 24, 2014 at 10:18 AM, Steven Rostedt wrote:
> > On Thu, 24 Jul 2014 12:50:31 -0400
> > Nick Krause wrote:
>
> >
> >> I am have this discussion with other kernel developers and just
>
On Thu, 24 Jul 2014 12:50:31 -0400
Nick Krause wrote:
\
> > Most kernel devs most certainly did NOT get started by spamming lkml
> > with unnecessary and incorrect patches despite being repeatedly told to
> > go away and stop wasting everybody's time.
Mans, shut up! That is uncalled for.
> >
>
On Thu, 24 Jul 2014 10:47:25 -0400
Steven Rostedt wrote:
> The three parameters are the number of elements, the size of each individual
> element, and then finally the flags used on how to allocate that memory.
> I have to say, you did get the flags part correct.
>
> Now lets l
On Wed, Jul 23, 2014 at 07:03:01PM -0400, Nicholas Krause wrote:
> This changes the call to kzalloc to kcalloc in ion_dummy_driver
> for allocating the heap.
>
> Signed-off-by: Nicholas Krause
> ---
> drivers/staging/android/ion/ion_dummy_driver.c | 5 ++---
> 1 file changed, 2 insertions(+), 3
On Thu, Jan 09, 2014 at 06:49:39PM +, Joe Bor?? wrote:
>
> I didn't do the changes as root, I sent them from my server as it has SMTP
> out.
>
Hmm, this gives me an idea. There's nothing, I believe, that makes the root user
have to have the name "root" except for the passwd file. Maybe I'll
On Mon, 4 Nov 2013 02:11:50 +0300
Dan Carpenter wrote:
> On Sun, Nov 03, 2013 at 10:28:02AM -0800, Josh Triplett wrote:
> > On Tue, Oct 29, 2013 at 11:01:43PM +0300, Dan Carpenter wrote:
> > > The icount.reserved[] array isn't initialized so it leaks stack
> > > information to userspace.
> > >
>
40 matches
Mail list logo
