Reapply, with minor tweaks, r338025, from the original commit:Remove unused and easy to misuse PNP macro parameterInspired by r338025, just remove the element size parameter to theMODULE_PNP_INF
Reapply, with minor tweaks, r338025, from the original commit:Remove unused and easy to misuse PNP macro parameterInspired by r338025, just remove the element size parameter to theMODULE_PNP_INFO macro entirely. The 'table' parameter is now required tohave correct pointer (or array) type. Since all invocations of the macroalready had this property and the emitted PNP data continues to include theelement size, there is no functional change.Mostly done with the coccinelle 'spatch' tool: $ cat modpnpsize0.cocci @normaltables@ identifier b,c; expression a,d,e; declarer MODULE_PNP_INFO; @@ MODULE_PNP_INFO(a,b,c,d, -sizeof(d[0]), e); @singletons@ identifier b,c,d; expression a; declarer MODULE_PNP_INFO; @@ MODULE_PNP_INFO(a,b,c,&d, -sizeof(d), 1); $ rg -l MODULE_PNP_INFO -- sys | \ xargs spatch --in-place --sp-file modpnpsize0.cocci(Note that coccinelle invokes diff(1) via a PATH search and expects diff totolerate the -B flag, which BSD diff does not. So I had to link gdiff intoPATH as diff to use spatch.)Tinderbox'd (-DMAKE_JUST_KERNELS).Approved by: re (glen)
show more ...
Back out r338035 until Warner is finished churning GSoC PNP patchesI was not aware Warner was making or planning to make forward progress inthis area and have since been informed of that.It's ea
Back out r338035 until Warner is finished churning GSoC PNP patchesI was not aware Warner was making or planning to make forward progress inthis area and have since been informed of that.It's easy to apply/reapply when churn dies down.
Remove unused and easy to misuse PNP macro parameterInspired by r338025, just remove the element size parameter to theMODULE_PNP_INFO macro entirely. The 'table' parameter is now required tohave
Remove unused and easy to misuse PNP macro parameterInspired by r338025, just remove the element size parameter to theMODULE_PNP_INFO macro entirely. The 'table' parameter is now required tohave correct pointer (or array) type. Since all invocations of the macroalready had this property and the emitted PNP data continues to include theelement size, there is no functional change.Mostly done with the coccinelle 'spatch' tool: $ cat modpnpsize0.cocci @normaltables@ identifier b,c; expression a,d,e; declarer MODULE_PNP_INFO; @@ MODULE_PNP_INFO(a,b,c,d, -sizeof(d[0]), e); @singletons@ identifier b,c,d; expression a; declarer MODULE_PNP_INFO; @@ MODULE_PNP_INFO(a,b,c,&d, -sizeof(d), 1); $ rg -l MODULE_PNP_INFO -- sys | \ xargs spatch --in-place --sp-file modpnpsize0.cocci(Note that coccinelle invokes diff(1) via a PATH search and expects diff totolerate the -B flag, which BSD diff does not. So I had to link gdiff intoPATH as diff to use spatch.)Tinderbox'd (-DMAKE_JUST_KERNELS).
Add PNP info to the PCI attachment of the aacraid driver.Reviewed by: imp, chuckSubmitted by: Lakhan Shiva Kamireddy <[email protected]>Sponsored by: Google, Inc. (GSoC 2018)
Move most of the contents of opt_compat.h to opt_global.h.opt_compat.h is mentioned in nearly 180 files. In-progress networkdriver compabibility improvements may add over 100 more so this isclose
Move most of the contents of opt_compat.h to opt_global.h.opt_compat.h is mentioned in nearly 180 files. In-progress networkdriver compabibility improvements may add over 100 more so this iscloser to "just about everywhere" than "only some files" per theguidance in sys/conf/options.Keep COMPAT_LINUX32 in opt_compat.h as it is confined to a subset ofsys/compat/linux/*.c. A fake _COMPAT_LINUX option ensure opt_compat.his created on all architectures.Move COMPAT_LINUXKPI to opt_dontuse.h as it is only used to control theset of compiled files.Reviewed by: kib, cem, jhb, jtlSponsored by: DARPA, AFRLDifferential Revision: https://reviews.freebsd.org/D14941
Fix FSACTL_GET_NEXT_ADAPTER_FIB under 32-bit compat.This includes FSACTL_LNX_GET_NEXT_ADAPTER_FIB.Reviewed by: cemObtained from: CheriBSDMFC after: 1 weekSponsored by: DARPA, AFRLDifferential
Fix FSACTL_GET_NEXT_ADAPTER_FIB under 32-bit compat.This includes FSACTL_LNX_GET_NEXT_ADAPTER_FIB.Reviewed by: cemObtained from: CheriBSDMFC after: 1 weekSponsored by: DARPA, AFRLDifferential Revision: https://reviews.freebsd.org/D14672
Revert r327828, r327949, r327953, r328016-r328026, r328041:Uses of mallocarray(9).The use of mallocarray(9) has rocketed the required swap to build FreeBSD.This is likely caused by the allocation
Revert r327828, r327949, r327953, r328016-r328026, r328041:Uses of mallocarray(9).The use of mallocarray(9) has rocketed the required swap to build FreeBSD.This is likely caused by the allocation size attributes which put extra pressureon the compiler.Given that most of these checks are superfluous we have to choose betterwhere to use mallocarray(9). We still have more uses of mallocarray(9) buthopefully this is enough to bring swap usage to a reasonable level.Reported by: woschPR: 225197
dev: make some use of mallocarray(9).Focus on code where we are doing multiplications within malloc(9). None ofthese is likely to overflow, however the change is still useful as somestatic checke
dev: make some use of mallocarray(9).Focus on code where we are doing multiplications within malloc(9). None ofthese is likely to overflow, however the change is still useful as somestatic checkers can benefit from the allocation attributes we use formallocarray.This initial sweep only covers malloc(9) calls with M_NOWAIT. No goodreason but I started doing the changes before r327796 and at that time itwas convenient to make sure the sorrounding code could handle NULL values.
sys/dev: further adoption of SPDX licensing ID tags.Mainly focus on files that use BSD 2-Clause license, however the tool Iwas using misidentified many licenses so this was mostly a manual - error
sys/dev: further adoption of SPDX licensing ID tags.Mainly focus on files that use BSD 2-Clause license, however the tool Iwas using misidentified many licenses so this was mostly a manual - errorprone - task.The Software Package Data Exchange (SPDX) group provides a specificationto make it easier for automated tools to detect and summarize well knownopensource licenses. We are gradually adopting the specification, notingthat the tags are considered only advisory and do not, in any way,superceed or replace the license texts.
Clean up MD pollution of bus_dma.h:--Remove special-case handling of sparc64 bus_dmamap* functions. Replace with a more generic mechanism that allows MD busdma implementations to generate inlin
Clean up MD pollution of bus_dma.h:--Remove special-case handling of sparc64 bus_dmamap* functions. Replace with a more generic mechanism that allows MD busdma implementations to generate inline mapping functions by defining WANT_INLINE_DMAMAP in <machine/bus_dma.h>. This is currently useful for sparc64, x86, and arm64, which all implement non-load dmamap operations as simple wrappers around map objects which may be bus- or device-specific.--Remove NULL-checked bus_dmamap macros. Implement the equivalent NULL checks in the inlined x86 implementation. For non-x86 platforms, these checks are a minor pessimization as those platforms do not currently allow NULL maps. NULL maps were originally allowed on arm64, which appears to have been the motivation behind adding arm[64]-specific barriers to bus_dma.h, but that support was removed in r299463.--Simplify the internal interface used by the bus_dmamap_load* variants and move it to bus_dma_internal.h--Fix some drivers that directly include sys/bus_dma.h despite the recommendations of bus_dma(9)Reviewed by: kib (previous revision), mariusDifferential Revision: https://reviews.freebsd.org/D10729
remove an unrelated local change from r319746MFC after: 1 dayX-MFC with: r319746
MFV r319744,r319745: 8269 dtrace stddev aggregation is normalized incorrectlyillumos/illumos-gate@79809f9cf402f130667349b2d4007ecd65d63c6fhttps://github.com/illumos/illumos-gate/commit/79809f9cf40
MFV r319744,r319745: 8269 dtrace stddev aggregation is normalized incorrectlyillumos/illumos-gate@79809f9cf402f130667349b2d4007ecd65d63c6fhttps://github.com/illumos/illumos-gate/commit/79809f9cf402f130667349b2d4007ecd65d63c6fhttps://www.illumos.org/issues/8269 It seems that currently normalization of stddev aggregation is done incorrectly. We divide both the sum of values and the sum of their squares by the normalization factor. But we should divide the sum of squares by the normalization factor squared to scale the original values properly.FreeBSD note: the actual change was committed in r316853, this commitadds the test files and record merge information.Reviewed by: Bryan Cantrill <[email protected]>Approved by: Robert Mustacchi <[email protected]>Author: Andriy Gapon <[email protected]>MFC after: 1 weekSponsored by: Panzura
aacraid: rework r315083 for a clean build with and without AACRAID_DEBUGr315083 essentially reverted r263954 which was made for a good reason,but didn't take into account AACRAID_DEBUG.Now both t
aacraid: rework r315083 for a clean build with and without AACRAID_DEBUGr315083 essentially reverted r263954 which was made for a good reason,but didn't take into account AACRAID_DEBUG.Now both types of build should be clean.MFC after: 5 daysNo MFC to: stable/10
aacraid: fix build with AACRAID_DEBUG=2MFC after: 10 days
Always null-terminate ccb_pathinq.(sim_vid|hba_vid|dev_name)The sim_vid, hba_vid, and dev_name fields of struct ccb_pathinq arefixed-length strings. AFAICT the only place they're read is insbin/c
Always null-terminate ccb_pathinq.(sim_vid|hba_vid|dev_name)The sim_vid, hba_vid, and dev_name fields of struct ccb_pathinq arefixed-length strings. AFAICT the only place they're read is insbin/camcontrol/camcontrol.c, which assumes they'll be null-terminated.However, the kernel doesn't null-terminate them. A bunch of copy-pasted codeuses strncpy to write them, and doesn't guarantee null-termination. For atleast 4 drivers (mpr, mps, ciss, and hyperv), the hba_vid field actuallyoverflows. You can see the result by doing "camcontrol negotiate da0 -v".This change null-terminates those fields everywhere they're set in thekernel. It also shortens a few strings to ensure they'll fit within the16-character field.PR: 215474Reported by: CoverityCID: 1009997 1010000 1010001 1010002 1010003 1010004 1010005CID: 1331519 1010006 1215097 1010007 1288967 1010008 1306000CID: 1211924 1010009 1010010 1010011 1010012 1010013 1010014CID: 1147190 1010017 1010016 1010018 1216435 1010020 1010021CID: 1010022 1009666 1018185 1010023 1010025 1010026 1010027CID: 1010028 1010029 1010030 1010031 1010033 1018186 1018187CID: 1010035 1010036 1010042 1010041 1010040 1010039Reviewed by: imp, sephe, slmMFC after: 4 weeksSponsored by: Spectra Logic CorpDifferential Revision: https://reviews.freebsd.org/D9037Differential Revision: https://reviews.freebsd.org/D9038
Remove a PCI ID for a raid controller from Adaptec that was planned,but never released. Since no real hardware was released with this ID,just drop it from the aacraid driver. This paves the path fo
Remove a PCI ID for a raid controller from Adaptec that was planned,but never released. Since no real hardware was released with this ID,just drop it from the aacraid driver. This paves the path for futuredrivers for hardware that actually has this ID.Submitted by: Scott Benesh from Microsemi.Differential Revision: https://reviews.freebsd.org/D8377MFC After: 3 days
sys/dev: minor spelling fixes.Most affect comments, very few have user-visible effects.
aacraid(4): Fix some mostly trivial buffer overrunsstrcpy(3) emits a trailing nul byte, trampling fields after the intendeddestination. Instead, use strncpy(3), intentionally leaving these fields
aacraid(4): Fix some mostly trivial buffer overrunsstrcpy(3) emits a trailing nul byte, trampling fields after the intendeddestination. Instead, use strncpy(3), intentionally leaving these fieldsnot nul-terminated.Reported by: CoverityCIDs: 1031024, 1305463, 1305494, 1305545Sponsored by: EMC / Isilon Storage Division
aacraid(4): Sanely copyin userland pointers and ensure that we don't getanything janky from a user. (cturt)aac(4): [email protected] pointed out that aacraid(4)had the same
aacraid(4): Sanely copyin userland pointers and ensure that we don't getanything janky from a user. (cturt)aac(4): [email protected] pointed out that aacraid(4)had the same issue and handling of pointers, so let's change that too.PR: 206573Submitted by: [email protected]Obtained from: HardenedBSDMFC after: 1 week
Cleanup unnecessary semicolons from the kernel.Found with devel/coccinelle.
Migrate many bus_alloc_resource() calls to bus_alloc_resource_anywhere().Most calls to bus_alloc_resource() use "anywhere" as the range, with a givencount. Migrate these to use the new bus_alloc_
Migrate many bus_alloc_resource() calls to bus_alloc_resource_anywhere().Most calls to bus_alloc_resource() use "anywhere" as the range, with a givencount. Migrate these to use the new bus_alloc_resource_anywhere() API.Reviewed by: jhbDifferential Revision: https://reviews.freebsd.org/D5370
Remove MAXBSIZE use from drivers where it has nothing to do.In some cases limits are just not needed, in others -- DFLTPHYS is theright constant to use instead.MFC after: 1 month
Remove instances of variables that were set, but never used. gcc 4.9warns about these by default.
Update kernel inclusions of capability.h to use capsicum.h instead; somefurther refinement is required as some device drivers intended to beportable over FreeBSD versions rely on __FreeBSD_version
Update kernel inclusions of capability.h to use capsicum.h instead; somefurther refinement is required as some device drivers intended to beportable over FreeBSD versions rely on __FreeBSD_version to decide whetherto include capability.h.MFC after: 3 weeks
Wrap this debug statement in debug defines. Else, this driverwill refuse to load.MFC after: 2 weeksSponsored by: Yahoo! Inc.
12