On Fri, 2018-07-13 at 01:08 +0200, Thomas Gleixner wrote:
> On Thu, 12 Jul 2018, Yu-cheng Yu wrote:
> >
> > On Thu, 2018-07-12 at 16:03 +0200, Ingo Molnar wrote:
> > >
> > > * Yu-cheng Yu <yu-cheng.yu@xxxxxxxxx> wrote:
> > > >
> > > > >
> > > > > >
> > > > > > diff --git a/arch/x86/kernel/ptrace.c b/arch/x86/kernel/ptrace.c
> > > > > > index e2ee403865eb..ac2bc3a18427 100644
> > > > > > --- a/arch/x86/kernel/ptrace.c
> > > > > > +++ b/arch/x86/kernel/ptrace.c
> > > > > > @@ -49,7 +49,9 @@ enum x86_regset {
> > > > > > REGSET_IOPERM64 = REGSET_XFP,
> > > > > > REGSET_XSTATE,
> > > > > > REGSET_TLS,
> > > > > > + REGSET_CET64 = REGSET_TLS,
> > > > > > REGSET_IOPERM32,
> > > > > > + REGSET_CET32,
> > > > > > };
> > > > > Why does REGSET_CET64 alias on REGSET_TLS?
> > > > In x86_64_regsets[], there is no [REGSET_TLS]. The core dump code
> > > > cannot handle holes in the array.
> > > Is there a fundamental (ABI) reason for that?
> > What I did was, ran Linux with 'slub_debug', and forced a core dump
> > (kill -abrt <pid>), then there was a red zone warning in the dmesg.
> > My feeling is there could be issues in the core dump code. These
> Kernel development is not about feelings.
I got that :-)
>
> Either you can track down the root cause or you cannot. There is no place
> for feelings and no place in between. And if you cannot track down the root
> cause and explain it proper then the resulting patch is just papering over
> the symptoms and will come back to hunt you (or others) sooner than later.
>
> No if, no could, no feelings. Facts is what matters. Really.
In kernel/ptrace.c,
find_regset(const struct user_regset_view *view, unsigned int type)
{
const struct user_regset *regset;
int n;
for (n = 0; n < view->n; ++n) {
regset = view->regsets + n;
if (regset->core_note_type == type)
return regset;
}
return NULL;
}
If there is a hole in the regset array, the empty slot's
regset->core_note_type is not defined.
We can add some comments near those enum's.
Yu-cheng
