The second argument of fc_lport_error() may be a valid frame pointer.
Hence only print it as an error code if it really is an error code.

Debug statements must end in a newline. Add one where it is missing.
Signed-off-by: NBart Van Assche <bvanassche@acm.org>
Cc: Neil Horman <nhorman@tuxdriver.com>
Signed-off-by: NRobert Love <robert.w.love@intel.com>

Change 'initiaive' into 'initiative', 'remainig' into 'remaining'
and change 'exected' into 'expected'.
Signed-off-by: NBart Van Assche <bvanassche@acm.org>
Signed-off-by: NRobert Love <robert.w.love@intel.com>

the return codes from fcoe_rcv should be NET_RX_*, not 0 or -1.
Signed-off-by: NNeil Horman <nhorman@tuxdriver.com>
Signed-off-by: NRobert Love <robert.w.love@intel.com>

Based on my last patch I noticed that fcoe_rcv has a simmilar problem, in that
it manipulates the passed in skb without checking to see if it has other users.
Making manipulations to a shared skb can result in various corruptions.

Easy fix, just make sure the skb is unshared prior to doing anything with it.
Signed-off-by: NNeil Horman <nhorman@tuxdriver.com>
Signed-off-by: NRobert Love <robert.w.love@intel.com>

Recently had this Oops reported to me on the 3.10 kernel:

[  807.554955] BUG: unable to handle kernel NULL pointer dereference at 0000000000000008
[  807.562799] IP: [<ffffffff814e6fc7>] skb_dequeue+0x47/0x70
[  807.568296] PGD 20c889067 PUD 20c8b8067 PMD 0
[  807.572769] Oops: 0002 [#1] SMP
[  807.655597] Hardware name: Dell Inc. PowerEdge R415/0DDT2D, BIOS 1.8.6 12/06/2011
[  807.663079] Workqueue: events fcoe_ctlr_recv_work [libfcoe]
[  807.668656] task: ffff88020b42a160 ti: ffff88020ae6c000 task.ti: ffff88020ae6c000
[  807.676126] RIP: 0010:[<ffffffff814e6fc7>]  [<ffffffff814e6fc7>] skb_dequeue+0x47/0x70
[  807.684046] RSP: 0000:ffff88020ae6dd70  EFLAGS: 00010097
[  807.689349] RAX: 0000000000000246 RBX: ffff8801d04d6700 RCX: 0000000000000000
[  807.696474] RDX: 0000000000000000 RSI: 0000000000000246 RDI: ffff88020df26434
[  807.703598] RBP: ffff88020ae6dd88 R08: 00000000000173e0 R09: ffff880216e173e0
[  807.710723] R10: ffffffff814e5897 R11: ffffea0007413580 R12: ffff88020df26420
[  807.717847] R13: ffff88020df26434 R14: 0000000000000004 R15: ffff8801d04c42ce
[  807.724972] FS:  00007fdaab6048c0(0000) GS:ffff880216e00000(0000) knlGS:0000000000000000
[  807.733049] CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b
[  807.738785] CR2: 0000000000000008 CR3: 000000020cbc9000 CR4: 00000000000006f0
[  807.745910] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[  807.753033] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
[  807.760156] Stack:
[  807.762162]  ffff8801d04d6700 0000000000000001 ffff88020df26400 ffff88020ae6de20
[  807.769586]  ffffffffa0444409 ffff88020b046a00 ffff88020ae6dde8 ffffffff810105be
[  807.777008]  ffff88020b42a868 0000000000000000 ffff88020df264a8 ffff88020df26348
[  807.784431] Call Trace:
[  807.786885]  [<ffffffffa0444409>] fcoe_ctlr_recv_work+0x59/0x9a0 [libfcoe]
[  807.793755]  [<ffffffff810105be>] ? __switch_to+0x13e/0x4a0
[  807.799324]  [<ffffffff8107d0e6>] process_one_work+0x176/0x420
[  807.805151]  [<ffffffff8107dd0b>] worker_thread+0x11b/0x3a0
[  807.810717]  [<ffffffff8107dbf0>] ? rescuer_thread+0x350/0x350
[  807.816545]  [<ffffffff810842b0>] kthread+0xc0/0xd0
[  807.821416]  [<ffffffff810841f0>] ? insert_kthread_work+0x40/0x40
[  807.827503]  [<ffffffff8160ce2c>] ret_from_fork+0x7c/0xb0
[  807.832897]  [<ffffffff810841f0>] ? insert_kthread_work+0x40/0x40
[  807.858500] RIP  [<ffffffff814e6fc7>] skb_dequeue+0x47/0x70
[  807.864076]  RSP <ffff88020ae6dd70>
[  807.867558] CR2: 0000000000000008

Looks like the root cause is the fact that the packet recieve function
fcoe_ctlr_recv enqueues the skb to a sk_buff_head_list prior to ensuring that
the skb is unshared.  This can happen when multiple packet listeners recieve an
skb, as the deliver_skb function just increments skb->users for each handler.
As a result, having multiple users of a single skb results in multiple
manipulators of its methods, implying list corruption, and the oops recorded
above.

The fix is pretty easy, just make sure that we clone the skb if its got multiple
users with the skb_share_check function, like other protocols do.
Signed-off-by: NNeil Horman <nhorman@tuxdriver.com>
Signed-off-by: NRobert Love <robert.w.love@intel.com>

The IO command size is 128 bytes for these new controllers as opposed to 64
for the old 8001 controller.

The Adaptec out-of-tree driver did this correctly. After comparing the two
this turned out to be the crucial difference.

So don't hardcode the IO command size, instead use pm8001_ha->iomb_size as
that is the correct value for both old and new controllers.
Signed-off-by: NHans Verkuil <hans.verkuil@cisco.com>
Acked-by: NAnand Kumar Santhanam <AnandKumar.Santhanam@pmcs.com>
Acked-by: NJack Wang <xjtuwjp@gmail.com>
Cc: stable@vger.kernel.org      # for v3.10 and up
Signed-off-by: NJames Bottomley <JBottomley@Parallels.com>

We want ppc64 to be able to select between optimised assembly
checksum routines in big endian and the generic lib/checksum.c
routines in little endian.

The lpfc driver is forcing CONFIG_GENERIC_CSUM on which means
we are unable to make the decision to enable it in the arch
Kconfig. If the option exists it is always forced on.

This got introduced in 3.10 via commit 6a7252fd ([SCSI] lpfc:
fix up Kconfig dependencies). I spoke to Randy about it and
the original issue was with CRC_T10DIF not being defined.

As such, remove the select of CONFIG_GENERIC_CSUM.
Signed-off-by: NAnton Blanchard <anton@samba.org>
Cc: <stable@vger.kernel.org> # 3.10
Signed-off-by: NJames Bottomley <JBottomley@Parallels.com>

If a device has the skip_vpd_pages flag set we should simply fail the
scsi_get_vpd_page() call.
Signed-off-by: NMartin K. Petersen <martin.petersen@oracle.com>
Acked-by: NAlan Stern <stern@rowland.harvard.edu>
Tested-by: NStuart Foster <smf.linux@ntlworld.com>
Cc: stable@vger.kernel.org
Signed-off-by: NJames Bottomley <JBottomley@Parallels.com>

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"
(d3c995f1)

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: NChris Leech <cleech@redhat.com>
Tested-by: NAnantha Tungarakodi <atungara@cisco.com>
Acked-by: NHiral Patel <hiralpat@cisco.com>
Signed-off-by: NJames Bottomley <JBottomley@Parallels.com>

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: NSumit Saxena <sumit.saxena@lsi.com>
Signed-off-by: NKashyap Desai <kashyap.desai@lsi.com>
Cc: stable@vger.kernel.org
Signed-off-by: NJames Bottomley <JBottomley@Parallels.com>

vscsi->num_queues counts the number of request virtqueue which does not
include the control and event virtqueue. It is wrong to subtract
VIRTIO_SCSI_VQ_BASE from vscsi->num_queues.

This patch fixes the following panic.

(qemu) device_del scsi0

 BUG: unable to handle kernel NULL pointer dereference at 0000000000000020
 IP: [<ffffffff8179b29f>] __virtscsi_set_affinity+0x6f/0x120
 PGD 0
 Oops: 0000 [#1] SMP
 Modules linked in:
 CPU: 0 PID: 659 Comm: kworker/0:1 Not tainted 3.11.0-rc2+ #1172
 Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011
 Workqueue: kacpi_hotplug _handle_hotplug_event_func
 task: ffff88007bee1cc0 ti: ffff88007bfe4000 task.ti: ffff88007bfe4000
 RIP: 0010:[<ffffffff8179b29f>]  [<ffffffff8179b29f>] __virtscsi_set_affinity+0x6f/0x120
 RSP: 0018:ffff88007bfe5a38  EFLAGS: 00010202
 RAX: 0000000000000010 RBX: ffff880077fd0d28 RCX: 0000000000000050
 RDX: 0000000000000000 RSI: 0000000000000246 RDI: 0000000000000000
 RBP: ffff88007bfe5a58 R08: ffff880077f6ff00 R09: 0000000000000001
 R10: ffffffff8143e673 R11: 0000000000000001 R12: 0000000000000001
 R13: ffff880077fd0800 R14: 0000000000000000 R15: ffff88007bf489b0
 FS:  0000000000000000(0000) GS:ffff88007ea00000(0000) knlGS:0000000000000000
 CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b
 CR2: 0000000000000020 CR3: 0000000079f8b000 CR4: 00000000000006f0
 Stack:
  ffff880077fd0d28 0000000000000000 ffff880077fd0800 0000000000000008
  ffff88007bfe5a78 ffffffff8179b37d ffff88007bccc800 ffff88007bccc800
  ffff88007bfe5a98 ffffffff8179b3b6 ffff88007bccc800 ffff880077fd0d28
 Call Trace:
  [<ffffffff8179b37d>] virtscsi_set_affinity+0x2d/0x40
  [<ffffffff8179b3b6>] virtscsi_remove_vqs+0x26/0x50
  [<ffffffff8179c7d2>] virtscsi_remove+0x82/0xa0
  [<ffffffff814cb6b2>] virtio_dev_remove+0x22/0x70
  [<ffffffff8167ca49>] __device_release_driver+0x69/0xd0
  [<ffffffff8167cb9d>] device_release_driver+0x2d/0x40
  [<ffffffff8167bb96>] bus_remove_device+0x116/0x150
  [<ffffffff81679936>] device_del+0x126/0x1e0
  [<ffffffff81679a06>] device_unregister+0x16/0x30
  [<ffffffff814cb889>] unregister_virtio_device+0x19/0x30
  [<ffffffff814cdad6>] virtio_pci_remove+0x36/0x80
  [<ffffffff81464ae7>] pci_device_remove+0x37/0x70
  [<ffffffff8167ca49>] __device_release_driver+0x69/0xd0
  [<ffffffff8167cb9d>] device_release_driver+0x2d/0x40
  [<ffffffff8167bb96>] bus_remove_device+0x116/0x150
  [<ffffffff81679936>] device_del+0x126/0x1e0
  [<ffffffff8145edfc>] pci_stop_bus_device+0x9c/0xb0
  [<ffffffff8145f036>] pci_stop_and_remove_bus_device+0x16/0x30
  [<ffffffff81474a9e>] acpiphp_disable_slot+0x8e/0x150
  [<ffffffff81474f6a>] hotplug_event_func+0xba/0x1a0
  [<ffffffff814906c8>] ? acpi_os_release_object+0xe/0x12
  [<ffffffff81475911>] _handle_hotplug_event_func+0x31/0x70
  [<ffffffff810b5333>] process_one_work+0x183/0x500
  [<ffffffff810b66e2>] worker_thread+0x122/0x400
  [<ffffffff810b65c0>] ? manage_workers+0x2d0/0x2d0
  [<ffffffff810bc5de>] kthread+0xce/0xe0
  [<ffffffff810bc510>] ? kthread_freezable_should_stop+0x70/0x70
  [<ffffffff81ca045c>] ret_from_fork+0x7c/0xb0
  [<ffffffff810bc510>] ? kthread_freezable_should_stop+0x70/0x70
 Code: 01 00 00 00 74 59 45 31 e4 83 bb c8 01 00 00 02 74 46 66 2e 0f 1f 84 00 00 00 00 00 49 63 c4 48 c1 e0 04 48 8b bc 0
3 10 02 00 00 <48> 8b 47 20 48 8b 80 d0 01 00 00 48 8b 40 50 48 85 c0 74 07 be
 RIP  [<ffffffff8179b29f>] __virtscsi_set_affinity+0x6f/0x120
  RSP <ffff88007bfe5a38>
 CR2: 0000000000000020
 ---[ end trace 99679331a3775f48 ]---

CC: stable@vger.kernel.org
Signed-off-by: NAsias He <asias@redhat.com>
Reviewed-by: NWanlong Gao <gaowanlong@cn.fujitsu.com>
Signed-off-by: NRusty Russell <rusty@rustcorp.com.au>

Oops, apparently no-one I cc'd at intel actually bothered to check this
patch for the isci driver:

commit e73823f7
Author: James Bottomley <JBottomley@Parallels.com>
Date:   Tue May 7 15:38:18 2013 -0700

    [SCSI] libsas: implement > 16 byte CDB support

sci_swab32_cpy needs multiples of four, so for commands that aren't that, it's
rounding the wrong way.  fix by doing (len+3)/4 instead of len/4.
Reported-by: NTony Luck <tony.luck@intel.com>
Tested-by: NTony Luck <tony.luck@intel.com>
Signed-off-by: NJames Bottomley <JBottomley@Parallels.com>

slot->response is a 64 bit quantity (and accessed as such), but its alignment
is only 32 bits.  This doesn't cause a problem on x86, but apparently causes a
kernel panic on Tile:

Stack dump complete Kernel panic - not syncing:
 Kernel unalign fault running the idle task!
 Starting stack dump of tid 0, pid 0 (swapper) on cpu 1 at cycle 341586172541
   frame 0: 0xfffffff700140ee0 dump_stack+0x0/0x20 (sp 0xfffffe43ffedf420)
   frame 1: 0xfffffff700283270 panic+0x150/0x3a0 (sp 0xfffffe43ffedf420)
   frame 2: 0xfffffff70012bff8 jit_bundle_gen+0xfd8/0x27e0 (sp 0xfffffe43ffedf4c8)
   frame 3: 0xfffffff7003b5b68 do_unaligned+0xc0/0x5a0 (sp 0xfffffe43ffedf710)
   frame 4: 0xfffffff70044ca78 handle_interrupt+0x270/0x278 (sp 0xfffffe43ffedf840)
   <interrupt 17 while in kernel mode>
   frame 5: 0xfffffff7002ac370 mvs_slot_complete+0x5f0/0x12a0 (sp 0xfffffe43ffedfa90)
   frame 6: 0xfffffff7002abec0 mvs_slot_complete+0x140/0x12a0 (sp 0xfffffe43ffedfa90)
   frame 7: 0xfffffff7005cc840 mvs_int_rx+0x140/0x2a0 (sp 0xfffffe43ffedfb00)
   frame 8: 0xfffffff7005bbaf0 mvs_94xx_isr+0xd8/0x2b8 (sp 0xfffffe43ffedfb68)
   frame 9: 0xfffffff700658ba0 mvs_tasklet+0x128/0x1f8 (sp 0xfffffe43ffedfba8)
   frame 10: 0xfffffff7003e8230 tasklet_action+0x178/0x2c8 (sp 0xfffffe43ffedfbe0)
   frame 11: 0xfffffff700103850 __do_softirq+0x210/0x398 (sp 0xfffffe43ffedfc40)
   frame 12: 0xfffffff700180308 do_softirq+0xc8/0x140 (sp 0xfffffe43ffedfcd8)
   frame 13: 0xfffffff7000bd7f0 irq_exit+0xb0/0x158 (sp 0xfffffe43ffedfcf0)
   frame 14: 0xfffffff70013fa58 tile_dev_intr+0x1d8/0x2f0 (sp 0xfffffe43ffedfd00)
   frame 15: 0xfffffff70044ca78 handle_interrupt+0x270/0x278 (sp 0xfffffe43ffedfd40)
   <interrupt 30 while in kernel mode>
   frame 16: 0xfffffff700143e68 _cpu_idle_nap+0x0/0x18 (sp 0xfffffe43ffedffb0)
   frame 17: 0xfffffff700482480 cpu_idle+0x310/0x428 (sp 0xfffffe43ffedffb0)

Since the check is just for non-zero, split it to be two 32 bit accesses
(preserving speed in the fast path) and do a get_unaligned() in the slow path.

This is a modification of a wholly get_unaligned patch submitted by Paul Guo
Reported-by: NPaul Guo <ggang@tilera.com>
Signed-off-by: NJames Bottomley <JBottomley@Parallels.com>

sd_prep_fn will allocate a larger CDB for the command via mempool_alloc
for devices using DIF type 2 protection.  This CDB was being freed
in sd_done, which results in a kernel crash if the command is retried
due to a UNIT ATTENTION.  This change moves the code to free the larger
CDB into sd_unprep_fn instead, which is invoked after the request is
complete.

It is no longer necessary to call scsi_print_command separately for
this case as the ->cmnd will no longer be NULL in the normal code path.

Also removed conditional test for DIF type 2 when freeing the larger
CDB because the protection_type could have been changed via sysfs while
the command was executing.
Signed-off-by: NEwan D. Milne <emilne@redhat.com>
Acked-by: NMartin K. Petersen <martin.petersen@oracle.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: NJames Bottomley <JBottomley@Parallels.com>

This fixes a regression where Xyratex controllers and disks were lost by the
driver:

https://bugzilla.kernel.org/show_bug.cgi?id=59601Reported-by: NJack Hill <jackhill@jackhill.us>
Signed-off-by: NSaurav Kashyap <saurav.kashyap@qlogic.com>
Signed-off-by: NGiridhar Malavali <giridhar.malavali@qlogic.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: NJames Bottomley <JBottomley@Parallels.com>

This commit fixes a race condition in the isci driver abort task and SSP
device task management path.  The race is caused when an I/O termination
in the SCU hardware is necessary because of an SSP target timeout condition,
and the check of the I/O end state races against the HW-termination-driven
end state.  The failure of the race meant that no TMF was sent to the device
to clean-up the pending I/O.
Signed-off-by: NJeff Skirvin <jeffrey.d.skirvin@intel.com>
Reviewed-by: NLukasz Dorau <lukasz.dorau@intel.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: NJames Bottomley <JBottomley@Parallels.com>

It has been several years since the SCSI constants.c
file has been updated. The attached is against lk 3.10
and brings the command strings, sense keys and additional
sense code strings into sync with spc4r36g.pdf.

Certain SCSI command names that previously only took the
opcode (i.e. byte 0 of the cdb) into account, have been
split into several command names using the associated
service action field to differentiate. For example,
persistent reservations that previously had 2 commands
(i.e. "in" and "out") have been expanded to 12 commands
(e.g. "Persistent reserve in, read reservation").

Sync SCSI command names, sense key strings and additional
sense code strings with SPC-4 draft revision 36g

[jejb: whitespace fix]
Signed-off-by: NDouglas Gilbert <dgilbert@interlog.com>
Signed-off-by: NJames Bottomley <JBottomley@Parallels.com>

Declare local variables and functions 'static'. This patch does not
change any functionality.
Signed-off-by: NBart Van Assche <bvanassche@acm.org>
Signed-off-by: NRobert Love <robert.w.love@intel.com>

When repeatedly doing rmmod and modprobe on the ixgbe
driver while FCoE is active in a VN2VN configuration,
memory leaks would be discovered by kmemleak with the
following backtrace:

unreferenced object 0xffff88003d076000 (size 1024):
  comm "kworker/0:3", pid 2998, jiffies 4295436448 (age 1015.332s)
  hex dump (first 32 bytes):
    48 8a fe 6f 00 88 ff ff 00 00 00 00 00 00 00 00  H..o............
    01 00 00 00 02 00 00 00 7b ac 87 21 1b 00 00 10  ........{..!....
  backtrace:
    [<ffffffff814b308b>] kmemleak_alloc+0x5b/0xc0
    [<ffffffff8115c6e8>] __kmalloc+0xd8/0x1b0
    [<ffffffffa0216638>] fc_rport_create+0x48/0x1f0 [libfc]
    [<ffffffffa023cd86>] fcoe_ctlr_vn_add.isra.10+0x56/0x1a0 [libfcoe]
    [<ffffffffa023f440>] fcoe_ctlr_vn_recv+0x8b0/0xab0 [libfcoe]
    [<ffffffffa023fb06>] fcoe_ctlr_recv_work+0x4c6/0xf60 [libfcoe]
    [<ffffffff81067404>] process_one_work+0x1e4/0x4d0
    [<ffffffff81068def>] worker_thread+0x10f/0x380
    [<ffffffff8107019a>] kthread+0xea/0xf0
    [<ffffffff814d32ec>] ret_from_fork+0x7c/0xb0
    [<ffffffffffffffff>] 0xffffffffffffffff

This patch stops the leak of the fc_rport_priv structure.
Signed-off-by: NMark Rustad <mark.d.rustad@intel.com>
Tested-by: NJack Morgan <jack.morgan@intel.com>
Signed-off-by: NRobert Love <robert.w.love@intel.com>

ctlr_dev was initialized to NULL, and never re-assigned. This
caused the log statement to always report failure. This patch
removes the unused variable and fixes the log statement to always
report 'success', as that is what should be logged if the code
reaches this point.
Signed-off-by: NRobert Love <robert.w.love@intel.com>
Tested-by: NJack Morgan <jack.morgan@intel.com>
Acked-by: NNeil Horman <nhorman@tuxdriver.com>

There are two debug statements with the same output string regarding
echange timer cancellation. This patch simply changes the output of
one string so that they can be differentiated.
Signed-off-by: NRobert Love <robert.w.love@intel.com>
Tested-by: NJack Morgan <jack.morgan@intel.com>
Acked-by: NNeil Horman <nhorman@tuxdriver.com>

Simply remove an extra space that violates coding style.
Signed-off-by: NRobert Love <robert.w.love@intel.com>
Tested-by: NJack Morgan <jack.morgan@intel.com>
Acked-by: NNeil Horman <nhorman@tuxdriver.com>

Both fcoe_fc_els_lesb and fc_els_lesb are in __be32 already, and both are
exactly the same size in bytes, with somewhat different member names to
reflect the fact the former is for Ethernet media the latter is for Fiber
Channel, so, remove conversion and use __be32 directly. This fixes the warning
from sparse check.
Signed-off-by: NYi Zou <yi.zou@intel.com>
Reported-by: NFengguang Wu <fengguang.wu@intel.com>
Tested-by: NJack Morgan <jack.morgan@intel.com>
Signed-off-by: NRobert Love <robert.w.love@intel.com>

do_device_access() is a function that abstracts copying SG list from/to
ramdisk storage (fake_storep).

It must deal with the ranges exceeding actual fake_storep size, because
such ranges are valid if virtual_gb is set greater than zero, and they
should be treated as fake_storep is repeatedly mirrored up to virtual
size.

Unfortunately, it can't deal with the range which wraps around the end of
fake_storep.  A wrap around range is copied by two
sg_copy_{from,to}_buffer() calls, but sg_copy_{from,to}_buffer() can't
copy from/to in the middle of SG list, therefore the second call can't
copy correctly.

This fixes it by using sg_pcopy_{from,to}_buffer() that can copy from/to
the middle of SG list.

This also simplifies the assignment of sdb->resid in
fill_from_dev_buffer().  Because fill_from_dev_buffer() is now only called
once per command execution cycle.  So it is not necessary to take care to
decrease sdb->resid if fill_from_dev_buffer() is called more than once.
Signed-off-by: NAkinobu Mita <akinobu.mita@gmail.com>
Cc: "David S. Miller" <davem@davemloft.net>
Cc: "James E.J. Bottomley" <JBottomley@parallels.com>
Cc: Douglas Gilbert <dgilbert@interlog.com>
Cc: Herbert Xu <herbert@gondor.apana.org.au>
Cc: Horia Geanta <horia.geanta@freescale.com>
Cc: Imre Deak <imre.deak@intel.com>
Cc: Tejun Heo <tj@kernel.org>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

This patch fixes a smatch warning as below:

smatch warnings:
drivers/scsi/fcoe/fcoe.c:782 fcoe_fdmi_info() warn: 'fdmi' puts 896 bytes on
stack
Reported-by: NFengguang Wu <fengguang.wu@intel.com>
Signed-off-by: NNeerav Parikh <Neerav.Parikh@intel.com>
Tested-by: NJack Morgan <jack.morgan@intel.com>
Signed-off-by: NRobert Love <robert.w.love@intel.com>

Reject a PLOGI from a node with an incompatible role,
that is, initiator-to-initiator or target-to-target.
Signed-off-by: NMark Rustad <mark.d.rustad@intel.com>
Reviewed-by: NYi Zou <yi.zou@intel.com>
Tested-by: NJack Morgan <jack.morgan@intel.com>
Signed-off-by: NRobert Love <robert.w.love@intel.com>

If something goes wrong during LUN scanning, e.g. a transport layer
failure occurs, then __scsi_remove_device() can get invoked by the
LUN scanning code for a SCSI device in state SDEV_CREATED_BLOCK and
before the SCSI device has been added to sysfs (is_visible == 0).
Make sure that even in this case the transition into state SDEV_DEL
occurs. This avoids that __scsi_remove_device() can get invoked a
second time by scsi_forget_host() if this last function is invoked
from another thread than the thread that performs LUN scanning.
Signed-off-by: NBart Van Assche <bvanassche@acm.org>
Signed-off-by: NJames Bottomley <JBottomley@Parallels.com>

scsi_run_queue() examines all SCSI devices that are present on
the starved list. Since scsi_run_queue() unlocks the SCSI host
lock a SCSI device can get removed after it has been removed
from the starved list and before its queue is run. Protect
against that race condition by holding a reference on the
queue while running it.
Reported-by: NChanho Min <chanho.min@lge.com>
Reviewed-by: NBart Van Assche <bvanassche@acm.org>
Signed-off-by: NJames Bottomley <JBottomley@Parallels.com>

On 64 bit then -1UL and -1U are not equal, so these conditions don't
work as intended and it breaks error handling.
Signed-off-by: NDan Carpenter <dan.carpenter@oracle.com>
Acked-by: NSumit Saxena <sumit.saxena@lsi.com>
Signed-off-by: NJames Bottomley <JBottomley@Parallels.com>

In order to reduce code duplication between prot_verify_read() and
prot_verify_write(), this moves common code into the new functions.

[jejb: fix unitialised variable warning]
Signed-off-by: NAkinobu Mita <akinobu.mita@gmail.com>
Acked-by: NDouglas Gilbert <dgilbert@interlog.com>
Acked-by: N"Martin K. Petersen" <martin.petersen@oracle.com>
Signed-off-by: NJames Bottomley <JBottomley@Parallels.com>

dif_storep is declared as pointer to unsigned char type.  But it is
actually used to store vmalloced array of struct sd_dif_tuple.

This changes the type of dif_storep to the pointer to struct sd_dif_tuple.
It simplifies offset calculation for dif_storep and enables to remove
hardcoded size of struct sd_dif_tuple.
Signed-off-by: NAkinobu Mita <akinobu.mita@gmail.com>
Acked-by: NDouglas Gilbert <dgilbert@interlog.com>
Acked-by: N"Martin K. Petersen" <martin.petersen@oracle.com>
Signed-off-by: NJames Bottomley <JBottomley@Parallels.com>

When UNMAP command is issued with the data integrity support enabled,
the protection info for the unmapped region is remain unchanged.
So READ command for the region later on causes data integrity failure.

This fixes it by invalidating protection info for the unmapped region
by filling with 0xff pattern.
Signed-off-by: NAkinobu Mita <akinobu.mita@gmail.com>
Acked-by: NDouglas Gilbert <dgilbert@interlog.com>
Acked-by: N"Martin K. Petersen" <martin.petersen@oracle.com>
Signed-off-by: NJames Bottomley <JBottomley@Parallels.com>

The protection info dif_storep is allocated only when parameter dif is
not zero.  But it will be accessed when reading or writing to the storage
installed with parameter dix is not zero.

So kernel crashes if scsi_debug module is loaded with parameters dix=1 and
dif=0.

This fixes it by making dif_storep available if parameter dix is not zero
instead of checking if parameter dif is not zero.
Signed-off-by: NAkinobu Mita <akinobu.mita@gmail.com>
Acked-by: NDouglas Gilbert <dgilbert@interlog.com>
Acked-by: N"Martin K. Petersen" <martin.petersen@oracle.com>
Signed-off-by: NJames Bottomley <JBottomley@Parallels.com>

In the function prot_verify_write(), kmap_atomic()/kunmap_atomic() for
data page and kmap_atomic()/kunmap_atomic() for protection information
page are not nested each other.

It worked perfectly before commit 3e4d3af5
("mm: stack based kmap_atomic()").  Because the kmap_atomic slot KM_IRQ0
was used for data page and the slot KM_IRQ1 was used for protection page.

But KM_types are gone and kmap_atomic() is using stack based implementation.
So two different kmap_atomic() usages must be strictly nested now.

This change ensures kmap_atomic() usage is strictly nested.
Signed-off-by: NAkinobu Mita <akinobu.mita@gmail.com>
Acked-by: NDouglas Gilbert <dgilbert@interlog.com>
Acked-by: N"Martin K. Petersen" <martin.petersen@oracle.com>
Signed-off-by: NJames Bottomley <JBottomley@Parallels.com>

In the function prot_verify_write(), the kmap address 'daddr' is
incremented in the loop for each data page.  Finally 'daddr' reaches
the next page boundary in the end of the loop, and the invalid address
is passed to kunmap_atomic().

Fix the issue by not incrementing 'daddr' in the loop and offsetting it
by the loop counter on demand.
Signed-off-by: NAkinobu Mita <akinobu.mita@gmail.com>
Acked-by: NDouglas Gilbert <dgilbert@interlog.com>
Acked-by: N"Martin K. Petersen" <martin.petersen@oracle.com>
Signed-off-by: NJames Bottomley <JBottomley@Parallels.com>

Bump driver version to v02.100.00.00.
Signed-off-by: NSreekanth Reddy <Sreekanth.Reddy@lsi.com>
Signed-off-by: NJames Bottomley <JBottomley@Parallels.com>

[SCSI] mpt3sas: when async scanning is enabled then while scanning, devices are removed but their transport layer entries are not removed

When Async scanning mode is enabled and device scanning is in progress,
devices should not be removed. But in actuality, devices are removed but
their transport layer entries are not removed. This causes error to add
the same device to the transport layer after host reset or diagnostic
reset.

So, in this patch, modified the code in such a way that device is not removed
when Async scanning mode is enabled and device scanning is in progress.
Signed-off-by: NSreekanth Reddy <Sreekanth.Reddy@lsi.com>
Signed-off-by: NJames Bottomley <JBottomley@Parallels.com>

Change set in MPI v2.5 Rev F(v2.5.1.1) specification and 2.00.29 header files

1. Added a bit to the IOCExceptions field of the IOCFacts Reply to indicate
   that the IOC detected a partial memory failure.
2. Added ElapsedSeconds field to RAID Volume Indicator Structure. Added
   Elapsed Seconds Valid flag to Flags field of this structure.
3. Added ElapsedSeconds field to Integrated RAID Operations Status Event Data.
4. Added two new AbortType values for TargetModeAbort Request, one to abort
   all I/Os from a single initiator, and the other to abort only Command IUs.
5. Added a new chapter covering DMA Flags and Multicast Modes.
6. In the IOCSettings field of BIOS Page 1, modified the Adapter Support bits
   description to specify X86 BIOS.
7. Marked bit 0 of the ControlFlags field of SAS IO Unit Page 1 as
   obsolete. This was the Clear SATA Affiliation flag.
8. Added additional requirements for certain IOCs that support more than eight
   MSI-x vectors.
Signed-off-by: NSreekanth Reddy <Sreekanth.Reddy@lsi.com>
Signed-off-by: NJames Bottomley <JBottomley@Parallels.com>

Infinite loop can occur if IOCStatus is not equal to
MPI2_IOCSTATUS_CONFIG_INVALID_PAGE value in the while loops in functions
_scsih_search_responding_sas_devices,
_scsih_search_responding_raid_devices and
_scsih_search_responding_expanders

So, Instead of checking for MPI2_IOCSTATUS_CONFIG_INVALID_PAGE value,
in this patch code is modified to check for IOCStatus not equals to
MPI2_IOCSTATUS_SUCCESS to break the while loop.
Signed-off-by: NSreekanth Reddy <Sreekanth.Reddy@lsi.com>
Cc: stable@vger.kernel.org
Signed-off-by: NJames Bottomley <JBottomley@Parallels.com>

[SCSI] mpt3sas: fix for kernel panic when driver loads with HBA conected to non LUN 0 configured expander

With some enclosures when LUN 0 is not created but LUN 1 or LUN X is created
then SCSI scan procedure calls target_alloc, slave_alloc call back functions
for LUN 0 and slave_destory() for same LUN 0.

In these kind of cases within slave_destroy, pointer to scsi_target in
_sas_device structure is set to NULL, following which when slave_alloc for LUN
1 is called then starget would not be set properly for this LUN.  So,
scsi_target pointer pointing to NULL value would lead to a crash later in the
discovery procedure.

To solve this issue set the sas_device's scsi_target pointer to scsi_device's
scsi_target if it is NULL earlier in slave_alloc callback function.
Signed-off-by: NSreekanth Reddy <Sreekanth.Reddy@lsi.com>
Cc: stable@vger.kernel.org
Signed-off-by: NJames Bottomley <JBottomley@Parallels.com>