FreeBSD source tree https://cgit-dev.freebsd.org/src/atom?h=stable%2F13 2023-08-23T17:43:26Z 2023-08-23T17:43:26Z Warner Losh imp@FreeBSD.org 2023-08-22T01:31:41Z urn:sha1:3d497e17ebd33fe0f58d773e35ab994d750258d6 Remove /^[\s*]*__FBSDID\("\$FreeBSD\$"\);?\s*\n/ Similar commit in main: (cherry picked from commit 1d386b48a555) 2022-01-13T07:56:00Z Emmanuel Vadot manu@FreeBSD.org 2021-12-09T14:46:39Z urn:sha1:4003cdd81b8776cb451395ffa53423ad52328bc9 getsecs is very costly, reuse the values we got before. Fetching a ~30MB kernel with the tftp command use to take ~26 seconds and now it's ~18 seconds. Reviewed by: imp, tsoome MFC after: 2 weeks Sponsored by: Beckhoff Automation GmbH & Co. KG Differential Revision: https://reviews.freebsd.org/D33408 (cherry picked from commit c5f24f5e0db24c8e33e6278a4fbb7e68364ca18d) 2018-12-20T19:27:46Z Rebecca Cran bcran@FreeBSD.org 2018-12-20T19:27:46Z urn:sha1:d5cee48f3e65662051e15c85e4fc1841d72977fe The reason for this change is that currently, a send/recv takes many hours to time out. This is suboptimal in the bootloader because it means for example that NFS will take hours to fail before allowing subsequent access methods such as gzip to be tried. Setting MAXWAIT to 300 seconds (5 minutes) still allows slow connections of 1Mb to be used to download a 30MB kernel file. Sponsored by: Netflix Differential Revision: https://reviews.freebsd.org/D18544 2018-10-31T19:59:20Z Gleb Smirnoff glebius@FreeBSD.org 2018-10-31T19:59:20Z urn:sha1:9319dded3d53a39ab6ba093c87bcbc42115ae968 2018-08-01T11:40:52Z Toomas Soome tsoome@FreeBSD.org 2018-08-01T11:40:52Z urn:sha1:eba1bc411b9c5af9e6d5aa9f32b5ecf623d1f76a A small cleanup, fix the argument type and while there, replace (char *)0 with NULL. 2018-02-26T18:24:24Z Kyle Evans kevans@FreeBSD.org 2018-02-26T18:24:24Z urn:sha1:ba37055c969d1d8c786c42657d1a8a998ad7eac2 The removal of tmo >= MAXTMO check should not have been done; this is specifically what handles timeout if MAXWAIT == 0. MFC after: 1 week 2018-02-26T18:14:37Z Kyle Evans kevans@FreeBSD.org 2018-02-26T18:14:37Z urn:sha1:fae9c380ce04d3419af5587c43bd14a058c6bab0 It's not a setting that has any effect or use outside of the net.c context. 2018-02-26T18:01:35Z Kyle Evans kevans@FreeBSD.org 2018-02-26T18:01:35Z urn:sha1:95c61459f374f954f10c9993386009438c31db04 Current timeout behavior is to progress in timeout values from MINTMO to MAXTMO in MINTMO steps before finally timing out. This results in a fairly long time before operations finally timeout, which may not be ideal for some use-cases. Add MAXWAIT that may be configured along with MINTMO/MAXTMO. If we attempt to start our send/recv cycle over again but MAXWAIT > 0 and MAXWAIT seconds have already passed, then go ahead and timeout. This is intended for those that just want to say "timeout after 180 seconds" rather than calculate and tweak MINTMO/MAXTMO to get their desired timeout. The default is 0, or "progress from MINTMO to MAXTMO with no exception." This has been modified since review to allow for it to be defined via CFLAGS and doing appropriate error checking. Future work may add some Makefile foo to respect LOADER_NET_MAXWAIT if it's specified in the environment and pass it in as MAXWAIT accordingly. Reviewed by: imp, sbruno, tsoome (all previous version) MFC after: 1 week Differential Revision: https://reviews.freebsd.org/D14389 2018-02-15T19:49:15Z Kyle Evans kevans@FreeBSD.org 2018-02-15T19:49:15Z urn:sha1:c5b86c3b7644e22989346cb48fc42a6ea5d508c4 bootp/arp/rarp/rpc all use the sendrecv implementation in net.c. tftp has its own implementation because it passes an extra parameter into the recv callback for the received payload type to be held. These sendrecv implementations are otherwise equivalent, so consolidate them. The other users of sendrecv won't be using the extra argument to recv, but this gives us only one place to worry about respecting timeouts and one consistent timeout behavior. Tested by: sbruno Reviewed by: sbruno, tsoome MFC after: 1 week Differential Revision: https://reviews.freebsd.org/D14373 2018-02-14T15:40:13Z Kyle Evans kevans@FreeBSD.org 2018-02-14T15:40:13Z urn:sha1:502b7cf99bea531fa3cf59d72cf89fcbb9311b8c readip() doesn't, at the moment, properly indicate to callers that it has timed out. One can tell that it's timed out if errno == EAGAIN when it returns, but this is not ideal. Restructure it a little bit to explicitly set errno to ETIMEDOUT if we've exhausted tleft. I found two places that care about where it timed out or not: sendrecv in net.c and sendrecv_tftp. Both are structured to pass smaller timeout values to readip while tracking a larger timeout. Neither of them were able to do this properly with readip not indicating ETIMEDOUT, so fix it. While here, straighten out the time (t/t1) usage in sendrecv_tftp. This would have manifested itself in periodic failures to NFS/TFTP boot for no apparent reason because MINTMO/MAXTMO were not actually being respected properly. Problems were not reported with NFS, only TFTP. Reported by: sbruno Reviewed by: sbruno, tsoome MFC after: 3 days Differential Revision: https://reviews.freebsd.org/D14350