linux-toradex.git/lib, branch v2.6.32.52

netlink: validate NLA_MSECS length

2011-11-26T17:10:33+00:00

commit c30bc94758ae2a38a5eb31767c1985c0aae0950b upstream.

L2TP for example uses NLA_MSECS like this:
policy:
        [L2TP_ATTR_RECV_TIMEOUT]        = { .type = NLA_MSECS, },
code:
        if (info->attrs[L2TP_ATTR_RECV_TIMEOUT])
                cfg.reorder_timeout = nla_get_msecs(info->attrs[L2TP_ATTR_RECV_TIMEOUT]);

As nla_get_msecs() is essentially nla_get_u64() plus the
conversion to a HZ-based value, this will not properly
reject attributes from userspace that aren't long enough
and might overrun the message.

Add NLA_MSECS to the attribute minlen array to check the
size properly.

Cc: Thomas Graf 
Signed-off-by: Johannes Berg 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman

kobj_uevent: Ignore if some listeners cannot handle message

2011-11-07T20:32:25+00:00

commit ebf4127cd677e9781b450e44dfaaa1cc595efcaa upstream.

kobject_uevent() uses a multicast socket and should ignore
if one of listeners cannot handle messages or nobody is
listening at all.

Easily reproducible when a process in system is cloned
with CLONE_NEWNET flag.

(See also http://article.gmane.org/gmane.linux.kernel.device-mapper.dm-crypt/5256)

Signed-off-by: Milan Broz 
Acked-by: Kay Sievers 
Signed-off-by: Greg Kroah-Hartman

crypto: Move md5_transform to lib/md5.c

2011-08-16T01:57:20+00:00

We are going to use this for TCP/IP sequence number and fragment ID
generation.

Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman

debugobjects: Fix boot crash when kmemleak and debugobjects enabled

2011-07-13T03:29:24+00:00

commit 161b6ae0e067e421b20bb35caf66bdb405c929ac upstream.

Order of initialization look like this:
...
debugobjects
kmemleak
...(lots of other subsystems)...
workqueues (through early initcall)
...

debugobjects use schedule_work for batch freeing of its data and kmemleak
heavily use debugobjects, so when it comes to freeing and workqueues were
not initialized yet, kernel crashes:

BUG: unable to handle kernel NULL pointer dereference at           (null)
IP: [] __queue_work+0x29/0x41a
 [] queue_work_on+0x16/0x1d
 [] queue_work+0x29/0x55
 [] schedule_work+0x13/0x15
 [] free_object+0x90/0x95
 [] debug_check_no_obj_freed+0x187/0x1d3
 [] ? _raw_spin_unlock_irqrestore+0x30/0x4d
 [] ? free_object_rcu+0x68/0x6d
 [] kmem_cache_free+0x64/0x12c
 [] free_object_rcu+0x68/0x6d
 [] __rcu_process_callbacks+0x1b6/0x2d9
...

because system_wq is NULL.

Fix it by checking if workqueues susbystem was initialized before using.

Signed-off-by: Marcin Slusarz 
Cc: Catalin Marinas 
Cc: Tejun Heo 
Cc: Dipankar Sarma 
Cc: Paul E. McKenney 
Link: http://lkml.kernel.org/r/20110528112342.GA3068@joi.lan
Signed-off-by: Thomas Gleixner 
Signed-off-by: Greg Kroah-Hartman

rcu: Fix unpaired rcu_irq_enter() from locking selftests

2011-06-23T22:24:02+00:00

commit ba9f207c9f82115aba4ce04b22e0081af0ae300f upstream.

HARDIRQ_ENTER() maps to irq_enter() which calls rcu_irq_enter().
But HARDIRQ_EXIT() maps to __irq_exit() which doesn't call
rcu_irq_exit().

So for every locking selftest that simulates hardirq disabled,
we create an imbalance in the rcu extended quiescent state
internal state.

As a result, after the first missing rcu_irq_exit(), subsequent
irqs won't exit dyntick-idle mode after leaving the interrupt
handler.  This means that RCU won't see the affected CPU as being
in an extended quiescent state, resulting in long grace-period
delays (as in grace periods extending for hours).

To fix this, just use __irq_enter() to simulate the hardirq
context. This is sufficient for the locking selftests as we
don't need to exit any extended quiescent state or perform
any check that irqs normally do when they wake up from idle.

As a side effect, this patch makes it possible to restore
"rcu: Decrease memory-barrier usage based on semi-formal proof",
which eventually helped finding this bug.

Reported-and-tested-by: Yinghai Lu 
Signed-off-by: Frederic Weisbecker 
Cc: Paul E. McKenney 
Cc: Ingo Molnar 
Cc: Peter Zijlstra 
Signed-off-by: Paul E. McKenney 
Signed-off-by: Greg Kroah-Hartman

Revert "swiotlb: fix wrong panic"

2011-03-03T16:23:19+00:00

This reverts commit 484d82b6e2e4239ba7a722e0c532e9aff64be51a.

It caused build problems on some architectures and was already asked to
be removed from the queue.  It was my fault for incorrectly applying it.

Reported-by: Shawn Bohrer 
Reported-by: David Engel 
Signed-off-by: Greg Kroah-Hartman

swiotlb: fix wrong panic

2011-03-02T14:47:04+00:00

commit fba99fa38b023224680308a482e12a0eca87e4e1 upstream.

swiotlb's map_page wrongly calls panic() when it can't find a buffer fit
for device's dma mask.  It should return an error instead.

Devices with an odd dma mask (i.e.  under 4G) like b44 network card hit
this bug (the system crashes):

   http://marc.info/?l=linux-kernel&m=129648943830106&w=2

If swiotlb returns an error, b44 driver can use the own bouncing
mechanism.

Reported-by: Chuck Ebbert 
Signed-off-by: FUJITA Tomonori 
Tested-by: Arkadiusz Miskiewicz 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds 
Signed-off-by: Greg Kroah-Hartman

percpu: fix list_head init bug in __percpu_counter_init()

2010-12-09T21:26:37+00:00

commit 8474b591faf3bb0a1e08a60d21d6baac498f15e4 upstream.

WARNING: at lib/list_debug.c:26 __list_add+0x3f/0x81()
Hardware name: Express5800/B120a [N8400-085]
list_add corruption. next->prev should be prev (ffffffff81a7ea00), but was dead000000200200. (next=ffff88080b872d58).
Modules linked in: aoe ipt_MASQUERADE iptable_nat nf_nat autofs4 sunrpc bridge 8021q garp stp llc ipv6 cpufreq_ondemand acpi_cpufreq freq_table dm_round_robin dm_multipath kvm_intel kvm uinput lpfc scsi_transport_fc igb ioatdma scsi_tgt i2c_i801 i2c_core dca iTCO_wdt iTCO_vendor_support pcspkr shpchp megaraid_sas [last unloaded: aoe]
Pid: 54, comm: events/3 Tainted: G        W  2.6.34-vanilla1 #1
Call Trace:
[] warn_slowpath_common+0x7c/0x94
[] warn_slowpath_fmt+0x41/0x43
[] __list_add+0x3f/0x81
[] __percpu_counter_init+0x59/0x6b
[] bdi_init+0x118/0x17e
[] blk_alloc_queue_node+0x79/0x143
[] blk_alloc_queue+0x11/0x13
[] aoeblk_gdalloc+0x8e/0x1c9 [aoe]
[] aoecmd_sleepwork+0x25/0xa8 [aoe]
[] worker_thread+0x1a9/0x237
[] ? aoecmd_sleepwork+0x0/0xa8 [aoe]
[] ? autoremove_wake_function+0x0/0x39
[] ? worker_thread+0x0/0x237
[] kthread+0x7f/0x87
[] kernel_thread_helper+0x4/0x10
[] ? kthread+0x0/0x87
[] ? kernel_thread_helper+0x0/0x10

It's because there is no initialization code for a list_head contained in
the struct backing_dev_info under CONFIG_HOTPLUG_CPU, and the bug comes up
when block device drivers calling blk_alloc_queue() are used.  In case of
me, I got them by using aoe.

Signed-off-by: Masanori Itoh 
Cc: Tejun Heo 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds 
Signed-off-by: Greg Kroah-Hartman

flex_array: fix the panic when calling flex_array_alloc() without __GFP_ZERO

2010-05-12T21:57:00+00:00

commit e59464c735db19619cde2aa331609adb02005f5b upstream.

memset() is called with the wrong address and the kernel panics.

Signed-off-by: Changli Gao 
Cc: Patrick McHardy 
Acked-by: David Rientjes 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds 
Signed-off-by: Greg Kroah-Hartman

block: Backport of various I/O topology fixes from 2.6.33 and 2.6.34

2010-04-01T22:58:56+00:00

block: Backport of various I/O topology fixes from 2.6.33 and 2.6.34

The stacking code incorrectly scaled up the data offset in some cases
causing misaligned devices to report alignment.  Rewrite the stacking
algorithm to remedy this.  

(Upstream commit 9504e0864b58b4a304820dcf3755f1da80d5e72f)

The top device misalignment flag would not be set if the added bottom
device was already misaligned as opposed to causing a stacking failure.
    
Also massage the reporting so that an error is only returned if adding
the bottom device caused the misalignment.  I.e. don't return an error
if the top is already flagged as misaligned.

(Upstream commit fe0b393f2c0a0d23a9bc9ed7dc51a1ee511098bd)


lcm() was defined to take integer-sized arguments.  The supplied
arguments are multiplied, however, causing us to overflow given
sufficiently large input.  That in turn led to incorrect optimal I/O
size reporting in some cases.  Switch lcm() over to unsigned long
similar to gcd() and move the function from blk-settings.c to lib.

Signed-off-by: Martin K. Petersen 
Reviewed-by: Mike Snitzer 
Signed-off-by: Greg Kroah-Hartman