From:  Adrian Bunk <bunk@fs.tum.de>

From:  "Perez-Gonzalez, Inaky" <inaky.perez-gonzalez@intel.com>

From:  Adrian Bunk <bunk@fs.tum.de>

From:  Petri Koistinen <petri.koistinen@iki.fi>

From:  krishnakumar@naturesoft.net

From:  Scharfe <l.s.r@web.de>

From:  Ed L Cashin <ecashin@uga.edu>

(Acked by Kanoj Sarcar <kanojsarcar@yahoo.com>)

From:  Josef Jeff Sipek <jeffpc@optonline.net>

From:  Vinay K Nallamothu <vinay-rc@naturesoft.net>

From:  Nicolas Kaiser <nikai@nikai.net>

From:  <adobriyan@mail.ru>

From:  <adobriyan@mail.ru>

(Acked by William Lee Irwin III <wli@holomorphy.com>)

From:  "ismail (cartman) donmez" <kde@myrealbox.com>

From:  Petri Koistinen <petri.koistinen@iki.fi>

From:  Scharfe <l.s.r@web.de>

The sysvfs code was confusing. Rewrite it to be readable, and
use the existing VFS helper for recalculating the hash instead
of doing it all by hand.

From:  Petri Koistinen <petri.koistinen@iki.fi>

From:  Mitchell Blank Jr <mitch@sfgoth.com>

Make some more of the hlist functions accept constant arguments.

From:  Stewart Smith <stewart@linux.org.au>

Document "---help---" tag in Kconfig

(Acked by Roman Zippel <zippel@linux-m68k.org>)

From:  Maciej Soltysiak <solt@dns.toxicfilms.tv>

  This changes the hugetlbfs examples actually being possible to
  compile. errno is being used while it's not included.

(Acked by William Lee Irwin III <wli@holomorphy.com>)

From:  Marcel Sebek <sebek64@post.cz>

(Acked by  William Lee Irwin III <wli@holomorphy.com>)

From:  Holger Schurig <h.schurig@mn-logistik.de>

From:  Pavel Machek <pavel@suse.cz>

From:  Josef Jeff Sipek <jeffpc@optonline.net>

From:  Scharfe <l.s.r@web.de>

  clean up the error handling in pipefs a little bit,
  shrinking pipe.o by whopping 4 bytes! :)

From:  Mitchell Blank Jr <mitch@sfgoth.com>

  Obvious typo fix for the scheduler docs

(Acked by Ingo)

From:  Bob Miller <rem@osdl.org>

  Removed the check_mem_region() call and replaced with request_mem_region().

From:  Tom Rini <trini@kernel.crashing.org>

  This removes two extra #includes of <linux/spinlock.h>.
  Nothing in either of these files require <linux/spinlock.h>.

From:  Vinay K Nallamothu <vinay-rc@naturesoft.net>

From:  Jeff Sipek <jeffpc@optonline.net>

into home.osdl.org:/home/torvalds/v2.5/linux

From: "V. Rajesh" <vrajesh@eecs.umich.edu>

Fix a rare pte_chain memory leak in do_no_page()

A little fix which is needed if both the "compat ioctl consolidation" and
"move job control fields from task_struct to signal_struct" patches are
applied.

From: Roland McGrath <roland@redhat.com>

This patch completes what was started with the `process_group' accessor
function, moving all the job control-related fields from task_struct into
signal_struct and using process_foo accessor functions to read them.  All
these things are per-process in POSIX, none per-thread.  Off hand it's hard
to come up with the hairy MT scenarios in which the existing code would do
insane things, but trust me, they're there.  At any rate, all the uses
being done via inline accessor functions now has got to be all good.

I did a "make allyesconfig" build and caught the few random drivers and
whatnot that referred to these fields.  I was surprised to find how few
references to ->tty there really were to fix up.  I'm sure there will be a
few more fixups needed in non-x86 code.  The only actual testing of a
running kernel with these patches I've done is on my normal minimal x86
config.  Everything works fine as it did before as far as I can tell.

One issue that may be of concern is the lack of any locking on multiple
threads diddling these fields.  I don't think it really matters, though
there might be some obscure races that could produce inconsistent job
control results.  Nothing shattering, I'm sure; probably only something
like a multi-threaded program calling setsid while its other threads do tty
i/o, which never happens in reality.  This is the same situation we get by
using ->group_leader->foo without other synchronization, which seemed to be
the trend and noone was worried about it.

From: Dominik Brodowski <linux@brodo.de>

Fix an ordering problem whcih was causing cpufreq oopses in sysfs.

From: Francois Romieu <romieu@fr.zoreil.com>

- dscc4_release_ring() must not appear in dscc4_{open/close} as the rings
  are allocated/freed in dscc4_{found1/free1};

- more elegant handling of return status in dscc4_found1().

When the BKL was removed from ext3 we lost locking coverage for
get_block()-versus-get_block().  Nobody seems to have hit the race because
get_block() almost always runs under i_sem: only memory pressure-based
writeout over a file hole runs outside i_sem.

ext2 uses the dedicated i_meta_lock spinlock in the inode to provide the
needed locking.  But ext3 already has an rwsem around all the get_block()
activity to protect it from truncate-related races.

So this patch just converts that rwsem into a semaphore, so concurrent
get_block() can never occur.  This will be more efficient than adding the new
spinlock.

We lose the ability to have two threads run get_block() against the same file
at the same time but again, that only happens during pageout over a hole
anyway.

(Kudos Alex Tomas for noticing the bug)

From: Marc Zyngier <mzyngier@freesurf.fr>, Christoph Hellwig

I'd like to kill willy's CONFIG_EISA_ALWAYS kludge.  So make EISA_bus a
variable always when CONFIG_EISA is set and initialize it to 1 for alpha.
We probably want to do that only if the system actually supports eisa, but
I keep the old behaviour for now.

From: Michael Still <mikal@stillhq.com>

The patch squelches build errors in the kernel-doc make targets by adding
documentation to arguements previously not documented, and updating the
argument names where they have changed.

From: Roland McGrath <roland@redhat.com>

This was supposed to be part of the recent mm_struct.saved_auxv[] patch.

The /proc addition is half the reason for the patch, and the more important
one (letting you debug live processes, while NT_AUXV in core dumps lets you
debug dead ones).  The patch below was supposed to be part of the original.

From: Muli Ben-Yehuda <mulix@mulix.org>

Shed some much-needed light.