commit cc540ceeceb321a779b1b5a4224774d83a6f1f1b
Author: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date:   Thu Aug 29 09:43:15 2013 -0700

    Linux 3.0.94

commit 43bbe371b28bdcb7367e846d53bf6632a2ab2287
Author: Martin Peschke <mpeschke@linux.vnet.ibm.com>
Date:   Thu Aug 22 17:45:37 2013 +0200

    SCSI: zfcp: fix schedule-inside-lock in scsi_device list loops
    
    commit 924dd584b198a58aa7cb3efefd8a03326550ce8f upstream.
    
    BUG: sleeping function called from invalid context at kernel/workqueue.c:2752
    in_atomic(): 1, irqs_disabled(): 1, pid: 360, name: zfcperp0.0.1700
    CPU: 1 Not tainted 3.9.3+ #69
    Process zfcperp0.0.1700 (pid: 360, task: 0000000075b7e080, ksp: 000000007476bc30)
    <snip>
    Call Trace:
    ([<00000000001165de>] show_trace+0x106/0x154)
     [<00000000001166a0>] show_stack+0x74/0xf4
     [<00000000006ff646>] dump_stack+0xc6/0xd4
     [<000000000017f3a0>] __might_sleep+0x128/0x148
     [<000000000015ece8>] flush_work+0x54/0x1f8
     [<00000000001630de>] __cancel_work_timer+0xc6/0x128
     [<00000000005067ac>] scsi_device_dev_release_usercontext+0x164/0x23c
     [<0000000000161816>] execute_in_process_context+0x96/0xa8
     [<00000000004d33d8>] device_release+0x60/0xc0
     [<000000000048af48>] kobject_release+0xa8/0x1c4
     [<00000000004f4bf2>] __scsi_iterate_devices+0xfa/0x130
     [<000003ff801b307a>] zfcp_erp_strategy+0x4da/0x1014 [zfcp]
     [<000003ff801b3caa>] zfcp_erp_thread+0xf6/0x2b0 [zfcp]
     [<000000000016b75a>] kthread+0xf2/0xfc
     [<000000000070c9de>] kernel_thread_starter+0x6/0xc
     [<000000000070c9d8>] kernel_thread_starter+0x0/0xc
    
    Apparently, the ref_count for some scsi_device drops down to zero,
    triggering device removal through execute_in_process_context(), while
    the lldd error recovery thread iterates through a scsi device list.
    Unfortunately, execute_in_process_context() decides to immediately
    execute that device removal function, instead of scheduling asynchronous
    execution, since it detects process context and thinks it is safe to do
    so. But almost all calls to shost_for_each_device() in our lldd are
    inside spin_lock_irq, even in thread context. Obviously, schedule()
    inside spin_lock_irq sections is a bad idea.
    
    Change the lldd to use the proper iterator function,
    __shost_for_each_device(), in combination with required locking.
    
    Occurences that need to be changed include all calls in zfcp_erp.c,
    since those might be executed in zfcp error recovery thread context
    with a lock held.
    
    Other occurences of shost_for_each_device() in zfcp_fsf.c do not
    need to be changed (no process context, no surrounding locking).
    
    The problem was introduced in Linux 2.6.37 by commit
    b62a8d9b45b971a67a0f8413338c230e3117dff5
    "[SCSI] zfcp: Use SCSI device data zfcp_scsi_dev instead of zfcp_unit".
    
    Reported-by: Christian Borntraeger <borntraeger@de.ibm.com>
    Signed-off-by: Martin Peschke <mpeschke@linux.vnet.ibm.com>
    Signed-off-by: Steffen Maier <maier@linux.vnet.ibm.com>
    Signed-off-by: James Bottomley <JBottomley@Parallels.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 374172589a9c99e63c373b1c74588553237a74d3
Author: Martin Peschke <mpeschke@linux.vnet.ibm.com>
Date:   Thu Aug 22 17:45:36 2013 +0200

    SCSI: zfcp: fix lock imbalance by reworking request queue locking
    
    commit d79ff142624e1be080ad8d09101f7004d79c36e1 upstream.
    
    This patch adds wait_event_interruptible_lock_irq_timeout(), which is a
    straight-forward descendant of wait_event_interruptible_timeout() and
    wait_event_interruptible_lock_irq().
    
    The zfcp driver used to call wait_event_interruptible_timeout()
    in combination with some intricate and error-prone locking. Using
    wait_event_interruptible_lock_irq_timeout() as a replacement
    nicely cleans up that locking.
    
    This rework removes a situation that resulted in a locking imbalance
    in zfcp_qdio_sbal_get():
    
    BUG: workqueue leaked lock or atomic: events/1/0xffffff00/10
        last function: zfcp_fc_wka_port_offline+0x0/0xa0 [zfcp]
    
    It was introduced by commit c2af7545aaff3495d9bf9a7608c52f0af86fb194
    "[SCSI] zfcp: Do not wait for SBALs on stopped queue", which had a new
    code path related to ZFCP_STATUS_ADAPTER_QDIOUP that took an early exit
    without a required lock being held. The problem occured when a
    special, non-SCSI I/O request was being submitted in process context,
    when the adapter's queues had been torn down. In this case the bug
    surfaced when the Fibre Channel port connection for a well-known address
    was closed during a concurrent adapter shut-down procedure, which is a
    rare constellation.
    
    This patch also fixes these warnings from the sparse tool (make C=1):
    
    drivers/s390/scsi/zfcp_qdio.c:224:12: warning: context imbalance in
     'zfcp_qdio_sbal_check' - wrong count at exit
    drivers/s390/scsi/zfcp_qdio.c:244:5: warning: context imbalance in
     'zfcp_qdio_sbal_get' - unexpected unlock
    
    Last but not least, we get rid of that crappy lock-unlock-lock
    sequence at the beginning of the critical section.
    
    It is okay to call zfcp_erp_adapter_reopen() with req_q_lock held.
    
    Reported-by: Mikulas Patocka <mpatocka@redhat.com>
    Reported-by: Heiko Carstens <heiko.carstens@de.ibm.com>
    Signed-off-by: Martin Peschke <mpeschke@linux.vnet.ibm.com>
    Signed-off-by: Steffen Maier <maier@linux.vnet.ibm.com>
    Signed-off-by: James Bottomley <JBottomley@Parallels.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 016d826cfcb22b27915149aabadf461641b7907c
Author: Terry Suereth <terry.suereth@gmail.com>
Date:   Sat Aug 17 15:53:12 2013 -0400

    libata: apply behavioral quirks to sil3826 PMP
    
    commit 8ffff94d20b7eb446e848e0046107d51b17a20a8 upstream.
    
    Fixing support for the Silicon Image 3826 port multiplier, by applying
    to it the same quirks applied to the Silicon Image 3726.  Specifically
    fixes the repeated timeout/reset process which previously afflicted
    the 3726, as described from line 290.  Slightly based on notes from:
    
    https://bugzilla.redhat.com/show_bug.cgi?id=890237
    
    Signed-off-by: Terry Suereth <terry.suereth@gmail.com>
    Signed-off-by: Tejun Heo <tj@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 8d43271717d467f6795cfc5a81fd2cd886833330
Author: Dan Carpenter <dan.carpenter@oracle.com>
Date:   Fri Aug 9 12:52:31 2013 +0300

    Hostap: copying wrong data prism2_ioctl_giwaplist()
    
    commit 909bd5926d474e275599094acad986af79671ac9 upstream.
    
    We want the data stored in "addr" and "qual", but the extra ampersands
    mean we are copying stack data instead.
    
    Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
    Signed-off-by: John W. Linville <linville@tuxdriver.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 3c6766ab27147383b3a084d29cb87163342f14b0
Author: Vyacheslav Dubeyko <slava@dubeyko.com>
Date:   Thu Aug 22 16:35:45 2013 -0700

    nilfs2: fix issue with counting number of bio requests for BIO_EOPNOTSUPP error detection
    
    commit 4bf93b50fd04118ac7f33a3c2b8a0a1f9fa80bc9 upstream.
    
    Fix the issue with improper counting number of flying bio requests for
    BIO_EOPNOTSUPP error detection case.
    
    The sb_nbio must be incremented exactly the same number of times as
    complete() function was called (or will be called) because
    nilfs_segbuf_wait() will call wail_for_completion() for the number of
    times set to sb_nbio:
    
      do {
          wait_for_completion(&segbuf->sb_bio_event);
      } while (--segbuf->sb_nbio > 0);
    
    Two functions complete() and wait_for_completion() must be called the
    same number of times for the same sb_bio_event.  Otherwise,
    wait_for_completion() will hang or leak.
    
    Signed-off-by: Vyacheslav Dubeyko <slava@dubeyko.com>
    Cc: Dan Carpenter <dan.carpenter@oracle.com>
    Acked-by: Ryusuke Konishi <konishi.ryusuke@lab.ntt.co.jp>
    Tested-by: Ryusuke Konishi <konishi.ryusuke@lab.ntt.co.jp>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 637a641c5478377849d936fa276f92a4f418bb65
Author: Vyacheslav Dubeyko <slava@dubeyko.com>
Date:   Thu Aug 22 16:35:44 2013 -0700

    nilfs2: remove double bio_put() in nilfs_end_bio_write() for BIO_EOPNOTSUPP error
    
    commit 2df37a19c686c2d7c4e9b4ce1505b5141e3e5552 upstream.
    
    Remove double call of bio_put() in nilfs_end_bio_write() for the case of
    BIO_EOPNOTSUPP error detection.  The issue was found by Dan Carpenter
    and he suggests first version of the fix too.
    
    Signed-off-by: Vyacheslav Dubeyko <slava@dubeyko.com>
    Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
    Acked-by: Ryusuke Konishi <konishi.ryusuke@lab.ntt.co.jp>
    Tested-by: Ryusuke Konishi <konishi.ryusuke@lab.ntt.co.jp>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 14c3de73b19d1c758ae92ec4674482742ad54fb3
Author: Wladislav Wiebe <wladislav.kw@gmail.com>
Date:   Mon Aug 12 13:06:53 2013 +0200

    of: fdt: fix memory initialization for expanded DT
    
    commit 9e40127526e857fa3f29d51e83277204fbdfc6ba upstream.
    
    Already existing property flags are filled wrong for properties created from
    initial FDT. This could cause problems if this DYNAMIC device-tree functions
    are used later, i.e. properties are attached/detached/replaced. Simply dumping
    flags from the running system show, that some initial static (not allocated via
    kzmalloc()) nodes are marked as dynamic.
    
    I putted some debug extensions to property_proc_show(..) :
    ..
    +       if (OF_IS_DYNAMIC(pp))
    +               pr_err("DEBUG: xxx : OF_IS_DYNAMIC\n");
    +       if (OF_IS_DETACHED(pp))
    +               pr_err("DEBUG: xxx : OF_IS_DETACHED\n");
    
    when you operate on the nodes (e.g.: ~$ cat /proc/device-tree/*some_node*) you
    will see that those flags are filled wrong, basically in most cases it will dump
    a DYNAMIC or DETACHED status, which is in not true.
    (BTW. this OF_IS_DETACHED is a own define for debug purposes which which just
    make a test_bit(OF_DETACHED, &x->_flags)
    
    If nodes are dynamic kernel is allowed to kfree() them. But it will crash
    attempting to do so on the nodes from FDT -- they are not allocated via
    kzmalloc().
    
    Signed-off-by: Wladislav Wiebe <wladislav.kw@gmail.com>
    Acked-by: Alexander Sverdlin <alexander.sverdlin@nsn.com>
    Signed-off-by: Rob Herring <rob.herring@calxeda.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 1b9ba06c5f4e84b8dfa402bee0daff42db045977
Author: David Vrabel <david.vrabel@citrix.com>
Date:   Thu Aug 15 13:21:06 2013 +0100

    xen/events: initialize local per-cpu mask for all possible events
    
    commit 84ca7a8e45dafb49cd5ca90a343ba033e2885c17 upstream.
    
    The sizeof() argument in init_evtchn_cpu_bindings() is incorrect
    resulting in only the first 64 (or 32 in 32-bit guests) ports having
    their bindings being initialized to VCPU 0.
    
    In most cases this does not cause a problem as request_irq() will set
    the irq affinity which will set the correct local per-cpu mask.
    However, if the request_irq() is called on a VCPU other than 0, there
    is a window between the unmasking of the event and the affinity being
    set were an event may be lost because it is not locally unmasked on
    any VCPU. If request_irq() is called on VCPU 0 then local irqs are
    disabled during the window and the race does not occur.
    
    Fix this by initializing all NR_EVENT_CHANNEL bits in the local
    per-cpu masks.
    
    Signed-off-by: David Vrabel <david.vrabel@citrix.com>
    Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 50e27a160f6146de036e81420dc13ec9f4824564
Author: Jussi Kivilinna <jussi.kivilinna@iki.fi>
Date:   Tue Aug 6 14:28:42 2013 +0300

    zd1201: do not use stack as URB transfer_buffer
    
    commit 1206ff4ff9d2ef7468a355328bc58ac6ebf5be44 upstream.
    
    Patch fixes zd1201 not to use stack as URB transfer_buffer. URB buffers need
    to be DMA-able, which stack is not.
    
    Patch is only compile tested.
    
    Signed-off-by: Jussi Kivilinna <jussi.kivilinna@iki.fi>
    Signed-off-by: John W. Linville <linville@tuxdriver.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>