Date: Tue, 24 May 2016 02:23:42 +0000 (GMT) From: jenkins-admin@FreeBSD.org To: adrian@FreeBSD.org, allanjude@FreeBSD.org, truckman@FreeBSD.org, asomers@FreeBSD.org, jenkins-admin@FreeBSD.org, freebsd-current@FreeBSD.org, freebsd-i386@FreeBSD.org Subject: FreeBSD_HEAD_i386 - Build #3186 - Fixed Message-ID: <1702050976.7.1464056625759.JavaMail.jenkins@jenkins-9.freebsd.org> In-Reply-To: <85571445.5.1464048574788.JavaMail.jenkins@jenkins-9.freebsd.org> References: <85571445.5.1464048574788.JavaMail.jenkins@jenkins-9.freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
FreeBSD_HEAD_i386 - Build #3186 - Fixed: Build information: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_i386/3186/ Full change log: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_i386/3186/changes Full build log: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_i386/3186/console Change summaries: 300548 by adrian: [bhnd] Implement pass-through resource management for ChipCommon. This patchset adds support to bhnd_chipc for sharing SYS_RES_MEMORY resources with its children, allowing us to hang devices off of bhnd_chipc that rely on access to a subset of the device register space that bhnd_chipc itself must also allocate. We could avoid most of this heavy lifting if RF_SHAREABLE+SYS_RES_MEMORY wasn't limited to use with allocations at the same size/offset. As a work-around, I implemented something similar to vga_pci.c, which implements similar reference counting of of PCI BAR resources for its children. With these changes, chipc will use reference counting of SYS_RES_MEMORY allocation/activation requests, to decide when to allocate/activate/ deactivate/release resources from the parent bhnd(4) bus. The requesting child device is allocated a new resource from chipc's rman, pointing to (possibly a subregion of) the refcounted bhnd resources allocated by chipc. Other resource types are just passed directly to the parent bhnd bus; RF_SHAREABLE works just fine with IRQs. I also lifted the SPROM device code out into a common driver, since this now allows me to hang simple subclasses off of a common driver off of both bhndb_pci and bhnd_chipc. Tested: * (landonf) Tested against BCM4331 and BCM4312, confirmed that SPROM still attaches and can be queried. Submitted by: Landon Fuller <landonf@landonf.org> Reviewed by: mizkha@gmail.com Differential Revision: https://reviews.freebsd.org/D6471 300547 by truckman: Fix multiple Coverity Out-of-bounds access false postive issues in CAM The currently used idiom for clearing the part of a ccb after its header generates one or two Coverity errors for each time it is used. All instances generate an Out-of-bounds access (ARRAY_VS_SINGLETON) error because of the treatment of the header as a two element array, with a pointer to the non-existent second element being passed as the starting address to bzero(). Some instances also alsp generate Out-of-bounds access (OVERRUN) errors, probably because the space being cleared is larger than the sizeofstruct ccb_hdr). In addition, this idiom is difficult for humans to understand and it is error prone. The user has to chose the proper struct ccb_* type (which does not appear in the surrounding code) for the sizeof() in the length calculation. I found several instances where the length was incorrect, which could cause either an actual out of bounds write, or incompletely clear the ccb. A better way is to write the code to clear the ccb itself starting at sizeof(ccb_hdr) bytes from the start of the ccb, and calculate the length based on the specific type of struct ccb_* being cleared as specified by the union ccb member being used. The latter can normally be seen in the nearby code. This is friendlier for Coverity and other static analysis tools because they will see that the intent is to clear the trailing part of the ccb. Wrap all of the boilerplate code in a convenient macro that only requires a pointer to the desired union ccb member (or a pointer to the union ccb itself) as an argument. Reported by: Coverity CID: 1007578, 1008684, 1009724, 1009773, 1011304, 1011306 CID: 1011307, 1011308, 1011309, 1011310, 1011311, 1011312 CID: 1011313, 1011314, 1011315, 1011316, 1011317, 1011318 CID: 1011319, 1011320, 1011321, 1011322, 1011324, 1011325 CID: 1011326, 1011327, 1011328, 1011329, 1011330, 1011374 CID: 1011390, 1011391, 1011392, 1011393, 1011394, 1011395 CID: 1011396, 1011397, 1011398, 1011399, 1011400, 1011401 CID: 1011402, 1011403, 1011404, 1011405, 1011406, 1011408 CID: 1011409, 1011410, 1011411, 1011412, 1011413, 1011414 CID: 1017461, 1018387, 1086860, 1086874, 1194257, 1229897 CID: 1229968, 1306229, 1306234, 1331282, 1331283, 1331294 CID: 1331295, 1331535, 1331536, 1331539, 1331540, 1341623 CID: 1341624, 1341637, 1341638, 1355264, 1355324 Reviewed by: scottl, ken, delphij, imp MFH: 1 month Differential Revision: https://reviews.freebsd.org/D6496 300546 by allanjude: Only set kern.geom.part.mbr.enforce_chs=0 once, instead of once per disk Sponsored by: ScaleEngine Inc. 300545 by allanjude: Add support for RAID 1+0 (striped mirrors) to bsdinstall/zfsboot Sponsored by: ScaleEngine Inc. 300544 by asomers: Fix build of kern/subr_unit.c, broken by r300539 Reported by: peter Pointyhat to: asomers Sponsored by: Spectra Logic Corp
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1702050976.7.1464056625759.JavaMail.jenkins>