Messages in this thread | | | Date | Wed, 6 May 2009 10:40:14 +0200 | From | Ingo Molnar <> | Subject | Re: [PATCH 4/4] tracing/events: fix concurrent access to ftrace_events list |
| |
* Frederic Weisbecker <fweisbec@gmail.com> wrote:
> On Wed, May 06, 2009 at 10:33:45AM +0800, Li Zefan wrote: > > A module will add/remove its trace events when it gets loaded/unloaded, so > > the ftrace_events list is not "const", and concurrent access needs to be > > protected. > > > > This patch thus fixes races between loading/unloding modules and read > > 'available_events' or read/write 'set_event', etc. > > > > Below shows how to reproduce the race: > > > > # for ((; ;)) { cat /mnt/tracing/available_events; } > /dev/null & > > # for ((; ;)) { insmod trace-events-sample.ko; rmmod sample; } & > > > > After a while: > > > > BUG: unable to handle kernel paging request at 0010011c > > IP: [<c1080f27>] t_next+0x1b/0x2d > > ... > > Call Trace: > > [<c10c90e6>] ? seq_read+0x217/0x30d > > [<c10c8ecf>] ? seq_read+0x0/0x30d > > [<c10b4c19>] ? vfs_read+0x8f/0x136 > > [<c10b4fc3>] ? sys_read+0x40/0x65 > > [<c1002a68>] ? sysenter_do_call+0x12/0x36 > > > > [ Impact: fix races when concurrent accessing ftrace_events list ] > > > > Signed-off-by: Li Zefan <lizf@cn.fujitsu.com> > > > Nice series of fixes! > > Thanks!
I've applied them to tip/tracing/events, thanks guys!
Ingo
| |