The clocksource infrastructure introduced with commit
ad596171 broke 31 bit s390.
The reason is that the do_div() primitive for 31 bit always
had a restriction: it could only divide an unsigned 64 bit
integer by an unsigned 31 bit integer. The clocksource code
now uses do_div() with a base value that has the most
significant bit set. The result is that clock->cycle_interval
has a funny value which causes the linux time to jump around
like mad.
The solution is "obvious": implement a proper __div64_32
function for 31 bit s390.
Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: Chris Wright <chrisw@sous-sol.org>

Don't jump to the unlock+release path, we already did that.
Signed-off-by: Jens Axboe <jens.axboe@oracle.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: Chris Wright <chrisw@sous-sol.org>

Dave Jones wrote:
> sfuzz         D 724EF62A  2828 28717  28691                     (NOTLB)
>        cd69fe98 00000082 0000012d 724ef62a 0001971a 00000010 00000007 df6d22b0
>        dfd81080 725bbc5e 0001971a 000cc634 00000001 df6d23bc c140e260 00000202
>        de1d5ba0 cd69fea0 de1d5ba0 00000000 00000000 de1d5b60 de1d5b8c de1d5ba0
> Call Trace:
>  [<c05b1708>] lock_sock+0x75/0xa6
>  [<e0b0b604>] dn_getname+0x18/0x5f [decnet]
>  [<c05b083b>] sys_getsockname+0x5c/0xb0
>  [<c05b0b46>] sys_socketcall+0xef/0x261
>  [<c0403f97>] syscall_call+0x7/0xb
> DWARF2 unwinder stuck at syscall_call+0x7/0xb
>
> I wonder if the plethora of lockdep related changes inadvertantly broke something?

Looks like unbalanced locking.
Acked-by: Steven Whitehouse <swhiteho@redhat.com>
Signed-off-by: Patrick McHardy <kaber@trash.net>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: Chris Wright <chrisw@sous-sol.org>

Signed-off-by: Dave Jones <davej@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

This patch fixes a copy-paste bug in videodev.c where the vidioc_qbuf()
function gets called for the dqbuf ioctl.
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
Cc: Jonathan Corbet <corbet@lwn.net>
Signed-off-by: Michael Krufky <mkrufky@linuxtv.org>
Signed-off-by: Mauro Carvalho Chehab <mchehab@infradead.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

elv_iosched_show function iterates other elv_list,
hence elv_list_lock should be got.

Also the question is: in elv_iosched_show, elv_iosched_store
q->elevator->elevator_type construction is used without locking q->queue_lock.
Is it expected?..
Signed-off-by: Vasily Tarasov <vtaras@openvz.org>
Cc: Jens Axboe <jens.axboe@oracle.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

The whole idea with the NOTRACK netfilter target is that
you can force the netfilter code to avoid connection
tracking, and all costs assosciated with it, by making
traffic match a NOTRACK rule.

But this is totally broken by the fact that we do a checksum
calculation over the packet before we do the NOTRACK bypass
check, which is very expensive.  People setup NOTRACK rules
explicitly to avoid all of these kinds of costs.

This patch from Patrick, already in Linus's tree, fixes the
bug.

Move the check for ip_conntrack_untracked before the call to
skb_checksum_help to fix NOTRACK excemptions from NAT. Pre-2.6.19
NAT code breaks TSO by invalidating hardware checksums for every
packet, even if explicitly excluded from NAT through NOTRACK.

2.6.19 includes a fix that makes NAT and TSO live in harmony,
but the performance degradation caused by this deserves making
at least the workaround work properly in -stable.
Signed-off-by: Patrick McHardy <kaber@trash.net>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

The bcm43xx code in 2.6.18 has a serious problems not found in 2.6.17, due to
a change in the locking mechanism introduced to reduce latency. The following patch
fixes the problems in locking, reduces the latency associated with the periodic
work tasklet, and contains code needed for those cards that use 64-bit DMA.
Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

This patch has already been submitted for inclusion in the 2.6.19
tree, but not backported to the 2.6.18.  Please pull the bug fix
below into the stable tree for the 2.6.18.1 release.

The purpose of the code being modified is to determine the location
of the calgary chip address space.  This is done by a magical formula
of FE0MB-8MB*OneBasedChassisNumber+1MB*(RioNodeId-ChassisBase) to
find the offset where BIOS puts it.  In this formula,
OneBasedChassisNumber corresponds to the NUMA node, and rionodeid is
always 2 or 3 depending on which chip in the system it is.  The
problem was that we had an off by one error that caused us to account
some busses to the wrong chip and thus give them the wrong address
space.

Fixes RH bugzilla #203971.
Signed-off-by: Jon Mason <jdmason@kudzu.us>
Signed-off-by: Muli Ben-Yehuda <muli@il.ibm.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

Some people find their Jmicron pata port reports its disabled even
though it has devices on it and was boot probed. Fix this

(Candidate for 2.6.18.*, less so for 2.6.19 as we've got a proper
jmicron driver on the merge for that to replace ide-generic support)

From: Alan Cox <alan@lxorguk.ukuu.org.uk>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

Fix paren-placement / precedence bug breaking initialization for 1 MHz
clock mode.

Also fix comment spelling error, and fence-post (off-by-one) error on
symbol used in request_region.

Addresses http://bugzilla.kernel.org/show_bug.cgi?id=7242

Thanks alexander.krause@erazor-zone.de, dzpost@dedekind.net, for the
reports and patch test, and phelps@mantara.com for the independent patch
and verification.
Signed-off-by: Jim Cromie <jim.cromie@gmail.com>
Cc: <alexander.krause@erazor-zone.de>
Cc: <dzpost@dedekind.net>
Cc: <phelps@mantara.com>
Acked-by: John Stultz <johnstul@us.ibm.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

The recent fix to invalidate_inode_pages() (git commit 016eb4a0) managed to
unfix invalidate_inode_pages2().

The problem is that various bits of code in the kernel can take transient refs
on pages: the page scanner will do this when inspecting a batch of pages, and
the lru_cache_add() batching pagevecs also hold a ref.

Net result is transient failures in invalidate_inode_pages2().  This affects
NFS directory invalidation (observed) and presumably also block-backed
direct-io (not yet reported).

Fix it by reverting invalidate_inode_pages2() back to the old version which
ignores the page refcounts.

We may come up with something more clever later, but for now we need a 2.6.18
fix for NFS.

Cc: Chuck Lever <cel@citi.umich.edu>
Cc: Nick Piggin <nickpiggin@yahoo.com.au>
Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

The century bit PCF8563_MO_C in the month register is misinterpreted.  It
is set to 1 for the 20th century and 0 for 21th, and the driver is
expecting the opposite behavior.
Acked-by: Alessandro Zummo <a.zummo@towertech.it>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

Address http://bugzilla.kernel.org/show_bug.cgi?id=7189

It should check `clen', not `len'.
Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
Cc: <jurij@wooyd.org>
Cc: "Antonino A. Daplas" <adaplas@pol.net>
Cc: Willy Tarreau <w@1wt.eu>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

This was triggered, but not the fault of, the dirty page accounting
patches. Suitable for -stable as well, after it goes upstream.

Unable to handle kernel NULL pointer dereference at virtual address 0000004c
EIP is at _spin_lock+0x12/0x66
Call Trace:
 [<401766e7>] __set_page_dirty_buffers+0x15/0xc0
 [<401401e7>] set_page_dirty+0x2c/0x51
 [<40140db2>] set_page_dirty_balance+0xb/0x3b
 [<40145d29>] __do_fault+0x1d8/0x279
 [<40147059>] __handle_mm_fault+0x125/0x951
 [<401133f1>] do_page_fault+0x440/0x59f
 [<4034d0c1>] error_code+0x39/0x40
 [<08048a33>] 0x8048a33
 =======================
Signed-off-by: Nick Piggin <npiggin@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

This changes the microsecond RTT sampling so that samples are taken in
the same way that RTT samples are taken for the RTO calculator: on the
last segment acknowledged, and only when the segment hasn't been
retransmitted.
Signed-off-by: John Heffner <jheffner@psc.edu>
Acked-by: Stephen Hemminger <shemminger@osdl.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

If a drive is added with HOT_ADD_DISK rather than ADD_NEW_DISK,
saved_raid_disk isn't initialised properly, and the drive can be
included in the array without a resync.


From: Neil Brown <neilb@suse.de>
Cc: <syrius.ml@no-log.org>
Cc: Richard Bollinger <rabollinger@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

Because the system won't turn off the SG flag for us we
need to do this manually on the IPv6 path.  Otherwise we
will throw IPv6 packets with bad checksums at the hardware.
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

gcc-4.1 and later take advantage of the fact that in the
C language certain types of overflow/underflow are undefined,
and this is completely legitimate.

Prevents filters from being added if the first generated
handle already exists.
Signed-off-by: Kim Nordlund <kim.nordlund@nokia.com>
Signed-off-by: Thomas Graf <tgraf@suug.ch>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

From: Jeff Garzik <jeff@garzik.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

[SPARC64]: Kill bogus check from bootmem_init().

There is an ancient and totally incorrect sanity check being
done on the ramdisk location.  The check assumes that the
kernel is always loaded to physical address zero, which is
wrong.  It was trying to validate the ramdisk value by saying that
if it fell within the kernel image address range it must be wrong.

Anyways, kill this because it actually creates problems.  The
'ramdisk_image' should always be adjusted down by KERNBASE.
SILO can easily put the ramdisk in a location which causes
this test to trigger, breaking things.

[ Based almost entirely upon a patch from Ben Collins. ]
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

A while ago Ingo patched tcp_v4_rcv on net/ipv4/tcp_ipv4.c to use
bh_lock_sock_nested and silence a lock validator warning. This fixed
it for IPv4, but recently I saw a report of the same warning on IPv6.
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

[CPUFREQ] Fix some more CPU hotplug locking.

Lukewarm IQ detected in hotplug locking
BUG: warning at kernel/cpu.c:38/lock_cpu_hotplug()
[<b0134a42>] lock_cpu_hotplug+0x42/0x65
[<b02f8af1>] cpufreq_update_policy+0x25/0xad
[<b0358756>] kprobe_flush_task+0x18/0x40
[<b0355aab>] schedule+0x63f/0x68b
[<b01377c2>] __link_module+0x0/0x1f
[<b0119e7d>] __cond_resched+0x16/0x34
[<b03560bf>] cond_resched+0x26/0x31
[<b0355b0e>] wait_for_completion+0x17/0xb1
[<f965c547>] cpufreq_stat_cpu_callback+0x13/0x20 [cpufreq_stats]
[<f9670074>] cpufreq_stats_init+0x74/0x8b [cpufreq_stats]
[<b0137872>] sys_init_module+0x91/0x174
[<b0102c81>] sysenter_past_esp+0x56/0x79

As there are other places that call cpufreq_update_policy without
the hotplug lock, it seems better to keep the hotplug locking
at the lower level for the time being until this is revamped.
Signed-off-by: Dave Jones <davej@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

Unfortunately, sparc64 doesn't have an easy way to do a "64 X 64 -->
128" bit multiply like PowerPC and IA64 do.  We were doing a
"64 X 64 --> 64" bit multiple which causes overflow very quickly with
a 30-bit quotient shift.

So use a quotientshift count of 10 instead of 30, just like x86 and
ARM do.

This also fixes the wrapping of printk timestamp values every ~17
seconds.
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

The v4l2 API documentation for VIDIOC_ENUMSTD says:

	To enumerate all standards applications shall begin at index
	zero, incrementing by one until the driver returns EINVAL.

The actual code, however, tests the index this way:

               if (index<=0 || index >= vfd->tvnormsize) {
                        ret=-EINVAL;

So any application which passes in index=0 gets EINVAL right off the bat
- and, in fact, this is what happens to mplayer.  So I think the
following patch is called for, and maybe even appropriate for a 2.6.18.x
stable release.
Signed-off-by: Jonathan Corbet <corbet@lwn.net>
Cc: Mauro Carvalho Chehab <mchehab@infradead.org>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

Invoking load_module() before param_sysfs_init() is called crashes in
mod_sysfs_setup(), since the kset in module_subsys is not initialized yet.

In my case, net-pf-1 is getting modprobed as a result of hotplug trying to
create a UNIX socket.  Calls to hotplug begin after the topology_init
initcall.

Another patch for the same symptom (module_subsys-initialize-earlier.patch)
moves param_sysfs_init() to the subsys initcalls, but this is still not
early enough in the boot process in some cases.  In particular,
topology_init() causes /sbin/hotplug to run, which requests net-pf-1 (the
UNIX socket protocol) which can be compiled as a module.  Moving
param_sysfs_init() to the postcore initcalls fixes this particular race,
but there might well be other cases where a usermodehelper causes a module
to load earlier still.

The patch makes load_module() return an error rather than crashing the
kernel if invoked before module_subsys is initialized.

Cc: Mark Huang <mlhuang@cs.princeton.edu>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

If there is only 1 node in the system cpus should think they are apart of
some other node.

If cases where a real numa system boots the Flat numa option make sure the
cpus don't claim to be apart on a non-existent node.
Signed-off-by: Keith Mannthey <kmannth@us.ibm.com>
Cc: Andy Whitcroft <apw@shadowen.org>
Cc: Dave Hansen <haveblue@us.ibm.com>
Cc: Andi Kleen <ak@suse.de>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

Assume that a cpu is *physically* offlined at boot time...

Because smpboot.c::smp_boot_cpu_map() canoot find cpu's sapicid,
numa.c::build_cpu_to_node_map() cannot build cpu<->node map for
offlined cpu.

For such cpus, cpu_to_node map should be fixed at cpu-hot-add.
This mapping should be done before cpu onlining.

This patch also handles cpu hotremove case.
Signed-off-by: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
Cc: Tony Luck <tony.luck@intel.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

Problem description:

  We have additional_cpus= option for allocating possible_cpus.  But nid
  for possible cpus are not fixed at boot time.  cpus which is offlined at
  boot or cpus which is not on SRAT is not tied to its node.  This will
  cause panic at cpu onlining.

Usually, pxm_to_nid() mapping is fixed at boot time by SRAT.

But, unfortunately, some system (my system!) do not include
full SRAT table for possible cpus.  (Then, I use
additiona_cpus= option.)

For such possible cpus, pxm<->nid should be fixed at
hot-add.  We now have acpi_map_pxm_to_node() which is also
used at boot.  It's suitable here.
Signed-off-by: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
Cc: Tony Luck <tony.luck@intel.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

Seems like not all drivers use the framebuffer_alloc() function and won't
have an initialized mutex.  But those don't have a backlight, anyway.
Signed-off-by: Michael Hanselmann <linux-kernel@hansmi.ch>
Cc: Olaf Hering <olaf@aepfle.de>
Cc: "Antonino A. Daplas" <adaplas@pol.net>
Cc: Daniel R Thompson <daniel.thompson@st.com>
Cc: Jon Smirl <jonsmirl@gmail.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

Stops panic associated with attempting to free a non slab-allocated
per_cpu_pageset.
Signed-off-by: David Rientjes <rientjes@cs.washington.edu>
Acked-by: Christoph Lameter <clameter@sgi.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

BUG: warning at kernel/lockdep.c:1816/trace_hardirqs_on() (Not tainted)
 [<c04051ee>] show_trace_log_lvl+0x58/0x171
 [<c0405802>] show_trace+0xd/0x10
 [<c040591b>] dump_stack+0x19/0x1b
 [<c043abee>] trace_hardirqs_on+0xa2/0x11e
 [<c06143c3>] _spin_unlock_irq+0x22/0x26
 [<c0541540>] rtc_get_rtc_time+0x32/0x176
 [<c0419ba4>] hpet_rtc_interrupt+0x92/0x14d
 [<c0450f94>] handle_IRQ_event+0x20/0x4d
 [<c0451055>] __do_IRQ+0x94/0xef
 [<c040678d>] do_IRQ+0x9e/0xbd
 [<c0404a49>] common_interrupt+0x25/0x2c
DWARF2 unwinder stuck at common_interrupt+0x25/0x2c
Signed-off-by: Peter Zijlstra <a.p.zijlstra@chello.nl>
Acked-by: Ingo Molnar <mingo@elte.hu>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

With CONFIG_PHYSICAL_START set to a non default values the i386
boot_ioremap code calculated its pte index wrong and users of boot_ioremap
have their areas incorrectly mapped (for me SRAT table not mapped during
early boot).  This patch removes the addr < BOOT_PTE_PTRS constraint.

Signed-off-by: Keith Mannthey<kmannth@us.ibm.com>
Cc: Vivek Goyal <vgoyal@in.ibm.com>
Cc: Dave Hansen <haveblue@us.ibm.com>
Cc: Adrian Bunk <bunk@stusta.de>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

Looks like a workaround for old bogus OF bitrot... This fixes it and hence fixes
boot on some performa machines.
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

Following function can drops d_count twice against one reference
by lookup_one_len.

<SOURCE>
/**
 * sysfs_update_file - update the modified timestamp on an object attribute.
 * @kobj: object we're acting for.
 * @attr: attribute descriptor.
 */
int sysfs_update_file(struct kobject * kobj, const struct attribute * attr)
{
        struct dentry * dir = kobj->dentry;
        struct dentry * victim;
        int res = -ENOENT;

        mutex_lock(&dir->d_inode->i_mutex);
        victim = lookup_one_len(attr->name, dir, strlen(attr->name));
        if (!IS_ERR(victim)) {
                /* make sure dentry is really there */
                if (victim->d_inode &&
                    (victim->d_parent->d_inode == dir->d_inode)) {
                        victim->d_inode->i_mtime = CURRENT_TIME;
                        fsnotify_modify(victim);

                        /**
                         * Drop reference from initial sysfs_get_dentry().
                         */
                        dput(victim);
                        res = 0;
                } else
                        d_drop(victim);

                /**
                 * Drop the reference acquired from sysfs_get_dentry() above.
                 */
                dput(victim);
        }
        mutex_unlock(&dir->d_inode->i_mutex);

        return res;
}
</SOURCE>

PCI-hotplug (drivers/pci/hotplug/pci_hotplug_core.c) is only user of
this function. I confirmed that dentry of /sys/bus/pci/slots/XXX/*
have negative d_count value.

This patch removes unnecessary dput().
Signed-off-by: Hidetoshi Seto <seto.hidetoshi@jp.fujitsu.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

Ulrich Weigand found a bug with the current version of the
asm-powerpc/ptrace.h that prevents building at least the
SPU target version of gdb, since some ptrace opcodes are
not defined.

The problem seems to have originated in the merging of 32 and
64 bit versions of that file, the problem is that some opcodes
are only valid on 64 bit kernels, but are also used by 32 bit
programs, so they can't depends on the __powerpc64__ symbol.
Signed-off-by: Arnd Bergmann <arnd.bergmann@de.ibm.com>
Signed-off-by: David Woodhouse <dwmw2@infradead.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

It's not used by anything user-visible, and it make g++ unhappy.
Signed-off-by: David Woodhouse <dwmw2@infradead.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

This fixes most of the issues with exported headers on CRIS, although
we do still need to deal with the asm/arch symlink.
Signed-off-by: David Woodhouse <dwmw2@infradead.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

Signed-off-by: David Woodhouse <dwmw2@infradead.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>