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

There is a typo in the current 2.5.70 bk version of class_device_release that
was not there in my original patch.  By confusing the class and the class_device,
the release function oops.  cd->release is always the function itself (class_device_release),
cls->release is the one setup for the class (net_class in my case).

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

Now the only users of this directly should be the pci core and arch specific
pci core code.

This will let not have to export the pci_devices variable.

This makes the driver build properly now, and removes a direct access
of the pci_devices variable.

Yeah, this is commented out code, but just trying to be complete...

This patch gets rid of CONFIG_ALL_PPC, which was a very confusing
option, since it didn't actually mean "ALL" at all, it was more a
"common set" thing.

The primary replacement for CONFIG_ALL_PPC is CONFIG_PPC_MULTIPLATFORM.
I have also defined CONFIG_PPC_PMAC, CONFIG_PPC_PREP and CONFIG_PPC_CHRP
for selecting code which is only needed for one of the three platforms
that CONFIG_ALL_PPC represented.  This is something that we (the PPC
community) have been talking about doing for some time.  There is also a
CONFIG_PPC_OF which is for PPC machines with Open Firmware, which is
currently powermacs and CHRP machines.

At the moment, CONFIG_PPC_{PMAC,PREP,CHRP,OF} get unconditionally
defined if CONFIG_PPC_MULTIPLATFORM is selected, but in future this
split will let us have more control over what gets included, so that
for example we don't necessarily have to include powermac bits in a
kernel for a PReP machine.

I have gone through the uses of CONFIG_ALL_PPC one by one and decided
which of the new symbols best represents the set of machines that need
the code in question.  In fact most of the uses of CONFIG_ALL_PPC in
the drivers have been replaced by CONFIG_PPC_PMAC.  The other symbols
are mostly confined to the PPC architecture code.

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

and fix the start/stop thing as well. I think this is all of them.

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

A few choice handling fixes:
- only visible choice values define the new state of the complete choice
- improve handling of choices without visible value
- two new warnings

If /proc/mdstat is large, or reads are for a small size,
then the last line of /proc/mdstat is repeated infinitely.

This patch will fix it.

Some paths free things twice, others free un-initialised values :-(
Not any more.

When raid1 writes, it needs to schedule writes to some number
of devices, and when all writes have completed, the r1_bio
structure that holds it all together must be freed.
However we must make sure not to free it before all devices
have been considered for submitting writes to.

This happens in two places: when submitting a normal write request
and when submiting a write as part of resync.

This patch makes both these places:
  the same
  simpler
  more correct.

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

This re-organizes the thread info allocations a bit, so that
architectures like ia64 that want to allocate the thread_info structure
as part of the task structure allocation can do so.

The bulk of the patch is adding the "tsk" information to the thread
info allocator (ignored by all non-ia64 architectures), and switching
the order of the allocators to make this all possible.

From: Mark Fasheh <mark.fasheh@oracle.com>

journal_create() is called under down_write(s_umount) on the mount path.  But
it calls fsync_bdev(), which wants down_write(s_umount).

Change journal_create() to run sync_blockdev() instead.  Just to write out
the new journal's blocks.

From Jens: It fixes the occasional

	BUG_ON(list_empty(&req->queuelist));

which people have been hitting in include/linux/blkdev.h:
blkdev_dequeue_request()

From: "Seth, Rohit" <rohit.seth@intel.com>

This patch enables system administrators to more flexibly assign read/write
permissions to files in hugetlbfs.  Mount options are added which will
specify the uid, gid and mode of the filesystem's root directory.

This patch also enables super users to do chown/chgrp on files in hugetlbfs.

Also included in this patch is the support for uid, gid and mode command line
options for mount command for hugetlbfs.

The following mount options are added to hugetlbfs:

	uid=value gid=value mode=value

The values may be specified in hex (0xNNN), decimal or octal (0NNN).

From: Oleg Drokin <green@namesys.com>

This patch allows reiserfs to support blocksizes from 1024 bytes and up to
PAGE_CACHE_SIZE.  Also it fixes two glitches that prevent reiserfs from
working correctly in case if PAGE_CACHE_SIZE is bigger than blocksize.

Originally this patch was created by Edward Shushkin and Vladimir Saveliev,
and then it was adapted to modern 2.4 and 2.5 by me.

Also people should be aware that 1024 bytes blocksize is not very good thing
as tree grows very fast.  mkreiserfs is able to create filesystems with
different blocksizes for quite a while already (-b switch).

From: Oleg Drokin <green@namesys.com>

This patch adds support for remounting taking into account all extra options
you may want to pass it.  (by Jeff Mahooney).

Also it reworks the parser to correctly deal with mutually exclusive options.
Now whatever option was specified last will take an effect.

- If you pass more than one jdev= option, the error will be reported and
  mount/remount refused.

- If you pass incorrect alloc= suboptions, the mount/remount will fail.
  (it did not before).

- nolargeio now actually looks at its argument.  Argument is expected to be
  numeric.  If it is zero, default io size is set to 128k (default setting),
  if it is non-zero, default io size is set to PAGE_SIZE.

From: "Milton D. Miller II" <miltonm@realtime.net>

The code at present has a small problem: when a fault is encountered we will
run commit_write() to cover the amount of data which was successfully copied
in from userspace.

But filemap_copy_from_user() may have zeroed out some more of the page.  So
pagecache now has zeroes and the buffer_head which represents those zeroes is
not dirtied.  So a subsequent eviction and re-read of the file in the window
beyond the faulting offset will return the file's old contents and not the
zeroes.

So we change filemap_copy_from_user_iovec() to have the same behaviour as the
non-iovec filemap_copy_from_user(), and ensure that the commit_write() covers
the parts of the page which copy_from_user() zeroed out.

From: Pavel Roskin <proski@gnu.org>, via Christoph Hellwig <hch@infradead.org>

It's already the second time that I encounter a kernel panic in the same
place.  When devfs_remove() is called on a non-existent file entry, the
kernel panics and I have to reboot the system.

First time it was unregistering of pseudoterminals.  This time it's
ide-floppy module that doesn't register devfs entries if the media is absent
but still tries to unregister them.  The bug in ide-floppy will be reported
separately.

The point of this message is that the failure in devfs_remove() is possible,
especially with rarely used drivers.  Secondly, is not fatal enough to
justify an immediate panic and reboot.  Thirdly, devfs misses a chance to
tell the user what's going wrong.

From: Hollis Blanchard <hollisb@us.ibm.com>

Like radio-cadet.c, bw-qcam.c is calling copy_to_user() where it shouldn't.
The user buffer is copied to/from kernel space by
drivers/media/video/videodev.c:video_usercopy().

From: Hollis Blanchard <hollisb@us.ibm.com>

Another simple case of a memcpy that should be copy_from_user...

Also fix some error-path memory leaks.

From: Hugh Dickins <hugh@veritas.com>

PageDirty BUG_ON in __remove_inode_page is, and always has been, unsafe for
SMP or preemption: truncation may be racing against unmapping's
set_page_dirty in zap_pte_range (amongst a few other possibilities).
!PageUptodate error in __set_page_dirty_buffers is unsafe then too.

From: Hollis Blanchard <hollisb@us.ibm.com>

Fix a direct userspace access, found by the Stanford checker.

From: Hollis Blanchard <hollisb@us.ibm.com>

Fix a direct userspace access, found by the Stanford checker.

From: Hollis Blanchard <hollisb@us.ibm.com>

As pointed out by the Stanford checker, 'v' is not tainted.  The driver
shouldn't be using copy_to_user() in cadet_do_ioctl() at all:

  cadet_do_ioctl() is being called by drivers/media/video/videodev.c:
  video_usercopy(), which has already copied the buffer 'arg' (aka 'v')
  into kernel space, and will copy it back after cadet_do_ioctl()
  returns.  So all the direct 'v' accesses are correct.