linux.git, branch v3.9.8

Linux 3.9.8

2013-06-27T17:41:32+00:00

spi/pxa2xx: fix memory corruption due to wrong size used in devm_kzalloc()

2013-06-27T17:39:23+00:00

commit cc0ee9873c6afafb387379ca1df25da78a08c603 upstream.

ACPI part of the driver accidentally used sizeof(*ssp) instead of the
correct sizeof(*pdata). This leads to nasty memory corruptions like the one
below:

    BUG: unable to handle kernel paging request at 0000000749fd30b8
    IP: [] __list_del_entry+0x31/0xd0
    PGD 0
    Oops: 0000 [#1] PREEMPT SMP
    Modules linked in:
    CPU: 0 PID: 30 Comm: kworker/0:1 Not tainted 3.10.0-rc6v3.10-rc6_sdhci_modprobe+ #443
    task: ffff8801483a0940 ti: ffff88014839e000 task.ti: ffff88014839e000
    RIP: 0010:[]  [] __list_del_entry+0x31/0xd0
    RSP: 0000:ffff88014839fde8  EFLAGS: 00010046
    RAX: ffff880149fd30b0 RBX: ffff880149fd3040 RCX: dead000000200200
    RDX: 0000000749fd30b0 RSI: ffff880149fd3058 RDI: ffff88014834d640
    RBP: ffff88014839fde8 R08: ffff88014834d640 R09: 0000000000000001
    R10: ffff8801483a0940 R11: 0000000000000001 R12: ffff880149fd3040
    R13: ffffffff810e0b30 R14: ffff8801483a0940 R15: ffff88014834d640
    FS:  0000000000000000(0000) GS:ffff880149e00000(0000) knlGS:0000000000000000
    CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
    CR2: 0000000000000168 CR3: 0000000001e0b000 CR4: 00000000001407f0
    DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
    DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
    Stack:
     ffff88014839fe48 ffffffff810e0baf ffffffff81120abd ffff88014839fe20
     ffff8801483a0940 ffff8801483a0940 ffff8801483a0940 ffff8801486b1c90
     ffff88014834d640 ffffffff810e0b30 0000000000000000 0000000000000000
    Call Trace:
     [] worker_thread+0x7f/0x390
     [] ? trace_hardirqs_on+0xd/0x10
     [] ? manage_workers.isra.22+0x2b0/0x2b0
     [] kthread+0xd9/0xe0
     [] ? local_clock+0x3f/0x50
     [] ? kthread_create_on_node+0x110/0x110
     [] ret_from_fork+0x7c/0xb0
     [] ? kthread_create_on_node+0x110/0x110

Fix this by using the right structure size in devm_kzalloc().

Reported-by: Jerome Blin 
Signed-off-by: Mika Westerberg 
Signed-off-by: Mark Brown 
Signed-off-by: Greg Kroah-Hartman

spi/pxa2xx: use GFP_ATOMIC in sg table allocation

2013-06-27T17:39:23+00:00

commit 5548f98c46538d1da04eff179a52e50537d11465 upstream.

pxa2xx_spi_map_dma_buffer() gets called in tasklet context so we can't
sleep when we allocate a new sg table. Use GFP_ATOMIC here instead.

Signed-off-by: Mika Westerberg 
Signed-off-by: Mark Brown 
Signed-off-by: Greg Kroah-Hartman

drivers: uio: Fix UIO device registration failure

2013-06-27T17:39:23+00:00

commit 5ed0505c713805f89473cdc0bbfb5110dfd840cb upstream.

Until recently uio_get_minor() returned 0 for success and
a negative value on failure.  This became non-negative for suceess and
negative for failure.  Restore the original return value spec so that we can
successfully initialize UIO devices with a non-zero minor device
number.

Signed-off-by: Damian Hobson-Garcia 
Cc: "Hans J. Koch" 
Cc: Guenter Roeck 
Signed-off-by: Greg Kroah-Hartman

perf: Fix mmap() accounting hole

2013-06-27T17:39:23+00:00

commit 9bb5d40cd93c9dd4be74834b1dcb1ba03629716b upstream.

Vince's fuzzer once again found holes. This time it spotted a leak in
the locked page accounting.

When an event had redirected output and its close() was the last
reference to the buffer we didn't have a vm context to undo accounting.

Change the code to destroy the buffer on the last munmap() and detach
all redirected events at that time. This provides us the right context
to undo the vm accounting.

Reported-and-tested-by: Vince Weaver 
Signed-off-by: Peter Zijlstra 
Link: http://lkml.kernel.org/r/20130604084421.GI8923@twins.programming.kicks-ass.net
Signed-off-by: Ingo Molnar 
Signed-off-by: Greg Kroah-Hartman

perf: Fix perf mmap bugs

2013-06-27T17:39:22+00:00

commit 26cb63ad11e04047a64309362674bcbbd6a6f246 upstream.

Vince reported a problem found by his perf specific trinity
fuzzer.

Al noticed 2 problems with perf's mmap():

 - it has issues against fork() since we use vma->vm_mm for accounting.
 - it has an rb refcount leak on double mmap().

We fix the issues against fork() by using VM_DONTCOPY; I don't
think there's code out there that uses this; we didn't hear
about weird accounting problems/crashes. If we do need this to
work, the previously proposed VM_PINNED could make this work.

Aside from the rb reference leak spotted by Al, Vince's example
prog was indeed doing a double mmap() through the use of
perf_event_set_output().

This exposes another problem, since we now have 2 events with
one buffer, the accounting gets screwy because we account per
event. Fix this by making the buffer responsible for its own
accounting.

Reported-by: Vince Weaver 
Signed-off-by: Peter Zijlstra 
Cc: Al Viro 
Cc: Paul Mackerras 
Cc: Arnaldo Carvalho de Melo 
Link: http://lkml.kernel.org/r/20130528085548.GA12193@twins.programming.kicks-ass.net
Signed-off-by: Ingo Molnar 
Signed-off-by: Greg Kroah-Hartman

rbd: use the correct length for format 2 object names

2013-06-27T17:39:17+00:00

commit 3a96d5cd7bdce45d5dded75c3a62d4fb98050280 upstream.

[Backported for 3.9-stable.
'kmalloc(MAX_OBJ_NAME_SIZE + 1, GFP_NOIO)' was changed as
'kmem_cache_alloc(rbd_segment_name_cache, GFP_NOIO)' in 78c2a44
since 3.10-rc1, and 78c2a44 is relied on a big patchset, so restore
it as 3.9 did.]

Format 2 objects use 16 characters for the object name suffix to be
able to express the full 64-bit range of object numbers. Format 1
images only use 12 characters for this. Using 12-character names for
format 2 caused userspace and kernel rbd clients to read differently
named objects, which made an image written by one client look empty to
the other client.

Reported-by: Chris Dunlop 
Signed-off-by: Josh Durgin 
Reviewed-by: Sage Weil 
Reviewed-by: Lingzhu Xiang 
Signed-off-by: Zhouping Liu 
Signed-off-by: Greg Kroah-Hartman

target/iscsi: don't corrupt bh_count in iscsit_stop_time2retain_timer()

2013-06-27T17:39:10+00:00

commit 574780fd5e6ec52bd43e0bdb777a19e4c4c6aa9c upstream.

Here is a fun one.  Bug seems to have been introduced by commit 140854cb,
almost two years ago.  I have no idea why we only started seeing it now,
but we did.

Rough callgraph:
core_tpg_set_initiator_node_queue_depth()
`-> spin_lock_irqsave(&tpg->session_lock, flags);
`-> lio_tpg_shutdown_session()
    `-> iscsit_stop_time2retain_timer()
        `-> spin_unlock_bh(&se_tpg->session_lock);
        `-> spin_lock_bh(&se_tpg->session_lock);
`-> spin_unlock_irqrestore(&tpg->session_lock, flags);

core_tpg_set_initiator_node_queue_depth() used to call spin_lock_bh(),
but 140854cb changed that to spin_lock_irqsave().  However,
lio_tpg_shutdown_session() still claims to be called with spin_lock_bh()
held, as does iscsit_stop_time2retain_timer():
 *      Called with spin_lock_bh(&struct se_portal_group->session_lock) held

Stale documentation is mostly annoying, but in this case the dropping
the lock with the _bh variant is plain wrong.  It is also wrong to drop
locks two functions below the lock-holder, but I will ignore that bit
for now.

After some more locking and unlocking we eventually hit this backtrace:
------------[ cut here ]------------
WARNING: at kernel/softirq.c:159 local_bh_enable_ip+0xe8/0x100()
Pid: 24645, comm: lio_helper.py Tainted: G           O 3.6.11+
Call Trace:
 [] warn_slowpath_common+0x7f/0xc0
 [] ? iscsit_inc_conn_usage_count+0x37/0x50 [iscsi_target_mod]
 [] warn_slowpath_null+0x1a/0x20
 [] local_bh_enable_ip+0xe8/0x100
 [] _raw_spin_unlock_bh+0x15/0x20
 [] iscsit_inc_conn_usage_count+0x37/0x50 [iscsi_target_mod]
 [] iscsit_stop_session+0xfa/0x1c0 [iscsi_target_mod]
 [] lio_tpg_shutdown_session+0x7b/0x90 [iscsi_target_mod]
 [] core_tpg_set_initiator_node_queue_depth+0xe4/0x290 [target_core_mod]
 [] iscsit_tpg_set_initiator_node_queue_depth+0x12/0x20 [iscsi_target_mod]
 [] lio_target_nacl_store_cmdsn_depth+0xa9/0x180 [iscsi_target_mod]
 [] target_fabric_nacl_base_attr_store+0x39/0x40 [target_core_mod]
 [] configfs_write_file+0xbd/0x120
 [] vfs_write+0xc6/0x180
 [] sys_write+0x51/0x90
 [] system_call_fastpath+0x16/0x1b
---[ end trace 3747632b9b164652 ]---

As a pure band-aid, this patch drops the _bh.

Signed-off-by: Joern Engel 
Signed-off-by: Nicholas Bellinger

tty: Fix transient pty write() EIO

2013-06-27T17:39:09+00:00

commit 7c61c3d8f44d5d822f758754287af644307b4af9 upstream.

Commit 699390354da6c258b65bf8fa79cfd5feaede50b6
('pty: Ignore slave pty close() if never successfully opened')
introduced a bug with ptys whereby a write() in parallel with an
open() on an existing pty could mistakenly indicate an I/O error.

Only indicate an I/O error if the condition on open() actually exists.

Reported-by: Markus Trippelsdorf 
Signed-off-by: Peter Hurley 
Tested-by: Mikael Pettersson 
Signed-off-by: Greg Kroah-Hartman

tcm_qla2xxx: Fix residual for underrun commands that fail

2013-06-27T17:39:09+00:00

commit b5aff3d2747bea08b386edd070941a45611ffe51 upstream.

Suppose an initiator sends a DATA IN command with an allocation length
shorter than the FC transfer length -- we get a target message like

    TARGET_CORE[qla2xxx]: Expected Transfer Length: 256 does not match SCSI CDB Length: 0 for SAM Opcode: 0x12

In that case, the target core adjusts the data_length and sets
se_cmd->residual_count for the underrun.  But now suppose that command
fails and we end up in tcm_qla2xxx_queue_status() -- that function
unconditionally overwrites residual_count with the already adjusted
data_length, and the initiator will burp with a message like

    qla2xxx [0000:00:06.0]-301d:0: Dropped frame(s) detected (0x100 of 0x100 bytes).

Fix this by adding on to the existing underflow residual count instead.

Signed-off-by: Roland Dreier 
Cc: Giridhar Malavali 
Cc: Chad Dupuis 
Signed-off-by: Nicholas Bellinger 
Signed-off-by: Greg Kroah-Hartman