PR/59411 CVS commit: src/sys

"Taylor R Campbell" <[email protected]>
Newsgroups gmane.os.netbsd.bugs
Message-ID <[email protected]>
The following reply was made to PR kern/59411; it has been noted by GNATS.

From: "Taylor R Campbell" <[email protected]>
To: [email protected]
Cc: 
Subject: PR/59411 CVS commit: src/sys
Date: Sun, 23 Aug 2026 17:49:11 +0000

 Module Name:	src
 Committed By:	riastradh
 Date:		Sun Aug 23 17:49:11 UTC 2026
 
 Modified Files:
 	src/sys/kern: subr_pool.c
 	src/sys/sys: pool.h
 
 Log Message:
 pool(9): Nix useless PR_GROWINGNOWAIT bit.
 
 This was introduced back in 2017 as an attempt to avoid spurious
 failure in concurrent PR_NOWAIT allocations, while still serializing
 calls to the pool's back end allocator to avoid fragmentation:
 
 https://mail-index.NetBSD.org/source-changes/2017/12/16/msg090490.html
 
 However, this probably doesn't work very well when one pool_get call
 in the middle of pool_grow is _interrupted by_ another one (in an
 interrupt handler) -- the busy wait will turn into a deadlock:
 
 https://mail-index.NetBSD.org/current-users/2017/12/29/msg033000.html
 
 So the logic was changed to keep holding the lock across the backing
 allocator in PR_NOWAIT allocations -- this way, calls to the pool's
 back end allocator are still serialized, but we at least avoid
 holding the lock _while sleeping_ in the back end allocator:
 
 https://mail-index.NetBSD.org/current-users/2017/12/29/msg033001.html
 
 But with that change, the PR_GROWINGNOWAIT bit no longer served any
 purpose, because it only stays set _while the lock is held_ so no
 other threads can observe it anyway.
 
 Cleanup prompted by:
 
 PR kern/59411: deadlock on mbuf pool
 
 
 To generate a diff of this commit:
 cvs rdiff -u -r1.297 -r1.298 src/sys/kern/subr_pool.c
 cvs rdiff -u -r1.96 -r1.97 src/sys/sys/pool.h
 
 Please note that diffs are not public domain; they are subject to the
 copyright notices on the relevant files.
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.