From: "leilei.lin"
A performance issue caused by less strickly check in task
sched when these tasks were once attached by per-task perf_event.
A task will alloc task->perf_event_ctxp[ctxn] when it was called
by perf_event_open, and task->perf_event_ctxp[ctxn] would
From: "leilei.lin"
A performance issue caused by less strickly check in task
sched when these tasks were once attached by per-task perf_event.
A task will alloc task->perf_event_ctxp[ctxn] when it was called
by perf_event_open, and task->perf_event_ctxp[ctxn] would
From: "leilei.lin"
A performance issue caused by less strickly check in task
sched when these tasks were once attached by per-task perf_event.
A task will alloc task->perf_event_ctxp[ctxn] when it was called
by perf_event_open, and task->perf_event_ctxp[ctxn] would
From: "leilei.lin"
A performance issue caused by less strickly check in task
sched when these tasks were once attached by per-task perf_event.
A task will alloc task->perf_event_ctxp[ctxn] when it was called
by perf_event_open, and task->perf_event_ctxp[ctxn] would
From: "leilei.lin"
locklessly and integrally copy dentry name. It will be used later for
bugfix
Signed-off-by: leilei.lin
---
fs/dcache.c| 38 ++
include/linux/dcache.h | 2 ++
2 files
From: "leilei.lin"
Slub alloced mem overwritten ocurrs when fsnotify thread was copying the
dentry name and another rename thread change the dentry name at same
time.
These patches do the following:
1. A new copy_dname method was created which copy file_name to new
From: "leilei.lin"
Kernel got panicked in inotify_handle_event, while running the rename
operation against the same file. The root cause is that the race between
fsnotify thread and file rename thread. When fsnotify thread was
copying the dentry name, another rename
From: "leilei.lin"
A performance issue caused by less strickly check in task
sched when these tasks were once attached by per-task perf_event.
A task will alloc task->perf_event_ctxp[ctxn] when it was called
by perf_event_open, and task->perf_event_ctxp[ctxn] would not
ever be freed to NULL.
From: "leilei.lin"
A performance issue caused by less strickly check in task
sched when these tasks were once attached by per-task perf_event.
A task will alloc task->perf_event_ctxp[ctxn] when it was called
by perf_event_open, and task->perf_event_ctxp[ctxn] would not
ever be freed to NULL.
From: "leilei.lin"
A performance issue caused by less strickly check in task
sched when these tasks were once attached by per-task perf_event.
A task will alloc task->perf_event_ctxp[ctxn] when it was called
by perf_event_open, and task->perf_event_ctxp[ctxn] would not
ever be freed to NULL.
From: "leilei.lin"
A performance issue caused by less strickly check in task
sched when these tasks were once attached by per-task perf_event.
A task will alloc task->perf_event_ctxp[ctxn] when it was called
by perf_event_open, and task->perf_event_ctxp[ctxn] would not
ever be freed to NULL.
From: "leilei.lin"
locklessly and integrally copy dentry name. It will be used later for
bugfix
Signed-off-by: leilei.lin
---
fs/dcache.c| 38 ++
include/linux/dcache.h | 2 ++
2 files changed, 40 insertions(+)
diff --git a/fs/dcache.c
From: "leilei.lin"
Slub alloced mem overwritten ocurrs when fsnotify thread was copying the
dentry name and another rename thread change the dentry name at same
time.
These patches do the following:
1. A new copy_dname method was created which copy file_name to new alloc mem.
The later
From: "leilei.lin"
Kernel got panicked in inotify_handle_event, while running the rename
operation against the same file. The root cause is that the race between
fsnotify thread and file rename thread. When fsnotify thread was
copying the dentry name, another rename thread could change the
14 matches
Mail list logo