Thus, it is strongly recommended to assign the splicing
> thread to corresponding node.
>
> Signed-off-by: Masami Hiramatsu
Acked-by: Steven Rostedt
-- Steve
> Cc: Frederic Weisbecker
> Cc: Ingo Molnar
> ---
>
> kernel/trace/trace.c |8 +---
> 1 file
On Thu, 2012-08-09 at 18:24 +0900, Masami Hiramatsu wrote:
> Yeah, it is really easy to fix that.
> But out of curiosity, would that be really a problem?
> I guess that host can access any guest page if need. If that
> is right, is that really insecure to leak randomly allocated
> unused page to t
On Wed, 2012-08-22 at 17:43 +0900, Yoshihiro YUNOMAE wrote:
> From: Masami Hiramatsu
>
> Use TRACE_DIR environment variable for setting
TRACING_DIR would be better, as we are searching for /debug/tracing and
not /debug/trace. Perhaps DEBUG_TRACING_DIR would be even better as to
be less of a gene
On Wed, 2012-08-22 at 17:43 +0900, Yoshihiro YUNOMAE wrote:
> From: Masami Hiramatsu
>
> Count debugfs/tracing/per_cpu/cpu* to determine the
> number of CPUs.
I'm curious, do you find that sysconf doesn't return the # of CPUs the
system has? I've had boxes where the per_cpu/cpu* had more cpus th
On Wed, 2012-08-22 at 17:43 +0900, Yoshihiro YUNOMAE wrote:
> Add read path and control path to use trace-agent of virtio-trace.
> When we use trace-agent, trace-cmd will be used as follows:
> # AGENT_READ_DIR=/tmp/virtio-trace/tracing \
> AGENT_CTL=/tmp/virtio-trace/agent-ctl-path.in
On Thu, 2012-08-23 at 12:00 +0900, Masami Hiramatsu wrote:
> (2012/08/23 11:01), Masami Hiramatsu wrote:
> > (2012/08/22 22:41), Steven Rostedt wrote:
> >> On Wed, 2012-08-22 at 17:43 +0900, Yoshihiro YUNOMAE wrote:
> >>> From: Masami Hiramatsu
> >>>
&
On Tue, 2013-04-09 at 17:43 -0700, H. Peter Anvin wrote:
> OK, thinking about the GDT here.
>
> The GDT is quite small -- 256 bytes on i386, 128 bytes on x86-64. As
> such, we probably don't want to allocate a full page to it for only
> that. This means that in order to create a readonly mapping
On Thu, 22 Aug 2013 22:47:28 +0100
Zoltan Kiss wrote:
> /*
> * Used to do a quick range check in swiotlb_tbl_unmap_single and
> * swiotlb_tbl_sync_single_*, to see if the memory was in fact allocated by
> this
> @@ -358,6 +362,9 @@ dma_addr_t xen_swiotlb_map_page(struct device *dev,
> str
On Wed, 25 Sep 2013 13:56:49 -0400
Konrad Rzeszutek Wilk wrote:
> .. snip..
> > >+ TP_printk("dev_name: %s dma_mask=%llx dev_addr=%llx "
> > >+ "size=%zu swiotlb_force=%x",
> > >+ __get_str(dev_name),
> > >+ __entry->dma_mask,
> > >+ (unsigned long long)__entr
On Tue, 12 Nov 2013 02:18:53 +0900
Masami Hiramatsu wrote:
>
> > After that we can convert all the rest, probably as part of this series.
>
> OK, I'll do. :)
> BTW, converting all the __kprobes involves many archs, which
> kprobes ported. In that case, which mailing-list would better me
> to pos
On Fri, 15 Nov 2013 04:53:18 +
Masami Hiramatsu wrote:
> .entry.text is a code area which is used for interrupt/syscall
> entries, and there are many sensitive codes.
> Thus, it is better to prohibit probing on all of such codes
> instead of a part of that.
> Since some symbols are already re
On Wed, 20 Nov 2013 12:36:00 -0500
"Frank Ch. Eigler" wrote:
> Hi -
>
> > > Does this new blacklist cover enough that the kernel now survives a
> > > broadly wildcarded perf-probe, e.g. over e.g. all of its kallsyms?
> >
> > That's generally the purpose of the annotations - if it doesn't then
Code: 12 48 c1 ea 0c 83 e8 01 83 e2 30 48 98 48 81 c2 40 6d 01 00 48 03 14
c5 80 6a 5d 82 48 89 0a 8b 41 08 85 c0 75 09 f3 90 8b 41 08 <85> c0 74 f7
4c 8b 09 4d 85 c9 74 08 41 0f 18 09 eb 02 f3 90 8b
Reported-by: Łukasz Daniluk
Signed-off-by: Steven Rostedt
diff --git a/arch/x86/
On Thu, 24 May 2018 13:40:24 +0200
Petr Mladek wrote:
> On Wed 2018-05-23 12:54:15, Thomas Garnier wrote:
> > When using -fPIE/PIC with function tracing, the compiler generates a
> > call through the GOT (call *__fentry__@GOTPCREL). This instruction
> > takes 6 bytes instead of 5 on the usual rel
[ Added Thomas Gleixner ]
On Thu, 26 Jul 2018 11:34:39 +0200
Dmitry Vyukov wrote:
> On Thu, Jul 26, 2018 at 11:29 AM, syzbot
> wrote:
> > Hello,
> >
> > syzbot found the following crash on:
> >
> > HEAD commit:dc66fe43b7eb rds: send: Fix dead code in rds_sendmsg
> > git tree: net-n
From: Steven Rostedt (VMware)
When running function tracing on a Linux guest running on VMware
Workstation, the guest would crash. This is due to tracing of the
sched_clock internal call of the VMware vmware_sched_clock(), which
causes an infinite recursion within the tracing code (clock calls
On Fri, 2007-03-16 at 11:39 -0700, Jeremy Fitzhardinge wrote:
> Ingo Molnar wrote:
> >> + /* Make sure kernel address space is empty so that a pagetable
> >> + will be allocated for it. */
> >>
> >
> > comment style.
> >
>
> As you've noticed its a comment style I use quite often. I
[added Ingo since he'd probably be interested in this]
On Fri, 2007-03-16 at 21:00 -0700, Jeremy Fitzhardinge wrote:
> Chris Wright wrote:
> > * Jeremy Fitzhardinge ([EMAIL PROTECTED]) wrote:
> >
> >> Chris Wright wrote:
> >>
> >>> Consistently wrap paravirt ops callsites
> >>> "ugh" - m
switch to turn it off.
- Send to the launcher the dump instead of printk.
- make modules work too.
Also I need to change the %u of the bad read print to a %x, because
seeing 0x200227d2 is better than seeing 537012178 for addresses.
Signed-off-by: Steven Rostedt <[EMAIL PROT
eding
emulated instructions.
Signed-off-by: Steven Rostedt <[EMAIL PROTECTED]>
Index: linux-2.6.21-rc5-mm2/drivers/lguest/core.c
===
--- linux-2.6.21-rc5-mm2.orig/drivers/lguest/core.c
+++ linux-2.6.21-rc5-mm2/drivers/lguest/core.c
Currently the lguest32 error messages from bad reads and writes prints a
decimal integer for addresses. This is pretty annoying. So this patch
changes those to be hex outputs.
This is applied on top of my debug patch.
Signed-off-by: Steven Rostedt <[EMAIL PROTECTED]>
Index: linux-2.6.21-r
On Wed, 2007-04-04 at 23:06 -0400, Kyle Moffett wrote:
> > (Erk, I wonder what I was thinking when I wrote that?) Can I ask
> > for %#x (or 0x%x)? I'm easily confused.
>
> How about "%p" for pointers?
But that would require casting the numbers to pointers.
-- Steve
On Thu, 2007-04-05 at 12:54 +1000, Rusty Russell wrote:
>
> This is a cool idea, but there are two issues with this patch. The
> first is that it's 500 lines of code: that's around +10% on lguest's
> total code size! The second is that it conflicts with the medium-term
> plan to allow any
On Thu, 2007-04-05 at 12:59 +1000, Rusty Russell wrote:
> On Wed, 2007-04-04 at 15:07 -0400, Steven Rostedt wrote:
> Yeah, I haven't tried loading random modules but I can imagine this does
> happen (what module was it, BTW?)
I have no idea of which module it crashed on. I didn
g went fine (fd == -1) or the
device should be ignored (fd >= 0).
Signed-off-by: Steven Rostedt <[EMAIL PROTECTED]>
Index: linux-2.6-lguest/Documentation/lguest/lguest.c
===
--- linux-2.6-lguest.orig/Documentation/lguest/lg
>
> (Note that lguest doesn't support NMIs, but Steven has code for NMI
> support for lguest-x86-64 which could be ported across).
Rusty,
About that. Is there a way to get a NMI only stack in i386? In x86_64
it's part of the TSS. So I can always know I have a good stack for the
NMI. I'm n
Hi Andi,
Thanks for all the comments, it's greatly appreciated.
On Wed, 8 Aug 2007, Andi Kleen wrote:
>
> > +#define SYSRETQ\
> > + movq%gs:pda_oldrsp,%rsp;\
> > + swapgs; \
> > +
On Wed, 8 Aug 2007, Andi Kleen wrote:
> Strictly you would at least need a !X86_VSMP dependency, but
> with the vsmp change i requested that will be unnecessary
>
> Is this really synced with the latest version of the i386 code?
Glauber started the paravirt ops 64 a second time around, from scra
On Wed, 8 Aug 2007, Andi Kleen wrote:
>
> > Probably not, but this part of the code I don't fully understand.
>
> I would suggest to defer all this until at least one example to test it
> (except vsmp which is too simple) is around.
Who uses that code? NMIs and debug regs? Lguest only has the h
--
On Wed, 8 Aug 2007, Andi Kleen wrote:
> Steven Rostedt <[EMAIL PROTECTED]> writes:
>
> > On Wed, 8 Aug 2007, Andi Kleen wrote:
> >
> > >
> > > > Probably not, but this part of the code I don't fully understand.
> > >
> > >
On Wed, 8 Aug 2007, Steven Rostedt wrote:
> On Wed, 8 Aug 2007, Andi Kleen wrote:
>
> >> paranoid_restore\trace:
> >> RESTORE_ALL 8
> >> - iretq
> >> + INTERRUPT_RETURN
> >
> >I suspect Xen will need much more changes any
--
On Wed, 8 Aug 2007, Andi Kleen wrote:
> > If you were talking about the general iretq => INTERRUPT_RETURN, then the
> > answer is "Yes, they are sufficient". The first version of lguest ran the
> > guest kernel in ring 3 (using dual page tables for guest kernel and guest
> > user). The curren
--
On Wed, 8 Aug 2007, Andi Kleen wrote:
> > When I said "this part of the code I don't fully understand" I was not
> > talking about entry.S. I understand entry.S very well, but the comment
> > was originally on the paranoid_restore code. Which I thought had to deal
> > with NMIs and such that
--
On Wed, 8 Aug 2007, Andi Kleen wrote:
> On Wed, Aug 08, 2007 at 09:47:05AM -0400, Steven Rostedt wrote:
> >
> > [...]
> > asm volatile ("pushq %2; pushq %%rsp; pushfq; pushq %3; call *%6;"
> > /* The stack we pushed is of
Hi all,
I've been working on lguest64 and in order to do this, I had to move
a lot of the i386 specific out of the way. Well, the lguest64 port
is still not ready to display, but before Rusty makes too many changes
I would like this in upstream so I don't have to keep repeating my
changes :-)
S
Add a generic lg.h file to call the architecture specific one.
Signed-off-by: Steven Rostedt <[EMAIL PROTECTED]>
---
drivers/lguest/lg.h |3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/drivers/lguest/lg.h b/drivers/lguest/lg.h
new file mode 100644
index 0
Have the lguest launcher include e820.h via asm/e820.h instead of explicitly
saying i386.
Signed-off-by: Steven Rostedt <[EMAIL PROTECTED]>
---
Documentation/lguest/lguest.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/Documentation/lguest/lguest.c b/Documen
The lguest_dma_info is also generic across architectures.
Move it to the generic lg.h
Signed-off-by: Steven Rostedt <[EMAIL PROTECTED]>
---
drivers/lguest/i386/lg.h | 11 ---
drivers/lguest/lg.h | 11 +++
2 files changed, 11 insertions(+), 11 deletions(-)
diff -
Make a i386 directory in the lguest directory, and move the lg.h into
it. This will clear the way for other archs to have their own lg.h
Signed-off-by: Steven Rostedt <[EMAIL PROTECTED]>
---
drivers/lguest/i386/lg.h | 300 ++
drivers/lgues
Move the io struct into the lg.h file since the io.c is generic to other
architectures.
Also added a proper ifdef for the generic lg.h.
Signed-off-by: Steven Rostedt <[EMAIL PROTECTED]>
---
drivers/lguest/i386/lg.h | 11 ++-
drivers/lguest/lg.h | 16
2
The hvc_lguest uses __pa in the const initialization.
In some architectures, __pa() is not constant so this fails in compiles.
Signed-off-by: Steven Rostedt <[EMAIL PROTECTED]>
---
drivers/char/hvc_lguest.c |8 +++-
1 files changed, 7 insertions(+), 1 deletions(-)
diff --git a/d
--
On Thu, 9 Aug 2007, Stephen Rothwell wrote:
> On Wed, 08 Aug 2007 20:32:13 -0400 Steven Rostedt <[EMAIL PROTECTED]>
> wrote:
> >
> > Add a generic lg.h file to call the architecture specific one.
>
> Please combine this with the previous patch so that the tree wi
--
On Thu, 9 Aug 2007, Stephen Rothwell wrote:
> On Wed, 08 Aug 2007 20:32:15 -0400 Steven Rostedt <[EMAIL PROTECTED]>
> wrote:
> >
> > diff --git a/drivers/lguest/i386/lg.h b/drivers/lguest/i386/lg.h
> > index 64f0abe..c5ea14c 100644
> > --- a/drivers/lgues
The hvc_lguest uses __pa in the const initialization.
In some architectures, __pa() is not constant so this fails in compiles.
Signed-off-by: Steven Rostedt <[EMAIL PROTECTED]>
---
drivers/char/hvc_lguest.c |8 +++-
1 files changed, 7 insertions(+), 1 deletions(-)
diff --git a/d
[
Changes since last version.
- Move lg.h to include/asm instead (suggested by Rusty Russel)
- All steps of the series compiles (suggested by Stephen Rothwell)
- Better ifdef header naming (suggested by Stephen Rothwell)
- Added Andi Kleen to CC (forgot to on V1)
]
Hi all,
I've been wor
Add a generic lg.h that can be included from lguest files.
This file will hold the data that can be shared across archs.
Signed-off-by: Steven Rostedt <[EMAIL PROTECTED]>
---
arch/i386/kernel/asm-offsets.c|2 +-
drivers/lguest/core.c |2 +-
drivers/
Have the lguest launcher include e820.h via asm/e820.h instead of explicitly
saying i386.
Signed-off-by: Steven Rostedt <[EMAIL PROTECTED]>
---
Documentation/lguest/lguest.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/Documentation/lguest/lguest.c b/Documen
The lg.h file has lots of i386 specific information. Move it over to the asm
directory where it belongs.
Signed-off-by: Steven Rostedt <[EMAIL PROTECTED]>
---
arch/i386/kernel/asm-offsets.c|2 +-
drivers/lguest/core.c |2 +-
drivers/lguest/hyperc
--
On Wed, 8 Aug 2007, Jeremy Fitzhardinge wrote:
> Steven Rostedt wrote:
> > /*
> > * x86 arch doesn't have an easy way to find out where
> > * gs is located. So we need to read the MSR. But first
> > * we need to save off the rcx, rax and rdx.
--
On Thu, 9 Aug 2007, Stephen Rothwell wrote:
> Hi Steven,
>
> I am just being pedantic here (and I should have beaten up on Rusty
> before now ... :-)
>
> On Thu, 09 Aug 2007 00:36:30 -0400 Steven Rostedt <[EMAIL PROTECTED]>
> wrote:
> >
> > --- a/incl
--
On Thu, 9 Aug 2007, Stephen Rothwell wrote:
> Hi Steven,
>
> On Thu, 09 Aug 2007 00:36:31 -0400 Steven Rostedt <[EMAIL PROTECTED]>
> wrote:
> >
> > Well, some may be merged with x86_64 later, but for now we move them
> > out of the way. Later on we
--
On Thu, 9 Aug 2007, Jeremy Fitzhardinge wrote:
> Glauber de Oliveira Costa wrote:
> > On 8/9/07, Jeremy Fitzhardinge <[EMAIL PROTECTED]> wrote:
> >
> >>> Does it really matter?
> >>>
> >>>
> >> Well, yes, if alignment is an issue.
> >>
> > Of course, But the question rises from the context tha
--
On Thu, 9 Aug 2007, Jes Sorensen wrote:
> Stephen Rothwell wrote:
> > On Wed, 08 Aug 2007 20:32:15 -0400 Steven Rostedt <[EMAIL PROTECTED]>
> > wrote:
> >> diff --git a/drivers/lguest/i386/lg.h b/drivers/lguest/i386/lg.h
> >> index 64f0abe..c5ea14c 100
--
On Wed, 8 Aug 2007, Jeremy Fitzhardinge wrote:
>
> At the moment Xen can't support guests with 2M pages. In 32-bit this
> isn't a huge problem, since the kernel doesn't assume it can map itself
> with 2M pages. But I think the 64-bit kernel assumes 2M pages are
> always available for mapping
--
On Thu, 9 Aug 2007, Andi Kleen wrote:
>
> > This has to match the normal C calling convention though, doesn't it?
>
> Native cli/sti/save/restore_flags are all only assembly and can be easily
> (in fact more easily than in C) written as pure assembler functions. Then
> you can use whatever calli
--
On Wed, 15 Aug 2007, Glauber de Oliveira Costa wrote:
> @@ -566,10 +596,15 @@ retint_restore_args:
> restore_args:
> RESTORE_ARGS 0,8,0
> iret_label:
> +#ifdef CONFIG_PARAVIRT
> + INTERRUPT_RETURN
> +#endif
> +.globl do_iretq;
Is the .globl really required here? I would think th
This is a formal announcement of Lguest64.
Most are aware of the little puppies (lguest32, or simply lguest, or in
some circles "rustyvisor"). But this time the puppies ate a bit too
much. No more lean and mean puppies, now we got big fat lazy ones.
Running on the hardware that's too lazy to do
--
On Mon, 10 Sep 2007, Markus Armbruster wrote:
>
> I believe this possible, but unlikely (perhaps not so unlikely on
> virtual machines). Scenarios involve enable succeeding the first
> time, failing the second time, and succeeding the third time. I can
> provide details, but the point I'd lik
On Mon, 19 Nov 2007, Bastian Blank wrote:
> On Fri, Nov 09, 2007 at 04:42:48PM -0200, Glauber de Oliveira Costa wrote:
> > - wrmsrl(MSR_CSTAR, ia32_cstar_target);
> > + wrmsrl(MSR_CSTAR, (u64)ia32_cstar_target);
>
> Hmm, why do you add explicit casts? The compiler should convert that
> correc
On Tue, 20 Nov 2007, Ingo Molnar wrote:
> * Steven Rostedt <[EMAIL PROTECTED]> wrote:
>
> > With PVOPS on it gives compiler warnings without that explict cast.
> > Without looking at the code, IIRC with non-PVOPS it is a macro
> > directly into asm, so it didn&#
On Tue, 20 Nov 2007, Ingo Molnar wrote:
>
> i dont think there's ever any true need (and good cause) to force
> integer type casts like that at the callee site.
Unless you mean we should do something like this:
static inline void __wrmsrl(unsigned int msr, unsigned long long val);
#define wrmsr(
On Wed, 26 Dec 2007, Rusty Russell wrote:
> On Friday 21 December 2007 00:33:42 Glauber de Oliveira Costa wrote:
> > + if (!vcpu_id) {
> > + /*
> > +* Service input, then unset the BREAK to
> > +* release the Waker.
> > +
[Added Chris Wright, Rusty and Virt list because they were involved with
this issue before]
On Thu, 3 Jan 2008, Ingo Molnar wrote:
>
> * Steven Rostedt <[EMAIL PROTECTED]> wrote:
>
> > +# function tracing might turn this off:
> > +config REGPARM
> > +
On Thu, 3 Jan 2008, Chris Wright wrote:
>
> Yes, paravirt ops have a well-specified calling convention (register
> based). There was a cleanup that Andi did that caused the problem
> because it removed all the "fastcall" annotations since -mregparm=3
> is now always on for i386. Since MCOUNT di
Hi!
Just an FYI,
When sending out patch series, could you send out a [PATCH 0/6] first,
and have all other patches a reply to that patch. Both git and quilt
have ways to do this.
The reason is that the linux kernel mailing list gets over 600 emails a
day, and for those of us that skim through, w
On Sat, 2011-08-06 at 11:22 -0700, Jeremy Fitzhardinge wrote:
> On 08/05/2011 06:58 PM, Konrad Rzeszutek Wilk wrote:
> > On Fri, Aug 05, 2011 at 11:14:23PM +0200, Ingo Molnar wrote:
> >> * Ingo Molnar wrote:
> >>
> >>> * Randy Dunlap wrote:
> >>>
> On 08/04/11 15:40, Konrad Rzeszutek Wilk wr
On Thu, 28 Jul 2016 14:39:53 +0900
Namhyung Kim wrote:
> Well, I dont' know. As you know, the kernel oops dump is already sent
> to serial device but it's rather slow. As I wrote in the cover
> letter, enabling ftrace_dump_on_oops makes it even worse.. Also
> pstore saves the (compressed) bina
Hmm, I'm guessing this patch got lost.
-- Steve
On Wed, 25 May 2016 13:47:26 -0400
Steven Rostedt wrote:
> Łukasz Daniluk reported that on a RHEL kernel that his machine would lock up
> after enabling function tracer. I asked him to bisect the functions within
> available_fi
-0400
Steven Rostedt wrote:
> Łukasz Daniluk reported that on a RHEL kernel that his machine would lock up
> after enabling function tracer. I asked him to bisect the functions within
> available_filter_functions, which he did and it came down to three:
>
> _paravirt_nop(), _paravirt
On Wed, 4 Oct 2017 14:19:56 -0700
Thomas Garnier wrote:
> When using -fPIE/PIC with function tracing, the compiler generates a
> call through the GOT (call *__fentry__@GOTPCREL). This instruction
> takes 6 bytes instead of 5 on the usual relative call.
>
> With this change, function tracing sup
On Thu, 5 Oct 2017 09:01:14 -0700
Thomas Garnier wrote:
> On Thu, Oct 5, 2017 at 6:06 AM, Steven Rostedt wrote:
> > On Wed, 4 Oct 2017 14:19:56 -0700
> > Thomas Garnier wrote:
> >
> >> When using -fPIE/PIC with function tracing, the compiler generates a
&
On Thu, 11 Nov 2021 07:50:39 +0100
Greg KH wrote:
> > Signed-off-by: Srivatsa S. Bhat (VMware)
> > Acked-by: Alexey Makhalov
> > Acked-by: Deep Shah
> > Acked-by: Juergen Gross
> > Cc: sta...@vger.kernel.org
>
> Why are MAINTAINERS updates needed for stable? That's not normal :(
Probably
after 15 usecs
> calling init+0x0/0x60 @ 1
> initcall init+0x0/0x60 returned 0 after 2 usecs
> calling init+0x0/0x9a @ 1
> initcall init+0x0/0x9a returned 0 after 74 usecs
>
> Fixes: 8b7d89d02ef3 ("x86: mmiotrace - trace memory mapped IO")
> Signed-off-by:
ut, and exit out if it spins there for more than 5 seconds. This
makes the problem go away.
Below is my changes, but this is a band-aid, it is not the cure.
Workaround-fix-by: Steven Rostedt (Google)
---
diff --git a/drivers/char/virtio_console.c b/drivers/char/virtio_console.c
index e3c430539a17..
On Fri, 25 Mar 2022 17:36:27 -0700
Linus Torvalds wrote:
> On Fri, Mar 25, 2022 at 2:20 PM Steven Rostedt wrote:
> >
> > With the updates to change the size being passed in the splice from
> > page_size to pipe_size, this never finished (it would copy around a meg or
>
On Thu, 9 Jun 2022 15:02:20 +0200
Petr Mladek wrote:
> > I'm somewhat curious whether we can actually remove that trace event.
>
> Good question.
>
> Well, I think that it might be useful. It allows to see trace and
> printk messages together.
Yes people still use it. I was just asked about
On Tue, 17 Nov 2020 12:23:41 +0200
Leon Romanovsky wrote:
> Hi,
>
> Approximately two weeks ago, our regression team started to experience those
> netconsole splats. The tested code is Linus's master (-rc4) + netdev net-next
> + netdev net-rc.
>
> Such splats are random and we can't bisect beca
[ Adding netdev as perhaps someone there knows ]
On Wed, 18 Nov 2020 12:09:59 +0800
Jason Wang wrote:
> > This CPU0 lock(_xmit_ETHER#2) -> hard IRQ -> lock(console_owner) is
> > basically
> > soft IRQ -> lock(_xmit_ETHER#2) -> hard IRQ -> printk()
> >
> > Then CPU1 spins on xmit, which is
On Mon, 23 Nov 2020 13:08:55 +0200
Leon Romanovsky wrote:
> [ 10.028024] Chain exists of:
> [ 10.028025] console_owner --> target_list_lock --> _xmit_ETHER#2
Note, the problem is that we have a location that grabs the xmit_lock while
holding target_list_lock (and possibly console_owner)
On Mon, 23 Nov 2020 10:52:52 -0800
Jakub Kicinski wrote:
> On Mon, 23 Nov 2020 09:31:28 -0500 Steven Rostedt wrote:
> > On Mon, 23 Nov 2020 13:08:55 +0200
> > Leon Romanovsky wrote:
> >
> >
> > > [ 10.028024] Chain exists of:
> > > [ 10
On Tue, 24 Nov 2020 11:22:03 +0800
Jason Wang wrote:
> Btw, have a quick search, there are several other drivers that uses tx
> lock in the tx NAPI.
tx NAPI is not the issue. The issue is that write_msg() (in netconsole.c)
calls this polling logic with the target_list_lock held.
Are those othe
On Thu, 18 Feb 2021 08:42:15 +0300
Arseny Krasnov wrote:
Not sure if this was pulled in yet, but I do have a small issue with this
patch.
> @@ -69,14 +82,19 @@ TRACE_EVENT(virtio_transport_alloc_pkt,
> __entry->type = type;
> __entry->op = op;
> __entry-
know.
>
> Yes, please, that would be great. I'll send out v3 with the few patches that
> haven't gotten a response, but I'll drop the virtio patches assuming you've
> got them.
>
Since the last patch 6/6 is not
07f9595 100644
> --- a/arch/x86/include/asm/ftrace.h
> +++ b/arch/x86/include/asm/ftrace.h
Acked-by: Steven Rostedt (Google)
-- Steve
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
On Wed, 13 Sep 2023 13:38:27 +0200
Juergen Gross wrote:
> diff --git a/include/trace/events/xen.h b/include/trace/events/xen.h
> index 44a3f565264d..0577f0cdd231 100644
> --- a/include/trace/events/xen.h
> +++ b/include/trace/events/xen.h
> @@ -6,26 +6,26 @@
> #define _TRACE_XEN_H
>
> #includ
timestamp=on
root2000 0.0 0.0 0 0 ?S16:22 0:00
[kvm-pit/1954]
root 2002 0.0 0.0 0 0 ?S16:22 0:00
[vhost-1954]
This is just an example of what I'm looking for. Just a way to find what
process is using what cid.
Signed-
For kicks, I wrote this program that uses libtracefs to search all CIDS
(1-255), and find the kvm guests that are attached to them.
It traces the sched_wakeup and kvm_exit, looking for:
this_task -> wakeup -> wakeup -> kvm_exit
when doing a connect to a cid.
When it finds the pid that did a kv
On Fri, 7 May 2021 16:11:20 +0200
Stefano Garzarella wrote:
> Hi Steven,
>
> On Wed, May 05, 2021 at 04:38:55PM -0400, Steven Rostedt wrote:
> >The new trace-cmd 3.0 (which is almost ready to be released) allows for
> >tracing between host and guests with timestamp sync
On Fri, 7 May 2021 17:43:32 +0200
Stefano Garzarella wrote:
> >The start/stop of a seq_file() is made for taking locks. I do this with all
> >my code in ftrace. Yeah, there's a while loop between the two, but that's
> >just to fill the buffer. It's not that long and it never goes to userspace
> >
On Thu, 13 May 2021 16:57:34 +0100
Stefan Hajnoczi wrote:
> This approach relies on process hierarchy of the VMM (QEMU).
> Multi-process QEMU is in development and will allow VIRTIO devices to
> run as separate processes from the main QEMU. It then becomes harder to
> correlate a VIRTIO device p
Nit, the subject should have "tracing:" an not "ftrace:" as the former
encompasses the tracing infrastructure and the latter is for the function
hook part of that.
On Mon, 19 Sep 2022 12:00:12 +0200
Peter Zijlstra wrote:
> CONFIG_GENERIC_ENTRY disallows any and all tracing when RCU isn't
> ena
On Mon, 23 Jan 2023 21:50:12 +0100
Peter Zijlstra wrote:
> All RCU disabled code should be noinstr and hence we should never get
> here -- when we do, WARN about it and make sure to not actually do
> tracing.
>
> Signed-off-by: Peter Zijlstra (Intel)
> ---
> arch/x86/kernel/ftrace.c |3 +++
On Mon, 23 Jan 2023 16:53:04 -0500
Steven Rostedt wrote:
> On Mon, 23 Jan 2023 21:50:12 +0100
> Peter Zijlstra wrote:
>
> > All RCU disabled code should be noinstr and hence we should never get
> > here -- when we do, WARN about it and make sure to not actually do
> &g
93 matches
Mail list logo
