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

into kernel.bkbits.net:/home/davem/sparc-2.6

Signed-off-by: David S. Miller <davem@davemloft.net>

1) Correct memory barriers.  Routines not returning a value need
   no memory barriers, however routines returning values do need
   them.
2) Actually implement non-atomic ext2 bitops.

Thanks to Anton Blanchard for pointing out the memory barrier
requirements.
Signed-off-by: David S. Miller <davem@davemloft.net>

Georgi Guninski has some tools that warn about bad user accesses.
This one was harmless, but still..

The patch fixes the noexec= boot option on x86_64 to actually work when
other options come after it.

Credits (if any ;)) should go to Matt Zimmerman and Colin Watson for
spotting the problem and providing/testing the fix.
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>

This patch fixes a compile problem on x86-64 when CONFIG_PM is turned off. 
Signed-off-by: Andi Kleen <ak@suse.de>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>

The Pentium4 models 0&1 have a longer MSR_EBC_FREQUENCY_ID register as the
models 2&3, so the bit shift must be bigger.
Signed-off-by: Matthias-Christian Ott <matthias.christian@tiscali.de>
Signed-off-by: Dominik Brodowski <linux@brodo.de>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>

The hugetlb_page test in do_munmap is too permissive.  It checks start vma,
but forgets that end vma might be different and huge though start is not:
so hits unmap_hugepage_range BUG if misaligned end was given.

And it's too restrictive: munmap has always succeeded on unmapped areas
within its range, why should it behave differently near a hugepage vma?

And the additional checks in is_aligned_hugepage_range are irrelevant here,
when the hugepage vma already exists.  But the function is still required
(on some arches), as the default for prepare_hugepage_range - leave
renaming cleanup to another occasion.
Signed-off-by: Hugh Dickins <hugh@veritas.com>
Acked-by: William Irwin <wli@holomorphy.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>

When looking for identical xattr blocks to share, we were not comparing the
name_index fields.  This could lead to false sharing when two xattr blocks
ended up with identical attribute names and values, and the only default
acls.  Because acls are cached, the bug was hidden until the next reload of
the affected inode.

  $ mkdir -m 700 a b
  $ setfacl -m u:bin:rwx a
	< acl of a goes in the mbcache

  $ setfacl -dm u:bin:rwx b
	< acl of b differs only in name_index, so a's acl is reused

  $ getfacl b
	< shows the result from the inode cache

  < empty inode cache (remount, etc.)

  $ getfacl b
	< shows an access acl instead of a default acl.
Signed-off-by: Andreas Gruenbacher <agruen@suse.de>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>

It's time to remove truncate_complete_page's BUG_ON(page_mapped(page)): it
was there to give confidence in the new vm_truncate_count mechanism. 
Earlier releases had no such check, and it wouldn't be at all helpful if it
ever bugged up file truncation on a production system - though we don't
know of any scenario in which that could happen now.
Signed-off-by: Hugh Dickins <hugh@veritas.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>

Just before removing truncate_complete_page's BUG_ON(page_mapped(page)),
thought I'd recheck on a few filesystems.  The shame!  Easily triggered
with tmpfs: not because of recent changes, but because shmem_nopage omitted
the i_size_read from Andrea's careful truncate_count/i_size_read
/cachelookup/truncate_count sequence.  For varying reasons, other users of
shmem_getpage can't go beyond i_size, so just add it to shmem_nopage.
Signed-off-by: Hugh Dickins <hugh@veritas.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>

Do it in one spot, a macro named get_pgd_cache(), instead of
three different places.
Signed-off-by: David S. Miller <davem@davemloft.net>

Signed-off-by: David S. Miller <davem@davemloft.net>

Currently, the kernel won't compile for SMP ppc32 if preempt is
enabled.  This patch adds suitable read_can_lock and write_can_lock
definitions.

This patch also adds a real _raw_read_trylock (inline and out-of-line
versions), changes the rwlock->lock field to a signed int, which is
what it really was all along, and cleans up the out-of-line rwlock
code in arch/ppc/lib/locks.c.  It removes the debug fields from the
rwlock struct because we were never using them, even with
CONFIG_DEBUG_SPINLOCK set.

I have compile and boot tested this with the four combinations of
CONFIG_DEBUG_SPINLOCKS on and off, and CONFIG_PREEMPT on and off.
Please put this patch into 2.6.11 so that 2.6.11 will work for
ppc32 with CONFIG_SMP and CONFIG_PREEMPT.
Signed-off-by: Paul Mackerras <paulus@samba.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>

This patch fixes the issue with HPET on some platforms.

According to Vojtech Pavlik:

The first write after writing TN_SETVAL to the config register sets the
counter value, the second write sets the threshold.

When you only do the first write you never set the threshold and interrupts
won't be generated properly.

Thanks to John Stultz and Andrew Walrond for reporting, root causing the
issue and verifying this fix.
Signed-off-by: Venkatesh Pallipadi <venkatesh.pallipadi@intel.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>

This patch just replaces the last usage of the vio dma mapping routines
with the equivalent generic dma mapping routines.
Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
Signed-off-by: Paul Mackerras <paulus@samba.org>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>

Make the physical_id cpu sysfs attribute on ppc64 show -1 instead of
65535 for non-present cpus.
Signed-off-by: Nathan Lynch <nathanl@austin.ibm.com>
Signed-off-by: Paul Mackerras <paulus@samba.org>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>

This patch is from David Woodhouse <dwmw2@infradead.org>.

We were pretending that every syscall returned zero. Don't do that.
Signed-Off-By: David Woodhouse <dwmw2@infradead.org>
Signed-off-by: Paul Mackerras <paulus@samba.org>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>

The 4 level pagetable code changed the exit_mmap code to rely on TASK_SIZE.
 On some architectures (eg ppc64 and ia64), this is a per task property and
bad things can happen in certain circumstances when using it.

It is possible for one task to end up "owning" an mm from another - we have
seen this with the procfs code when process 1 accesses /proc/pid/cmdline of
process 2 while it is exiting.  Process 2 exits but does not tear its mm
down.  Later on process 1 finishes with the proc file and the mm gets torn
down at this point.

Now if process 1 was 32bit and process 2 was 64bit then we end up using a
bad value for TASK_SIZE in exit_mmap.  We only tear down part of the
address space and leave half initialised pagetables and entries in the MMU
etc.

MM_VM_SIZE() was created for this purpose (and is used in the next line for
tlb_finish_mmu), so use it.  I moved the PGD round up of TASK_SIZE into the
default MM_VM_SIZE.
Signed-off-by: Anton Blanchard <anton@samba.org>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>

Bad things can happen if a 32-bit process is the last user of a 64-bit mm. 
TASK_SIZE isn't a constant, and we can end up clearing page tables only up
to the 32-bit TASK_SIZE instead of all the way.  We should probably
double-check every instance of TASK_SIZE or USER_PTRS_PER_PGD for this kind
of problem.

We should also double-check that MM_VM_SIZE() and other such things are
correctly defined on all architectures.  I already fixed ppc64 which let it
stay as TASK_SIZE, and hence dependent on the _current_ context instead of
the mm in the argument.
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>

Changeset 1.1938.196.11 broke MPC8260 PCI9 Errata workaround.  This pach
makes it work again.
Signed-off-by: Rune Torgersen <runet@innovsys.com>
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>

Forgot to use ARCH_USER_CFLAGS after defining it for x86_64.
Signed-off-by: Paolo 'Blaisorblade' Giarrusso <blaisorblade@yahoo.it>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>

This fixes a bug which assumes that __binary_start starts on a page boundary,
which isn't true when UML is configured to load into the normal executable
area.
Signed-off-by: Paolo 'Blaisorblade' Giarrusso <blaisorblade@yahoo.it>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>

The previous ifdef to check whether to use the host's vsyscall page was buggy.
This bug can cause crashes.
Signed-off-by: Paolo 'Blaisorblade' Giarrusso <blaisorblade@yahoo.it>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>

Initialize jiffies_64 to INITIAL_JIFFIES.
Signed-off-by: Paolo 'Blaisorblade' Giarrusso <blaisorblade@yahoo.it>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>

When a page fault occurs on an address below the stack-vma, UML tries to
expand the stack.

On i386 and x86_64, the failing address is compared to the current userspace
stack pointer.  If the failing address is below "esp-32" resp.  "rsp-128",
stack expansion is not allowed, and a SIGSEGV is given to the user.

This patch makes UML behave like i386/x86_64.
Signed-off-by: Bodo Stroesser <bstroesser@fujitsu-siemens.com>
Signed-off-by: Paolo 'Blaisorblade' Giarrusso <blaisorblade@yahoo.it>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>

This adds code which enables SIGSEGV reception to the SKAS sig_handler_common,
which matches the tt code.

I still need to figure out why the SA_NODEFER flag was backed out in favor of
this.
Signed-off-by: Paolo 'Blaisorblade' Giarrusso <blaisorblade@yahoo.it>
CC: uml-devel <user-mode-linux-devel@lists.sourceforge.net>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>

Change some config text (hide CONFIG_MODVERSION which is broken on UML and fix
a dummy prompt).
Signed-off-by: Paolo 'Blaisorblade' Giarrusso <blaisorblade@yahoo.it>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>

Re-add some needed headers inclusion deleted in
http://linux.bkbits.net:8080/linux-2.5/cset@41e49628dGbOWX-bT9yZII4f19GT6A

If you think it cannot make sense to include both <sys/ptrace.h> and
<linux/ptrace.h> (as userspace process, i.e.  host includes), go complaining
with glibc, or follow the linux-abi includes idea.

However, the compilation failure is possibly glibc-version (or better glibc
includes version) related - what I now is that the failure happens on my
system with a glibc 2.3.4 (from Gentoo).

Also, fix the syscall table to both compile and have no empty slot (which
could cause Oopses).
Acked-by: Jeff Dike <jdike@addtoit.com>
Signed-off-by: Paolo 'Blaisorblade' Giarrusso <blaisorblade@yahoo.it>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>

arch/um/Kconfig_arch is actually a symlink, so
* Remove it from the tree.
* Make sure it is removed during make mrproper.
Signed-off-by: Paolo 'Blaisorblade' Giarrusso <blaisorblade@yahoo.it>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>

With NFSD=y, EXPORTFS=m:

fs/built-in.o(.text+0x7fff5): In function `fh_verify':
/usr/src/25/fs/nfsd/nfsfh.c:221: undefined reference to `export_op_default'

So it seems that nfsd requires exportfs.

For consistency we should tidy up the definition of EXPORTFS too.
Signed-off-by: Neil Brown <neilb@cse.unsw.edu.au>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>

Signed-off-by: Michal Ludvig <michal@logix.cz>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>

Fixes the math of both jiffies_to_usecs() and usecs_to_jiffies() which
improperly assume the same rounding point -- 1,000 -- as jiffies_to_msecs()
and msecs_to_jiffies(), when in fact it should be 1,000,000.  Furthermore,
the actual math of both functions is actually wrong and will lead to more
than just rounding errors.
Signed-off-by: Nishanth Aravamudan <nacc@us.ibm.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>

The hvcs driver does not register a devfs_name resulting in devfs creating
/dev/<NULL>* entries.  The following one line patch remedies the problem.
Signed-off-by: Jimi Xenidis <jimix@watson.ibm.com>
Signed-off-by: Paul Mackerras <paulus@samba.org>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>

Yet another ppc64 build failure..  Move the function before its first
usage, and the failure goes away.
Signed-off-by: Dave Jones <davej@redhat.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>

There is an obvious error in the header of /proc/slabinfo
Signed-off-by: Zou Nan hai <nanhai.zou@intel.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>

A wrong ordering of operators in pcmica_register_client() causes
initialization problems with multiple PCMCIA cards.
Signed-off-by: Josh Green <jgreen@users.sourceforge.net>
Signed-off-by: Dominik Brodowski <linux@dominikbrodowski.de>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>

This fixes the selinux_inode_setattr hook function to honor the ATTR_FORCE
flag, skipping any permission checking in that case.  Otherwise, it is
possible though unlikely for a denial from the hook to prevent proper
updating, e.g.  for remove_suid upon writing to a file.  This would only
occur if the process had write permission to a suid file but lacked setattr
permission to it.
Signed-off-by: Stephen Smalley <sds@tycho.nsa.gov>
Signed-off-by: James Morris <jmorris@redhat.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>