FreeBSD source tree https://cgit-dev.freebsd.org/src-test2/atom?h=master 2020-09-01T22:07:37Z 2020-09-01T22:07:37Z Mateusz Guzik mjg@FreeBSD.org 2020-09-01T22:07:37Z urn:sha1:5ef3520a3397d39828849171dbf460f9aea788bd 2020-04-18T02:53:04Z Warner Losh imp@FreeBSD.org 2020-04-18T02:53:04Z urn:sha1:5b18755735f964e02e22e0a223dfe935f7e06f4b 2018-08-21T10:08:12Z John Baldwin jhb@FreeBSD.org 2018-08-21T10:08:12Z urn:sha1:3b27d79c2a2bde3e729a2a0fe35b51c6c8ccd4c2 The driver already has mutex locking and holds its per-softc lock across calls to the one function that still used splcam(). 2017-11-27T14:52:40Z Pedro F. Giffuni pfg@FreeBSD.org 2017-11-27T14:52:40Z urn:sha1:718cf2ccb9956613756ab15d7a0e28f2c8e91cab Mainly focus on files that use BSD 2-Clause license, however the tool I was using misidentified many licenses so this was mostly a manual - error prone - task. The Software Package Data Exchange (SPDX) group provides a specification to make it easier for automated tools to detect and summarize well known opensource licenses. We are gradually adopting the specification, noting that the tags are considered only advisory and do not, in any way, superceed or replace the license texts. 2017-08-08T17:49:57Z John Baldwin jhb@FreeBSD.org 2017-08-08T17:49:57Z urn:sha1:d081dfc7cd467d2d29473aa5603db1f39f1d8511 If mly_user_command fails to allocate a command slot it jumps to an 'out' label used for error handling. The error handling code checks for a data buffer in 'mc->mc_data' to free before checking if 'mc' is NULL. Fix by just returning directly if we fail to allocate a command and only using the 'out' label for subsequent errors when there is actual cleanup to perform. PR: 217747 Reported by: PVS-Studio Reviewed by: emaste MFC after: 1 week 2017-01-05T03:08:57Z Ravi Pokala rpokala@FreeBSD.org 2017-01-05T03:08:57Z urn:sha1:d3c06026c2bac2ca95e210400df2d0002c735d9a several more drivers. Sponsored by: Panasas 2017-01-04T20:26:42Z Alan Somers asomers@FreeBSD.org 2017-01-04T20:26:42Z urn:sha1:4195c7de2471d6212744bcbf128d659e94801d17 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 Reviewed by: imp, sephe, slm MFC after: 4 weeks Sponsored by: Spectra Logic Corp Differential Revision: https://reviews.freebsd.org/D9037 Differential Revision: https://reviews.freebsd.org/D9038 2016-05-03T03:41:25Z Pedro F. Giffuni pfg@FreeBSD.org 2016-05-03T03:41:25Z urn:sha1:453130d9bfc1c6d68b366dfcb041689d69f81295 Most affect comments, very few have user-visible effects. 2015-03-22T16:10:28Z Alexander Motin mav@FreeBSD.org 2015-03-22T16:10:28Z urn:sha1:6f954fb36b28550c58678125b289ae80ea4d7089 In some cases limits are just not needed, in others -- DFLTPHYS is the right constant to use instead. MFC after: 1 month 2014-11-18T21:55:50Z John Baldwin jhb@FreeBSD.org 2014-11-18T21:55:50Z urn:sha1:caddd60abd10124e93c4dd27471567bc26dc4ee0 - Add a per-softc mutex. - Use mutex as CAM sim lock. - Use taskqueue_thread instead of taskqueue_swi_giant. - Use callout(9) instead of timeout(9). - Use bus_*() instead of bus_space_*(). Tested by: no one