public inbox for libc-alpha@sourceware.org
 help / color / mirror / Atom feed
From: Samuel Thibault <samuel.thibault@gnu.org>
To: Sergey Bugaev <bugaevc@gmail.com>
Cc: libc-alpha@sourceware.org, bug-hurd@gnu.org
Subject: Re: [PATCH] hurd: Run init_pids () before init_dtable ()
Date: Mon, 17 Apr 2023 23:05:14 +0200	[thread overview]
Message-ID: <20230417210514.3sgkgkfr64rezaiz@begin> (raw)
In-Reply-To: <20230415190856.109348-1-bugaevc@gmail.com>

Applied, thanks!

Sergey Bugaev, le sam. 15 avril 2023 22:08:56 +0300, a ecrit:
> 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
> 

-- 
Samuel
---
Pour une évaluation indépendante, transparente et rigoureuse !
Je soutiens la Commission d'Évaluation de l'Inria.

  reply	other threads:[~2023-04-17 21:05 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   ` [PATCH] hurd: Run init_pids () before init_dtable () Sergey Bugaev
2023-04-17 21:05     ` Samuel Thibault [this message]
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=20230417210514.3sgkgkfr64rezaiz@begin \
    --to=samuel.thibault@gnu.org \
    --cc=bug-hurd@gnu.org \
    --cc=bugaevc@gmail.com \
    --cc=libc-alpha@sourceware.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).