Re: kernel behaviour, was Re: dash behaviour

Finn Thain
2023-04-11T04:47:40Z

On Tue, 11 Apr 2023, Michael Schmitz wrote:

> >
> > I was able to find some command line options (init_on_alloc,
> > init_on_free) and the related Kconfig symbols
> > (CONFIG_INIT_ON_ALLOC_DEFAULT_ON, CONFIG_INIT_ON_FREE_DEFAULT_ON).
>
> Right - not sure how I managed to miss those.
>
> init_on_free might delay the boot process a while! But I would guesss
> init_on_alloc should be OK in the first instance.
>
> >
> > Given the compiler supports -fzero-call-used-regs=used-gpr there's
> > also CONFIG_ZERO_CALL_USED_REGS. Also CONFIG_INIT_STACK_ALL_ZERO
> > (-ftrivial-auto-var-init=zero).
> >

With all of those options enabled I still see dash crash sometimes. I
don't think I've learned anything new about the bug from that test.

> > The problem with these options is that they may produce a large effect
> > on the timing of events but they should still have no effect on the
> > behaviour of a correct userspace program.
> >
> > Since we are dealing with a suspect userspace program, what could we
> > learn from such a test? E.g. if the crashing stopped one could simply
> > attribute
>
> We don't know for definite that we deal with a suspect user space
> program - it might just be a change in a previously fine program that
> now exposes a subtle kernel bug (undetected for quite a long time, but
> we've seen a few of those now...)?
>

That's right -- the kernel is also suspect. As is glibc. I will keep
looking for some way to narrow down the search.