Re: Xorg bug returns: Too many files open in system

2021-11-06 Thread Samuel Thibault
Almudena Garcia, le sam. 06 nov. 2021 19:13:54 +0100, a ecrit: > Have you uploaded this to Debian GNU/Hurd's repository? I have uploaded to debian-ports, it takes 6h to get on the mirrors etc. Samuel

Re: Xorg bug returns: Too many files open in system

2021-11-06 Thread Almudena Garcia
Have you uploaded this to Debian GNU/Hurd's repository? I've just upgrade the system, but the problem continues here. El sáb, 6 nov 2021 a las 13:17, Samuel Thibault () escribió: > Samuel Thibault, le sam. 06 nov. 2021 13:16:08 +0100, a ecrit: > > Sergey Bugaev, le sam. 06 nov. 2021 14:26:23 +030

[PATCH] hurd: Implement close_range and closefrom

2021-11-06 Thread Sergey Bugaev
The close_range () function implements the same API as the Linux and FreeBSD syscalls. It operates atomically and reliably. The specified upper bound is clamped to the actual size of the file descriptor table; it is expected that the most common use case is with last = UINT_MAX. Like in the Linux

Re: Xorg bug returns: Too many files open in system

2021-11-06 Thread Sergey Bugaev
On Sat, Nov 6, 2021 at 3:16 PM Samuel Thibault wrote: > To exercise it you can probably move > sysdeps/unix/sysv/linux/tst-close_range.c to misc/, > and add it to tests in sysdeps/mach/hurd/Makefile too. That doesn't seem to work: it uses support_descriptors_* () which walks over /proc/self/fd/ w

Re: Xorg bug returns: Too many files open in system

2021-11-06 Thread Samuel Thibault
Samuel Thibault, le sam. 06 nov. 2021 13:16:08 +0100, a ecrit: > Sergey Bugaev, le sam. 06 nov. 2021 14:26:23 +0300, a ecrit: > > I investigated briefly and found this piece of code to be the likely > > culprit [0]. > > Yes. Unfortunately I apparently hadn't had the time, at the time, to > actuall

Re: Xorg bug returns: Too many files open in system

2021-11-06 Thread Samuel Thibault
Hello, Sergey Bugaev, le sam. 06 nov. 2021 14:26:23 +0300, a ecrit: > I investigated briefly and found this piece of code to be the likely > culprit [0]. Yes. Unfortunately I apparently hadn't had the time, at the time, to actually submit the fix I had uploaded as 0.62.3-1+hurd.1. Now done in ht

Re: Xorg bug returns: Too many files open in system

2021-11-06 Thread Sergey Bugaev
Hello, I investigated briefly and found this piece of code to be the likely culprit [0]. I also see that the previous investigation also arrived at the same conclusion [1]. [0]: https://gitlab.gnome.org/GNOME/vte/-/blob/db3c6253d7fa1645996a2abd9fd55df414ca4c2d/src/missing.cc#L218 [1]: https://li

Re: [PATCH] new interface: memory_object_get_proxy

2021-11-06 Thread Joan Lledó
Hi, I tested it and everything works fine. I'm attaching the two patches for convenience. About the name, feel free to change it if you want, although I think if we rename it then the function should be moved to vm_map.c, maybe just below vm_region()

[PATCH 1/2] new interface: memory_object_get_proxy

2021-11-06 Thread Joan Lledó
From: Joan Lledó To get a proxy to the region a given address belongs to, with protection and range limited to the region ones. * include/mach/mach4.defs: memory_object_get_proxy RPC declaration * vm/memory_object_proxy.c: memory_object_get_proxy implementation --- include/mach/mach4.defs | 10

[PATCH 2/2] Memory proxies: Add support for anonymous mappings

2021-11-06 Thread Joan Lledó
From: Sergey Bugaev * vm/memory_object_proxy.c: * memory_object_get_proxy(): * Return KERN_INVALID_ARGUMENT when the entry is a submap. * Create a pager for the vm_object when the entry doesn't have any yet, since it's an anonymous mapping. --- vm/memory_object_proxy.c | 21 +