From: CaT <cat@zip.com.au>

What this patch does is allow you to specify the max amount of memory tmpfs
can use as a percentage of available real ram.  This (in my eyes) is useful
so that you do not have to remember to change the setting if you want
something other then 50% and some of your ram goes.

Hugh redid the arithmetic to not overflow at 4GB; the particular order of
lines helps RH's gcc-2.96-110 not to get confused in the do_div.  2.5 can use
totalram_pages.  Update mount options in tmpfs Doc.

There's an argument that the percentage should be of ram+swap, that's what
Christoph originally intended.  But we set the default at 50% of ram only, so
I believe it's more consistent to follow that precedent.

From: Hugh Dickins <hugh@veritas.com>

cond_resched each time around the loop in shmem_file_write
and do_shmem_file_read, matching filemap.c.

From: Hugh Dickins <hugh@veritas.com>

tmpfs pages should be surfing the LRUs in the company of their filemap
friends: I was expecting the rules to change, but they've been stable so
long, let's sprinkle mark_page_accessed in the equivalent places here; but
(don't ask me why) SetPageReferenced in shmem_file_write.  Ooh, and
shmem_populate was missing a flush_page_to_ram.

From: Hugh Dickins <hugh@veritas.com>

default_llseek's use of BKL and not i_sem was recently exposed:
tmpfs should be using generic_file_llseek which guards with i_sem.

From: Hugh Dickins <hugh@veritas.com>

shmem_readpage was created to give tmpfs sendfile and loop ability; but
they're both using shmem_file_sendfile now, so remove shmem_readpage.

From: Hugh Dickins <hugh@veritas.com>

Remove the duplicated checks in shmem_file-write(), use
generic_write_checks() instead.

From: Hugh Dickins <hugh@veritas.com>

When handling rlimit != RLIM_INFINITY, generic_write_checks tests file
position against 0xFFFFFFFFULL, and casts it to a u32.  This code is
carried forward from 2.4.4, and the 2.4-ac tree contains an apparently
obvious fix to one part of it (should set count to 0 not to a negative).
But when you think it through, it all turns out to be bogus.

On a 32-bit architecture: limit is a 32-bit unsigned long, we've
already handled *pos < 0 and *pos >= limit, so *pos here has no way
of being > 0xFFFFFFFFULL, and thus casting it to u32 won't truncate it.
And on a 64-bit architecture: limit is a 64-bit unsigned long, but this
code is disallowing file position beyond the 32 bits; or if there's some
userspace compatibility issue, with limit having to fit into 32 bits,
the 32-bit architecture argument applies and they're still irrelevant.

So just remove the 0xFFFFFFFFULL test; and in place of the u32, cast to
typeof(limit) so it's right even if rlimits get wider.  And there's no
way we'd want to send SIGXFSZ below the limit: remove send_sig comment.

There's a similarly suspicious u32 cast a little further down, when
checking MAX_NON_LFS.  Given its definition, that does no harm on any
arch: but it's better changed to unsigned long, the type of MAX_NON_LFS.

RAID5 is calling copy_data() under sh->lock.  But copy_data() does kmap(),
which can sleep.

The best fix is to use kmap_atomic() in there.  It is faster than kmap() and
does not block.

The patch removes the unused bio_kmap() and replaces __bio_kmap() with
__bio_kmap_atomic().  I think it's best to withdraw the sleeping-and-slow
bio_kmap() from the kernel API before someone else tries to use it.


Also, I notice that bio_kmap_irq() was using local_save_flags().  This is a
bug - local_save_flags() does not disable interrupts.  Converted that to
local_irq_save().  These names are terribly chosen.

This patch was acked by Jens and Neil.

From: "Martin J. Bligh" <mbligh@aracnet.com>

Fix a couple of instances of "warning: suggest parentheses around assignment
used as truth value".

From: john stultz <johnstul@us.ibm.com>

This patch, written with the advice of Joel Becker, addresses a problem with
the hangcheck-timer.

The basic problem is that the hangcheck-timer code (Required for Oracle)
needs a accurate hard clock which can be used to detect OS stalls (due to
udelay() or pci bus hangs) that would cause system time to skew (its sort of
a sanity check that insures the system's notion of time is accurate).
However, currently they are using get_cycles() to fetch the cpu's TSC
register, thus this does not work on systems w/o a synced TSC.

As suggested by Andi Kleen (see thread here:
http://www.uwsg.iu.edu/hypermail/linux/kernel/0302.0/1234.html ) I've worked
with Joel and others to implement the monotonic_clock() interface.  Some of
the major considerations made when writing this patch were

o Needs to be able to return accurate time in the absence of multiple timer
  interrupts

o Needs to be abstracted out from the hardware

o Avoids impacting gettimeofday() performance

This interface returns a unsigned long long representing the number of
nanoseconds that has passed since time_init().

From: "J. Bruce Fields" <bfields@fieldses.org>

If the NFS daemon is presented with a filehandle for a file that has
been deleted, it does an iget() in fs/exportfs/expfs.c:export_iget() and
gets a bad inode back.  When it subsequently iput()s the inode, the
result is:

Mar 27 12:53:40 snoopy kernel: EXT2-fs error (device ide0(3,3)): ext2_free_blocks: Freeing blocks not in datazone - block = 1802201963, count = 27499
Mar 27 12:53:40 snoopy kernel: Remounting filesystem read-only

The same can happen if ext2_get_inode() returns an error - ext2_read_inode()
will return an uninitialised inode and ext2_put_inode() is not allowed to go
looking inside the bad inode.

From: Hugh Dickins <hugh@veritas.com>

The blk_congestion_waits in shmem_getpage are appropriate when the error is
-ENOMEM, but not when the error is -EEXIST.  So add that test in the first
instance, but omit it all in the second instance.

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

For some reason which I cannot remember, we didn't use the automatic
dependency generation for the generated .mod.[co] files. However, we do
of course need dependency information for those, too, they need to be updated
when e.g. the kernel version number changes.

This patch fixes two issues:
o The CONFIG_MODVERSIONING=y case broke at compile time since some
  functions were not updated with the latest module changes
o Exporting symbols from modules stopped working due to confusion of
  mod->num_syms and mod->num_ksyms. Rename mod->num_ksyms to mod->num_syms,
  which is more logical since the associated array is called ->syms, and
  for the kallsyms member use "num_symtab", since the associated array is
  ->symtab.

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

This should have a working w83781d driver updated for 2.5.66-bk4.
Currently sysfs support is working, and are according to the spec
(sensors-sysfs) in the 'lm sensors sysfs file structure' thread.
Thus I used 'temp_input[1-3]', as there was not final decision
on having them temp_input[0-2] as well, for example.

(the users of this function have already been changed in previous patches)

This still needs to be converted to use sysfs files, but due to
lack of hardware, I can not do this.  This change is necessary as
the sysctl and proc interface is about to go away.

Note, some data is not converted and will not be displayed.
Someone with this hardware is going to have to finish the rest of 
this conversion.

while number of symbols is "num_syms". It used to be "num_syms" and
"num_ksyms" respectively (ie the "k" was the wrong way around).

The previous naming was not just confusing, it had caused one actual
bug (ie the normal symbol code had used "num_syms", which was wrong
in the old confusing naming scheme).

This is Mikael's version of Pavel's patch, fixed to let CONFIG_PM=n
compile. It works for me on my 2-way using oprofile.

Damn, a copy and paste error and nobody noticed until now.

From Daniel K.

This implements a simple notifier so oprofile can notice removed and
added modules properly

According to Intel document 24161823.pdf[*] page 18, 'tm2' is misdefined.
Its bit 7 not, bit 8. Also add the missing 'EST' (Enhanced Speedstep Technology)
bit, and use the correct Intel terminology for the context ID bit.

[*] http://www.intel.com/design/xeon/applnots/241618.htm

The fb-logo *.c files are not deleted on a make clean; this patch fixes
this.

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