On Sat, Jun 13, 2015 at 2:23 PM, Andy Lutomirski wrote:
> On Sat, Jun 13, 2015 at 12:03 AM, Ingo Molnar wrote:
>>
>> * Brian Gerst wrote:
>>
>>> On Fri, Jun 12, 2015 at 4:36 AM, Ingo Molnar wrote:
>>> >
>>> > * H. Peter Anvin wrote:
>>> >
>>> >> %es is used implicitly by string instructions.
>
On Sat, Jun 13, 2015 at 12:03 AM, Ingo Molnar wrote:
>
> * Brian Gerst wrote:
>
>> On Fri, Jun 12, 2015 at 4:36 AM, Ingo Molnar wrote:
>> >
>> > * H. Peter Anvin wrote:
>> >
>> >> %es is used implicitly by string instructions.
>> >
>> > Ok, so we are probably better off reloading ES as well ear
On Sat 2015-06-13 00:45:29, Denys Vlasenko wrote:
> On Fri, Jun 12, 2015 at 5:48 PM, Brian Gerst wrote:
> > If you follow the convoluted flow of the calls in this file,
> > ...
>
> Speaking of which. It is indeed quite bad.
>
> For one, saved_eip is only ever set to point to ret_point:
>
> ENTR
* Brian Gerst wrote:
> On Fri, Jun 12, 2015 at 4:36 AM, Ingo Molnar wrote:
> >
> > * H. Peter Anvin wrote:
> >
> >> %es is used implicitly by string instructions.
> >
> > Ok, so we are probably better off reloading ES as well early, right
> > when we return from the firmware, just in case some
* Srinivas Pandruvada wrote:
> On Fri, 2015-06-12 at 11:11 -0700, Andy Lutomirski wrote:
> > On Fri, Jun 12, 2015 at 8:48 AM, Brian Gerst wrote:
> > > On Fri, Jun 12, 2015 at 4:36 AM, Ingo Molnar wrote:
> > >>
> > >> * H. Peter Anvin wrote:
> > >>
> > >>> %es is used implicitly by string inst
On Fri, Jun 12, 2015 at 5:48 PM, Brian Gerst wrote:
> If you follow the convoluted flow of the calls in this file,
> ...
Speaking of which. It is indeed quite bad.
For one, saved_eip is only ever set to point to ret_point:
ENTRY(saved_eip).long 0
...
movl$ret_point, saved
On Fri, 2015-06-12 at 11:11 -0700, Andy Lutomirski wrote:
> On Fri, Jun 12, 2015 at 8:48 AM, Brian Gerst wrote:
> > On Fri, Jun 12, 2015 at 4:36 AM, Ingo Molnar wrote:
> >>
> >> * H. Peter Anvin wrote:
> >>
> >>> %es is used implicitly by string instructions.
> >>
> >> Ok, so we are probably bet
On Fri, Jun 12, 2015 at 8:48 AM, Brian Gerst wrote:
> On Fri, Jun 12, 2015 at 4:36 AM, Ingo Molnar wrote:
>>
>> * H. Peter Anvin wrote:
>>
>>> %es is used implicitly by string instructions.
>>
>> Ok, so we are probably better off reloading ES as well early, right
>> when we return from the firmw
On Fri, 2015-06-12 at 08:07 +0200, Ingo Molnar wrote:
> * Srinivas Pandruvada wrote:
>
> > Suspend to RAM process is returning to userspsace with DS set to KERNEL_DS
> > after resume, this cause general protection fault. [...]
>
> But s2ram has no influence on 'returning to user-space'. So unles
On Fri, Jun 12, 2015 at 4:36 AM, Ingo Molnar wrote:
>
> * H. Peter Anvin wrote:
>
>> %es is used implicitly by string instructions.
>
> Ok, so we are probably better off reloading ES as well early, right
> when we return from the firmware, just in case something does
> a copy before we hit the ES
* H. Peter Anvin wrote:
> %es is used implicitly by string instructions.
Ok, so we are probably better off reloading ES as well early, right
when we return from the firmware, just in case something does
a copy before we hit the ES restore in restore_processor_state(),
which is a generic C funct
%es is used implicitly by string instructions.
On June 12, 2015 12:50:13 AM PDT, Ingo Molnar wrote:
>
>* Andy Lutomirski wrote:
>
>> > --- a/arch/x86/kernel/acpi/wakeup_32.S
>> > +++ b/arch/x86/kernel/acpi/wakeup_32.S
>> > @@ -81,6 +81,10 @@ ENTRY(do_suspend_lowlevel)
>> > jmp ret_po
* Andy Lutomirski wrote:
> > --- a/arch/x86/kernel/acpi/wakeup_32.S
> > +++ b/arch/x86/kernel/acpi/wakeup_32.S
> > @@ -81,6 +81,10 @@ ENTRY(do_suspend_lowlevel)
> > jmp ret_point
> > .p2align 4,,7
> > ret_point:
> > + /* In case the BIOS corrupted DS, make the kernel c
On Thu, Jun 11, 2015 at 11:07 PM, Ingo Molnar wrote:
>
> * Srinivas Pandruvada wrote:
>
>> Suspend to RAM process is returning to userspsace with DS set to KERNEL_DS
>> after resume, this cause general protection fault. [...]
>
> But s2ram has no influence on 'returning to user-space'. So unless
* Andy Lutomirski wrote:
> > 1)
> >
> > So the first critical question is: if the ACPI/BIOS suspend code corrupts
> > the
> > kernel's DS, how can we get so far as to resume fully, return to
> > user-space,
> > and segfault there so that it can all be reported?
> >
> > So neither the explana
On Thu, Jun 11, 2015 at 11:07 PM, Ingo Molnar wrote:
>
> * Srinivas Pandruvada wrote:
>
>> Suspend to RAM process is returning to userspsace with DS set to KERNEL_DS
>> after resume, this cause general protection fault. [...]
>
> But s2ram has no influence on 'returning to user-space'. So unless
* Srinivas Pandruvada wrote:
> Suspend to RAM process is returning to userspsace with DS set to KERNEL_DS
> after resume, this cause general protection fault. [...]
But s2ram has no influence on 'returning to user-space'. So unless I'm missing
something this changelog makes no sense.
Unfortun
Suspend to RAM process is returning to userspsace with DS set to KERNEL_DS
after resume, this cause general protection fault. This is very difficult
to reproduce, but this does happen on 32 bit systems. This crash is not
reproduced after save/restore DS during calls to _save_processor_state/
__rest
18 matches
Mail list logo
