[Webkit-unassigned] [Bug 191360] [GTK][WPE] Bubblewrap launcher should not depend on memfd

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=191360

--- Comment #4 from Michael Catanzaro <mcatanzaro at igalia.com> ---
Comment on attachment 354090
  --> https://bugs.webkit.org/attachment.cgi?id=354090
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=354090&action=review

OK, I was confused because I had forgotten about r237922 and was looking at the old version of SharedMemoryUnix.cpp!

>>> Source/WebCore/platform/glib/FileSystemGlib.cpp:477
>>> +            fileDescriptor = syscall(__NR_memfd_create, name, 0);
>> 
>> Since you're inside an #if HAVE(LINUX_MEMFD_H) guard, you know linux/memfd.h is available, and can use it instead of syscall(). We were using syscall() to ensure this works when memfd.h is not available.
> 
> Can't we have newer glibc with old kernel? that's what ENOSYS is detecting, isn't it?

If you're checking for linux/memfd.h, you should use it. Right now you check to make sure the header exists, and include the header, but don't actually use anything from the header. So that doesn't make sense. r237922 has the same problem, which I missed when I reviewed it.

So I would replace this syscall() and the syscall() in SharedMemoryUnix.cpp with calls to memfd_create(). Then you can get rid of the #include <sys/syscall.h>.

Alternatively, you could take the opposite route, get rid of the checks for linux/memfd.h, and just rely on syscall(), like Patrick's original code was doing. Either way is fine IMO. But checking for the header and including it and not using it isn't fine!

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-unassigned/attachments/20181108/6ddc2f75/attachment.html>