- 05 Nov, 2020 14 commits
-
-
Mike Christie authored
Except for debug output in the shutdown path, tcm_qla2xxx is the only driver using the se_session sess_cmd_list. Move the list to that driver to facilitate removing the sess_cmd_lock from the main I/O path for the rest of the drivers. Link: https://lore.kernel.org/r/1604257174-4524-6-git-send-email-michael.christie@oracle.com Cc: Nilesh Javali <njavali@marvell.com> Reviewed-by:
Himanshu Madhani <himanshu.madhani@oracle.com> Signed-off-by:
Mike Christie <michael.christie@oracle.com> Signed-off-by:
Martin K. Petersen <martin.petersen@oracle.com>
-
Mike Christie authored
TARGET_SCF_LOOKUP_LUN_FROM_TAG is no longer used so remove it. Link: https://lore.kernel.org/r/1604257174-4524-5-git-send-email-michael.christie@oracle.comReviewed-by:
-
Mike Christie authored
Only the __qlt_24xx_handle_abts() code path does not know the LUN for an abort and it uses the TARGET_SCF_LOOKUP_LUN_FROM_TAG flag to have LIO core look it up. LIO uses target_lookup_lun_from_tag to go from cmd tag to LUN for the driver. However, qla2xxx has a tcm_qla2xxx_find_cmd_by_tag() which does almost the same thing as the LIO helper (it finds the cmd but does not return the LUN). This patch has qla2xxx use its internal helper. Link: https://lore.kernel.org/r/1604257174-4524-4-git-send-email-michael.christie@oracle.com Cc: Nilesh Javali <njavali@marvell.com> Reviewed-by:
-
Mike Christie authored
percpu_ref_init sets the refcount to 1 and percpu_ref_kill drops it. Drivers like iSCSI and loop do not call target_sess_cmd_list_set_waiting during session shutdown, though, so they have been calling percpu_ref_exit with a refcount still taken and leaking the cmd_counts memory. Link: https://lore.kernel.org/r/1604257174-4524-3-git-send-email-michael.christie@oracle.comReviewed-by:
-
Mike Christie authored
Fix two bugs in the LUN refcounting: 1. For the TCM_WRITE_PROTECTED case we were returning an error after taking a ref to the LUN, but never dropping it (caller just send status and drops cmd ref). 2. We still need to do a percpu_ref_tryget_live for the virt LUN 0 like we do for other LUNs, because the TPG code does the refcount/wait process like it does with other LUNs. Link: https://lore.kernel.org/r/1604257174-4524-2-git-send-email-michael.christie@oracle.comReviewed-by: -
Tom Rix authored
A semicolon is not needed after a switch statement. Link: https://lore.kernel.org/r/20201101144017.2284047-1-trix@redhat.comSigned-off-by:
Tom Rix <trix@redhat.com> Signed-off-by:
-
Tom Rix authored
A semicolon is not needed after a switch statement. Link: https://lore.kernel.org/r/20201101143812.2283642-1-trix@redhat.comReviewed-by:
Saurav Kashyap <skashyap@marvell.com> Signed-off-by:
-
David Disseldorp authored
SBC-4 r15 5.3 COMPARE AND WRITE command states: if the compare operation does not indicate a match, then terminate the command with CHECK CONDITION status with the sense key set to MISCOMPARE and the additional sense code set to MISCOMPARE DURING VERIFY OPERATION. In the sense data (see 4.18 and SPC-5) the offset from the start of the Data-Out Buffer to the first byte of data that was not equal shall be reported in the INFORMATION field. This change implements the missing logic to report the miscompare offset in the sense data INFORMATION field. As an optimization, byte-by-byte miscompare offset calculation is only performed after memcmp() mismatch. Link: https://lore.kernel.org/r/20201031233211.5207-5-ddiss@suse.deSigned-off-by:
David Disseldorp <ddiss@suse.de> Signed-off-by:
-
David Disseldorp authored
In preparation for finding and returning the miscompare offset. Link: https://lore.kernel.org/r/20201031233211.5207-4-ddiss@suse.deReviewed-by:
-
David Disseldorp authored
cmd.bad_sector currently gets packed into the sense INFORMATION field for TCM_LOGICAL_BLOCK_{GUARD,APP_TAG,REF_TAG}_CHECK_FAILED errors, which carry an .add_sector_info flag in the sense_detail_table to ensure this. In preparation for propagating a byte offset on COMPARE AND WRITE TCM_MISCOMPARE_VERIFY error, rename cmd.bad_sector to cmd.sense_info and sense_detail.add_sector_info to sense_detail.add_sense_info so that it better reflects the sense INFORMATION field destination. [ddiss: update previously overlooked ib_isert] Link: https://lore.kernel.org/r/20201031233211.5207-3-ddiss@suse.deReviewed-by: -
David Disseldorp authored
This helps distinguish it from the SCSI sense INFORMATION field. Link: https://lore.kernel.org/r/20201031233211.5207-2-ddiss@suse.deReviewed-by:
-
Arnd Bergmann authored
There have been several attempts to fix serious problems in the compat handling in megasas_mgmt_compat_ioctl_fw(), and it also uses the compat_alloc_user_space() function. Folding the compat handling into the regular ioctl function with in_compat_syscall() simplifies it a lot and avoids some of the remaining problems: - missing handling of unaligned pointers - overflowing the ioc->frame.raw array from invalid input - compat_alloc_user_space() Link: https://lore.kernel.org/r/20201030164450.1253641-3-arnd@kernel.orgReviewed-by:
Christoph Hellwig <hch@lst.de> Signed-off-by:
Arnd Bergmann <arnd@arndb.de> Signed-off-by:
-
Arnd Bergmann authored
It sounds unwise to let user space pass an unchecked 32-bit offset into a kernel structure in an ioctl. This is an unsigned variable, so checking the upper bound for the size of the structure it points into is sufficient to avoid data corruption, but as the pointer might also be unaligned, it has to be written carefully as well. While I stumbled over this problem by reading the code, I did not continue checking the function for further problems like it. Link: https://lore.kernel.org/r/20201030164450.1253641-2-arnd@kernel.org Fixes: c4a3e0a5 ("[SCSI] MegaRAID SAS RAID: new driver") Cc: <stable@vger.kernel.org> # v2.6.15+ Reviewed-by:
-
Arnd Bergmann authored
The use of compat_alloc_user_space() can be easily replaced by handling compat arguments in the regular handler, and this will make it work for big-endian kernels as well, which at the moment get an invalid indirect pointer argument. Calling aac_ioctl() instead of aac_compat_do_ioctl() means the compat and native code paths behave the same way again, which they stopped when the adapter health check was added only in the native function. Link: https://lore.kernel.org/r/20201030164450.1253641-1-arnd@kernel.org Fixes: 572ee53a ("scsi: aacraid: check adapter health") Reviewed-by:
-
- 04 Nov, 2020 14 commits
-
-
Sreekanth Reddy authored
Bump mpt3sas driver version to 35.101.00.00 Link: https://lore.kernel.org/r/20201027130847.9962-15-sreekanth.reddy@broadcom.comSigned-off-by:
Sreekanth Reddy <sreekanth.reddy@broadcom.com> Signed-off-by:
-
Sreekanth Reddy authored
Add module parameter multipath_on_hba to enable/disable multi-port path topology support. By default this feature is enabled on SAS3.5 HBA device and disabled on SAS3 &SAS2.5 HBA devices. When this feature is disabled then driver uses a default PhysicalPort(PortID) number i.e. 255 instead of the PhysicalPort number provided by HBA firmware. Link: https://lore.kernel.org/r/20201027130847.9962-14-sreekanth.reddy@broadcom.comSigned-off-by:
-
Sreekanth Reddy authored
During HBA reset the Port ID of vSES device may change. As a result, it is necessary to refresh virtual_phy objects after reset. Each Port's vphy_list table needs to be updated after updating the HBA port table. The algorithm is as follows: - Loop over each port entry from HBA port table * Loop over each virtual phy entry from port's vphys_list table - Mark virtual phy entry as dirty by setting dirty bit in virtual phy entry's flags field - Read SASIOUnitPage0 page - Loop over each HBA Phy's Phy data from SASIOUnitPage0 * If phy's remote attached device is not SES device then continue with processing next HBA Phy's Phy data; * Read SASPhyPage0 data for this Phy number and determine whether current phy is a virtual phy or not. If it is not a virtual phy then continue with next Phy data; * Get the current phy's remote attached vSES device's SAS Address; * Loop over each port entry from HBA port table - If Port's vphys_mask field is zero then continue with next Port entry, - Loop over each virtual phy entry from Port's vphy_list table - If the current phy's remote SAS Address is different from virtual phy entry's SAS Address then continue with next virtual phy entry, - Set bit corresponding to current phy number in virtual phy entry's phy_mask field, - Get the HBA port table's Port entry corresponding to Phy data's 'Port' value, * If there is no Port entry corresponding to Phy data's 'Port' value in HBA port table then create a new port entry and add it to HBA port table. - If this retrieved Port entry is the same as the current Port entry then don't do anything, just clear the dirty bit from virtual phy entry's flag field and continue with processing next HBA Phy's Phy data. - If this retrieved Port entry is different from the current Port entry then move the current virtual phy entry from current Port's vphys_list to retrieved Port entry's vphys_list. * Clear current phy bit in current Port entry's vphys_mask and set the current phy bit in the retrieved Port entry's vphys_mask field. * Clear the dirty bit from virtual phy entry's flag field and continue with next HBA Phy's Phy data. - Delete the 'virtual phy' entries and HBA's 'Port table' entries which are still marked as 'dirty'. Link: https://lore.kernel.org/r/20201027130847.9962-13-sreekanth.reddy@broadcom.comSigned-off-by: -
Sreekanth Reddy authored
Added a new parameter bypass_dirty_port_flag in function mpt3sas_get_port_by_id(). When this parameter is set to one then search for matching hba port entry from port_table_list even when this hba_port entry is marked as dirty. Link: https://lore.kernel.org/r/20201027130847.9962-12-sreekanth.reddy@broadcom.comSigned-off-by:
-
Sreekanth Reddy authored
Each direct attached device will have a unique Port ID, but with an exception. HBA vSES may use the same Port ID of another direct attached device Port's ID. As a result, special handling is needed for vSES. Create a virtual_phy object when a new HBA vSES device is detected and add this virtual_phy object to vphys_list of port ID's hba_port object. When the HBA vSES device is removed then remove the corresponding virtual_phy object from its parent's hba_port's vphy_list and free this virtual_vphy object. In hba_port object add vphy_mask field to hold the list of HBA phy bits which are assigned to vSES devices. Also add vphy_list list to hold list of virtual_phy objects which holds the same portID of current hba_port's portID. Also, add a hba_vphy field in _sas_phy object to determine whether this _sas_phy object belongs to vSES device or not. - Allocate a virtual_phy object whenever a virtual phy is detected while processing the SASIOUnitPage0's phy data. And this allocated virtual_phy object to corresponding PortID's hba_port's vphy_list. - When a vSES device is added to the SML then initialize the corresponding virtual_phy objects's sas_address field with vSES device's SAS Address. - Free this virtual_phy object during driver unload time and when this vSES device is removed. Link: https://lore.kernel.org/r/20201027130847.9962-11-sreekanth.reddy@broadcom.comSigned-off-by:
-
Sreekanth Reddy authored
The driver currently sets PhysicalPort field to 0xFF for SMPPassthrough Request message. In zoning topologies this SMPPassthrough command always operates on devices in one zone (default zone) even when user issues SMP command for other zone drives. Define _transport_get_port_id_by_rphy() and _transport_get_port_id_by_sas_phy() helper functions to get Physical Port number from sas_rphy & sas_phy respectively for SMPPassthrough request message so that SMP Passthrough request message is sent to intended zone device. Link: https://lore.kernel.org/r/20201027130847.9962-10-sreekanth.reddy@broadcom.comSigned-off-by:
-
Sreekanth Reddy authored
During host reset there is a chance that the Port number allocated by the firmware for the attached devices may change. Also, it may be possible that some HBA phy's can go down/come up after reset. As a result, the driver can't just trust the HBA Port table that it has populated before host reset as valid. Instead it has to update the HBA Port table in such a way that it shouldn't disturb the drives which are still accessible even after host reset. Use the following algorithm to update the HBA Port table during host reset: I. After host reset operation and before marking the devices as responding/non-responding, create a temporary Port table called "New Port table" by parsing each of the HBA phy's Phy data info read from SAS IOUnit Page0: a. Check whether Phy's negotiated link rate is greater than 1.5Gbps, if not go to next Phy; b. Get the SAS Address of the attached device; c. Create a new entry in the "New Port table" with SAS Address field filled with attached device's SAS Address, port number with Phy's Port number (read from SAS IOUnit Page0) and enable bit in the 'Phy mask' field corresponding to current Phy number. New entry is created only if the driver can't find an entry in the "New Port table" which matches with attached device 'SAS Address' & 'Port Number'. If it finds an entry with matches with attached device 'SAS Address' & 'Port Number' then the driver takes that matched entry and will enable current Phy number bit in the 'Phy mask' field; d. After parsing all the HBA phy's info, the driver will have complete Port table info in "New Port table". II. Mark all the existing sas_device & sas_expander device structures as 'dirty'. III. Mark each entry of the HBA Port lists as 'dirty'. IV. Take each entry from 'New Port table' one by one and check whether the entry has any corresponding matched entry (which is marked as 'dirty') in the HBA Port table or not. While looking for a corresponding matched entry, look for matched entry in the sequence from top row to bottom row listed in the following table. If you find any matched entry (according to any of the rules tabulated below) then perform the action mentioned in the 'Action' column in that matched rule. =========================================================================== |Search |SAS | Phy Mask | Port | Possibilities| Action | |every |Address | or | Number | | required | |entry |matched?| subset of| matched?| | | |in below| | phy mask | | | | |sequence| | matched? | | | | =========================================================================== | 1 |matched | matched | matched | nothing |* unmark HBA port | | | | | | changed |table entry as | | | | | | |dirty | --------------------------------------------------------------------------- | 2 |matched | matched | not | port number |* Update port | | | | | matched | is changed |number in the | | | | | | |matched port table | | | | | | |entry | | | | | | |* unmask HBA port | | | | | | |table entry as | | | | | | |dirty | --------------------------------------------------------------------------- | 3.a |matched | subset of| matched |some phys |* Add these new | | | | phy mask | (or) |might have |phys to current | | | | matched | not |enabled which |port in STL | | | | | matched |are previously|* Update phy mask | | | | | (but |disabled |field in HBA's port| | | | | first | |table's matched | | | | | look for| |entry, | | | | | matched | |* Update port | | | | | one) | |number in the | | | | | | |matched port | | | | | | |table entry (if | | | | | | |port number is | | | | | | |changed), | | | | | | |* Unmask HBA port | | | | | | |table entry as | | | | | | |dirty | --------------------------------------------------------------------------- | 3.b |matched | subset of| matched |some phys |*Remove these phys | | | | phy mask | (or) |might have |from current port | | | | matched | not |disabled which|in STL | | | | | matched |are previously|* Update phy mask | | | | | (but |enabled |field in HBA's port| | | | | first | |tables's matched | | | | | look for| |entry, | | | | | matched | |*Update port number| | | | | one) | |in the matched port| | | | | | |table entry (if | | | | | | |port number is | | | | | | |changed), | | | | | | |* Unmask HBA port | | | | | | |table entry as | | | | | | |dirty | --------------------------------------------------------------------------- | 4 |matched | not | matched |A cable |*Remove old phys & | | | | matched | (or) |attached to an|new phys to current| | | | | not |expander is |port in STL | | | | | matched |changed to |* Update phy mask | | | | | |another HBA |field in HBA's port| | | | | |port during |tables's matched | | | | | |reset |entry, | | | | | | |*Update port number| | | | | | |in the matched port| | | | | | |table entry (if | | | | | | |port number is | | | | | | |changed), | | | | | | |* Unmask HBA port | | | | | | |table entry as | | | | | | |dirty | --------------------------------------------------------------------------- V. Delete the hba_port objects which are still marked as dirty. Link: https://lore.kernel.org/r/20201027130847.9962-9-sreekanth.reddy@broadcom.comReported-by:kernel test robot <lkp@intel.com> Reported-by:
Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by:
-
Sreekanth Reddy authored
In the following scsi_host_template and sas_function_template callback functions the driver does not have PhysicalPort number information to retrieve the sas_device object using SAS Address & PhysicalPort number. In these callback functions the device's rphy object is used to retrieve sas_device object for the device. .target_alloc, .get_enclosure_identifier .get_bay_identifier When a rphy (of type sas_rphy) object is allocated then its address is saved in corresponding sas_device object's rphy field. In __mpt3sas_get_sdev_by_rphy(), the driver loops over all the sas_device objects from sas_device_list list to retrieve the sas_device objects whose rphy matches the provided rphy. Link: https://lore.kernel.org/r/20201027130847.9962-8-sreekanth.reddy@broadcom.comSigned-off-by:
-
Sreekanth Reddy authored
Renamed _transport_add_phy_to_an_existing_port() to mpt3sas_transport_add_phy_to_an_existing_port() and _transport_del_phy_from_an_existing_port() to mpt3sas_transport_del_phy_from_an_existing_port() as the driver needs to call these functions from outside mpt3sas_transport.c file. Added extra function argument 'port' of type struct hba_port to above functions and check for portID before adding/removing the phy from the _sas_port object. I.e. add/remove the phy from _sas_port object only if _sas_port's port object and phy's port object are the same. Link: https://lore.kernel.org/r/20201027130847.9962-7-sreekanth.reddy@broadcom.comSigned-off-by:
-
Sreekanth Reddy authored
Currently driver retrieves the sas_device/sas_expander objects from corresponding object's lists using just device's SAS Address. Make driver retrieve the objects from the corresponding objects list using device's SAS Address and PhysicalPort (or PortID) number. PhysicalPort number is the port number of the HBA through which this device is accessed. Link: https://lore.kernel.org/r/20201027130847.9962-6-sreekanth.reddy@broadcom.comSigned-off-by:
-
Sreekanth Reddy authored
Update hba_port's sas_address & phy_mask fields whenever a direct expander or sas/sata target devices are added or removed. When any direct attached device is discovered then driver: - Gets the hba_port object corresponding to device's PhysicalPort number; - Updates the hba_port's sas_address field with device's SAS Address; - Updates the hba_port's phy_mask filed with device's narrow/wide port Phy number bits; - If a sas/sata end device (not only direct-attached devices) is added then corresponding sas_device object's port variable is assigned with hba_port object's address whose port_id matches the device's PhysicalPort number. - If an expander device is added then corresponding sas_expander object's port variable is assigned with hba_port object's address whose port_id matches the expander device's PhysicalPort number. When any direct attached device is detached then driver will delete the hba_port object corresponding to device's PhysicalPort number. Whenever any HBA phy's link (of direct attached device's port) comes up then update the phy_mask field of corresponding hba_port object. Link: https://lore.kernel.org/r/20201027130847.9962-5-sreekanth.reddy@broadcom.comSigned-off-by:
-
Sreekanth Reddy authored
Rearrange _scsih_mark_responding_sas_device function. No functional change. Link: https://lore.kernel.org/r/20201027130847.9962-4-sreekanth.reddy@broadcom.comSigned-off-by:
-
Sreekanth Reddy authored
Allocate hba_port object whenever a new HBA's wide/narrow port is identified while processing the SASIOUnitPage0's phy data and add this object to port_table_list. Deallocate these objects during driver unload. Link: https://lore.kernel.org/r/20201027130847.9962-3-sreekanth.reddy@broadcom.comSigned-off-by:
-
Sreekanth Reddy authored
Define a new hba_port structure which holds the following variables: - port_id: Port ID of the narrow/wide port of the HBA - sas_address: SAS Address of the remote device that is attached to the current HBA port - phy_mask: HBA's phy bits to which above SAS addressed device is attached - flags: This field is used to refresh port details during HBA reset Link: https://lore.kernel.org/r/20201027130847.9962-2-sreekanth.reddy@broadcom.comSigned-off-by:
-
- 30 Oct, 2020 12 commits
-
-
Julian Wiedmann authored
As recovery for a lost Version Change event, trigger an Exchange Config Data cmd to retrieve the current FW version. Doing so requires process context (as eg. zfcp_qdio_sbal_get() might need to sleep), so defer from tasklet context into a work item. Link: https://lore.kernel.org/r/297c7be2944c3714863fcd22d531d910312d29f0.1603908167.git.bblock@linux.ibm.comSuggested-by:
Steffen Maier <maier@linux.ibm.com> Reviewed-by:
Benjamin Block <bblock@linux.ibm.com> Signed-off-by:
Julian Wiedmann <jwi@linux.ibm.com> Signed-off-by:
-
Julian Wiedmann authored
Handle notifications for a concurrent change of the FCP Channel firmware. Update the relevant user-visible fields to provide accurate data. Link: https://lore.kernel.org/r/d2c7bc57c6cf1b65eabbf7a5d0e3927b9f65647f.1603908167.git.bblock@linux.ibm.comReviewed-by:
-
Julian Wiedmann authored
Explain why the plain spin_lock() suffices in current code, even when the stat_lock is also used by zfcp_qdio_int_req() in tasklet context. We could also promote the spin_lock() to a spin_lock_irqsave(), but that would just obfuscate the locking even further. Link: https://lore.kernel.org/r/b023b1472630f4bf9fce580577d7bb49de89ccbf.1603908167.git.bblock@linux.ibm.comReviewed-by:
-
Vasily Gorbik authored
drivers/s390/scsi/zfcp_ext.h: zfcp_sg_free_table - only declaration left after commit 58f3ead5 ("scsi: zfcp: move SG table helper from aux to fc and make them static") drivers/s390/scsi/zfcp_ext.h: zfcp_sg_setup_table - only declaration left after commit 58f3ead5 ("scsi: zfcp: move SG table helper from aux to fc and make them static") Link: https://lore.kernel.org/r/6854ae03c5c65805f746774eeb0f2869fcd6c397.1603908167.git.bblock@linux.ibm.comReviewed-by:
Vasily Gorbik <gor@linux.ibm.com> Signed-off-by:
-
Julian Wiedmann authored
Shift the IRQ tasklet processing from the qdio layer into zfcp. This will allow for a good amount of cleanups in qdio, and provides future opportunity to improve the IRQ processing inside zfcp. We continue to use the qdio layer's internal tasklet/timer mechanism (ie. scan_threshold etc) to check for Request Queue completions. Initially we planned to check for such completions after inspecting the Response Queue - this should typically work, but there's a theoretical race where the device only presents the Request Queue completions _after_ all Response Queue processing has finished. If the Request Queue is then also _completely_ full, we could send no further IOs and thus get no interrupt that would trigger an inspection of the Request Queue. So for now stick to the old model, where we can trust that such a race would be recovered by qdio's internal timer. Code-flow wise, this establishes two levels of control: 1. The qdio layer will only deliver IRQs to the device driver if the QDIO_IRQ_DISABLED flag is cleared. zfcp manages this through qdio_start_irq() / qdio_stop_irq(). The initial state is DISABLED, and zfcp_qdio_open() schedules zfcp's IRQ tasklet once during startup to explicitly enable IRQ delivery. 2. The zfcp tasklet is initialized with tasklet_disable(), and only gets enabled once we open the qdio device. When closing the qdio device, we must disable the tasklet _before_ disabling IRQ delivery (otherwise a concurrently running tasklet could re-enable IRQ delivery after we disabled it). A final tasklet_kill() during teardown ensures that no lingering tasklet_schedule() is still accessing the tasklet structure. Link: https://lore.kernel.org/r/94a765211c48b74a7b91c5e60b158de01db98d43.1603908167.git.bblock@linux.ibm.comReviewed-by:
-
ching Huang authored
Ensure getting a free ccb is done under the spin_lock. Link: https://lore.kernel.org/r/f3ec374cada762149911ff35e92a68a15a7d0327.camel@areca.com.twSigned-off-by:
ching Huang <ching2048@areca.com.tw> Signed-off-by:
-
ching Huang authored
Allow configuring the default command timeout value for devices attached to arcmsr controllers. Link: https://lore.kernel.org/r/27c0cda7fd103f05021adaf67490e9298ed5cc3f.camel@areca.com.twSigned-off-by:
-
Asutosh Das authored
Enabling this capability to let HBA power-collapse more often to save power. Link: https://lore.kernel.org/r/1306284ab2215425ca0a3d9c802574cbd6d35ea7.1603825776.git.asutoshd@codeaurora.orgReviewed-by:
Can Guo <cang@codeaurora.org> Reviewed-by:
Avri Altman <avri.altman@wdc.com> Signed-off-by:
Asutosh Das <asutoshd@codeaurora.org> Signed-off-by:
-
Can Guo authored
During clock gating, after clocks are disabled, put HBA into LPM to save more power. Link: https://lore.kernel.org/r/52198e70bff750632740d78678a815256d697e43.1603825776.git.asutoshd@codeaurora.orgReviewed-by:
Stanley Chu <stanley.chu@mediatek.com> Signed-off-by:
-
Arnd Bergmann authored
gcc -Wextra points out an assignment between two different enum types: drivers/scsi/libfc/fc_exch.c: In function 'fc_exch_setup_hdr': ../drivers/scsi/libfc/fc_exch.c:275:26: warning: implicit conversion from 'enum fc_class' to 'enum fc_sof' [-Wenum-conversion] This seems to be intentional, as the same numeric values are used here, so shut up the warning by adding an explicit cast. Link: https://lore.kernel.org/r/20201026214911.3892701-1-arnd@kernel.org Fixes: 42e9a92f ("[SCSI] libfc: A modular Fibre Channel library") Signed-off-by:
-
Arnd Bergmann authored
Building libfc with gcc -Warray-bounds identifies a number of cases in one file where a strncpy() is performed into a single-byte character array: In file included from include/linux/bitmap.h:9, from include/linux/cpumask.h:12, from include/linux/smp.h:13, from include/linux/lockdep.h:14, from include/linux/spinlock.h:59, from include/linux/debugobjects.h:6, from include/linux/timer.h:8, from include/scsi/libfc.h:11, from drivers/scsi/libfc/fc_elsct.c:17: In function 'strncpy', inlined from 'fc_ct_ms_fill.constprop' at drivers/scsi/libfc/fc_encode.h:235:3: include/linux/string.h:290:30: warning: '__builtin_strncpy' offset [56, 135] from the object at 'pp' is out of the bounds of referenced subobject 'value' with type '__u8[1]' {aka 'unsigned char[1]'} at offset 56 [-Warray-bounds] 290 | #define __underlying_strncpy __builtin_strncpy | ^ include/linux/string.h:300:9: note: in expansion of macro '__underlying_strncpy' 300 | return __underlying_strncpy(p, q, size); | ^~~~~~~~~~~~~~~~~~~~ This is not a bug because the 1-byte array is used as an odd way to express a variable-length data field here. I tried to convert it to a flexible-array member, but in the end could not figure out why the sizeof(struct fc_fdmi_???) are used the way they are, and how to properly convert those. Work around this instead by abstracting the string copy in a slightly higher-level function fc_ct_hdr_fill() helper that strscpy() and memset() to achieve the same result as strncpy() but does not require a zero-terminated input and does not get checked for the array overflow because gcc (so far) does not understand the behavior of strscpy(). Link: https://lore.kernel.org/r/20201026160705.3706396-2-arnd@kernel.orgSigned-off-by: -
Arnd Bergmann authored
Most of this file is only used inside of libfc, so move it to where it is actually used, with only fc_fill_fc_hdr() left inside of the header. Link: https://lore.kernel.org/r/20201026160705.3706396-1-arnd@kernel.orgReported-by:
-
