kernel.git/drivers/scsi/aacraid, branch linux-4.13.y

scsi: aacraid: Fix controller initialization failure

2017-11-02T08:54:48Z

commit 45348de2c8a7a1e64c5be27b22c9786b4152dd41 upstream. This is a fix to an issue where the driver sends its periodic WELLNESS command to the controller after the driver shut it down.This causes the controller to crash. The window where this can happen is small, but it can be hit at around 4 hours of constant resets. Fixes: fbd185986eba (aacraid: Fix AIF triggered IOP_RESET) Signed-off-by: Raghava Aditya Renukunta Reviewed-by: Dave Carroll Signed-off-by: Martin K. Petersen Signed-off-by: Greg Kroah-Hartman

scsi: aacraid: Add a small delay after IOP reset

2017-10-05T07:47:27Z

commit d1b490939d8c117a06dfc562c41d933f71d30289 upstream. Commit 0e9973ed3382 ("scsi: aacraid: Add periodic checks to see IOP reset status") changed the way driver checks if a reset succeeded. Now, after an IOP reset, aacraid immediately start polling a register to verify the reset is complete. This behavior cause regressions on the reset path in PowerPC (at least). Since the delay after the IOP reset was removed by the aforementioned patch, the fact driver just starts to read a register instantly after the reset was issued (by writing in another register) "corrupts" the reset procedure, which ends up failing all the time. The issue highly impacted kdump on PowerPC, since on kdump path we proactively issue a reset in adapter (through the reset_devices kernel parameter). This patch (re-)adds a delay right after IOP reset is issued. Empirically we measured that 3 seconds is enough, but for safety reasons we delay for 5s (and since it was 30s before, 5s is still a small amount). For reference, without this patch we observe the following messages on kdump kernel boot process: [ 76.294] aacraid 0003:01:00.0: IOP reset failed [ 76.294] aacraid 0003:01:00.0: ARC Reset attempt failed [ 86.524] aacraid 0003:01:00.0: adapter kernel panic'd ff. [ 86.524] aacraid 0003:01:00.0: Controller reset type is 3 [ 86.524] aacraid 0003:01:00.0: Issuing IOP reset [146.534] aacraid 0003:01:00.0: IOP reset failed [146.534] aacraid 0003:01:00.0: ARC Reset attempt failed Fixes: 0e9973ed3382 ("scsi: aacraid: Add periodic checks to see IOP reset status") Signed-off-by: Guilherme G. Piccoli Acked-by: Dave Carroll Signed-off-by: Martin K. Petersen Signed-off-by: Greg Kroah-Hartman

scsi: aacraid: Fix 2T+ drives on SmartIOC-2000

2017-10-05T07:47:27Z

commit 6c92f7dbf25c36f35320e4ae0b508676410bac04 upstream. The logic for supporting large drives was previously tied to 4Kn support for SmartIOC-2000. As SmartIOC-2000 does not support volumes using 4Kn drives, use the intended option flag AAC_OPT_NEW_COMM_64 to determine support for volumes greater than 2T. Signed-off-by: Dave Carroll Reviewed-by: Christoph Hellwig Reviewed-by: Raghava Aditya Renukunta Signed-off-by: Martin K. Petersen Signed-off-by: Greg Kroah-Hartman

scsi: aacraid: Fix command send race condition

2017-09-27T12:43:17Z

commit 1ae948fa4f00f3a2823e7cb19a3049ef27dd6947 upstream. This fixes a potential race condition observed on Power systems. Several places throughout the aacraid driver call aac_fib_send or similar to send a command to the aacraid adapter, then check the return code to determine if the command was actually sent to the adapter, then update the phase field in the scsi command scratch pad area to track that the firmware now owns this command. However, there is nothing that ensures that by the time the aac_fib_send function returns and we go to write to the scsi command, that the command hasn't already completed and the scsi command has been freed. This was causing random crashes in the TCP stack which was tracked down to be caused by memory that had been a struct request + scsi_cmnd being now used for an skbuff. Memory poisoning was enabled in the kernel to debug this which showed that the last owner of the memory that had been freed was aacraid and that it was a struct request. The memory that was corrupted was the exact data pattern of AAC_OWNER_FIRMWARE and it was at the same offset that aacraid writes, which is scsicmd->SCp.phase. The patch below resolves this issue. Signed-off-by: Brian King Tested-by: Wen Xiong Reviewed-by: Dave Carroll Signed-off-by: Martin K. Petersen Signed-off-by: Greg Kroah-Hartman

scsi: aacraid: Fix out of bounds in aac_get_name_resp

2017-08-17T00:01:31Z

We terminate the aac_get_name_resp on a byte that is outside the bounds of the structure. Extend the return response by one byte to remove the out of bounds reference. Fixes: b836439faf04 ("aacraid: 4KB sector support") Reported-by: Dan Carpenter Signed-off-by: David Carroll Signed-off-by: Raghava Aditya Renukunta Reviewed-by: Bart Van Assche Signed-off-by: Martin K. Petersen

scsi: aacraid: reading out of bounds

2017-07-27T02:09:21Z

"qd.id" comes directly from the copy_from_user() on the line before so we should verify that it's within bounds. Signed-off-by: Dan Carpenter Signed-off-by: Martin K. Petersen

scsi: aacraid: Don't copy uninitialized stack memory to userspace

2017-06-26T19:01:03Z

Both aac_send_raw_srb() and aac_get_hba_info() may copy stack allocated structs to userspace without initializing all members of these structs. Clear out this memory to prevent information leaks. Fixes: 423400e64d377 ("scsi: aacraid: Include HBA direct interface") Fixes: c799d519bf088 ("scsi: aacraid: Retrieve HBA host information ioctl") Signed-off-by: Seth Forshee Reviewed-by: Johannes Thumshirn Signed-off-by: Martin K. Petersen

scsi: aacraid: fix leak of data from stack back to userspace

2017-06-26T16:32:15Z

The fields sense_data_size and sense_data are unitialized garbage from the stack and are being copied back to userspace. Fix this leak of stack information by ensuring they are zero'd. Detected by CoverityScan, CID#1435473 ("Uninitialized scalar variable") Fixes: 423400e64d377 ("scsi: aacraid: Include HBA direct interface") Signed-off-by: Colin Ian King Acked-by: Dave Carroll Signed-off-by: Martin K. Petersen

scsi: aacraid: Update driver version to 50834

2017-06-13T00:48:00Z

Update the driver version to 50834 Signed-off-by: Raghava Aditya Renukunta Reviewed-by: David Carroll Signed-off-by: Martin K. Petersen

scsi: aacraid: Remove reference to Series-9

2017-06-13T00:48:00Z

Remove reference to Series-9 HBA and created arc ctrl check function. Signed-off-by: Prasad B Munirathnam Signed-off-by: Raghava Aditya Renukunta Reviewed-by: David Carroll Signed-off-by: Martin K. Petersen