With data=ordered it is often the case that a quick write-and-truncate will
leave large numbers of pages on the page LRU with no ->mapping, and attached
buffers.  Because ext3 was not ready to let the pages go at the time of
truncation.

These pages are trivially reclaimable, but their seeming absence makes the VM
overcommit accounting confused (they don't count as "free", nor as
pagecache).  And they make the /proc/meminfo stats look odd.

So what we do here is to try to strip the buffers from these pages as the
buffers exit the journal commit.

This was a flag which said "the transaction's time is active".
timer_pending() could have told us that, but in fact there is no need to
query it at all.

Fix various problems which cropped up due to MAP_SHARED traffic on
data=journal with blocksize < PAGE_CACHE_SIZE.

All relate to handling the "pending truncate" buffers outside i_size.

start_this_handle() can decide to add this handle to a transaction, but
kjournald then moves the handle into commit phase.

Extend the coverage of j_state_lock so that start_this_transaction()'s
examination of journal->j_state is atomic wrt journal_commit_transaction().

Try to trap some more state when an assertion which cannot happen happens.

Before taking the highly-taken j_list_lock, take a peek to seem if this
buffer is already journalled and in the appropriate state.

ext3 no longer keeps the filesystem-wide free blocks counter and free inodes
counter up to date all the time in the superblock.  Because that requires
fs-wide locking.  These counters are only needed at runtime for the Orlov
allocator heuristics, and we are now using a fuzzy per-cpu coutner for that.

These counters are rather unnecessary: the same info is present in the file
allocation maps and inode tables, the group descriptor blocks and the
bitmaps.

e2fsck will be changed to downgrade the seriousness of this inconsistency.

The filesystem _will_ write these numbers out in the superblock on a clean
unmount, based on the sum of the free block and inode counts in the group
descriptors.

From: Andreas Gruenbacher <agruen@suse.de>

This function can leak a posix_acl on an error path.

The ioctl handler can leave a transaction open on an error path.  That
will wedge up the filesystem.

add a dump_stack() to a can't-happen path which happened during development.

There is a race between transaction commit's attempt to free journal_heads
and journal_try_to_free_buffers' attempt.

Fix that by taking a ref against the journal_head in
journal_try_to_free_buffers().

ext3's fully data-journalled mode has been broken for a year.  This patch
fixes it up.

The prepare_write/commit_write/writepage implementations have been split up.
Instead of having each function handle all three journalling mode we now have
three separate sets of address_space_operations.

The problematic part of data=journal is MAP_SHARED writepage traffic: pages
which don't have buffers.  In 2.4 these were cheatingly treated as
data-ordered buffers and that caused several nasty problems.

Here we do it properly: writepage traffic is fully journalled.  This means
that the various workarounds for the 2.4 scheme can be removed, when I
remember where they all are.

The PG_checked flag has been borrowed: it it set in the atomic set_page_dirty
a_op to tell the subsequent writepage() that this page needs to have buffers
attached, dirtied and journalled.

This rather defines PG_checked as "fs-private info in page->flags" and it
should be renamed sometime.

Avoid holding the journal's j_list_lock while copying the buffer_head's data.
We hold jbd_lock_bh_state() during the copy, which is all that is needed.

In start_this_handle() the caller does not have a handle ref pinning the
transaction open, and so the call to log_start_commit() is racy because some
other CPU could take the transaction into commit state independently.

Fix that by holding j_state_lock (which pins j_running_transaction) across
the log_start_commit() call.

Plug a conceivable race with the freeing up of trasnactions, and add some
more debug checks.

Drop in a few assertions to ensure that the locking rules are being adhered
to.

Add a comment describing why a race isn't there.

After ext3_writepage() has called block_write_full_page() it will walk the
page's buffer ring dropping the buffer_head refcounts.

It does this wrong - on the final loop it will dereference the buffer_head
which it just dropped the refcount on.  Poisoned oopses have been seen
against bh->b_this_page.

Change it to take a local copy of b_this_page prior to dropping the bh's
refcount.

We need to check that buffer is still journalled _after_ taking the right
locks.

There's a bug: a caller tries to journal a buffer and then decides he didn't
want to after all.  He calls journal_release_buffer().

But journal_release_buffer() is only allowed to give the caller a buffer
credit back if it was the caller who added the buffer in the first place.

journal_release_buffer() currently looks at the buffer state to work that
out, but gets it wrong: if the buffer has been moved onto a different list by
some other part of ext3 the credit is bogusly not returned to the caller and
the fs can later go BUG due to handle credit exhaustion.


The fix:

Change journal_get_undo_access() to return the number of buffers which the
caller actually added to the journal.  (one or zero).

When the caller later calls journal_release_buffer(), he passes in that
count, to tell journal_release_buffer() how many credits the caller should
get back.

For API consistency this change should also be made to
journal_get_create_access() and journal_get_write_access().  But there is no
requirement for that in ext3 at this time.


The remaining bug:

This logic effectively gives another transaction handle a free buffer credit.
These could conceivably accumulate and cause a journal overflow.  This is a
separate problem and needs changes to the t_outstanding_credits accounting
and the logic in start_this_handle.

This filesystem-wide sleeping lock is no longer needed.  Remove it.

lock_kernel() is no longer needed in JBD.  Remove all the lock_kernel() calls
from fs/jbd/.

Here is where I get to say "ex-parrot".

Remove the remaining sleep_on() calls from JBD.

From: Alex Tomas <bzzz@tmi.comex.ru>

We're about to remove lock_journal(), and it is lock_journal which separates
the running and committing transaction's revokes on the single revoke table.

So implement two revoke tables and rotate them at commit time.

Impement the designed locking around journal->j_commit_request.

Implement the designed locking around journal->j_commit_sequence.

Implement the designed locking around journal->j_free.

Things get a lot better here, too.

Implement the designed locking around journal->j_tail.

Implement the designed locking around journal->j_head.

Implement the designed locking around j_checkpoint_transactions.  It was all
pretty much there actually.

Go through all sites which use j_committing_transaction and ensure that the
deisgned locking is correctly implemented there.

Implement the designed locking around journal->j_running_transaction.

A lot more of the new locking scheme falls into place.

We now start to move onto the fields of the topmost JBD data structure: the
journal.

The patch implements the designed locking around the j_barrier_count member.
And as a part of that, a lot of the new locking scheme is implemented.
Several lock_kernel()s and sleep_on()s go away.

Provide the designed locking around the transaction's t_jcb callback list.

It turns out that this is wholly redundant at present.

Implement the designed locking for t_outstanding_credits

Provide the designating locking for transaction_t.t_updates.

Now we move more into the locking of the transaction_t fields.

t_nr_buffers locking is just an audit-and-commentary job.

This was a system-wide spinlock.

Simple transformation: make it a filesystem-wide spinlock, in the JBD
journal.

That's a bit lame, and later it might be nice to make it per-transaction_t.
But there are interesting ranking and ordering problems with that, especially
around __journal_refile_buffer().

Implement the designated b_tnext locking.

This also covers b_tprev locking.

Go through all b_next_transaction instances, implement locking rules.
(Nothing to do here - b_transaction locking covered it)