Re: smr inp breaks some jail use cases and panics with i915kms don't switch to the console anymore

On 12/13/21 12:25 PM, Gleb Smirnoff wrote:
> On Mon, Dec 13, 2021 at 11:56:35AM -0800, John Baldwin wrote:
> J> > J> So there are two things here.  The root issue is that the devel/apr1 port
> J> > J> runs a configure test for TCP_NDELAY being inherited by accepted sockets.
> J> > J> This test panics because prison_check_ip4() tries to lock a prison mutex
> J> > J> to walk the IPs assigned to a jail, but the caller (in_pcblookup_hash()) has
> J> > J> done an smr_enter() which is a critical_enter():
> J> >
> J> > The first one is known, and I got a patch to fix it:
> J> >
> J> > https://reviews.freebsd.org/D33340
> J> >
> J> > However, a pre-requisite to this simple patch is more complex:
> J> >
> J> > https://reviews.freebsd.org/D33339
> J> >
> J> > There is some discussion on how to improve that, and I decided to do that
> J> > rather than stick to original version. So I takes a few extra days.
> J> >
> J> > We could push D33340 into main, if the negative effects (raciness of
> J> > the prison check) is considered lesser evil then potentially contested
> J> > mtx_lock in smr section.
> J>
> J> I think raciness is probably better than always panicking as it does today.
> 
> AFAIK, today it will always panic only with WITNESS. Without WITNESS it would
> pass through mtx_lock as long as the mutex is not locked.

Yes, but the default kernel on head is GENERIC which has witness enabled, hence
the out of the box kernel panics reliably. :)

> So, do you suggest to push D33340 before finalizing D33339?

Yes, I think so.

-- 
John Baldwin