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:
[19314.529510s][pid:2694,cpu3,GAC_Execu
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 f2fs_
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 swit
Xia
On Thu, Sep 08, 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
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
Sorry for noise!
--
Regards
Kaixu Xia
于 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.
于 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
> + 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);
> +
> +
于 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 @
> 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);
> EXPORT_TR
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
>>
于 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.
>>
>>>...
>
> 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
>>> b/tools/perf/t
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
Objd
于 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 o
于 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
>>> +++ b/kernel/event
于 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 \
>> +((
于 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 samples
于 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 samples
于 2015/10/15 5:28, Alexei Starovoitov 写道:
> On 10/14/15 5:37 AM, Kaixu Xia wrote:
>> +event->p_sample_disable = &enabler_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?
>
>> --- a/k
于 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;
>>
于 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
于 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
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 com
于 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
于 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
于 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 poi
于 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(m
于 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 u
于 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
于 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 st
于 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.
>>
>> S
于 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 = BPF
于 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
于 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
于 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
于 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 ac
于 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
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
于 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
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 i
于 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
>&
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
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
于 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&q
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 kno
于 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&
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 pro
49 matches
Mail list logo