NetBSD Problem Report #57666

From www@netbsd.org  Tue Oct 17 11:33:19 2023
Return-Path: <www@netbsd.org>
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 961AD1A9238
	for <gnats-bugs@gnats.NetBSD.org>; Tue, 17 Oct 2023 11:33:19 +0000 (UTC)
Message-Id: <20231017113318.2C7B91A9239@mollari.NetBSD.org>
Date: Tue, 17 Oct 2023 11:33:18 +0000 (UTC)
From: campbell+netbsd@mumble.net
Reply-To: campbell+netbsd@mumble.net
To: gnats-bugs@NetBSD.org
Subject: thmap_create tests wrong value for allocation failure and can spuriously fail
X-Send-Pr-Version: www-1.0

>Number:         57666
>Category:       kern
>Synopsis:       thmap_create tests wrong value for allocation failure and can spuriously fail
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    kern-bug-people
>State:          closed
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Tue Oct 17 11:35:00 +0000 2023
>Closed-Date:    Sat Oct 21 17:07:35 +0000 2023
>Last-Modified:  Sat Oct 21 17:07:35 +0000 2023
>Originator:     Taylor R Campbell
>Release:        current, 10, 9
>Organization:
The NpfBSD Foundation
>Environment:
>Description:
    989 		root = thmap->ops->alloc(THMAP_ROOT_LEN);
    990 		thmap->root = THMAP_GETPTR(thmap, root);
    991 		if (!thmap->root) {
    992 			kmem_free(thmap, sizeof(thmap_t));
    993 			return NULL;
    994 		}
https://nxr.netbsd.org/xref/src/sys/kern/subr_thmap.c?r=1.13#989

1. The alloc operation fails by returning zero, so the test should check alloc's return value, not THMAP_GETPTR's return value which will relocate the address by the thmap's base pointer.

2. This allocation shouldn't be allowed to fail anyway -- it should pass through KM_SLEEP, and the branch should be pruned, in contrast to other calls like in thmap_put which are used in the packet-processing path and can fail on temporary memory shortage.

Side note: the thmap(9) man page doesn't mention that thmap_put can fail for temporary allocation failure.
>How-To-Repeat:
Pass a nonzero baseptr and an allocator that can fail (like the default kernel kmem allocator) to thmap_create.
>Fix:
Yes, please!

>Release-Note:

>Audit-Trail:
From: "Taylor R Campbell" <riastradh@netbsd.org>
To: gnats-bugs@gnats.NetBSD.org
Cc: 
Subject: PR/57666 CVS commit: src/sys/kern
Date: Tue, 17 Oct 2023 11:55:28 +0000

 Module Name:	src
 Committed By:	riastradh
 Date:		Tue Oct 17 11:55:28 UTC 2023

 Modified Files:
 	src/sys/kern: subr_thmap.c

 Log Message:
 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

 XXX pullup-10
 XXX pullup-9


 To generate a diff of this commit:
 cvs rdiff -u -r1.13 -r1.14 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: open->needs-pullups
State-Changed-By: riastradh@NetBSD.org
State-Changed-When: Tue, 17 Oct 2023 14:27:46 +0000
State-Changed-Why:
committed to HEAD, needs pullup-10 and pullup-9


From: "Martin Husemann" <martin@netbsd.org>
To: gnats-bugs@gnats.NetBSD.org
Cc: 
Subject: PR/57666 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/57666 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: needs-pullups->closed
State-Changed-By: maya@NetBSD.org
State-Changed-When: Sat, 21 Oct 2023 17:07:35 +0000
State-Changed-Why:
pullups done


>Unformatted:

Home	PR Database Search