Hi Samuel
On Tue, Oct 31, 2023 at 9:14 PM Samuel Thibault <samuel.thiba...@gnu.org>
wrote:
> Samuel Thibault, le mer. 01 nov. 2023 01:50:40 +0100, a ecrit:
> > Samuel Thibault, le mar. 31 oct. 2023 04:40:43 +0100, a ecrit:
> > > Samuel Thibault, le lun. 30 oct. 2023 18:35:03 +0100, a ecrit:
> > > > Samuel Thibault, le dim. 29 oct. 2023 23:27:22 +0100, a ecrit:
> > > > > Samuel Thibault, le ven. 27 oct. 2023 08:48:19 +0200, a ecrit:
> > > > > > while [ "$(echo -n `echo internal/reflectlite.s-gox | sed -e
> 's/s-gox/gox/' ` )" = internal/reflectlite.gox ] ; do : ; done
> > > > >
> > > > > For now, I could reproduce with
> > > > >
> > > > > time while [ "$(echo -n `echo a` )" = a ] ; do : ; done
> > > > >
> > > > > by running two of them in parallel, along with an apt install loop
> in
> > > > > parallel. It takes a few hours to reproduce (sometimes 1, sometimes
> > > > > 3...)
> > > >
> > > > It seems to happen more often when running inside a chroot (possibly
> > > > because of the intermediate firmlink redirection?), and possibly
> > > > eatmydata also makes it more frequent.
> > >
> > > (it looks like there are memory leaks in proc, its vminfo keeps
> > > increasing).
> >
> > It seems 64bit-specific: the program below makes proc leak memory, 100
> > vminfo lines at a time. Possibly __mach_msg_destroy doesn't actually
> > properly parse messages to be destroyed, so that in the error case the
> > server leaks non-inline data? Flavio, perhaps you have an idea?
>
> Realizing only now by reading the __mach_msg_destroy assembly...
>
> unsigned int msgt_inline : 1,
> msgt_longform : 1,
> msgt_deallocate : 1,
> msgt_name : 8,
> msgt_size : 16,
> msgt_unused : 5;
>
> This field ordering makes reading them overly complex... It'll be a pain
> to rebootstrap, but perhaps we do want to put msgt_size and msgt_name
> first?
>
I only moved msgt_size to the end of the struct since a small number of
(deprecated) RPC types
require msgt_size to be 2 bytes long and those can be shortened to be under
1 byte.
We could end up with a much larger contiguous msgt_unused that could be
used for
other things in the future.
In relation to other changes we have to do for finishing the ABI... I think
we have a reasonable
ABI now. However, I wonder if it would be simpler to just ask the user land
to pass port names using
the following struct:
#ifdef KERNEL
union mach_rpc_port {
mach_port_name_t name;
mach_port_t kernel_port;
};
#else
struct mach_rpc_port {
mach_port_name_t name;
int unused;
};
#endif
It would make the kernel simpler since no message resizing is necessary and
most of the code using this
would be MiG generated.
Flavio
> Samuel
>
