Fix insufficient oce(4) ioctl(2) privilege checking.Approved by: soSecurity: FreeBSD-SA-20:05.if_oce_ioctlSecurity: CVE-2019-15876
MFC r350630, r350657: static analysis fixes from Haikur350630:oce(4): potential out of bounds access before vector validationr350657:ral: rt2860: fix wcid2ni access/size issueRT2860_WCID_MAX
MFC r350630, r350657: static analysis fixes from Haikur350630:oce(4): potential out of bounds access before vector validationr350657:ral: rt2860: fix wcid2ni access/size issueRT2860_WCID_MAX is supposed to describe the max STA index for wcid2ni, andwas instead being used as the size -- off-by-one.rt2860_drain_stats_fifo was range-checking wcid only after accessingout-of-bounds potentially.
show more ...
MFC r348332: Fix array out of bound panic introduced in r306219.As I see, different NICs in different configurations may have differentnumbers of TX and RX queues. The code was assuming 1:1 mappi
MFC r348332: Fix array out of bound panic introduced in r306219.As I see, different NICs in different configurations may have differentnumbers of TX and RX queues. The code was assuming 1:1 mapping betweenevent queues (interrupts) and TX/RX queues. Since number of interruptsis set to maximum of TX and RX queues, when those two are different, thesystem is doomed.I have no documentation or deep knowledge about this hardware, so thischange is based on general observations and code reading. If some of myguesses are wrong, please do better. I just confirmed HP NC550SFP NICsare working now.
MFC r342856: Added support for the SIOCGI2C ioctl.Submitted by: Ram Kishore Vegesna <[email protected]>Obtained from: Broadcom
Add PNP info to PCI attachments of cbb, cxgb, ida, iwn, ixl, ixlv,mfi, mps, mpr, mvs, my, oce, pcn, ral, rl. This only labels existingpci device tables, and has no probe / attach code changes.Rev
Add PNP info to PCI attachments of cbb, cxgb, ida, iwn, ixl, ixlv,mfi, mps, mpr, mvs, my, oce, pcn, ral, rl. This only labels existingpci device tables, and has no probe / attach code changes.Reviewed by: imp, chuckSubmitted by: Lakhan Shiva Kamireddy <[email protected]>Sponsored by: Google, Inc. (GSoC 2018)Approved by: re (glen)
ifnet: Replace if_addr_lock rwlock with epoch + mutexRun on LLNW canaries and tested by pho@gallatin:Using a 14-core, 28-HTT single socket E5-2697 v3 with a 40GbE MLX5based ConnectX 4-LX NIC, I
ifnet: Replace if_addr_lock rwlock with epoch + mutexRun on LLNW canaries and tested by pho@gallatin:Using a 14-core, 28-HTT single socket E5-2697 v3 with a 40GbE MLX5based ConnectX 4-LX NIC, I see an almost 12% improvement in receivedpacket rate, and a larger improvement in bytes delivered all the wayto userspace.When the host receiving 64 streams of netperf -H $DUT -t UDP_STREAM -- -m 1,I see, using nstat -I mce0 1 before the patch:InMpps OMpps InGbs OGbs err TCP Est %CPU syscalls csw irq GBfree4.98 0.00 4.42 0.00 4235592 33 83.80 4720653 2149771 1235 247.324.73 0.00 4.20 0.00 4025260 33 82.99 4724900 2139833 1204 247.324.72 0.00 4.20 0.00 4035252 33 82.14 4719162 2132023 1264 247.324.71 0.00 4.21 0.00 4073206 33 83.68 4744973 2123317 1347 247.324.72 0.00 4.21 0.00 4061118 33 80.82 4713615 2188091 1490 247.324.72 0.00 4.21 0.00 4051675 33 85.29 4727399 2109011 1205 247.324.73 0.00 4.21 0.00 4039056 33 84.65 4724735 2102603 1053 247.32After the patchInMpps OMpps InGbs OGbs err TCP Est %CPU syscalls csw irq GBfree5.43 0.00 4.20 0.00 3313143 33 84.96 5434214 1900162 2656 245.515.43 0.00 4.20 0.00 3308527 33 85.24 5439695 1809382 2521 245.515.42 0.00 4.19 0.00 3316778 33 87.54 5416028 1805835 2256 245.515.42 0.00 4.19 0.00 3317673 33 90.44 5426044 1763056 2332 245.515.42 0.00 4.19 0.00 3314839 33 88.11 5435732 1792218 2499 245.525.44 0.00 4.19 0.00 3293228 33 91.84 5426301 1668597 2121 245.52Similarly, netperf reports 230Mb/s before the patch, and 270Mb/s after the patchReviewed by: gallatinSponsored by: Limelight NetworksDifferential Revision: https://reviews.freebsd.org/D15366
Add ability to perform a firmware reset during driver initialization.Required by Lancer Gen 5 hardware.Submitted by: Ram Kishore Vegesna <[email protected]>Obtained from: Broadcom
Use an accessor function to access ifr_data.This fixes 32-bit compat (no ioctl command defintions are requiredas struct ifreq is the same size). This is believed to be sufficent tofully support
Use an accessor function to access ifr_data.This fixes 32-bit compat (no ioctl command defintions are requiredas struct ifreq is the same size). This is believed to be sufficent tofully support ifconfig on 32-bit systems.Reviewed by: kibObtained from: CheriBSDMFC after: 1 weekRelnotes: yesSponsored by: DARPA, AFRLDifferential Revision: https://reviews.freebsd.org/D14900
sys/dev: further adoption of SPDX licensing ID tags.Mainly focus on files that use BSD 3-Clause license.The Software Package Data Exchange (SPDX) group provides a specificationto make it easier
sys/dev: further adoption of SPDX licensing ID tags.Mainly focus on files that use BSD 3-Clause license.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.Special thanks to Wind River for providing access to "The Duke ofHighlander" tool: an older (2014) run over FreeBSD tree was useful as astarting point.
Update oce to version 11.0.50.0Submitted by: Venkat Duvvuru <[email protected]>
Revert r306148 to fix buildRequested by: jpaetzelReported by: Larry Rosenman <ler at lerctr.org>, Jenkins
Update oce driver to 11.0.50.0Submitted by: Venkat Duvvuru <[email protected]>
Cleanup unnecessary semicolons from the kernel.Found with devel/coccinelle.
tcp/lro: Use tcp_lro_flush_all in device drivers to avoid code duplicationAnd factor out tcp_lro_rx_done, which deduplicates the same logic withnetinet/tcp_lro.cReviewed by: gallatin (1st versio
tcp/lro: Use tcp_lro_flush_all in device drivers to avoid code duplicationAnd factor out tcp_lro_rx_done, which deduplicates the same logic withnetinet/tcp_lro.cReviewed by: gallatin (1st version), hps, zbb, np, Dexuan Cui <decui microsoft com>Sponsored by: Microsoft OSTCDifferential Revision: https://reviews.freebsd.org/D5725
Remove taskqueue_enqueue_fast().taskqueue_enqueue() was changed to support both fast and non-fasttaskqueues 10 years ago in r154167. It has been a compat shim eversince. It's time for the compa
Remove taskqueue_enqueue_fast().taskqueue_enqueue() was changed to support both fast and non-fasttaskqueues 10 years ago in r154167. It has been a compat shim eversince. It's time for the compat shim to go.Submitted by: Howard Su <[email protected]>Reviewed by: sepheDifferential Revision: https://reviews.freebsd.org/D5131
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
These files were getting sys/malloc.h and vm/uma.h with header pollutionvia sys/mbuf.h
CALLOUT_MPSAFE has lost its meaning since r141428, i.e., for more than tenyears for head. However, it is continuously misused as the mpsafe argumentfor callout_init(9). Deprecate the flag and cle
CALLOUT_MPSAFE has lost its meaning since r141428, i.e., for more than tenyears for head. However, it is continuously misused as the mpsafe argumentfor callout_init(9). Deprecate the flag and clean up callout_init() callsto make them more consistent.Differential Revision: https://reviews.freebsd.org/D2613Reviewed by: jhbMFC after: 2 weeks
srandom has no influence on read_random, at least not this late...
Start process of removing the use of the deprecated "M_FLOWID" flagfrom the FreeBSD network code. The flag is still kept around in the"sys/mbuf.h" header file, but does no longer have any users. In
Start process of removing the use of the deprecated "M_FLOWID" flagfrom the FreeBSD network code. The flag is still kept around in the"sys/mbuf.h" header file, but does no longer have any users. Insteadthe "m_pkthdr.rsstype" field in the mbuf structure is now used todecide the meaning of the "m_pkthdr.flowid" field. To modify the"m_pkthdr.rsstype" field please use the existing "M_HASHTYPE_XXX"macros as defined in the "sys/mbuf.h" header file.This patch introduces new behaviour in the transmit direction.Previously network drivers checked if "M_FLOWID" was set in "m_flags"before using the "m_pkthdr.flowid" field. This check has now now beenreplaced by checking if "M_HASHTYPE_GET(m)" is different from"M_HASHTYPE_NONE". In the future more hashtypes will be added, forexample hashtypes for hardware dedicated flows."M_HASHTYPE_OPAQUE" indicates that the "m_pkthdr.flowid" value isvalid and has no particular type. This change removes the need for an"if" statement in TCP transmit code checking for the presence of avalid flowid value. The "if" statement mentioned above is now a directvariable assignment which is then later checked by the respectivenetwork drivers like before.Additional notes:- The SCTP code changes will be committed as a separate patch.- Removal of the "M_FLOWID" flag will also be done separately.- The FreeBSD version has been bumped.MFC after: 1 monthSponsored by: Mellanox Technologies
Fix multiple incorrect SYSCTL arguments in the kernel:- Wrong integer type was specified.- Wrong or missing "access" specifier. The "access" specifiersometimes included the SYSCTL type, which it
Fix multiple incorrect SYSCTL arguments in the kernel:- Wrong integer type was specified.- Wrong or missing "access" specifier. The "access" specifiersometimes included the SYSCTL type, which it should not, except forprocedural SYSCTL nodes.- Logical OR where binary OR was expected.- Properly assert the "access" argument passed to all SYSCTL macros,using the CTASSERT macro. This applies to both static- and dynamicallycreated SYSCTLs.- Properly assert the the data type for both static and dynamicSYSCTLs. In the case of static SYSCTLs we only assert that the datapointed to by the SYSCTL data pointer has the correct size, hencethere is no easy way to assert types in the C language outside aC-function.- Rewrote some code which doesn't pass a constant "access" specifierwhen creating dynamic SYSCTL nodes, which is now a requirement.- Updated "EXAMPLES" section in SYSCTL manual page.MFC after: 3 daysSponsored by: Mellanox Technologies
Improve transmit sending offload, TSO, algorithm in general.The current TSO limitation feature only takes the total number ofbytes in an mbuf chain into account and does not limit by the numberof
Improve transmit sending offload, TSO, algorithm in general.The current TSO limitation feature only takes the total number ofbytes in an mbuf chain into account and does not limit by the numberof mbufs in a chain. Some kinds of hardware is limited by twofactors. One is the fragment length and the second is the fragmentcount. Both of these limits need to be taken into account when doingTSO. Else some kinds of hardware might have to drop completely validmbuf chains because they cannot loaded into the given hardware's DMAengine. The new way of doing TSO limitation has been made backwardscompatible as input from other FreeBSD developers and will usedefaults for values not set.Reviewed by: adrian, rmacklemSponsored by: Mellanox TechnologiesMFC after: 1 week
Mechanically convert to if_inc_counter().
Revert r271504. A new patch to solve this issue will be made.Suggested by: adrian @
Improve transmit sending offload, TSO, algorithm in general.The current TSO limitation feature only takes the total number ofbytes in an mbuf chain into account and does not limit by the numberof mbufs in a chain. Some kinds of hardware is limited by twofactors. One is the fragment length and the second is the fragmentcount. Both of these limits need to be taken into account when doingTSO. Else some kinds of hardware might have to drop completely validmbuf chains because they cannot loaded into the given hardware's DMAengine. The new way of doing TSO limitation has been made backwardscompatible as input from other FreeBSD developers and will usedefaults for values not set.MFC after: 1 weekSponsored by: Mellanox Technologies
123