Re: Observed a ecryptFS crash

ping... Hi Tyhicks, We observed a ecryptFS crash occasionally in Linux kernel 4.1.18. The call trace is attached below. Is it a known issue？ Look forward to hearing from you. Thanks in advance! [19314.529479s][pid:2694,cpu3,GAC_Executor[0]]Call trace:

Re: Observed a ecryptFS crash

ping... Hi Tyhicks, We observed a ecryptFS crash occasionally in Linux kernel 4.1.18. The call trace is attached below. Is it a known issue？ Look forward to hearing from you. Thanks in advance! [19314.529479s][pid:2694,cpu3,GAC_Executor[0]]Call trace:

there are unencrypted files in an encrypted directory in F2FS

Hi Kim, According to the encryption design policy "all of the files or subdirectories in an encrypted directory must be encrypted". But the current f2fs code seems allow to there are unencrypted files in an encrypted directory. For example, the f2fs_create() and f2fs_mknod() functions call

there are unencrypted files in an encrypted directory in F2FS

Hi Kim, According to the encryption design policy "all of the files or subdirectories in an encrypted directory must be encrypted". But the current f2fs code seems allow to there are unencrypted files in an encrypted directory. For example, the f2fs_create() and f2fs_mknod() functions call

Re: Kernel panic - encryption/decryption failed when open file on Arm64

On 12 September 2016 at 03:16, liushuoran wrote: Hi Ard, Thanks for the prompt reply. With the patch, there is no panic anymore. But it seems that the encryption/decryption is not successful anyway. As Herbert points out, "If the page allocation fails in

Re: Kernel panic - encryption/decryption failed when open file on Arm64

On 12 September 2016 at 03:16, liushuoran wrote: Hi Ard, Thanks for the prompt reply. With the patch, there is no panic anymore. But it seems that the encryption/decryption is not successful anyway. As Herbert points out, "If the page allocation fails in blkcipher_walk_next it'll simply

Re: Kernel panic - encryption/decryption failed when open file on Arm64

2016 at 08:38:43PM +0800, xiakaixu wrote: Hi, I am using the encryption/decryption feature on arm64 board and a kernel panic occurs just when open a file. As the memory size of the board is limited and there are some page allocation failures before the panic. Seems it is a kernel bu

Re: Kernel panic - encryption/decryption failed when open file on Arm64

2016 at 08:38:43PM +0800, xiakaixu wrote: Hi, I am using the encryption/decryption feature on arm64 board and a kernel panic occurs just when open a file. As the memory size of the board is limited and there are some page allocation failures before the panic. Seems it is a kernel bu

Re: Kernel panic - encryption/decryption failed when open file on Arm64

k->page to NULL manually. I get the same crash when open file with the above change log. So I think this NULL page failure is not be handled correctly in current code. Regards Kaixu Xia On Thu, Sep 08, 2016 at 08:38:43PM +0800, xiakaixu wrote: Hi, I am using the encryption/decryption feat

Re: Kernel panic - encryption/decryption failed when open file on Arm64

k->page to NULL manually. I get the same crash when open file with the above change log. So I think this NULL page failure is not be handled correctly in current code. Regards Kaixu Xia On Thu, Sep 08, 2016 at 08:38:43PM +0800, xiakaixu wrote: Hi, I am using the encryption/decryption feat

test

Sorry for noise! -- Regards Kaixu Xia

test

Sorry for noise! -- Regards Kaixu Xia

Re: [PATCHSET v5] Make background writeback great again for the first time

于 2016/4/28 4:59, Jens Axboe 写道: > On Wed, Apr 27 2016, Jens Axboe wrote: >> On Wed, Apr 27 2016, Jens Axboe wrote: >>> On 04/27/2016 12:01 PM, Jan Kara wrote: Hi, On Tue 26-04-16 09:55:23, Jens Axboe wrote: > Since the dawn of time, our background buffered writeback has sucked.

Re: [PATCHSET v5] Make background writeback great again for the first time

于 2016/4/28 4:59, Jens Axboe 写道: > On Wed, Apr 27 2016, Jens Axboe wrote: >> On Wed, Apr 27 2016, Jens Axboe wrote: >>> On 04/27/2016 12:01 PM, Jan Kara wrote: Hi, On Tue 26-04-16 09:55:23, Jens Axboe wrote: > Since the dawn of time, our background buffered writeback has sucked.

Re: [PATCH 7/8] wbt: add general throttling mechanism

于 2016/4/27 23:21, Jens Axboe 写道: > On 04/27/2016 06:06 AM, xiakaixu wrote: >>> +void __wbt_done(struct rq_wb *rwb) >>> +{ >>> +int inflight, limit = rwb->wb_normal; >>> + >>> +/* >>> + * If the device does write back cac

Re: [PATCH 7/8] wbt: add general throttling mechanism

于 2016/4/27 23:21, Jens Axboe 写道: > On 04/27/2016 06:06 AM, xiakaixu wrote: >>> +void __wbt_done(struct rq_wb *rwb) >>> +{ >>> +int inflight, limit = rwb->wb_normal; >>> + >>> +/* >>> + * If the device does write back cac

Re: [PATCH 7/8] wbt: add general throttling mechanism

> + return rwb && rwb->wb_normal != 0; > +} > + > +/* > + * Increment 'v', if 'v' is below 'below'. Returns true if we succeeded, > + * false if 'v' + 1 would be bigger than 'below'. > + */ > +static bool atomic_inc_below(atomic_t *v, int below) > +{ > + int cur = atomic_read(v); > + > +

Re: [PATCH 7/8] wbt: add general throttling mechanism

> + return rwb && rwb->wb_normal != 0; > +} > + > +/* > + * Increment 'v', if 'v' is below 'below'. Returns true if we succeeded, > + * false if 'v' + 1 would be bigger than 'below'. > + */ > +static bool atomic_inc_below(atomic_t *v, int below) > +{ > + int cur = atomic_read(v); > + > +

Re: [PATCH 8/8] writeback: throttle buffered writeback

于 2016/4/24 5:37, Jens Axboe 写道: > On 04/23/2016 02:21 AM, xiakaixu wrote: >>> diff --git a/block/blk-core.c b/block/blk-core.c >>> index 40b57bf4852c..d941f69dfb4b 100644 >>> --- a/block/blk-core.c >>> +++ b/block/blk-core.c >>> @@ -39,6 +39,7 @

Re: [PATCH 8/8] writeback: throttle buffered writeback

于 2016/4/24 5:37, Jens Axboe 写道: > On 04/23/2016 02:21 AM, xiakaixu wrote: >>> diff --git a/block/blk-core.c b/block/blk-core.c >>> index 40b57bf4852c..d941f69dfb4b 100644 >>> --- a/block/blk-core.c >>> +++ b/block/blk-core.c >>> @@ -39,6 +39,7 @

Re: [PATCH 8/8] writeback: throttle buffered writeback

> diff --git a/block/blk-core.c b/block/blk-core.c > index 40b57bf4852c..d941f69dfb4b 100644 > --- a/block/blk-core.c > +++ b/block/blk-core.c > @@ -39,6 +39,7 @@ > > #include "blk.h" > #include "blk-mq.h" > +#include "blk-wb.h" > > EXPORT_TRACEPOINT_SYMBOL_GPL(block_bio_remap); >

Re: [PATCH 8/8] writeback: throttle buffered writeback

> diff --git a/block/blk-core.c b/block/blk-core.c > index 40b57bf4852c..d941f69dfb4b 100644 > --- a/block/blk-core.c > +++ b/block/blk-core.c > @@ -39,6 +39,7 @@ > > #include "blk.h" > #include "blk-mq.h" > +#include "blk-wb.h" > > EXPORT_TRACEPOINT_SYMBOL_GPL(block_bio_remap); >

Re: [PATCH v2] arm64: Store breakpoint single step state into pstate

ping... 于 2016/1/15 16:20, xiakaixu 写道: > 于 2016/1/13 1:06, Will Deacon 写道: >> On Tue, Jan 05, 2016 at 01:06:15PM +0800, Wangnan (F) wrote: >>> On 2016/1/5 0:55, Will Deacon wrote: >>>> The problem seems to be that we take the debug exception before the >>

Re: [PATCH v2] arm64: Store breakpoint single step state into pstate

ping... 于 2016/1/15 16:20, xiakaixu 写道: > 于 2016/1/13 1:06, Will Deacon 写道: >> On Tue, Jan 05, 2016 at 01:06:15PM +0800, Wangnan (F) wrote: >>> On 2016/1/5 0:55, Will Deacon wrote: >>>> The problem seems to be that we take the debug exception before the >>

Re: [BUG] perf test 21("Test object code reading") failure on ARM64

于 2015/12/20 8:25, Jan Stancek 写道: > On Sat, Dec 19, 2015 at 11:04:21AM +0800, xiakaixu wrote: >> >>>>>... >>> >>> Hi, >>> >>> What is your objdump version? >> >> Hi, >> >> Sorry for the late reply. >>

Re: [BUG] perf test 21("Test object code reading") failure on ARM64

于 2015/12/20 8:25, Jan Stancek 写道: > On Sat, Dec 19, 2015 at 11:04:21AM +0800, xiakaixu wrote: >> >>>>>... >>> >>> Hi, >>> >>> What is your objdump version? >> >> Hi, >> >> Sorry for the late reply. >>

Re: [BUG] perf test 21("Test object code reading") failure on ARM64

>>>... > > Hi, > > What is your objdump version? Hi, Sorry for the late reply. # objdump --version GNU objdump (GNU Binutils) 2.25. I am sure that the system is Little endian. > >>> >>> So the following patch is needed. >>> diff --git a/tools/perf/tests/code-reading.c >>>

Re: [BUG] perf test 21("Test object code reading") failure on ARM64

>>>... > > Hi, > > What is your objdump version? Hi, Sorry for the late reply. # objdump --version GNU objdump (GNU Binutils) 2.25. I am sure that the system is Little endian. > >>> >>> So the following patch is needed. >>> diff --git a/tools/perf/tests/code-reading.c >>>

[BUG] perf test 21("Test object code reading") failure on ARM64

Hi, Perf test "Test object code reading" failed on ARM64 board and the test log is here. ## # perf test -v 21 ... File is: /tmp/oxygen_root-root/lib64/libc-2.19-2014.08.so On file address is: 0x70c3c

[BUG] perf test 21("Test object code reading") failure on ARM64

Hi, Perf test "Test object code reading" failed on ARM64 board and the test log is here. ## # perf test -v 21 ... File is: /tmp/oxygen_root-root/lib64/libc-2.19-2014.08.so On file address is: 0x70c3c

Re: [PATCH V5 1/1] bpf: control events stored in PERF_EVENT_ARRAY maps trace data output when perf sampling

于 2015/10/23 23:12, Peter Zijlstra 写道: > On Fri, Oct 23, 2015 at 02:52:11PM +0200, Peter Zijlstra wrote: >> On Thu, Oct 22, 2015 at 06:28:22PM +0800, Wangnan (F) wrote: >>> information to analysis when glitch happen. Another way we are trying to >>> implement >>> now is to dynamically turn events

Re: [PATCH V5 1/1] bpf: control events stored in PERF_EVENT_ARRAY maps trace data output when perf sampling

于 2015/10/23 23:12, Peter Zijlstra 写道: > On Fri, Oct 23, 2015 at 02:52:11PM +0200, Peter Zijlstra wrote: >> On Thu, Oct 22, 2015 at 06:28:22PM +0800, Wangnan (F) wrote: >>> information to analysis when glitch happen. Another way we are trying to >>> implement >>> now is to dynamically turn events

Re: [PATCH V5 1/1] bpf: control events stored in PERF_EVENT_ARRAY maps trace data output when perf sampling

于 2015/10/21 17:12, Peter Zijlstra 写道: > On Tue, Oct 20, 2015 at 03:53:02PM -0700, Alexei Starovoitov wrote: >> On 10/20/15 12:22 AM, Kaixu Xia wrote: >>> diff --git a/kernel/events/core.c b/kernel/events/core.c >>> index b11756f..5219635 100644 >>> --- a/kernel/events/core.c >>> +++

Re: [PATCH V5 1/1] bpf: control events stored in PERF_EVENT_ARRAY maps trace data output when perf sampling

于 2015/10/21 17:12, Peter Zijlstra 写道: > On Tue, Oct 20, 2015 at 03:53:02PM -0700, Alexei Starovoitov wrote: >> On 10/20/15 12:22 AM, Kaixu Xia wrote: >>> diff --git a/kernel/events/core.c b/kernel/events/core.c >>> index b11756f..5219635 100644 >>> --- a/kernel/events/core.c >>> +++

Re: [PATCH V4 1/1] bpf: control events stored in PERF_EVENT_ARRAY maps trace data output when perf sampling

于 2015/10/20 10:14, Alexei Starovoitov 写道: > On 10/19/15 3:37 AM, Kaixu Xia wrote: >> +/* flags for PERF_EVENT_ARRAY maps*/ >> +enum { >> +BPF_EVENT_CTL_BIT_CUR = 0, >> +BPF_EVENT_CTL_BIT_ALL = 1, >> +__NR_BPF_EVENT_CTL_BITS, >> +}; >> + >> +#defineBPF_CTL_BIT_FLAG_MASK \ >> +

Re: [PATCH V4 1/1] bpf: control events stored in PERF_EVENT_ARRAY maps trace data output when perf sampling

于 2015/10/20 10:14, Alexei Starovoitov 写道: > On 10/19/15 3:37 AM, Kaixu Xia wrote: >> +/* flags for PERF_EVENT_ARRAY maps*/ >> +enum { >> +BPF_EVENT_CTL_BIT_CUR = 0, >> +BPF_EVENT_CTL_BIT_ALL = 1, >> +__NR_BPF_EVENT_CTL_BITS, >> +}; >> + >> +#defineBPF_CTL_BIT_FLAG_MASK \ >> +

Re: [PATCH V3 1/2] bpf: control the trace data output on current cpu when perf sampling

于 2015/10/17 6:06, Alexei Starovoitov 写道: > On 10/16/15 12:42 AM, Kaixu Xia wrote: >> This patch adds the flag dump_enable to control the trace data >> output process when perf sampling. By setting this flag and >> integrating with ebpf, we can control the data output process and >> get the

Re: [PATCH V3 1/2] bpf: control the trace data output on current cpu when perf sampling

于 2015/10/17 6:06, Alexei Starovoitov 写道: > On 10/16/15 12:42 AM, Kaixu Xia wrote: >> This patch adds the flag dump_enable to control the trace data >> output process when perf sampling. By setting this flag and >> integrating with ebpf, we can control the data output process and >> get the

Re: [PATCH V3 1/2] bpf: control the trace data output on current cpu when perf sampling

于 2015/10/17 6:06, Alexei Starovoitov 写道: > On 10/16/15 12:42 AM, Kaixu Xia wrote: >> This patch adds the flag dump_enable to control the trace data >> output process when perf sampling. By setting this flag and >> integrating with ebpf, we can control the data output process and >> get the

Re: [PATCH V3 1/2] bpf: control the trace data output on current cpu when perf sampling

于 2015/10/17 6:06, Alexei Starovoitov 写道: > On 10/16/15 12:42 AM, Kaixu Xia wrote: >> This patch adds the flag dump_enable to control the trace data >> output process when perf sampling. By setting this flag and >> integrating with ebpf, we can control the data output process and >> get the

Re: [PATCH V2 2/2] bpf: control a set of perf events by creating a new ioctl PERF_EVENT_IOC_SET_ENABLER

于 2015/10/15 5:28, Alexei Starovoitov 写道: > On 10/14/15 5:37 AM, Kaixu Xia wrote: >> +event->p_sample_disable = _event->sample_disable; > > I don't like it as a concept and it's buggy implementation. > What happens here when enabler is alive, but other event is destroyed? > >> ---

Re: [PATCH V2 2/2] bpf: control a set of perf events by creating a new ioctl PERF_EVENT_IOC_SET_ENABLER

于 2015/10/15 5:28, Alexei Starovoitov 写道: > On 10/14/15 5:37 AM, Kaixu Xia wrote: >> +event->p_sample_disable = _event->sample_disable; > > I don't like it as a concept and it's buggy implementation. > What happens here when enabler is alive, but other event is destroyed? > >> ---

Re: [RFC PATCH 1/2] perf: Add the flag sample_disable not to output data on samples

于 2015/10/13 3:20, Alexei Starovoitov 写道: > On 10/12/15 2:02 AM, Kaixu Xia wrote: >> diff --git a/include/linux/bpf.h b/include/linux/bpf.h >> index f57d7fe..25e073d 100644 >> --- a/include/linux/bpf.h >> +++ b/include/linux/bpf.h >> @@ -39,6 +39,7 @@ struct bpf_map { >> u32 max_entries; >>

Re: [RFC PATCH 1/2] perf: Add the flag sample_disable not to output data on samples

于 2015/10/13 3:20, Alexei Starovoitov 写道: > On 10/12/15 2:02 AM, Kaixu Xia wrote: >> diff --git a/include/linux/bpf.h b/include/linux/bpf.h >> index f57d7fe..25e073d 100644 >> --- a/include/linux/bpf.h >> +++ b/include/linux/bpf.h >> @@ -39,6 +39,7 @@ struct bpf_map { >> u32 max_entries; >>

Re: [RFC PATCH 0/4] perf tools: Use the new ability of eBPF programs to access hardware PMU counter

于 2015/8/29 9:28, Alexei Starovoitov 写道: > On 8/27/15 3:42 AM, Kaixu Xia wrote: >> An example is pasted at the bottom of this cover letter. In that example, >> we can get the cpu_cycles and exception taken in sys_write. >> >> $ cat /sys/kernel/debug/tracing/trace_pipe >> $ ./perf record

Re: [RFC PATCH 0/4] perf tools: Use the new ability of eBPF programs to access hardware PMU counter

于 2015/8/29 9:28, Alexei Starovoitov 写道: On 8/27/15 3:42 AM, Kaixu Xia wrote: An example is pasted at the bottom of this cover letter. In that example, we can get the cpu_cycles and exception taken in sys_write. $ cat /sys/kernel/debug/tracing/trace_pipe $ ./perf record --event

Re: [PATCH v2 net-next] bpf: s390: Fix build error caused by the struct bpf_array member name changed

于 2015/8/11 16:24, Daniel Borkmann 写道: > On 08/11/2015 08:53 AM, Kaixu Xia wrote: >> There is a build error that "'struct bpf_array' has no member >> named 'prog'" on s390. In commit 2a36f0b, the member 'prog' of >> struct bpf_array is replaced by 'ptrs'. So this patch fixes it. >> >>

Re: [PATCH v2 net-next] bpf: s390: Fix build error caused by the struct bpf_array member name changed

于 2015/8/11 16:24, Daniel Borkmann 写道: On 08/11/2015 08:53 AM, Kaixu Xia wrote: There is a build error that 'struct bpf_array' has no member named 'prog' on s390. In commit 2a36f0b, the member 'prog' of struct bpf_array is replaced by 'ptrs'. So this patch fixes it. Signed-off-by: Kaixu Xia

[RFC] perf ebpf: The example that how to access hardware PMU counter in eBPF programs bu using perf

By combining PMU, kprobe and eBPF program together, many interesting things can be done. For example, by probing at sched:sched_switch we can measure IPC changing between different processes by watching 'cycle' PMU counter; by probing at entry and exit points of a kernel function we are able to

[RFC] perf ebpf: The example that how to access hardware PMU counter in eBPF programs bu using perf

By combining PMU, kprobe and eBPF program together, many interesting things can be done. For example, by probing at sched:sched_switch we can measure IPC changing between different processes by watching 'cycle' PMU counter; by probing at entry and exit points of a kernel function we are able to

Re: [PATCH v6 3/4] bpf: Implement function bpf_perf_event_read() that get the selected hardware PMU conuter

于 2015/8/5 21:53, Peter Zijlstra 写道: > On Wed, Aug 05, 2015 at 12:04:25PM +0200, Peter Zijlstra wrote: >> Also, you probably want a WARN_ON(in_nmi()) there, this function is >> _NOT_ NMI safe. > > I had a wee think about that, and I think the below is safe. > > (with the obvious problem that

Re: [PATCH v6 3/4] bpf: Implement function bpf_perf_event_read() that get the selected hardware PMU conuter

于 2015/8/5 18:04, Peter Zijlstra 写道: > On Tue, Aug 04, 2015 at 08:58:15AM +, Kaixu Xia wrote: >> diff --git a/kernel/events/core.c b/kernel/events/core.c >> index 6251b53..726ca1b 100644 >> --- a/kernel/events/core.c >> +++ b/kernel/events/core.c >> @@ -8599,6 +8599,25 @@ struct

Re: [PATCH v6 3/4] bpf: Implement function bpf_perf_event_read() that get the selected hardware PMU conuter

于 2015/8/5 18:04, Peter Zijlstra 写道: On Tue, Aug 04, 2015 at 08:58:15AM +, Kaixu Xia wrote: diff --git a/kernel/events/core.c b/kernel/events/core.c index 6251b53..726ca1b 100644 --- a/kernel/events/core.c +++ b/kernel/events/core.c @@ -8599,6 +8599,25 @@ struct perf_event_attr

Re: [PATCH v6 3/4] bpf: Implement function bpf_perf_event_read() that get the selected hardware PMU conuter

于 2015/8/5 21:53, Peter Zijlstra 写道: On Wed, Aug 05, 2015 at 12:04:25PM +0200, Peter Zijlstra wrote: Also, you probably want a WARN_ON(in_nmi()) there, this function is _NOT_ NMI safe. I had a wee think about that, and I think the below is safe. (with the obvious problem that WARN from

Re: [PATCH v6 3/4] bpf: Implement function bpf_perf_event_read() that get the selected hardware PMU conuter

于 2015/8/5 1:55, Alexei Starovoitov 写道: > On 8/4/15 1:58 AM, Kaixu Xia wrote: >> +static int check_func_limit(struct bpf_map **mapp, int func_id) > > how about 'check_map_func_compatibility' or 'check_map_func_affinity' ? > >> +{ >> +struct bpf_map *map = *mapp; > > why pass pointer to a

Re: [PATCH v6 3/4] bpf: Implement function bpf_perf_event_read() that get the selected hardware PMU conuter

于 2015/8/5 1:55, Alexei Starovoitov 写道: On 8/4/15 1:58 AM, Kaixu Xia wrote: +static int check_func_limit(struct bpf_map **mapp, int func_id) how about 'check_map_func_compatibility' or 'check_map_func_affinity' ? +{ +struct bpf_map *map = *mapp; why pass pointer to a pointer?

Re: [PATCH v3 2/3] bpf: Implement function bpf_perf_event_read() that get the selected hardware PMU conuter

于 2015/8/3 17:34, Peter Zijlstra 写道: > On Thu, Jul 23, 2015 at 09:42:41AM +, Kaixu Xia wrote: >> +static u64 bpf_perf_event_read(u64 r1, u64 index, u64 r3, u64 r4, u64 r5) >> +{ >> +struct bpf_map *map = (struct bpf_map *) (unsigned long) r1; >> +struct bpf_array *array =

Re: [PATCH v3 2/3] bpf: Implement function bpf_perf_event_read() that get the selected hardware PMU conuter

于 2015/8/3 17:34, Peter Zijlstra 写道: On Thu, Jul 23, 2015 at 09:42:41AM +, Kaixu Xia wrote: +static u64 bpf_perf_event_read(u64 r1, u64 index, u64 r3, u64 r4, u64 r5) +{ +struct bpf_map *map = (struct bpf_map *) (unsigned long) r1; +struct bpf_array *array = container_of(map,

Re: [PATCH v4 1/4] bpf: Make the bpf_prog_array_map more generic

于 2015/7/30 9:44, Alexei Starovoitov 写道: > On 7/29/15 4:17 PM, Daniel Borkmann wrote: >>> -if (map->map_type == BPF_MAP_TYPE_PROG_ARRAY) >>> +if (map->map_type >= BPF_MAP_TYPE_PROG_ARRAY) >>> /* prog_array stores refcnt-ed bpf_prog pointers >>>* release them all when

Re: [PATCH v4 1/4] bpf: Make the bpf_prog_array_map more generic

于 2015/7/30 9:44, Alexei Starovoitov 写道: On 7/29/15 4:17 PM, Daniel Borkmann wrote: -if (map-map_type == BPF_MAP_TYPE_PROG_ARRAY) +if (map-map_type = BPF_MAP_TYPE_PROG_ARRAY) /* prog_array stores refcnt-ed bpf_prog pointers * release them all when user space

Re: [PATCH v2 0/5] bpf: Introduce the new ability of eBPF programs to access hardware PMU counter

于 2015/7/24 7:33, Daniel Borkmann 写道: > On 07/22/2015 10:09 AM, Kaixu Xia wrote: >> Previous patch v1 url: >> https://lkml.org/lkml/2015/7/17/287 > > [ Sorry to chime in late, just noticed this series now as I wasn't in Cc for > the core BPF changes. More below ... ] Sorry about this, will add

Re: [PATCH v2 0/5] bpf: Introduce the new ability of eBPF programs to access hardware PMU counter

于 2015/7/24 7:33, Daniel Borkmann 写道: On 07/22/2015 10:09 AM, Kaixu Xia wrote: Previous patch v1 url: https://lkml.org/lkml/2015/7/17/287 [ Sorry to chime in late, just noticed this series now as I wasn't in Cc for the core BPF changes. More below ... ] Sorry about this, will add you to

Re: [PATCH v3 1/3] bpf: Add new bpf map type to store the pointer to struct perf_event

于 2015/7/24 6:54, Alexei Starovoitov 写道: > On 7/23/15 2:42 AM, Kaixu Xia wrote: >> Introduce a new bpf map type 'BPF_MAP_TYPE_PERF_EVENT_ARRAY'. >> This map only stores the pointer to struct perf_event. The >> user space event FDs from perf_event_open() syscall are converted >> to the pointer to

Re: [PATCH v3 2/3] bpf: Implement function bpf_perf_event_read() that get the selected hardware PMU conuter

于 2015/7/24 6:56, Alexei Starovoitov 写道: > On 7/23/15 2:42 AM, Kaixu Xia wrote: >> According to the perf_event_map_fd and index, the function >> bpf_perf_event_read() can convert the corresponding map >> value to the pointer to struct perf_event and return the >> Hardware PMU counter value. >> >>

Re: [PATCH v3 3/3] samples/bpf: example of get selected PMU counter value

于 2015/7/24 6:59, Alexei Starovoitov 写道: > On 7/23/15 2:42 AM, Kaixu Xia wrote: >> This is a simple example and shows how to use the new ability >> to get the selected Hardware PMU counter value. >> >> Signed-off-by: Kaixu Xia > ... >> +struct bpf_map_def SEC("maps") my_map = { >> +.type =

Re: [PATCH v3 2/3] bpf: Implement function bpf_perf_event_read() that get the selected hardware PMU conuter

于 2015/7/24 6:56, Alexei Starovoitov 写道: On 7/23/15 2:42 AM, Kaixu Xia wrote: According to the perf_event_map_fd and index, the function bpf_perf_event_read() can convert the corresponding map value to the pointer to struct perf_event and return the Hardware PMU counter value.

Re: [PATCH v3 3/3] samples/bpf: example of get selected PMU counter value

于 2015/7/24 6:59, Alexei Starovoitov 写道: On 7/23/15 2:42 AM, Kaixu Xia wrote: This is a simple example and shows how to use the new ability to get the selected Hardware PMU counter value. Signed-off-by: Kaixu Xia xiaka...@huawei.com ... +struct bpf_map_def SEC(maps) my_map = { +.type =

Re: [PATCH v3 1/3] bpf: Add new bpf map type to store the pointer to struct perf_event

于 2015/7/24 6:54, Alexei Starovoitov 写道: On 7/23/15 2:42 AM, Kaixu Xia wrote: Introduce a new bpf map type 'BPF_MAP_TYPE_PERF_EVENT_ARRAY'. This map only stores the pointer to struct perf_event. The user space event FDs from perf_event_open() syscall are converted to the pointer to struct

Re: [PATCH v2 4/5] bpf: Implement function bpf_perf_event_read() that get the selected hardware PMU conuter

于 2015/7/23 10:22, Alexei Starovoitov 写道: > On 7/22/15 7:12 PM, xiakaixu wrote: >> So you mean like this? >> >> u64 bpf_perf_event_read(u64 r1, u64 index,...) >> { >>struct bpf_perf_event_array *array = (void *) (long) r1; >>struct perf_event *event

Re: [PATCH v2 4/5] bpf: Implement function bpf_perf_event_read() that get the selected hardware PMU conuter

于 2015/7/23 9:14, Alexei Starovoitov 写道: > On 7/22/15 1:09 AM, Kaixu Xia wrote: >> According to the perf_event_map_fd and key, the function >> bpf_perf_event_read() can convert the corresponding map >> value to the pointer to struct perf_event and return the >> Hardware PMU counter value. >> >>

Re: [PATCH v2 4/5] bpf: Implement function bpf_perf_event_read() that get the selected hardware PMU conuter

于 2015/7/23 9:14, Alexei Starovoitov 写道: On 7/22/15 1:09 AM, Kaixu Xia wrote: According to the perf_event_map_fd and key, the function bpf_perf_event_read() can convert the corresponding map value to the pointer to struct perf_event and return the Hardware PMU counter value. The key can't

Re: [PATCH v2 4/5] bpf: Implement function bpf_perf_event_read() that get the selected hardware PMU conuter

于 2015/7/23 10:22, Alexei Starovoitov 写道: On 7/22/15 7:12 PM, xiakaixu wrote: So you mean like this? u64 bpf_perf_event_read(u64 r1, u64 index,...) { struct bpf_perf_event_array *array = (void *) (long) r1; struct perf_event *event; ... event = array-events[index

Re: [PATCH] perf: remove the extra validity check on nr_pages

于 2015/1/27 17:55, Kaixu Xia 写道: ping... > The function is_power_of_2() also do the check on nr_pages, > so the first check performed is unnecessary. On the other > hand, the key point is to ensure @nr_pages is a power-of-two > number and mostly @nr_pages is a nonzero value, so in the > most

Re: [PATCH] perf: remove the extra validity check on nr_pages

于 2015/1/27 17:55, Kaixu Xia 写道: ping... The function is_power_of_2() also do the check on nr_pages, so the first check performed is unnecessary. On the other hand, the key point is to ensure @nr_pages is a power-of-two number and mostly @nr_pages is a nonzero value, so in the most cases,

Re: [PATCH] ARM: cns3xxx: fix allmodconfig panic in pci driver

于 2014/9/3 21:27, Arnd Bergmann 写道: > On Wednesday 03 September 2014 21:18:12 Xia Kaixu wrote: >> From: Xia Kaixu >> >> The kernel panic occurs when running an allmodconfig kernel on >> OMAP4460. The inicall "cns3xxx_pcie_init" does not check which >> hardware it's running on and just tries to

Re: [PATCH] ARM: cns3xxx: fix allmodconfig panic in pci driver

于 2014/9/3 21:27, Arnd Bergmann 写道: On Wednesday 03 September 2014 21:18:12 Xia Kaixu wrote: From: Xia Kaixu kaixu@linaro.org The kernel panic occurs when running an allmodconfig kernel on OMAP4460. The inicall cns3xxx_pcie_init does not check which hardware it's running on and just

Re: Does perf support different length of user-space hw_breakpoint?

于 2014/5/13 23:06, Frederic Weisbecker 写道: > On Tue, May 13, 2014 at 02:00:46PM +0200, Jiri Olsa wrote: >> On Mon, May 12, 2014 at 03:52:54PM +0800, xiakaixu wrote: >>> Hi guys, >>> >>> Does perf support different length of user-space hw_breakpoi

Re: Does perf support different length of user-space hw_breakpoint?

ping 于 2014/5/12 17:00, xiakaixu 写道: > 于 2014/5/12 16:48, Peter Zijlstra 写道: >> On Mon, May 12, 2014 at 04:20:44PM +0800, kaixu xia wrote: >>> 2014-05-12 16:05 GMT+08:00 Peter Zijlstra : >>> >>>> On Mon, May 12, 2014 at 03:52:54PM +0800, xiakaixu wrot

Re: Does perf support different length of user-space hw_breakpoint?

ping 于 2014/5/12 17:00, xiakaixu 写道: 于 2014/5/12 16:48, Peter Zijlstra 写道: On Mon, May 12, 2014 at 04:20:44PM +0800, kaixu xia wrote: 2014-05-12 16:05 GMT+08:00 Peter Zijlstra pet...@infradead.org: On Mon, May 12, 2014 at 03:52:54PM +0800, xiakaixu wrote: Hi guys, Does perf support

Re: Does perf support different length of user-space hw_breakpoint?

于 2014/5/13 23:06, Frederic Weisbecker 写道: On Tue, May 13, 2014 at 02:00:46PM +0200, Jiri Olsa wrote: On Mon, May 12, 2014 at 03:52:54PM +0800, xiakaixu wrote: Hi guys, Does perf support different length of user-space hw_breakpoint, such as HW_BREAKPOINT_LEN_1/HW_BREAKPOINT_LEN_2

Re: Does perf support different length of user-space hw_breakpoint?

于 2014/5/12 16:48, Peter Zijlstra 写道: > On Mon, May 12, 2014 at 04:20:44PM +0800, kaixu xia wrote: >> 2014-05-12 16:05 GMT+08:00 Peter Zijlstra : >> >>> On Mon, May 12, 2014 at 03:52:54PM +0800, xiakaixu wrote: >>>> Hi guys, >>>> >>>> Do

Does perf support different length of user-space hw_breakpoint?

Hi guys, Does perf support different length of user-space hw_breakpoint, such as HW_BREAKPOINT_LEN_1/HW_BREAKPOINT_LEN_2/HW_BREAKPOINT_LEN_4/ HW_BREAKPOINT_LEN_8? Seems perf only support HW_BREAKPOINT_LEN_4/sizeof(long) by default from the source code and simple test. May I have your opinions

Does perf support different length of user-space hw_breakpoint?

Hi guys, Does perf support different length of user-space hw_breakpoint, such as HW_BREAKPOINT_LEN_1/HW_BREAKPOINT_LEN_2/HW_BREAKPOINT_LEN_4/ HW_BREAKPOINT_LEN_8? Seems perf only support HW_BREAKPOINT_LEN_4/sizeof(long) by default from the source code and simple test. May I have your opinions

Re: Does perf support different length of user-space hw_breakpoint?

于 2014/5/12 16:48, Peter Zijlstra 写道: On Mon, May 12, 2014 at 04:20:44PM +0800, kaixu xia wrote: 2014-05-12 16:05 GMT+08:00 Peter Zijlstra pet...@infradead.org: On Mon, May 12, 2014 at 03:52:54PM +0800, xiakaixu wrote: Hi guys, Does perf support different length of user-space hw_breakpoint

Re: [PATCH] perf tools: Remove extra '/' character in events file path

于 2014/4/28 8:14, Namhyung Kim 写道: > Hi xiakaixu, > > (Adding Jiri and Boris to CC) OK. thanks, > >> The array debugfs_known_mountpoints[] will cause extra '/' >> character output. >> Remove it. >> >> pre: >> $ perf probe -l >> /sys/k

Re: [PATCH] perf tools: Remove extra '/' character in events file path

于 2014/4/28 8:14, Namhyung Kim 写道: Hi xiakaixu, (Adding Jiri and Boris to CC) OK. thanks, The array debugfs_known_mountpoints[] will cause extra '/' character output. Remove it. pre: $ perf probe -l /sys/kernel/debug//tracing/uprobe_events file does not exist - please rebuild

[PATCH] perf tools: Remove extra '/' character in events file path

The array debugfs_known_mountpoints[] will cause extra '/' character output. Remove it. pre: $ perf probe -l /sys/kernel/debug//tracing/uprobe_events file does not exist - please rebuild kernel with CONFIG_UPROBE_EVENTS. post: $ perf probe -l /sys/kernel/debug/tracing/uprobe_events file does not

[PATCH] perf tools: Remove extra '/' character in events file path

The array debugfs_known_mountpoints[] will cause extra '/' character output. Remove it. pre: $ perf probe -l /sys/kernel/debug//tracing/uprobe_events file does not exist - please rebuild kernel with CONFIG_UPROBE_EVENTS. post: $ perf probe -l /sys/kernel/debug/tracing/uprobe_events file does not

[PATCH] perf tools: Remove extra '/' character in events file path

The array debugfs_known_mountpoints[] will cause extra '/' character output. Remove it. pre: $ perf probe -l /sys/kernel/debug//tracing/uprobe_events file does not exist - please rebuild kernel with CONFIG_UPROBE_EVENTS. post: $ perf probe -l /sys/kernel/debug/tracing/uprobe_events file does not

[PATCH] perf tools: Remove extra '/' character in events file path

The array debugfs_known_mountpoints[] will cause extra '/' character output. Remove it. pre: $ perf probe -l /sys/kernel/debug//tracing/uprobe_events file does not exist - please rebuild kernel with CONFIG_UPROBE_EVENTS. post: $ perf probe -l /sys/kernel/debug/tracing/uprobe_events file does not

Re: A Bug Inquiry in linux/tools/perf/builtin-record.c

于 2014/2/27 10:53, xiakaixu 写道: > Hi Namhyung, > > 于 2014/2/26 16:03, Namhyung Kim 写道: >> Hi xiakaixu, >> >>> 于 2014/2/19 9:48, xiakaixu 写道: >>>> Hi all, >>>> >>>> There is a bug found in my work when running "perf rec

Re: A Bug Inquiry in linux/tools/perf/builtin-record.c

于 2014/2/27 10:53, xiakaixu 写道: Hi Namhyung, 于 2014/2/26 16:03, Namhyung Kim 写道: Hi xiakaixu, 于 2014/2/19 9:48, xiakaixu 写道: Hi all, There is a bug found in my work when running perf record. The basic information is here. As we know, perf record is a parent process and the programme

Re: A Bug Inquiry in linux/tools/perf/builtin-record.c

Hi Namhyung, 于 2014/2/26 16:03, Namhyung Kim 写道: > Hi xiakaixu, > >> 于 2014/2/19 9:48, xiakaixu 写道: >>> Hi all, >>> >>> There is a bug found in my work when running "perf record". The basic >>> information >>> is here. As we

Re: A Bug Inquiry in linux/tools/perf/builtin-record.c

Hi Namhyung, 于 2014/2/26 16:03, Namhyung Kim 写道: Hi xiakaixu, 于 2014/2/19 9:48, xiakaixu 写道: Hi all, There is a bug found in my work when running perf record. The basic information is here. As we know, perf record is a parent process and the programme traced is a child process when

Re: A Bug Inquiry in linux/tools/perf/builtin-record.c

于 2014/2/19 9:48, xiakaixu 写道: > Hi all, > > There is a bug found in my work when running "perf record". The basic > information > is here. As we know, perf record is a parent process and the programme traced > is > a child process when running "perf record&

Re: A Bug Inquiry in linux/tools/perf/builtin-record.c

于 2014/2/19 9:48, xiakaixu 写道: Hi all, There is a bug found in my work when running perf record. The basic information is here. As we know, perf record is a parent process and the programme traced is a child process when running perf record. Sometimes the child process become zombie

A Bug Inquiry in linux/tools/perf/builtin-record.c

Hi all, There is a bug found in my work when running "perf record". The basic information is here. As we know, perf record is a parent process and the programme traced is a child process when running "perf record". Sometimes the child process become zombie state and disappear until the parent

A Bug Inquiry in linux/tools/perf/builtin-record.c

Hi all, There is a bug found in my work when running perf record. The basic information is here. As we know, perf record is a parent process and the programme traced is a child process when running perf record. Sometimes the child process become zombie state and disappear until the parent