Skip to content
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

Seb-LineRate
Copy link

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.

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>
@cemeyer
Copy link
Member

cemeyer commented Sep 18, 2016

lidl@ suggests instead:

Index: tcp_input.c
===================================================================
--- tcp_input.c (revision 305860)
+++ tcp_input.c (working copy)
@@ -675,6 +675,7 @@
            /* XXX stat */
            goto drop;
        }
+       iptos = (ntohl(ip6->ip6_flow) >> 20) & 0xff;
    }
 #endif
 #if defined(INET) && defined(INET6)
@@ -701,6 +702,7 @@
        th = (struct tcphdr *)((caddr_t)ip + off0);
        tlen = ntohs(ip->ip_len) - off0;

+       iptos = ip->ip_tos;
        if (m->m_pkthdr.csum_flags & CSUM_DATA_VALID) {
            if (m->m_pkthdr.csum_flags & CSUM_PSEUDO_HDR)
                th->th_sum = m->m_pkthdr.csum_data;
@@ -722,6 +724,10 @@
            th->th_sum = in_cksum(m, len);
            /* Reset length for SDT probes. */
            ip->ip_len = htons(tlen + off0);
+           /* Reset TOS bits */
+           ip->ip_tos = iptos;
+           /* Re-initialization for later version check */
+           ip->ip_v = IPVERSION;
        }

        if (th->th_sum) {
@@ -728,22 +734,9 @@
            TCPSTAT_INC(tcps_rcvbadsum);
            goto drop;
        }
-       /* Re-initialization for later version check */
-       ip->ip_v = IPVERSION;
    }
 #endif /* INET */

-#ifdef INET6
-   if (isipv6)
-       iptos = (ntohl(ip6->ip6_flow) >> 20) & 0xff;
-#endif
-#if defined(INET) && defined(INET6)
-   else
-#endif
-#ifdef INET
-       iptos = ip->ip_tos;
-#endif
-
    /*
     * Check that TCP offset makes sense,
     * pull out TCP options and adjust length.      XXX

@cemeyer
Copy link
Member

cemeyer commented Sep 29, 2016

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.
@emaste
Copy link
Member

emaste commented Feb 28, 2017

As mentioned by @cemeyer this has been committed

@emaste emaste closed this Feb 28, 2017
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
Labels
None yet
Projects
None yet
3 participants