On Fri, May 16, 2025 at 02:08:33AM +0000, Taylor R Campbell wrote:
> > Date: Tue, 6 May 2025 11:54:50 +0200
> > From: Manuel Bouyer <bou...@antioche.eu.org>
> >
> > 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
done
--
Manuel Bouyer <bou...@antioche.eu.org>
NetBSD: 26 ans d'experience feront toujours la difference
--
