; linux-kernel@vger.kernel.org; Ard
> > Biesheuvel;
> > joeyli; Borislav Petkov
> > Subject: Re: [PATCH] efi/capsule: Make efi_capsule_pending()
> > lockless
> >
> > On Wed, 04 May, at 02:20:42PM, Borislav Petkov wrote:
> > >
> > > Blergh.
> &
; linux-kernel@vger.kernel.org; Ard
> > Biesheuvel;
> > joeyli; Borislav Petkov
> > Subject: Re: [PATCH] efi/capsule: Make efi_capsule_pending()
> > lockless
> >
> > On Wed, 04 May, at 02:20:42PM, Borislav Petkov wrote:
> > >
> > > Blergh.
> &
On Thu, 5 May 2016 15:36:43 +0100
Matt Fleming wrote:
> On Thu, 05 May, at 02:27:16PM, Kweh, Hock Leong wrote:
> >
> > If not mistaken, the EFI firmware will not update a partially uploaded
> > binary due to checksum error.
> > User is required to re-update the efi
On Thu, 5 May 2016 15:36:43 +0100
Matt Fleming wrote:
> On Thu, 05 May, at 02:27:16PM, Kweh, Hock Leong wrote:
> >
> > If not mistaken, the EFI firmware will not update a partially uploaded
> > binary due to checksum error.
> > User is required to re-update the efi capsule again on the next
On Thu, 05 May, at 02:27:16PM, Kweh, Hock Leong wrote:
>
> If not mistaken, the EFI firmware will not update a partially uploaded binary
> due to checksum error.
> User is required to re-update the efi capsule again on the next boot up.
Ah, so the capsule is only processed by the firmware after
On Thu, 05 May, at 02:27:16PM, Kweh, Hock Leong wrote:
>
> If not mistaken, the EFI firmware will not update a partially uploaded binary
> due to checksum error.
> User is required to re-update the efi capsule again on the next boot up.
Ah, so the capsule is only processed by the firmware after
ject: Re: [PATCH] efi/capsule: Make efi_capsule_pending() lockless
>
> On Wed, 04 May, at 02:20:42PM, Borislav Petkov wrote:
> >
> > Blergh.
>
> Wilson, Bryan, what kind of rollback support does the Intel Quark have if its
> firmware update is interrupted?
>
ject: Re: [PATCH] efi/capsule: Make efi_capsule_pending() lockless
>
> On Wed, 04 May, at 02:20:42PM, Borislav Petkov wrote:
> >
> > Blergh.
>
> Wilson, Bryan, what kind of rollback support does the Intel Quark have if its
> firmware update is interrupted?
>
On Wed, 04 May, at 02:20:42PM, Borislav Petkov wrote:
>
> Blergh.
Wilson, Bryan, what kind of rollback support does the Intel Quark have
if its firmware update is interrupted?
The interruption could be for a number of reasons including power
loss, or the example in this case, rebooting due to
On Wed, 04 May, at 02:20:42PM, Borislav Petkov wrote:
>
> Blergh.
Wilson, Bryan, what kind of rollback support does the Intel Quark have
if its firmware update is interrupted?
The interruption could be for a number of reasons including power
loss, or the example in this case, rebooting due to
On Wed, 04 May, at 02:20:42PM, Borislav Petkov wrote:
> On Wed, May 04, 2016 at 12:46:05PM +0100, Matt Fleming wrote:
> > But emergency_restart() is called after bust_spinlocks(0) which can
> > reset oops_in_progress, so can't even use that to solve the panic
> > case.
>
> Blergh.
>
> So I guess
On Wed, 04 May, at 02:20:42PM, Borislav Petkov wrote:
> On Wed, May 04, 2016 at 12:46:05PM +0100, Matt Fleming wrote:
> > But emergency_restart() is called after bust_spinlocks(0) which can
> > reset oops_in_progress, so can't even use that to solve the panic
> > case.
>
> Blergh.
>
> So I guess
On Wed, May 04, 2016 at 12:46:05PM +0100, Matt Fleming wrote:
> But emergency_restart() is called after bust_spinlocks(0) which can
> reset oops_in_progress, so can't even use that to solve the panic
> case.
Blergh.
So I guess you need an explicit call efi_stop_capsules() somewhere in
the reboot
On Wed, May 04, 2016 at 12:46:05PM +0100, Matt Fleming wrote:
> But emergency_restart() is called after bust_spinlocks(0) which can
> reset oops_in_progress, so can't even use that to solve the panic
> case.
Blergh.
So I guess you need an explicit call efi_stop_capsules() somewhere in
the reboot
On Wed, 04 May, at 11:30:31AM, Borislav Petkov wrote:
>
> Hmmm, so panic() does bust_spinlocks() and efi_capsule_pending() could
> look at oops_in_progress which is set by bust_spinlocks() and that would
> probably solve the panic case but maybe the normal reboot case would
> still hang...
But
On Wed, 04 May, at 11:30:31AM, Borislav Petkov wrote:
>
> Hmmm, so panic() does bust_spinlocks() and efi_capsule_pending() could
> look at oops_in_progress which is set by bust_spinlocks() and that would
> probably solve the panic case but maybe the normal reboot case would
> still hang...
But
On Tue, May 03, 2016 at 03:12:01PM +0100, Matt Fleming wrote:
> We can find ourselves in the reboot code even if the admin has not
> executed the reboot command. The trace above shows we entered because
> the kernel panic()'d and it was booted with panic=-1.
I knew you were gonna say something
On Tue, May 03, 2016 at 03:12:01PM +0100, Matt Fleming wrote:
> We can find ourselves in the reboot code even if the admin has not
> executed the reboot command. The trace above shows we entered because
> the kernel panic()'d and it was booted with panic=-1.
I knew you were gonna say something
On Tue, 03 May, at 11:02:29AM, Borislav Petkov wrote:
> On Sat, Apr 30, 2016 at 11:13:27PM +0100, Matt Fleming wrote:
> > Taking a mutex in the reboot path is bogus because we cannot sleep
> > with interrupts disabled, such as when rebooting due to panic(),
> >
> > [ 18.069005] BUG: sleeping
On Tue, 03 May, at 11:02:29AM, Borislav Petkov wrote:
> On Sat, Apr 30, 2016 at 11:13:27PM +0100, Matt Fleming wrote:
> > Taking a mutex in the reboot path is bogus because we cannot sleep
> > with interrupts disabled, such as when rebooting due to panic(),
> >
> > [ 18.069005] BUG: sleeping
On Sat, Apr 30, 2016 at 11:13:27PM +0100, Matt Fleming wrote:
> Taking a mutex in the reboot path is bogus because we cannot sleep
> with interrupts disabled, such as when rebooting due to panic(),
>
> [ 18.069005] BUG: sleeping function called from invalid context at
>
On Sat, Apr 30, 2016 at 11:13:27PM +0100, Matt Fleming wrote:
> Taking a mutex in the reboot path is bogus because we cannot sleep
> with interrupts disabled, such as when rebooting due to panic(),
>
> [ 18.069005] BUG: sleeping function called from invalid context at
>
Taking a mutex in the reboot path is bogus because we cannot sleep
with interrupts disabled, such as when rebooting due to panic(),
[ 18.069005] BUG: sleeping function called from invalid context at
kernel/locking/mutex.c:97
[ 18.071639] in_atomic(): 0, irqs_disabled(): 1, pid: 7, name:
Taking a mutex in the reboot path is bogus because we cannot sleep
with interrupts disabled, such as when rebooting due to panic(),
[ 18.069005] BUG: sleeping function called from invalid context at
kernel/locking/mutex.c:97
[ 18.071639] in_atomic(): 0, irqs_disabled(): 1, pid: 7, name:
24 matches
Mail list logo