linux.git/include/trace/events/ext4.h, branch v2.6.38

ext4: Add new ext4 inode tracepoints

2010-11-08T18:51:33+00:00

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:47+00:00

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:50+00:00

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:07+00:00

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:07+00:00

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:12+00:00

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:05+00:00

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:04+00:00

The allocation_context pointer can be NULL.

Signed-off-by: "Theodore Ts'o"

writeback: pay attention to wbc->nr_to_write in write_cache_pages

2010-06-09T01:12:44+00:00

If a filesystem writes more than one page in ->writepage, write_cache_pages
fails to notice this and continues to attempt writeback when wbc->nr_to_write
has gone negative - this trace was captured from XFS:

    wbc_writeback_start: towrt=1024
    wbc_writepage: towrt=1024
    wbc_writepage: towrt=0
    wbc_writepage: towrt=-1
    wbc_writepage: towrt=-5
    wbc_writepage: towrt=-21
    wbc_writepage: towrt=-85

This has adverse effects on filesystem writeback behaviour. write_cache_pages()
needs to terminate after a certain number of pages are written, not after a
certain number of calls to ->writepage are made.  This is a regression
introduced by 17bc6c30cf6bfffd816bdc53682dd46fc34a2cf4 ("vfs: Add
no_nrwrite_index_update writeback control flag"), but cannot be reverted
directly due to subsequent bug fixes that have gone in on top of it.

Signed-off-by: Dave Chinner 
Reviewed-by: Christoph Hellwig 
Signed-off-by: Linus Torvalds

drop unused dentry argument to ->fsync

2010-05-28T02:05:02+00:00

Signed-off-by: Christoph Hellwig 
Signed-off-by: Al Viro