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.
--
:wq Claudio
