From: DHollenbeck <dick@softplc.com>

This patch was needed against a pristine 2.6.4 kernel when compiling with
"gcc 3.4 _very recent_" using the -Os option.

Without this patch, modules would use a non-inline memcmp() and then not
find it in the kernel, causing depmod to complain and some modules not to
load.

From: Tim Schmielau <tim@physik3.uni-rostock.de>

BSD accounting was missed in the conversion from HZ to USER_HZ.  I thought
nobody cared, but apparently there are still users to it.

From: "Randy.Dunlap" <rddunlap@osdl.org>

From: Michael Veeck <michael.veeck@gmx.net>

Remove unnecessary min/max macros and changes calls to use kernel.h macros
instead.

From: "Randy.Dunlap" <rddunlap@osdl.org>

From: Michael Veeck <michael.veeck@gmx.net>

Remove unnecessary min/max macros and changes calls to use kernel.h macros
instead.

From: "Randy.Dunlap" <rddunlap@osdl.org>

From: Michael Veeck <michael.veeck@gmx.net>

Remove unnecessary min/max macros and changes calls to use kernel.h macros
instead.

From: "Randy.Dunlap" <rddunlap@osdl.org>

From: Michael Veeck <michael.veeck@gmx.net>

Patch (against 2.6.3) removes unnecessary min/max macros and changes calls to
use kernel.h macros instead.

From: "Randy.Dunlap" <rddunlap@osdl.org>

This trivial patch fixes the bug #320:

http://bugme.osdl.org/show_bug.cgi?id=320

The additional comment:

http://bugme.osdl.org/show_bug.cgi?id=320#c1

Is wrong, because it will send the command twice.

We only want to see if the command got success, thus is not necessary
to test against < 0 (if the return value is not 1, we got a error).

Note that I'm using the function (bad) style.

From: "Randy.Dunlap" <rddunlap@osdl.org>

Remove the rest of references to smp.tex
Documentation/cpufreq => Documentation/cpu-freq
DocBook/tulip.{pdf,ps,html} => DocBook/tulip-user.{pdf,ps,html}
Bunch of other typos.

From: "Randy.Dunlap" <rddunlap@osdl.org>

From: Luiz Fernando Capitulino <lcapitulino@prefeitura.sp.gov.br>

From: "Randy.Dunlap" <rddunlap@osdl.org>

From: Luiz Fernando Capitulino <lcapitulino@prefeitura.sp.gov.br>

From: Roman Zippel <zippel@linux-m68k.org>

When a boolean choice value has a dependency of 'm' it can be shortly
treated as a tristate symbol.  This fixes this and also add a small
optimization to precompute the value of the module symbol instead of
checking it all the time.

From: Roman Zippel <zippel@linux-m68k.org>

This patch is by Andreas Fester <Andreas.Fester@gmx.de> and saves and
restores various runtime options of qconf.

From: Roman Zippel <zippel@linux-m68k.org>

This disables some debug prints, which are more confusing than helpful for
normal users.

From: Roman Zippel <zippel@linux-m68k.org>

conf_write() now checks the target path whether it's a directory, so it
saves the config in the directory instead of renaming it.

From: Roman Zippel <zippel@linux-m68k.org>

The correct link path is needed at config time to find the correct library,
so let's ask gcc for the real path.

From: Brian Gerst <bgerst@didntduck.org>

Don't abuse empty_zero_page as temporary storage for boot parameters and
command line.  This is a holdover from the days before discardable init
sections.

From: Matt Mackall <mpm@selenic.com>

This keeps the alignment of the init task matched with the stack size.

From: Maneesh Soni <maneesh@in.ibm.com>

Fix a sysfs use-after-free crash.  The problem we have is of the kobject
going away while we have a live dentry (the corresponding sysfs directory)
still pointing to it throuh d_fsdata pointer.  The patch makes sure to keep
the kobject alive by taking a reference to it during the life-time of
corresponding dentry.


o The following pins the kobject when sysfs assigns dentry and inode to
  the kobject. This ensures that kobject is alive during the life time of
  the dentry and inode, and people holding ref. to the dentry can access the
  kobject without any problems.

o The ref. taken for the kobject is released through dentry->d_op->d_iput()
  call when the dentry ref. count drops to zero and it is being freed. For
  this sysfs_dentry_operations is introduced.

For testing one has to run the following test on a SMP box:

1) Do insmod/rmmod "dummy.o" network driver in a forever loop.

2) Parallely do "find /sys/class/net | xargs cat" also in a forever loop.

From: Maneesh Soni <maneesh@in.ibm.com>

The following patch fixes the dentry refcounting, during
sysfs_remove_group() and also adds the missing dput() for the "extra" ref
taken during sysfs_create() for the sub-directory dentry corresponding to
attribute group.

From: Maneesh Soni <maneesh@in.ibm.com>

I have re-done the patch fixing the race between sysfs_remove_dir() and
dcache_readdir().  If you recall, sysfs_remove_dir(kobj) manipulates the
->d_subdirs list for the dentry corresponding to the sysfs directory being
removed.  It can end up deleting the cursor dentry which is added to the
->d_subdirs list during a concurrent dcache_dir_open() ==> dcache_readdir()
for the same directory.  And as a result dcache_readdir() can loop for ever
holding dcache_lock.

The earlier patch which was included in -mm1 created problems which
resulted in list_del() BUG hits in prune_dcache().  The reason I think is
that in the main loop in sysfs_remove_dir(), dcache_lock is dropped and
re-acquired, and this could result in inconsistent ->d_subdirs list and
prune_dcache() may try to delete an already deleted dentry.  I have
corrected this in the new patch as below.

I could do sysfs_remove_dir() more neatly on sysfs backing store patch set
as there I don't use the ->d_subdirs list.  Instead the list of children
sysfs_dirent works out well.  But untill sysfs backing store patch is
picked up the existing code suffer from this race.  This can be easily
tested by running following two loops on a SMP box

# while true; do insmod drivers/net/dummy.ko; rmmod dummy; done
# while true; do find /sys/class/net > /dev/null; done


o This patch fixes sysfs_remove_dir race with dcache_readdir.  There is
  no need for sysfs_remove_dir to modify the d_subdirs list for the
  directory being deleted as it is taken care in the final dput.  Modifying
  this list results in inconsistent d_subdirs list and causes infinite loop
  in concurrently occurring dcache_readdir.

o The main loop is restarted every time, dcache_lock is re-acquired in
  order to maintain consistency.

From: Anton Blanchard <anton@samba.org>

Introduce dma_error() and pci_dma_error() which are used to detect failures
in pci_map_single.

From: Anton Blanchard <anton@samba.org>

- Fix for machines with 3GB IO holes (eg nighthawk).
- Increase the maximum number of PHBs and warn if we exceed this (we used
  to walk off the end of the array)
- Only allocate an 8MB TCE table on POWER4

From: Paul Mackerras <paulus@samba.org>

Recently we found a particularly nasty bug in the segment handling in the
ppc64 kernel.  It would only happen rarely under heavy load, but when it
did the machine would lock up with the whole of memory filled with
exception stack frames.

The primary cause was that we were losing the translation for the kernel
stack from the SLB, but we still had it in the ERAT for a while longer.
Now, there is a critical region in various exception exit paths where we
have loaded the SRR0 and SRR1 registers from GPRs and we are loading those
GPRs and the stack pointer from the exception frame on the kernel stack.
If we lose the ERAT entry for the kernel stack in that region, we take an
SLB miss on the next access to the kernel stack.  Taking the exception
overwrites the values we have put into SRR0 and SRR1, which means we lose
state.  In fact we ended up repeating that last section of the exception
exit path, but using the user stack pointer this time.  That caused another
exception (or if it didn't, we loaded a new value from the user stack and
then went around and tried to use that).  And it spiralled downwards from
there.

The patch below fixes the primary problem by making sure that we really
never cast out the SLB entry for the kernel stack.  It also improves
debuggability in case anything like this happens again by:

- In our exception exit paths, we now check whether the RI bit in the
  SRR1 value is 0.  We already set the RI bit to 0 before starting the
  critical region, but we never checked it.  Now, if we do ever get an
  exception in one of the critical regions, we will detect it before
  returning to the critical region, and instead we will print a nasty
  message and oops.

- In the exception entry code, we now check that the kernel stack pointer
  value we're about to use isn't a userspace address.  If it is, we print a
  nasty message and oops.

This has been tested on G5 and pSeries (both with and without hypervisor)
and compile-tested on iSeries.

From: Anton Blanchard <anton@samba.org>

Add numa=off command line option to disable NUMA support at runtime.
Useful if there are issues with our parsing of the NUMA toplogy or for
testing NUMA gains.

From: Anton Blanchard <anton@samba.org>

Remove the old __IO_DEBUG stuff and add some nice comments courtesy of x86.

From: Stephen Rothwell <sfr@canb.auug.org.au>

This patch adds the driver for the PPC64 iSeries virtual tape.

Preparation for per-mountpoint noatime, nodiratime and later -
per-mountpoint r/o.  Depends on file_accessed() patch, should go after
it.

New helper - touch_atime(mnt, dentry).  It's a wrapper for
update_atime() and that's where all future per-mountpoint checks will
go.

New inlined helper - file_accessed(file) (wrapper for update_atime())

Make sure that we don't end up with symlink mounted over something

(mount --bind is safe since we use LOOKUP_FOLLOW in pathname resolution
there).

into nuts.davemloft.net:/disk1/BK/sparc-2.6

This fixes a minor problem with fcntl.

get_close_on_exec() uses FD_ISSET() to determine the fd state, but this
is not guaranteed to be either 0 of FD_CLOEXEC.  Make that explicit.

Also, the argument of set_close_on_exec() is being AND'ed with the
literal constant 1.  Make it use an explicit FD_CLOEXEC test.

(The broken macro only triggers for non-gcc compiles, but
still..)

Original patch from Hannes Reinecke <hare@suse.de>.

This is required to have modular IDE drivers announce themselves
properly in modules.pcimap.

Implement migrate_all_tasks() which moves tasks off cpu while machine
is stopped.

The registration and unregistration of CPU notifiers should be done
under the cpucontrol sem.  They should also be exported.

include files moved to fs/hpfs/, gratitious #include removed, stuff that
doesn't have to be global made static, misindented chunk of
hpfs_readdir() put in place, etc.

	Fixed the locking scheme.  The need of extra locking was caused by
the fact that hpfs_write_inode() must update directory entry; since HPFS
directories are implemented as b-trees, we must provide protection both
against rename() (to make sure that we update the entry in right directory)
and against rebalancing of the parent.

	Old scheme had both deadlocks and races - to start with, we had no
protection against rename()/unlink()/rmdir(), since (a) locking parent
was done without any warranties that it will remain our parent and (b)
check that we still have a directory entry (== have positive nlink) was
done before we tried to lock the parent.  Moreover, iget serialization
killed two steps ago gave immediate deadlocks if iget() of parent had
triggered another hpfs_write_inode().

	New scheme introduces another per-inode semaphore (hpfs-only,
obviously) protecting the reference to parent.  It's taken on
rename/rmdir/unlink victims and inode being moved by rename.  Old semaphores
are taken only on parent(s) and only after we grab one(s) of the new kind.
hpfs_write_inode() gets the new semaphore on our inode, checks nlink and
if it's non-zero grabs parent and takes the old semaphore on it.

	Order among the semaphores of the same kind is arbitrary - the only
function that might take more than one of the same kind is hpfs_rename()
and it's serialized by VFS.

	We might get away with only one semaphore, but then the ordering
issues would bite us big way - we would have to make sure that child is
always locked before parent (hpfs_write_inode() leaves no other choice)
and while that's easy to do for almost all operations, rename() is a bitch -
as always.  And per-superblock rwsem giving rename() vs. write_inode()
exclusion on hpfs would make the entire thing too baroque for my taste.
	->readdir() takes no locks at all (protection against directory
modifications is provided by VFS exclusion), ditto for ->lookup().
	->llseek() on directories switched to use of (VFS) ->i_sem, so
it's safe from directory modifications and ->readdir() is safe from it -
no hpfs locks are needed here.