FreeBSD source tree https://cgit-dev.freebsd.org/src-test2/atom?h=release%2F11.3.0 2018-03-29T02:50:57Z 2018-03-29T02:50:57Z Eitan Adler eadler@FreeBSD.org 2018-03-29T02:50:57Z urn:sha1:4ab2e064d7950be84256d671a7ae93f87cc6aa36 This was intended to be a non-functional change. It wasn't. The commit message was thus wrong. In addition it broke arm, and merged crypto related code. Revert with prejudice. This revert skips files touched in r316370 since that commit was since MFCed. This revert also skips files that require $FreeBSD$ property changes. Thank you to those who helped me get out of this mess including but not limited to gonzo, kevans, rgrimes. Requested by: gjb (re) 2018-03-14T03:19:51Z Eitan Adler eadler@FreeBSD.org 2018-03-14T03:19:51Z urn:sha1:be5d0b9566b13fdf8cabebb63334cbec12bfc409 These changes are incomplete but are making it difficult to determine what other changes can/should be merged. No objections from: pfg 2015-01-12T07:37:06Z Pyun YongHyeon yongari@FreeBSD.org 2015-01-12T07:37:06Z urn:sha1:8e5e237669840d943196aff94aa4fc476cbc9628 While I'm here add a check for driver running state for multicast filter handling. Suggested by: brad@OpenBSD.org 2014-12-16T06:13:30Z Pyun YongHyeon yongari@FreeBSD.org 2014-12-16T06:13:30Z urn:sha1:e01343ccd72bf1a09cee54dc2bf805fc14a24023 sheet, RX filter should be disabled before programming. Previously it was clearing wrong bits so RX filter was not disabled in RX filter configuration. Reported by: brad@OpenBSD.org 2014-09-18T20:09:35Z Gleb Smirnoff glebius@FreeBSD.org 2014-09-18T20:09:35Z urn:sha1:e1ed7fe8b101c12ebe351f1b06a2b7b9a8d2bf23 2014-08-30T19:55:54Z Gleb Smirnoff glebius@FreeBSD.org 2014-08-30T19:55:54Z urn:sha1:1bffa9511fe94125820858b0ead796db54ac019d that resides in struct ifnet. Sponsored by: Nginx, Inc. 2014-06-28T03:56:17Z Hans Petter Selasky hselasky@FreeBSD.org 2014-06-28T03:56:17Z urn:sha1:af3b2549c4ba2ef00a7cbb4cb6836598bf0aefbe 2014-06-27T22:05:21Z Glen Barber gjb@FreeBSD.org 2014-06-27T22:05:21Z urn:sha1:37a107a407cdb47ee0f4c4337e369e9973b34076 These changes prevent sysctl(8) from returning proper output, such as: 1) no output from sysctl(8) 2) erroneously returning ENOMEM with tools like truss(1) or uname(1) truss: can not get etype: Cannot allocate memory 2014-06-27T16:33:43Z Hans Petter Selasky hselasky@FreeBSD.org 2014-06-27T16:33:43Z urn:sha1:3da1cf1e88f8448bb10c5f778ab56ff65c7a6938 there is an environment variable which shall initialize the SYSCTL during early boot. This works for all SYSCTL types both statically and dynamically created ones, except for the SYSCTL NODE type and SYSCTLs which belong to VNETs. A new flag, CTLFLAG_NOFETCH, has been added to be used in the case a tunable sysctl has a custom initialisation function allowing the sysctl to still be marked as a tunable. The kernel SYSCTL API is mostly the same, with a few exceptions for some special operations like iterating childrens of a static/extern SYSCTL node. This operation should probably be made into a factored out common macro, hence some device drivers use this. The reason for changing the SYSCTL API was the need for a SYSCTL parent OID pointer and not only the SYSCTL parent OID list pointer in order to quickly generate the sysctl path. The motivation behind this patch is to avoid parameter loading cludges inside the OFED driver subsystem. Instead of adding special code to the OFED driver subsystem to post-load tunables into dynamically created sysctls, we generalize this in the kernel. Other changes: - Corrected a possibly incorrect sysctl name from "hw.cbb.intr_mask" to "hw.pcic.intr_mask". - Removed redundant TUNABLE statements throughout the kernel. - Some minor code rewrites in connection to removing not needed TUNABLE statements. - Added a missing SYSCTL_DECL(). - Wrapped two very long lines. - Avoid malloc()/free() inside sysctl string handling, in case it is called to initialize a sysctl from a tunable, hence malloc()/free() is not ready when sysctls from the sysctl dataset are registered. - Bumped FreeBSD version to indicate SYSCTL API change. MFC after: 2 weeks Sponsored by: Mellanox Technologies 2014-06-11T14:53:58Z John Baldwin jhb@FreeBSD.org 2014-06-11T14:53:58Z urn:sha1:068d8643adb13434b57fdd5febf43a11194d508f In particular, don't check the value of the bus_dma map against NULL to determine if either bus_dmamem_alloc() or bus_dmamap_load() succeeded. Instead, assume that bus_dmamap_load() succeeeded (and thus that bus_dmamap_unload() should be called) if the bus address for a resource is non-zero, and assume that bus_dmamem_alloc() succeeded (and thus that bus_dmamem_free() should be called) if the virtual address for a resource is not NULL. In many cases these bugs could result in leaks when a driver was detached. Reviewed by: yongari MFC after: 2 weeks