linux/drivers, branch v3.10.34

PNP / ACPI: proper handling of ACPI IO/Memory resource parsing failures

2014-03-24T04:38:22Z

commit 89935315f192abf7068d0044cefc84f162c3c81f upstream. Before commit b355cee88e3b (ACPI / resources: ignore invalid ACPI device resources), if acpi_dev_resource_memory()/acpi_dev_resource_io() returns false, it means the the resource is not a memeory/IO resource. But after commit b355cee88e3b, those functions return false if the given memory/IO resource entry is invalid (the length of the resource is zero). This breaks pnpacpi_allocated_resource(), because it now recognizes the invalid memory/io resources as resources of unknown type. Thus users see confusing warning messages on machines with zero length ACPI memory/IO resources. Fix the problem by rearranging pnpacpi_allocated_resource() so that it calls acpi_dev_resource_memory() for memory type and IO type resources only, respectively. Fixes: b355cee88e3b (ACPI / resources: ignore invalid ACPI device resources) Signed-off-by: Zhang Rui Reported-and-tested-by: Markus Trippelsdorf Reported-and-tested-by: Julian Wollrath Reported-and-tested-by: Paul Bolle [rjw: Changelog] Signed-off-by: Rafael J. Wysocki Signed-off-by: Greg Kroah-Hartman

iser-target: Fix post_send_buf_count for RDMA READ/WRITE

2014-03-24T04:38:22Z

commit b6b87a1df604678ed1be40158080db012a99ccca upstream. This patch fixes the incorrect setting of ->post_send_buf_count related to RDMA WRITEs + READs where isert_rdma_rw->send_wr_num was not being taken into account. This includes incrementing ->post_send_buf_count within isert_put_datain() + isert_get_dataout(), decrementing within __isert_send_completion() + isert_response_completion(), and clearing wr->send_wr_num within isert_completion_rdma_read() This is necessary because even though IB_SEND_SIGNALED is not set for RDMA WRITEs + READs, during a QP failure event the work requests will be returned with exception status from the TX completion queue. Acked-by: Sagi Grimberg Cc: Or Gerlitz Signed-off-by: Nicholas Bellinger Signed-off-by: Greg Kroah-Hartman

iscsi/iser-target: Fix isert_conn->state hung shutdown issues

2014-03-24T04:38:21Z

commit defd884845297fd5690594bfe89656b01f16d87e upstream. This patch addresses a couple of different hug shutdown issues related to wait_event() + isert_conn->state. First, it changes isert_conn->conn_wait + isert_conn->conn_wait_comp_err from waitqueues to completions, and sets ISER_CONN_TERMINATING from within isert_disconnect_work(). Second, it splits isert_free_conn() into isert_wait_conn() that is called earlier in iscsit_close_connection() to ensure that all outstanding commands have completed before continuing. Finally, it breaks isert_cq_comp_err() into seperate TX / RX related code, and adds logic in isert_cq_rx_comp_err() to wait for outstanding commands to complete before setting ISER_CONN_DOWN and calling complete(&isert_conn->conn_wait_comp_err). Acked-by: Sagi Grimberg Cc: Or Gerlitz Signed-off-by: Nicholas Bellinger Signed-off-by: Greg Kroah-Hartman

iscsi/iser-target: Use list_del_init for ->i_conn_node

2014-03-24T04:38:21Z

commit 5159d763f60af693a3fcec45dce2021f66e528a4 upstream. There are a handful of uses of list_empty() for cmd->i_conn_node within iser-target code that expect to return false once a cmd has been removed from the per connect list. This patch changes all uses of list_del -> list_del_init in order to ensure that list_empty() returns false as expected. Acked-by: Sagi Grimberg Cc: Or Gerlitz Cc: #3.10+ Signed-off-by: Nicholas Bellinger Signed-off-by: Greg Kroah-Hartman

iwlwifi: mvm: don't WARN when statistics are handled late

2014-03-24T04:38:21Z

commit 1e9291996c4eedf79883f47ec635235e39d3d6cd upstream. Since the statistics handler is asynchrous, it can very well be that we will handle the statistics (hence the RSSI fluctuation) when we already disassociated. Don't WARN on this case. This solves: https://bugzilla.redhat.com/show_bug.cgi?id=1071998 Fixes: 2b76ef13086f ("iwlwifi: mvm: implement reduced Tx power") Reviewed-by: Johannes Berg Signed-off-by: Emmanuel Grumbach Signed-off-by: Greg Kroah-Hartman

s390/dasd: hold request queue sysfs lock when calling elevator_init()

2014-03-24T04:38:20Z

commit ef0899410ff630b2e75306da49996dbbfa318165 upstream. "elevator: Fix a race in elevator switching and md device initialization" changed the semantics of elevator_init() in a way that now enforces to hold the corresponding request queue's sysfs_lock when calling elevator_init() to fix a race. The patch did not convert the s390 dasd device driver which is the only device driver which also calls elevator_init(). So add the missing locking. Cc: Tomoki Sekiyama Cc: Jens Axboe Signed-off-by: Heiko Carstens Signed-off-by: Jens Axboe Cc: Christian Borntraeger Signed-off-by: Greg Kroah-Hartman

SCSI: storvsc: NULL pointer dereference fix

2014-03-24T04:38:19Z

commit b12bb60d6c350b348a4e1460cd68f97ccae9822e upstream. If the initialization of storvsc fails, the storvsc_device_destroy() causes NULL pointer dereference. storvsc_bus_scan() scsi_scan_target() __scsi_scan_target() scsi_probe_and_add_lun(hostdata=NULL) scsi_alloc_sdev(hostdata=NULL) sdev->hostdata = hostdata now the host allocation fails __scsi_remove_device(sdev) calls sdev->host->hostt->slave_destroy() == storvsc_device_destroy(sdev) access of sdev->hostdata->request_mempool Signed-off-by: Ales Novak Signed-off-by: Thomas Abraham Reviewed-by: Jiri Kosina Acked-by: K. Y. Srinivasan Signed-off-by: James Bottomley Signed-off-by: Greg Kroah-Hartman

SCSI: qla2xxx: Poll during initialization for ISP25xx and ISP83xx

2014-03-24T04:38:19Z

commit b77ed25c9f8402e8b3e49e220edb4ef09ecfbb53 upstream. Signed-off-by: Giridhar Malavali Signed-off-by: Saurav Kashyap Signed-off-by: James Bottomley Signed-off-by: Greg Kroah-Hartman

SCSI: isci: correct erroneous for_each_isci_host macro

2014-03-24T04:38:19Z

commit c59053a23d586675c25d789a7494adfdc02fba57 upstream. In the first place, the loop 'for' in the macro 'for_each_isci_host' (drivers/scsi/isci/host.h:314) is incorrect, because it accesses the 3rd element of 2 element array. After the 2nd iteration it executes the instruction: ihost = to_pci_info(pdev)->hosts[2] (while the size of the 'hosts' array equals 2) and reads an out of range element. In the second place, this loop is incorrectly optimized by GCC v4.8 (see http://marc.info/?l=linux-kernel&m=138998871911336&w=2). As a result, on platforms with two SCU controllers, the loop is executed more times than it can be (for i=0,1 and 2). It causes kernel panic during entering the S3 state and the following oops after 'rmmod isci': BUG: unable to handle kernel NULL pointer dereference at (null) IP: [] __list_add+0x1b/0xc0 Oops: 0000 [#1] SMP RIP: 0010:[] [] __list_add+0x1b/0xc0 Call Trace: [] __mutex_lock_slowpath+0x114/0x1b0 [] mutex_lock+0x1f/0x30 [] sas_disable_events+0x1b/0x50 [libsas] [] sas_unregister_ha+0x18/0x60 [libsas] [] isci_unregister+0x1e/0x40 [isci] [] isci_pci_remove+0x5d/0x100 [isci] [] pci_device_remove+0x3b/0xb0 [] __device_release_driver+0x7f/0xf0 [] driver_detach+0xa8/0xb0 [] bus_remove_driver+0x9b/0x120 [] driver_unregister+0x2c/0x50 [] pci_unregister_driver+0x23/0x80 [] isci_exit+0x10/0x1e [isci] [] SyS_delete_module+0x16b/0x2d0 [] ? do_notify_resume+0x61/0xa0 [] system_call_fastpath+0x16/0x1b The loop has been corrected. This patch fixes kernel panic during entering the S3 state and the above oops. Signed-off-by: Lukasz Dorau Reviewed-by: Maciej Patelczyk Tested-by: Lukasz Dorau Signed-off-by: Dan Williams Signed-off-by: James Bottomley Signed-off-by: Greg Kroah-Hartman

SCSI: isci: fix reset timeout handling

2014-03-24T04:38:19Z

commit ddfadd7736b677de2d4ca2cd5b4b655368c85a7a upstream. Remove an erroneous BUG_ON() in the case of a hard reset timeout. The reset timeout handler puts the port into the "awaiting link-up" state. The timeout causes the device to be disconnected and we need to be in the awaiting link-up state to re-connect the port. The BUG_ON() made the incorrect assumption that resets never timeout and we always complete the reset in the "resetting" state. Testing this patch also uncovered that libata continues to attempt to reset the port long after the driver has torn down the context. Once the driver has committed to abandoning the link it must indicate to libata that recovery ends by returning -ENODEV from ->lldd_I_T_nexus_reset(). Acked-by: Lukasz Dorau Reported-by: David Milburn Reported-by: Xun Ni Tested-by: Xun Ni Signed-off-by: Dan Williams Signed-off-by: James Bottomley Signed-off-by: Greg Kroah-Hartman