glamor and the sync extension
Mark Kettenis
mark.kettenis at xs4all.nl
Sun Nov 15 10:41:17 PST 2015
> Date: Sun, 15 Nov 2015 09:53:57 -0800
> From: "Jasper St. Pierre" <jstpierre at mecheye.net>
>
> Should we just unconditionally enable xshmfence? Are there any OSes
> we care about that can't implement a fence primitive?
There currently is no implementation on OpenBSD, and that's the
platform I care about ;).
The futex implementation supportsLinux and FreeBSD. The pthreads
implementation should in theory supports many other OSes. But in
practice support for process-shared mutexes and condition variables
isn't very widespread. It probably works on Solaris, but not much
else.
An important reason why I haven't pushed for an xshmfence
implementation on OpenBSD is that I have some security concerns.
Especially with the pthreads implementation.
It is trivial to block any application that calls xshmfence_await() by
simply never triggering the fence. I guess that isn't a major concern
as long the xserver never waits on a fence and only triggers them.
I'm not sure that's the case though with dri3-enable glamor.
However, with the pthreads implementation, even triggering a fence
becomes dangerous since it needs to acquire a shared mutex before
broadcasting the condition. So a client could trivially DOS the
server by locking the mutex and never unlocking it. Doesn't even have
to be mailicious. A buggy client could simply crash after locking the
mutex and the server would be toast. So in my view the pthreads
implementation is not a robust xshmfence implementationand should
probably be avoided.
> On Sun, Nov 15, 2015 at 8:59 AM, Mark Kettenis <mark.kettenis at xs4all.nl> wrote:
> > Currently glamor hits an assertion on systems that don't have
> > xshmfence. This happens when the glamor code calls
> > miSyncGetScreenFuncs() because the miSyncScreenPrivateKey has not been
> > set up. For systems with xshmfence, this happens when
> > miSyncShmScreenInit() gets called, but that code is wrapped within
> > #ifdef HAVE_XSHMFENCE. The diff below simply calls miSyncSetup()
> > instead if HAVE_XSHMFENCE is not defined. This makes things work, but
> > I'm not sure if this is the right approach.
> >
> > Thoughts?
> >
> >
> > Index: glamor/glamor_sync.c
> > ===================================================================
> > RCS file: /cvs/xenocara/xserver/glamor/glamor_sync.c,v
> > retrieving revision 1.1
> > diff -u -p -r1.1 glamor_sync.c
> > --- glamor/glamor_sync.c 16 Sep 2015 19:10:21 -0000 1.1
> > +++ glamor/glamor_sync.c 15 Nov 2015 13:02:31 -0000
> > @@ -97,6 +97,9 @@ glamor_sync_init(ScreenPtr screen)
> > #ifdef HAVE_XSHMFENCE
> > if (!miSyncShmScreenInit(screen))
> > return FALSE;
> > +#else
> > + if (!miSyncSetup(screen))
> > + return FALSE;
> > #endif
> >
> > screen_funcs = miSyncGetScreenFuncs(screen);
> >
More information about the xorg-devel
mailing list