From: Sergey Bugaev <bugaevc@gmail.com>
To: libc-alpha@sourceware.org, bug-hurd@gnu.org
Cc: Samuel Thibault <samuel.thibault@gnu.org>,
Sergey Bugaev <bugaevc@gmail.com>
Subject: [PATCH] hurd: Run init_pids () before init_dtable ()
Date: Sat, 15 Apr 2023 22:08:56 +0300 [thread overview]
Message-ID: <20230415190856.109348-1-bugaevc@gmail.com> (raw)
In-Reply-To: <20230415175826.at5pjnu2wp54vlhv@begin>
Much as the comment says, things on _hurd_subinit assume that _hurd_pid
is already initialized by the time _hurd_subinit is run, so
_hurd_proc_subinit has to run before it. Specifically, init_dtable ()
calls _hurd_port2fd (), which uses _hurd_pid and _hurd_pgrp to set up
ctty handling. With _hurd_subinit running before _hurd_proc_subinit,
ctty setup was broken:
13<--33(pid1255)->term_getctty () = 0 4<--39(pid1255)
task16(pid1255)->mach_port_deallocate (pn{ 10}) = 0
13<--33(pid1255)->term_open_ctty (0 0) = 0x40000016 (Invalid argument)
Fix this by running the _hurd_proc_subinit hook in the correct place --
just after _hurd_portarray is set up (so the proc server port is
available in its usual place) and just before running _hurd_subinit.
Fixes 1ccbb9258eed0f667edf459a28ba23a805549b36
("hurd: Notify the proc server later during initialization").
Signed-off-by: Sergey Bugaev <bugaevc@gmail.com>
---
hurd/hurdinit.c | 18 +++++++++---------
1 file changed, 9 insertions(+), 9 deletions(-)
diff --git a/hurd/hurdinit.c b/hurd/hurdinit.c
index f88c5666..d0c7a831 100644
--- a/hurd/hurdinit.c
+++ b/hurd/hurdinit.c
@@ -54,6 +54,10 @@ _hurd_ports_use (int which, error_t (*operate) (mach_port_t))
DEFINE_HOOK (_hurd_subinit, (void));
+/* Hook for things which should be initialized as soon as the proc
+ server is available. */
+DEFINE_HOOK (_hurd_proc_subinit, (void));
+
__typeof (_hurd_proc_init) _hurd_new_proc_init; /* below */
/* Initialize the library data structures from the
@@ -105,6 +109,11 @@ _hurd_init (int flags, char **argv,
*/
}
+ /* Call other things which want to do some initialization. These are not
+ on the _hurd_subinit hook because things there assume that things done
+ here, like _hurd_pid, are already initialized. */
+ RUN_RELHOOK (_hurd_proc_subinit, ());
+
/* Call other things which want to do some initialization. These are not
on the __libc_subinit hook because things there like to be able to
assume the availability of the POSIX.1 services we provide. */
@@ -148,10 +157,6 @@ libc_hidden_def (_hurd_libc_proc_init)
sure the arguments are never visible with `ps'. */
int _hide_arguments, _hide_environment;
-/* Hook for things which should be initialized as soon as the proc
- server is available. */
-DEFINE_HOOK (_hurd_proc_subinit, (void));
-
/* Do startup handshaking with the proc server just installed in _hurd_ports.
Call _hurdsig_init to set up signal processing. */
@@ -187,11 +192,6 @@ _hurd_new_proc_init (char **argv,
/* Initialize proc server-assisted fault recovery for the signal thread. */
_hurdsig_fault_init ();
- /* Call other things which want to do some initialization. These are not
- on the _hurd_subinit hook because things there assume that things done
- here, like _hurd_pid, are already initialized. */
- RUN_RELHOOK (_hurd_proc_subinit, ());
-
/* XXX This code should probably be removed entirely at some point. This
conditional should make it reasonably usable with old gdb's for a
while. Eventually it probably makes most sense for the exec server to
--
2.39.2
next prev parent reply other threads:[~2023-04-15 19:09 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-04-15 16:17 [PATCH 0/1] Let's improve/fix ccty handling Sergey Bugaev
2023-04-15 16:17 ` [PATCH 1/1] hurd: Avoid extra ctty RPCs in init_dtable () Sergey Bugaev
2023-04-17 12:08 ` Samuel Thibault
2023-04-15 17:58 ` [PATCH 0/1] Let's improve/fix ccty handling Samuel Thibault
2023-04-15 19:08 ` Sergey Bugaev [this message]
2023-04-17 21:05 ` [PATCH] hurd: Run init_pids () before init_dtable () Samuel Thibault
2023-04-17 12:14 ` [PATCH 0/1] Let's improve/fix ccty handling Samuel Thibault
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20230415190856.109348-1-bugaevc@gmail.com \
--to=bugaevc@gmail.com \
--cc=bug-hurd@gnu.org \
--cc=libc-alpha@sourceware.org \
--cc=samuel.thibault@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).