<feed xmlns='http://www.w3.org/2005/Atom'>
<title>linux/drivers/scsi, branch v3.14.8</title>
<subtitle>Linux kernel source tree</subtitle>
<id>https://git.amat.us/linux/atom/drivers/scsi?h=v3.14.8</id>
<link rel='self' href='https://git.amat.us/linux/atom/drivers/scsi?h=v3.14.8'/>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/'/>
<updated>2014-06-11T18:54:09Z</updated>
<entry>
<title>SCSI: scsi_transport_sas: move bsg destructor into sas_rphy_remove</title>
<updated>2014-06-11T18:54:09Z</updated>
<author>
<name>Joe Lawrence</name>
<email>joe.lawrence@stratus.com</email>
</author>
<published>2014-05-22T21:30:54Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=1530eb587a3a426e1351da4f6012d2be21b536b7'/>
<id>urn:sha1:1530eb587a3a426e1351da4f6012d2be21b536b7</id>
<content type='text'>
commit 6aa6caff30f5dcb9e55b03b9710c30b83750cae5 upstream.

The recent change in sysfs, bcdde7e221a8750f9b62b6d0bd31b72ea4ad9309
"sysfs: make __sysfs_remove_dir() recursive" revealed an asymmetric
rphy device creation/deletion sequence in scsi_transport_sas:

  modprobe mpt2sas
    sas_rphy_add
      device_add A               rphy-&gt;dev
      device_add B               sas_device transport class
      device_add C               sas_end_device transport class
      device_add D               bsg class

  rmmod mpt2sas
    sas_rphy_delete
      sas_rphy_remove
        device_del B
        device_del C
        device_del A
          sysfs_remove_group     recursive sysfs dir removal
      sas_rphy_free
        device_del D             warning

  where device A is the parent of B, C, and D.

When sas_rphy_free tries to unregister the bsg request queue (device D
above), the ensuing sysfs cleanup discovers that its sysfs group has
already been removed and emits a warning, "sysfs group... not found for
kobject 'end_device-X:0'".

Since bsg creation is a side effect of sas_rphy_add, move its
complementary removal call into sas_rphy_remove. This imposes the
following tear-down order for the devices above: D, B, C, A.

Note the sas_device and sas_end_device transport class devices (B and C
above) are created and destroyed both via the list match traversal in
attribute_container_device_trigger, so the order in which they are
handled is fixed. This is fine as long as they are deleted before their
parent device.

Signed-off-by: Joe Lawrence &lt;joe.lawrence@stratus.com&gt;
Acked-by: Dan Williams &lt;dan.j.williams@intel.com&gt;
Signed-off-by: James Bottomley &lt;JBottomley@Parallels.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>SCSI: megaraid: missing bounds check in mimd_to_kioc()</title>
<updated>2014-05-31T20:20:27Z</updated>
<author>
<name>Dan Carpenter</name>
<email>dan.carpenter@oracle.com</email>
</author>
<published>2013-10-30T17:13:51Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=aa726923293e27cf9d3ee572d4a674c3818911e4'/>
<id>urn:sha1:aa726923293e27cf9d3ee572d4a674c3818911e4</id>
<content type='text'>
commit 3de2260140417759c669d391613d583baf03b0cf upstream.

pthru32-&gt;dataxferlen comes from the user so we need to check that it's
not too large so we don't overflow the buffer.

Reported-by: Nico Golde &lt;nico@ngolde.de&gt;
Reported-by: Fabian Yamaguchi &lt;fabs@goesec.de&gt;
Signed-off-by: Dan Carpenter &lt;dan.carpenter@oracle.com&gt;
Acked-by: Sumit Saxena &lt;sumit.saxena@lsi.com&gt;
Signed-off-by: James Bottomley &lt;JBottomley@Parallels.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>SCSI: dual scan thread bug fix</title>
<updated>2014-05-31T20:20:27Z</updated>
<author>
<name>James Bottomley</name>
<email>JBottomley@Parallels.com</email>
</author>
<published>2014-01-21T15:01:41Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=50b9f5b92eeee5b1ec5495d0ba1645f900855a1b'/>
<id>urn:sha1:50b9f5b92eeee5b1ec5495d0ba1645f900855a1b</id>
<content type='text'>
commit f2495e228fce9f9cec84367547813cbb0d6db15a upstream.

In the highly unusual case where two threads are running concurrently through
the scanning code scanning the same target, we run into the situation where
one may allocate the target while the other is still using it.  In this case,
because the reap checks for STARGET_CREATED and kills the target without
reference counting, the second thread will do the wrong thing on reap.

Fix this by reference counting even creates and doing the STARGET_CREATED
check in the final put.

Tested-by: Sarah Sharp &lt;sarah.a.sharp@linux.intel.com&gt;
Signed-off-by: James Bottomley &lt;JBottomley@Parallels.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>scsi: fix our current target reap infrastructure</title>
<updated>2014-05-31T20:20:27Z</updated>
<author>
<name>James Bottomley</name>
<email>JBottomley@Parallels.com</email>
</author>
<published>2014-01-21T15:00:50Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=bf1802de75b7e3aab950efde9efb61637e4f449f'/>
<id>urn:sha1:bf1802de75b7e3aab950efde9efb61637e4f449f</id>
<content type='text'>
commit e63ed0d7a98014fdfc2cfeb3f6dada313dcabb59 upstream.

This patch eliminates the reap_ref and replaces it with a proper kref.
On last put of this kref, the target is removed from visibility in
sysfs.  The final call to scsi_target_reap() for the device is done from
__scsi_remove_device() and only if the device was made visible.  This
ensures that the target disappears as soon as the last device is gone
rather than waiting until final release of the device (which is often
too long).

Reviewed-by: Alan Stern &lt;stern@rowland.harvard.edu&gt;
Tested-by: Sarah Sharp &lt;sarah.a.sharp@linux.intel.com&gt;
Signed-off-by: James Bottomley &lt;JBottomley@Parallels.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>mpt2sas: Don't disable device twice at suspend.</title>
<updated>2014-05-13T11:32:49Z</updated>
<author>
<name>Tyler Stachecki</name>
<email>tstache1@binghamton.edu</email>
</author>
<published>2014-04-25T20:41:04Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=c6f694696b0e50fc5a3ea99f42f02fe090cb00da'/>
<id>urn:sha1:c6f694696b0e50fc5a3ea99f42f02fe090cb00da</id>
<content type='text'>
commit af61e27c3f77c7623b5335590ae24b6a5c323e22 upstream.

On suspend, _scsih_suspend calls mpt2sas_base_free_resources, which
in turn calls pci_disable_device if the device is enabled prior to
suspending. However, _scsih_suspend also calls pci_disable_device
itself.

Thus, in the event that the device is enabled prior to suspending,
pci_disable_device will be called twice. This patch removes the
duplicate call to pci_disable_device in _scsi_suspend as it is both
unnecessary and results in a kernel oops.

Signed-off-by: Tyler Stachecki &lt;tstache1@binghamton.edu&gt;
Signed-off-by: James Bottomley &lt;JBottomley@Parallels.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>virtio-scsi: Skip setting affinity on uninitialized vq</title>
<updated>2014-05-13T11:32:48Z</updated>
<author>
<name>Fam Zheng</name>
<email>famz@redhat.com</email>
</author>
<published>2014-04-14T02:16:09Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=1849c68ea7b66667820473898f6a8056fb2eb176'/>
<id>urn:sha1:1849c68ea7b66667820473898f6a8056fb2eb176</id>
<content type='text'>
commit 0c8482ac92db5ac15792caf23b7f7df9e4f48ae1 upstream.

virtscsi_init calls virtscsi_remove_vqs on err, even before initializing
the vqs. The latter calls virtscsi_set_affinity, so let's check the
pointer there before setting affinity on it.

This fixes a panic when setting device's num_queues=2 on RHEL 6.5:

qemu-system-x86_64 ... \
-device virtio-scsi-pci,id=scsi0,addr=0x13,...,num_queues=2 \
-drive file=/stor/vm/dummy.raw,id=drive-scsi-disk,... \
-device scsi-hd,drive=drive-scsi-disk,...

[    0.354734] scsi0 : Virtio SCSI HBA
[    0.379504] BUG: unable to handle kernel NULL pointer dereference at 0000000000000020
[    0.380141] IP: [&lt;ffffffff814741ef&gt;] __virtscsi_set_affinity+0x4f/0x120
[    0.380141] PGD 0
[    0.380141] Oops: 0000 [#1] SMP
[    0.380141] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 3.14.0+ #5
[    0.380141] Hardware name: Red Hat KVM, BIOS 0.5.1 01/01/2007
[    0.380141] task: ffff88003c9f0000 ti: ffff88003c9f8000 task.ti: ffff88003c9f8000
[    0.380141] RIP: 0010:[&lt;ffffffff814741ef&gt;]  [&lt;ffffffff814741ef&gt;] __virtscsi_set_affinity+0x4f/0x120
[    0.380141] RSP: 0000:ffff88003c9f9c08  EFLAGS: 00010256
[    0.380141] RAX: 0000000000000000 RBX: ffff88003c3a9d40 RCX: 0000000000001070
[    0.380141] RDX: 0000000000000002 RSI: 0000000000000000 RDI: 0000000000000000
[    0.380141] RBP: ffff88003c9f9c28 R08: 00000000000136c0 R09: ffff88003c801c00
[    0.380141] R10: ffffffff81475229 R11: 0000000000000008 R12: 0000000000000000
[    0.380141] R13: ffffffff81cc7ca8 R14: ffff88003cac3d40 R15: ffff88003cac37a0
[    0.380141] FS:  0000000000000000(0000) GS:ffff88003e400000(0000) knlGS:0000000000000000
[    0.380141] CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b
[    0.380141] CR2: 0000000000000020 CR3: 0000000001c0e000 CR4: 00000000000006f0
[    0.380141] Stack:
[    0.380141]  ffff88003c3a9d40 0000000000000000 ffff88003cac3d80 ffff88003cac3d40
[    0.380141]  ffff88003c9f9c48 ffffffff814742e8 ffff88003c26d000 ffff88003c26d000
[    0.380141]  ffff88003c9f9c68 ffffffff81474321 ffff88003c26d000 ffff88003c3a9d40
[    0.380141] Call Trace:
[    0.380141]  [&lt;ffffffff814742e8&gt;] virtscsi_set_affinity+0x28/0x40
[    0.380141]  [&lt;ffffffff81474321&gt;] virtscsi_remove_vqs+0x21/0x50
[    0.380141]  [&lt;ffffffff81475231&gt;] virtscsi_init+0x91/0x240
[    0.380141]  [&lt;ffffffff81365290&gt;] ? vp_get+0x50/0x70
[    0.380141]  [&lt;ffffffff81475544&gt;] virtscsi_probe+0xf4/0x280
[    0.380141]  [&lt;ffffffff81363ea5&gt;] virtio_dev_probe+0xe5/0x140
[    0.380141]  [&lt;ffffffff8144c669&gt;] driver_probe_device+0x89/0x230
[    0.380141]  [&lt;ffffffff8144c8ab&gt;] __driver_attach+0x9b/0xa0
[    0.380141]  [&lt;ffffffff8144c810&gt;] ? driver_probe_device+0x230/0x230
[    0.380141]  [&lt;ffffffff8144c810&gt;] ? driver_probe_device+0x230/0x230
[    0.380141]  [&lt;ffffffff8144ac1c&gt;] bus_for_each_dev+0x8c/0xb0
[    0.380141]  [&lt;ffffffff8144c499&gt;] driver_attach+0x19/0x20
[    0.380141]  [&lt;ffffffff8144bf28&gt;] bus_add_driver+0x198/0x220
[    0.380141]  [&lt;ffffffff8144ce9f&gt;] driver_register+0x5f/0xf0
[    0.380141]  [&lt;ffffffff81d27c91&gt;] ? spi_transport_init+0x79/0x79
[    0.380141]  [&lt;ffffffff8136403b&gt;] register_virtio_driver+0x1b/0x30
[    0.380141]  [&lt;ffffffff81d27d19&gt;] init+0x88/0xd6
[    0.380141]  [&lt;ffffffff81d27c18&gt;] ? scsi_init_procfs+0x5b/0x5b
[    0.380141]  [&lt;ffffffff81ce88a7&gt;] do_one_initcall+0x7f/0x10a
[    0.380141]  [&lt;ffffffff81ce8aa7&gt;] kernel_init_freeable+0x14a/0x1de
[    0.380141]  [&lt;ffffffff81ce8b3b&gt;] ? kernel_init_freeable+0x1de/0x1de
[    0.380141]  [&lt;ffffffff817dec20&gt;] ? rest_init+0x80/0x80
[    0.380141]  [&lt;ffffffff817dec29&gt;] kernel_init+0x9/0xf0
[    0.380141]  [&lt;ffffffff817e68fc&gt;] ret_from_fork+0x7c/0xb0
[    0.380141]  [&lt;ffffffff817dec20&gt;] ? rest_init+0x80/0x80
[    0.380141] RIP  [&lt;ffffffff814741ef&gt;] __virtscsi_set_affinity+0x4f/0x120
[    0.380141]  RSP &lt;ffff88003c9f9c08&gt;
[    0.380141] CR2: 0000000000000020
[    0.380141] ---[ end trace 8074b70c3d5e1d73 ]---
[    0.475018] Kernel panic - not syncing: Attempted to kill init! exitcode=0x00000009
[    0.475018]
[    0.475068] Kernel Offset: 0x0 from 0xffffffff81000000 (relocation range: 0xffffffff80000000-0xffffffff9fffffff)
[    0.475068] ---[ end Kernel panic - not syncing: Attempted to kill init! exitcode=0x00000009

[jejb: checkpatch fixes]
Signed-off-by: Fam Zheng &lt;famz@redhat.com&gt;
Acked-by: Paolo Bonzini &lt;pbonzini@redhat.com&gt;
Signed-off-by: James Bottomley &lt;JBottomley@Parallels.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>SCSI: arcmsr: upper 32 of dma address lost</title>
<updated>2014-05-06T14:59:29Z</updated>
<author>
<name>Dan Carpenter</name>
<email>dan.carpenter@oracle.com</email>
</author>
<published>2014-02-11T16:06:33Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=60babe4b2093420c4a29162b1614671b65dc1949'/>
<id>urn:sha1:60babe4b2093420c4a29162b1614671b65dc1949</id>
<content type='text'>
commit e2c70425f05219b142b3a8a9489a622c736db39d upstream.

The original code always set the upper 32 bits to zero because it was
doing a shift of the wrong variable.

Fixes: 1a4f550a09f8 ('[SCSI] arcmsr: 1.20.00.15: add SATA RAID plus other fixes')
Signed-off-by: Dan Carpenter &lt;dan.carpenter@oracle.com&gt;
Signed-off-by: James Bottomley &lt;JBottomley@Parallels.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>SCSI: qla2xxx: fix error handling of qla2x00_mem_alloc()</title>
<updated>2014-05-06T14:59:29Z</updated>
<author>
<name>Dan Carpenter</name>
<email>dan.carpenter@oracle.com</email>
</author>
<published>2014-01-21T07:00:10Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=b5c0bf598c7ce3f45fe670be00e873228746a727'/>
<id>urn:sha1:b5c0bf598c7ce3f45fe670be00e873228746a727</id>
<content type='text'>
commit b2a72ec32d0f499aaadf41264232517a12326df0 upstream.

qla2x00_mem_alloc() returns 1 on success and -ENOMEM on failure.  On the
one hand the caller assumes non-zero is success but on the other hand
the caller also assumes that it returns an error code.

I've fixed it to return zero on success and a negative error code on
failure.  This matches the documentation as well.

[jejb: checkpatch fix]
Fixes: e315cd28b9ef ('[SCSI] qla2xxx: Code changes for qla data structure refactoring')
Signed-off-by: Dan Carpenter &lt;dan.carpenter@oracle.com&gt;
Acked-by: Saurav Kashyap &lt;saurav.kashyap@qlogic.com&gt;
Signed-off-by: James Bottomley &lt;JBottomley@Parallels.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>SCSI: sd: don't fail if the device doesn't recognize SYNCHRONIZE CACHE</title>
<updated>2014-04-27T00:19:04Z</updated>
<author>
<name>Alan Stern</name>
<email>stern@rowland.harvard.edu</email>
</author>
<published>2014-01-15T20:37:04Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=0561b77b0f366aa168fa23aa07b606f5f49638c8'/>
<id>urn:sha1:0561b77b0f366aa168fa23aa07b606f5f49638c8</id>
<content type='text'>
commit 7aae51347b21eb738dc1981df1365b57a6c5ee4e upstream.

Evidently some wacky USB-ATA bridges don't recognize the SYNCHRONIZE
CACHE command, as shown in this email thread:

	http://marc.info/?t=138978356200002&amp;r=1&amp;w=2

The fact that we can't tell them to drain their caches shouldn't
prevent the system from going into suspend.  Therefore sd_sync_cache()
shouldn't return an error if the device replies with an Invalid
Command ASC.

Signed-off-by: Alan Stern &lt;stern@rowland.harvard.edu&gt;
Reported-by: Sven Neumann &lt;s.neumann@raumfeld.com&gt;
Tested-by: Daniel Mack &lt;zonque@gmail.com&gt;
Signed-off-by: James Bottomley &lt;JBottomley@Parallels.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net</title>
<updated>2014-03-25T00:07:24Z</updated>
<author>
<name>Linus Torvalds</name>
<email>torvalds@linux-foundation.org</email>
</author>
<published>2014-03-25T00:07:24Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=8a1094462c7ec47f9d3a31b0a281ce35cb138f50'/>
<id>urn:sha1:8a1094462c7ec47f9d3a31b0a281ce35cb138f50</id>
<content type='text'>
Pull networking fixes from David Miller:

 1) OpenVswitch's lookup_datapath() returns error pointers, so don't
    check against NULL.  From Jiri Pirko.

 2) pfkey_compile_policy() code path tries to do a GFP_KERNEL allocation
    under RCU locks, fix by using GFP_ATOMIC when necessary.  From
    Nikolay Aleksandrov.

 3) phy_suspend() indirectly passes uninitialized data into the ethtool
    get wake-on-land implementations.  Fix from Sebastian Hesselbarth.

 4) CPSW driver unregisters CPTS twice, fix from Benedikt Spranger.

 5) If SKB allocation of reply packet fails, vxlan's arp_reduce() defers
    a NULL pointer.  Fix from David Stevens.

 6) IPV6 neigh handling in vxlan doesn't validate the destination
    address properly, and it builds a packet with the src and dst
    reversed.  Fix also from David Stevens.

 7) Fix spinlock recursion during subscription failures in TIPC stack,
    from Erik Hugne.

 8) Revert buggy conversion of davinci_emac to devm_request_irq, from
    Chrstian Riesch.

 9) Wrong flags passed into forwarding database netlink notifications,
    from Nicolas Dichtel.

10) The netpoll neighbour soliciation handler checks wrong ethertype,
    needs to be ETH_P_IPV6 rather than ETH_P_ARP.  Fix from Li RongQing.

* git://git.kernel.org/pub/scm/linux/kernel/git/davem/net: (34 commits)
  tipc: fix spinlock recursion bug for failed subscriptions
  vxlan: fix nonfunctional neigh_reduce()
  net: davinci_emac: Fix rollback of emac_dev_open()
  net: davinci_emac: Replace devm_request_irq with request_irq
  netpoll: fix the skb check in pkt_is_ns
  net: micrel : ks8851-ml: add vdd-supply support
  ip6mr: fix mfc notification flags
  ipmr: fix mfc notification flags
  rtnetlink: fix fdb notification flags
  tcp: syncookies: do not use getnstimeofday()
  netlink: fix setsockopt in mmap examples in documentation
  openvswitch: Correctly report flow used times for first 5 minutes after boot.
  via-rhine: Disable device in error path
  ATHEROS-ATL1E: Convert iounmap to pci_iounmap
  vxlan: fix potential NULL dereference in arp_reduce()
  cnic: Update version to 2.5.20 and copyright year.
  cnic,bnx2i,bnx2fc: Fix inconsistent use of page size
  cnic: Use proper ulp_ops for per device operations.
  net: cdc_ncm: fix control message ordering
  ipv6: ip6_append_data_mtu do not handle the mtu of the second fragment properly
  ...
</content>
</entry>
</feed>
