This fixes types so that sparse has less stuff to complain about.
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>

Fixes typo in header, please apply,
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>

This fixes confusing printk.
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>

This fixes memory leak when we are low on memory during suspend.  Ouch and
nr_needed_pages is only used twice, and only written :-(.  I guess that can
wait for 2.6.10.
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>

This prevents oops when not enough memory is available during resume.
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>

Fix the below:

drivers/atm/zatm.c:1608: error: invalid lvalue in assignment

drivers/atm/iphase.c:623: error: invalid storage class for function 'ia_pkt_tx'

drivers/cdrom/sbpcd.c: In function 'get_state_T':
drivers/cdrom/sbpcd.c:1168: error: invalid storage class for function 'cmd_out_T'
drivers/cdrom/sbpcd.c: In function 'cmd_out_T':
drivers/cdrom/sbpcd.c:1317: error: invalid storage class for function 'cc_DriveReset'

drivers/media/video/saa7134/saa7134-core.c:90: error: static declaration of 'saa7134_devcount' follows non-static declaration
drivers/media/video/saa7134/saa7134.h:479: error: previous declaration of 'saa7134_devcount' was here

drivers/net/acenic.c:488: error: invalid storage class for function 'ace_watchdog'
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>

As of 2.6.10-rc3, the following is needed to allow various userland
packages (sysvinit, dhcp, ppp, libcap, libpcap, lilo) to compile as parts
that userland needs (e.g.  for ioctls) is in files with stuff userland
isn't allowed to see.

This adds __KERNEL__ around <linux/ata.h> and some defines (<linux/ata.h>
isn't needed by userland, and is unhappy right now).  sysvinit and some
other packages need <linux/hdreg.h> for HDIO_DRIVE_CMD and other IOCTL
things.  In <linux/types.h> we were unsafely typedef'ing __le64/__be64 as
__u64 only exists when __GNUC__ && !__STRICT_ANSI__ (causing libcap to
fail, for example).  Finally, <asm/atomic.h> provides routines userland
simply cannot use on all arches, but <linux/filter.h> is needed by iputils
for example.  While not all arches put __KERNEL__ around their header, on
MIPS including this header currently blows up the build.
Signed-off-by: Tom Rini <trini@kernel.crashing.org>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>

Document how Linux/ia64 names serial devices and how to use them
as console devices.
Signed-off-by: Bjorn Helgaas <bjorn.helgaas@hp.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>

It turns out there are more issues with our VPA code:

1. vpa_init doesnt report errors when it fails.  This was masking a bug
   where the VPA spanned 2 pages and phyp failed to register it.

2. We call idle_setup before we initialise the boot cpus vpa.  This
   means we never select the shared processor idle loop.

3. We dont call vpa_init on UP kernels.
Signed-off-by: Anton Blanchard <anton@samba.org>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>

ppc64 has a global called "pci_probe_only" which, when set, prevents the
arch PCI code from calling pci_assign_unassigned_resources().  This was
cleared by pmac so far, but a bug in the definition of the variable make
that ineffective until 2.6.10, and so we never called
pci_assign_unassigned_resources().

With 2.6.10, that bug was fixed and so we now call it, which results in
some problems.  Some devices who have perfectly valid assigned addresses by
firmware end up beeing moved around anyway, which is a BAD thing can can
break boot on some machines since it breaks the relationship between
addresses in Open Firmware device-tree and actual location of PCI devices. 
(Some low level things like the PIC are ioremap'ed based on their OF
address, way before the PCI based ASIC hosting them has been found).  This
also break the "offb" default framebuffer driver since the video card ends
up beeing moved around as well.

For now, the fix is to set pci_probe_only on pmac, thus reverting to the
old behaviour.  In the long run, it would be interesting to "fix"
pci_assign_unassigned_resources() so that it does what it's name claims,
and only assigns things that have been left unassigned instead of moving
things around gratuituously...
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>

Sometimes /proc/<pid>/status shows VmLib: 42949..... kB.

mprotect_fixup must note oldflags on entry: if vma_merge is successful,
vma->vm_flags afterwards may be either the oldflags or the newflags, and
the extent of the change will be less than the extent of the vma.

And let's use unsigned long for these flags throughout.
Signed-off-by: Hugh Dickins <hugh@veritas.com>
Acked-by: William Lee Irwin III <wli@holomorphy.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>

In some cases /proc/<pid>/status shows VmLib: 42949..... kB.

If READ_IMPLIES_EXEC then the break area is VM_EXEC, but omitted from
exec_vm since do_brk contains no __vm_stat_account call.  Later munmaps
count its pages out of exec_vm, hence (exec_vm - VmExe) can go negative.

do_brk is right not to call __vm_stat_account, its pages shouldn't need to
be counted.  What's wrong is that __vm_stat_account is counting all the
VM_EXEC pages, whereas (to mimic 2.4 and earlier 2.6) it should be leaving
VM_WRITE areas and non-vm_file areas out of exec_vm.

VmLib may still appear larger than before - where a READ_IMPLIES_EXEC
personality makes what was a readonly mapping of a file now executable e.g.
 /usr/lib/locale stuff.  And a program which mprotects its own text as
writable will appear with wrapped VmLib: sorry, but while it's worth
showing ordinary programs as ordinary, it's not worth much effort to avoid
showing odd ones as odd.
Signed-off-by: Hugh Dickins <hugh@veritas.com>
Acked-by: William Lee Irwin III <wli@holomorphy.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>

Michael Kerrisk has observed that at present any process can SHM_LOCK any
shm segment of size within process RLIMIT_MEMLOCK, despite having no
permissions on the segment: surprising, though not obviously evil.  And any
process can SHM_UNLOCK any shm segment, despite no permissions on it: that
is surely wrong.

Unless CAP_IPC_LOCK, restrict both SHM_LOCK and SHM_UNLOCK to when the
process euid matches the shm owner or creator: that seems the least
surprising behaviour, which could be relaxed if a need appears later.
Signed-off-by: Hugh Dickins <hugh@veritas.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>

ObviouslyCorrect[tm] buildfix ;)
Signed-off-by: Gerd Knorr <kraxel@bytesex.org>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>

The patch below fixes an ext2/ext3 memory leak: the *_fill_super functions
allocate percpu data structures but don't free them in *_put_super.
Signed-off-by: Heiko Carstens <heiko.carstens@de.ibm.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>

Use pid_alive() rather than testing for a zero value of ->pid.  Is the right
thing to do and addresses an oops dereferencing real_parent which one person
reported.
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>

When drives go offline, e.g.  usb-storage disconnect, the upper layers
don't behave very intelligently yet: ext3 over scsi keeps retrying reads,
logging three lines for each error:

10:58:31  scsi0 (0:0): rejecting I/O to dead device
10:58:31  EXT3-fs error (device sda1): ext3_find_entry: reading directory #18089296 offset 0
10:58:31 
10:59:47  EXT3-fs error (device sda1): ext3_find_entry: reading directory #18089296 offset 0

This patch shrinks that log spam by the trivial third, getting rid of those
needless blank lines.  It's not clear to me why the "no such device" errors
don't immediately make ext3 (or is it the block layer?) give up ...  maybe
someone else can make Linux not retry after those errors.
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>

We need to set the PF_SYNCWRITE when performing direct-io writes.  Otherwise
the anticipatory scheduler exhibits bad read-starves-write problems.
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>

Recently I tried booting a UP kernel on a 1-processor logical partition on
a POWER4 system.  It failed because the CPU we happened to be running on
was CPU 2, but hard_smp_processor_id() is defined to 0 for !CONFIG_SMP. 
(Note that this code runs quite early, as part of init_IRQ, so
hard_smp_processor_id() should be the physical ID of the boot cpu.)

This patch does a minimal fix to make it work.  I think this patch should
go in 2.6.10.  Ultimately I think the hard_smp_processor_id() definition
should be removed from include/linux/smp.h, but that carries a risk of
breaking other architectures and probably shouldn't be done pre 2.6.10.
Signed-off-by: Paul Mackerras <paulus@samba.org>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>

Found a subtle bug that caused mount errors on a SATA drive with
barriers on reiser and ext3, where it should have recovered and just
turned off barriers. The problem is that the EOPNOTSUPP error isn't
being propagated properly to the bounced bio. This patch fixes that by
correctly passing error all the way down.
Signed-off-by: Jens Axboe <axboe@suse.de>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>

This patch is from Will Schmidt <willschm@us.ibm.com>, with some extra
comments from me.

On iSeries and on POWER5 machines, there is a data structure which is
used for communication between the hypervisor and the kernel, called
the `lppaca'.  The kernel tells the hypervisor where it is, and the
hypervisor requires that it doesn't cross a page boundary.  With other
changes in the last few months we have ended up with a situation where
it could cross a page boundary.  This patch increases the alignment
requirement for the struct to make sure that it can't cross a page
boundary.

This is a bug fix and should go into 2.6.10.
Signed-off-by: Will Schmidt  <willschm@us.ibm.com>
Signed-off-by: Paul Mackerras <paulus@samba.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>

into ppc970.osdl.org:/home/torvalds/v2.6/linux

allowing buffer size to be changed

Signed-off-by: Steve French (sfrench@us.ibm.com)

into ppc970.osdl.org:/home/torvalds/v2.6/linux

into bkbits.net:/repos/c/cifs/linux-2.5cifs

The patch below by "Petri T. Koistinen" <petri.koistinen@iki.fi> in
Rusty's trivial patches is IMHO a candidate for 2.6.10 .
Signed-off-by: Adrian Bunk <bunk@stusta.de>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>

into bkbits.net:/repos/c/cifs/linux-2.5cifs

It contains the thread info pointer. That's not something that
user mode can really use for anything interesting, but it's also
not something that user mode should ever really see.

Pointed out by Brad Spender as being in PaX.

Signed-off-by: Steve French (sfrench@us.ibm.com)

Signed-off-by: Steve French (sfrench@us.ibm.com)

buffers and for maximum number of simultaneous requests.  Fix directio of 
userbuffers to use copy_to_user.

Signed-off-by: Steve French (sfrench@us.ibm.com)

into bkbits.net:/repos/c/cifs/linux-2.5cifs

Signed-off-by: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>

Signed-off-by: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>

From: Edward Falk <efalk@google.com>
Signed-off-by: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>

From: Alan Cox <alan@lxorguk.ukuu.org.uk>

When we issue an ide command the status bits don't become valid for
400nS. In the DMA case ide_execute_command handles this but in the PIO
case we don't do the needed locking, use OUTBSYNC to avoid posting or
delay. This means that in some situations we can execute the command
handler in PIO mode before the command status bits are valid and the
handler may read and act wrongly.
Signed-off-by: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>

From: Clear Zhang <Clear.Zhang@uli.com.tw>
Signed-off-by: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>

From: Pascal Lengard <lklm@lengard.net>
Signed-off-by: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>

pdc202xx_old_cable_detect() always returns '0' (which means 80c cable)
due to a sloppy coding - result of CIS & mask is truncated to 8 bits
although CIS holds cable info in bits 10-11.
Signed-off-by: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>

Reported to work OK by Alexander E. Patrakov <patrakov@ums.usu.ru>.
Signed-off-by: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>