{"shas":[["60b3c51a474342be2a44e9e6191e343ec80a30e2","a454492e42fd9810e577ebee548c7e59bd883bca@ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f","In init_dynamic_kenv(), ignore environment strings exceeding the\nKENV_MNAMELEN + 1 + KENV_MVALLEN + 1 length limit to avoid buffer\noverflow in getenv(). Currenly loader(8) doesn't limit the length of\nenvironment strings.\n\nPR:\t\tkern/132104\nMFC after:\t1 month\n\n\ngit-svn-id: svn+ssh://svn.freebsd.org/base/head@222216 ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f","jh"],["95d524238c078d0d0066f26c147cd4098b53ba84","b302c7c05c763bc48575273e37ed69e0b3ea6fc0@ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f","Continue to refine inpcb reference counting and locking, in preparation for\nreworking of inpcbinfo locking:\n\n(1) Convert inpcb reference counting from manually manipulated integers to\n    the refcount(9) KPI.  This allows the refcount to be managed atomically\n    with an inpcb read lock rather than write lock, or even with no inpcb\n    lock at all.  As a result, in_pcbref() also no longer requires an inpcb\n    lock, so can be performed solely using the lock used to look up an\n    inpcb.\n\n(2) Shift more inpcb freeing activity from the in_pcbrele() context (via\n    in_pcbfree_internal) to the explicit in_pcbfree() context.  This means\n    that the inpcb refcount is increasingly used only to maintain memory\n    stability, not actually defer the clean up of inpcb protocol parts.\n    This is desirable as many of those protocol parts required the pcbinfo\n    lock, which we'd like not to acquire in in_pcbrele() contexts.  Document\n    this in comments better.\n\n(3) Introduce new read-locked and write-locked in_pcbrele() variations,\n    in_pcbrele_rlocked() and in_pcbrele_wlocked(), which allow the inpcb to\n    be properly unlocked as needed.  in_pcbrele() is a wrapper around the\n    latter, and should probably go away at some point.  This makes it\n    easier to use this weak reference model when holding only a read lock,\n    as will happen in the future.\n\nThis may well be safe to MFC, but some more KBI analysis is required.\n\nReviewed by:    bz\nMFC after:      3 weeks\nSponsored by:   Juniper Networks, Inc.\n\n\ngit-svn-id: svn+ssh://svn.freebsd.org/base/head@222217 ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f","rwatson"],["5b378b540d7aa19bad4c7209d63f7dbb5ac565c4","67b8b1c4fedb2e38e2eb26f403b9c2b2642b0a2c@ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f","expr -> sh arithmetic expansion\n\n\ngit-svn-id: svn+ssh://svn.freebsd.org/base/head@222218 ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f","ru"],["ce3c738fe22fba49f5117a87cf5f545119c933b6","79c7d24101a3af56696b485dbd1362edab3b7da5@ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f","Do not blindly clear entire GPHY control register. It seems some\nbits of the register is used for other purposes such that clearing\nthese bits resulted in unexpected results such as corrupted RX\nframes or missing LE status updates.  For old controllers like\nYukon EC it had no effect but it caused all kind of troubles on\nYukon Supreme.\nThis change shall improve stability of controllers like Yukon\nUltra, Ultra2, Extreme, Optima and Supreme.\n\n\ngit-svn-id: svn+ssh://svn.freebsd.org/base/head@222219 ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f","yongari"],["235e5e7d32e946cd37a44e478a3531eb806f6a28","67b8b1c4fedb2e38e2eb26f403b9c2b2642b0a2c@ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f","BKVASIZE was bumped to 16k more than a decade ago.\n\n\ngit-svn-id: svn+ssh://svn.freebsd.org/base/head@222220 ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f","ru"]],"repo":"arundel/FreeBSD-git","actor":"arundel","ref":"refs/heads/master","size":5,"head":"235e5e7d32e946cd37a44e478a3531eb806f6a28","actor_gravatar":"9f1a05a2dbcd1250eb2a4e344d490d5c","push_id":32088772}