I know I'm listed as a reviewer, but I can't assess the code change here. The gist of it looks good, though. I'd be a lot less worried about enabling the feature with this limiter in place.

Yes, that's true. The loop is effectively the same as the one used by NAT rules to assign a source port, but that would typically apply to outbound connections and so is less concerning. I'm not sure if 15k iterations is expensive enough for this to be a fatal problem, but it could well be.

Beating a closed ticket here, but in case anyone is reading this - wouldn't there be a way to DoS this?
If you know anything at all about the target network, it would seem that you could hammer the load balanced address 15k times to create states for all the source ports in the range, and then hit one of the other addresses that have rdr rules that translate to the same address. Each such hit would cause the loop to run 15k times, for as long as the initial states remain valid. Or am I completely misreading this?

How does this work for jailed processes/users? I may have missed out on something (a lot) since last I prodded the MAC framework, but IIRC the support for jail-specific rules is limited, at best?

• Add $zfskeys_timeout variable to $timeout variable

• Fix style

• Changes requested by dteske, others

In D21278#466622, @madpilot wrote:

In D21278#466552, @duchateau.olivier_gmail.com wrote:

I made some tests (on 12.0-STABLE):

Libepoxy and XPresent are required for support of vblank (Vertical blanking interval). Currently only GL backend (via libepoxy) is used. I get these warnings (.xession-errors)

(xfwm4:1092): xfwm4-WARNING **: 16:28:42.750: Unsupported GL renderer (llvmpipe (LLVM 8.0, 128 bits)).

(xfwm4:1092): xfwm4-WARNING **: 16:28:42.751: Screen is missing required GL renderer, GL support disabled.

This property (vblank) is by default on 'auto' xfconf-query -c xfwm4 -p /general/vblank_mode

Have you tested setting that to off?

According to compositor documentation, we can disable this property. If I use the kernel mode-setting port, borders are not well formed [1] (same result when vblank_mode is on 'auto'), but with Xorg drivers everything is fine (not checked warnings in .xsession-errors).

Then I tried with libXpresent (no update since 2015, but still uses by linux distributions), 2 backends are enabled, in my .xsession-errors messages related to xfwm4 disappeared. Render of borders (when I use the drm-kmod port) is always identical even if Xpresent is installed or not.

Presence of libXpresent avoids warnings for xfwm4. I can provide this port (and diff for x11-wm/xfce4-wm) if someone is interested.

If I understand the docs I read, the mere presence of libXpresent could not be enough. The window manager by default tries to autodetect what to use and could not even try using libXpresent by itself.

To be sure to test libXpresent you should run:

xfwm4 --vblank=xpresent --replace

I also noticed (on my laptop) compositor is not functional (it was functional with the previous stable release).

[1] http://pix.toile-libre.org/upload/original/1566927773.png

I have no idea what is causing this at this point.

Now first a personal note. My poudriere machine died just today. I was testing a libXpresent port. I could not fully test it but here is the XFCE 4.14 diff including this port and adding it as a dependency for xfwm:

https://people.freebsd.org/~madpilot/xfce414-libXpresent.diff

I'm posting this patch just in case someone could test it.

I will need a little time to fix or rebuild the failed machine before I can do much work on ports.

Apart from this we need some plan to get ahead on this. I'm personally out of ideas and unable to test it since it does not show on my hardware.

I'd like to understand if this is an xfce problem, an x11 problem or a driver problem. I'm asking someone with hardware showing the problem to run another compositing window manager, to check what happens.

I also need to decide if I should push to commit this update anyway, or wait for a solution. Keeping XFCE not updated indefinitely does not look like a good thing to me. Also because now I have problems updating the old ports. I'd need to build a brand new testing environment. I was hoping to update everything at once with this big update.

Does someone has a suggestion on how to address or manage this issue? Is it really a showstopper?

In D21278#466181, @madpilot wrote:

In D21278#466163, @duchateau.olivier_gmail.com wrote:

Can you specify exactly which driver is creating problems?

It is AMD Radeon R2.

vgapci0@pci0:0:1:0:     class=0x030000 card=0x108a1025 chip=0x98531002 rev=0x40 hdr=0x00
    vendor     = 'Advanced Micro Devices, Inc. [AMD/ATI]'
    device     = 'Mullins [Radeon R2 Graphics]'
    class      = display
    subclass   = VGA

Xorg loads the Vesa driver (amdgpu is also installed, but not loaded).

If I follow this documentation, I have same problem as Eirik.

So it depends on the hardware.

I'm almost sure it has to do with the compositing functionality. shadows, transparencies and the like. I'm sorry I have no idea how to "fix" this.

Could you try using some other compositing window manager and check if the problem appears with them too? (compiz for example)

Another thing to try iis disabling the compositing functionality in xfwm. I found this:

https://www.reddit.com/r/GlobalOffensiveLinux/comments/6b3cs5/is_it_possible_to_disable_compositing_in_xfce_for/

Could you try this and see if the problem goes away?

Has the new xfwm4 been tested with the modesetting X driver? When I do, all window decorations are black. That is - buttons and title shows up, also the corner pieces of windows, but the rest is just black. Switching to intel driver does not show this problem. Other window managers (windowmaker tested so far) do not seem to exhibit any such issues.

In D21278#465837, @duchateau.olivier_gmail.com wrote:

Your log is related to ibus, not xfce4-conf. Xfconf does not depend of dbus-glib anymore, only of gdbus through gio.

In D21278#465772, @madpilot wrote:

In D21278#465745, @ltning-freebsd_anduin.net wrote:

x11/xfce4-conf fails to build because it need dbus, but this has been removed from the Makefile.

The following needs adding back before it will build (using poudriere):
LIB_DEPENDS= libdbus-1.so:devel/dbus \

libdbus-glib-1.so:devel/dbus-glib

This isn't failing for me in poudriere. It builds fine(I've been testing all the xfce ports with poudriere with various FreeBSD versions and OPTIONS combinations for some time) and the resulting binaries are not linked with libdbus, which is the reason why I removed the dependency.

Also xfce components have been migrated away from dbus-glib to gdbus, which, if I'm correct, is included in glib, so the new versions don't need that library.

Could you provide a full build log for the failure so this can be investigated?

x11/xfce4-conf fails to build because it need dbus, but this has been removed from the Makefile.