1. 02 Jun, 2014 1 commit
    • Nicholas Bellinger's avatar
      virtio-scsi: Enable DIF/DIX modes in SCSI host LLD · e6dc783a
      Nicholas Bellinger authored
      
      
      This patch updates virtscsi_probe() to setup necessary Scsi_Host
      level protection resources. (currently hardcoded to 1)
      
      It changes virtscsi_add_cmd() to attach outgoing / incoming
      protection SGLs preceeding the data payload, and is using the
      new virtio_scsi_cmd_req_pi->pi_bytes[out,in] field to signal
      to signal to vhost/scsi bytes to expect for protection data.
      
      (Add missing #include <linux/blkdev.h> for blk_integrity - sfr + nab)
      Acked-by: default avatarPaolo Bonzini <pbonzini@redhat.com>
      Cc: Michael S. Tsirkin <mst@redhat.com>
      Cc: Martin K. Petersen <martin.petersen@oracle.com>
      Cc: Christoph Hellwig <hch@lst.de>
      Cc: Hannes Reinecke <hare@suse.de>
      Cc: Sagi Grimberg <sagig@dev.mellanox.co.il>
      Cc: H. Peter Anvin <hpa@zytor.com>
      Signed-off-by: default avatarNicholas Bellinger <nab@linux-iscsi.org>
      e6dc783a
  2. 21 Apr, 2014 7 commits
  3. 13 Apr, 2014 1 commit
    • Mikulas Patocka's avatar
      sym53c8xx_2: Set DID_REQUEUE return code when aborting squeue · fd1232b2
      Mikulas Patocka authored
      
      
      This patch fixes I/O errors with the sym53c8xx_2 driver when the disk
      returns QUEUE FULL status.
      
      When the controller encounters an error (including QUEUE FULL or BUSY
      status), it aborts all not yet submitted requests in the function
      sym_dequeue_from_squeue.
      
      This function aborts them with DID_SOFT_ERROR.
      
      If the disk has full tag queue, the request that caused the overflow is
      aborted with QUEUE FULL status (and the scsi midlayer properly retries
      it until it is accepted by the disk), but the sym53c8xx_2 driver aborts
      the following requests with DID_SOFT_ERROR --- for them, the midlayer
      does just a few retries and then signals the error up to sd.
      
      The result is that disk returning QUEUE FULL causes request failures.
      
      The error was reproduced on 53c895 with COMPAQ BD03685A24 disk
      (rebranded ST336607LC) with command queue 48 or 64 tags.  The disk has
      64 tags, but under some access patterns it return QUEUE FULL when there
      are less than 64 pending tags.  The SCSI specification allows returning
      QUEUE FULL anytime and it is up to the host to retry.
      Signed-off-by: default avatarMikulas Patocka <mpatocka@redhat.com>
      Cc: Matthew Wilcox <matthew@wil.cx>
      Cc: James Bottomley <JBottomley@Parallels.com>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      fd1232b2
  4. 11 Apr, 2014 1 commit
    • David S. Miller's avatar
      net: Fix use after free by removing length arg from sk_data_ready callbacks. · 676d2369
      David S. Miller authored
      
      
      Several spots in the kernel perform a sequence like:
      
      	skb_queue_tail(&sk->s_receive_queue, skb);
      	sk->sk_data_ready(sk, skb->len);
      
      But at the moment we place the SKB onto the socket receive queue it
      can be consumed and freed up.  So this skb->len access is potentially
      to freed up memory.
      
      Furthermore, the skb->len can be modified by the consumer so it is
      possible that the value isn't accurate.
      
      And finally, no actual implementation of this callback actually uses
      the length argument.  And since nobody actually cared about it's
      value, lots of call sites pass arbitrary values in such as '0' and
      even '1'.
      
      So just remove the length argument from the callback, that way there
      is no confusion whatsoever and all of these use-after-free cases get
      fixed as a side effect.
      
      Based upon a patch by Eric Dumazet and his suggestion to audit this
      issue tree-wide.
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      676d2369
  5. 10 Apr, 2014 2 commits
    • Dan Williams's avatar
      scsi: async sd resume · 3c31b52f
      Dan Williams authored
      async_schedule() sd resume work to allow disks and other devices to
      resume in parallel.
      
      This moves the entirety of scsi_device resume to an async context to
      ensure that scsi_device_resume() remains ordered with respect to the
      completion of the start/stop command.  For the duration of the resume,
      new command submissions (that do not originate from the scsi-core) will
      be deferred (BLKPREP_DEFER).
      
      It adds a new ASYNC_DOMAIN_EXCLUSIVE(scsi_sd_pm_domain) as a container
      of these operations.  Like scsi_sd_probe_domain it is flushed at
      sd_remove() time to ensure async ops do not continue past the
      end-of-life of the sdev.  The implementation explicitly refrains from
      reusing scsi_sd_probe_domain directly for this purpose as it is flushed
      at the end of dpm_resume(), potentially defeating some of the benefit.
      Given sdevs are quiesced it is permissible for these resume operations
      to bleed past the async_synchronize_full() calls made by the driver
      core.
      
      We defer the resolution of which pm callback to call until
      scsi_dev_type_{suspend|resume} time and guarantee that the callback
      parameter is never NULL.  With this in place the type of resume
      operation is encoded in the async function identifier.
      
      There is a concern that async resume could trigger PSU overload.  In the
      enterprise, storage enclosures enforce staggered spin-up regardless of
      what the kernel does making async scanning safe by default.  Outside of
      that context a user can disable asynchronous scanning via a kernel
      command line or CONFIG_SCSI_SCAN_ASYNC.  Honor that setting when
      deciding whether to do resume asynchronously.
      
      Inspired by Todd's analysis and initial proposal [2]:
      https://01.org/suspendresume/blogs/tebrandt/2013/hard-disk-resume-optimization-simpler-approach
      
      
      
      Cc: Len Brown <len.brown@intel.com>
      Cc: Phillip Susi <psusi@ubuntu.com>
      [alan: bug fix and clean up suggestion]
      Acked-by: default avatarAlan Stern <stern@rowland.harvard.edu>
      Suggested-by: default avatarTodd Brandt <todd.e.brandt@linux.intel.com>
      [djbw: kick all resume work to the async queue]
      Signed-off-by: default avatarDan Williams <dan.j.williams@intel.com>
      3c31b52f
    • Martin K. Petersen's avatar
      scsi: Make sure cmd_flags are 64-bit · 2bfad21e
      Martin K. Petersen authored
      
      
      cmd_flags in struct request is now 64 bits wide but the scsi_execute
      functions truncated arguments passed to int leading to errors. Make sure
      the flags parameters are u64.
      Signed-off-by: default avatarMartin K. Petersen <martin.petersen@oracle.com>
      Cc: Jens Axboe <axboe@fb.com>
      CC: Jan Kara <jack@suse.cz>
      Cc: Frederic Weisbecker <fweisbec@gmail.com>
      Signed-off-by: default avatarJens Axboe <axboe@fb.com>
      2bfad21e
  6. 07 Apr, 2014 2 commits
    • Nicholas Bellinger's avatar
      target: Pass in transport supported PI at session initialization · e70beee7
      Nicholas Bellinger authored
      
      
      In order to support local WRITE_INSERT + READ_STRIP operations for
      non PI enabled fabrics, the fabric driver needs to be able signal
      what protection offload operations are supported.
      
      This is done at session initialization time so the modes can be
      signaled by individual se_wwn + se_portal_group endpoints, as well
      as optionally across different transports on the same endpoint.
      
      For iser-target, set TARGET_PROT_ALL if the underlying ib_device
      has already signaled PI offload support, and allow this to be
      exposed via a new iscsit_transport->iscsit_get_sup_prot_ops()
      callback.
      
      For loopback, set TARGET_PROT_ALL to signal SCSI initiator mode
      operation.
      
      For all other drivers, set TARGET_PROT_NORMAL to disable fabric
      level PI.
      
      Cc: Martin K. Petersen <martin.petersen@oracle.com>
      Cc: Sagi Grimberg <sagig@mellanox.com>
      Cc: Or Gerlitz <ogerlitz@mellanox.com>
      Cc: Quinn Tran <quinn.tran@qlogic.com>
      Cc: Giridhar Malavali <giridhar.malavali@qlogic.com>
      Signed-off-by: default avatarNicholas Bellinger <nab@linux-iscsi.org>
      e70beee7
    • Nicholas Bellinger's avatar
      target: Add TFO->abort_task for aborted task resources release · 131e6abc
      Nicholas Bellinger authored
      
      
      Now that TASK_ABORTED status is not generated for all cases by
      TMR ABORT_TASK + LUN_RESET, a new TFO->abort_task() caller is
      necessary in order to give fabric drivers a chance to unmap
      hardware / software resources before the se_cmd descriptor is
      released via the normal TFO->release_cmd() codepath.
      
      This patch adds TFO->aborted_task() in core_tmr_abort_task()
      in place of the original transport_send_task_abort(), and
      also updates all fabric drivers to implement this caller.
      
      The fabric drivers that include changes to perform cleanup
      via ->aborted_task() are:
      
        - iscsi-target
        - iser-target
        - srpt
        - tcm_qla2xxx
      
      The fabric drivers that currently set ->aborted_task() to
      NOPs are:
      
        - loopback
        - tcm_fc
        - usb-gadget
        - sbp-target
        - vhost-scsi
      
      For the latter five, there appears to be no additional cleanup
      required before invoking TFO->release_cmd() to release the
      se_cmd descriptor.
      
      v2 changes:
        - Move ->aborted_task() call into transport_cmd_finish_abort (Alex)
      
      Cc: Alex Leung <amleung21@yahoo.com>
      Cc: Mark Rustad <mark.d.rustad@intel.com>
      Cc: Roland Dreier <roland@kernel.org>
      Cc: Vu Pham <vu@mellanox.com>
      Cc: Chris Boot <bootc@bootc.net>
      Cc: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
      Cc: Michael S. Tsirkin <mst@redhat.com>
      Cc: Giridhar Malavali <giridhar.malavali@qlogic.com>
      Cc: Saurav Kashyap <saurav.kashyap@qlogic.com>
      Cc: Quinn Tran <quinn.tran@qlogic.com>
      Cc: Sagi Grimberg <sagig@mellanox.com>
      Cc: Or Gerlitz <ogerlitz@mellanox.com>
      Signed-off-by: default avatarNicholas Bellinger <nab@linux-iscsi.org>
      131e6abc
  7. 27 Mar, 2014 7 commits
  8. 24 Mar, 2014 1 commit
  9. 20 Mar, 2014 3 commits
    • Srivatsa S. Bhat's avatar
      scsi, fcoe: Fix CPU hotplug callback registration · cd45ae38
      Srivatsa S. Bhat authored
      
      
      Subsystems that want to register CPU hotplug callbacks, as well as perform
      initialization for the CPUs that are already online, often do it as shown
      below:
      
      	get_online_cpus();
      
      	for_each_online_cpu(cpu)
      		init_cpu(cpu);
      
      	register_cpu_notifier(&foobar_cpu_notifier);
      
      	put_online_cpus();
      
      This is wrong, since it is prone to ABBA deadlocks involving the
      cpu_add_remove_lock and the cpu_hotplug.lock (when running concurrently
      with CPU hotplug operations).
      
      Instead, the correct and race-free way of performing the callback
      registration is:
      
      	cpu_notifier_register_begin();
      
      	for_each_online_cpu(cpu)
      		init_cpu(cpu);
      
      	/* Note the use of the double underscored version of the API */
      	__register_cpu_notifier(&foobar_cpu_notifier);
      
      	cpu_notifier_register_done();
      
      Fix the fcoe code in scsi by using this latter form of callback registration.
      
      Cc: Robert Love <robert.w.love@intel.com>
      Cc: "James E.J. Bottomley" <JBottomley@parallels.com>
      Cc: Ingo Molnar <mingo@kernel.org>
      Signed-off-by: default avatarSrivatsa S. Bhat <srivatsa.bhat@linux.vnet.ibm.com>
      Signed-off-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      cd45ae38
    • Srivatsa S. Bhat's avatar
      scsi, bnx2fc: Fix CPU hotplug callback registration · 7229b6d0
      Srivatsa S. Bhat authored
      
      
      Subsystems that want to register CPU hotplug callbacks, as well as perform
      initialization for the CPUs that are already online, often do it as shown
      below:
      
      	get_online_cpus();
      
      	for_each_online_cpu(cpu)
      		init_cpu(cpu);
      
      	register_cpu_notifier(&foobar_cpu_notifier);
      
      	put_online_cpus();
      
      This is wrong, since it is prone to ABBA deadlocks involving the
      cpu_add_remove_lock and the cpu_hotplug.lock (when running concurrently
      with CPU hotplug operations).
      
      Instead, the correct and race-free way of performing the callback
      registration is:
      
      	cpu_notifier_register_begin();
      
      	for_each_online_cpu(cpu)
      		init_cpu(cpu);
      
      	/* Note the use of the double underscored version of the API */
      	__register_cpu_notifier(&foobar_cpu_notifier);
      
      	cpu_notifier_register_done();
      
      Fix the bnx2fc code in scsi by using this latter form of callback
      registration.
      
      Cc: Eddie Wai <eddie.wai@broadcom.com>
      Cc: "James E.J. Bottomley" <JBottomley@parallels.com>
      Cc: Ingo Molnar <mingo@kernel.org>
      Signed-off-by: default avatarSrivatsa S. Bhat <srivatsa.bhat@linux.vnet.ibm.com>
      Signed-off-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      7229b6d0
    • Srivatsa S. Bhat's avatar
      scsi, bnx2i: Fix CPU hotplug callback registration · bc0003c9
      Srivatsa S. Bhat authored
      
      
      Subsystems that want to register CPU hotplug callbacks, as well as perform
      initialization for the CPUs that are already online, often do it as shown
      below:
      
      	get_online_cpus();
      
      	for_each_online_cpu(cpu)
      		init_cpu(cpu);
      
      	register_cpu_notifier(&foobar_cpu_notifier);
      
      	put_online_cpus();
      
      This is wrong, since it is prone to ABBA deadlocks involving the
      cpu_add_remove_lock and the cpu_hotplug.lock (when running concurrently
      with CPU hotplug operations).
      
      Instead, the correct and race-free way of performing the callback
      registration is:
      
      	cpu_notifier_register_begin();
      
      	for_each_online_cpu(cpu)
      		init_cpu(cpu);
      
      	/* Note the use of the double underscored version of the API */
      	__register_cpu_notifier(&foobar_cpu_notifier);
      
      	cpu_notifier_register_done();
      
      Fix the bnx2i code in scsi by using this latter form of callback registration.
      
      Cc: Eddie Wai <eddie.wai@broadcom.com>
      Cc: "James E.J. Bottomley" <JBottomley@parallels.com>
      Cc: Ingo Molnar <mingo@kernel.org>
      Signed-off-by: default avatarSrivatsa S. Bhat <srivatsa.bhat@linux.vnet.ibm.com>
      Signed-off-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      bc0003c9
  10. 19 Mar, 2014 15 commits