kernel/include/trace/events/ext4.h, branch linux-3.0.y

ext4: fixed tracepoints cleanup

2011-06-06T13:51:52Z

While creating fixed tracepoints for ext3, basically by porting them from ext4, I found a lot of useless retyping, wrong type usage, useless variable passing and other inconsistencies in the ext4 fixed tracepoint code. This patch cleans the fixed tracepoint code for ext4 and also simplify some of them. Signed-off-by: Lukas Czerner Signed-off-by: "Theodore Ts'o"

ext4: add more tracepoints and use dev_t in the trace buffer

2011-03-22T01:38:05Z

- Add more ext4 tracepoints. - Change ext4 tracepoints to use dev_t field with MAJOR/MINOR macros so that we can save 4 bytes in the ring buffer on some platforms. - Add sync_mode to ext4_da_writepages, ext4_da_write_pages, and ext4_da_writepages_result tracepoints. Also remove for_reclaim field from ext4_da_writepages since it is usually not very useful. Signed-off-by: Jiaying Zhang Signed-off-by: "Theodore Ts'o"

ext4: Add new ext4 inode tracepoints

2010-11-08T18:51:33Z

Add ext4_evict_inode, ext4_drop_inode, ext4_mark_inode_dirty, and ext4_begin_ordered_truncate() Signed-off-by: "Theodore Ts'o"

Merge branch 'next' into upstream-merge

2010-10-28T03:44:47Z

Conflicts: fs/ext4/inode.c fs/ext4/mballoc.c include/trace/events/ext4.h

ext4,jbd2: convert tracepoints to use major/minor numbers

2010-10-28T02:08:50Z

Unfortunately perf can't deal with anything other than direct structure accesses in the TP_printk() section. It will drop dead when it sees jbd2_dev_to_name() in the "print fmt" section of the tracepoint. Addresses-Google-Bug: 3138508 Signed-off-by: "Theodore Ts'o"

ext4: don't use ext4_allocation_contexts for tracing

2010-10-28T01:30:07Z

Many tracepoints were populating an ext4_allocation_context to pass in, but this requires a slab allocation even when tracepoints are off. In fact, 4 of 5 of these allocations were only for tracing. In addition, we were only using a small fraction of the 144 bytes of this structure for this purpose. We can do away with all these alloc/frees of the ac and simply pass in the bits we care about, instead. I tested this by turning on tracing and running through xfstests on x86_64. I did not actually do anything with the trace output, however. Signed-off-by: Eric Sandeen Signed-off-by: "Theodore Ts'o"

ext4: fix oops in trace_ext4_mb_release_group_pa

2010-10-28T01:30:07Z

Our QA reported an oops in the ext4_mb_release_group_pa tracing, and Josef Bacik pointed out that it was because we may have a non-null but uninitialized ac_inode in the allocation context. I can reproduce it when running xfstests with ext4 tracepoints on, on a CONFIG_SLAB_DEBUG kernel. We call trace_ext4_mb_release_group_pa from 2 places, ext4_mb_discard_group_preallocations and ext4_mb_discard_lg_preallocations In both cases we allocate an ac as a container just for tracing (!) and never fill in the ac_inode. There's no reason to be assigning, testing, or printing it as far as I can see, so just remove it from the tracepoint. Signed-off-by: Eric Sandeen Reviewed-by: Josef Bacik Signed-off-by: "Theodore Ts'o"

ext4: avoid null dereference in trace_ext4_mballoc_discard

2010-10-28T01:27:12Z

ac->inode is set to null in function ext4_mb_release_group_pa(), and then trace_ext4_mballoc_discard(ac) is called, the kernel will panic. BUG: unable to handle kernel NULL pointer dereference at 000000a4 IP: [] ftrace_raw_event_ext4__mballoc+0x54/0xc0 [ext4] *pdpt = 0000000000abd001 *pde = 0000000000000000 Oops: 0000 [#1] SMP Pid: 550, comm: flush-8:16 Not tainted 2.6.36-rc1 #1 SE7320EP2/Altos G530 EIP: 0060:[] EFLAGS: 00010206 CPU: 1 EIP is at ftrace_raw_event_ext4__mballoc+0x54/0xc0 [ext4] EAX: f32ac840 EBX: f3f1cf88 ECX: f32ac840 EDX: 00000000 ESI: f32ac83c EDI: f880b9d8 EBP: 00000000 ESP: f4b77ae4 DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068 Process flush-8:16 (pid: 550, ti=f4b76000 task=f613e540 task.ti=f4b76000) Call Trace: [] ? ext4_mb_release_group_pa+0x121/0x150 [ext4] [] ? ext4_mb_discard_group_preallocations+0x336/0x400 [ext4] [] ? ext4_mb_new_blocks+0x3d1/0x4f0 [ext4] [] ? __make_request+0x10b/0x440 [] ? ext4_ext_map_blocks+0x1334/0x1980 [ext4] [] ? rb_reserve_next_event+0xaa/0x3b0 [] ? ext4_map_blocks+0xd6/0x1d0 [ext4] [] ? mpage_da_map_blocks+0xc7/0x8a0 [ext4] [] ? find_get_pages_tag+0x38/0x110 [] ? __pagevec_release+0x15/0x20 [] ? ext4_da_writepages+0x2b5/0x5d0 [ext4] [] ? __writepage+0x0/0x30 [] ? do_writepages+0x14/0x30 [] ? writeback_single_inode+0xa0/0x240 [] ? writeback_sb_inodes+0xc1/0x180 [] ? writeback_inodes_wb+0x88/0x140 [] ? wb_writeback+0x20b/0x320 [] ? lock_timer_base+0x27/0x50 [] ? wb_do_writeback+0x150/0x190 [] ? bdi_writeback_thread+0x88/0x1f0 [] ? complete+0x40/0x60 [] ? bdi_writeback_thread+0x0/0x1f0 [] ? kthread+0x74/0x80 [] ? kthread+0x0/0x80 [] ? kernel_thread_helper+0x6/0x10 Signed-off-by: Wen Congyang Acked-by: Steven Rostedt Signed-off-by: "Theodore Ts'o"

writeback: remove nonblocking/encountered_congestion references

2010-10-26T23:52:05Z

This removes more dead code that was somehow missed by commit 0d99519efef (writeback: remove unused nonblocking and congestion checks). There are no behavior change except for the removal of two entries from one of the ext4 tracing interface. The nonblocking checks in ->writepages are no longer used because the flusher now prefer to block on get_request_wait() than to skip inodes on IO congestion. The latter will lead to more seeky IO. The nonblocking checks in ->writepage are no longer used because it's redundant with the WB_SYNC_NONE check. We no long set ->nonblocking in VM page out and page migration, because a) it's effectively redundant with WB_SYNC_NONE in current code b) it's old semantic of "Don't get stuck on request queues" is mis-behavior: that would skip some dirty inodes on congestion and page out others, which is unfair in terms of LRU age. Inspired by Christoph Hellwig. Thanks! Signed-off-by: Wu Fengguang Cc: Theodore Ts'o Cc: David Howells Cc: Sage Weil Cc: Steve French Cc: Chris Mason Cc: Jens Axboe Cc: Christoph Hellwig Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds

ext4: fix potential NULL dereference while tracing

2010-07-27T15:56:04Z

The allocation_context pointer can be NULL. Signed-off-by: "Theodore Ts'o"