NetBSD Problem Report #57208
From he@smistad.uninett.no Tue Jan 31 12:17:42 2023
Return-Path: <he@smistad.uninett.no>
Received: from mail.netbsd.org (mail.netbsd.org [199.233.217.200])
(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits))
(Client CN "mail.NetBSD.org", Issuer "mail.NetBSD.org CA" (not verified))
by mollari.NetBSD.org (Postfix) with ESMTPS id 4621D1A9239
for <gnats-bugs@gnats.NetBSD.org>; Tue, 31 Jan 2023 12:17:42 +0000 (UTC)
Message-Id: <20230131121736.414A943ED13@smistad.uninett.no>
Date: Tue, 31 Jan 2023 13:17:36 +0100 (CET)
From: he@NetBSD.org
Reply-To: he@NetBSD.org
To: gnats-bugs@NetBSD.org
Subject: panic related to NPF functionality
X-Send-Pr-Version: 3.95
>Number: 57208
>Category: kern
>Synopsis: panic related to NPF functionality
>Confidential: no
>Severity: serious
>Priority: medium
>Responsible: riastradh
>State: closed
>Class: sw-bug
>Submitter-Id: net
>Arrival-Date: Tue Jan 31 12:20:00 +0000 2023
>Closed-Date: Thu Apr 04 05:18:53 +0000 2024
>Last-Modified: Thu Apr 04 05:19:33 +0000 2024
>Originator: he@NetBSD.org
>Release: NetBSD 9.2
>Organization:
I Try...
>Environment:
System: NetBSD xxx.xxxx.net 9.2 NetBSD 9.2 (GENERIC) #0: Wed May 12 13:15:55 UTC 2021 mkrepro@mkrepro.NetBSD.org:/usr/src/sys/arch/amd64/compile/GENERIC amd64
Architecture: x86_64
Machine: amd64
>Description:
We recently experienced a number of panic()s related to NPF.
Inspecting the resulting core dumps with "dmesg" reveals:
[ 134.887867] fatal page fault in supervisor mode
[ 134.887867] trap type 6 code 0x2 rip 0xffffffff80997103 cs 0x8 rflags 0x10286 cr2 0 ilevel 0x4 rsp 0xffff8000660fec80
[ 134.887867] curlwp 0xffffa2ae4201e480 pid 0.3 lowest kstack 0xffff8000660fc2c0
[ 134.887867] panic: trap
[ 134.887867] cpu0: Begin traceback...
[ 134.887867] vpanic() at netbsd:vpanic+0x160
[ 134.887867] snprintf() at netbsd:snprintf
[ 134.887867] startlwp() at netbsd:startlwp
[ 134.897870] alltraps() at netbsd:alltraps+0xbb
[ 134.897870] thmap_del() at netbsd:thmap_del+0x1d2
[ 134.897870] npf_conndb_remove() at netbsd:npf_conndb_remove+0x37
[ 134.897870] npf_conn_establish() at netbsd:npf_conn_establish+0x1ca
[ 134.897870] npfk_packet_handler() at netbsd:npfk_packet_handler+0x428
[ 134.897870] pfil_run_hooks() at netbsd:pfil_run_hooks+0x122
[ 134.897870] ipintr() at netbsd:ipintr+0x3a3
[ 134.897870] softint_dispatch() at netbsd:softint_dispatch+0xab
[ 134.897870] cpu0: End traceback...
[ 134.897870] dumping to dev 4,1 (offset=12469831, size=1029687):
[ 134.897870] dump
or
[ 2206938.776755] uvm_fault(0xfffffa6db0377008, 0x0, 2) -> e
[ 2206938.776755] fatal page fault in supervisor mode
[ 2206938.776755] trap type 6 code 0x2 rip 0xffffffff80997103 cs 0x8 rflags 0x10
286 cr2 0 ilevel 0x4 rsp 0xffffd58070e864e0
[ 2206938.776755] curlwp 0xfffffa6d801e8340 pid 1321.3 lowest kstack 0xffffd5807
0e842c0
[ 2206938.776755] panic: trap
[ 2206938.776755] cpu2: Begin traceback...
[ 2206938.776755] vpanic() at netbsd:vpanic+0x160
[ 2206938.776755] snprintf() at netbsd:snprintf
[ 2206938.776755] startlwp() at netbsd:startlwp
[ 2206938.776755] alltraps() at netbsd:alltraps+0xbb
[ 2206938.776755] thmap_del() at netbsd:thmap_del+0x1d2
[ 2206938.786760] npf_conndb_remove() at netbsd:npf_conndb_remove+0x37
[ 2206938.786760] npf_conn_establish() at netbsd:npf_conn_establish+0x1ca
[ 2206938.786760] npfk_packet_handler() at netbsd:npfk_packet_handler+0x428
[ 2206938.786760] pfil_run_hooks() at netbsd:pfil_run_hooks+0x122
[ 2206938.786760] ip6_output() at netbsd:ip6_output+0x11cb
[ 2206938.786760] udp6_output() at netbsd:udp6_output+0x544
[ 2206938.786760] udp6_send_wrapper() at netbsd:udp6_send_wrapper+0x51
[ 2206938.786760] sosend() at netbsd:sosend+0x722
[ 2206938.796763] do_sys_sendmsg_so() at netbsd:do_sys_sendmsg_so+0x211
[ 2206938.796763] do_sys_sendmsg() at netbsd:do_sys_sendmsg+0xac
[ 2206938.796763] sys_sendmsg() at netbsd:sys_sendmsg+0x47
[ 2206938.796763] syscall() at netbsd:syscall+0x157
[ 2206938.796763] --- syscall (number 28) ---
[ 2206938.796763] 74fd1b487aba:
[ 2206938.796763] cpu2: End traceback...
[ 2206938.796763] dumping to dev 4,1 (offset=12469831, size=1029687):
[ 2206938.796763] dump
Looking at one of the core dumps with gdb after building
netbsd.gdb with the -P switch for reproducible builds reveals:
# gdb /usr/obj/sys/arch/amd64/compile/GENERIC/netbsd.gdb
GNU gdb (GDB) 8.3
...
(gdb) target kvm netbsd.6.core
0xffffffff80222aaa in cpu_reboot (howto=howto@entry=260,
bootstr=bootstr@entry=0x0) at /usr/src/sys/arch/amd64/amd64/machdep.c:728
728 dumpsys();
(gdb) info line *(thmap_del+0x1d2)
Line 876 of "/usr/src/sys/kern/subr_thmap.c"
starts at address 0xffffffff80997a70 <thmap_del+466>
and ends at 0xffffffff80997a75 <thmap_del+471>.
(gdb) where
#0 0xffffffff80222aaa in cpu_reboot (howto=howto@entry=260,
bootstr=bootstr@entry=0x0) at /usr/src/sys/arch/amd64/amd64/machdep.c:728
#1 0xffffffff80994a96 in vpanic (fmt=0xffffffff811114f8 "trap",
fmt@entry=0xffffffff81111538 "ault", ap=ap@entry=0xffff9400660fea48)
at /usr/src/sys/kern/subr_prf.c:336
#2 0xffffffff80994b47 in panic (fmt=fmt@entry=0xffffffff81111538 "ault")
at /usr/src/sys/kern/subr_prf.c:255
#3 0xffffffff80224aed in trap (frame=0xffff9400660feb90)
at /usr/src/sys/arch/amd64/amd64/trap.c:334
#4 0xffffffff8021d56b in alltraps ()
#5 0xffffffff80997103 in stage_mem_gc (thmap=thmap@entry=0xffffd7202ae60080,
addr=18446699131934760928, len=len@entry=24)
at /usr/src/sys/kern/subr_thmap.c:888
#6 0xffffffff80997a70 in thmap_del (thmap=0xffffd7202ae60080,
key=key@entry=0xffffd7202f7a2134, len=len@entry=16)
at /usr/src/sys/kern/subr_thmap.c:875
#7 0xffffffff80764655 in npf_conndb_remove (cd=cd@entry=0xffffd7202ae60058,
ck=ck@entry=0xffffd7202f7a2134) at /usr/src/sys/net/npf/npf_conndb.c:235
#8 0xffffffff80763197 in npf_conn_establish (
npc=npc@entry=0xffff9400660fee50, di=di@entry=1, global=<optimized out>)
at /usr/src/sys/net/npf/npf_conn.c:502
#9 0xffffffff8075e6e9 in npfk_packet_handler (npf=0xffffd7202adfdcc0,
mp=0xffff9400660fef00, ifp=<optimized out>, di=1)
at /usr/src/sys/net/npf/npf_handler.c:257
#10 0xffffffff80a4b6b6 in pfil_run_hooks (ph=<optimized out>,
mp=mp@entry=0xffff9400660fefe0, ifp=ifp@entry=0xffff9400071db008,
dir=dir@entry=1) at /usr/src/sys/net/pfil.c:417
#11 0xffffffff806f1eca in ip_input (m=<optimized out>)
at /usr/src/sys/netinet/ip_input.c:578
#12 ipintr (arg=<optimized out>) at /usr/src/sys/netinet/ip_input.c:402
#13 0xffffffff8096f549 in softint_execute (l=<optimized out>, s=4,
si=0xffff9400660f4230) at /usr/src/sys/kern/kern_softint.c:592
#14 softint_dispatch (pinned=<optimized out>, s=4)
at /usr/src/sys/kern/kern_softint.c:881
#15 0xffffffff8021d24f in Xsoftintr ()
...
(gdb) up
#1 0xffffffff80994a96 in vpanic (fmt=0xffffffff811114f8 "trap",
fmt@entry=0xffffffff81111538 "ault", ap=ap@entry=0xffff9400660fea48)
at /usr/src/sys/kern/subr_prf.c:336
336 cpu_reboot(bootopt, NULL);
(gdb) up
#2 0xffffffff80994b47 in panic (fmt=fmt@entry=0xffffffff81111538 "ault")
at /usr/src/sys/kern/subr_prf.c:255
255 vpanic(fmt, ap);
(gdb) up
#3 0xffffffff80224aed in trap (frame=0xffff9400660feb90)
at /usr/src/sys/arch/amd64/amd64/trap.c:334
334 panic("trap");
(gdb) up
#4 0xffffffff8021d56b in alltraps ()
(gdb) up
#5 0xffffffff80997103 in stage_mem_gc (thmap=thmap@entry=0xffffd7202ae60080,
addr=18446699131934760928, len=len@entry=24)
at /usr/src/sys/kern/subr_thmap.c:888
888 gc = kmem_intr_alloc(sizeof(thmap_gc_t), KM_NOSLEEP);
(gdb) up
#6 0xffffffff80997a70 in thmap_del (thmap=0xffffd7202ae60080,
key=key@entry=0xffffd7202f7a2134, len=len@entry=16)
at /usr/src/sys/kern/subr_thmap.c:875
875 stage_mem_gc(thmap, THMAP_GETOFF(thmap, leaf), sizeof(thmap_leaf_t));
(gdb) up
#7 0xffffffff80764655 in npf_conndb_remove (cd=cd@entry=0xffffd7202ae60058,
ck=ck@entry=0xffffd7202f7a2134) at /usr/src/sys/net/npf/npf_conndb.c:235
235 val = thmap_del(cd->cd_map, ck->ck_key, keylen);
(gdb) up
#8 0xffffffff80763197 in npf_conn_establish (
npc=npc@entry=0xffff9400660fee50, di=di@entry=1, global=<optimized out>)
at /usr/src/sys/net/npf/npf_conn.c:502
502 ret = npf_conndb_remove(conn_db, fw);
(gdb) up
#9 0xffffffff8075e6e9 in npfk_packet_handler (npf=0xffffd7202adfdcc0,
mp=0xffff9400660fef00, ifp=<optimized out>, di=1)
at /usr/src/sys/net/npf/npf_handler.c:257
257 con = npf_conn_establish(&npc, di,
(gdb) up
#10 0xffffffff80a4b6b6 in pfil_run_hooks (ph=<optimized out>,
mp=mp@entry=0xffff9400660fefe0, ifp=ifp@entry=0xffff9400071db008,
dir=dir@entry=1) at /usr/src/sys/net/pfil.c:417
417 ret = (*func)(pfh->pfil_arg, &m, ifp, dir);
(gdb) up
#11 0xffffffff806f1eca in ip_input (m=<optimized out>)
at /usr/src/sys/netinet/ip_input.c:578
578 freed = pfil_run_hooks(inet_pfil_hook, &m, ifp, PFIL_IN) != 0;
(gdb) up
#12 ipintr (arg=<optimized out>) at /usr/src/sys/netinet/ip_input.c:402
402 ip_input(m);
(gdb) up
#13 0xffffffff8096f549 in softint_execute (l=<optimized out>, s=4,
si=0xffff9400660f4230) at /usr/src/sys/kern/kern_softint.c:592
592 (*sh->sh_func)(sh->sh_arg);
(gdb) up
#14 softint_dispatch (pinned=<optimized out>, s=4)
at /usr/src/sys/kern/kern_softint.c:881
881 softint_execute(si, l, s);
(gdb)
>How-To-Repeat:
Don't know, this may possibly be network-triggered...
>Fix:
Don't know, sorry.
>Release-Note:
>Audit-Trail:
From: Taylor R Campbell <riastradh@NetBSD.org>
To: gnats-bugs@NetBSD.org
Cc:
Subject: Re: kern/57208: panic related to NPF functionality
Date: Tue, 31 Jan 2023 14:03:59 +0000
Nontrivial bugs in the thmap API contract and in npf's usage of it:
https://github.com/rmind/thmap/issues/11
https://github.com/rmind/npf/issues/129
State-Changed-From-To: open->analyzed
State-Changed-By: riastradh@NetBSD.org
State-Changed-When: Tue, 31 Jan 2023 14:07:58 +0000
State-Changed-Why:
problem has been analyzed
From: Taylor R Campbell <riastradh@NetBSD.org>
To: gnats-bugs@NetBSD.org
Cc:
Subject: Re: kern/57208: panic related to NPF functionality
Date: Tue, 31 Jan 2023 14:07:00 +0000
Summary:
- This is the result of a short-term memory allocation failure with
KM_NOSLEEP in soft interrupt context.
- The problem remains in netbsd-10.
- Requires change to API contract in thmap -- either must be able to
fail, or must be allowed to sleep and therefore must be forbidden in
(soft) interrupt context or under locks held in (soft) interrupt
context.
From: Taylor R Campbell <riastradh@NetBSD.org>
To: he@NetBSD.org
Cc: gnats-bugs@NetBSD.org, netbsd-bugs@NetBSD.org, rmind@NetBSD.org
Subject: Re: kern/57208: panic related to NPF functionality
Date: Thu, 12 Oct 2023 19:34:57 +0000
This is a multi-part message in MIME format.
--=_2Yq8a6fRuEaGoxA1LAInCnTY5Q7059bP
The attached patch trades some extra memory usage in thmap(9) for
avoiding the panic by preallocating the thmap_gc_t list entry data
structures in each object they might be used to deferred-free.
I'd like to pull this up into netbsd-10, even if we end up using a
different approach later, whatever that approach is -- nobody's
suggested anything better in the nine months since this was filed, and
this should work by eliminating the possibility of failure in
thmap_del without adding any new sleeps for allocation that might be
hit in the softint packet-processing path.
I ran npftest via the atf tests and it passed, but can you give it a
try just to make sure it hasn't horribly broken anything else?
--=_2Yq8a6fRuEaGoxA1LAInCnTY5Q7059bP
Content-Type: text/plain; charset="ISO-8859-1"; name="pr57208-thmapgcprealloc"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="pr57208-thmapgcprealloc.patch"
From f5367bc5d1c34562fe381ce184ac4693da9b6a95 Mon Sep 17 00:00:00 2001
From: Taylor R Campbell <riastradh@NetBSD.org>
Date: Thu, 12 Oct 2023 14:53:45 +0000
Subject: [PATCH] thmap(9): Preallocate GC list storage for thmap_del.
thmap_del can't fail, and it is used in places in npf where sleeping
is forbidden, so it can't rely on allocating memory either.
Instead of having thmap_del allocate memory on the fly for each
object to defer freeing until thmap_gc, arrange to have thmap(9)
preallocate the same storage when allocating all the objects in the
first place, with a GC header.
This is suboptimal for memory usage, especially on insertion- and
lookup-heavy but deletion-light workloads, but nobody's proposed a
better approach since the issue was reported, so we'll go with this
for correctness.
PR kern/57208
https://github.com/rmind/npf/issues/129
XXX pullup-10
XXX pullup-9
---
sys/kern/subr_thmap.c | 71 ++++++++++++++++++++++++++++++++-----------
1 file changed, 53 insertions(+), 18 deletions(-)
diff --git a/sys/kern/subr_thmap.c b/sys/kern/subr_thmap.c
index 7af1dc33d0af..a0a8cee3ce62 100644
--- a/sys/kern/subr_thmap.c
+++ b/sys/kern/subr_thmap.c
@@ -212,11 +212,17 @@ typedef struct {
uint32_t hashval; // current hash value
} thmap_query_t;
=20
-typedef struct {
- uintptr_t addr;
+union thmap_align {
+ void * p;
+ uint64_t v;
+};
+
+typedef struct thmap_gc thmap_gc_t;
+struct thmap_gc {
size_t len;
- void * next;
-} thmap_gc_t;
+ thmap_gc_t * next;
+ char data[] __aligned(sizeof(union thmap_align));
+};
=20
#define THMAP_ROOT_LEN (sizeof(thmap_ptr_t) * ROOT_SIZE)
=20
@@ -252,6 +258,34 @@ static const thmap_ops_t thmap_default_ops =3D {
.free =3D free_wrapper
};
=20
+static uintptr_t
+gc_alloc(const thmap_t *thmap, size_t len)
+{
+ const size_t alloclen =3D offsetof(struct thmap_gc, data[len]);
+ const uintptr_t gcaddr =3D thmap->ops->alloc(alloclen);
+
+ if (!gcaddr)
+ return 0;
+
+ thmap_gc_t *const gc =3D THMAP_GETPTR(thmap, gcaddr);
+ gc->len =3D len;
+ return THMAP_GETOFF(thmap, &gc->data[0]);
+}
+
+static void
+gc_free(const thmap_t *thmap, uintptr_t addr, size_t len)
+{
+ const size_t alloclen =3D offsetof(struct thmap_gc, data[len]);
+ char *const ptr =3D THMAP_GETPTR(thmap, addr);
+ thmap_gc_t *const gc =3D container_of(ptr, struct thmap_gc, data[0]);
+ const uintptr_t gcaddr =3D THMAP_GETOFF(thmap, gc);
+
+ KASSERTMSG(gc->len =3D=3D len, "thmap=3D%p ops=3D%p addr=3D%p len=3D%zu"
+ " gc=3D%p gc->len=3D%zu",
+ thmap, thmap->ops, (void *)addr, len, gc, gc->len);
+ thmap->ops->free(gcaddr, alloclen);
+}
+
/*
* NODE LOCKING.
*/
@@ -395,7 +429,7 @@ node_create(thmap_t *thmap, thmap_inode_t *parent)
thmap_inode_t *node;
uintptr_t p;
=20
- p =3D thmap->ops->alloc(THMAP_INODE_LEN);
+ p =3D gc_alloc(thmap, THMAP_INODE_LEN);
if (!p) {
return NULL;
}
@@ -456,7 +490,7 @@ leaf_create(const thmap_t *thmap, const void *key, size=
_t len, void *val)
thmap_leaf_t *leaf;
uintptr_t leaf_off, key_off;
=20
- leaf_off =3D thmap->ops->alloc(sizeof(thmap_leaf_t));
+ leaf_off =3D gc_alloc(thmap, sizeof(thmap_leaf_t));
if (!leaf_off) {
return NULL;
}
@@ -467,9 +501,9 @@ leaf_create(const thmap_t *thmap, const void *key, size=
_t len, void *val)
/*
* Copy the key.
*/
- key_off =3D thmap->ops->alloc(len);
+ key_off =3D gc_alloc(thmap, len);
if (!key_off) {
- thmap->ops->free(leaf_off, sizeof(thmap_leaf_t));
+ gc_free(thmap, leaf_off, sizeof(thmap_leaf_t));
return NULL;
}
memcpy(THMAP_GETPTR(thmap, key_off), key, len);
@@ -487,9 +521,9 @@ static void
leaf_free(const thmap_t *thmap, thmap_leaf_t *leaf)
{
if ((thmap->flags & THMAP_NOCOPY) =3D=3D 0) {
- thmap->ops->free(leaf->key, leaf->len);
+ gc_free(thmap, leaf->key, leaf->len);
}
- thmap->ops->free(THMAP_GETOFF(thmap, leaf), sizeof(thmap_leaf_t));
+ gc_free(thmap, THMAP_GETOFF(thmap, leaf), sizeof(thmap_leaf_t));
}
=20
static thmap_leaf_t *
@@ -547,7 +581,7 @@ root_try_put(thmap_t *thmap, const thmap_query_t *query=
, thmap_leaf_t *leaf)
nptr =3D THMAP_GETOFF(thmap, node);
again:
if (atomic_load_relaxed(&thmap->root[i])) {
- thmap->ops->free(nptr, THMAP_INODE_LEN);
+ gc_free(thmap, nptr, THMAP_INODE_LEN);
return EEXIST;
}
/* Release to subsequent consume in find_edge_node(). */
@@ -927,11 +961,13 @@ thmap_del(thmap_t *thmap, const void *key, size_t len)
static void
stage_mem_gc(thmap_t *thmap, uintptr_t addr, size_t len)
{
+ char *const ptr =3D THMAP_GETPTR(thmap, addr);
thmap_gc_t *head, *gc;
=20
- gc =3D kmem_intr_alloc(sizeof(thmap_gc_t), KM_NOSLEEP);
- gc->addr =3D addr;
- gc->len =3D len;
+ gc =3D container_of(ptr, struct thmap_gc, data[0]);
+ KASSERTMSG(gc->len =3D=3D len,
+ "thmap=3D%p ops=3D%p ptr=3D%p len=3D%zu gc=3D%p gc->len=3D%zu",
+ thmap, thmap->ops, (char *)addr, len, gc, gc->len);
retry:
head =3D atomic_load_relaxed(&thmap->gc_list);
gc->next =3D head; // not yet published
@@ -958,8 +994,7 @@ thmap_gc(thmap_t *thmap, void *ref)
=20
while (gc) {
thmap_gc_t *next =3D gc->next;
- thmap->ops->free(gc->addr, gc->len);
- kmem_intr_free(gc, sizeof(thmap_gc_t));
+ gc_free(thmap, THMAP_GETOFF(thmap, &gc->data[0]), gc->len);
gc =3D next;
}
}
@@ -986,7 +1021,7 @@ thmap_create(uintptr_t baseptr, const thmap_ops_t *ops=
, unsigned flags)
=20
if ((thmap->flags & THMAP_SETROOT) =3D=3D 0) {
/* Allocate the root level. */
- root =3D thmap->ops->alloc(THMAP_ROOT_LEN);
+ root =3D gc_alloc(thmap, THMAP_ROOT_LEN);
thmap->root =3D THMAP_GETPTR(thmap, root);
if (!thmap->root) {
kmem_free(thmap, sizeof(thmap_t));
@@ -1026,7 +1061,7 @@ thmap_destroy(thmap_t *thmap)
thmap_gc(thmap, ref);
=20
if ((thmap->flags & THMAP_SETROOT) =3D=3D 0) {
- thmap->ops->free(root, THMAP_ROOT_LEN);
+ gc_free(thmap, root, THMAP_ROOT_LEN);
}
kmem_free(thmap, sizeof(thmap_t));
}
--=_2Yq8a6fRuEaGoxA1LAInCnTY5Q7059bP--
From: "Taylor R Campbell" <riastradh@netbsd.org>
To: gnats-bugs@gnats.NetBSD.org
Cc:
Subject: PR/57208 CVS commit: src/sys/kern
Date: Tue, 17 Oct 2023 11:57:20 +0000
Module Name: src
Committed By: riastradh
Date: Tue Oct 17 11:57:20 UTC 2023
Modified Files:
src/sys/kern: subr_thmap.c
Log Message:
thmap(9): Preallocate GC list storage for thmap_del.
thmap_del can't fail, and it is used in places in npf where sleeping
is forbidden, so it can't rely on allocating memory either.
Instead of having thmap_del allocate memory on the fly for each
object to defer freeing until thmap_gc, arrange to have thmap(9)
preallocate the same storage when allocating all the objects in the
first place, with a GC header.
This is suboptimal for memory usage, especially on insertion- and
lookup-heavy but deletion-light workloads, but it's not clear rmind's
alternative (https://github.com/rmind/thmap/tree/thmap_del_mem_fail)
is ready to use yet, so we'll go with this for correctness.
PR kern/57208
https://github.com/rmind/npf/issues/129
XXX pullup-10
XXX pullup-9
To generate a diff of this commit:
cvs rdiff -u -r1.14 -r1.15 src/sys/kern/subr_thmap.c
Please note that diffs are not public domain; they are subject to the
copyright notices on the relevant files.
From: "Martin Husemann" <martin@netbsd.org>
To: gnats-bugs@gnats.NetBSD.org
Cc:
Subject: PR/57208 CVS commit: [netbsd-10] src/sys/kern
Date: Wed, 18 Oct 2023 15:03:12 +0000
Module Name: src
Committed By: martin
Date: Wed Oct 18 15:03:12 UTC 2023
Modified Files:
src/sys/kern [netbsd-10]: subr_thmap.c
Log Message:
Pull up following revision(s) (requested by riastradh in ticket #423):
sys/kern/subr_thmap.c: revision 1.14
sys/kern/subr_thmap.c: revision 1.15
thmap(9): Test alloc failure, not THMAP_GETPTR failure.
THMAP_GETPTR may return nonnull even though alloc returned zero.
Note that this failure branch is not actually appropriate;
thmap_create should not fail. We really need to pass KM_SLEEP
through in this call site even though there are other call sites for
which KM_NOSLEEP is appropriate.
Adapted from: https://github.com/rmind/thmap/pull/14
PR kern/57666
https://github.com/rmind/thmap/issues/13
thmap(9): Preallocate GC list storage for thmap_del.
thmap_del can't fail, and it is used in places in npf where sleeping
is forbidden, so it can't rely on allocating memory either.
Instead of having thmap_del allocate memory on the fly for each
object to defer freeing until thmap_gc, arrange to have thmap(9)
preallocate the same storage when allocating all the objects in the
first place, with a GC header.
This is suboptimal for memory usage, especially on insertion- and
lookup-heavy but deletion-light workloads, but it's not clear rmind's
alternative (https://github.com/rmind/thmap/tree/thmap_del_mem_fail)
is ready to use yet, so we'll go with this for correctness.
PR kern/57208
https://github.com/rmind/npf/issues/129
To generate a diff of this commit:
cvs rdiff -u -r1.12 -r1.12.4.1 src/sys/kern/subr_thmap.c
Please note that diffs are not public domain; they are subject to the
copyright notices on the relevant files.
From: "Martin Husemann" <martin@netbsd.org>
To: gnats-bugs@gnats.NetBSD.org
Cc:
Subject: PR/57208 CVS commit: [netbsd-9] src/sys/kern
Date: Wed, 18 Oct 2023 15:07:06 +0000
Module Name: src
Committed By: martin
Date: Wed Oct 18 15:07:06 UTC 2023
Modified Files:
src/sys/kern [netbsd-9]: subr_thmap.c
Log Message:
Pull up following revision(s) (requested by riastradh in ticket #1755):
sys/kern/subr_thmap.c: revision 1.14
sys/kern/subr_thmap.c: revision 1.15
thmap(9): Test alloc failure, not THMAP_GETPTR failure.
THMAP_GETPTR may return nonnull even though alloc returned zero.
Note that this failure branch is not actually appropriate;
thmap_create should not fail. We really need to pass KM_SLEEP
through in this call site even though there are other call sites for
which KM_NOSLEEP is appropriate.
Adapted from: https://github.com/rmind/thmap/pull/14
PR kern/57666
https://github.com/rmind/thmap/issues/13
thmap(9): Preallocate GC list storage for thmap_del.
thmap_del can't fail, and it is used in places in npf where sleeping
is forbidden, so it can't rely on allocating memory either.
Instead of having thmap_del allocate memory on the fly for each
object to defer freeing until thmap_gc, arrange to have thmap(9)
preallocate the same storage when allocating all the objects in the
first place, with a GC header.
This is suboptimal for memory usage, especially on insertion- and
lookup-heavy but deletion-light workloads, but it's not clear rmind's
alternative (https://github.com/rmind/thmap/tree/thmap_del_mem_fail)
is ready to use yet, so we'll go with this for correctness.
PR kern/57208
https://github.com/rmind/npf/issues/129
To generate a diff of this commit:
cvs rdiff -u -r1.5.6.1 -r1.5.6.2 src/sys/kern/subr_thmap.c
Please note that diffs are not public domain; they are subject to the
copyright notices on the relevant files.
State-Changed-From-To: analyzed->closed
State-Changed-By: riastradh@NetBSD.org
State-Changed-When: Thu, 04 Apr 2024 05:18:53 +0000
State-Changed-Why:
fixed in HEAD, pulled up to 10 and 9, inapplicable <9
Responsible-Changed-From-To: kern-bug-people->riastradh
Responsible-Changed-By: riastradh@NetBSD.org
Responsible-Changed-When: Thu, 04 Apr 2024 05:19:33 +0000
Responsible-Changed-Why:
mine
>Unformatted:
(Contact us)
$NetBSD: query-full-pr,v 1.47 2022/09/11 19:34:41 kim Exp $
$NetBSD: gnats_config.sh,v 1.9 2014/08/02 14:16:04 spz Exp $
Copyright © 1994-2024
The NetBSD Foundation, Inc. ALL RIGHTS RESERVED.
Home