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

Verify at least a full header is there before derefencing
length struct member.

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

There are currently two files besides mm/vmalloc.c that make use of that
function:

- arch/sh/kernel/cpu/sh4/sq.c
  which defined its own prototype locally risking not being in sync with
  the real function, and

- arch/arm/kernel/module.c which has no prototype at all and cause
  build warnings.

This fixes those issues

remove extraneous security_inode_setattr call in hugetlbfs, it's already
done by VFS.
Signed-off-by: Chris Wright <chrisw@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>

Al's current changes to struct nameidata broke nfsroot for my discless
clients (oops in nfs_fill_super).  The patch below fixes this problem
for me.

Cc: Trond Myklebust <trond.myklebust@fys.uio.no>
Cc: <viro@parcelfarce.linux.theplanet.co.uk>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>

char can be either signed or unsigned, depending on the target system.
Signed-off-by: Olaf Hering <olh@suse.de>
Signed-off-by: David S. Miller <davem@redhat.com>

sizeof(struct kiocb) is dangerously large for a structure commonly
allocated on-stack. This patch converts the 24*sizeof(long) field,
->private, to a void pointer for use by file_operations entrypoints.
A ->dtor() method is added to the kiocb in order to support the release
of dynamically allocated structures referred to by ->private.

The sole in-tree users of ->private are async network read/write,
which are not, in fact, async, and so need not handle preallocated
->private as they would need to if ->ki_retry were ever used. The sole
truly async operations are direct IO pread()/pwrite() which do not
now use ->ki_retry(). All they would need to do in that case is to
check for ->private already being allocated for async kiocbs.

This rips 88B off the stack on 32-bit in the common case.
Signed-off-by: William Lee Irwin III <wli@holomorphy.com>
Signed-off-by: David S. Miller <davem@redhat.com>

CAP_DAC_OVERRIDE fails to give search permission in a directory with
mode 0.

Patch acked by Chris Wright <chrisw@osdl.org>
Signed-off-by: Andries Brouwer <aeb@cwi.nl>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>

There's no reason to keep files that
a) nobody #include's
b) produce #error 
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>

For each node there are a defined list of MAX_NR_ZONES zones.  These are
selected as a result of the __GFP_DMA and __GFP_HIGHMEM zone modifier flags
being passed to the memory allocator as part of the GFP mask.  Each node
has a set of zone lists, node_zonelists, which defines the list and order
of zones to scan for each flag combination.  When initialising these lists
we iterate over modifier combinations 0 ..  MAX_NR_ZONES.  However, this is
only correct when there are at most ZONES_SHIFT flags.  If another flag is
introduced zonelists for it would not be initialised.

This patch introduces GFP_ZONETYPES (based on GFP_ZONEMASK) as a bound for
the number of modifier combinations.
Signed-off-by: Andy Whitcroft <apw@shadowen.org>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>

Like a few other drivers the vc driver is doing unlocked careless
references to file offsets.  Its got kind of 2.2 locking that hasnt been
updated in the lseek function so someone at least tried. 

Fortunately we have a real lock for this and can just make lseek use that
too.

The 'assume 64bit load is atomic' bug seems to be very widely spread

akpm@osdl.org:

   Move declarations to vt_kern.h
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>

Here's the accel capabilities patch for radeonfb.  It updates radeonfb to
advertise its acceleration capabilities via fbinfo.flags.  I've tested this
on my box, and it gives me a nice fast console.

defect: "$ fbset -accel 0" doesn't work for radeonfb -- disabling accel
will only work from the kernel command line :-/

Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: David Eger <eger@havoc.gtf.org>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>

This has been reported a couple of times and is consistently causing some
folks grief, so Urban, would you mind terribly if i send this patch to at
least clear current bug reports.  If there is additional stuff you want
ontop of this let me know and i can send a follow up patch.

The bug is that at times we haven't completed setting up the smb_ops so we
have a temporary 'null' ops in place until the connection is completely up.
 With this setup it's possible to hit ->readdir() whilst the null ops are
still in place, so we put the process to sleep until the connection setup
is complete and then call the real ->readdir().

This patch addresses the bugzilla report at
http://bugzilla.kernel.org/show_bug.cgi?id=1671Signed-off-by: Zwane Mwaikambo <zwane@linuxpower.ca>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>

- Fix the !CONFIG_FRAME_POINTER && !CONFIG_KALLSYMS output formatting.

- Make print_context_stack() static
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>

If a fault in the kernel leads to an unexpected protection fault whilst in
a code path which holds mmap_sem we will deadlock in do_page_fault() while
trying to classify the fault.  By carefully testing the source of the fault
we can detect and OOPS on the vast majority of these, greatly enhancing
diagnosis of such bugs.
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>

We need setup.h for COMMAND_LINE_SIZE.
Signed-off-by: Joseph Fannin <jhf@rivenstone.net>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>

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

A microsecond is 1 millionth of a second not
1 thousandth of a second.

Noticed by Markus Mottl <markus@oefai.at>
Signed-off-by: David S. Miller <davem@redhat.com>

Signed-off-by: Adrian Bunk <bunk@fs.tum.de>
Signed-off-by: David S. Miller <davem@redhat.com>

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

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

Also uninline pfn_to_page and page_to_pfn.
Struct page is now 8 bytes smaller.

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

Jeremy Katz of Red Hat reported that his iSeries machine would not boot
with 2.6.7 based kernels.

It appears that with the inclusion of Paul Mackerras' patch "Optimize
exception/syscall entry/exit" a small previous patch got reverted.  Here
is that patch again.  The lack of this patch does not stop all iSeries
machines booting, but it does stop some.
Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>

affs is failing to propagate the inode_setattr() return value.
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>

ncpfs is failing to propagate the inode_setattr return value.
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>

CIFS is failing to propagate the inode_setattr() return value.
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>

jfs is dropping inode_setattr()'s return value.
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>

reiserfs() is also dropping inode_setattr() retvals on the floor.
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>

ext2_setattr() drops the inode_setattr() return value on the floor.  This is
very bad - I/O errors during truncate are lost.

The patch changes ext2_setattr() so that we no longer call ext2_acl_chmod() if
inode_setattr(), which is what ext3 does.
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>

We permanently hold the i_sem of swapfiles so that nobody can addidentally
ftruncate them, causing subsequent filesystem destruction.

Problem is, it's fairly easy for things like backup applications to get
stuck onthe swapfile, sleeping until someone does a swapoff.

So take all that out again and add a new S_SWAPFILE inode flag.  Test that
in the truncate path and refuse to truncate an in-use swapfile.

Synchronisation between swapon and truncate is via i_sem.
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>

Rework the declaration, sizing and memcpying of saved_command_line[] so
that ARM doesn't need to implement unwelcome header file nestings.
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>

ext3_direct_io_get_blocks() is misinterpreting the return value from
ext3_journal_extend(), and is consequently running out of buffer credits and
going BUG on tremendously large direct-io writes.  Fix that up.

Also, I note that the really large direct-io writes can hold a transaction
open for the entire duration, which can be minutes.  This violates ext3's
attempt to commit data at regular intervals.  Fix that up by looking at the
transaction state: if it's T_LOCKED, shut off the current handle so the
pending commit can complete.
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>

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

Here's a patch to reorder timer_tsc.c so gcc 3.4 does not fail to inline
and thus fix the warning "arch/i386/kernel/timers/timer_tsc.c:30: warning:
inlining failed in call to 'cpufreq_delayed_get': function body not
available"
Signed-off-by: Jesper Juhl <juhl-lkml@dif.dk>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>

Vladimir Saveliev reported anon_vma_unlink list_del BUG (LKML 24 June). 
His testing is still in progress, but we believe it comes from a nasty
locking deficiency I introduced in 2.6.7's anon_vma_prepare.

Andrea's original anon_vma_prepare was fine, it needed no anon_vma lock
because it was always linking a freshly allocated structure; but my
find_mergeable enhancement let it adopt a neighbouring anon_vma, which of
course needs locking against a racing linkage from another mm - which the
earlier adjust_vma fix seems to have made more likely.

Does anon_vma->lock nest inside or outside page_table_lock?  Inside, but
that's not obvious without a lock ordering list: instead of listing the
order here, update the list in filemap.c; but a separate patch because
that's less urgent and more likely to get wrong or provoke controversy.

(Could do it with anon_vma lock after dropping page_table_lock, but a long
comment explaining why some code is safe suggests it's not.)
Signed-off-by: Hugh Dickins <hugh@veritas.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>

drivers/char/ipmi/ipmi_si_intf.c: In function `acpi_gpe_irq_setup':
drivers/char/ipmi/ipmi_si_intf.c:1173: warning: passing arg 4 of `acpi_install_gpe_handler' from incompatible pointer type
drivers/char/ipmi/ipmi_si_intf.c: In function `acpi_gpe_irq_cleanup':
drivers/char/ipmi/ipmi_si_intf.c:1193: warning: passing arg 3 of `acpi_remove_gpe_handler' from incompatible pointer type
Signed-off-by: Luiz Capitulino <lcapitulino@prefeitura.sp.gov.br>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>