JFS has always used ugly debug macros, jFYI, jEVENT, & jERROR.  I have
replaced them with simpler jfs_info(), jfs_warn(), & jfs_err().

This is in preparation for sync_fs super_operation.

The logic surrounding COMMIT_Holdlock was well-intentioned to reduce
latency when deleting files, but it can also result in a hang that I don't
have good fix for.  I don't think removing this will hurt our overall
performance very much.

JFS currently writes a journal page as any transaction is committed, as
long as there is no current journal I/O.  This results in a lot of partial
journal pages being written, even if no threads are waiting for the commit
to complete.  This patch avoids these partial page writes if the transaction
being committed is asynchronous (lazy).  It a couple places, we need to
make sure that the group commit is performed to flush all transactions to
disk.

The metadata representing the directory entries' persistent index has been
mapped to the directory inode's address space.  This was the cause of much
ugliness in the code to avoid the inode being released from the inode cache
while there was still dirty metadata mapped to the inode.

This patch moves this metadata to the block device inode's address space,
which allows us to clean up the code somewhat.

txForce() was not doing what it was supposed to do.  Setting the META_sync
flag in the metapage will force the page to disk when the metapage is
released.

These pages must be written to disk to ensure that replaying the log will
correctly update the inode map.

In txLazyCommit, we are releasing log->gclock (LOGGC_LOCK) before
checking tblk->flag for tblkGC_LAZY.  For the case that tblkGC_LAZY
is not set, the user thread may release the tblk, and it may be
reused and the tblkGC_LAZY bit set again, between the time we release
the spinlock until we check the flag.  This is a lot to happen in an
SMP environment, but when CONFIG_PREEMPT is set, it is very easy to
see the problem.

The fix is to hold the spinlock until after we've checked the flag.

(Yes, I know the symbol names are ugly.)

Avoid racing on signal delivery with thread signal blocking in thread
groups.

The method to do this is to eliminate the per-thread sigmask_lock, and
use the per-group (per 'process') siglock for all signal related
activities.  This immensely simplified some of the locking interactions
within signal.c, and enabled the fixing of the above category of signal
delivery races.

This became possible due to the former thread-signal patch, which made
siglock an irq-safe thing.  (it used to be a process-context-only
spinlock.) And this is even a speedup for non-threaded applications:
only one lock is used.

I fixed all places within the kernel except the non-x86 arch sections.
Even for them the transition is very straightforward, in almost every
case the following is sufficient in arch/*/kernel/signal.c:

		:1,$s/->sigmask_lock/->sig->siglock/g

 This makes daemonize() call reparent_to_init() itself, as long
suggested for 2.5, and fixes the callers so they don't call it again.
Also fixes callers which set current->tty to NULL themselves (also
no longer neccessary).

This is a performance and correctness fix against the writeback paths.

The writeback code has competing requirements.  Sometimes it is used
for "memory cleansing": kupdate, bdflush, writer throttling, page
allocator writeback, etc.  And sometimes this same code is used for
data integrity pruposes: fsync, msync, fdatasync, sync, umount, various
other kernel-internal uses.

The problem is: how to handle a dirty buffer or page which is currently
under writeback.

For memory cleansing, we just want to skip that buffer/page and go onto
the next one.  But for sync, we must wait on the old writeback and then
start new writeback.

mpage_writepages() is current correct for cleansing, but incorrect for
sync.  block_write_full_page() is currently correct for sync, but
inefficient for cleansing.

The fix is fairly simple.

- In mpage_writepages(), don't skip the page is it's a sync
operation.

- In block_write_full_page(), skip the buffer if it is a sync
operation.  And return -EAGAIN to tell the caller that the writeout
didn't work out.  The caller must then set the page dirty again and
move it onto mapping->dirty_pages.

This is an extension of the writepage API: writepage can now return
EAGAIN.  There are only three callers, and they have been updated.

fail_writepage() and ext3_writepage() were actually doing this by
hand.  They have been changed to return -EAGAIN.  NTFS will want to
be able to return -EAGAIN from its writepage as well.

- A sticky question is: how to tell the writeout code which mode it
is operating in?  Cleansing or sync?

It's such a tiny code change that I didn't have the heart to go and
propagate a `mode' argument down every instance of writepages() and
writepage() in the kernel.  So I passed it in via current->flags.

Incidentally, the occurrence of a locked-and-dirty buffer in
block_write_full_page() is fairly rare: normally the collision avoidance
happens at the address_space level, via PageWriteback.  But some
mappings (blockdevs, ext3 files, etc) have their dirty buffers written
out via submit_bh().  It is these buffers which can stall
block_write_full_page().

This wart will be pretty intrusive to fix.  ext3 needs to become fully
page-based (ugh.  It's a block-based journalling filesystem, and pages
are unnatural).  blockdev mappings are still written out by buffers
because that's how filesystems use them.  Putting _all_ metadata
(indirects, inodes, superblocks, etc) into standalone address_spaces
would fix that up.

- filemap_fdatawrite() sets PF_SYNC.  So filemap_fdatawrite() is the
kernel function which will start writeback against a mapping for
"data integrity" purposes, whereas the unexported, internal-only
do_writepages() is the writeback function which is used for memory
cleansing.  This difference is the reason why I didn't consolidate
those functions ages ago...

- Lots of code paths had a bogus extra call to filemap_fdatawait(),
which I previously added in a moment of weak-headedness.  They have
all been removed.

Kernel threads take a void * argument
Fix compiler warnings in printk statement on 64-bit architectures

This is invoked by mount -remount,resize=<blocks>.
See Documentation/filesystems/jfs.txt for more information.

In order for JFS to be able to quiesce the current activity, while
blocking new transactions, the locking needed some rework.  New
transactions are stopped in the functions txBegin or txBeginAnon,
where the rdwrlock (IREAD_LOCK/IWRITE_LOCK) may be held.  Dirty
inodes may need to be committed while new transactions are blocked
here, so another lock is introduced (commit_sem) which is taken after
txBegin/txBeginAnon is called.  This ensures that the proper
serialization takes place, without the write_inode method needing to
grab the rdwrlock.

In addition, the use of IWRITE_LOCK and IREAD_LOCK has been removed
from directory inodes.  The serialization done by the VFS using i_sem
is sufficient to avoid races.

This patch removes JFS's dependency on down_write_trylock.

Simple janitoral code cleanup submitted by Christoph Hellwig

A little cleanup: Most callers of list_splice() immediately
reinitialise the source list_head after calling list_splice().

So create a new list_splice_init() which does all that.

Currently, if CONFIG_JFS_DEBUG is not set, no entries are created
under /proc/fs/jfs, even if CONFIG_JFS_STATISTICS is set.

I've got to keep my 2.4 and 2.5 patches straight!

In the case where a large truncate requires multiple transactions,
we were setting the COMMIT_Nolink flag too early, causing an
assert to fire during the next transaction in the sequence.

Timing window between JFS threads dropping a lock and going to sleep
allowed a waker to send wake_up_process right before wakee slept.
This resulted in the thread going to sleep indefinately.

misc gratitious kdev_t uses fixed (janitorial stuff - e.g. quota
patches had reintroduced kdevname(sb->s_dev) in places where we'd
switched to sb->s_id, etc.)

He has added significant content to these files.

There was a bug truncating large files to non-zero lengths which led
to space not being marked free in the block map.

The lock.h header contained some hand-crafted lcoking routines from
the pre-SMP days.  In 2.5 only lock_super/unlock_super are left,
guarded by a number of completly unrelated (!) includes.

This patch moves lock_super/unlock_super to fs.h, which defined
struct super_block that is needed for those to operate it, removes
locks.h and updates all caller to not include it and add the missing,
previously nested includes where needed.

This prevents a deadlock in JFS.

- Fixes a performance problem - callers of
  prepare_write/commit_write, etc are locking pages, which synchronises
  them behind writeback, which also locks these pages.  Significant
  slowdowns for some workloads.

- So pages are no longer locked while under writeout.  Introduce a
  new PG_writeback and associated infrastructure to support this design
  change.

- Pages which are under read I/O still use PageLocked.  Pages which
  are under write I/O have PageWriteback() true.

  I considered creating Page_IO instead of PageWriteback, and marking
  both readin and writeout pages as PageIO().  So pages are unlocked
  during both read and write.  There just doesn't seem a need to do
  this - nobody ever needs unblocking access to a page which is under
  read I/O.

- Pages under swapout (brw_page) are PageLocked, not PageWriteback.
  So their treatment is unchangeded.

  It's not obvious that pages which are under swapout actually need
  the more asynchronous behaviour of PageWriteback.

  I was setting the swapout pages PageWriteback and unlocking them
  prior to submitting the buffers in brw_page().  This led to deadlocks
  on the exit_mmap->zap_page_range->free_swap_and_cache path.  These
  functions call block_flushpage under spinlock.  If the page is
  unlocked but has locked buffers, block_flushpage->discard_buffer()
  sleeps.  Under spinlock.  So that will need fixing if for some reason
  we want swapout to use PageWriteback.

  Kernel has called block_flushpage() under spinlock for a long time.
   It is assuming that a locked page will never have locked buffers.
  This appears to be true, but it's ugly.

- Adds new function wait_on_page_writeback().  Renames wait_on_page()
  to wait_on_page_locked() to remind people that they need to call the
  appropriate one.

- Renames filemap_fdatasync() to filemap_fdatawrite().  It's more
  accurate - "sync" implies, if anything, writeout and wait.  (fsync,
  msync) Or writeout.  it's not clear.

- Subtly changes the filemap_fdatawrite() internals - this function
  used to do a lock_page() - it waited for any other user of the page
  to let go before submitting new I/O against a page.  It has been
  changed to simply skip over any pages which are currently under
  writeback.

  This is the right thing to do for memory-cleansing reasons.

  But it's the wrong thing to do for data consistency operations (eg,
  fsync()).  For those operations we must ensure that all data which
  was dirty *at the time of the system call* are tight on disk before
  the call returns.

  So all places which care about this have been converted to do:

	filemap_fdatawait(mapping);	/* Wait for current writeback */
	filemap_fdatawrite(mapping);	/* Write all dirty pages */
	filemap_fdatawait(mapping);	/* Wait for I/O to complete */

- Fixes a truncate_inode_pages problem - truncate currently will
  block when it hits a locked page, so it ends up getting into lockstep
  behind writeback and all of the file is pointlessly written back.

  One fix for this is for truncate to simply walk the page list in the
  opposite direction from writeback.

  I chose to use a separate cleansing pass.  It is more
  CPU-intensive, but it is surer and clearer.  This is because there is
  no reason why the per-address_space ->vm_writeback and
  ->writeback_mapping functions *have* to perform writeout in
  ->dirty_pages order.  They may choose to do something totally
  different.

  (set_page_dirty() is an a_op now, so address_spaces could almost
  privatise the whole dirty-page handling thing.  Except
  truncate_inode_pages and invalidate_inode_pages assume that the pages
  are on the address_space lists.  hmm.  So making truncate_inode_pages
  and invalidate_inode_pages a_ops would make some sense).

Removes inode.i_dirty_data_buffers.  It's no longer used - all dirty
buffers have their pages marked dirty and filemap_fdatasync() /
filemap_fdatawait() catches it all.

Updates all callers.

This required a change in JFS - it has "metapages" which
are a container around a page which holds metadata.  They
were holding these pages locked and were relying on fsync_inode_data_buffers
for writing them out.  So fdatasync() deadlocked.

I've changed JFS to not lock those pages.  Change was acked
by Dave Kleikamp <shaggy@austin.ibm.com> as the right
thing to do, but may not be complete.  Probably igrab()
against ->host is needed to pin the address_space down.

Original fix from Andi Kleen

Submitted by Christoph Hellwig and Dave Kleikamp

From Christoph Hellwig

http://oss.software.ibm.com/pipermail/jfs-patches/2002-March/000045.html

These files use completion, but don't include header.