On 03/26, Yu, Fenghua wrote:
>
> > On 03/05, Oleg Nesterov wrote:
> >
> > void sighup(int sig, siginfo_t *info, void *ctxt) {
> > struct ucontext *uctxt = ctxt;
> > struct sigcontext *sctxt = (void*)>uc_mcontext;
> >
> > printf("SIGHUP! %p\n", sctxt->fpstate);
> > sctxt->fpstate =
On Thu, Mar 26, 2015 at 10:48:18PM +, Yu, Fenghua wrote:
> > > sctxt->fpstate=(void *)1 changes the fpstate pointer in the
> > > sigcontext. It will generate segfault and bad frame info in kernel.
> > >
> > > This is expected behavior, right? Is this still a valid test?
> >
> > Just to be
On Thu, Mar 26, 2015 at 10:48:18PM +, Yu, Fenghua wrote:
sctxt-fpstate=(void *)1 changes the fpstate pointer in the
sigcontext. It will generate segfault and bad frame info in kernel.
This is expected behavior, right? Is this still a valid test?
Just to be clear, I saw a
On 03/26, Yu, Fenghua wrote:
On 03/05, Oleg Nesterov wrote:
void sighup(int sig, siginfo_t *info, void *ctxt) {
struct ucontext *uctxt = ctxt;
struct sigcontext *sctxt = (void*)uctxt-uc_mcontext;
printf(SIGHUP! %p\n, sctxt-fpstate);
sctxt-fpstate = (void *)1;
> From: Hansen, Dave
> Sent: Thursday, March 26, 2015 3:44 PM
> On 03/26/2015 03:37 PM, Yu, Fenghua wrote:
> >> > void sighup(int sig, siginfo_t *info, void *ctxt) {
> >> > struct ucontext *uctxt = ctxt;
> >> > struct sigcontext *sctxt = (void*)>uc_mcontext;
> >> >
> >> > printf("SIGHUP! %p\n",
On 03/26/2015 03:37 PM, Yu, Fenghua wrote:
>> > void sighup(int sig, siginfo_t *info, void *ctxt) {
>> >struct ucontext *uctxt = ctxt;
>> >struct sigcontext *sctxt = (void*)>uc_mcontext;
>> >
>> >printf("SIGHUP! %p\n", sctxt->fpstate);
>> >sctxt->fpstate = (void *)1;
>
> From: Oleg Nesterov [mailto:o...@redhat.com]
> Sent: Thursday, March 05, 2015 10:22 AM
>
> On 03/05, Oleg Nesterov wrote:
> >
>
> Does it trigger something else on your machine?
>
> Oleg.
>
> #include
> #include
> #include
> #include
>
> void sighup(int sig, siginfo_t *info, void *ctxt)
On 03/26/2015 03:37 PM, Yu, Fenghua wrote:
void sighup(int sig, siginfo_t *info, void *ctxt) {
struct ucontext *uctxt = ctxt;
struct sigcontext *sctxt = (void*)uctxt-uc_mcontext;
printf(SIGHUP! %p\n, sctxt-fpstate);
sctxt-fpstate = (void *)1;
sctxt-fpstate=(void *)1
From: Hansen, Dave
Sent: Thursday, March 26, 2015 3:44 PM
On 03/26/2015 03:37 PM, Yu, Fenghua wrote:
void sighup(int sig, siginfo_t *info, void *ctxt) {
struct ucontext *uctxt = ctxt;
struct sigcontext *sctxt = (void*)uctxt-uc_mcontext;
printf(SIGHUP! %p\n, sctxt-fpstate);
From: Oleg Nesterov [mailto:o...@redhat.com]
Sent: Thursday, March 05, 2015 10:22 AM
On 03/05, Oleg Nesterov wrote:
Does it trigger something else on your machine?
Oleg.
#include stdio.h
#include signal.h
#include unistd.h
#include ucontext.h
void sighup(int sig, siginfo_t
On 03/05/2015 10:42 AM, Borislav Petkov wrote:
> On Thu, Mar 05, 2015 at 04:13:38PM +0100, Oleg Nesterov wrote:
>> > Yes, yes, sure. That is what I meant, sorry for confusion.
> It might be worth to try with Quentin's patch which fixes the exception
> tables. I can imagine with wrong exception
On 03/05, Dave Hansen wrote:
>
> On 03/05/2015 10:22 AM, Oleg Nesterov wrote:
> > On 03/05, Oleg Nesterov wrote:
> >> I _think_ that the difference is that eager_fpu_init()->xrstor_state()
> >> was called before apply_alternatives(), so it used XRSTOR.
> >>
> >> Note also that (before this commit)
On Thu, Mar 05, 2015 at 04:13:38PM +0100, Oleg Nesterov wrote:
> Yes, yes, sure. That is what I meant, sorry for confusion.
It might be worth to try with Quentin's patch which fixes the exception
tables. I can imagine with wrong exception tables us jumping somewhere
in the fields and causing this
On 03/05/2015 10:22 AM, Oleg Nesterov wrote:
> On 03/05, Oleg Nesterov wrote:
>>
>> I _think_ that the difference is that eager_fpu_init()->xrstor_state()
>> was called before apply_alternatives(), so it used XRSTOR.
>>
>> Note also that (before this commit) restore_fpu_checking() was almost
>>
On 03/05/2015 10:22 AM, Oleg Nesterov wrote:
> On 03/05, Oleg Nesterov wrote:
>> I _think_ that the difference is that eager_fpu_init()->xrstor_state()
>> was called before apply_alternatives(), so it used XRSTOR.
>>
>> Note also that (before this commit) restore_fpu_checking() was almost
>> never
On 03/04, Borislav Petkov wrote:
>
> On Wed, Mar 04, 2015 at 08:06:51PM +0100, Oleg Nesterov wrote:
> > Thanks. I'll try to investigate tomorrow.
> >
> > Well, the kernel crashes because xrstor_state() is buggy, Quentin already
> > has a fix.
> >
> > But #GP should be explained...
>
> Could it be
On 03/05, Quentin Casasnovas wrote:
>
> On Wed, Mar 04, 2015 at 08:06:51PM +0100, Oleg Nesterov wrote:
> >
> > Well, the kernel crashes because xrstor_state() is buggy, Quentin already
> > has a fix.
> >
> > But #GP should be explained...
> >
>
> Hopefully the couple of fixes to prevent the #GP
On Wed, Mar 04, 2015 at 08:06:51PM +0100, Oleg Nesterov wrote:
> On 03/04, Dave Hansen wrote:
> >
> > I'm running a commit from the tip/x86/fpu branch: ae486033b98. It's on
> > a system which I normally boot with 'noxsaves'. When I boot without
> > 'noxsaves' it is getting a GPF around the time
On 03/05/2015 10:42 AM, Borislav Petkov wrote:
On Thu, Mar 05, 2015 at 04:13:38PM +0100, Oleg Nesterov wrote:
Yes, yes, sure. That is what I meant, sorry for confusion.
It might be worth to try with Quentin's patch which fixes the exception
tables. I can imagine with wrong exception tables us
On Wed, Mar 04, 2015 at 08:06:51PM +0100, Oleg Nesterov wrote:
On 03/04, Dave Hansen wrote:
I'm running a commit from the tip/x86/fpu branch: ae486033b98. It's on
a system which I normally boot with 'noxsaves'. When I boot without
'noxsaves' it is getting a GPF around the time that init
On 03/05, Quentin Casasnovas wrote:
On Wed, Mar 04, 2015 at 08:06:51PM +0100, Oleg Nesterov wrote:
Well, the kernel crashes because xrstor_state() is buggy, Quentin already
has a fix.
But #GP should be explained...
Hopefully the couple of fixes to prevent the #GP should be merged
On 03/04, Borislav Petkov wrote:
On Wed, Mar 04, 2015 at 08:06:51PM +0100, Oleg Nesterov wrote:
Thanks. I'll try to investigate tomorrow.
Well, the kernel crashes because xrstor_state() is buggy, Quentin already
has a fix.
But #GP should be explained...
Could it be one of those
On 03/05/2015 10:22 AM, Oleg Nesterov wrote:
On 03/05, Oleg Nesterov wrote:
I _think_ that the difference is that eager_fpu_init()-xrstor_state()
was called before apply_alternatives(), so it used XRSTOR.
Note also that (before this commit) restore_fpu_checking() was almost
never called
On 03/05/2015 10:22 AM, Oleg Nesterov wrote:
On 03/05, Oleg Nesterov wrote:
I _think_ that the difference is that eager_fpu_init()-xrstor_state()
was called before apply_alternatives(), so it used XRSTOR.
Note also that (before this commit) restore_fpu_checking() was almost
never called
On Thu, Mar 05, 2015 at 04:13:38PM +0100, Oleg Nesterov wrote:
Yes, yes, sure. That is what I meant, sorry for confusion.
It might be worth to try with Quentin's patch which fixes the exception
tables. I can imagine with wrong exception tables us jumping somewhere
in the fields and causing this
On 03/05, Dave Hansen wrote:
On 03/05/2015 10:22 AM, Oleg Nesterov wrote:
On 03/05, Oleg Nesterov wrote:
I _think_ that the difference is that eager_fpu_init()-xrstor_state()
was called before apply_alternatives(), so it used XRSTOR.
Note also that (before this commit)
On Wed, Mar 04, 2015 at 08:06:51PM +0100, Oleg Nesterov wrote:
> Thanks. I'll try to investigate tomorrow.
>
> Well, the kernel crashes because xrstor_state() is buggy, Quentin already
> has a fix.
>
> But #GP should be explained...
Could it be one of those conditions for which XRSTORS #GPs,
On 03/04/2015 11:06 AM, Oleg Nesterov wrote:
> On 03/04, Dave Hansen wrote:
>> > I'm running a commit from the tip/x86/fpu branch: ae486033b98. It's on
>> > a system which I normally boot with 'noxsaves'. When I boot without
>> > 'noxsaves' it is getting a GPF around the time that init is forked
Thanks. I'll try to investigate tomorrow.
Well, the kernel crashes because xrstor_state() is buggy, Quentin already
has a fix.
But #GP should be explained...
On 03/04, Dave Hansen wrote:
>
> I'm running a commit from the tip/x86/fpu branch: ae486033b98. It's on
> a system which I normally boot
I'm running a commit from the tip/x86/fpu branch: ae486033b98. It's on
a system which I normally boot with 'noxsaves'. When I boot without
'noxsaves' it is getting a GPF around the time that init is forked off.
The full oops is below, but addr2line points to the "alternative_input("
line in
I'm running a commit from the tip/x86/fpu branch: ae486033b98. It's on
a system which I normally boot with 'noxsaves'. When I boot without
'noxsaves' it is getting a GPF around the time that init is forked off.
The full oops is below, but addr2line points to the alternative_input(
line in
Thanks. I'll try to investigate tomorrow.
Well, the kernel crashes because xrstor_state() is buggy, Quentin already
has a fix.
But #GP should be explained...
On 03/04, Dave Hansen wrote:
I'm running a commit from the tip/x86/fpu branch: ae486033b98. It's on
a system which I normally boot
On 03/04/2015 11:06 AM, Oleg Nesterov wrote:
On 03/04, Dave Hansen wrote:
I'm running a commit from the tip/x86/fpu branch: ae486033b98. It's on
a system which I normally boot with 'noxsaves'. When I boot without
'noxsaves' it is getting a GPF around the time that init is forked off.
And
On Wed, Mar 04, 2015 at 08:06:51PM +0100, Oleg Nesterov wrote:
Thanks. I'll try to investigate tomorrow.
Well, the kernel crashes because xrstor_state() is buggy, Quentin already
has a fix.
But #GP should be explained...
Could it be one of those conditions for which XRSTORS #GPs, like
If
34 matches
Mail list logo
