similar to: [RFC PATCH 0/6] virtio-trace: Support virtio-trace

Hi All, The following patch set provides a low-overhead system for collecting kernel tracing data of guests by a host in a virtualization environment. A guest OS generally shares some devices with other guests or a host, so reasons of any problems occurring in a guest may be from other guests or a host. Then, to collect some tracing data of a number of guests and a host is needed when some

Hi All, The following patch set provides a low-overhead system for collecting kernel tracing data of guests by a host in a virtualization environment. A guest OS generally shares some devices with other guests or a host, so reasons of any problems occurring in a guest may be from other guests or a host. Then, to collect some tracing data of a number of guests and a host is needed when some

Hi Steven, The following patch set provides a feature which can read trace data of a guest using virtio-trace (https://lkml.org/lkml/2012/8/9/210) for a recorder function of trace-cmd. This patch set depends on the trace-agent running on a guest in the virtio-trace system. To translate raw data of a guest to text data on a host, information of debugfs in the guest is also needed on the host. In

Hi Steven, The following patch set provides a feature which can read trace data of a guest using virtio-trace (https://lkml.org/lkml/2012/8/9/210) for a recorder function of trace-cmd. This patch set depends on the trace-agent running on a guest in the virtio-trace system. To translate raw data of a guest to text data on a host, information of debugfs in the guest is also needed on the host. In

Hi, This patch set fixes two bugs of splice_write in the virtio-console driver. [BUG1] Although pipe->nrbufs is empty, the driver tries to do splice_write. => This induces oops in sg_init_table(). [BUG2] No lock for competition of splice_write. => This induces oops in splice_from_pipe_feed() by bug of any user application. These reports are written in each

Hi, This patch set fixes two bugs of splice_write in the virtio-console driver. [BUG1] Although pipe->nrbufs is empty, the driver tries to do splice_write. => This induces oops in sg_init_table(). [BUG2] No lock for competition of splice_write. => This induces oops in splice_from_pipe_feed() by bug of any user application. These reports are written in each

Hi, This patch set fixes two bugs of splice_write in the virtio-console driver. [BUG1] Although pipe->nrbufs is empty, the driver tries to do splice_write. => This induces oops in sg_init_table(). [BUG2] No lock for competition of splice_write. => This induces oops in splice_from_pipe_feed() by bug of any user application. These reports are written in each

Hi, This patch set fixes two bugs of splice_write in the virtio-console driver. [BUG1] Although pipe->nrbufs is empty, the driver tries to do splice_write. => This induces oops in sg_init_table(). [BUG2] No lock for competition of splice_write. => This induces oops in splice_from_pipe_feed() by bug of any user application. These reports are written in each

From: Sjur Br?ndeland <sjur.brandeland at stericsson.com> I thought rebasing rproc_serial to linux-next was going to be trivial. But when starting the merge I realized that I had to refactor the the patches from Masami Hiramatsu. The splice support has the same issue as I faced, with different type of buffers in the out_vq. So I ended up refactoring the splice functionality. The code size

From: Sjur Br?ndeland <sjur.brandeland at stericsson.com> I thought rebasing rproc_serial to linux-next was going to be trivial. But when starting the merge I realized that I had to refactor the the patches from Masami Hiramatsu. The splice support has the same issue as I faced, with different type of buffers in the out_vq. So I ended up refactoring the splice functionality. The code size

(2013/11/22 11:35), Masami Hiramatsu wrote: > (2013/11/21 16:29), Ingo Molnar wrote: >> >> * Masami Hiramatsu <masami.hiramatsu.pt at hitachi.com> wrote: >> >>> (2013/11/21 2:36), Frank Ch. Eigler wrote: >> >> [ ... ] >>>> one needs to resort to something like: >>>> >>>> # cat /proc/kallsyms | grep ' [tT] '

(2013/11/22 11:35), Masami Hiramatsu wrote: > (2013/11/21 16:29), Ingo Molnar wrote: >> >> * Masami Hiramatsu <masami.hiramatsu.pt at hitachi.com> wrote: >> >>> (2013/11/21 2:36), Frank Ch. Eigler wrote: >> >> [ ... ] >>>> one needs to resort to something like: >>>> >>>> # cat /proc/kallsyms | grep ' [tT] '

(2013/11/27 22:30), Ingo Molnar wrote: > > * Masami Hiramatsu <masami.hiramatsu.pt at hitachi.com> wrote: > >> (2013/11/22 11:35), Masami Hiramatsu wrote: >>> (2013/11/21 16:29), Ingo Molnar wrote: >>>> >>>> * Masami Hiramatsu <masami.hiramatsu.pt at hitachi.com> wrote: >>>> >>>>> (2013/11/21 2:36), Frank Ch.

(2013/11/27 22:30), Ingo Molnar wrote: > > * Masami Hiramatsu <masami.hiramatsu.pt at hitachi.com> wrote: > >> (2013/11/22 11:35), Masami Hiramatsu wrote: >>> (2013/11/21 16:29), Ingo Molnar wrote: >>>> >>>> * Masami Hiramatsu <masami.hiramatsu.pt at hitachi.com> wrote: >>>> >>>>> (2013/11/21 2:36), Frank Ch.

* Masami Hiramatsu <masami.hiramatsu.pt at hitachi.com> wrote: > (2013/11/21 2:36), Frank Ch. Eigler wrote: [ ... ] > > one needs to resort to something like: > > > > # cat /proc/kallsyms | grep ' [tT] ' | while read addr type symbol; do > > perf probe $symbol > > done > > > > then wait for a few hours for that to finish. Then, or

* Masami Hiramatsu <masami.hiramatsu.pt at hitachi.com> wrote: > (2013/11/21 2:36), Frank Ch. Eigler wrote: [ ... ] > > one needs to resort to something like: > > > > # cat /proc/kallsyms | grep ' [tT] ' | while read addr type symbol; do > > perf probe $symbol > > done > > > > then wait for a few hours for that to finish. Then, or

* Masami Hiramatsu <masami.hiramatsu.pt at hitachi.com> wrote: > Use NOKPROBE_SYMBOL macro for protecting functions > from kprobes instead of __kprobes annotation in > dumpstack.c. > > Signed-off-by: Masami Hiramatsu <masami.hiramatsu.pt at hitachi.com> > Cc: Thomas Gleixner <tglx at linutronix.de> > Cc: Ingo Molnar <mingo at redhat.com> > Cc:

* Masami Hiramatsu <masami.hiramatsu.pt at hitachi.com> wrote: > Use NOKPROBE_SYMBOL macro for protecting functions > from kprobes instead of __kprobes annotation in > dumpstack.c. > > Signed-off-by: Masami Hiramatsu <masami.hiramatsu.pt at hitachi.com> > Cc: Thomas Gleixner <tglx at linutronix.de> > Cc: Ingo Molnar <mingo at redhat.com> > Cc:

On Wed, Nov 20, 2013 at 04:22:21AM +0000, Masami Hiramatsu wrote: > Use NOKPROBE_SYMBOL macro to protect functions from kprobes > instead of __kprobes annotation in trap.c. > This also applies __always_inline annotation for some cases, > because NOKPROBE_SYMBOL() will inhibit inlining by referring > the symbol address. NOKPROBE_SYMBOL seems to add a reference from some variable to

On Fri, 15 Nov 2013 04:53:18 +0000 Masami Hiramatsu <masami.hiramatsu.pt at hitachi.com> 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 registered on kprobe blacklist, > this also