into hostme.bitkeeper.com:/ua/repos/j/jfs/linux-2.5

into hostme.bitkeeper.com:/ua/repos/j/jfs/linux-2.5

SERIAL_IO_GSC was a mistake and should never have been added.

When drivers/serial was split off, the following helptexts should have
been deleted, but weren't.

The reason for the ftape messup of export-objs is the usage of the
strange FT_KSYM macro in ftape_syms.c.

That exist solely for backwards compatibility for kernel 2.1.18 and older.

Better clean it up.

 - Add FL_SLEEP flag to indicate we intend to sleep and therefore desire
   to be placed on the block list.  Use it for POSIX & flock locks.
 - Remove locks_block_on.
 - Change posix_unblock_lock to eliminate a race that will appear once we
   don't use the BKL any more.
 - Update the comment for locks_same_owner() and rename it to
   posix_same_owner().
 - Change locks_mandatory_area() to allocate its lock on the stack and
   call posix_lock_file() instead of repeating that logic.
 - Rename the "caller" parameter to posix_lock_file() to "request"
   to better show that this is not to be inserted directly.
 - Redo some of the proc code a little.  Stop exposing kernel addresses
   to userspace (whoever thought _that_ was a good idea?!) and show how
   we should be printing the device name.  The last part is ifdeffed
   out to avoid breaking lslk.
 - Remove FL_BROKEN.  And there was much rejoicing.

  Here are some patches for C99 initializers in fs/nfs. Patches
  are against 2.5.32.

  The function save_flags must use unsigned long instead long (signed)
  This trivial patch solves the problem

  The function save_flags must use an unsigned long parameter instead a
  long (signed) one
  This trivial patch solves the problem

  The function save_flags must use an unsigned long parameter instead a
  long (signed) one
  This trivial patch solves the problem

  <asm/io.h> has the normal idempotent construction on every architecture.

  The attached file removes the second #include.

  <linux/init.h> has the normal idempotent construction.

  The attached file removes the second #include.

  The function save_flags must use unsigned long instead long (signed)
  This trivial patch solves the problem

  This is a trivial patch already applied in the -ac tree for the 2.4.19 kernel.
  Patch for lp.c avoid +/- operations with 0 and explicit some debug information
  as KERN_INFO or KERN_ERR.

  drivers/char/Config.in still has a complete copy of agp/Config.in.
  It's an exact cut-n-paste - the md5sums even match. (:

  Bad error path..

  ret is already set to -ENODEV, no need to set them again before
  jumping out.

The old form of designated initializers are obsolete: we need to
replace them with the ISO C forms before 2.6.  Gcc has always supported
both forms anyway.

The old form of designated initializers are obsolete: we need to
replace them with the ISO C forms before 2.6.  Gcc has always supported
both forms anyway.

  The function save_flags must use unsigned long instead long (signed)
  This trivial patch solves the problem

  The function save_flags must use an unsigned long parameter instead a
  long (signed) one

  This trivial patch solves the problem

  <linux/serial.h> has the normal idempotent construction.

  The attached file removes the second #include.

  Trivial patch changes my zip code.  Applies to 2.4.x and 2.5.x trees.

  The function save_flags must use unsigned long instead long (signed)
  This trivial patch solves the problem

  The function save_flags must use unsigned long instead long (signed)
  This trivial patch solves the problem

  The function save_flags must use unsigned long instead long (signed)
  This trivial patch solves the problem

  The function save_flags must use an unsigned long parameter instead a
  long (signed) one

  This trivial patch solves the problem

but also about being called whenever we're holding any
other preemption locks.

version in include/linux didn't get deleted.

Bill Irwin's patch to fix up pte's in highmem.

With CONFIG_HIGHPTE, the direct pte pointer in struct page becomes the
64-bit physical address of the single pte which is mapping this page.

If the page is not PageDirect then page->pte.chain points at a list of
pte_chains, which each now contain an array of 64-bit physical
addresses of the pte's which are mapping the page.

The functions rmap_ptep_map() and rmap_ptep_unmap() are used for
mapping and unmapping the page which backs the target pte.

The patch touches all architectures (adding do-nothing compatibility
macros and inlines).  It generally mangles lots of header files and may
break non-ia32 compiles.  I've had it in testing since 2.5.31.

The pte_chains presently consist of a pte pointer and a `next' link.
So there's a 50% memory wastage here as well as potential for a lot of
misses during walks of the singly-linked per-page list.

This patch increases the pte_chain structure to occupy a full
cacheline.  There are 7, 15 or 31 pte pointers per structure rather
than just one.  So the wastage falls to a few percent and the number of
misses during the walk is reduced.

The patch doesn't make much difference in simple testing, because in
those tests the pte_chain list from the previous page has good cache
locality with the next page's list.

The patch sped up Anton's "10,000 concurrently exitting shells" test by
3x or 4x.  It gives a 10% reduction in system time for a kernel build
on 16p NUMAQ.

It saves memory and reduces the amount of work performed in the slab
allocator.

Pages which are mapped by only a single process continue to not have a
pte_chain.  The pointer in struct page points directly at the mapping
pte (a "PageDirect" pte pointer).  Once the page is shared a pte_chain
is allocated and both the new and old pte pointers are moved into it.

We used to collapse the pte_chain back to a PageDirect representation
in page_remove_rmap().  That has been changed.  That collapse is now
performed inside page reclaim, via page_referenced().  The thinking
here is that if a page was previously shared then it may become shared
again, so leave the pte_chain structure in place.  But if the system is
under memory pressure then start reaping them anyway.