Re: kernel behaviour, was Re: dash behaviour

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.