mutex: Fix w/w mutex deadlock injection

The check needs to be for > 1, because ctx->acquired is already incremented.
This will prevent ww_mutex_lock_slow from returning -EDEADLK and not locking
the mutex. It caused a lot of false gpu lockups on radeon with
CONFIG_DEBUG_WW_MUTEX_SLOWPATH=y because a function that shouldn't be able
to return -EDEADLK did.

Signed-off-by: Maarten Lankhorst <maarten.lankhorst@canonical.com>
Signed-off-by: Peter Zijlstra <peterz@infradead.org>
Cc: Alex Deucher <alexander.deucher@amd.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Link: http://lkml.kernel.org/r/51F775B5.201@canonical.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
[SCSI] megaraid_sas: megaraid_sas driver init fails in kdump kernel

Problem: When Hardware IOMMU is on, megaraid_sas driver initialization fails
in kdump kernel with LSI MegaRAID controller(device id-0x73).

Actually this issue needs fix in firmware, but for firmware running in field,
this driver fix is proposed to resolve the issue.  At firmware initialization
time, if firmware does not come to ready state, driver will reset the adapter
and retry for firmware transition to ready state unconditionally(not only
executed for kdump kernel).

Signed-off-by: Sumit Saxena <sumit.saxena@lsi.com>
Signed-off-by: Kashyap Desai <kashyap.desai@lsi.com>
Cc: stable@vger.kernel.org
Signed-off-by: James Bottomley <JBottomley@Parallels.com>
[SCSI] fnic: BUG: sleeping function called from invalid context during probe

I hit this during driver probe with the latest fnic updates (this trace
is from a backport into a distro kernel, but the issue is the same).

> BUG: sleeping function called from invalid context at mm/slab.c:3113
> in_atomic(): 0, irqs_disabled(): 1, pid: 610, name: work_for_cpu
> INFO: lockdep is turned off.
> irq event stamp: 0
> hardirqs last  enabled at (0): [<(null)>] (null)
> hardirqs last disabled at (0): [<ffffffff81070aa5>]
> copy_process+0x5e5/0x1670
> softirqs last  enabled at (0): [<ffffffff81070aa5>]
> copy_process+0x5e5/0x1670
> softirqs last disabled at (0): [<(null)>] (null)
> Pid: 610, comm: work_for_cpu Not tainted
> Call Trace:
>  [<ffffffff810b2d10>] ? print_irqtrace_events+0xd0/0xe0
>  [<ffffffff8105c1a7>] ? __might_sleep+0xf7/0x130
>  [<ffffffff81184efb>] ? kmem_cache_alloc_trace+0x20b/0x2d0
>  [<ffffffff8109709e>] ? __create_workqueue_key+0x3e/0x1d0
>  [<ffffffff8109709e>] ? __create_workqueue_key+0x3e/0x1d0
>  [<ffffffffa00c101c>] ? fnic_probe+0x977/0x11aa [fnic]
>  [<ffffffffa00c1048>] ? fnic_probe+0x9a3/0x11aa [fnic]
>  [<ffffffff81096f00>] ? do_work_for_cpu+0x0/0x30
>  [<ffffffff812c6da7>] ? local_pci_probe+0x17/0x20
>  [<ffffffff81096f18>] ? do_work_for_cpu+0x18/0x30
>  [<ffffffff8109cdc6>] ? kthread+0x96/0xa0
>  [<ffffffff8100c1ca>] ? child_rip+0xa/0x20
>  [<ffffffff81550f80>] ? _spin_unlock_irq+0x30/0x40
>  [<ffffffff8100bb10>] ? restore_args+0x0/0x30
>  [<ffffffff8109cd30>] ? kthread+0x0/0xa0
>  [<ffffffff8100c1c0>] ? child_rip+0x0/0x20

The problem is in this hunk of "FIP VLAN Discovery Feature Support"
(d3c995f1dcf938f1084388d92b8fb97bec366566)

create_singlethreaded_workqueue cannot be called with irqs disabled

@@ -620,7 +634,29 @@ static int __devinit fnic_probe(struct pci_dev
*pdev,
        vnic_dev_packet_filter(fnic->vdev, 1, 1, 0, 0, 0);
        vnic_dev_add_addr(fnic->vdev, FIP_ALL_ENODE_MACS);
        vnic_dev_add_addr(fnic->vdev, fnic->ctlr.ctl_src_addr);
+       fnic->set_vlan = fnic_set_vlan;
        fcoe_ctlr_init(&fnic->ctlr, FIP_MODE_AUTO);
+       setup_timer(&fnic->fip_timer, fnic_fip_notify_timer,
+                           (unsigned long)fnic);
+       spin_lock_init(&fnic->vlans_lock);
+       INIT_WORK(&fnic->fip_frame_work, fnic_handle_fip_frame);
+       INIT_WORK(&fnic->event_work, fnic_handle_event);
+       skb_queue_head_init(&fnic->fip_frame_queue);
+       spin_lock_irqsave(&fnic_list_lock, flags);
+       if (!fnic_fip_queue) {
+           fnic_fip_queue =
+               create_singlethread_workqueue("fnic_fip_q");
+           if (!fnic_fip_queue) {
+               spin_unlock_irqrestore(&fnic_list_lock, flags);
+               printk(KERN_ERR PFX "fnic FIP work queue "
+                        "create failed\n");
+               err = -ENOMEM;
+               goto err_out_free_max_pool;
+           }
+       }
+       spin_unlock_irqrestore(&fnic_list_lock, flags);
+       INIT_LIST_HEAD(&fnic->evlist);
+       INIT_LIST_HEAD(&fnic->vlans);
    } else {
        shost_printk(KERN_INFO, fnic->lport->host,
                 "firmware uses non-FIP mode\n");

The attempts to make fnic_fip_queue a single instance for the driver
while it's being created in probe look awkward anyway, why is this not
created in fnic_init_module like the event workqueue?

Signed-off-by: Chris Leech <cleech@redhat.com>
Tested-by: Anantha Tungarakodi <atungara@cisco.com>
Acked-by: Hiral Patel <hiralpat@cisco.com>
Signed-off-by: James Bottomley <JBottomley@Parallels.com>
[SCSI] Don't attempt to send extended INQUIRY command if skip_vpd_pages is set

If a device has the skip_vpd_pages flag set we should simply fail the
scsi_get_vpd_page() call.

Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Acked-by: Alan Stern <stern@rowland.harvard.edu>
Tested-by: Stuart Foster <smf.linux@ntlworld.com>
Cc: stable@vger.kernel.org
Signed-off-by: James Bottomley <JBottomley@Parallels.com>
Merge tag 'scsi-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi

Pull SCSI fixes from James Bottomley:
 "This is three bug fixes: An fnic warning caused by sleeping under a
  lock, a major regression with our updated WRITE SAME/UNMAP logic which
  caused tons of USB devices (and one RAID card) to cease to function
  and a megaraid_sas firmware initialisation problem which causes kdump
  failures"

* tag 'scsi-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi:
  [SCSI] Don't attempt to send extended INQUIRY command if skip_vpd_pages is set
  [SCSI] fnic: BUG: sleeping function called from invalid context during probe
  [SCSI] megaraid_sas: megaraid_sas driver init fails in kdump kernel
Linux 3.11-rc5
Merge branch 'core-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip

Pull w/w mutex deadlock injection fix from Ingo Molnar.

This bug made the CONFIG_DEBUG_WW_MUTEX_SLOWPATH=y option largely
useless, but wouldn't affect normal users.

* 'core-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
  mutex: Fix w/w mutex deadlock injection