as if they were coming form the touchpad itself if pass-through
       port is disconnected, just pass them to serio core and it will
       attempt to bind proper driver to the port
Signed-off-by: Dmitry Torokhov <dtor@mail.ru>

       filly initialized - helps when USB Legacy emulation gets
       in our way and starts generating junk data stream while
       psmouse is detecting hardware
Signed-off-by: Dmitry Torokhov <dtor@mail.ru>

       serio_continue_rx so it will not fight with the interrupt handler
Signed-off-by: Dmitry Torokhov <dtor@mail.ru>

       their critical sections from port's interrupt handler
Signed-off-by: Dmitry Torokhov <dtor@mail.ru>

       track of where data is coming from. Also sprinkled some
       "likely"s in i8042 interrupt handler.
Signed-off-by: Dmitry Torokhov <dtor@mail.ru>

       only after hardware was fully initialized and with interrupts
       tuned back on, otherwise it deadlocks.
Signed-off-by: Dmitry Torokhov <dtor@mail.ru>

       serio_bus is available early
Signed-off-by: Dmitry Torokhov <dtor@mail.ru>

into ameritech.net:/usr/src/export/input

This cleans up legacy x86 binary support by introducing a new
personality bit: READ_IMPLIES_EXEC, and implements Linus' suggestion to
add the PROT_EXEC bit on the two affected syscall entry places,
sys_mprotect() and sys_mmap().  If this bit is set then PROT_READ will
also add the PROT_EXEC bit - as expected by legacy x86 binaries.  The
ELF loader will automatically set this bit when it encounters a legacy
binary.

This approach avoids the problems the previous ->def_flags solution
caused.  In particular this patch fixes the PROT_NONE problem in a
cleaner way (http://lkml.org/lkml/2004/7/12/227), and it should fix the
ia64 PROT_EXEC problem reported by David Mosberger.  Also,
mprotect(PROT_READ) done by legacy binaries will do the right thing as
well. 

the details:

- the personality bit is added to the personality mask upon exec(),
  within the ELF loader, but is not cleared (see the exceptions below). 
  This means that if an environment that already has the bit exec()s a
  new-style binary it will still get the old behavior.

- one exception are setuid/setgid binaries: these will reset the
  bit - thus local attackers cannot manually set the bit and circumvent
  NX protection. Legacy setuid binaries will still get the bit through
  the ELF loader. This gives us maximum flexibility in shaping
  compatibility environments.

- selinux also clears the bit when switching SIDs via exec().

- x86 is the only arch making use of READ_IMPLIES_EXEC currently. Other
  arches will have the pre-NX-patch protection setup they always had.

I have booted an old distro [RH 7.2] and two new PT_GNU_STACK distros
[SuSE 9.2 and FC2] on an NX-capable CPU - they work just fine and all
the mapping details are right. I've checked the PROT_NONE test-utility
as well and it works as expected. I have checked various setuid
scenarios as well involving legacy and new-style binaries.

an improved setarch utility can be used to set the personality bit
manually:

	http://redhat.com/~mingo/nx-patches/setarch-1.4-3.tar.gz

the new '-X' flag does it, e.g.:

	./setarch -X linux /bin/cat /proc/self/maps

will trigger the old protection layout even on a new distro.
Signed-off-by: Ingo Molnar <mingo@elte.hu>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>

I've tracked down the core issue giving me the oops wrt pmac_zilog.

When you have two serial drivers, (e.g. 8250 and PMAC_ZILOG) they both say

"I want to reserve X ports starting with major TTY_MAJOR and minor 64".

By the time pmac_zilog gets there, the ports it requests are already
reserved.  Unfortunately, init_pmz() doesn't check for pmz_register()
failure, and so it merrily goes on to register the half-initialized
pmac_zilog driver with the power management subsystem.

This path provides a proper failure path.

Also: 

Restore ppc configs now that I know people use AT Keyboards on CHRP and PReP
machines, and the zilog driver is no longer Oops'ing.
Signed-off-by: David Eger <eger@havoc.gtf.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>

Ready for the kernel summit in Ottawa...

This also fixes it for when the real parent is ignoring
SIGCHLD - noted by David Mosberger.

For some reason I booted a NUMA and SLAB_DEBUG i386 kernel on a non
NUMA 512MB machine.  This caused an oops at bootup in change_page_attr.
The reason was that highmem_start_start page ended up zero and 
that triggered the highmem check in change_page_attr when the
slab debug code would unmap a kernel mapping.

Fix is straightforward: if there is no highmem set highmem_start_page
to max_low_pfn+1

This fixes a long standing corruption bug in the x86-64 code. The SMP
trampoline would corrupt page 2, which was sometimes used for other
data.  This corrupted the ioport/iomem list in some cases and causes
oopses while read /proc/iomem.

Fix is to check the correct location and don't zero it afterwards
because it gets reinitialized for the next CPU anyways.

Thanks to Alexander Nyberg for tracking it down.

This patch fixes a hard-to-trigger condition, where the inode is on the
inode_in_use list while it's state is dirty.  In this state dirty pages are
not written back in sync() or from kupdate, only from direct page reclaim. 
And this causes a livelock in balance_dirty_pages after a while.

The actual sequence of events required to get into this state is:

thread   function                             inode state         inode list
----------------------------------------------------------------------------
1 __sync_single_inode (background)            I_DIRTY             sb->s_io
1 do_writepages ...                           I_LOCKED
2 __writeback_single_inode (sync) sleeps      I_LOCKED
1 __sync_single_inode (background) finish     0                   inode_in_use
2 __writeback_single_inode (sync) wakeup      0
2 __sync_single_inode (sync)                  0 
2 do_writepages ...                           I_LOCKED
3 __mark_inode_dirty                          I_LOCKED | I_DIRTY
2 __sync_single_inode (sync) finish           I_DIRTY             left on
                                                                  inode_in_use
Signed-off-by: Miklos Szeredi <miklos@szeredi.hu>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>

Patch for our console driver.  We converted the driver to use the serial
core functions.  Also some changes to use sysfs/udev and a new major
number.

Cc: Jesse Barnes <jbarnes@engr.sgi.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>

partially annotated, fixed dereferencing of userland pointer (trivial,
since we'd just copied the entire structure).

Massive, but trivial - drm annotated and got 0->NULL where needed.  That
patch kills ~2200 lines of warnings - out of 5400 that remained at that
point.

the rest of iovec cleanups: nbd, dvb-net, sock.c::sock_no_sendpage(),
econet over udp and ip_vs switched to use of kvec and kernel_...msg().

sunrpc, nfs and nfsd switched to use of kvec and kernel_...msg()

rxrpc (low-level part of afs) switched to kernel_...msg(); it already was
using kvec instead of iovec.

cifs switched to kvec and kernel_...msg()

ncpfs switched to kvec and kernel_...msg()

smbfs switched to kvec and kernel_...msg()

Beginning of iovec cleanups - added two helpers (kernel_{send,recv}msg)
that do sock_sendmsg/sock_recvmsg with kvec instead of iovec; basically,
they were abstracted from earlier afs patch.  They take kvec/length of
kvec as separate arguments, do set_fs(), stick kvec into msghdr and call
sock_...msg(). 

The next group of patches will switch network filesystems to use of kvec
for kernel data + use of these helpers.  Basically, the same thing we'd
done for afs.

switched to compat_alloc_user_space(), cleaned up.

 - missing ; between default: and } in sun4setup.c
 - cast of pointer to unsigned long long instead of unsigned long in
   x86_64 signal.c
 - missed annotations for ioctl structure in sparc64 openpromio.h
   (should've been in the same patch as the rest of drivers/sbus/*
   annotations)
 - 0->NULL in list.h and pmdisk.c

A bunch of drivers are broken on sparc64; mark them as such in Kconfig.
arlan and smctr are not 64bit-clean; again, markes as such.

The au88x0 driver tries to use the wrong private field - there are two,
one of them int and another void *.

While it's not a problem on 32bot boxen, it breaks on 64bit ones. 

Fixed.

This works around the current PROT_NONE problem from elf binaries that
do not have the PT_GNU_STACK so that the do not have execute permission.

The problem was that setting "def_flags" to include the VM_EXEC bit for
compatibility reasons would also make PROT_NONE pages executable, which
is obviously not correct.
Signed-off-by: Daniel McNeil <daniel@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>