From: Dave Hansen <haveblue@us.ibm.com>

Documents the information in /proc/meminfo

From: Matt Porter <porter@cox.net>

There was a thread a while back on lkml where Dave Hansen proposed this
simple vmalloc usage reporting patch.  The thread pretty much died out as
most people seemed focused on what VM loading type bugs it could solve.  I
had posted that this type of information was really valuable in debugging
embedded Linux board ports.  A common example is where people do arch
specific setup that limits there vmalloc space and then they find modules
won't load.  ;) Having the Vmalloc* info readily available is real useful in
helping folks to fix their kernel ports.

From: David Mosberger <davidm@napali.hpl.hp.com>

interrupts_open() can easily try to kmalloc() more memory than
supported by kmalloc.  E.g., with 16KB page size and NR_CPUS==64, it
would try to allocate 147456 bytes.

The workaround below is to allocate 4KB per 8 CPUs.  Not really a
solution, but the fundamental problem is that /proc/interrupts
shouldn't use a fixed buffer size in the first place.  I suppose
another solution would be to use vmalloc() instead.  It all feels like
bandaids though.

From: Brian Gerst and David Mosberger

The previous fix to the kmalloc_sizes[] array didn't null-terminate the
correct array.

Fix that up, and also avoid running ARRAY_SIZE() against an array which is
really a null-terminated list.

From: Christoph Hellwig <hch@lst.de>

This patch is from the IA64 tree, with minor cleanups from me.

Split out initialization of pgdat->node_mem_map into a separate function
and allow architectures to override it.  This is needed for HP IA64
machines that have a virtually mapped memory map to support big
memory holes without having to use discontigmem.

(memmap_init_zone is non-static to allow the IA64 code to use it -
 I did that instead of passing it's address into the arch hook as
 it is done currently in the IA64 tree)

From: Christoph Hellwig <hch@lst.de>

This patch is from the IA64 tree, with some minor cleanups by me.
David described it as:

  This is a performance speed up and some minor indendation fixups.

  The problem is that the bootmem code is (a) hugely slow and (b) has
  execution that grow quadratically with the size of the bootmap bitmap.
  This causes noticable slowdowns, especially on machines with (relatively)
  large holes in the physical memory map.  Issue (b) is addressed by
  maintaining the "last_success" cache, so that we start the next search
  from the place where we last found some memory (this part of the patch
  could stand additional reviewing/testing).  Issue (a) is addressed by
  using find_next_zero_bit() instead of the slow bit-by-bit testing.

Time to write a 2M file, one byte at a time:

Before:
        1.09s user 4.92s system 99% cpu 6.014 total
        0.74s user 5.28s system 99% cpu 6.023 total
        1.03s user 4.97s system 100% cpu 5.991 total

After:
	0.79s user 5.17s system 99% cpu 5.993 total
	0.79s user 5.17s system 100% cpu 5.957 total
	0.84s user 5.11s system 100% cpu 5.942 total

From: David Mosberger <davidm@napali.hpl.hp.com>

The patch below is needed to make it possible to map stack pages
without execution permission (as we do on ia64).

If get_block() returns -ENOSPC __block_write_full_page() is currently
clearing PG_uptodate.

Tht doesn't make any sense - failure to allocate space (or an IO error) does
not make the page not uptodate.  It will create pages which are dirty, mapped
into pagetables and not uptodate, which is a nonsensical state.

From: Jan Kara <jack@ucw.cz>

Fixes a deadlock-causing lock-ranking bug between dqio_sem and
journal_start().

It sets up the needed infrastructure so that the quota code's sync_dquot()
operation can call into ext3 and arrange for the transaction start to be
nested outside the taking of dqio_sem.

From: Hugh Dickins <hugh@veritas.com>

This patch removes the long deprecated flush_page_to_ram.  We have
two different schemes for doing this cache flushing stuff, the old
flush_page_to_ram way and the not so old flush_dcache_page etc. way:
see DaveM's Documentation/cachetlb.txt.  Keeping flush_page_to_ram
around is confusing, and makes it harder to get this done right.

All architectures are updated, but the only ones where it amounts
to more than deleting a line or two are m68k, mips, mips64 and v850.

I followed a prescription from DaveM (though not to the letter), that
those arches with non-nop flush_page_to_ram need to do what it did
in their clear_user_page and copy_user_page and flush_dcache_page.

Dave is consterned that, in the v850 nb85e case, this patch leaves its
flush_dcache_page as was, uses it in clear_user_page and copy_user_page,
instead of making them all flush icache as well.  That may be wrong:
I'm just hesitant to add cruft blindly, changing a flush_dcache macro
to flush icache too; and naively hope that the necessary flush_icache
calls are already in place.  Miles, please let us know which way is
right for v850 nb85e - thanks.

I've had a warning in there for 4-5 months and it has never triggered.  I
think it's safe to remove this test.

From: Geert Uytterhoeven <geert@linux-m68k.org>

It updates include/asm-{generic,parisc}/rtc.h for the recent changes in
drivers/char/genrtc.c and include/asm-{m68k,ppc}/rtc.h.

get_rtc_time() now returns some RTC flags instead of a 0/-1 success/failure
indicator.  These flags include:

   - RTC_BATT_BAD: RTC battery is bad (can be detected on PA-RISC)
   - RTC_24H: Clock runs in 24 hour mode

Most of these flags are the same as drivers/char/rtc.c, but RTC_BATT_BAD is a
new one.

radix_tree_delete() currently returns 0 on success, -ENOENT if there was
nothing to delete.

But it is more useful to return the address of the deleted item on success
and NULL if there was no matching item.  It can potentially save a
lookup+delete operation.

- allocated storage `envp' was being leaked on an error path

- kmalloc() returns void*, no need to cast it

- don't return 0 from a void-returning function

Greg has acked this patch.

into kernel.bkbits.net:/home/davem/net-2.5

Noted by David Mosberger:

 "If someone happens to arm a periodic timer at exactly 256 jiffies (as
  ohci happens to do on platforms with HZ=1024), then you end up getting
  an endless loop of timer activations, causing a machine hang.

  The problem is that __run_timers updates base->timer_jiffies _before_
  running the callback routines.  If a callback re-arms the timer at
  exactly 256 jiffies, add_timers() will reinsert the timer into the list
  that we're currently processing, which of course will cause the timer to
  expire immediately again, etc., etc., ad naseum... "

The answer here is to move the whole expired list to a local header and
to not look back.

- Convert nodemgr to new driver model.
- Convert to new module_param() calls.
- Merged fixes for devfs mkdir and some sleep-in-atomic fixes from
  mainline 2.5-bk
- Fix possible memory corruption on highlevel local read/write.
- Fix bitmap usage for some bitops.
- Fix bug in closing ISO stream.
- Fixes for nodemgr probing in the event of a reset storm.
- Workaround for nForce2 firewire chipset. This is preliminary.
- Conversion of SBP-2 to use new driver model in nodemgr, including
  providing a driver for firewire unit directories and registering
  proper callbacks.

into home.transmeta.com:/home/torvalds/v2.5/linux

into kroah.com:/home/greg/linux/BK/gregkh-2.5

into kroah.com:/home/greg/linux/BK/i2c-2.5

the driver should not mess with configurations here.

there's no reason this driver should mess with configurations.

Found by Rik van Riel:

 "There's a serious bug in the handling of the pointer returned
  by kmap_atomic() in nfs/dir.c.   The pointer (part of desc) is
  passed into find_dirent_name and from there into dir_decode,
  which modifies the pointer.

  That means you end up passing a wrong address to kunmap_atomic()."

into home.transmeta.com:/home/torvalds/v2.5/linux

into home.transmeta.com:/home/torvalds/v2.5/linux

into kernel.bkbits.net:/home/davem/net-2.5