-
Notifications
You must be signed in to change notification settings - Fork 2.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
don't zero the IP TOS bits on mbufs that need checksumming #12
Closed
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
On mbufs that don't have the CSUM_DATA_VALID flag set, tcp_input() needs to compute the TCP checksum itself. The TCP checksum includes some but not all fields from the IP header. tcp_input() zeroes the fields of the IP header that are not to be included in the checksum, then checksums the entire packet (IP header, TCP header, and TCP data), then restores the IP header fields it will need later. The bug that this commit fixes is that the IP TOS field was not restored, so the later read of it returned a zeroed byte instead of the incoming packet's actual TOS value.
uqs
pushed a commit
that referenced
this pull request
Nov 1, 2014
Released on October 23rd, 2014. * Restored the atf(7) manual page to serve as a reference to all the other manual pages shipped by ATF. * Added the -s flag to atf-sh to support specifying the shell interpreter to be used. * Removed ATF_WORKDIR. The only remaining consumers have been converted to use the standard TMPDIR environment variable. As a benefit, and because Kyua forces the TMPDIR to live within the test case's work directory, any stale files left behind by ATF will be automatically cleaned up. * Documented the environment variables recognized by each component in the relevant manual pages. This information was lost with the atf-config(1) removal. * Added a new "require.diskspace" metadata property to test cases so that they can specify the minimum amount of disk space required for the test to run. * Renamed the atf-{c,c++,sh}-api(3) manual pages to atf-{c,c++,sh}(3) for discoverability purposes. Symbolic links are provided for the time being to still make the old names visible. * Issue #5: Recommend the (expected, actual) idiom for calls to the test macros in the manual pages. * Issue #7: Stopped catching unhandled exceptions in atf-c++ tests. This propagates the crash to the caller, which in turn allows it to obtain proper debugging information. In particular, Kyua should now be able to extract a stacktrace pinpointing the problem. * Issue #8: Fixed atf-c/macros_test:use test failures spotted by the clang that ships with FreeBSD 11.0-CURRENT. * Issue #12: Improved documentation of atf-sh(3) and atf-check(1) by better explaining how they relate to each other. * Issue #14: Stopped setting 'set -e' in atf-sh. This setting was initially added as a way to enable a "strict" mode in the library and to make test cases fail fast when they run unprotected commands. However, doing so in the library is surprising as the responsibility of enabling 'set -e' should be on the user's code. Also, 'set -e' introduces inconsistent behavior on subshells and users do not expect that. * Issue #15: Fixed atf_utils_{fork,wait} to support nested calls. * Issue #16: Fixed test failures (by removing a long-standing hack) on systems that lack \e support in printf(1). * Issue #19: Removed stale references to atf-config and atf-run.
opntr
pushed a commit
to opntr/opBSD
that referenced
this pull request
Aug 4, 2015
* Move the shared page address to the proc struct. * Move the sigcode base address to the proc struct. * Add new sysctls for the VDSO randomization. * Use vm_map_find() to make VDSO randomization robust. + adapted to 10-STABLE code github-issue: freebsd#12 Sponsored-by: SoldierX Signed-Off-by: Shawn Webb <shawn.webb@hardenedbsd.org> Signed-off-by: Oliver Pinter <oliver.pinter@hardenedbsd.org> (cherry picked from commit b3bf41a5e955d121a8394d40c1f7b921278381db) (cherry picked from commit 951a6ca) (cherry picked from commit 2b2925f) (cherry picked from commit 71c4ac1) HBSD ASLR: fix a bug in freebsd32 compat layer Signed-off-by: Oliver Pinter <oliver.pinter@hardenedbsd.org> (cherry picked from commit f8f6159)
uqs
pushed a commit
that referenced
this pull request
Oct 26, 2015
The new load_ma implementation can cause dereferences when used with certain drivers, back it out until the reason is found: Fatal trap 12: page fault while in kernel mode cpuid = 11; apic id = 03 fault virtual address = 0x30 fault code = supervisor read data, page not present instruction pointer = 0x20:0xffffffff808a2d22 stack pointer = 0x28:0xfffffe07cc737710 frame pointer = 0x28:0xfffffe07cc737790 code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 13 (g_down) trap number = 12 panic: page fault cpuid = 11 KDB: stack backtrace: #0 0xffffffff80641647 at kdb_backtrace+0x67 #1 0xffffffff80606762 at vpanic+0x182 #2 0xffffffff806067e3 at panic+0x43 #3 0xffffffff8084eef1 at trap_fatal+0x351 #4 0xffffffff8084f0e4 at trap_pfault+0x1e4 #5 0xffffffff8084e82f at trap+0x4bf #6 0xffffffff80830d57 at calltrap+0x8 #7 0xffffffff8063beab at _bus_dmamap_load_ccb+0x1fb #8 0xffffffff8063bc51 at bus_dmamap_load_ccb+0x91 #9 0xffffffff8042dcad at ata_dmaload+0x11d #10 0xffffffff8042df7e at ata_begin_transaction+0x7e #11 0xffffffff8042c18e at ataaction+0x9ce #12 0xffffffff802a220f at xpt_run_devq+0x5bf #13 0xffffffff802a17ad at xpt_action_default+0x94d #14 0xffffffff802c0024 at adastart+0x8b4 #15 0xffffffff802a2e93 at xpt_run_allocq+0x193 #16 0xffffffff802c0735 at adastrategy+0xf5 #17 0xffffffff80554206 at g_disk_start+0x426 Uptime: 2m29s git-svn-id: svn+ssh://svn.freebsd.org/base/head@290005 ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f
uqs
pushed a commit
that referenced
this pull request
Oct 26, 2015
The new load_ma implementation can cause dereferences when used with certain drivers, back it out until the reason is found: Fatal trap 12: page fault while in kernel mode cpuid = 11; apic id = 03 fault virtual address = 0x30 fault code = supervisor read data, page not present instruction pointer = 0x20:0xffffffff808a2d22 stack pointer = 0x28:0xfffffe07cc737710 frame pointer = 0x28:0xfffffe07cc737790 code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 13 (g_down) trap number = 12 panic: page fault cpuid = 11 KDB: stack backtrace: #0 0xffffffff80641647 at kdb_backtrace+0x67 #1 0xffffffff80606762 at vpanic+0x182 #2 0xffffffff806067e3 at panic+0x43 #3 0xffffffff8084eef1 at trap_fatal+0x351 #4 0xffffffff8084f0e4 at trap_pfault+0x1e4 #5 0xffffffff8084e82f at trap+0x4bf #6 0xffffffff80830d57 at calltrap+0x8 #7 0xffffffff8063beab at _bus_dmamap_load_ccb+0x1fb #8 0xffffffff8063bc51 at bus_dmamap_load_ccb+0x91 #9 0xffffffff8042dcad at ata_dmaload+0x11d #10 0xffffffff8042df7e at ata_begin_transaction+0x7e #11 0xffffffff8042c18e at ataaction+0x9ce #12 0xffffffff802a220f at xpt_run_devq+0x5bf #13 0xffffffff802a17ad at xpt_action_default+0x94d #14 0xffffffff802c0024 at adastart+0x8b4 #15 0xffffffff802a2e93 at xpt_run_allocq+0x193 #16 0xffffffff802c0735 at adastrategy+0xf5 #17 0xffffffff80554206 at g_disk_start+0x426 Uptime: 2m29s
opntr
added a commit
to opntr/opBSD
that referenced
this pull request
Aug 19, 2016
…unix socket. - by markj@ If the listening socket is closed while sonewconn() is executing, the nascent child socket is aborted, which results in recursion on the unp_link lock when the child's pru_detach method is invoked. Fix this by using a flag to mark such sockets, and skip a part of the socket's teardown during detach. Reported by: Raviprakash Darbha <rdarbha@juniper.net> Tested by: pho MFC after: 2 weeks Differential Revision: https://reviews.freebsd.org/D7398 --8<-- [128] panic: __rw_wlock_hard: recursing but non-recursive rw unp_link_rwlock @ /usr/src/sys/kern/uipc_usrreq.c:654 [128] [128] cpuid = 1 [128] KDB: stack backtrace: [128] #0 0xffffffff8098dc90 at kdb_backtrace+0x60 [128] #1 0xffffffff80953ed6 at vpanic+0x126 [128] #2 0xffffffff80953da9 at kassert_panic+0x139 [128] #3 0xffffffff80951454 at __rw_wlock_hard+0x394 [128] #4 0xffffffff80951072 at _rw_wlock_cookie+0x92 [128] #5 0xffffffff809de636 at uipc_detach+0x36 [128] #6 0xffffffff809d217a at sofree+0x1da [128] #7 0xffffffff809d1da4 at sonewconn+0x324 [128] #8 0xffffffff809e0496 at unp_connectat+0x326 [128] freebsd#9 0xffffffff809de4ac at uipc_connect+0x4c [128] freebsd#10 0xffffffff809d8cf6 at kern_connectat+0x126 [128] freebsd#11 0xffffffff809d8b87 at sys_connect+0x77 [128] freebsd#12 0xffffffff80d6bab4 at amd64_syscall+0x2c4 [128] freebsd#13 0xffffffff80d4f6db at Xfast_syscall+0xfb [128] Uptime: 2m8s [128] Dumping 73 out of 487 MB:..22%..44%..66%..88% --8<-- (cherry picked from commit cfea0ef) Signed-off-by: Oliver Pinter <oliver.pinter@hardenedbsd.org>
lidl@ suggests instead:
|
mat813
pushed a commit
to mat813/freebsd
that referenced
this pull request
Nov 1, 2016
The new load_ma implementation can cause dereferences when used with certain drivers, back it out until the reason is found: Fatal trap 12: page fault while in kernel mode cpuid = 11; apic id = 03 fault virtual address = 0x30 fault code = supervisor read data, page not present instruction pointer = 0x20:0xffffffff808a2d22 stack pointer = 0x28:0xfffffe07cc737710 frame pointer = 0x28:0xfffffe07cc737790 code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 13 (g_down) trap number = 12 panic: page fault cpuid = 11 KDB: stack backtrace: #0 0xffffffff80641647 at kdb_backtrace+0x67 freebsd#1 0xffffffff80606762 at vpanic+0x182 freebsd#2 0xffffffff806067e3 at panic+0x43 freebsd#3 0xffffffff8084eef1 at trap_fatal+0x351 freebsd#4 0xffffffff8084f0e4 at trap_pfault+0x1e4 freebsd#5 0xffffffff8084e82f at trap+0x4bf freebsd#6 0xffffffff80830d57 at calltrap+0x8 freebsd#7 0xffffffff8063beab at _bus_dmamap_load_ccb+0x1fb freebsd#8 0xffffffff8063bc51 at bus_dmamap_load_ccb+0x91 freebsd#9 0xffffffff8042dcad at ata_dmaload+0x11d freebsd#10 0xffffffff8042df7e at ata_begin_transaction+0x7e freebsd#11 0xffffffff8042c18e at ataaction+0x9ce freebsd#12 0xffffffff802a220f at xpt_run_devq+0x5bf freebsd#13 0xffffffff802a17ad at xpt_action_default+0x94d freebsd#14 0xffffffff802c0024 at adastart+0x8b4 freebsd#15 0xffffffff802a2e93 at xpt_run_allocq+0x193 freebsd#16 0xffffffff802c0735 at adastrategy+0xf5 freebsd#17 0xffffffff80554206 at g_disk_start+0x426 Uptime: 2m29s git-svn-id: https://svn.freebsd.org/base/svnadmin@290005 ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f
rkojedzinszky
pushed a commit
to rkojedzinszky/freebsd
that referenced
this pull request
Dec 5, 2016
Allow sysctl kern.vm_guest to return bhyve when running under bhyve.
As mentioned by @cemeyer this has been committed |
mat813
pushed a commit
to mat813/freebsd
that referenced
this pull request
Mar 10, 2017
Released on October 23rd, 2014. * Restored the atf(7) manual page to serve as a reference to all the other manual pages shipped by ATF. * Added the -s flag to atf-sh to support specifying the shell interpreter to be used. * Removed ATF_WORKDIR. The only remaining consumers have been converted to use the standard TMPDIR environment variable. As a benefit, and because Kyua forces the TMPDIR to live within the test case's work directory, any stale files left behind by ATF will be automatically cleaned up. * Documented the environment variables recognized by each component in the relevant manual pages. This information was lost with the atf-config(1) removal. * Added a new "require.diskspace" metadata property to test cases so that they can specify the minimum amount of disk space required for the test to run. * Renamed the atf-{c,c++,sh}-api(3) manual pages to atf-{c,c++,sh}(3) for discoverability purposes. Symbolic links are provided for the time being to still make the old names visible. * Issue freebsd#5: Recommend the (expected, actual) idiom for calls to the test macros in the manual pages. * Issue freebsd#7: Stopped catching unhandled exceptions in atf-c++ tests. This propagates the crash to the caller, which in turn allows it to obtain proper debugging information. In particular, Kyua should now be able to extract a stacktrace pinpointing the problem. * Issue freebsd#8: Fixed atf-c/macros_test:use test failures spotted by the clang that ships with FreeBSD 11.0-CURRENT. * Issue freebsd#12: Improved documentation of atf-sh(3) and atf-check(1) by better explaining how they relate to each other. * Issue freebsd#14: Stopped setting 'set -e' in atf-sh. This setting was initially added as a way to enable a "strict" mode in the library and to make test cases fail fast when they run unprotected commands. However, doing so in the library is surprising as the responsibility of enabling 'set -e' should be on the user's code. Also, 'set -e' introduces inconsistent behavior on subshells and users do not expect that. * Issue freebsd#15: Fixed atf_utils_{fork,wait} to support nested calls. * Issue freebsd#16: Fixed test failures (by removing a long-standing hack) on systems that lack \e support in printf(1). * Issue freebsd#19: Removed stale references to atf-config and atf-run. git-svn-id: https://svn.freebsd.org/base/vendor/atf/dist@273869 ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f
guyyur
added a commit
to guyyur/freebsd-src
that referenced
this pull request
May 31, 2018
… we have no API for controlling the latter. This fixes a long standing problem where addresses added with non /128 prefixes and non infinite address lifetimes would register a prefix route which would expire. Subsequent calls set new lifetimes for the same address would not affect the prefix route management, so once expired, the prefix route would be impossible to add back as the kernel would remove it. Based on NetBSD changes (and reusing the commit message): sys/netinet6/in6.c 1.216 sys/netinet6/in6.c 1.217 sys/netinet6/in6.c 1.218 sys/netinet6/in6_ifattach.c 1.104 sys/netinet6/nd6_rtr.c 1.119 Also fixes a panic with INVARIANTS set and running "ndp -P" after an IPv6 address is manually added and the same prefix for the address is learned via router advertisment. freebsd#11 0xffffffff805d42b0 in kassert_panic (fmt=0xffffffff80939e3a "prefix %p has referencing addresses") at /usr/src/sys/kern/kern_shutdown.c:723 freebsd#12 0xffffffff807d4049 in nd6_prefix_del (pr=0xfffff800043c0400) at /usr/src/sys/netinet6/nd6_rtr.c:1189 freebsd#13 0xffffffff807caf38 in nd6_ioctl (cmd=<optimized out>, data=<optimized out>, ifp=0xfffff80002337000) at /usr/src/sys/netinet6/nd6.c:1831 PR: 195197
guyyur
added a commit
to guyyur/freebsd-src
that referenced
this pull request
Jun 30, 2018
… we have no API for controlling the latter. This fixes a long standing problem where addresses added with non /128 prefixes and non infinite address lifetimes would register a prefix route which would expire. Subsequent calls set new lifetimes for the same address would not affect the prefix route management, so once expired, the prefix route would be impossible to add back as the kernel would remove it. Based on NetBSD changes (and reusing the commit message): sys/netinet6/in6.c 1.216 sys/netinet6/in6.c 1.217 sys/netinet6/in6.c 1.218 sys/netinet6/in6_ifattach.c 1.104 sys/netinet6/nd6_rtr.c 1.119 Also fixes a panic with INVARIANTS set and running "ndp -P" after an IPv6 address is manually added and the same prefix for the address is learned via router advertisment. freebsd#11 0xffffffff805d42b0 in kassert_panic (fmt=0xffffffff80939e3a "prefix %p has referencing addresses") at /usr/src/sys/kern/kern_shutdown.c:723 freebsd#12 0xffffffff807d4049 in nd6_prefix_del (pr=0xfffff800043c0400) at /usr/src/sys/netinet6/nd6_rtr.c:1189 freebsd#13 0xffffffff807caf38 in nd6_ioctl (cmd=<optimized out>, data=<optimized out>, ifp=0xfffff80002337000) at /usr/src/sys/netinet6/nd6.c:1831 PR: 195197
guyyur
added a commit
to guyyur/freebsd-src
that referenced
this pull request
Aug 11, 2018
… we have no API for controlling the latter. This fixes a long standing problem where addresses added with non /128 prefixes and non infinite address lifetimes would register a prefix route which would expire. Subsequent calls set new lifetimes for the same address would not affect the prefix route management, so once expired, the prefix route would be impossible to add back as the kernel would remove it. Based on NetBSD changes (and reusing the commit message): sys/netinet6/in6.c 1.216 sys/netinet6/in6.c 1.217 sys/netinet6/in6.c 1.218 sys/netinet6/in6_ifattach.c 1.104 sys/netinet6/nd6_rtr.c 1.119 Also fixes a panic with INVARIANTS set and running "ndp -P" after an IPv6 address is manually added and the same prefix for the address is learned via router advertisment. freebsd#11 0xffffffff805d42b0 in kassert_panic (fmt=0xffffffff80939e3a "prefix %p has referencing addresses") at /usr/src/sys/kern/kern_shutdown.c:723 freebsd#12 0xffffffff807d4049 in nd6_prefix_del (pr=0xfffff800043c0400) at /usr/src/sys/netinet6/nd6_rtr.c:1189 freebsd#13 0xffffffff807caf38 in nd6_ioctl (cmd=<optimized out>, data=<optimized out>, ifp=0xfffff80002337000) at /usr/src/sys/netinet6/nd6.c:1831 PR: 195197
guyyur
added a commit
to guyyur/freebsd-src
that referenced
this pull request
Apr 15, 2019
… we have no API for controlling the latter. This fixes a long standing problem where addresses added with non /128 prefixes and non infinite address lifetimes would register a prefix route which would expire. Subsequent calls set new lifetimes for the same address would not affect the prefix route management, so once expired, the prefix route would be impossible to add back as the kernel would remove it. Based on NetBSD changes (and reusing the commit message): sys/netinet6/in6.c 1.216 sys/netinet6/in6.c 1.217 sys/netinet6/in6.c 1.218 sys/netinet6/in6_ifattach.c 1.104 sys/netinet6/nd6_rtr.c 1.119 Also fixes a panic with INVARIANTS set and running "ndp -P" after an IPv6 address is manually added and the same prefix for the address is learned via router advertisment. freebsd#11 0xffffffff805d42b0 in kassert_panic (fmt=0xffffffff80939e3a "prefix %p has referencing addresses") at /usr/src/sys/kern/kern_shutdown.c:723 freebsd#12 0xffffffff807d4049 in nd6_prefix_del (pr=0xfffff800043c0400) at /usr/src/sys/netinet6/nd6_rtr.c:1189 freebsd#13 0xffffffff807caf38 in nd6_ioctl (cmd=<optimized out>, data=<optimized out>, ifp=0xfffff80002337000) at /usr/src/sys/netinet6/nd6.c:1831 PR: 195197
guyyur
added a commit
to guyyur/freebsd-src
that referenced
this pull request
Apr 21, 2019
… we have no API for controlling the latter. This fixes a long standing problem where addresses added with non /128 prefixes and non infinite address lifetimes would register a prefix route which would expire. Subsequent calls set new lifetimes for the same address would not affect the prefix route management, so once expired, the prefix route would be impossible to add back as the kernel would remove it. Based on NetBSD changes (and reusing the commit message): sys/netinet6/in6.c 1.216 sys/netinet6/in6.c 1.217 sys/netinet6/in6.c 1.218 sys/netinet6/in6_ifattach.c 1.104 sys/netinet6/nd6_rtr.c 1.119 Also fixes a panic with INVARIANTS set and running "ndp -P" after an IPv6 address is manually added and the same prefix for the address is learned via router advertisment. freebsd#11 0xffffffff805d42b0 in kassert_panic (fmt=0xffffffff80939e3a "prefix %p has referencing addresses") at /usr/src/sys/kern/kern_shutdown.c:723 freebsd#12 0xffffffff807d4049 in nd6_prefix_del (pr=0xfffff800043c0400) at /usr/src/sys/netinet6/nd6_rtr.c:1189 freebsd#13 0xffffffff807caf38 in nd6_ioctl (cmd=<optimized out>, data=<optimized out>, ifp=0xfffff80002337000) at /usr/src/sys/netinet6/nd6.c:1831 PR: 195197
uqs
pushed a commit
that referenced
this pull request
Dec 29, 2019
With WITNESS enabled we see the following warning: lock order reversal: (sleepable after non-sleepable) 1st 0xffffffd0847c7210 fu540spi0 (fu540spi0) @ /usr/home/kp/axiado/hornet-freebsd/src/sys/riscv/sifive/fu540_spi.c:297 2nd 0xffffffc00372bb30 Clock topology lock (Clock topology lock) @ /usr/home/kp/axiado/hornet-freebsd/src/sys/dev/extres/clk/clk.c:1137 stack backtrace: #0 0xffffffc0002a579e at witness_checkorder+0xb72 #1 0xffffffc0002a5556 at witness_checkorder+0x92a #2 0xffffffc000254c7a at _sx_slock_int+0x66 #3 0xffffffc00025537a at _sx_slock+0x8 #4 0xffffffc000123022 at clk_get_freq+0x38 #5 0xffffffc0005463e4 at __clzdi2+0x2bb8 #6 0xffffffc00014af58 at randomdev_getkey+0x76e #7 0xffffffc0001278b0 at simplebus_add_device+0x7ee #8 0xffffffc00027c9a8 at device_attach+0x2e6 #9 0xffffffc00027c634 at device_probe_and_attach+0x7a #10 0xffffffc00027d76a at bus_generic_attach+0x10 #11 0xffffffc00014aab0 at randomdev_getkey+0x2c6 #12 0xffffffc00027c9a8 at device_attach+0x2e6 #13 0xffffffc00027c634 at device_probe_and_attach+0x7a #14 0xffffffc00027d76a at bus_generic_attach+0x10 #15 0xffffffc000278bd2 at config_intrhook_oneshot+0x52 #16 0xffffffc000278b3e at config_intrhook_establish+0x146 #17 0xffffffc000278cf2 at config_intrhook_disestablish+0xfe The clock topology lock can sleep, which means we cannot attempt to acquire it while holding the non-sleepable mutex. Fix that by retrieving the clock speed once, during attach and not every time during SPI transaction setup. Submitted by: kp Sponsored by: Axiado git-svn-id: svn+ssh://svn.freebsd.org/base/head@356166 ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f
uqs
pushed a commit
that referenced
this pull request
Dec 29, 2019
With WITNESS enabled we see the following warning: lock order reversal: (sleepable after non-sleepable) 1st 0xffffffd0847c7210 fu540spi0 (fu540spi0) @ /usr/home/kp/axiado/hornet-freebsd/src/sys/riscv/sifive/fu540_spi.c:297 2nd 0xffffffc00372bb30 Clock topology lock (Clock topology lock) @ /usr/home/kp/axiado/hornet-freebsd/src/sys/dev/extres/clk/clk.c:1137 stack backtrace: #0 0xffffffc0002a579e at witness_checkorder+0xb72 #1 0xffffffc0002a5556 at witness_checkorder+0x92a #2 0xffffffc000254c7a at _sx_slock_int+0x66 #3 0xffffffc00025537a at _sx_slock+0x8 #4 0xffffffc000123022 at clk_get_freq+0x38 #5 0xffffffc0005463e4 at __clzdi2+0x2bb8 #6 0xffffffc00014af58 at randomdev_getkey+0x76e #7 0xffffffc0001278b0 at simplebus_add_device+0x7ee #8 0xffffffc00027c9a8 at device_attach+0x2e6 #9 0xffffffc00027c634 at device_probe_and_attach+0x7a #10 0xffffffc00027d76a at bus_generic_attach+0x10 #11 0xffffffc00014aab0 at randomdev_getkey+0x2c6 #12 0xffffffc00027c9a8 at device_attach+0x2e6 #13 0xffffffc00027c634 at device_probe_and_attach+0x7a #14 0xffffffc00027d76a at bus_generic_attach+0x10 #15 0xffffffc000278bd2 at config_intrhook_oneshot+0x52 #16 0xffffffc000278b3e at config_intrhook_establish+0x146 #17 0xffffffc000278cf2 at config_intrhook_disestablish+0xfe The clock topology lock can sleep, which means we cannot attempt to acquire it while holding the non-sleepable mutex. Fix that by retrieving the clock speed once, during attach and not every time during SPI transaction setup. Submitted by: kp Sponsored by: Axiado
mat813
pushed a commit
to mat813/freebsd
that referenced
this pull request
Jan 6, 2020
With WITNESS enabled we see the following warning: lock order reversal: (sleepable after non-sleepable) 1st 0xffffffd0847c7210 fu540spi0 (fu540spi0) @ /usr/home/kp/axiado/hornet-freebsd/src/sys/riscv/sifive/fu540_spi.c:297 2nd 0xffffffc00372bb30 Clock topology lock (Clock topology lock) @ /usr/home/kp/axiado/hornet-freebsd/src/sys/dev/extres/clk/clk.c:1137 stack backtrace: #0 0xffffffc0002a579e at witness_checkorder+0xb72 freebsd#1 0xffffffc0002a5556 at witness_checkorder+0x92a freebsd#2 0xffffffc000254c7a at _sx_slock_int+0x66 freebsd#3 0xffffffc00025537a at _sx_slock+0x8 freebsd#4 0xffffffc000123022 at clk_get_freq+0x38 freebsd#5 0xffffffc0005463e4 at __clzdi2+0x2bb8 freebsd#6 0xffffffc00014af58 at randomdev_getkey+0x76e freebsd#7 0xffffffc0001278b0 at simplebus_add_device+0x7ee freebsd#8 0xffffffc00027c9a8 at device_attach+0x2e6 freebsd#9 0xffffffc00027c634 at device_probe_and_attach+0x7a freebsd#10 0xffffffc00027d76a at bus_generic_attach+0x10 freebsd#11 0xffffffc00014aab0 at randomdev_getkey+0x2c6 freebsd#12 0xffffffc00027c9a8 at device_attach+0x2e6 freebsd#13 0xffffffc00027c634 at device_probe_and_attach+0x7a freebsd#14 0xffffffc00027d76a at bus_generic_attach+0x10 freebsd#15 0xffffffc000278bd2 at config_intrhook_oneshot+0x52 freebsd#16 0xffffffc000278b3e at config_intrhook_establish+0x146 freebsd#17 0xffffffc000278cf2 at config_intrhook_disestablish+0xfe The clock topology lock can sleep, which means we cannot attempt to acquire it while holding the non-sleepable mutex. Fix that by retrieving the clock speed once, during attach and not every time during SPI transaction setup. Submitted by: kp Sponsored by: Axiado git-svn-id: https://svn.freebsd.org/base/head@356166 ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f
guyyur
added a commit
to guyyur/freebsd-src
that referenced
this pull request
Feb 20, 2020
… we have no API for controlling the latter. This fixes a long standing problem where addresses added with non /128 prefixes and non infinite address lifetimes would register a prefix route which would expire. Subsequent calls set new lifetimes for the same address would not affect the prefix route management, so once expired, the prefix route would be impossible to add back as the kernel would remove it. Based on NetBSD changes (and reusing the commit message): sys/netinet6/in6.c 1.216 sys/netinet6/in6.c 1.217 sys/netinet6/in6.c 1.218 sys/netinet6/in6_ifattach.c 1.104 sys/netinet6/nd6_rtr.c 1.119 Also fixes a panic with INVARIANTS set and running "ndp -P" after an IPv6 address is manually added and the same prefix for the address is learned via router advertisment. freebsd#11 0xffffffff805d42b0 in kassert_panic (fmt=0xffffffff80939e3a "prefix %p has referencing addresses") at /usr/src/sys/kern/kern_shutdown.c:723 freebsd#12 0xffffffff807d4049 in nd6_prefix_del (pr=0xfffff800043c0400) at /usr/src/sys/netinet6/nd6_rtr.c:1189 freebsd#13 0xffffffff807caf38 in nd6_ioctl (cmd=<optimized out>, data=<optimized out>, ifp=0xfffff80002337000) at /usr/src/sys/netinet6/nd6.c:1831 PR: 195197
uqs
pushed a commit
that referenced
this pull request
Aug 22, 2020
Instantiate Error in Target::GetEntryPointAddress() only when necessary When Target::GetEntryPointAddress() calls exe_module->GetObjectFile()->GetEntryPointAddress(), and the returned entry_addr is valid, it can immediately be returned. However, just before that, an llvm::Error value has been setup, but in this case it is not consumed before returning, like is done further below in the function. In https://bugs.freebsd.org/248745 we got a bug report for this, where a very simple test case aborts and dumps core: * thread #1, name = 'testcase', stop reason = breakpoint 1.1 frame #0: 0x00000000002018d4 testcase`main(argc=1, argv=0x00007fffffffea18) at testcase.c:3:5 1 int main(int argc, char *argv[]) 2 { -> 3 return 0; 4 } (lldb) p argc Program aborted due to an unhandled Error: Error value was Success. (Note: Success values must still be checked prior to being destroyed). Thread 1 received signal SIGABRT, Aborted. thr_kill () at thr_kill.S:3 3 thr_kill.S: No such file or directory. (gdb) bt #0 thr_kill () at thr_kill.S:3 #1 0x00000008049a0004 in __raise (s=6) at /usr/src/lib/libc/gen/raise.c:52 #2 0x0000000804916229 in abort () at /usr/src/lib/libc/stdlib/abort.c:67 #3 0x000000000451b5f5 in fatalUncheckedError () at /usr/src/contrib/llvm-project/llvm/lib/Support/Error.cpp:112 #4 0x00000000019cf008 in GetEntryPointAddress () at /usr/src/contrib/llvm-project/llvm/include/llvm/Support/Error.h:267 #5 0x0000000001bccbd8 in ConstructorSetup () at /usr/src/contrib/llvm-project/lldb/source/Target/ThreadPlanCallFunction.cpp:67 #6 0x0000000001bcd2c0 in ThreadPlanCallFunction () at /usr/src/contrib/llvm-project/lldb/source/Target/ThreadPlanCallFunction.cpp:114 #7 0x00000000020076d4 in InferiorCallMmap () at /usr/src/contrib/llvm-project/lldb/source/Plugins/Process/Utility/InferiorCallPOSIX.cpp:97 #8 0x0000000001f4be33 in DoAllocateMemory () at /usr/src/contrib/llvm-project/lldb/source/Plugins/Process/FreeBSD/ProcessFreeBSD.cpp:604 #9 0x0000000001fe51b9 in AllocatePage () at /usr/src/contrib/llvm-project/lldb/source/Target/Memory.cpp:347 #10 0x0000000001fe5385 in AllocateMemory () at /usr/src/contrib/llvm-project/lldb/source/Target/Memory.cpp:383 #11 0x0000000001974da2 in AllocateMemory () at /usr/src/contrib/llvm-project/lldb/source/Target/Process.cpp:2301 #12 CanJIT () at /usr/src/contrib/llvm-project/lldb/source/Target/Process.cpp:2331 #13 0x0000000001a1bf3d in Evaluate () at /usr/src/contrib/llvm-project/lldb/source/Expression/UserExpression.cpp:190 #14 0x00000000019ce7a2 in EvaluateExpression () at /usr/src/contrib/llvm-project/lldb/source/Target/Target.cpp:2372 #15 0x0000000001ad784c in EvaluateExpression () at /usr/src/contrib/llvm-project/lldb/source/Commands/CommandObjectExpression.cpp:414 #16 0x0000000001ad86ae in DoExecute () at /usr/src/contrib/llvm-project/lldb/source/Commands/CommandObjectExpression.cpp:646 #17 0x0000000001a5e3ed in Execute () at /usr/src/contrib/llvm-project/lldb/source/Interpreter/CommandObject.cpp:1003 #18 0x0000000001a6c4a3 in HandleCommand () at /usr/src/contrib/llvm-project/lldb/source/Interpreter/CommandInterpreter.cpp:1762 #19 0x0000000001a6f98c in IOHandlerInputComplete () at /usr/src/contrib/llvm-project/lldb/source/Interpreter/CommandInterpreter.cpp:2760 #20 0x0000000001a90b08 in Run () at /usr/src/contrib/llvm-project/lldb/source/Core/IOHandler.cpp:548 #21 0x00000000019a6c6a in ExecuteIOHandlers () at /usr/src/contrib/llvm-project/lldb/source/Core/Debugger.cpp:903 #22 0x0000000001a70337 in RunCommandInterpreter () at /usr/src/contrib/llvm-project/lldb/source/Interpreter/CommandInterpreter.cpp:2946 #23 0x0000000001d9d812 in RunCommandInterpreter () at /usr/src/contrib/llvm-project/lldb/source/API/SBDebugger.cpp:1169 #24 0x0000000001918be8 in MainLoop () at /usr/src/contrib/llvm-project/lldb/tools/driver/Driver.cpp:675 #25 0x000000000191a114 in main () at /usr/src/contrib/llvm-project/lldb/tools/driver/Driver.cpp:890 Fix the incorrect error catch by only instantiating an Error object if it is necessary. Reviewed By: JDevlieghere Differential Revision: https://reviews.llvm.org/D86355 This should fix lldb aborting as described in the scenario above. Reported by: dmgk PR: 248745 git-svn-id: svn+ssh://svn.freebsd.org/base/head@364480 ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f
uqs
pushed a commit
that referenced
this pull request
Aug 22, 2020
Instantiate Error in Target::GetEntryPointAddress() only when necessary When Target::GetEntryPointAddress() calls exe_module->GetObjectFile()->GetEntryPointAddress(), and the returned entry_addr is valid, it can immediately be returned. However, just before that, an llvm::Error value has been setup, but in this case it is not consumed before returning, like is done further below in the function. In https://bugs.freebsd.org/248745 we got a bug report for this, where a very simple test case aborts and dumps core: * thread #1, name = 'testcase', stop reason = breakpoint 1.1 frame #0: 0x00000000002018d4 testcase`main(argc=1, argv=0x00007fffffffea18) at testcase.c:3:5 1 int main(int argc, char *argv[]) 2 { -> 3 return 0; 4 } (lldb) p argc Program aborted due to an unhandled Error: Error value was Success. (Note: Success values must still be checked prior to being destroyed). Thread 1 received signal SIGABRT, Aborted. thr_kill () at thr_kill.S:3 3 thr_kill.S: No such file or directory. (gdb) bt #0 thr_kill () at thr_kill.S:3 #1 0x00000008049a0004 in __raise (s=6) at /usr/src/lib/libc/gen/raise.c:52 #2 0x0000000804916229 in abort () at /usr/src/lib/libc/stdlib/abort.c:67 #3 0x000000000451b5f5 in fatalUncheckedError () at /usr/src/contrib/llvm-project/llvm/lib/Support/Error.cpp:112 #4 0x00000000019cf008 in GetEntryPointAddress () at /usr/src/contrib/llvm-project/llvm/include/llvm/Support/Error.h:267 #5 0x0000000001bccbd8 in ConstructorSetup () at /usr/src/contrib/llvm-project/lldb/source/Target/ThreadPlanCallFunction.cpp:67 #6 0x0000000001bcd2c0 in ThreadPlanCallFunction () at /usr/src/contrib/llvm-project/lldb/source/Target/ThreadPlanCallFunction.cpp:114 #7 0x00000000020076d4 in InferiorCallMmap () at /usr/src/contrib/llvm-project/lldb/source/Plugins/Process/Utility/InferiorCallPOSIX.cpp:97 #8 0x0000000001f4be33 in DoAllocateMemory () at /usr/src/contrib/llvm-project/lldb/source/Plugins/Process/FreeBSD/ProcessFreeBSD.cpp:604 #9 0x0000000001fe51b9 in AllocatePage () at /usr/src/contrib/llvm-project/lldb/source/Target/Memory.cpp:347 #10 0x0000000001fe5385 in AllocateMemory () at /usr/src/contrib/llvm-project/lldb/source/Target/Memory.cpp:383 #11 0x0000000001974da2 in AllocateMemory () at /usr/src/contrib/llvm-project/lldb/source/Target/Process.cpp:2301 #12 CanJIT () at /usr/src/contrib/llvm-project/lldb/source/Target/Process.cpp:2331 #13 0x0000000001a1bf3d in Evaluate () at /usr/src/contrib/llvm-project/lldb/source/Expression/UserExpression.cpp:190 #14 0x00000000019ce7a2 in EvaluateExpression () at /usr/src/contrib/llvm-project/lldb/source/Target/Target.cpp:2372 #15 0x0000000001ad784c in EvaluateExpression () at /usr/src/contrib/llvm-project/lldb/source/Commands/CommandObjectExpression.cpp:414 #16 0x0000000001ad86ae in DoExecute () at /usr/src/contrib/llvm-project/lldb/source/Commands/CommandObjectExpression.cpp:646 #17 0x0000000001a5e3ed in Execute () at /usr/src/contrib/llvm-project/lldb/source/Interpreter/CommandObject.cpp:1003 #18 0x0000000001a6c4a3 in HandleCommand () at /usr/src/contrib/llvm-project/lldb/source/Interpreter/CommandInterpreter.cpp:1762 #19 0x0000000001a6f98c in IOHandlerInputComplete () at /usr/src/contrib/llvm-project/lldb/source/Interpreter/CommandInterpreter.cpp:2760 #20 0x0000000001a90b08 in Run () at /usr/src/contrib/llvm-project/lldb/source/Core/IOHandler.cpp:548 #21 0x00000000019a6c6a in ExecuteIOHandlers () at /usr/src/contrib/llvm-project/lldb/source/Core/Debugger.cpp:903 #22 0x0000000001a70337 in RunCommandInterpreter () at /usr/src/contrib/llvm-project/lldb/source/Interpreter/CommandInterpreter.cpp:2946 #23 0x0000000001d9d812 in RunCommandInterpreter () at /usr/src/contrib/llvm-project/lldb/source/API/SBDebugger.cpp:1169 #24 0x0000000001918be8 in MainLoop () at /usr/src/contrib/llvm-project/lldb/tools/driver/Driver.cpp:675 #25 0x000000000191a114 in main () at /usr/src/contrib/llvm-project/lldb/tools/driver/Driver.cpp:890 Fix the incorrect error catch by only instantiating an Error object if it is necessary. Reviewed By: JDevlieghere Differential Revision: https://reviews.llvm.org/D86355 This should fix lldb aborting as described in the scenario above. Reported by: dmgk PR: 248745
bdrewery
pushed a commit
to bdrewery/freebsd
that referenced
this pull request
Sep 25, 2020
Instantiate Error in Target::GetEntryPointAddress() only when necessary When Target::GetEntryPointAddress() calls exe_module->GetObjectFile()->GetEntryPointAddress(), and the returned entry_addr is valid, it can immediately be returned. However, just before that, an llvm::Error value has been setup, but in this case it is not consumed before returning, like is done further below in the function. In https://bugs.freebsd.org/248745 we got a bug report for this, where a very simple test case aborts and dumps core: * thread freebsd#1, name = 'testcase', stop reason = breakpoint 1.1 frame #0: 0x00000000002018d4 testcase`main(argc=1, argv=0x00007fffffffea18) at testcase.c:3:5 1 int main(int argc, char *argv[]) 2 { -> 3 return 0; 4 } (lldb) p argc Program aborted due to an unhandled Error: Error value was Success. (Note: Success values must still be checked prior to being destroyed). Thread 1 received signal SIGABRT, Aborted. thr_kill () at thr_kill.S:3 3 thr_kill.S: No such file or directory. (gdb) bt #0 thr_kill () at thr_kill.S:3 freebsd#1 0x00000008049a0004 in __raise (s=6) at /usr/src/lib/libc/gen/raise.c:52 freebsd#2 0x0000000804916229 in abort () at /usr/src/lib/libc/stdlib/abort.c:67 freebsd#3 0x000000000451b5f5 in fatalUncheckedError () at /usr/src/contrib/llvm-project/llvm/lib/Support/Error.cpp:112 freebsd#4 0x00000000019cf008 in GetEntryPointAddress () at /usr/src/contrib/llvm-project/llvm/include/llvm/Support/Error.h:267 freebsd#5 0x0000000001bccbd8 in ConstructorSetup () at /usr/src/contrib/llvm-project/lldb/source/Target/ThreadPlanCallFunction.cpp:67 freebsd#6 0x0000000001bcd2c0 in ThreadPlanCallFunction () at /usr/src/contrib/llvm-project/lldb/source/Target/ThreadPlanCallFunction.cpp:114 freebsd#7 0x00000000020076d4 in InferiorCallMmap () at /usr/src/contrib/llvm-project/lldb/source/Plugins/Process/Utility/InferiorCallPOSIX.cpp:97 freebsd#8 0x0000000001f4be33 in DoAllocateMemory () at /usr/src/contrib/llvm-project/lldb/source/Plugins/Process/FreeBSD/ProcessFreeBSD.cpp:604 freebsd#9 0x0000000001fe51b9 in AllocatePage () at /usr/src/contrib/llvm-project/lldb/source/Target/Memory.cpp:347 freebsd#10 0x0000000001fe5385 in AllocateMemory () at /usr/src/contrib/llvm-project/lldb/source/Target/Memory.cpp:383 freebsd#11 0x0000000001974da2 in AllocateMemory () at /usr/src/contrib/llvm-project/lldb/source/Target/Process.cpp:2301 freebsd#12 CanJIT () at /usr/src/contrib/llvm-project/lldb/source/Target/Process.cpp:2331 freebsd#13 0x0000000001a1bf3d in Evaluate () at /usr/src/contrib/llvm-project/lldb/source/Expression/UserExpression.cpp:190 freebsd#14 0x00000000019ce7a2 in EvaluateExpression () at /usr/src/contrib/llvm-project/lldb/source/Target/Target.cpp:2372 freebsd#15 0x0000000001ad784c in EvaluateExpression () at /usr/src/contrib/llvm-project/lldb/source/Commands/CommandObjectExpression.cpp:414 freebsd#16 0x0000000001ad86ae in DoExecute () at /usr/src/contrib/llvm-project/lldb/source/Commands/CommandObjectExpression.cpp:646 freebsd#17 0x0000000001a5e3ed in Execute () at /usr/src/contrib/llvm-project/lldb/source/Interpreter/CommandObject.cpp:1003 freebsd#18 0x0000000001a6c4a3 in HandleCommand () at /usr/src/contrib/llvm-project/lldb/source/Interpreter/CommandInterpreter.cpp:1762 freebsd#19 0x0000000001a6f98c in IOHandlerInputComplete () at /usr/src/contrib/llvm-project/lldb/source/Interpreter/CommandInterpreter.cpp:2760 freebsd#20 0x0000000001a90b08 in Run () at /usr/src/contrib/llvm-project/lldb/source/Core/IOHandler.cpp:548 freebsd#21 0x00000000019a6c6a in ExecuteIOHandlers () at /usr/src/contrib/llvm-project/lldb/source/Core/Debugger.cpp:903 freebsd#22 0x0000000001a70337 in RunCommandInterpreter () at /usr/src/contrib/llvm-project/lldb/source/Interpreter/CommandInterpreter.cpp:2946 freebsd#23 0x0000000001d9d812 in RunCommandInterpreter () at /usr/src/contrib/llvm-project/lldb/source/API/SBDebugger.cpp:1169 freebsd#24 0x0000000001918be8 in MainLoop () at /usr/src/contrib/llvm-project/lldb/tools/driver/Driver.cpp:675 freebsd#25 0x000000000191a114 in main () at /usr/src/contrib/llvm-project/lldb/tools/driver/Driver.cpp:890 Fix the incorrect error catch by only instantiating an Error object if it is necessary. Reviewed By: JDevlieghere Differential Revision: https://reviews.llvm.org/D86355 This should fix lldb aborting as described in the scenario above. Reported by: dmgk PR: 248745 git-svn-id: svn+ssh://svn.freebsd.org/base/head@364480 ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f
guyyur
added a commit
to guyyur/freebsd-src
that referenced
this pull request
Sep 27, 2020
… we have no API for controlling the latter. This fixes a long standing problem where addresses added with non /128 prefixes and non infinite address lifetimes would register a prefix route which would expire. Subsequent calls set new lifetimes for the same address would not affect the prefix route management, so once expired, the prefix route would be impossible to add back as the kernel would remove it. Based on NetBSD changes (and reusing the commit message): sys/netinet6/in6.c 1.216 sys/netinet6/in6.c 1.217 sys/netinet6/in6.c 1.218 sys/netinet6/in6_ifattach.c 1.104 sys/netinet6/nd6_rtr.c 1.119 Also fixes a panic with INVARIANTS set and running "ndp -P" after an IPv6 address is manually added and the same prefix for the address is learned via router advertisment. freebsd#11 0xffffffff805d42b0 in kassert_panic (fmt=0xffffffff80939e3a "prefix %p has referencing addresses") at /usr/src/sys/kern/kern_shutdown.c:723 freebsd#12 0xffffffff807d4049 in nd6_prefix_del (pr=0xfffff800043c0400) at /usr/src/sys/netinet6/nd6_rtr.c:1189 freebsd#13 0xffffffff807caf38 in nd6_ioctl (cmd=<optimized out>, data=<optimized out>, ifp=0xfffff80002337000) at /usr/src/sys/netinet6/nd6.c:1831 PR: 195197
guyyur
added a commit
to guyyur/freebsd-src
that referenced
this pull request
Sep 27, 2020
… we have no API for controlling the latter. This fixes a long standing problem where addresses added with non /128 prefixes and non infinite address lifetimes would register a prefix route which would expire. Subsequent calls set new lifetimes for the same address would not affect the prefix route management, so once expired, the prefix route would be impossible to add back as the kernel would remove it. Based on NetBSD changes (and reusing the commit message): sys/netinet6/in6.c 1.216 sys/netinet6/in6.c 1.217 sys/netinet6/in6.c 1.218 sys/netinet6/in6_ifattach.c 1.104 sys/netinet6/nd6_rtr.c 1.119 Also fixes a panic with INVARIANTS set and running "ndp -P" after an IPv6 address is manually added and the same prefix for the address is learned via router advertisment. freebsd#11 0xffffffff805d42b0 in kassert_panic (fmt=0xffffffff80939e3a "prefix %p has referencing addresses") at /usr/src/sys/kern/kern_shutdown.c:723 freebsd#12 0xffffffff807d4049 in nd6_prefix_del (pr=0xfffff800043c0400) at /usr/src/sys/netinet6/nd6_rtr.c:1189 freebsd#13 0xffffffff807caf38 in nd6_ioctl (cmd=<optimized out>, data=<optimized out>, ifp=0xfffff80002337000) at /usr/src/sys/netinet6/nd6.c:1831 PR: 195197
hardenedbsd-services
referenced
this pull request
in HardenedBSD/hardenedBSD
Dec 27, 2020
Merge commit 1ce07cd614be from llvm git (by me): Instantiate Error in Target::GetEntryPointAddress() only when necessary When Target::GetEntryPointAddress() calls exe_module->GetObjectFile()->GetEntryPointAddress(), and the returned entry_addr is valid, it can immediately be returned. However, just before that, an llvm::Error value has been setup, but in this case it is not consumed before returning, like is done further below in the function. In https://bugs.freebsd.org/248745 we got a bug report for this, where a very simple test case aborts and dumps core: * thread #1, name = 'testcase', stop reason = breakpoint 1.1 frame #0: 0x00000000002018d4 testcase`main(argc=1, argv=0x00007fffffffea18) at testcase.c:3:5 1 int main(int argc, char *argv[]) 2 { -> 3 return 0; 4 } (lldb) p argc Program aborted due to an unhandled Error: Error value was Success. (Note: Success values must still be checked prior to being destroyed). Thread 1 received signal SIGABRT, Aborted. thr_kill () at thr_kill.S:3 3 thr_kill.S: No such file or directory. (gdb) bt #0 thr_kill () at thr_kill.S:3 #1 0x00000008049a0004 in __raise (s=6) at /usr/src/lib/libc/gen/raise.c:52 #2 0x0000000804916229 in abort () at /usr/src/lib/libc/stdlib/abort.c:67 #3 0x000000000451b5f5 in fatalUncheckedError () at /usr/src/contrib/llvm-project/llvm/lib/Support/Error.cpp:112 #4 0x00000000019cf008 in GetEntryPointAddress () at /usr/src/contrib/llvm-project/llvm/include/llvm/Support/Error.h:267 #5 0x0000000001bccbd8 in ConstructorSetup () at /usr/src/contrib/llvm-project/lldb/source/Target/ThreadPlanCallFunction.cpp:67 #6 0x0000000001bcd2c0 in ThreadPlanCallFunction () at /usr/src/contrib/llvm-project/lldb/source/Target/ThreadPlanCallFunction.cpp:114 #7 0x00000000020076d4 in InferiorCallMmap () at /usr/src/contrib/llvm-project/lldb/source/Plugins/Process/Utility/InferiorCallPOSIX.cpp:97 #8 0x0000000001f4be33 in DoAllocateMemory () at /usr/src/contrib/llvm-project/lldb/source/Plugins/Process/FreeBSD/ProcessFreeBSD.cpp:604 #9 0x0000000001fe51b9 in AllocatePage () at /usr/src/contrib/llvm-project/lldb/source/Target/Memory.cpp:347 #10 0x0000000001fe5385 in AllocateMemory () at /usr/src/contrib/llvm-project/lldb/source/Target/Memory.cpp:383 #11 0x0000000001974da2 in AllocateMemory () at /usr/src/contrib/llvm-project/lldb/source/Target/Process.cpp:2301 #12 CanJIT () at /usr/src/contrib/llvm-project/lldb/source/Target/Process.cpp:2331 #13 0x0000000001a1bf3d in Evaluate () at /usr/src/contrib/llvm-project/lldb/source/Expression/UserExpression.cpp:190 #14 0x00000000019ce7a2 in EvaluateExpression () at /usr/src/contrib/llvm-project/lldb/source/Target/Target.cpp:2372 #15 0x0000000001ad784c in EvaluateExpression () at /usr/src/contrib/llvm-project/lldb/source/Commands/CommandObjectExpression.cpp:414 #16 0x0000000001ad86ae in DoExecute () at /usr/src/contrib/llvm-project/lldb/source/Commands/CommandObjectExpression.cpp:646 #17 0x0000000001a5e3ed in Execute () at /usr/src/contrib/llvm-project/lldb/source/Interpreter/CommandObject.cpp:1003 #18 0x0000000001a6c4a3 in HandleCommand () at /usr/src/contrib/llvm-project/lldb/source/Interpreter/CommandInterpreter.cpp:1762 #19 0x0000000001a6f98c in IOHandlerInputComplete () at /usr/src/contrib/llvm-project/lldb/source/Interpreter/CommandInterpreter.cpp:2760 #20 0x0000000001a90b08 in Run () at /usr/src/contrib/llvm-project/lldb/source/Core/IOHandler.cpp:548 #21 0x00000000019a6c6a in ExecuteIOHandlers () at /usr/src/contrib/llvm-project/lldb/source/Core/Debugger.cpp:903 #22 0x0000000001a70337 in RunCommandInterpreter () at /usr/src/contrib/llvm-project/lldb/source/Interpreter/CommandInterpreter.cpp:2946 #23 0x0000000001d9d812 in RunCommandInterpreter () at /usr/src/contrib/llvm-project/lldb/source/API/SBDebugger.cpp:1169 #24 0x0000000001918be8 in MainLoop () at /usr/src/contrib/llvm-project/lldb/tools/driver/Driver.cpp:675 #25 0x000000000191a114 in main () at /usr/src/contrib/llvm-project/lldb/tools/driver/Driver.cpp:890 Fix the incorrect error catch by only instantiating an Error object if it is necessary. Reviewed By: JDevlieghere Differential Revision: https://reviews.llvm.org/D86355 This should fix lldb aborting as described in the scenario above. Reported by: dmgk PR: 248745
uqs
pushed a commit
that referenced
this pull request
Dec 30, 2020
Merge commit 1ce07cd614be from llvm git (by me): Instantiate Error in Target::GetEntryPointAddress() only when necessary When Target::GetEntryPointAddress() calls exe_module->GetObjectFile()->GetEntryPointAddress(), and the returned entry_addr is valid, it can immediately be returned. However, just before that, an llvm::Error value has been setup, but in this case it is not consumed before returning, like is done further below in the function. In https://bugs.freebsd.org/248745 we got a bug report for this, where a very simple test case aborts and dumps core: * thread #1, name = 'testcase', stop reason = breakpoint 1.1 frame #0: 0x00000000002018d4 testcase`main(argc=1, argv=0x00007fffffffea18) at testcase.c:3:5 1 int main(int argc, char *argv[]) 2 { -> 3 return 0; 4 } (lldb) p argc Program aborted due to an unhandled Error: Error value was Success. (Note: Success values must still be checked prior to being destroyed). Thread 1 received signal SIGABRT, Aborted. thr_kill () at thr_kill.S:3 3 thr_kill.S: No such file or directory. (gdb) bt #0 thr_kill () at thr_kill.S:3 #1 0x00000008049a0004 in __raise (s=6) at /usr/src/lib/libc/gen/raise.c:52 #2 0x0000000804916229 in abort () at /usr/src/lib/libc/stdlib/abort.c:67 #3 0x000000000451b5f5 in fatalUncheckedError () at /usr/src/contrib/llvm-project/llvm/lib/Support/Error.cpp:112 #4 0x00000000019cf008 in GetEntryPointAddress () at /usr/src/contrib/llvm-project/llvm/include/llvm/Support/Error.h:267 #5 0x0000000001bccbd8 in ConstructorSetup () at /usr/src/contrib/llvm-project/lldb/source/Target/ThreadPlanCallFunction.cpp:67 #6 0x0000000001bcd2c0 in ThreadPlanCallFunction () at /usr/src/contrib/llvm-project/lldb/source/Target/ThreadPlanCallFunction.cpp:114 #7 0x00000000020076d4 in InferiorCallMmap () at /usr/src/contrib/llvm-project/lldb/source/Plugins/Process/Utility/InferiorCallPOSIX.cpp:97 #8 0x0000000001f4be33 in DoAllocateMemory () at /usr/src/contrib/llvm-project/lldb/source/Plugins/Process/FreeBSD/ProcessFreeBSD.cpp:604 #9 0x0000000001fe51b9 in AllocatePage () at /usr/src/contrib/llvm-project/lldb/source/Target/Memory.cpp:347 #10 0x0000000001fe5385 in AllocateMemory () at /usr/src/contrib/llvm-project/lldb/source/Target/Memory.cpp:383 #11 0x0000000001974da2 in AllocateMemory () at /usr/src/contrib/llvm-project/lldb/source/Target/Process.cpp:2301 #12 CanJIT () at /usr/src/contrib/llvm-project/lldb/source/Target/Process.cpp:2331 #13 0x0000000001a1bf3d in Evaluate () at /usr/src/contrib/llvm-project/lldb/source/Expression/UserExpression.cpp:190 #14 0x00000000019ce7a2 in EvaluateExpression () at /usr/src/contrib/llvm-project/lldb/source/Target/Target.cpp:2372 #15 0x0000000001ad784c in EvaluateExpression () at /usr/src/contrib/llvm-project/lldb/source/Commands/CommandObjectExpression.cpp:414 #16 0x0000000001ad86ae in DoExecute () at /usr/src/contrib/llvm-project/lldb/source/Commands/CommandObjectExpression.cpp:646 #17 0x0000000001a5e3ed in Execute () at /usr/src/contrib/llvm-project/lldb/source/Interpreter/CommandObject.cpp:1003 #18 0x0000000001a6c4a3 in HandleCommand () at /usr/src/contrib/llvm-project/lldb/source/Interpreter/CommandInterpreter.cpp:1762 #19 0x0000000001a6f98c in IOHandlerInputComplete () at /usr/src/contrib/llvm-project/lldb/source/Interpreter/CommandInterpreter.cpp:2760 #20 0x0000000001a90b08 in Run () at /usr/src/contrib/llvm-project/lldb/source/Core/IOHandler.cpp:548 #21 0x00000000019a6c6a in ExecuteIOHandlers () at /usr/src/contrib/llvm-project/lldb/source/Core/Debugger.cpp:903 #22 0x0000000001a70337 in RunCommandInterpreter () at /usr/src/contrib/llvm-project/lldb/source/Interpreter/CommandInterpreter.cpp:2946 #23 0x0000000001d9d812 in RunCommandInterpreter () at /usr/src/contrib/llvm-project/lldb/source/API/SBDebugger.cpp:1169 #24 0x0000000001918be8 in MainLoop () at /usr/src/contrib/llvm-project/lldb/tools/driver/Driver.cpp:675 #25 0x000000000191a114 in main () at /usr/src/contrib/llvm-project/lldb/tools/driver/Driver.cpp:890 Fix the incorrect error catch by only instantiating an Error object if it is necessary. Reviewed By: JDevlieghere Differential Revision: https://reviews.llvm.org/D86355 This should fix lldb aborting as described in the scenario above. Reported by: dmgk PR: 248745
guyyur
added a commit
to guyyur/freebsd-src
that referenced
this pull request
Mar 24, 2021
… we have no API for controlling the latter. This fixes a long standing problem where addresses added with non /128 prefixes and non infinite address lifetimes would register a prefix route which would expire. Subsequent calls set new lifetimes for the same address would not affect the prefix route management, so once expired, the prefix route would be impossible to add back as the kernel would remove it. Based on NetBSD changes (and reusing the commit message): sys/netinet6/in6.c 1.216 sys/netinet6/in6.c 1.217 sys/netinet6/in6.c 1.218 sys/netinet6/in6_ifattach.c 1.104 sys/netinet6/nd6_rtr.c 1.119 Also fixes a panic with INVARIANTS set and running "ndp -P" after an IPv6 address is manually added and the same prefix for the address is learned via router advertisment. freebsd#11 0xffffffff805d42b0 in kassert_panic (fmt=0xffffffff80939e3a "prefix %p has referencing addresses") at /usr/src/sys/kern/kern_shutdown.c:723 freebsd#12 0xffffffff807d4049 in nd6_prefix_del (pr=0xfffff800043c0400) at /usr/src/sys/netinet6/nd6_rtr.c:1189 freebsd#13 0xffffffff807caf38 in nd6_ioctl (cmd=<optimized out>, data=<optimized out>, ifp=0xfffff80002337000) at /usr/src/sys/netinet6/nd6.c:1831 PR: 195197
guyyur
added a commit
to guyyur/freebsd-src
that referenced
this pull request
Mar 25, 2021
… we have no API for controlling the latter. This fixes a long standing problem where addresses added with non /128 prefixes and non infinite address lifetimes would register a prefix route which would expire. Subsequent calls set new lifetimes for the same address would not affect the prefix route management, so once expired, the prefix route would be impossible to add back as the kernel would remove it. Based on NetBSD changes (and reusing the commit message): sys/netinet6/in6.c 1.216 sys/netinet6/in6.c 1.217 sys/netinet6/in6.c 1.218 sys/netinet6/in6_ifattach.c 1.104 sys/netinet6/nd6_rtr.c 1.119 Also fixes a panic with INVARIANTS set and running "ndp -P" after an IPv6 address is manually added and the same prefix for the address is learned via router advertisment. freebsd#11 0xffffffff805d42b0 in kassert_panic (fmt=0xffffffff80939e3a "prefix %p has referencing addresses") at /usr/src/sys/kern/kern_shutdown.c:723 freebsd#12 0xffffffff807d4049 in nd6_prefix_del (pr=0xfffff800043c0400) at /usr/src/sys/netinet6/nd6_rtr.c:1189 freebsd#13 0xffffffff807caf38 in nd6_ioctl (cmd=<optimized out>, data=<optimized out>, ifp=0xfffff80002337000) at /usr/src/sys/netinet6/nd6.c:1831 PR: 195197
guyyur
added a commit
to guyyur/freebsd-src
that referenced
this pull request
Mar 25, 2021
… we have no API for controlling the latter. This fixes a long standing problem where addresses added with non /128 prefixes and non infinite address lifetimes would register a prefix route which would expire. Subsequent calls set new lifetimes for the same address would not affect the prefix route management, so once expired, the prefix route would be impossible to add back as the kernel would remove it. Based on NetBSD changes (and reusing the commit message): sys/netinet6/in6.c 1.216 sys/netinet6/in6.c 1.217 sys/netinet6/in6.c 1.218 sys/netinet6/in6_ifattach.c 1.104 sys/netinet6/nd6_rtr.c 1.119 Also fixes a panic with INVARIANTS set and running "ndp -P" after an IPv6 address is manually added and the same prefix for the address is learned via router advertisment. freebsd#11 0xffffffff805d42b0 in kassert_panic (fmt=0xffffffff80939e3a "prefix %p has referencing addresses") at /usr/src/sys/kern/kern_shutdown.c:723 freebsd#12 0xffffffff807d4049 in nd6_prefix_del (pr=0xfffff800043c0400) at /usr/src/sys/netinet6/nd6_rtr.c:1189 freebsd#13 0xffffffff807caf38 in nd6_ioctl (cmd=<optimized out>, data=<optimized out>, ifp=0xfffff80002337000) at /usr/src/sys/netinet6/nd6.c:1831 PR: 195197
guyyur
added a commit
to guyyur/freebsd-src
that referenced
this pull request
Mar 25, 2021
… we have no API for controlling the latter. This fixes a long standing problem where addresses added with non /128 prefixes and non infinite address lifetimes would register a prefix route which would expire. Subsequent calls set new lifetimes for the same address would not affect the prefix route management, so once expired, the prefix route would be impossible to add back as the kernel would remove it. Based on NetBSD changes (and reusing the commit message): sys/netinet6/in6.c 1.216 sys/netinet6/in6.c 1.217 sys/netinet6/in6.c 1.218 sys/netinet6/in6_ifattach.c 1.104 sys/netinet6/nd6_rtr.c 1.119 Also fixes a panic with INVARIANTS set and running "ndp -P" after an IPv6 address is manually added and the same prefix for the address is learned via router advertisment. freebsd#11 0xffffffff805d42b0 in kassert_panic (fmt=0xffffffff80939e3a "prefix %p has referencing addresses") at /usr/src/sys/kern/kern_shutdown.c:723 freebsd#12 0xffffffff807d4049 in nd6_prefix_del (pr=0xfffff800043c0400) at /usr/src/sys/netinet6/nd6_rtr.c:1189 freebsd#13 0xffffffff807caf38 in nd6_ioctl (cmd=<optimized out>, data=<optimized out>, ifp=0xfffff80002337000) at /usr/src/sys/netinet6/nd6.c:1831 PR: 195197
guyyur
added a commit
to guyyur/freebsd-src
that referenced
this pull request
Mar 25, 2021
… we have no API for controlling the latter. This fixes a long standing problem where addresses added with non /128 prefixes and non infinite address lifetimes would register a prefix route which would expire. Subsequent calls set new lifetimes for the same address would not affect the prefix route management, so once expired, the prefix route would be impossible to add back as the kernel would remove it. Based on NetBSD changes (and reusing the commit message): sys/netinet6/in6.c 1.216 sys/netinet6/in6.c 1.217 sys/netinet6/in6.c 1.218 sys/netinet6/in6_ifattach.c 1.104 sys/netinet6/nd6_rtr.c 1.119 Also fixes a panic with INVARIANTS set and running "ndp -P" after an IPv6 address is manually added and the same prefix for the address is learned via router advertisment. freebsd#11 0xffffffff805d42b0 in kassert_panic (fmt=0xffffffff80939e3a "prefix %p has referencing addresses") at /usr/src/sys/kern/kern_shutdown.c:723 freebsd#12 0xffffffff807d4049 in nd6_prefix_del (pr=0xfffff800043c0400) at /usr/src/sys/netinet6/nd6_rtr.c:1189 freebsd#13 0xffffffff807caf38 in nd6_ioctl (cmd=<optimized out>, data=<optimized out>, ifp=0xfffff80002337000) at /usr/src/sys/netinet6/nd6.c:1831 PR: 195197
guyyur
added a commit
to guyyur/freebsd-src
that referenced
this pull request
Mar 25, 2021
… we have no API for controlling the latter. This fixes a long standing problem where addresses added with non /128 prefixes and non infinite address lifetimes would register a prefix route which would expire. Subsequent calls set new lifetimes for the same address would not affect the prefix route management, so once expired, the prefix route would be impossible to add back as the kernel would remove it. Based on NetBSD changes (and reusing the commit message): sys/netinet6/in6.c 1.216 sys/netinet6/in6.c 1.217 sys/netinet6/in6.c 1.218 sys/netinet6/in6_ifattach.c 1.104 sys/netinet6/nd6_rtr.c 1.119 Also fixes a panic with INVARIANTS set and running "ndp -P" after an IPv6 address is manually added and the same prefix for the address is learned via router advertisment. freebsd#11 0xffffffff805d42b0 in kassert_panic (fmt=0xffffffff80939e3a "prefix %p has referencing addresses") at /usr/src/sys/kern/kern_shutdown.c:723 freebsd#12 0xffffffff807d4049 in nd6_prefix_del (pr=0xfffff800043c0400) at /usr/src/sys/netinet6/nd6_rtr.c:1189 freebsd#13 0xffffffff807caf38 in nd6_ioctl (cmd=<optimized out>, data=<optimized out>, ifp=0xfffff80002337000) at /usr/src/sys/netinet6/nd6.c:1831 PR: 195197
guyyur
added a commit
to guyyur/freebsd-src
that referenced
this pull request
Mar 25, 2021
… we have no API for controlling the latter. This fixes a long standing problem where addresses added with non /128 prefixes and non infinite address lifetimes would register a prefix route which would expire. Subsequent calls set new lifetimes for the same address would not affect the prefix route management, so once expired, the prefix route would be impossible to add back as the kernel would remove it. Based on NetBSD changes (and reusing the commit message): sys/netinet6/in6.c 1.216 sys/netinet6/in6.c 1.217 sys/netinet6/in6.c 1.218 sys/netinet6/in6_ifattach.c 1.104 sys/netinet6/nd6_rtr.c 1.119 Also fixes a panic with INVARIANTS set and running "ndp -P" after an IPv6 address is manually added and the same prefix for the address is learned via router advertisment. freebsd#11 0xffffffff805d42b0 in kassert_panic (fmt=0xffffffff80939e3a "prefix %p has referencing addresses") at /usr/src/sys/kern/kern_shutdown.c:723 freebsd#12 0xffffffff807d4049 in nd6_prefix_del (pr=0xfffff800043c0400) at /usr/src/sys/netinet6/nd6_rtr.c:1189 freebsd#13 0xffffffff807caf38 in nd6_ioctl (cmd=<optimized out>, data=<optimized out>, ifp=0xfffff80002337000) at /usr/src/sys/netinet6/nd6.c:1831 PR: 195197
guyyur
added a commit
to guyyur/freebsd-src
that referenced
this pull request
Mar 25, 2021
… we have no API for controlling the latter. This fixes a long standing problem where addresses added with non /128 prefixes and non infinite address lifetimes would register a prefix route which would expire. Subsequent calls set new lifetimes for the same address would not affect the prefix route management, so once expired, the prefix route would be impossible to add back as the kernel would remove it. Based on NetBSD changes (and reusing the commit message): sys/netinet6/in6.c 1.216 sys/netinet6/in6.c 1.217 sys/netinet6/in6.c 1.218 sys/netinet6/in6_ifattach.c 1.104 sys/netinet6/nd6_rtr.c 1.119 Also fixes a panic with INVARIANTS set and running "ndp -P" after an IPv6 address is manually added and the same prefix for the address is learned via router advertisment. freebsd#11 0xffffffff805d42b0 in kassert_panic (fmt=0xffffffff80939e3a "prefix %p has referencing addresses") at /usr/src/sys/kern/kern_shutdown.c:723 freebsd#12 0xffffffff807d4049 in nd6_prefix_del (pr=0xfffff800043c0400) at /usr/src/sys/netinet6/nd6_rtr.c:1189 freebsd#13 0xffffffff807caf38 in nd6_ioctl (cmd=<optimized out>, data=<optimized out>, ifp=0xfffff80002337000) at /usr/src/sys/netinet6/nd6.c:1831 PR: 195197
guyyur
added a commit
to guyyur/freebsd-src
that referenced
this pull request
Mar 27, 2021
… we have no API for controlling the latter. This fixes a long standing problem where addresses added with non /128 prefixes and non infinite address lifetimes would register a prefix route which would expire. Subsequent calls set new lifetimes for the same address would not affect the prefix route management, so once expired, the prefix route would be impossible to add back as the kernel would remove it. Based on NetBSD changes (and reusing the commit message): sys/netinet6/in6.c 1.216 sys/netinet6/in6.c 1.217 sys/netinet6/in6.c 1.218 sys/netinet6/in6_ifattach.c 1.104 sys/netinet6/nd6_rtr.c 1.119 Also fixes a panic with INVARIANTS set and running "ndp -P" after an IPv6 address is manually added and the same prefix for the address is learned via router advertisment. freebsd#11 0xffffffff805d42b0 in kassert_panic (fmt=0xffffffff80939e3a "prefix %p has referencing addresses") at /usr/src/sys/kern/kern_shutdown.c:723 freebsd#12 0xffffffff807d4049 in nd6_prefix_del (pr=0xfffff800043c0400) at /usr/src/sys/netinet6/nd6_rtr.c:1189 freebsd#13 0xffffffff807caf38 in nd6_ioctl (cmd=<optimized out>, data=<optimized out>, ifp=0xfffff80002337000) at /usr/src/sys/netinet6/nd6.c:1831 PR: 195197
guyyur
added a commit
to guyyur/freebsd-src
that referenced
this pull request
Mar 30, 2021
… we have no API for controlling the latter. This fixes a long standing problem where addresses added with non /128 prefixes and non infinite address lifetimes would register a prefix route which would expire. Subsequent calls set new lifetimes for the same address would not affect the prefix route management, so once expired, the prefix route would be impossible to add back as the kernel would remove it. Based on NetBSD changes (and reusing the commit message): sys/netinet6/in6.c 1.216 sys/netinet6/in6.c 1.217 sys/netinet6/in6.c 1.218 sys/netinet6/in6_ifattach.c 1.104 sys/netinet6/nd6_rtr.c 1.119 Also fixes a panic with INVARIANTS set and running "ndp -P" after an IPv6 address is manually added and the same prefix for the address is learned via router advertisment. freebsd#11 0xffffffff805d42b0 in kassert_panic (fmt=0xffffffff80939e3a "prefix %p has referencing addresses") at /usr/src/sys/kern/kern_shutdown.c:723 freebsd#12 0xffffffff807d4049 in nd6_prefix_del (pr=0xfffff800043c0400) at /usr/src/sys/netinet6/nd6_rtr.c:1189 freebsd#13 0xffffffff807caf38 in nd6_ioctl (cmd=<optimized out>, data=<optimized out>, ifp=0xfffff80002337000) at /usr/src/sys/netinet6/nd6.c:1831 PR: 195197
guyyur
added a commit
to guyyur/freebsd-src
that referenced
this pull request
Apr 3, 2021
… we have no API for controlling the latter. This fixes a long standing problem where addresses added with non /128 prefixes and non infinite address lifetimes would register a prefix route which would expire. Subsequent calls set new lifetimes for the same address would not affect the prefix route management, so once expired, the prefix route would be impossible to add back as the kernel would remove it. Based on NetBSD changes (and reusing the commit message): sys/netinet6/in6.c 1.216 sys/netinet6/in6.c 1.217 sys/netinet6/in6.c 1.218 sys/netinet6/in6_ifattach.c 1.104 sys/netinet6/nd6_rtr.c 1.119 Also fixes a panic with INVARIANTS set and running "ndp -P" after an IPv6 address is manually added and the same prefix for the address is learned via router advertisment. freebsd#11 0xffffffff805d42b0 in kassert_panic (fmt=0xffffffff80939e3a "prefix %p has referencing addresses") at /usr/src/sys/kern/kern_shutdown.c:723 freebsd#12 0xffffffff807d4049 in nd6_prefix_del (pr=0xfffff800043c0400) at /usr/src/sys/netinet6/nd6_rtr.c:1189 freebsd#13 0xffffffff807caf38 in nd6_ioctl (cmd=<optimized out>, data=<optimized out>, ifp=0xfffff80002337000) at /usr/src/sys/netinet6/nd6.c:1831 PR: 195197
guyyur
added a commit
to guyyur/freebsd-src
that referenced
this pull request
Apr 5, 2021
… we have no API for controlling the latter. This fixes a long standing problem where addresses added with non /128 prefixes and non infinite address lifetimes would register a prefix route which would expire. Subsequent calls set new lifetimes for the same address would not affect the prefix route management, so once expired, the prefix route would be impossible to add back as the kernel would remove it. Based on NetBSD changes (and reusing the commit message): sys/netinet6/in6.c 1.216 sys/netinet6/in6.c 1.217 sys/netinet6/in6.c 1.218 sys/netinet6/in6_ifattach.c 1.104 sys/netinet6/nd6_rtr.c 1.119 Also fixes a panic with INVARIANTS set and running "ndp -P" after an IPv6 address is manually added and the same prefix for the address is learned via router advertisment. freebsd#11 0xffffffff805d42b0 in kassert_panic (fmt=0xffffffff80939e3a "prefix %p has referencing addresses") at /usr/src/sys/kern/kern_shutdown.c:723 freebsd#12 0xffffffff807d4049 in nd6_prefix_del (pr=0xfffff800043c0400) at /usr/src/sys/netinet6/nd6_rtr.c:1189 freebsd#13 0xffffffff807caf38 in nd6_ioctl (cmd=<optimized out>, data=<optimized out>, ifp=0xfffff80002337000) at /usr/src/sys/netinet6/nd6.c:1831 PR: 195197
guyyur
added a commit
to guyyur/freebsd-src
that referenced
this pull request
Apr 5, 2021
… we have no API for controlling the latter. This fixes a long standing problem where addresses added with non /128 prefixes and non infinite address lifetimes would register a prefix route which would expire. Subsequent calls set new lifetimes for the same address would not affect the prefix route management, so once expired, the prefix route would be impossible to add back as the kernel would remove it. Based on NetBSD changes (and reusing the commit message): sys/netinet6/in6.c 1.216 sys/netinet6/in6.c 1.217 sys/netinet6/in6.c 1.218 sys/netinet6/in6_ifattach.c 1.104 sys/netinet6/nd6_rtr.c 1.119 Also fixes a panic with INVARIANTS set and running "ndp -P" after an IPv6 address is manually added and the same prefix for the address is learned via router advertisment. freebsd#11 0xffffffff805d42b0 in kassert_panic (fmt=0xffffffff80939e3a "prefix %p has referencing addresses") at /usr/src/sys/kern/kern_shutdown.c:723 freebsd#12 0xffffffff807d4049 in nd6_prefix_del (pr=0xfffff800043c0400) at /usr/src/sys/netinet6/nd6_rtr.c:1189 freebsd#13 0xffffffff807caf38 in nd6_ioctl (cmd=<optimized out>, data=<optimized out>, ifp=0xfffff80002337000) at /usr/src/sys/netinet6/nd6.c:1831 PR: 195197
freebsd-git
pushed a commit
that referenced
this pull request
Apr 6, 2021
Merge commit 1ce07cd614be from llvm git (by me): Instantiate Error in Target::GetEntryPointAddress() only when necessary When Target::GetEntryPointAddress() calls exe_module->GetObjectFile()->GetEntryPointAddress(), and the returned entry_addr is valid, it can immediately be returned. However, just before that, an llvm::Error value has been setup, but in this case it is not consumed before returning, like is done further below in the function. In https://bugs.freebsd.org/248745 we got a bug report for this, where a very simple test case aborts and dumps core: * thread #1, name = 'testcase', stop reason = breakpoint 1.1 frame #0: 0x00000000002018d4 testcase`main(argc=1, argv=0x00007fffffffea18) at testcase.c:3:5 1 int main(int argc, char *argv[]) 2 { -> 3 return 0; 4 } (lldb) p argc Program aborted due to an unhandled Error: Error value was Success. (Note: Success values must still be checked prior to being destroyed). Thread 1 received signal SIGABRT, Aborted. thr_kill () at thr_kill.S:3 3 thr_kill.S: No such file or directory. (gdb) bt #0 thr_kill () at thr_kill.S:3 #1 0x00000008049a0004 in __raise (s=6) at /usr/src/lib/libc/gen/raise.c:52 #2 0x0000000804916229 in abort () at /usr/src/lib/libc/stdlib/abort.c:67 #3 0x000000000451b5f5 in fatalUncheckedError () at /usr/src/contrib/llvm-project/llvm/lib/Support/Error.cpp:112 #4 0x00000000019cf008 in GetEntryPointAddress () at /usr/src/contrib/llvm-project/llvm/include/llvm/Support/Error.h:267 #5 0x0000000001bccbd8 in ConstructorSetup () at /usr/src/contrib/llvm-project/lldb/source/Target/ThreadPlanCallFunction.cpp:67 #6 0x0000000001bcd2c0 in ThreadPlanCallFunction () at /usr/src/contrib/llvm-project/lldb/source/Target/ThreadPlanCallFunction.cpp:114 #7 0x00000000020076d4 in InferiorCallMmap () at /usr/src/contrib/llvm-project/lldb/source/Plugins/Process/Utility/InferiorCallPOSIX.cpp:97 #8 0x0000000001f4be33 in DoAllocateMemory () at /usr/src/contrib/llvm-project/lldb/source/Plugins/Process/FreeBSD/ProcessFreeBSD.cpp:604 #9 0x0000000001fe51b9 in AllocatePage () at /usr/src/contrib/llvm-project/lldb/source/Target/Memory.cpp:347 #10 0x0000000001fe5385 in AllocateMemory () at /usr/src/contrib/llvm-project/lldb/source/Target/Memory.cpp:383 #11 0x0000000001974da2 in AllocateMemory () at /usr/src/contrib/llvm-project/lldb/source/Target/Process.cpp:2301 #12 CanJIT () at /usr/src/contrib/llvm-project/lldb/source/Target/Process.cpp:2331 #13 0x0000000001a1bf3d in Evaluate () at /usr/src/contrib/llvm-project/lldb/source/Expression/UserExpression.cpp:190 #14 0x00000000019ce7a2 in EvaluateExpression () at /usr/src/contrib/llvm-project/lldb/source/Target/Target.cpp:2372 #15 0x0000000001ad784c in EvaluateExpression () at /usr/src/contrib/llvm-project/lldb/source/Commands/CommandObjectExpression.cpp:414 #16 0x0000000001ad86ae in DoExecute () at /usr/src/contrib/llvm-project/lldb/source/Commands/CommandObjectExpression.cpp:646 #17 0x0000000001a5e3ed in Execute () at /usr/src/contrib/llvm-project/lldb/source/Interpreter/CommandObject.cpp:1003 #18 0x0000000001a6c4a3 in HandleCommand () at /usr/src/contrib/llvm-project/lldb/source/Interpreter/CommandInterpreter.cpp:1762 #19 0x0000000001a6f98c in IOHandlerInputComplete () at /usr/src/contrib/llvm-project/lldb/source/Interpreter/CommandInterpreter.cpp:2760 #20 0x0000000001a90b08 in Run () at /usr/src/contrib/llvm-project/lldb/source/Core/IOHandler.cpp:548 #21 0x00000000019a6c6a in ExecuteIOHandlers () at /usr/src/contrib/llvm-project/lldb/source/Core/Debugger.cpp:903 #22 0x0000000001a70337 in RunCommandInterpreter () at /usr/src/contrib/llvm-project/lldb/source/Interpreter/CommandInterpreter.cpp:2946 #23 0x0000000001d9d812 in RunCommandInterpreter () at /usr/src/contrib/llvm-project/lldb/source/API/SBDebugger.cpp:1169 #24 0x0000000001918be8 in MainLoop () at /usr/src/contrib/llvm-project/lldb/tools/driver/Driver.cpp:675 #25 0x000000000191a114 in main () at /usr/src/contrib/llvm-project/lldb/tools/driver/Driver.cpp:890 Fix the incorrect error catch by only instantiating an Error object if it is necessary. Reviewed By: JDevlieghere Differential Revision: https://reviews.llvm.org/D86355 This should fix lldb aborting as described in the scenario above. Reported by: dmgk PR: 248745 Approved by: so Security: FreeBSD-EN-21:07.lldb (cherry picked from commit eb41eed)
guyyur
added a commit
to guyyur/freebsd-src
that referenced
this pull request
Apr 16, 2021
… we have no API for controlling the latter. This fixes a long standing problem where addresses added with non /128 prefixes and non infinite address lifetimes would register a prefix route which would expire. Subsequent calls set new lifetimes for the same address would not affect the prefix route management, so once expired, the prefix route would be impossible to add back as the kernel would remove it. Based on NetBSD changes (and reusing the commit message): sys/netinet6/in6.c 1.216 sys/netinet6/in6.c 1.217 sys/netinet6/in6.c 1.218 sys/netinet6/in6_ifattach.c 1.104 sys/netinet6/nd6_rtr.c 1.119 Also fixes a panic with INVARIANTS set and running "ndp -P" after an IPv6 address is manually added and the same prefix for the address is learned via router advertisment. freebsd#11 0xffffffff805d42b0 in kassert_panic (fmt=0xffffffff80939e3a "prefix %p has referencing addresses") at /usr/src/sys/kern/kern_shutdown.c:723 freebsd#12 0xffffffff807d4049 in nd6_prefix_del (pr=0xfffff800043c0400) at /usr/src/sys/netinet6/nd6_rtr.c:1189 freebsd#13 0xffffffff807caf38 in nd6_ioctl (cmd=<optimized out>, data=<optimized out>, ifp=0xfffff80002337000) at /usr/src/sys/netinet6/nd6.c:1831 PR: 195197
guyyur
added a commit
to guyyur/freebsd-src
that referenced
this pull request
May 18, 2021
… we have no API for controlling the latter. This fixes a long standing problem where addresses added with non /128 prefixes and non infinite address lifetimes would register a prefix route which would expire. Subsequent calls set new lifetimes for the same address would not affect the prefix route management, so once expired, the prefix route would be impossible to add back as the kernel would remove it. Based on NetBSD changes (and reusing the commit message): sys/netinet6/in6.c 1.216 sys/netinet6/in6.c 1.217 sys/netinet6/in6.c 1.218 sys/netinet6/in6_ifattach.c 1.104 sys/netinet6/nd6_rtr.c 1.119 Also fixes a panic with INVARIANTS set and running "ndp -P" after an IPv6 address is manually added and the same prefix for the address is learned via router advertisment. freebsd#11 0xffffffff805d42b0 in kassert_panic (fmt=0xffffffff80939e3a "prefix %p has referencing addresses") at /usr/src/sys/kern/kern_shutdown.c:723 freebsd#12 0xffffffff807d4049 in nd6_prefix_del (pr=0xfffff800043c0400) at /usr/src/sys/netinet6/nd6_rtr.c:1189 freebsd#13 0xffffffff807caf38 in nd6_ioctl (cmd=<optimized out>, data=<optimized out>, ifp=0xfffff80002337000) at /usr/src/sys/netinet6/nd6.c:1831 PR: 195197
guyyur
added a commit
to guyyur/freebsd-src
that referenced
this pull request
Jan 20, 2023
… we have no API for controlling the latter. This fixes a long standing problem where addresses added with non /128 prefixes and non infinite address lifetimes would register a prefix route which would expire. Subsequent calls set new lifetimes for the same address would not affect the prefix route management, so once expired, the prefix route would be impossible to add back as the kernel would remove it. Based on NetBSD changes (and reusing the commit message): sys/netinet6/in6.c 1.216 sys/netinet6/in6.c 1.217 sys/netinet6/in6.c 1.218 sys/netinet6/in6_ifattach.c 1.104 sys/netinet6/nd6_rtr.c 1.119 Also fixes a panic with INVARIANTS set and running "ndp -P" after an IPv6 address is manually added and the same prefix for the address is learned via router advertisment. freebsd#11 0xffffffff805d42b0 in kassert_panic (fmt=0xffffffff80939e3a "prefix %p has referencing addresses") at /usr/src/sys/kern/kern_shutdown.c:723 freebsd#12 0xffffffff807d4049 in nd6_prefix_del (pr=0xfffff800043c0400) at /usr/src/sys/netinet6/nd6_rtr.c:1189 freebsd#13 0xffffffff807caf38 in nd6_ioctl (cmd=<optimized out>, data=<optimized out>, ifp=0xfffff80002337000) at /usr/src/sys/netinet6/nd6.c:1831 PR: 195197
guyyur
added a commit
to guyyur/freebsd-src
that referenced
this pull request
Jan 31, 2023
… we have no API for controlling the latter. This fixes a long standing problem where addresses added with non /128 prefixes and non infinite address lifetimes would register a prefix route which would expire. Subsequent calls set new lifetimes for the same address would not affect the prefix route management, so once expired, the prefix route would be impossible to add back as the kernel would remove it. Based on NetBSD changes (and reusing the commit message): sys/netinet6/in6.c 1.216 sys/netinet6/in6.c 1.217 sys/netinet6/in6.c 1.218 sys/netinet6/in6_ifattach.c 1.104 sys/netinet6/nd6_rtr.c 1.119 Also fixes a panic with INVARIANTS set and running "ndp -P" after an IPv6 address is manually added and the same prefix for the address is learned via router advertisment. freebsd#11 0xffffffff805d42b0 in kassert_panic (fmt=0xffffffff80939e3a "prefix %p has referencing addresses") at /usr/src/sys/kern/kern_shutdown.c:723 freebsd#12 0xffffffff807d4049 in nd6_prefix_del (pr=0xfffff800043c0400) at /usr/src/sys/netinet6/nd6_rtr.c:1189 freebsd#13 0xffffffff807caf38 in nd6_ioctl (cmd=<optimized out>, data=<optimized out>, ifp=0xfffff80002337000) at /usr/src/sys/netinet6/nd6.c:1831 PR: 195197
guyyur
added a commit
to guyyur/freebsd-src
that referenced
this pull request
Mar 2, 2023
… we have no API for controlling the latter. This fixes a long standing problem where addresses added with non /128 prefixes and non infinite address lifetimes would register a prefix route which would expire. Subsequent calls set new lifetimes for the same address would not affect the prefix route management, so once expired, the prefix route would be impossible to add back as the kernel would remove it. Based on NetBSD changes (and reusing the commit message): sys/netinet6/in6.c 1.216 sys/netinet6/in6.c 1.217 sys/netinet6/in6.c 1.218 sys/netinet6/in6_ifattach.c 1.104 sys/netinet6/nd6_rtr.c 1.119 Also fixes a panic with INVARIANTS set and running "ndp -P" after an IPv6 address is manually added and the same prefix for the address is learned via router advertisment. freebsd#11 0xffffffff805d42b0 in kassert_panic (fmt=0xffffffff80939e3a "prefix %p has referencing addresses") at /usr/src/sys/kern/kern_shutdown.c:723 freebsd#12 0xffffffff807d4049 in nd6_prefix_del (pr=0xfffff800043c0400) at /usr/src/sys/netinet6/nd6_rtr.c:1189 freebsd#13 0xffffffff807caf38 in nd6_ioctl (cmd=<optimized out>, data=<optimized out>, ifp=0xfffff80002337000) at /usr/src/sys/netinet6/nd6.c:1831 PR: 195197
dnelson-1901
pushed a commit
to dnelson-1901/freebsd-src
that referenced
this pull request
Mar 23, 2023
Under certain loads, the following panic is hit: panic: page fault KDB: stack backtrace: #0 0xffffffff805db025 at kdb_backtrace+0x65 freebsd#1 0xffffffff8058e86f at vpanic+0x17f freebsd#2 0xffffffff8058e6e3 at panic+0x43 freebsd#3 0xffffffff808adc15 at trap_fatal+0x385 freebsd#4 0xffffffff808adc6f at trap_pfault+0x4f freebsd#5 0xffffffff80886da8 at calltrap+0x8 freebsd#6 0xffffffff80669186 at vgonel+0x186 freebsd#7 0xffffffff80669841 at vgone+0x31 freebsd#8 0xffffffff8065806d at vfs_hash_insert+0x26d freebsd#9 0xffffffff81a39069 at sfs_vgetx+0x149 freebsd#10 0xffffffff81a39c54 at zfsctl_snapdir_lookup+0x1e4 freebsd#11 0xffffffff8065a28c at lookup+0x45c freebsd#12 0xffffffff806594b9 at namei+0x259 freebsd#13 0xffffffff80676a33 at kern_statat+0xf3 freebsd#14 0xffffffff8067712f at sys_fstatat+0x2f freebsd#15 0xffffffff808ae50c at amd64_syscall+0x10c freebsd#16 0xffffffff808876bb at fast_syscall_common+0xf8 The page fault occurs because vgonel() will call VOP_CLOSE() for active vnodes. For this reason, define vop_close for zfsctl_ops_snapshot. While here, define vop_open for consistency. After adding the necessary vop, the bug progresses to the following panic: panic: VERIFY3(vrecycle(vp) == 1) failed (0 == 1) cpuid = 17 KDB: stack backtrace: #0 0xffffffff805e29c5 at kdb_backtrace+0x65 freebsd#1 0xffffffff8059620f at vpanic+0x17f freebsd#2 0xffffffff81a27f4a at spl_panic+0x3a freebsd#3 0xffffffff81a3a4d0 at zfsctl_snapshot_inactive+0x40 freebsd#4 0xffffffff8066fdee at vinactivef+0xde freebsd#5 0xffffffff80670b8a at vgonel+0x1ea freebsd#6 0xffffffff806711e1 at vgone+0x31 freebsd#7 0xffffffff8065fa0d at vfs_hash_insert+0x26d freebsd#8 0xffffffff81a39069 at sfs_vgetx+0x149 freebsd#9 0xffffffff81a39c54 at zfsctl_snapdir_lookup+0x1e4 freebsd#10 0xffffffff80661c2c at lookup+0x45c freebsd#11 0xffffffff80660e59 at namei+0x259 freebsd#12 0xffffffff8067e3d3 at kern_statat+0xf3 freebsd#13 0xffffffff8067eacf at sys_fstatat+0x2f freebsd#14 0xffffffff808b5ecc at amd64_syscall+0x10c freebsd#15 0xffffffff8088f07b at fast_syscall_common+0xf8 This is caused by a race condition that can occur when allocating a new vnode and adding that vnode to the vfs hash. If the newly created vnode loses the race when being inserted into the vfs hash, it will not be recycled as its usecount is greater than zero, hitting the above assertion. Fix this by dropping the assertion. FreeBSD-issue: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=252700 Reviewed-by: Andriy Gapon <avg@FreeBSD.org> Reviewed-by: Mateusz Guzik <mjguzik@gmail.com> Reviewed-by: Alek Pinchuk <apinchuk@axcient.com> Reviewed-by: Ryan Moeller <ryan@iXsystems.com> Signed-off-by: Rob Wing <rob.wing@klarasystems.com> Co-authored-by: Rob Wing <rob.wing@klarasystems.com> Submitted-by: Klara, Inc. Sponsored-by: rsync.net Closes #14501
dnelson-1901
pushed a commit
to dnelson-1901/freebsd-src
that referenced
this pull request
Jun 15, 2023
Under certain loads, the following panic is hit: panic: page fault KDB: stack backtrace: #0 0xffffffff805db025 at kdb_backtrace+0x65 freebsd#1 0xffffffff8058e86f at vpanic+0x17f freebsd#2 0xffffffff8058e6e3 at panic+0x43 freebsd#3 0xffffffff808adc15 at trap_fatal+0x385 freebsd#4 0xffffffff808adc6f at trap_pfault+0x4f freebsd#5 0xffffffff80886da8 at calltrap+0x8 freebsd#6 0xffffffff80669186 at vgonel+0x186 freebsd#7 0xffffffff80669841 at vgone+0x31 freebsd#8 0xffffffff8065806d at vfs_hash_insert+0x26d freebsd#9 0xffffffff81a39069 at sfs_vgetx+0x149 freebsd#10 0xffffffff81a39c54 at zfsctl_snapdir_lookup+0x1e4 freebsd#11 0xffffffff8065a28c at lookup+0x45c freebsd#12 0xffffffff806594b9 at namei+0x259 freebsd#13 0xffffffff80676a33 at kern_statat+0xf3 freebsd#14 0xffffffff8067712f at sys_fstatat+0x2f freebsd#15 0xffffffff808ae50c at amd64_syscall+0x10c freebsd#16 0xffffffff808876bb at fast_syscall_common+0xf8 The page fault occurs because vgonel() will call VOP_CLOSE() for active vnodes. For this reason, define vop_close for zfsctl_ops_snapshot. While here, define vop_open for consistency. After adding the necessary vop, the bug progresses to the following panic: panic: VERIFY3(vrecycle(vp) == 1) failed (0 == 1) cpuid = 17 KDB: stack backtrace: #0 0xffffffff805e29c5 at kdb_backtrace+0x65 freebsd#1 0xffffffff8059620f at vpanic+0x17f freebsd#2 0xffffffff81a27f4a at spl_panic+0x3a freebsd#3 0xffffffff81a3a4d0 at zfsctl_snapshot_inactive+0x40 freebsd#4 0xffffffff8066fdee at vinactivef+0xde freebsd#5 0xffffffff80670b8a at vgonel+0x1ea freebsd#6 0xffffffff806711e1 at vgone+0x31 freebsd#7 0xffffffff8065fa0d at vfs_hash_insert+0x26d freebsd#8 0xffffffff81a39069 at sfs_vgetx+0x149 freebsd#9 0xffffffff81a39c54 at zfsctl_snapdir_lookup+0x1e4 freebsd#10 0xffffffff80661c2c at lookup+0x45c freebsd#11 0xffffffff80660e59 at namei+0x259 freebsd#12 0xffffffff8067e3d3 at kern_statat+0xf3 freebsd#13 0xffffffff8067eacf at sys_fstatat+0x2f freebsd#14 0xffffffff808b5ecc at amd64_syscall+0x10c freebsd#15 0xffffffff8088f07b at fast_syscall_common+0xf8 This is caused by a race condition that can occur when allocating a new vnode and adding that vnode to the vfs hash. If the newly created vnode loses the race when being inserted into the vfs hash, it will not be recycled as its usecount is greater than zero, hitting the above assertion. Fix this by dropping the assertion. FreeBSD-issue: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=252700 Reviewed-by: Andriy Gapon <avg@FreeBSD.org> Reviewed-by: Mateusz Guzik <mjguzik@gmail.com> Reviewed-by: Alek Pinchuk <apinchuk@axcient.com> Reviewed-by: Ryan Moeller <ryan@iXsystems.com> Signed-off-by: Rob Wing <rob.wing@klarasystems.com> Co-authored-by: Rob Wing <rob.wing@klarasystems.com> Submitted-by: Klara, Inc. Sponsored-by: rsync.net Closes #14501
freebsd-git
pushed a commit
that referenced
this pull request
Sep 5, 2023
netlink(4) calls back into the driver during detach and it attempts to start an internal synchronized op recursively, causing an interruptible hang. Fix it by failing the ioctl if the VI has been marked as DOOMED by cxgbe_detach. Here's the stack for the hang for reference. #6 begin_synchronized_op #7 cxgbe_media_status #8 ifmedia_ioctl #9 cxgbe_ioctl #10 if_ioctl #11 get_operstate_ether #12 get_operstate #13 dump_iface #14 rtnl_handle_ifevent #15 rtnl_handle_ifnet_event #16 rt_ifmsg #17 if_unroute #18 if_down #19 if_detach_internal #20 if_detach #21 ether_ifdetach #22 cxgbe_vi_detach #23 cxgbe_detach #24 DEVICE_DETACH MFC after: 3 days Sponsored by: Chelsio Communications
guyyur
added a commit
to guyyur/freebsd-src
that referenced
this pull request
Sep 6, 2023
… we have no API for controlling the latter. This fixes a long standing problem where addresses added with non /128 prefixes and non infinite address lifetimes would register a prefix route which would expire. Subsequent calls set new lifetimes for the same address would not affect the prefix route management, so once expired, the prefix route would be impossible to add back as the kernel would remove it. Based on NetBSD changes (and reusing the commit message): sys/netinet6/in6.c 1.216 sys/netinet6/in6.c 1.217 sys/netinet6/in6.c 1.218 sys/netinet6/in6_ifattach.c 1.104 sys/netinet6/nd6_rtr.c 1.119 Also fixes a panic with INVARIANTS set and running "ndp -P" after an IPv6 address is manually added and the same prefix for the address is learned via router advertisment. freebsd#11 0xffffffff805d42b0 in kassert_panic (fmt=0xffffffff80939e3a "prefix %p has referencing addresses") at /usr/src/sys/kern/kern_shutdown.c:723 freebsd#12 0xffffffff807d4049 in nd6_prefix_del (pr=0xfffff800043c0400) at /usr/src/sys/netinet6/nd6_rtr.c:1189 freebsd#13 0xffffffff807caf38 in nd6_ioctl (cmd=<optimized out>, data=<optimized out>, ifp=0xfffff80002337000) at /usr/src/sys/netinet6/nd6.c:1831 PR: 195197
guyyur
added a commit
to guyyur/freebsd-src
that referenced
this pull request
Sep 7, 2023
… we have no API for controlling the latter. This fixes a long standing problem where addresses added with non /128 prefixes and non infinite address lifetimes would register a prefix route which would expire. Subsequent calls set new lifetimes for the same address would not affect the prefix route management, so once expired, the prefix route would be impossible to add back as the kernel would remove it. Based on NetBSD changes (and reusing the commit message): sys/netinet6/in6.c 1.216 sys/netinet6/in6.c 1.217 sys/netinet6/in6.c 1.218 sys/netinet6/in6_ifattach.c 1.104 sys/netinet6/nd6_rtr.c 1.119 Also fixes a panic with INVARIANTS set and running "ndp -P" after an IPv6 address is manually added and the same prefix for the address is learned via router advertisment. freebsd#11 0xffffffff805d42b0 in kassert_panic (fmt=0xffffffff80939e3a "prefix %p has referencing addresses") at /usr/src/sys/kern/kern_shutdown.c:723 freebsd#12 0xffffffff807d4049 in nd6_prefix_del (pr=0xfffff800043c0400) at /usr/src/sys/netinet6/nd6_rtr.c:1189 freebsd#13 0xffffffff807caf38 in nd6_ioctl (cmd=<optimized out>, data=<optimized out>, ifp=0xfffff80002337000) at /usr/src/sys/netinet6/nd6.c:1831 PR: 195197
freebsd-git
pushed a commit
that referenced
this pull request
Sep 18, 2023
netlink(4) calls back into the driver during detach and it attempts to start an internal synchronized op recursively, causing an interruptible hang. Fix it by failing the ioctl if the VI has been marked as DOOMED by cxgbe_detach. Here's the stack for the hang for reference. #6 begin_synchronized_op #7 cxgbe_media_status #8 ifmedia_ioctl #9 cxgbe_ioctl #10 if_ioctl #11 get_operstate_ether #12 get_operstate #13 dump_iface #14 rtnl_handle_ifevent #15 rtnl_handle_ifnet_event #16 rt_ifmsg #17 if_unroute #18 if_down #19 if_detach_internal #20 if_detach #21 ether_ifdetach #22 cxgbe_vi_detach #23 cxgbe_detach #24 DEVICE_DETACH MFC after: 3 days Sponsored by: Chelsio Communications (cherry picked from commit 3814249)
freebsd-git
pushed a commit
that referenced
this pull request
Sep 19, 2023
netlink(4) calls back into the driver during detach and it attempts to start an internal synchronized op recursively, causing an interruptible hang. Fix it by failing the ioctl if the VI has been marked as DOOMED by cxgbe_detach. Here's the stack for the hang for reference. #6 begin_synchronized_op #7 cxgbe_media_status #8 ifmedia_ioctl #9 cxgbe_ioctl #10 if_ioctl #11 get_operstate_ether #12 get_operstate #13 dump_iface #14 rtnl_handle_ifevent #15 rtnl_handle_ifnet_event #16 rt_ifmsg #17 if_unroute #18 if_down #19 if_detach_internal #20 if_detach #21 ether_ifdetach #22 cxgbe_vi_detach #23 cxgbe_detach #24 DEVICE_DETACH Sponsored by: Chelsio Communications Approved by: re (kib) (cherry picked from commit 3814249) (cherry picked from commit 3287f64)
guyyur
added a commit
to guyyur/freebsd-src
that referenced
this pull request
Dec 1, 2023
… we have no API for controlling the latter. This fixes a long standing problem where addresses added with non /128 prefixes and non infinite address lifetimes would register a prefix route which would expire. Subsequent calls set new lifetimes for the same address would not affect the prefix route management, so once expired, the prefix route would be impossible to add back as the kernel would remove it. Based on NetBSD changes (and reusing the commit message): sys/netinet6/in6.c 1.216 sys/netinet6/in6.c 1.217 sys/netinet6/in6.c 1.218 sys/netinet6/in6_ifattach.c 1.104 sys/netinet6/nd6_rtr.c 1.119 Also fixes a panic with INVARIANTS set and running "ndp -P" after an IPv6 address is manually added and the same prefix for the address is learned via router advertisment. freebsd#11 0xffffffff805d42b0 in kassert_panic (fmt=0xffffffff80939e3a "prefix %p has referencing addresses") at /usr/src/sys/kern/kern_shutdown.c:723 freebsd#12 0xffffffff807d4049 in nd6_prefix_del (pr=0xfffff800043c0400) at /usr/src/sys/netinet6/nd6_rtr.c:1189 freebsd#13 0xffffffff807caf38 in nd6_ioctl (cmd=<optimized out>, data=<optimized out>, ifp=0xfffff80002337000) at /usr/src/sys/netinet6/nd6.c:1831 PR: 195197
guyyur
added a commit
to guyyur/freebsd-src
that referenced
this pull request
Dec 1, 2023
… we have no API for controlling the latter. This fixes a long standing problem where addresses added with non /128 prefixes and non infinite address lifetimes would register a prefix route which would expire. Subsequent calls set new lifetimes for the same address would not affect the prefix route management, so once expired, the prefix route would be impossible to add back as the kernel would remove it. Based on NetBSD changes (and reusing the commit message): sys/netinet6/in6.c 1.216 sys/netinet6/in6.c 1.217 sys/netinet6/in6.c 1.218 sys/netinet6/in6_ifattach.c 1.104 sys/netinet6/nd6_rtr.c 1.119 Also fixes a panic with INVARIANTS set and running "ndp -P" after an IPv6 address is manually added and the same prefix for the address is learned via router advertisment. freebsd#11 0xffffffff805d42b0 in kassert_panic (fmt=0xffffffff80939e3a "prefix %p has referencing addresses") at /usr/src/sys/kern/kern_shutdown.c:723 freebsd#12 0xffffffff807d4049 in nd6_prefix_del (pr=0xfffff800043c0400) at /usr/src/sys/netinet6/nd6_rtr.c:1189 freebsd#13 0xffffffff807caf38 in nd6_ioctl (cmd=<optimized out>, data=<optimized out>, ifp=0xfffff80002337000) at /usr/src/sys/netinet6/nd6.c:1831 PR: 195197
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
On mbufs that don't have the CSUM_DATA_VALID flag set, tcp_input()
needs to compute the TCP checksum itself.
The TCP checksum includes some but not all fields from the IP header.
tcp_input() zeroes the fields of the IP header that are not to be
included in the checksum, then checksums the entire packet (IP
header, TCP header, and TCP data), then restores the IP header
fields it will need later.
The bug that this commit fixes is that the IP TOS field was not
restored, so the later read of it returned a zeroed byte instead
of the incoming packet's actual TOS value.