[PATCH libxshmfence v2] futex: unbreak build on FreeBSD 11.0+

From: Jung-uk Kim Date: Tue, 15 Apr 2014 17:08:46 + In file included from src/xshmfence_alloc.c:27: In file included from src/xshmfenceint.h:32: src/xshmfence_futex.h:40:39: error: use of undeclared identifier 'INT_MAX' return sys_futex(addr, UMTX_OP_WAKE, INT_MAX);

Re: [PATCH xserver] dix: unbreak --with-dtrace (default) on FreeBSD 11.1+

On 07/ 7/17 10:59 AM, Jan Beich wrote: gmake[2]: Entering directory '/path/to/xserver/dix' /usr/sbin/dtrace -G -C -o dtrace-dix.o -s ../dix/Xserver.d .libs/atom.o ... dtrace: failed to compile script ../dix/Xserver.d: line 26: useless declaration gmake[2]: *** [Makefile:1007: dtrace-dix.o] Error

Re: [PATCH xserver 1/2] shm, xwayland: prefer atomic close-on-exec without O_TMPFILE

On Fri, Jul 7, 2017 at 22:41:06 +0200, Jan Beich wrote: > Julien Cristau writes: > > > On Fri, Jul 7, 2017 at 16:31:48 +0200, Jan Beich wrote: > >> - flags = fcntl(fd, F_GETFD); > >> +#ifndef HAVE_MKOSTEMP > >> + int flags = fcntl(fd, F_GETFD); > > > > Do we allow mixed

Re: [PATCH xserver 1/2] shm, xwayland: prefer atomic close-on-exec without O_TMPFILE

Julien Cristau writes: > On Fri, Jul 7, 2017 at 16:31:48 +0200, Jan Beich wrote: >> -flags = fcntl(fd, F_GETFD); >> +#ifndef HAVE_MKOSTEMP >> +int flags = fcntl(fd, F_GETFD); > > Do we allow mixed declarations and code nowadays? xserver has quite a few of those

Re: [PATCH libxshmfence] futex: unbreak build on FreeBSD 11.0+

On 07/07/2017 15:37, Julien Cristau wrote: > On Fri, Jul 7, 2017 at 16:31:07 +0200, Jan Beich wrote: > >> From: Jung-uk Kim >> Date: Tue, 15 Apr 2014 17:08:46 + >> >> In file included from src/xshmfence_alloc.c:27: >> In file included from src/xshmfenceint.h:32: >>

Re: [PATCH xserver 1/2] shm, xwayland: prefer atomic close-on-exec without O_TMPFILE

On Fri, Jul 7, 2017 at 16:31:48 +0200, Jan Beich wrote: > > Signed-off-by: Jan Beich > --- > Xext/shm.c | 9 +++-- > configure.ac| 2 +- > include/dix-config.h.in | 3 +++ > 3 files changed, 11 insertions(+), 3 deletions(-) > > diff --git

Re: [PATCH libxshmfence] futex: unbreak build on FreeBSD 11.0+

On Fri, Jul 7, 2017 at 16:31:07 +0200, Jan Beich wrote: > From: Jung-uk Kim > Date: Tue, 15 Apr 2014 17:08:46 + > > In file included from src/xshmfence_alloc.c:27: > In file included from src/xshmfenceint.h:32: > src/xshmfence_futex.h:40:39: error: use of undeclared

[PATCH xserver] dix: unbreak --with-dtrace (default) on FreeBSD 11.1+

gmake[2]: Entering directory '/path/to/xserver/dix' /usr/sbin/dtrace -G -C -o dtrace-dix.o -s ../dix/Xserver.d .libs/atom.o ... dtrace: failed to compile script ../dix/Xserver.d: line 26: useless declaration gmake[2]: *** [Makefile:1007: dtrace-dix.o] Error 1 Signed-off-by: Jan Beich

Re: [PATCH libxshmfence 2/2] alloc: close-on-exec without O_TMPFILE as well

The patch is v2 of https://lists.x.org/archives/xorg-devel/2013-December/039482.html v1 leaked files, see https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=217676 but no one noticed because FreeBSD < 12.0 (drm-next) lacks DRI3 support. ___

[PATCH] Xi: Test exact size of XIBarrierReleasePointer

From: Michal Srb Otherwise a client can send any value of num_barriers and cause reading or swapping of values on heap behind the receive buffer. --- Xi/xibarriers.c | 9 ++--- 1 file changed, 6 insertions(+), 3 deletions(-) diff --git a/Xi/xibarriers.c b/Xi/xibarriers.c

Re: [PATCH] os: Make sure big requests have sufficient length.

Here is a script that can be used to crash X server using a broken big request for PolyLine. It connects to DISPLAY=:1 and doesn't support authentication. Look inside the script for more details. Other requests could be used to crash X server in similar way, for example SetFontPath. Michal

[PATCH] os: Make sure big requests have sufficient length.

From: Michal Srb A client can send a big request where the 32B "length" field has value 0. When the big request header is removed and the is length corrected, the value will underflow to 0x. Functions processing the request later will think that the client sent much

[PATCH libxshmfence 2/2] alloc: close-on-exec without O_TMPFILE as well

Signed-off-by: Jan Beich --- configure.ac | 2 +- src/xshmfence_alloc.c | 13 + 2 files changed, 14 insertions(+), 1 deletion(-) diff --git a/configure.ac b/configure.ac index 0c98875..2d55890 100644 --- a/configure.ac +++ b/configure.ac @@ -89,7 +89,7

[PATCH xserver 1/2] shm, xwayland: prefer atomic close-on-exec without O_TMPFILE

Signed-off-by: Jan Beich --- Xext/shm.c | 9 +++-- configure.ac| 2 +- include/dix-config.h.in | 3 +++ 3 files changed, 11 insertions(+), 3 deletions(-) diff --git a/Xext/shm.c b/Xext/shm.c index 91ea90b14..6edeba6fb 100644 --- a/Xext/shm.c +++

[PATCH libxshmfence] futex: unbreak build on FreeBSD 11.0+

From: Jung-uk Kim Date: Tue, 15 Apr 2014 17:08:46 + In file included from src/xshmfence_alloc.c:27: In file included from src/xshmfenceint.h:32: src/xshmfence_futex.h:40:39: error: use of undeclared identifier 'INT_MAX' return sys_futex(addr, UMTX_OP_WAKE, INT_MAX);

[PATCH libICE 3/3] Make sure string is never NULL

`error_message` is passed in to strncpy() without any check, which doesn't handle NULL itself, so let's make it a valid empty string in cases where it was NULL. Signed-off-by: Eric Engestrom --- src/process.c | 14 -- 1 file changed, 12 insertions(+), 2

[PATCH libICE 2/3] Make sure error_message is a free-able string

Similar to the previous commit, assigning a static string would crash upon freeing. Signed-off-by: Eric Engestrom --- src/process.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/src/process.c b/src/process.c index 1d7c07a..1ee1ceb 100644 ---

[PATCH libICE 1/3] Make sure errorStr is a free-able string

If the `errorClass` isn't handled by the switch, `errorStr`'s initial value would be a pointer to some static memory with an empty string, and freeing it would most likely crash. Let's set it to NULL instead, as is done in other similar places. Signed-off-by: Eric Engestrom

[PATCH libICE 0/3] Fix memory access

Fix a few free() of static strings and strncpy() of NULL. BTW, there hasn't been a release in quite a few years, but some of the fixes might be interesting, especially ff5e59f322 "Use getentropy() if arc4random_buf() is not available". Could it be time to release 1.0.10/1.1.0? Cc: Alan

Re: [RFC PATCH v2] Add xdg-output protocol

Hi Pekka, > it's very hard for me to wrap my head around this, so the below may > sound a bit harsh, sorry. I don't mean to rant, but I feel there is > something fundamental amiss. I am diving back into the high-level > design which is fairly separated from the xdg_output interface. No worries,