summaryrefslogtreecommitdiffstats
path: root/sys/cam
Commit message (Collapse)AuthorAgeFilesLines
* MFC: r323840jkim2017-09-251-4/+0
| | | | Remove an ancient comment about the existence of READ(16)/WRITE(16) for MMC.
* MFV r318962: Allow PROBE_SPINUP to fail in CAM ATA transportavg2017-09-191-0/+10
| | | | | | | | | | | | | | The motivation for this is two-fold. 1. Some old WD SATA disks may appear as if they need to be spun up when they are already spinning. Those disks would respond with an error to the spin-up request. 2. Even if we really fail to spin up the disk, we still can try to proceed to the subsequent phases. If we fail later on, then no difference. Otherwise we get a chance to communicate with the disk which is better than completely ignoring it, because a user can try to recover the disk.
* MFC r320421:ken2017-07-031-2/+12
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | ------------------------------------------------------------------------ r320421 | ken | 2017-06-27 13:26:02 -0600 (Tue, 27 Jun 2017) | 37 lines Fix a panic in camperiphfree(). If a peripheral driver (e.g. da, sa, cd) is added or removed from the peripheral driver list while an unrelated peripheral driver instance (e.g. da0, sa5, cd2) is going away and is inside camperiphfree(), we could dereference an invalid pointer. When peripheral drivers are added or removed (see periphdriver_register() and periphdriver_unregister()), the peripheral driver array is resized and existing entries are moved. Although we hold the topology lock while we traverse the peripheral driver list, we retain a pointer to the location of the peripheral driver pointer and then drop the topology lock. So we are still vulnerable to the list getting moved around while the lock is dropped. To solve the problem, cache a copy of the peripheral driver pointer. If its storage location in the list changes while we have the lock dropped, it won't have any effect. This doesn't solve the issue that peripheral drivers ("da", "cd", as opposed to individual instances like "da0", "cd0") are not generally part of a reference counting scheme to guard against deregistering them while there are instances active. The caller (generally the person unloading a module) has to be aware of active drivers and not unload something that is in use. sys/cam/cam_periph.c: In camperiphfree(), cache a pointer to the peripheral driver instance to avoid holding a pointer to an invalid memory location in the event that the peripheral driver list changes while we have the topology lock dropped. PR: kern/219701 Submitted by: avg Sponsored by: Spectra Logic ------------------------------------------------------------------------ PR: kern/219701 Sponsored by: Spectra Logic
* MFC r320372:markj2017-06-291-1/+2
| | | | Fix a memory leak in ses_get_elm_devnames().
* MFC r320123:ken2017-06-261-1/+12
| | | | | | | | | | | | | | | | | | | | | | | Fix a potential sleep while holding a mutex in the sa(4) driver. If the user issues a MTIOCEXTGET ioctl, and the tape drive in question has a serial number that is longer than 80 characters, we malloc a buffer in saextget() to hold the output of cam_strvis(). Since a mutex is held in that codepath, doing a M_WAITOK malloc could lead to sleeping while holding a mutex. Change it to a M_NOWAIT malloc and bail out if we fail to allocate the memory. Devices with serial numbers longer than 80 bytes are very rare (I don't recall seeing one), so this should be a very unusual case to hit. But it is a bug that should be fixed. sys/cam/scsi/scsi_sa.c: In saextget(), if we need to malloc a buffer to hold the output of cam_strvis(), don't wait for the memory. Fail and return an error if we can't allocate the memory immediately. PR: kern/220094 Submitted by: Jia-Ju Bai <baijiaju1990@163.com> Sponsored by: Spectra Logic
* MFC r317775:ken2017-05-101-3/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Fix error recovery behavior in the pass(4) driver. After FreeBSD SVN revision 236814, the pass(4) driver changed from only doing error recovery when the CAM_PASS_ERR_RECOVER flag was set on a CCB to sometimes doing error recovery if the passed in retry count was non-zero. Error recovery would happen if two conditions were met: 1. The error recovery action was simply a retry. (Which is most cases.) 2. The retry_count is non-zero. (Which happened a lot because of cut-and-pasted code.) This explains a bug I noticed in with camcontrol: # camcontrol tur da34 -v Unit is ready # camcontrol reset da34 Reset of 1:172:0 was successful At this point, there should be a Unit Attention: # camcontrol tur da34 -v Unit is ready No Unit Attention. Try it again: # camcontrol reset da34 Reset of 1:172:0 was successful Now set the retry_count to 0 for the TUR: # camcontrol tur da34 -v -C 0 Unit is not ready (pass42:mps1:0:172:0): TEST UNIT READY. CDB: 00 00 00 00 00 00 (pass42:mps1:0:172:0): CAM status: SCSI Status Error (pass42:mps1:0:172:0): SCSI status: Check Condition (pass42:mps1:0:172:0): SCSI sense: UNIT ATTENTION asc:29,2 (SCSI bus reset occurred) (pass42:mps1:0:172:0): Field Replaceable Unit: 2 There is the unit attention. camcontrol(8) has a default retry_count of 1, in case someone sets the -E flag without setting -C. The CAM_PASS_ERR_RECOVER behavior was only broken with the CAMIOCOMMAND ioctl, which is the synchronous pass(4) API. It has worked as intended (error recovery is only done when the flag is set) in the asynchronous API (CAMIOQUEUE ioctl). sys/cam/scsi/scsi_pass.c: In passsendccb(), when calling cam_periph_runccb(), only specify the error routine when CAM_PASS_ERR_RECOVER is set. share/man/man4/pass.4: Document that CAM_PASS_ERR_RECOVER is needed to enable error recovery. Reported by: Terry Kennedy <TERRY@glaver.org> PR: kern/218572 Sponsored by: Spectra Logic
* MFC r317848:ken2017-05-081-3/+30
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Add basic programmable early warning error injection to the sa(4) driver. This will help application developers simulate end of tape conditions. To inject an error in sa0: sysctl kern.cam.sa.0.inject_eom=1 This will return the next read or write request queued with 0 bytes written. Any subsequent writes or reads will go along as usual. This will also cause the early warning position flag to get set for the next position query. So, 'mt status' will show the BPEW (Beyond Programmable Early Warning) flag on the first query after an error injection. After that, the position flags will be as they are in the underlying tape drive. Also, update the sa(4) man page to describe tape parameters, which can be set via 'mt param'. sys/cam/scsi/scsi_sa.c: In saregister(), create the inject_eom sysctl variable. In sastart(), check to see whether inject_eom is set. If so, return the read or write with 0 bytes written to indicate EOM. Set the set_pews_status flag so that we fake PEWS status in the next position call for reads, and the next 3 calls for writes. This allows the user to see the BPEW flag one time via 'mt status'. In sagetpos(), check the set_pews_status flag and fake PEWS status and decrement the counter if it is set. share/man/man4/sa.4: Document the inject_eom sysctl variable. Document all of the parameters currently supported via 'mt param'. usr.bin/mt/mt.1: Point the user to the sa(4) man page for more details on supported parameters. Sponsored by: Spectra Logic
* MFC r317799:ken2017-05-081-0/+8
| | | | | | | | | | | Add the SCSI Solid State Media Log page (0x11) definition. sys/cam/scsi/scsi_all.h: Add the SCSI Solid State Media log page (0x11) structure definition. This gives the percentage used (in terms of lifetime flash wear) of an SSD. Sponsored by: Spectra Logic
* MFC r317745:ken2017-05-081-1/+1
| | | | | | | | | | | | | | Don't bother retrying errors for encrypted drives that are locked. sys/cam/scsi/scsi_all.c: In the asc_table, if we get a 0x20,0x02 error ("Access denied - no access rights"), don't bother retrying. Instead, immediately fail the command. This is the error returned by Self Encrypting Drives (SED) when they are locked. Sponsored by: Spectra Logic
* MFC r317680:ken2017-05-051-0/+13
| | | | | | | | | Add the SCSI SSC Manufacturer assigned serial number VPD page. This is current as of SSC-5r03. Submitted by: Sam Klopsch Sponsored by: Spectra Logic
* MFC r316653: Fix few minor issues found by Clang Analyzer.mav2017-04-232-4/+10
|
* MFC r316066:bdrewery2017-04-131-0/+1
| | | | Release ccb if mode_buffer allocation fails.
* MFC r315673, r315674: Make CAM SIM lock optional.mav2017-04-042-44/+72
| | | | | | For three years now CAM does not use SIM lock, but still enforces SIM to use it. Remove this requirement, allowing SIMs to have any locking they prefer, if they pass no mutex to cam_sim_alloc().
* MFC r315084: Increase device openings to tagged maximum.mav2017-03-251-5/+25
| | | | | | | | | | | Some SIMs report much less untagged device openings then tagged ones. Target mode devices are not handled by regular probing routines, and so there is nothing to increase queue size for them to the SIM's maximum. To fix that resize the queue explicitly on ctl periph registration. This radically improves performance of mpt(4) in target mode. Also fetch and report device queue statistics in `ctladm dumpstructs`, since regular way of `camcontrol tags` is not usable in target mode.
* MFC r315082: Allow XPT_GDEV_STATS for UNCONFIGURED devices.mav2017-03-251-29/+18
| | | | | Queue statistics has nothing to do with presence or absence of INQUIRY data, etc. Target mode devices are never configured, but have queues.
* MFC r315022: Request change of SIM target role only when it is different.mav2017-03-241-51/+51
| | | | Separate WWNs change into separate request to know what actually failed.
* MFC r315030: Abort all ATIOs and INOTs queued to SIM on LUN disable.mav2017-03-241-22/+45
| | | | | | | Some SIMs may not abort them implicitly, that either fail the LUN disable request or just make us wait for those CCBs forever. With this change I can successfully disable LUNs on mpt(4). For isp(4), which aborts them implicitly, this change should be irrelevant.
* MFC r315025: Switch work_queue from TAILQ to STAILQ.mav2017-03-241-14/+13
| | | | It is mostly FIFO and we don't need random removal there.
* MFC r311305 (by asomers):mav2017-03-233-9/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | Always null-terminate ccb_pathinq.(sim_vid|hba_vid|dev_name) The sim_vid, hba_vid, and dev_name fields of struct ccb_pathinq are fixed-length strings. AFAICT the only place they're read is in sbin/camcontrol/camcontrol.c, which assumes they'll be null-terminated. However, the kernel doesn't null-terminate them. A bunch of copy-pasted code uses strncpy to write them, and doesn't guarantee null-termination. For at least 4 drivers (mpr, mps, ciss, and hyperv), the hba_vid field actually overflows. You can see the result by doing "camcontrol negotiate da0 -v". This change null-terminates those fields everywhere they're set in the kernel. It also shortens a few strings to ensure they'll fit within the 16-character field. PR: 215474 Reported by: Coverity CID: 1009997 1010000 1010001 1010002 1010003 1010004 1010005 CID: 1331519 1010006 1215097 1010007 1288967 1010008 1306000 CID: 1211924 1010009 1010010 1010011 1010012 1010013 1010014 CID: 1147190 1010017 1010016 1010018 1216435 1010020 1010021 CID: 1010022 1009666 1018185 1010023 1010025 1010026 1010027 CID: 1010028 1010029 1010030 1010031 1010033 1018186 1018187 CID: 1010035 1010036 1010042 1010041 1010040 1010039
* MFC r314307: Add support for SIMs without autosense.mav2017-03-121-0/+14
| | | | | | | If we asked to send sense data by setting CAM_SEND_SENSE, but SIM didn't confirm transmission by setting CAM_SENT_SENSE, assume it was not sent. Queue the I/O back to CTL for later REQUEST SENSE with ctl_queue_sense(). This is needed for error reporting on SPI HBAs like ahc(4)/ahd(4).
* MFC r314338: Polish handling of different reset flavours.mav2017-03-063-93/+101
| | | | | The biggest change is that ctl_remove_initiator() now generates I_T NEXUS LOSS event, cleaning part of LUs state related to the initiator.
* MFC r314496: Add check missed in r314257.mav2017-03-061-1/+1
|
* MFC r314387: Make ctl_queue_sense() not sleep.mav2017-03-061-14/+8
| | | | It may be called in non-sleepable frontend context.
* MFC r314299, r314300: Fix residual length reporting in target mode.mav2017-03-061-3/+4
| | | | | | This allows to properly handle cases when target wants to receive or send more data then initiator wants to send or receive. Previously in such cases isp(4) returned CAM_DATA_RUN_ERR, while now it returns resid > 0.
* MFC r314257: Add reporting SAS protocol, in case we ever have one.mav2017-03-062-0/+4
|
* MFC r314255: Reenable CTL_WITH_CA, optimizing it for lower memory usage.mav2017-03-062-46/+45
| | | | | | This code was disabled due to its high memory usage. But now we need this functionality for cfumass(4) frontend, since USB MS BBB transport does not support autosense.
* MFC r314247: Axe out some forever disabled questionable functionality.mav2017-03-061-116/+6
| | | | This code is complicated enough even in its base shape.
* MFC r314246: Improve CAM target frontend reference counting.mav2017-03-061-54/+52
| | | | | Before this change it was possible to trigger some use-after-free panics by disabling LUNs/ports under heavy load.
* MFC r314204: Explicitly abort ATIO if CTIO sending status has failed.mav2017-03-061-0/+8
| | | | This helps SIM to free related resources in questionable cases.
* MFC r314200: We can't access periph after ctlfe_free_ccb().mav2017-03-061-1/+3
|
* MFC r314196: Unify ATIO/INOT CCBs requeuing.mav2017-03-061-58/+48
|
* MFC r314193: Some code cleanup.mav2017-03-061-38/+15
|
* MFC r314027: Do not blindly free completed ATIOs/INOTs on invalidation.mav2017-03-061-59/+19
| | | | | | | | | When LUN is disabled, SIM starts returning queued ATIOs/INOTs. But at the same time there can be some ATIOs/INOTs still carrying real new requests. If we free those, SIM may leak some resources, forever expecting for any response from us. So try to be careful, separating ATIOs/INOTs carrying requests which still must be processed, from ATIOs/INOTs completed with errors which can be freed.
* MFC r313744: No need to erase sense_data when sense_len is set to zero.mav2017-02-281-15/+0
|
* MFC r313910: Change XCOPY memory allocations.mav2017-02-251-13/+12
| | | | | | | | | | | | Before this change XCOPY code could allocate memory in chunks up to 16-32MB (VMware does XCOPY in 4MB chunks by default), that could be difficult for VM subsystem to do due to KVA fragmentation, that sometimes created huge allocation delays, blocking any I/O for respective LU for that time. This change limits allocations down to TPC_MAX_IO_SIZE, which is 1MB now. 1MB is also not a cookie, but ZFS also can do that for large blocks, so it should be less dramatic. As drawback this increases CPU overhead, but it still look acceptable comparing to time consumed by ZFS read/write.
* MFC r313736: Fix panic on shutdown of ramdisk LU with zero capacity.mav2017-02-211-1/+3
|
* MFC 313895:ken2017-02-201-0/+3
| | | | | | | | | | | | | | | ------------------------------------------------------------------------ r313895 | ken | 2017-02-17 13:15:27 -0700 (Fri, 17 Feb 2017) | 9 lines Make ctl(4) build with CTL_IO_DELAY defined. sys/cam/ctl/ctl.c: In ctl_datamove(), inside CTL_IO_DELAY, add a lun variable and fill it in before trying to dereference it. Sponsored by: Spectra Logic ------------------------------------------------------------------------
* MFC r312694: Make CTL ramdisk backend a real RAM disk.mav2017-02-071-205/+637
| | | | | | | | | | | | | | | | | If "capacity" LU option is set, ramdisk backend now implements featured thin provisioned disk, storing data in malloc(9) allocated memory blocks of pblocksize bytes (default PAGE_SIZE or 4KB). Additionally ~0.2% of LU size is used for indirection tree (bigger pblocksize reduce the overhead). Backend supports all unmap and anchor operations. If configured capacity is overflowed, proper error conditions are reported. If "capacity" LU option is not set, the backend operates mostly the same as before without allocating real storage: writes go to nowhere, reads return zeroes, reporting that all LBAs are unmapped. This backend is still mostly oriented on testing and benchmarking (it is still a volatile RAM disk), but now it should allow to run real FS tests, not only simple dumb dd.
* MFC r312603: Add initial support for CTL module unloading.mav2017-02-0713-196/+264
| | | | | | It is only a first step and not perfect, but better then nothing. The main blocker is CAM target frontend, that can not be unloaded, since CAM does not have mechanism to unregister periph driver now.
* MFC r312348: Remove writing 'residual' field of struct ctl_scsiio.mav2017-02-073-353/+75
| | | | | | | | | | This field has no practical use and never readed. Initiators already receive respective residual size from frontends. Removed field had different semantics, which looks useless, and was never passed through by any frontend. While there, fix kern_data_resid field support in case of HA, missed in r312291.
* MFC r312291, r312669:mav2017-02-0712-196/+122
| | | | | | | | | | | | | | Make CTL frontends report kern_data_resid for under-/overruns. It seems like kern_data_resid was never really implemented. This change finally does it. Now frontends update this field while transferring data, while CTL/backends getting it can more flexibly handle the result. At this point behavior should not change significantly, still reporting errors on write overrun, but that may be changed later, if we decide so. CAM target frontend still does not properly handle overruns due to CAM API limitations. We may need to add some fields to struct ccb_accept_tio to pass information about initiator requested transfer size(s).
* MFC r312343: Improve error message on duplicate iSCSI port.mav2017-02-071-1/+2
|
* MFC r296891 (by imp):mav2017-01-261-0/+7
| | | | | | | Make sure we check for CAM_CDB_POINTER for all drivers. Also, for the drivers I've touched, filter out CAM_CDB_PHYS. Differential Revision: https://reviews.freebsd.org/D5585
* MFC r312232: Add under-/overrun support to IOCTL and CAM SIM frontends.mav2017-01-262-13/+32
|
* MFC r312231: When in kernel, map ctl_scsi_zero_io() to ctl_zero_io().mav2017-01-262-4/+4
|
* MFC r312026: Improve CAM_CDB_POINTER support.mav2017-01-265-29/+18
|
* MFC r311873: Fix malloc(M_WAITOK) under mutex, introduced at r311787.mav2017-01-261-21/+17
|
* MFC r311804: Rewrite CTL statistics in more simple and scalable way.mav2017-01-266-130/+242
| | | | | | | | | | | | | Instead of collecting statistics for each combination of ports and logical units, that consumed ~45KB per LU with present number of ports, collect separate statistics for every port and every logical unit separately, that consume only 176 bytes per each single LU/port. This reduces struct ctl_lun size down to just 6KB. Also new IOCTL API/ABI does not hardcode number of LUs/ports, and should allow handling of very large quantities. Old API is still enabled in stable branches for compatibility reasons.
* MFC r311787: Allocate memory for prevent flags only for removable LUs.mav2017-01-262-5/+12
| | | | | This array takes 64KB of RAM now, that was more then half of struct ctl_lun size. If at some point we support more ports, this may need another tune.
* MFC r311680: Make CTL_GETSTATS ioctl return partial data if buffer is small.mav2017-01-261-12/+9
|
OpenPOWER on IntegriCloud