Re: PR_GROWINGNOWAIT useless ?

[Taylor R Campbell <riastradh%NetBSD.org@localhost>]

> Date: Tue, 6 May 2025 11:54:50 +0200
> From: Manuel Bouyer <bouyer%antioche.eu.org@localhost>
> 
> while investigating the deadlock reported in
> https://mail-index.netbsd.org/tech-kern/2025/05/05/msg030407.html
> I looked at pool_grow(). It seems that the PR_GROWINGNOWAIT is used only for
> this:
>                         if (pp->pr_flags & PR_GROWINGNOWAIT) {
>                                 /*
>                                  * This needs an unlock/relock dance so
>                                  * that the other caller has a chance to
>                                  * run and actually do the thing.  Note 
>                                  * that this is effectively a busy-wait.
>                                  */  
>                                 mutex_exit(&pp->pr_lock);
>                                 mutex_enter(&pp->pr_lock);
>                                 return ERESTART;
>                         }
> 
> but as I understand it, the thread setting PR_GROWINGNOWAIT in pool_grow()
> is holding the pr_lock and will never release it before clearing
> PR_GROWINGNOWAIT. If pool_allocator_alloc() or pool_alloc_item_header()
> was releasing the lock, it would have to eventually sleep to reaquire
> it and it's not allowed without PR_WAITOK.
> So it seems that PR_GROWINGNOWAIT could be removed.

It looks like you deleted this code:

https://mail-index.netbsd.org/source-changes/2025/05/09/msg156870.html

I think you should put the code back as it was for now, because

(a) it appears to be harmless,

(b) it is unchanged since netbsd-9,

(c) it is the product of a series of changes in 2017 that I suspect we
    will want to disentangle all at once rather than piecemeal, and

(d) there is a good chance it is related to your PR kern/59411:
    deadlock on mbuf pool <https://gnats.NetBSD.org/59411>.

Changes to address the underlying problem head-on -- and whatever
problem motivated PR_GROWINGNOWAIT -- are likely to be easier to pull
up if you revert this change, and track any other changes in the PR,
so we have less to sort through back to netbsd-9 and it's all recorded
in one place.