linux-toradex.git/drivers/scsi, branch v3.11.9 Linux kernel for Apalis and Colibri modules aacraid: missing capable() check in compat ioctl 2013-11-13T03:08:10+00:00 Dan Carpenter dan.carpenter@oracle.com 2013-10-29T19:11:06+00:00 2af344097ce82d1772d709229adcf02390c3f1b5 commit f856567b930dfcdbc3323261bf77240ccdde01f5 upstream. In commit d496f94d22d1 ('[SCSI] aacraid: fix security weakness') we added a check on CAP_SYS_RAWIO to the ioctl. The compat ioctls need the check as well. Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
commit f856567b930dfcdbc3323261bf77240ccdde01f5 upstream.

In commit d496f94d22d1 ('[SCSI] aacraid: fix security weakness') we
added a check on CAP_SYS_RAWIO to the ioctl.  The compat ioctls need the
check as well.

Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
SCSI: sd: call blk_pm_runtime_init before add_disk 2013-11-13T03:08:08+00:00 Aaron Lu aaron.lu@intel.com 2013-10-10T05:22:36+00:00 836a6eec8e00243f10b40b066673e572d690adf7 commit 10c580e4239df5c3344ca00322eca86ab2de880b upstream. Sujit has found a race condition that would make q->nr_pending unbalanced, it occurs as Sujit explained: " sd_probe_async() -> add_disk() -> disk_add_event() -> schedule(disk_events_workfn) sd_revalidate_disk() blk_pm_runtime_init() return; Let's say the disk_events_workfn() calls sd_check_events() which tries to send test_unit_ready() and because of sd_revalidate_disk() trying to send another commands the test_unit_ready() might be re-queued as the tagged command queuing is disabled. So the race condition is - Thread 1 | Thread 2 sd_revalidate_disk() | sd_check_events() ...nr_pending = 0 as q->dev = NULL| scsi_queue_insert() blk_runtime_pm_init() | blk_pm_requeue_request() -> | nr_pending = -1 since | q->dev != NULL " The problem is, the test_unit_ready request doesn't get counted the first time it is queued, so the later decrement of q->nr_pending in blk_pm_requeue_request makes it unbalanced. Fix this by calling blk_pm_runtime_init before add_disk so that all requests initiated there will all be counted. Signed-off-by: Aaron Lu <aaron.lu@intel.com> Reported-and-tested-by: Sujit Reddy Thumma <sthumma@codeaurora.org> Signed-off-by: James Bottomley <JBottomley@Parallels.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
commit 10c580e4239df5c3344ca00322eca86ab2de880b upstream.

Sujit has found a race condition that would make q->nr_pending
unbalanced, it occurs as Sujit explained:

"
sd_probe_async() ->
	add_disk() ->
		disk_add_event() ->
			schedule(disk_events_workfn)
	sd_revalidate_disk()
	blk_pm_runtime_init()
return;

Let's say the disk_events_workfn() calls sd_check_events() which tries
to send test_unit_ready() and because of sd_revalidate_disk() trying to
send another commands the test_unit_ready() might be re-queued as the
tagged command queuing is disabled.

So the race condition is -

Thread 1 			  |		Thread 2
sd_revalidate_disk()		  |	sd_check_events()
...nr_pending = 0 as q->dev = NULL|	scsi_queue_insert()
blk_runtime_pm_init()		  | 	blk_pm_requeue_request() ->
				  |	nr_pending = -1 since
				  |	q->dev != NULL
"

The problem is, the test_unit_ready request doesn't get counted the
first time it is queued, so the later decrement of q->nr_pending in
blk_pm_requeue_request makes it unbalanced.

Fix this by calling blk_pm_runtime_init before add_disk so that all
requests initiated there will all be counted.

Signed-off-by: Aaron Lu <aaron.lu@intel.com>
Reported-and-tested-by: Sujit Reddy Thumma <sthumma@codeaurora.org>
Signed-off-by: James Bottomley <JBottomley@Parallels.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
SCSI: BusLogic: Fix an oops when intializing multimaster adapter 2013-11-13T03:08:08+00:00 Khalid Aziz khalid.aziz@oracle.com 2013-09-25T17:45:11+00:00 e353d5ce7cc2c6636bde123869e43b3b007708f2 commit 6541932ea2f7de0b0c5203decf666b143ad5fa33 upstream. This fixes an oops caused by buslogic driver when initializing a BusLogic MultiMaster adapter. Initialization code used scope of a variable incorrectly which created a NULL pointer. Oops message is below: BUG: unable to handle kernel NULL pointer dereference at 0000000c IP: [<c150c137>] blogic_init_mm_probeinfo.isra.17+0x20a/0x583 *pde = 00000000 Oops: 002 [#1] PREEMPT SMP Modules linked in: CPU: 1 PID: 1 Comm: swapper/0 Not tainted 3.11.1.puz1 #1 Hardware name: /Canterwood, BIOS 6.00 PG 05/16/2003 task: f7050000 ti: f7054000 task.ti: f7054000 EIP: 0060:[<c150c137>] EFLAGS: 00010246 CPU:1 EIP is at blogic_init_mm_probeinfo.isra.17+0x20a/0x583 EAX: 00000013 EBX: 00000000 ECX: 00000000 EDX: f8001000 ESI: f71cb800 EDI: f7388000 EBP: 00007800 ESP: f7055c84 DS: 007b ES: 007b FS: 00d8 GS: 0000 SS: 0068 CR0: 8005003b CR2: 0000000c CR3: 0154f000 CR4: 000007d0 Stack: 0000001c 00000000 c11a59f6 f7055c98 00008130 ffffffff ffffffff 00000000 00000003 00000000 00000000 00000000 00000013 f8001000 00000001 000003d0 00000000 00000000 00000000 c14e3f84 f78803c8 00000000 f738c000 000000e9 Call Trace: [<c11a59f6>] ? pci_get_subsys+0x33/0x38 [<c150c4fb>] ? blogic_init_probeinfo_list+0x4b/0x19e [<c108d593>] ? __alloc_pages_nodemask+0xe3/0x623 [<c108d593>] ? __alloc_pages_nodemask+0xe3/0x623 [<c10fb99e>] ? sysfs_link_sibling+0x61/0x8d [<c10b0519>] ? kmem_cache_alloc+0x8b/0xb5 [<c150cce5>] ? blogic_init+0xa1/0x10e8 [<c10fc0a8>] ? sysfs_add_one+0x10/0x9d [<c10fc18a>] ? sysfs_addrm_finish+0x12/0x85 [<c10fca37>] ? sysfs_do_create_link_sd+0x9d/0x1b4 [<c117c272>] ? blk_register_queue+0x69/0xb3 [<c10fcb68>] ? sysfs_create_link+0x1a/0x2c [<c1181a07>] ? add_disk+0x1a1/0x3c7 [<c138737b>] ? klist_next+0x60/0xc3 [<c122cc3a>] ? scsi_dh_detach+0x68/0x68 [<c1213e36>] ? bus_for_each_dev+0x51/0x61 [<c1000356>] ? do_one_initcall+0x22/0x12c [<c10f3688>] ? __proc_create+0x8c/0xba [<c150cc44>] ? blogic_setup+0x5f6/0x5f6 [<c14e94aa>] ? repair_env_string+0xf/0x4d [<c14e949b>] ? do_early_param+0x71/0x71 [<c103efaa>] ? parse_args+0x21f/0x33d [<c14e9a54>] ? kernel_init_freeable+0xdf/0x17d [<c14e949b>] ? do_early_param+0x71/0x71 [<c1388b64>] ? kernel_init+0x8/0xc0 [<c1392222>] ? ret_from_kernel_thread+0x6/0x28 [<c1392227>] ? ret_from_kernel_thread+0x1b/0x28 [<c1388b5c>] ? rest_init+0x6c/0x6c Code: 89 44 24 10 0f b6 44 24 3d 89 44 24 0c c7 44 24 08 00 00 00 00 c7 44 24 04 38 62 46 c1 c7 04 24 02 00 00 00 e8 78 13 d2 ff 31 db <89> 6b 0c b0 20 89 ea ee c7 44 24 08 04 00 00 00 8d 44 24 4c 89 EIP: [<c150c137>] blogic_init_mm_probeinfo.isra.17+0x20a/0x583 SS:ESP 0068:f7055c84 CR2: 000000000000000c ---[ end trace 17f45f5196d40487 ]--- Kernel panic - not syncing: Attempted to kill init! exitcode=0x00000009 Signed-off-by: Khalid Aziz <khalid.aziz@oracle.com> Reported-by: Pierre Uszynski <pierre@rahul.net> Tested-by: Pierre Uszynski <pierre@rahul.net> Signed-off-by: James Bottomley <JBottomley@Parallels.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
commit 6541932ea2f7de0b0c5203decf666b143ad5fa33 upstream.

This fixes an oops caused by buslogic driver when initializing a BusLogic
MultiMaster adapter. Initialization code used scope of a variable
incorrectly which created a NULL pointer. Oops message is below:

BUG: unable to handle kernel NULL pointer dereference at 0000000c
IP: [<c150c137>] blogic_init_mm_probeinfo.isra.17+0x20a/0x583
*pde = 00000000
Oops: 002 [#1] PREEMPT SMP
Modules linked in:
CPU: 1 PID: 1 Comm: swapper/0 Not tainted 3.11.1.puz1 #1
Hardware name:    /Canterwood, BIOS 6.00 PG 05/16/2003
task: f7050000 ti: f7054000 task.ti: f7054000
EIP: 0060:[<c150c137>] EFLAGS: 00010246 CPU:1
EIP is at blogic_init_mm_probeinfo.isra.17+0x20a/0x583
EAX: 00000013 EBX: 00000000 ECX: 00000000 EDX: f8001000
ESI: f71cb800 EDI: f7388000 EBP: 00007800 ESP: f7055c84
 DS: 007b ES: 007b FS: 00d8 GS: 0000 SS: 0068
CR0: 8005003b CR2: 0000000c CR3: 0154f000 CR4: 000007d0
Stack:
 0000001c 00000000 c11a59f6 f7055c98 00008130 ffffffff ffffffff 00000000
 00000003 00000000 00000000 00000000 00000013 f8001000 00000001 000003d0
 00000000 00000000 00000000 c14e3f84 f78803c8 00000000 f738c000 000000e9
Call Trace:
 [<c11a59f6>] ? pci_get_subsys+0x33/0x38
 [<c150c4fb>] ? blogic_init_probeinfo_list+0x4b/0x19e
 [<c108d593>] ? __alloc_pages_nodemask+0xe3/0x623
 [<c108d593>] ? __alloc_pages_nodemask+0xe3/0x623
 [<c10fb99e>] ? sysfs_link_sibling+0x61/0x8d
 [<c10b0519>] ? kmem_cache_alloc+0x8b/0xb5
 [<c150cce5>] ? blogic_init+0xa1/0x10e8
 [<c10fc0a8>] ? sysfs_add_one+0x10/0x9d
 [<c10fc18a>] ? sysfs_addrm_finish+0x12/0x85
 [<c10fca37>] ? sysfs_do_create_link_sd+0x9d/0x1b4
 [<c117c272>] ? blk_register_queue+0x69/0xb3
 [<c10fcb68>] ? sysfs_create_link+0x1a/0x2c
 [<c1181a07>] ? add_disk+0x1a1/0x3c7
 [<c138737b>] ? klist_next+0x60/0xc3
 [<c122cc3a>] ? scsi_dh_detach+0x68/0x68
 [<c1213e36>] ? bus_for_each_dev+0x51/0x61
 [<c1000356>] ? do_one_initcall+0x22/0x12c
 [<c10f3688>] ? __proc_create+0x8c/0xba
 [<c150cc44>] ? blogic_setup+0x5f6/0x5f6
 [<c14e94aa>] ? repair_env_string+0xf/0x4d
 [<c14e949b>] ? do_early_param+0x71/0x71
 [<c103efaa>] ? parse_args+0x21f/0x33d
 [<c14e9a54>] ? kernel_init_freeable+0xdf/0x17d
 [<c14e949b>] ? do_early_param+0x71/0x71
 [<c1388b64>] ? kernel_init+0x8/0xc0
 [<c1392222>] ? ret_from_kernel_thread+0x6/0x28
 [<c1392227>] ? ret_from_kernel_thread+0x1b/0x28
 [<c1388b5c>] ? rest_init+0x6c/0x6c
Code: 89 44 24 10 0f b6 44 24 3d 89 44 24 0c c7 44 24 08 00 00 00 00 c7 44 24 04 38 62 46 c1 c7 04 24 02 00 00 00 e8 78 13 d2 ff 31 db <89> 6b 0c b0 20 89 ea ee
 c7 44 24 08 04 00 00 00 8d 44 24 4c 89
EIP: [<c150c137>] blogic_init_mm_probeinfo.isra.17+0x20a/0x583 SS:ESP 0068:f7055c84
CR2: 000000000000000c
---[ end trace 17f45f5196d40487 ]---
Kernel panic - not syncing: Attempted to kill init! exitcode=0x00000009

Signed-off-by: Khalid Aziz <khalid.aziz@oracle.com>
Reported-by: Pierre Uszynski <pierre@rahul.net>
Tested-by: Pierre Uszynski <pierre@rahul.net>
Signed-off-by: James Bottomley <JBottomley@Parallels.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
esp_scsi: Fix tag state corruption when autosensing. 2013-10-14T01:14:29+00:00 David S. Miller davem@davemloft.net 2013-08-02T01:08:34+00:00 7de5c6bba258f2d3390ed73c938a98f15440213b [ Upstream commit 21af8107f27878813d0364733c0b08813c2c192a ] Meelis Roos reports a crash in esp_free_lun_tag() in the presense of a disk which has died. The issue is that when we issue an autosense command, we do so by hijacking the original command that caused the check-condition. When we do so we clear out the ent->tag[] array when we issue it via find_and_prep_issuable_command(). This is so that the autosense command is forced to be issued non-tagged. That is problematic, because it is the value of ent->tag[] which determines whether we issued the original scsi command as tagged vs. non-tagged (see esp_alloc_lun_tag()). And that, in turn, is what trips up the sanity checks in esp_free_lun_tag(). That function needs the original ->tag[] values in order to free up the tag slot properly. Fix this by remembering the original command's tag values, and having esp_alloc_lun_tag() and esp_free_lun_tag() use them. Reported-by: Meelis Roos <mroos@linux.ee> Tested-by: Meelis Roos <mroos@linux.ee> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
[ Upstream commit 21af8107f27878813d0364733c0b08813c2c192a ]

Meelis Roos reports a crash in esp_free_lun_tag() in the presense
of a disk which has died.

The issue is that when we issue an autosense command, we do so by
hijacking the original command that caused the check-condition.

When we do so we clear out the ent->tag[] array when we issue it via
find_and_prep_issuable_command().  This is so that the autosense
command is forced to be issued non-tagged.

That is problematic, because it is the value of ent->tag[] which
determines whether we issued the original scsi command as tagged
vs. non-tagged (see esp_alloc_lun_tag()).

And that, in turn, is what trips up the sanity checks in
esp_free_lun_tag().  That function needs the original ->tag[] values
in order to free up the tag slot properly.

Fix this by remembering the original command's tag values, and
having esp_alloc_lun_tag() and esp_free_lun_tag() use them.

Reported-by: Meelis Roos <mroos@linux.ee>
Tested-by: Meelis Roos <mroos@linux.ee>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
SCSI: sd: Fix potential out-of-bounds access 2013-09-27T00:21:35+00:00 Alan Stern stern@rowland.harvard.edu 2013-09-06T15:49:51+00:00 9ed42ce59457ba8df30d345278f3c079ca61b595 commit 984f1733fcee3fbc78d47e26c5096921c5d9946a upstream. This patch fixes an out-of-bounds error in sd_read_cache_type(), found by Google's AddressSanitizer tool. When the loop ends, we know that "offset" lies beyond the end of the data in the buffer, so no Caching mode page was found. In theory it may be present, but the buffer size is limited to 512 bytes. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Reported-by: Dmitry Vyukov <dvyukov@google.com> Signed-off-by: James Bottomley <JBottomley@Parallels.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
commit 984f1733fcee3fbc78d47e26c5096921c5d9946a upstream.

This patch fixes an out-of-bounds error in sd_read_cache_type(), found
by Google's AddressSanitizer tool.  When the loop ends, we know that
"offset" lies beyond the end of the data in the buffer, so no Caching
mode page was found.  In theory it may be present, but the buffer size
is limited to 512 bytes.

Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Reported-by: Dmitry Vyukov <dvyukov@google.com>
Signed-off-by: James Bottomley <JBottomley@Parallels.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
SCSI: Allow MPT Fusion SAS 3.0 driver to be built into the kernel 2013-09-27T00:21:22+00:00 Greg Kroah-Hartman gregkh@linuxfoundation.org 2013-09-03T22:00:11+00:00 97bd47aaaeff070e7907a6a0be78329e8c783feb commit 9807b4d94911be4e4efb9a08481b24292a9edf8a upstream. Right now the Makefile for the mpt3sas driver does not even allow the driver to be built into the kernel. So fix that up, as there doesn't seem to be any obvious reason why this shouldn't be done. Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Acked-by: Sreekanth Reddy <Sreekanth.Reddy@lsi.com> Signed-off-by: James Bottomley <JBottomley@Parallels.com> 
commit 9807b4d94911be4e4efb9a08481b24292a9edf8a upstream.

Right now the Makefile for the mpt3sas driver does not even allow the
driver to be built into the kernel.  So fix that up, as there doesn't
seem to be any obvious reason why this shouldn't be done.

Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Acked-by: Sreekanth Reddy <Sreekanth.Reddy@lsi.com>
Signed-off-by: James Bottomley <JBottomley@Parallels.com>
[SCSI] pm80xx: fix Adaptec 71605H hang 2013-08-26T09:33:58+00:00 Hans Verkuil hverkuil@xs4all.nl 2013-07-26T16:43:45+00:00 9504a923924d663e1953f872f0a828e6454a6cfc 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: Hans Verkuil <hans.verkuil@cisco.com> Acked-by: Anand Kumar Santhanam <AnandKumar.Santhanam@pmcs.com> Acked-by: Jack Wang <xjtuwjp@gmail.com> Cc: stable@vger.kernel.org # for v3.10 and up Signed-off-by: James Bottomley <JBottomley@Parallels.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: Hans Verkuil <hans.verkuil@cisco.com>
Acked-by: Anand Kumar Santhanam <AnandKumar.Santhanam@pmcs.com>
Acked-by: Jack Wang <xjtuwjp@gmail.com>
Cc: stable@vger.kernel.org      # for v3.10 and up
Signed-off-by: James Bottomley <JBottomley@Parallels.com>
[SCSI] lpfc: Don't force CONFIG_GENERIC_CSUM on 2013-08-21T17:54:20+00:00 Anton Blanchard anton@samba.org 2013-08-08T07:47:34+00:00 f5944daa0a72316077435c18a6571e73ed338332 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 6a7252fdb0c3 ([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: Anton Blanchard <anton@samba.org> Cc: <stable@vger.kernel.org> # 3.10 Signed-off-by: James 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 6a7252fdb0c3 ([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: Anton Blanchard <anton@samba.org>
Cc: <stable@vger.kernel.org> # 3.10
Signed-off-by: James Bottomley <JBottomley@Parallels.com>
Merge tag 'scsi-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi 2013-08-11T23:32:26+00:00 Linus Torvalds torvalds@linux-foundation.org 2013-08-11T23:32:26+00:00 e5d081f4686f9c6be8ab3d34dfcdb0afdbbdeefd 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 
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
Merge tag 'fixes-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/rusty/linux 2013-08-08T16:32:20+00:00 Linus Torvalds torvalds@linux-foundation.org 2013-08-08T16:32:20+00:00 bb014db07ce04851f0e19ef5c0f15ad0021ec38c Pull virtio fixes from Rusty Russell: "More virtio console fixes than I'm happy with, but all real issues, and all CC:stable.." * tag 'fixes-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/rusty/linux: virtio-scsi: Fix virtqueue affinity setup virtio: console: return -ENODEV on all read operations after unplug virtio: console: fix raising SIGIO after port unplug virtio: console: clean up port data immediately at time of unplug virtio: console: fix race in port_fops_open() and port unplug virtio: console: fix race with port unplug and open/close virtio/console: Add pipe_lock/unlock for splice_write virtio/console: Quit from splice_write if pipe->nrbufs is 0 
Pull virtio fixes from Rusty Russell:
 "More virtio console fixes than I'm happy with, but all real issues,
  and all CC:stable.."

* tag 'fixes-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/rusty/linux:
  virtio-scsi: Fix virtqueue affinity setup
  virtio: console: return -ENODEV on all read operations after unplug
  virtio: console: fix raising SIGIO after port unplug
  virtio: console: clean up port data immediately at time of unplug
  virtio: console: fix race in port_fops_open() and port unplug
  virtio: console: fix race with port unplug and open/close
  virtio/console: Add pipe_lock/unlock for splice_write
  virtio/console: Quit from splice_write if pipe->nrbufs is 0