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

[Sergey Bugaev]

On Sun, Nov 7, 2021 at 6:00 PM Samuel Thibault <samuel.thibault@gnu.org> wrote:
> > That doesn't seem to work: it uses support_descriptors_* () which
> > walks over /proc/self/fd/ which procfs doesn't implement — though I
> > guess it could, via msg_get_dtable () & msg_get_fd () and even
> > FS_RETRY_MAGICAL.
>
> It'd probably not that simple, because self/ is actually just a
> magic retry on the pid variable, so in the end you'd be just opening
> /proc/<callerpid>/fd. Exposing fd there with a magic retry would expose
> the fd of the _caller_ in all /proc/*/, which is not what we want: we
> want the fd/ there to be per-pid.

What I meant is if we see a dir_lookup ("self/fd/42"), we might just
tell you to retry with your own fd 42, without having to actually
resolve what "self" means in terms of PIDs. But that could be just a
potential optimization; msg_get_dtable () and msg_get_fd () should
work for any specific PID.

> > Is there some way to add sysdep-specific implementations of support/
> > functions?
>
> I see #ifdef __linux__ there so I guess adding #ifdef __GNU__ there
> would be fine.

Right, good point.

> I assume you have tested your glibc patch with your own baked test?

I have tested it locally, and it worked just as expected, yes.

I might have made a mistake in the patch: should the symbol version be
GLIBC_2.35 and not GLIBC_2.34? I also don't think I quite understand
what __libc_close_range would be useful for (over __close_range) and
so whether it's needed, but other related symbols seem to have their
__libc-prefixed versions, so I've added that one too.

Also maybe you happen to know: why are the argument names in the
header prefixed with double underscores (__first, __last, __flags)? I
mimicked what I saw elsewhere, but I'm wondering about the purpose of
this.

Sergey