bug-hurd
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH gnumach] Use MACH_PORT_NAME_NULL and MACH_PORT_NAME_DEAD when


From: Samuel Thibault
Subject: Re: [PATCH gnumach] Use MACH_PORT_NAME_NULL and MACH_PORT_NAME_DEAD when checking for null or dead rights
Date: Wed, 29 Nov 2023 10:13:32 +0100
User-agent: NeoMutt/20170609 (1.8.3)

Flavio Cruz, le mer. 29 nov. 2023 00:28:38 -0500, a ecrit:
> Comparing mach_port_name_t that is MACH_PORT_NAME_DEAD against
> MACH_PORT_DEAD will always return false.
> ---
>  ipc/ipc_space.h | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/ipc/ipc_space.h b/ipc/ipc_space.h
> index 9b199de..3f0eaa0 100644
> --- a/ipc/ipc_space.h
> +++ b/ipc/ipc_space.h
> @@ -161,7 +161,7 @@ extern volatile boolean_t mach_port_deallocate_debug;
>  static inline void
>  ipc_entry_lookup_failed(mach_msg_header_t *msg, mach_port_name_t name)
>  {
> -     if (name == MACH_PORT_NULL || name == MACH_PORT_DEAD)
> +     if (name == MACH_PORT_NAME_NULL || name == MACH_PORT_NAME_DEAD)
>               return;
>       printf("task %.*s looked up a bogus port %lu for %d, most probably a 
> bug.\n", (int) sizeof current_task()->name, current_task()->name, (unsigned 
> long) name, msg->msgh_id);
>       if (mach_port_deallocate_debug)

Oh, my bad!

Flávio Cruz, le mer. 29 nov. 2023 00:35:06 -0500, a ecrit:
> On Tue, Nov 28, 2023 at 7:53 PM Samuel Thibault <[1]samuel.thibault@gnu.org>
> wrote:
> 
>     Samuel Thibault, le mer. 29 nov. 2023 00:19:41 +0100, a ecrit:
>     > I'm hitting the last assertion, not sure exactly where it is coming from
>     yet.
> 
>     Ok, I missed updating libc :) Now fixed. I'm however getting:
> 
>     task /sbin/getty(631) looked up a bogus port 4294967295 for 28000, most
>     probably a bug.
> 
>     it seems the extension of MACH_PORT_DEAD doesn't work.
> 
> 
> Thanks for checking. I think the comparison in gnumach will always be false
> because the name is up-cast to a mach_port_t.
> However, this change does not seem to be a no-op since we haven't seen this
> message before, right?

This message is new, and I missed the _name_t type.

So we're now just missing turning the assert into errors.

Samuel



reply via email to

[Prev in Thread] Current Thread [Next in Thread]