On Wed, Feb 08, 2023 at 12:47:23PM +0100, Claudio Jeker wrote:
> On Wed, Feb 08, 2023 at 12:40:50PM +0100, Mark Kettenis wrote:
> > > Date: Wed, 8 Feb 2023 14:17:14 +0300
> > > From: Vitaliy Makkoveev <m...@openbsd.org>
> > >
> > > On Tue, Feb 07, 2023 at 05:42:40PM +0300, Vitaliy Makkoveev wrote:
> > > >
> > > > > > Otherwise, if you are concerning about serialized `p_sigmask' and
> > > > > > P_SIGSUSPEND, dosigsuspend() should be left under kernel lock:
> > > > > >
> > > > > > if (sigmask) {
> > > > > > KERNEL_LOCK();
> > > > > > dosigsuspend(p, *sigmask &~ sigcantmask);
> > > > > > KERNEL_UNLOCK();
> > > > > > }
> > > > >
> > > > > This is a hack but would allow progress. Now I would prefer if
> > > > > dosigsuspend() is made safe so that the KERNEL_LOCK is not needed.
> > > > > Which
> > > > > would also allow sigsuspend to be called with NOLOCK.
> > > > >
> > > >
> > > > Makes sense, but sigsuspend(2) will not be unlocked together with
> > > > select(2), so dosigsuspend() could be left under kernel lock for a
> > > > while.
> > > >
> > >
> > > Now, I want to keep dosigsuspend() under the kernel lock. To me it's
> > > better to unlock it together with sigsuspend(2) to separate possible
> > > signal related fallout. This still makes sense because signal mask is
> > > the optional arg for pselect(2) only. Except the local event data
> > > conversion, poll(2) internals are the same as select(2) internals, it
> > > makes sense to unlock them both.
> > >
> > > This doesn't mean I dropped dosigsuspend(), I'm still waiting feedback
> > > for barriers.
> >
> > Splitting it this way makes sense to me.
>
> I agree. Will throw that onto my bgpd test box that will test the poll
> case.
>
Can I push this forward?
