See https://bugzilla.samba.org/show_bug.cgi?id=1032 and http://www.mail-archive.com/linux-390@vm.marist.edu/msg11467.html If we detect the machine architecture is s390 or s390x we MMAP_BLACKLIST 1
Created attachment 10186 [details] Detect s390(x) architecture and blacklist nmap
(In reply to comment #1) > Created attachment 10186 [details] > Detect s390(x) architecture and blacklist nmap HAVE_INCOHERENT_MMAP might be more suitable for master, as ntdb doesn't appear to check for HAVE_MMAP or MMAP_BLACKLIST. Please also sign your patch when once finalised and tested.
docs-xml/smbdotconf/tuning/usemmap.xml should also be updated to cover HPUX _and_ s390[x].
Created attachment 10197 [details] replace/wscript: Detect if we have a s390(x) system
Created attachment 10198 [details] Detect s390(x) architecture and blacklist nmap
instead of hard coding that this architecture is broken, which might get fixed in the future ... do you have an idea why the test from ./lib/replace/test/incoherent_mmap.c doesn't detect the mmap misbehaviour?
It seems that the underlying s390 memory management bug may have been fixed via CVE-2016-2143 - see: http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2016-2143 https://bugzilla.suse.com/show_bug.cgi?id=970504 We're still carrying Lars's patch locally, but I think it's worth checking whether we can now run without it (on a system carrying the CVE-2016-2143 fix). @Aurélien: any chance you could try to test this?
Comment on attachment 10198 [details] Detect s390(x) architecture and blacklist nmap The patch looks fine, but I think we should still check whether the underlying issues are fixed via CVE-2016-2143.