Re: [PATCH 4/4] tracing/events: fix concurrent access to ftrace_events list

Ingo Molnar
2009-05-06T08:40:44Z

* 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