linux-toradex.git, branch v2.6.22.12

Linux 2.6.22.12

2007-11-05T17:59:33+00:00

Revert "x86_64: allocate sparsemem memmap above 4G"

2007-11-05T17:56:08+00:00

patch 6a22c57b8d2a62dea7280a6b2ac807a539ef0716 in mainline.

This reverts commit 2e1c49db4c640b35df13889b86b9d62215ade4b6.

First off, testing in Fedora has shown it to cause boot failures,
bisected down by Martin Ebourne, and reported by Dave Jobes.  So the
commit will likely be reverted in the 2.6.23 stable kernels.

Secondly, in the 2.6.24 model, x86-64 has now grown support for
SPARSEMEM_VMEMMAP, which disables the relevant code anyway, so while the
bug is not visible any more, it's become invisible due to the code just
being irrelevant and no longer enabled on the only architecture that
this ever affected.

backported to 2.6.22 by Chuck Ebbert

Reported-by: Dave Jones 
Tested-by: Martin Ebourne 
Cc: Zou Nan hai 
Cc: Suresh Siddha 
Cc: Andrew Morton 
Acked-by: Andy Whitcroft 
Signed-off-by: Linus Torvalds 
Cc: Chuck Ebbert 
Signed-off-by: Greg Kroah-Hartman

dm snapshot: fix invalidation deadlock

2007-11-05T17:56:07+00:00

patch fcac03abd325e4f7a4cc8fe05fea2793b1c8eb75 in mainline

Process persistent exception store metadata IOs in a separate thread.

A snapshot may become invalid while inside generic_make_request().
A synchronous write is then needed to update the metadata while still
inside that function.  Since the introduction of
md-dm-reduce-stack-usage-with-stacked-block-devices.patch this has to
be performed by a separate thread to avoid deadlock.

Signed-off-by: Milan Broz 
Signed-off-by: Alasdair G Kergon 
Signed-off-by: Linus Torvalds 
Cc: Chuck Ebbert 
Signed-off-by: Greg Kroah-Hartman

x86: fix global_flush_tlb() bug

2007-11-05T17:56:07+00:00

patch 9a24d04a3c26c223f22493492c5c9085b8773d4a upstream

While we were reviewing pageattr_32/64.c for unification,
Thomas Gleixner noticed the following serious SMP bug in
global_flush_tlb():

	down_read(&init_mm.mmap_sem);
	list_replace_init(&deferred_pages, &l);
	up_read(&init_mm.mmap_sem);

this is SMP-unsafe because list_replace_init() done on two CPUs in
parallel can corrupt the list.

This bug has been introduced about a year ago in the 64-bit tree:

       commit ea7322decb974a4a3e804f96a0201e893ff88ce3
       Author: Andi Kleen 
       Date:   Thu Dec 7 02:14:05 2006 +0100

       [PATCH] x86-64: Speed and clean up cache flushing in change_page_attr

                down_read(&init_mm.mmap_sem);
        -       dpage = xchg(&deferred_pages, NULL);
        +       list_replace_init(&deferred_pages, &l);
                up_read(&init_mm.mmap_sem);

the xchg() based version was SMP-safe, but list_replace_init() is not.
So this "cleanup" introduced a nasty bug.

why this bug never become prominent is a mystery - it can probably be
explained with the (still) relative obscurity of the x86_64 architecture.

the safe fix for now is to write-lock init_mm.mmap_sem.

Signed-off-by: Ingo Molnar 
Signed-off-by: Thomas Gleixner 
Cc: Andi Kleen 
Cc: Andrew Morton 
Signed-off-by: Greg Kroah-Hartman

param_sysfs_builtin memchr argument fix

2007-11-05T17:56:07+00:00

patch faf8c714f4508207a9c81cc94dafc76ed6680b44 in mainline.

If memchr argument is longer than strlen(kp->name), there will be some
weird result.

It will casuse duplicate filenames in sysfs for the "nousb".  kernel
warning messages are as bellow:

sysfs: duplicate filename 'usbcore' can not be created
WARNING: at fs/sysfs/dir.c:416 sysfs_add_one()
 [] sysfs_add_one+0xa0/0xe0
 [] create_dir+0x48/0xb0
 [] sysfs_create_dir+0x29/0x50
 [] create_dir+0x1b/0x50
 [] kobject_add+0x46/0x150
 [] kobject_init+0x3a/0x80
 [] kernel_param_sysfs_setup+0x50/0xb0
 [] param_sysfs_builtin+0xee/0x130
 [] param_sysfs_init+0x23/0x60
 [] __next_cpu+0x12/0x20
 [] kernel_init+0x0/0xb0
 [] kernel_init+0x0/0xb0
 [] do_initcalls+0x46/0x1e0
 [] create_proc_entry+0x52/0x90
 [] register_irq_proc+0x9c/0xc0
 [] proc_mkdir_mode+0x34/0x50
 [] kernel_init+0x0/0xb0
 [] kernel_init+0x62/0xb0
 [] kernel_thread_helper+0x7/0x14
 =======================
kobject_add failed for usbcore with -EEXIST, don't try to register things with the same name in the same directory.
 [] kobject_add+0xf6/0x150
 [] kernel_param_sysfs_setup+0x50/0xb0
 [] param_sysfs_builtin+0xee/0x130
 [] param_sysfs_init+0x23/0x60
 [] __next_cpu+0x12/0x20
 [] kernel_init+0x0/0xb0
 [] kernel_init+0x0/0xb0
 [] do_initcalls+0x46/0x1e0
 [] create_proc_entry+0x52/0x90
 [] register_irq_proc+0x9c/0xc0
 [] proc_mkdir_mode+0x34/0x50
 [] kernel_init+0x0/0xb0
 [] kernel_init+0x62/0xb0
 [] kernel_thread_helper+0x7/0x14
 =======================
Module 'usbcore' failed to be added to sysfs, error number -17
The system will be unstable now.

Signed-off-by: Dave Young 
Cc: Greg KH 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds 
Cc: Chuck Ebbert 
Signed-off-by: Greg Kroah-Hartman

minixfs: limit minixfs printks on corrupted dir i_size (CVE-2006-6058)

2007-11-05T17:56:07+00:00

patch 44ec6f3f89889a469773b1fd894f8fcc07c29cf in mainline

This attempts to address CVE-2006-6058
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-6058

first reported at http://projects.info-pull.com/mokb/MOKB-17-11-2006.html

Essentially a corrupted minix dir inode reporting a very large
i_size will loop for a very long time in minix_readdir, minix_find_entry,
etc, because on EIO they just move on to try the next page.  This is
under the BKL, printk-storming as well.  This can lock up the machine
for a very long time.  Simply ratelimiting the printks gets things back
under control.  Make the message a bit more informative while we're here.

Signed-off-by: Eric Sandeen 
Cc: Bodo Eggert <7eggert@gmx.de>
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds 
Signed-off-by: Greg Kroah-Hartman

IB/uverbs: Fix checking of userspace object ownership

2007-11-05T17:56:06+00:00

Upstream as cbfb50e6e2e9c580848c0f51d37c24cdfb1cb704

Commit 9ead190b ("IB/uverbs: Don't serialize with ib_uverbs_idr_mutex")
rewrote how userspace objects are looked up in the uverbs module's
idrs, and introduced a severe bug in the process: there is no checking
that an operation is being performed by the right process any more.
Fix this by adding the missing check of uobj->context in __idr_get_uobj().

Apparently everyone is being very careful to only touch their own
objects, because this bug was introduced in June 2006 in 2.6.18, and
has gone undetected until now.

Signed-off-by: Roland Dreier 
Signed-off-by: Greg Kroah-Hartman

genirq: mark io_apic level interrupts to avoid resend

2007-11-05T17:56:06+00:00

patch cc75b92d11384ba14f93828a2a0040344ae872e7 in mainline.

Level type interrupts do not need to be resent.  It was also found that
some chipsets get confused in case of the resend.

Mark the ioapic level type interrupts as such to avoid the resend
functionality in the generic irq code.

Signed-off-by: Thomas Gleixner 
Signed-off-by: Linus Torvalds 
Cc: Chuck Ebbert 
Signed-off-by: Greg Kroah-Hartman

genirq: suppress resend of level interrupts

2007-11-05T17:56:06+00:00

patch 2464286ace55b3abddfb9cc30ab95e2dac1de9a6 in mainline.

Level type interrupts are resent by the interrupt hardware when they are
still active at irq_enable().

Suppress the resend mechanism for interrupts marked as level.

Signed-off-by: Thomas Gleixner 
Signed-off-by: Linus Torvalds 
Cc: Chuck Ebbert 
Signed-off-by: Greg Kroah-Hartman

genirq: cleanup mismerge artifact

2007-11-05T17:56:06+00:00

patch 496634217e5671ed876a0348e9f5b7165e830b20 in mainline.

Commit 5a43a066b11ac2fe84cf67307f20b83bea390f83: "genirq: Allow fasteoi
handler to retrigger disabled interrupts" was erroneously applied to
handle_level_irq().  This added the irq retrigger / resend functionality
to the level irq handler.

Revert the offending bits.

Signed-off-by: Thomas Gleixner 
Signed-off-by: Linus Torvalds 
Cc: Chuck Ebbert 
Signed-off-by: Greg Kroah-Hartman