[PATCH 2/5] efibc: Fix excessive stack footprint warning

Reported-by: Arnd Bergmann Signed-off-by: Jeremy Compostella Cc: Ard Biesheuvel [ Updated changelog to include gcc error ] Signed-off-by: Matt Fleming --- drivers/firmware/efi/efibc.c | 34 +++--- 1 file changed, 23 insertions(+), 11 deletions(-) diff --git a/drivers

Re: sched: tweak select_idle_sibling to look for idle threads

On Wed, 04 May, at 12:37:01PM, Peter Zijlstra wrote: > > tbench wants select_idle_siblings() to just not exist; it goes happy > when you just return target. I've been playing with this patch a little bit by hitting it with tbench on a Xeon, 12 cores with HT enabled, 2 sockets (48 cpus). I see a

Re: sched: tweak select_idle_sibling to look for idle threads

On Wed, 04 May, at 12:37:01PM, Peter Zijlstra wrote: > > tbench wants select_idle_siblings() to just not exist; it goes happy > when you just return target. I've been playing with this patch a little bit by hitting it with tbench on a Xeon, 12 cores with HT enabled, 2 sockets (48 cpus). I see a

Re: [PATCH] efi/capsule: Make efi_capsule_pending() lockless

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

Re: [PATCH] efi/capsule: Make efi_capsule_pending() lockless

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

[PATCH] x86/sysfb_efi: Fix valid BAR address range check

<t...@linutronix.de> Cc: Ingo Molnar <mi...@kernel.org> Cc: Tomi Valkeinen <tomi.valkei...@ti.com> Cc: <sta...@vger.kernel.org> [ Rewrote changelog. ] Signed-off-by: Matt Fleming <m...@codeblueprint.co.uk> --- arch/x86/kernel/sysfb_efi.c | 14 -- 1 file c

[PATCH] x86/sysfb_efi: Fix valid BAR address range check

buffer address range without testing later BARs. Signed-off-by: Wang YanQing Reviewed-by: Peter Jones Cc: David Herrmann Cc: "H. Peter Anvin" Cc: Thomas Gleixner Cc: Ingo Molnar Cc: Tomi Valkeinen Cc: [ Rewrote changelog. ] Signed-off-by: Matt Fleming --- arch/x86/kernel/sysfb_

[GIT PULL v2] EFI urgent fix

Folks, please pull the following with from Wang which includes a rewritten changelog as compared with the previous pull request. The following changes since commit 04974df8049fc4240d22759a91e035082ccd18b4: Linux 4.6-rc6 (2016-05-01 15:52:31 -0700) are available in the git repository at:

[GIT PULL v2] EFI urgent fix

Folks, please pull the following with from Wang which includes a rewritten changelog as compared with the previous pull request. The following changes since commit 04974df8049fc4240d22759a91e035082ccd18b4: Linux 4.6-rc6 (2016-05-01 15:52:31 -0700) are available in the git repository at:

[tip:sched/core] sched/fair: Update rq clock before updating nohz CPU load

Commit-ID: b52fad2db5d792d89975cebf2fe1646a7af28ed0 Gitweb: http://git.kernel.org/tip/b52fad2db5d792d89975cebf2fe1646a7af28ed0 Author: Matt Fleming <m...@codeblueprint.co.uk> AuthorDate: Tue, 3 May 2016 20:46:54 +0100 Committer: Ingo Molnar <mi...@kernel.org> CommitDate: Thu

[tip:sched/core] sched/fair: Update rq clock before updating nohz CPU load

Commit-ID: b52fad2db5d792d89975cebf2fe1646a7af28ed0 Gitweb: http://git.kernel.org/tip/b52fad2db5d792d89975cebf2fe1646a7af28ed0 Author: Matt Fleming AuthorDate: Tue, 3 May 2016 20:46:54 +0100 Committer: Ingo Molnar CommitDate: Thu, 5 May 2016 09:41:09 +0200 sched/fair: Update rq clock

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? The interruption could be for a number of reasons including power loss, or the example in this case, rebooting due to

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? The interruption could be for a number of reasons including power loss, or the example in this case, rebooting due to

Re: [PATCH] efi/capsule: Make efi_capsule_pending() lockless

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. > &

Re: [PATCH] efi/capsule: Make efi_capsule_pending() lockless

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. > &

Re: [PATCH] efi/capsule: Make efi_capsule_pending() lockless

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

Re: [PATCH] efi/capsule: Make efi_capsule_pending() lockless

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

Re: [Xen-devel] efi_enabled(EFI_PARAVIRT) use

On Tue, 03 May, at 09:45:22AM, Shannon Zhao wrote: > > +static int __init fdt_find_uefi_params(unsigned long node, const char > > *uname, > > + int depth, void *data) > > +{ > > + struct param_info *info = data; > > + int i; > > + > > + for (i = 0; i <

Re: [Xen-devel] efi_enabled(EFI_PARAVIRT) use

On Tue, 03 May, at 09:45:22AM, Shannon Zhao wrote: > > +static int __init fdt_find_uefi_params(unsigned long node, const char > > *uname, > > + int depth, void *data) > > +{ > > + struct param_info *info = data; > > + int i; > > + > > + for (i = 0; i <

[PATCH 1/5] ia64/PCI: Fix incorrect PCI resource end address

n [-Wmaybe-uninitialized] res->end = addr + size; ^ 'addr' is indeed uninitialised and the correct value to use is res->start. Cc: Tony Luck <tony.l...@intel.com> Cc: Fenghua Yu <fenghua...@intel.com> Cc: Bjorn Helgaas <helg...@kernel.org&

[PATCH 3/5] ia64: Reduce stack usage by iterating over nodemask

=] 2048 bytes of the stack are consumed by the node ID array 'nasids[]'. But we don't actually need to put the ID array on the stack and can use nodemask operations. Cc: Tony Luck <tony.l...@intel.com> Cc: Fenghua Yu <fenghua...@intel.com> Cc: Bjorn Helgaas <helg...@kernel.org> S

[PATCH 3/5] ia64: Reduce stack usage by iterating over nodemask

=] 2048 bytes of the stack are consumed by the node ID array 'nasids[]'. But we don't actually need to put the ID array on the stack and can use nodemask operations. Cc: Tony Luck Cc: Fenghua Yu Cc: Bjorn Helgaas Signed-off-by: Matt Fleming --- arch/ia64/sn/kernel/sn2/sn2_smp.c | 35

[PATCH 1/5] ia64/PCI: Fix incorrect PCI resource end address

n [-Wmaybe-uninitialized] res->end = addr + size; ^ 'addr' is indeed uninitialised and the correct value to use is res->start. Cc: Tony Luck Cc: Fenghua Yu Cc: Bjorn Helgaas Signed-off-by: Matt Fleming --- arch/ia64/sn/kernel/io_init.c | 4 ++-- 1 file chang

[PATCH 0/5] ia64: Fix compiler warnings

I routinely build ia64 kernels when merging EFI patches and for a while now I've seen a bunch of warnings from GCC. These patches silence those warnings, with the first patch fixing an actual bug but the rest just making GCC happier. NOTE: None of these patches have been runtime tested. Matt

[PATCH 2/5] ia64/PCI: Remove unused 'addr' and fix build warning

t.c:429:16: warning: unused variable 'addr' [-Wunused-variable] void __iomem *addr; ^ Cc: Tony Luck <tony.l...@intel.com> Cc: Fenghua Yu <fenghua...@intel.com> Cc: Bjorn Helgaas <helg...@kernel.org> Signed-off-by: Matt Fleming <m...@codeblueprint.

[PATCH 5/5] ia64/unaligned: Silence another GCC warning about an uninitialised variable

arch/ia64/kernel/unaligned.c: In function 'ia64_handle_unaligned': arch/ia64/kernel/unaligned.c:1385:16: warning: 'u.l' may be used uninitialized in this function [-Wmaybe-uninitialized] opcode = (u.l >> IA64_OPCODE_SHIFT) & IA64_OPCODE_MASK; ^ Signed-off-by: Ma

[PATCH 4/5] ia64/traps: Silence GCC warning about uninitialised variable

t; Cc: Bjorn Helgaas <helg...@kernel.org> Signed-off-by: Matt Fleming <m...@codeblueprint.co.uk> --- arch/ia64/kernel/traps.c | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/ia64/kernel/traps.c b/arch/ia64/kernel/traps.c index 6f7d4a4dcf24..77edd68c5161 100644 --- a/arch/ia64/k

[PATCH 5/5] ia64/unaligned: Silence another GCC warning about an uninitialised variable

arch/ia64/kernel/unaligned.c: In function 'ia64_handle_unaligned': arch/ia64/kernel/unaligned.c:1385:16: warning: 'u.l' may be used uninitialized in this function [-Wmaybe-uninitialized] opcode = (u.l >> IA64_OPCODE_SHIFT) & IA64_OPCODE_MASK; ^ Signed-off-by: Ma

[PATCH 4/5] ia64/traps: Silence GCC warning about uninitialised variable

arch/ia64/kernel/traps.c: In function 'ia64_fault': arch/ia64/kernel/traps.c:433:17: warning: 'siginfo.si_code' may be used uninitialized in this function [-Wmaybe-uninitialized] struct siginfo siginfo; Cc: Tony Luck Cc: Fenghua Yu Cc: Bjorn Helgaas Signed-off-by: Matt Fleming

[PATCH 0/5] ia64: Fix compiler warnings

I routinely build ia64 kernels when merging EFI patches and for a while now I've seen a bunch of warnings from GCC. These patches silence those warnings, with the first patch fixing an actual bug but the rest just making GCC happier. NOTE: None of these patches have been runtime tested. Matt

[PATCH 2/5] ia64/PCI: Remove unused 'addr' and fix build warning

t.c:429:16: warning: unused variable 'addr' [-Wunused-variable] void __iomem *addr; ^ Cc: Tony Luck Cc: Fenghua Yu Cc: Bjorn Helgaas Signed-off-by: Matt Fleming --- arch/ia64/sn/kernel/io_acpi_init.c | 1 - 1 file changed, 1 deletion(-) diff --git a/arch/ia64/sn/kernel/io_a

Re: [PATCH 2/3] x86/sysfb_efi: Fix valid BAR address range check

On Wed, 04 May, at 12:23:40PM, Ingo Molnar wrote: > > * Matt Fleming <m...@codeblueprint.co.uk> wrote: > > > On Wed, 04 May, at 08:35:24AM, Ingo Molnar wrote: > > > > > > * Matt Fleming <m...@codeblueprint.co.uk> wrote: > > > > > >

Re: [PATCH 2/3] x86/sysfb_efi: Fix valid BAR address range check

On Wed, 04 May, at 12:23:40PM, Ingo Molnar wrote: > > * Matt Fleming wrote: > > > On Wed, 04 May, at 08:35:24AM, Ingo Molnar wrote: > > > > > > * Matt Fleming wrote: > > > > > > > From: Wang YanQing > > > > > > >

Re: [PATCH 2/3] x86/sysfb_efi: Fix valid BAR address range check

On Wed, 04 May, at 08:35:24AM, Ingo Molnar wrote: > > * Matt Fleming <m...@codeblueprint.co.uk> wrote: > > > From: Wang YanQing <udkni...@gmail.com> > > > > We can't just break out when meet start is equal to zero, > > Hm, wot? The existing cod

Re: [PATCH 2/3] x86/sysfb_efi: Fix valid BAR address range check

On Wed, 04 May, at 08:35:24AM, Ingo Molnar wrote: > > * Matt Fleming wrote: > > > From: Wang YanQing > > > > We can't just break out when meet start is equal to zero, > > Hm, wot? The existing code treats address 0x0 as invalid for a PCI BAR range start addr

[tip:efi/urgent] MAINTAINERS: Remove asterisk from EFI directory names

Commit-ID: e8dfe6d8f6762d515fcd4f30577f7bfcf7659887 Gitweb: http://git.kernel.org/tip/e8dfe6d8f6762d515fcd4f30577f7bfcf7659887 Author: Matt Fleming <m...@codeblueprint.co.uk> AuthorDate: Tue, 3 May 2016 20:29:39 +0100 Committer: Ingo Molnar <mi...@kernel.org> CommitDate: Wed

[tip:efi/urgent] MAINTAINERS: Remove asterisk from EFI directory names

Commit-ID: e8dfe6d8f6762d515fcd4f30577f7bfcf7659887 Gitweb: http://git.kernel.org/tip/e8dfe6d8f6762d515fcd4f30577f7bfcf7659887 Author: Matt Fleming AuthorDate: Tue, 3 May 2016 20:29:39 +0100 Committer: Ingo Molnar CommitDate: Wed, 4 May 2016 08:36:44 +0200 MAINTAINERS: Remove asterisk

[PATCH] sched/fair: Update rq clock before updating nohz cpu load

ernel.org> Cc: Mike Galbraith <umgwanakikb...@gmail.com> Cc: Mel Gorman <mgor...@techsingularity.net> Cc: Thomas Gleixner <t...@linutronix.de> Cc: Frederic Weisbecker <fweis...@gmail.com> Cc: Rik van Riel <r...@redhat.com> Signed-off-by: Matt Fleming <m...@code

[PATCH] sched/fair: Update rq clock before updating nohz cpu load

: Thomas Gleixner Cc: Frederic Weisbecker Cc: Rik van Riel Signed-off-by: Matt Fleming --- kernel/sched/fair.c | 1 + 1 file changed, 1 insertion(+) diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c index b8a33abce650..aa9ba82f0d7c 100644 --- a/kernel/sched/fair.c +++ b/kernel/sched/fair.c

[PATCH 2/3] x86/sysfb_efi: Fix valid BAR address range check

x.de> Cc: Ingo Molnar <mi...@kernel.org> Cc: Tomi Valkeinen <tomi.valkei...@ti.com> Cc: <sta...@vger.kernel.org> [ Updated changelog ] Signed-off-by: Matt Fleming <m...@codeblueprint.co.uk> --- arch/x86/kernel/sysfb_efi.c | 14 -- 1 file changed, 12 insertions(+)

[GIT PULL 0/3] EFI urgent fixes

b not work on some the ThinkPad E550 - Wang YanQing * Update the MAINTAINERS entry for EFI by removing the trailing asterisk characters which was intended to denote "all subdirectories" but which breaks get_maintainer.pl - Matt Fleming * Convert ACPI BGRT driver messages from p

[PATCH 2/3] x86/sysfb_efi: Fix valid BAR address range check

t test later BARs. Signed-off-by: Wang YanQing Reviewed-by: Peter Jones Cc: David Herrmann Cc: "H. Peter Anvin" Cc: Thomas Gleixner Cc: Ingo Molnar Cc: Tomi Valkeinen Cc: [ Updated changelog ] Signed-off-by: Matt Fleming --- arch/x86/kernel/sysfb_efi.c | 14 -- 1

[GIT PULL 0/3] EFI urgent fixes

b not work on some the ThinkPad E550 - Wang YanQing * Update the MAINTAINERS entry for EFI by removing the trailing asterisk characters which was intended to denote "all subdirectories" but which breaks get_maintainer.pl - Matt Fleming * Convert ACPI BGRT driver messages from p

[PATCH 3/3] x86/efi-bgrt: Switch all pr_err() to pr_notice() for invalid BGRT

@moshe.nl> Signed-off-by: Matt Fleming <m...@codeblueprint.co.uk> --- arch/x86/platform/efi/efi-bgrt.c | 18 +- 1 file changed, 9 insertions(+), 9 deletions(-) diff --git a/arch/x86/platform/efi/efi-bgrt.c b/arch/x86/platform/efi/efi-bgrt.c index a2433817c987..6a2f5691b1ab

[PATCH 3/3] x86/efi-bgrt: Switch all pr_err() to pr_notice() for invalid BGRT

the 'quiet' kernel parameter is specified. Ironic, considering BGRT is supposed to make boot pretty to begin with. Signed-off-by: Josh Boyer Reviewed-by: Josh Triplett Cc: Môshe van der Sterre Signed-off-by: Matt Fleming --- arch/x86/platform/efi/efi-bgrt.c | 18 +- 1 file

[PATCH 1/3] MAINTAINERS: Remove asterisk from EFI directory names

inaro.org> Cc: Catalin Marinas <catalin.mari...@arm.com> Cc: <sta...@vger.kernel.org> Signed-off-by: Matt Fleming <m...@codeblueprint.co.uk> --- MAINTAINERS | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/MAINTAINERS b/MAINTAINERS index 42e

[PATCH 1/3] MAINTAINERS: Remove asterisk from EFI directory names

Mark reported that having asterisks on the end of directory names confuses get_maintainer.pl when it encounters subdirectories, and that my name does not appear when run on drivers/firmware/efi/libstub. Reported-by: Mark Rutland Cc: Ard Biesheuvel Cc: Catalin Marinas Cc: Signed-off-by: Matt

Re: [PATCH v2] x86/efi-bgrt: Switch all pr_err() to pr_notice() for invalid BGRT

On Tue, 03 May, at 01:47:04PM, Josh Boyer wrote: > The promise of pretty boot splashes from firmware via BGRT was at > best only that; a promise. The kernel diligently checks to make > sure the BGRT data firmware gives it is valid, and dutifully warns > the user when it isn't. However, it does

Re: [PATCH v2] x86/efi-bgrt: Switch all pr_err() to pr_notice() for invalid BGRT

On Tue, 03 May, at 01:47:04PM, Josh Boyer wrote: > The promise of pretty boot splashes from firmware via BGRT was at > best only that; a promise. The kernel diligently checks to make > sure the BGRT data firmware gives it is valid, and dutifully warns > the user when it isn't. However, it does

Re: [PATCH] efivarfs: merge boolean flag arguments

On Thu, 21 Apr, at 03:24:29PM, Julia Lawall wrote: > The parameters atomic and duplicates of efivar_init always have opposite > values. Drop the parameter atomic, replace the uses of !atomic with > duplicates, and update the call sites accordingly. > > The code using duplicates is slightly

Re: [PATCH] efivarfs: merge boolean flag arguments

On Thu, 21 Apr, at 03:24:29PM, Julia Lawall wrote: > The parameters atomic and duplicates of efivar_init always have opposite > values. Drop the parameter atomic, replace the uses of !atomic with > duplicates, and update the call sites accordingly. > > The code using duplicates is slightly

Re: [PATCH v2] x86:sysfb_efi:efifb_set_system: fix miss valid address range in later BARs

gt; > Signed-off-by: Wang YanQing <udkni...@gmail.com> > > This looks correct to me: > > Reviewed-By: Peter Jones <pjo...@redhat.com> > > Cc'ing Matt Fleming, since this should probably go through the EFI tree. Applied, thanks.

Re: [PATCH v2] x86:sysfb_efi:efifb_set_system: fix miss valid address range in later BARs

t; > Signed-off-by: Wang YanQing > > This looks correct to me: > > Reviewed-By: Peter Jones > > Cc'ing Matt Fleming, since this should probably go through the EFI tree. Applied, thanks.

Re: [tip:efi/core] efibc: Add EFI Bootloader Control module

On Mon, 02 May, at 09:56:09AM, Jeremy Compostella wrote: > > Please find the updated patch in attachment. Thanks Jeremy. Applied.

Re: [tip:efi/core] efibc: Add EFI Bootloader Control module

On Mon, 02 May, at 09:56:09AM, Jeremy Compostella wrote: > > Please find the updated patch in attachment. Thanks Jeremy. Applied.

Re: [PATCH] efi/capsule: Make efi_capsule_pending() lockless

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(), > > > > [

Re: [PATCH] efi/capsule: Make efi_capsule_pending() lockless

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(), > > > > [

Re: efi_enabled(EFI_PARAVIRT) use

On Sun, 01 May, at 10:36:51PM, Shannon Zhao wrote: > So is there any other way you suggest? Would this work (compile tested but not runtime tested)? --- diff --git a/drivers/firmware/efi/efi.c b/drivers/firmware/efi/efi.c index 3a69ed5ecfcb..13d8be16447a 100644 --- a/drivers/firmware/efi/efi.c

Re: efi_enabled(EFI_PARAVIRT) use

On Sun, 01 May, at 10:36:51PM, Shannon Zhao wrote: > So is there any other way you suggest? Would this work (compile tested but not runtime tested)? --- diff --git a/drivers/firmware/efi/efi.c b/drivers/firmware/efi/efi.c index 3a69ed5ecfcb..13d8be16447a 100644 --- a/drivers/firmware/efi/efi.c

Re: efi_enabled(EFI_PARAVIRT) use

On Sun, 01 May, at 11:24:18AM, Shannon Zhao wrote: > Because the UEFI params for Dom0 are located under /hypervisor/uefi node > instead of /chosen. So it needs to check whether it's a Dom0 then search > and parse different node with different params arrays. Why can't you search both nodes? Would

Re: efi_enabled(EFI_PARAVIRT) use

On Sun, 01 May, at 11:24:18AM, Shannon Zhao wrote: > Because the UEFI params for Dom0 are located under /hypervisor/uefi node > instead of /chosen. So it needs to check whether it's a Dom0 then search > and parse different node with different params arrays. Why can't you search both nodes? Would

Re: [PATCH] efibc: avoid stack overflow warning

On Sun, 01 May, at 01:25:12AM, Arnd Bergmann wrote: > On Saturday 30 April 2016 23:46:41 Matt Fleming wrote: > > > > > It's not something we'd have to worry about in practice, but it does > > > make my patch incorrect. Should we come up with a different way to &

Re: [tip:efi/core] efibc: Add EFI Bootloader Control module

On Sun, 01 May, at 10:03:55AM, Ard Biesheuvel wrote: > > Apologies for only mentioning this now, but I wonder why we need this > in the kernel in the first place? The UEFI spec defines 'BootNext' as > the way to set the boot entry for the next boot only, and this could > also be set from

Re: [tip:efi/core] efibc: Add EFI Bootloader Control module

On Sun, 01 May, at 10:03:55AM, Ard Biesheuvel wrote: > > Apologies for only mentioning this now, but I wonder why we need this > in the kernel in the first place? The UEFI spec defines 'BootNext' as > the way to set the boot entry for the next boot only, and this could > also be set from

Re: [PATCH] efibc: avoid stack overflow warning

On Sun, 01 May, at 01:25:12AM, Arnd Bergmann wrote: > On Saturday 30 April 2016 23:46:41 Matt Fleming wrote: > > > > > It's not something we'd have to worry about in practice, but it does > > > make my patch incorrect. Should we come up with a different way to &

Re: [PATCH] efibc: avoid stack overflow warning

On Sun, 01 May, at 12:34:29AM, Arnd Bergmann wrote: > > The sys_restart() system call takes a mutex before calling kernel_restart() > or kernel_poweroff(). > > I've had a closer look now and found that there are a few other > callers of kernel_restart, so I guess if you restart using sysctl > at

Re: [PATCH] efibc: avoid stack overflow warning

On Sun, 01 May, at 12:34:29AM, Arnd Bergmann wrote: > > The sys_restart() system call takes a mutex before calling kernel_restart() > or kernel_poweroff(). > > I've had a closer look now and found that there are a few other > callers of kernel_restart, so I guess if you restart using sysctl > at

Re: [PATCH] x86/efi-bgrt: Switch all pr_err() to pr_debug() for invalid BGRT

(Adding Colin and Ricardo) On Wed, 27 Apr, at 01:23:55PM, Josh Boyer wrote: > > How is an end user supposed to see such a message and report it to the > people that can fix it? They can't. So they report it in their > distributions bug tracker and it either gets closed as "yeah, firmware >

Re: [PATCH] x86/efi-bgrt: Switch all pr_err() to pr_debug() for invalid BGRT

(Adding Colin and Ricardo) On Wed, 27 Apr, at 01:23:55PM, Josh Boyer wrote: > > How is an end user supposed to see such a message and report it to the > people that can fix it? They can't. So they report it in their > distributions bug tracker and it either gets closed as "yeah, firmware >

[PATCH] efi/capsule: Make efi_capsule_pending() lockless

nexus-software.ie> Cc: joeyli <j...@suse.com> Signed-off-by: Matt Fleming <m...@codeblueprint.co.uk> --- drivers/firmware/efi/capsule.c | 36 ++-- 1 file changed, 26 insertions(+), 10 deletions(-) diff --git a/drivers/firmware/efi/capsule.c b/drivers/firmw

[PATCH] efi/capsule: Make efi_capsule_pending() lockless

while we're in the middle of efi_capsule_update_locked() (since CPUs won't have been stopped at that point). Cc: Borislav Petkov Cc: Kweh Hock Leong Cc: Ard Biesheuvel Cc: Bryan O'Donoghue Cc: joeyli Signed-off-by: Matt Fleming --- drivers/firmware/efi/capsule.c | 36

Re: [BUG] x86/efi: MMRs no longer properly mapped after switch to isolated page table

On Fri, 29 Apr, at 10:41:19AM, Alex Thorlton wrote: > > You can see here that we've made it past the MMR read in uv_system_init, > but we die inside of our first EFI callback. In this example, it looks > like we're using the kernel page table at the time of the failure, and I > believe that the

Re: [BUG] x86/efi: MMRs no longer properly mapped after switch to isolated page table

On Fri, 29 Apr, at 10:41:19AM, Alex Thorlton wrote: > > You can see here that we've made it past the MMR read in uv_system_init, > but we die inside of our first EFI callback. In this example, it looks > like we're using the kernel page table at the time of the failure, and I > believe that the

Re: [PATCH] arm64: Relocate screen_info.lfb_base on PCI BAR allocation

(Pulling in efifb maintainer, Peter) On Fri, 29 Apr, at 06:31:19PM, Bjorn Helgaas wrote: > > The efifb.c driver doesn't do anything at all with PCI (it includes > linux/pci.h, but probably doesn't need it). That's part of what I'm > suggesting -- if it *did* register as a PCI device driver,

Re: [PATCH] arm64: Relocate screen_info.lfb_base on PCI BAR allocation

(Pulling in efifb maintainer, Peter) On Fri, 29 Apr, at 06:31:19PM, Bjorn Helgaas wrote: > > The efifb.c driver doesn't do anything at all with PCI (it includes > linux/pci.h, but probably doesn't need it). That's part of what I'm > suggesting -- if it *did* register as a PCI device driver,

Re: efi_enabled(EFI_PARAVIRT) use

On Sat, 30 Apr, at 10:14:42PM, Shannon Zhao wrote: > Sure. How should I add this change? Rework this patch or add new one on > top of it? Rework this patch, please. > Yes, in this patch we could set EFI_RUNTIME_SERVICES flag in > fdt_find_hyper_node instead of setting EFI_PARAVIRT flag, and

Re: efi_enabled(EFI_PARAVIRT) use

On Sat, 30 Apr, at 10:14:42PM, Shannon Zhao wrote: > Sure. How should I add this change? Rework this patch or add new one on > top of it? Rework this patch, please. > Yes, in this patch we could set EFI_RUNTIME_SERVICES flag in > fdt_find_hyper_node instead of setting EFI_PARAVIRT flag, and

Re: [PATCH] efibc: avoid stack overflow warning

On Fri, 29 Apr, at 07:48:31PM, Arnd Bergmann wrote: > gcc complains about a newly added file for the EFI Bootloader Control: > > drivers/firmware/efi/efibc.c: In function 'efibc_set_variable': > drivers/firmware/efi/efibc.c:53:1: error: the frame size of 2272 bytes is > larger than 1024 bytes

Re: [PATCH] efibc: avoid stack overflow warning

On Fri, 29 Apr, at 07:48:31PM, Arnd Bergmann wrote: > gcc complains about a newly added file for the EFI Bootloader Control: > > drivers/firmware/efi/efibc.c: In function 'efibc_set_variable': > drivers/firmware/efi/efibc.c:53:1: error: the frame size of 2272 bytes is > larger than 1024 bytes

Re: [tip:efi/core] efibc: Add EFI Bootloader Control module

On Fri, 29 Apr, at 03:53:39PM, Jeremy Compostella wrote: > From ef3a2941769e59b11d1ec36117209dc4c90c7cf9 Mon Sep 17 00:00:00 2001 > From: Jeremy Compostella > Date: Fri, 29 Apr 2016 15:29:59 +0200 > Subject: [PATCH] efibc: fix excessive stack footprint warning > >

Re: [tip:efi/core] efibc: Add EFI Bootloader Control module

On Fri, 29 Apr, at 03:53:39PM, Jeremy Compostella wrote: > From ef3a2941769e59b11d1ec36117209dc4c90c7cf9 Mon Sep 17 00:00:00 2001 > From: Jeremy Compostella > Date: Fri, 29 Apr 2016 15:29:59 +0200 > Subject: [PATCH] efibc: fix excessive stack footprint warning > > Use dynamic memory allocation

Re: [tip:efi/core] efibc: Add EFI Bootloader Control module

On Sat, 30 Apr, at 10:33:32AM, Jeremy Compostella wrote: > Ingo Molnar writes: > > > > Hm, can reboot notifiers do non-atomic allocations? > The reboot notifier chain is a blocking notifier chain. AFAIK, it > allows non-atomic allocation, right ? I would assume so, yes. > >

Re: [tip:efi/core] efibc: Add EFI Bootloader Control module

On Sat, 30 Apr, at 10:33:32AM, Jeremy Compostella wrote: > Ingo Molnar writes: > > > > Hm, can reboot notifiers do non-atomic allocations? > The reboot notifier chain is a blocking notifier chain. AFAIK, it > allows non-atomic allocation, right ? I would assume so, yes. > > Why is efivar_entry

Re: efi_enabled(EFI_PARAVIRT) use

On Fri, 29 Apr, at 11:34:45AM, Stefano Stabellini wrote: > On Fri, 29 Apr 2016, Ingo Molnar wrote: > > Also, it would be nice to have all things EFI in a single tree, the > > conflicts are > > going to be painful! There's very little reason not to carry this kind of > > commit: > > > >

Re: efi_enabled(EFI_PARAVIRT) use

On Fri, 29 Apr, at 11:34:45AM, Stefano Stabellini wrote: > On Fri, 29 Apr 2016, Ingo Molnar wrote: > > Also, it would be nice to have all things EFI in a single tree, the > > conflicts are > > going to be painful! There's very little reason not to carry this kind of > > commit: > > > >

Re: [tip:efi/core] efibc: Add EFI Bootloader Control module

On Fri, 29 Apr, at 01:36:01PM, Jeremy Compostella wrote: > I would go for this last proposal because it fixes the issue, it works > with the potential race condition you mentioned and it is a simple > solution. Yet, it means that if we really run into a race condition, > the LoaderEntryOneShot

Re: [tip:efi/core] efibc: Add EFI Bootloader Control module

On Fri, 29 Apr, at 01:36:01PM, Jeremy Compostella wrote: > I would go for this last proposal because it fixes the issue, it works > with the potential race condition you mentioned and it is a simple > solution. Yet, it means that if we really run into a race condition, > the LoaderEntryOneShot

Re: [tip:efi/core] efibc: Add EFI Bootloader Control module

On Fri, 29 Apr, at 11:53:56AM, Ingo Molnar wrote: > > * tip-bot for Compostella, Jeremy wrote: > > > Commit-ID: 06f7d4a1618dbb086e738c93cd1ef416ab01027d > > Gitweb: > > http://git.kernel.org/tip/06f7d4a1618dbb086e738c93cd1ef416ab01027d > > Author: Compostella, Jeremy

Re: [tip:efi/core] efibc: Add EFI Bootloader Control module

On Fri, 29 Apr, at 11:53:56AM, Ingo Molnar wrote: > > * tip-bot for Compostella, Jeremy wrote: > > > Commit-ID: 06f7d4a1618dbb086e738c93cd1ef416ab01027d > > Gitweb: > > http://git.kernel.org/tip/06f7d4a1618dbb086e738c93cd1ef416ab01027d > > Author: Compostella, Jeremy > > AuthorDate:

Re: efi_enabled(EFI_PARAVIRT) use

On Fri, 29 Apr, at 10:25:02AM, Borislav Petkov wrote: > On Fri, Apr 29, 2016 at 08:39:36AM +0200, Ingo Molnar wrote: > > With considerable pain we just got rid of paravirt_enabled() in the > > x86 tree, and Xen is now reintroducing it in the EFI code. > > I think Matt is working towards removing

Re: efi_enabled(EFI_PARAVIRT) use

On Fri, 29 Apr, at 10:25:02AM, Borislav Petkov wrote: > On Fri, Apr 29, 2016 at 08:39:36AM +0200, Ingo Molnar wrote: > > With considerable pain we just got rid of paravirt_enabled() in the > > x86 tree, and Xen is now reintroducing it in the EFI code. > > I think Matt is working towards removing

Re: linux-next: manual merge of the tip tree with the arm64 tree

On Fri, 29 Apr, at 01:56:45PM, Stephen Rothwell wrote: > Hi all, > > Today's linux-next merge of the tip tree got a conflict in: > > drivers/firmware/efi/arm-init.c > > between commits: > > 500899c2cc3e ("efi: ARM/arm64: ignore DT memory nodes instead of removing > them") > 7464b6e3a5fb

Re: linux-next: manual merge of the tip tree with the arm64 tree

On Fri, 29 Apr, at 01:56:45PM, Stephen Rothwell wrote: > Hi all, > > Today's linux-next merge of the tip tree got a conflict in: > > drivers/firmware/efi/arm-init.c > > between commits: > > 500899c2cc3e ("efi: ARM/arm64: ignore DT memory nodes instead of removing > them") > 7464b6e3a5fb

Re: [BUG] x86/efi: MMRs no longer properly mapped after switch to isolated page table

On Wed, 27 Apr, at 10:41:32AM, Alex Thorlton wrote: > > From what I know, this works because the first PGD entry (the one > containing the identity mappings) of the trampoline_pgd is shared with > the main kernel PGD (init_level4_pgt), so when __map_region maps this > stuff into the

Re: [BUG] x86/efi: MMRs no longer properly mapped after switch to isolated page table

On Wed, 27 Apr, at 10:41:32AM, Alex Thorlton wrote: > > From what I know, this works because the first PGD entry (the one > containing the identity mappings) of the trampoline_pgd is shared with > the main kernel PGD (init_level4_pgt), so when __map_region maps this > stuff into the

Re: [PATCH] efi: Remove unnecessary (and buggy) .memmap initialization from the Xen EFI driver

s an EFI core internal data structure > plus > it's not used in the Xen driver anyway. > > Signed-off-by: Ingo Molnar <mi...@kernel.org> > --- > drivers/xen/efi.c | 1 - > 1 file changed, 1 deletion(-) Yep, looks good. Thanks Ingo! Reviewed-by: Matt Fleming <m...@codeblueprint.co.uk>

Re: [PATCH] efi: Remove unnecessary (and buggy) .memmap initialization from the Xen EFI driver

s an EFI core internal data structure > plus > it's not used in the Xen driver anyway. > > Signed-off-by: Ingo Molnar > --- > drivers/xen/efi.c | 1 - > 1 file changed, 1 deletion(-) Yep, looks good. Thanks Ingo! Reviewed-by: Matt Fleming

[tip:efi/core] efi: Add 'capsule' update support

Commit-ID: f0133f3c5b8bb34ec4dec50c27e7a655aeee8935 Gitweb: http://git.kernel.org/tip/f0133f3c5b8bb34ec4dec50c27e7a655aeee8935 Author: Matt Fleming <m...@codeblueprint.co.uk> AuthorDate: Mon, 25 Apr 2016 21:06:59 +0100 Committer: Ingo Molnar <mi...@kernel.org> CommitDate:

[tip:efi/core] efi: Add 'capsule' update support

Commit-ID: f0133f3c5b8bb34ec4dec50c27e7a655aeee8935 Gitweb: http://git.kernel.org/tip/f0133f3c5b8bb34ec4dec50c27e7a655aeee8935 Author: Matt Fleming AuthorDate: Mon, 25 Apr 2016 21:06:59 +0100 Committer: Ingo Molnar CommitDate: Thu, 28 Apr 2016 11:34:03 +0200 efi: Add 'capsule' update

[tip:efi/core] x86/efi: Force EFI reboot to process pending capsules

Commit-ID: 87615a34d561ef59bd0cffc73256a21220dfdffd Gitweb: http://git.kernel.org/tip/87615a34d561ef59bd0cffc73256a21220dfdffd Author: Matt Fleming <m...@codeblueprint.co.uk> AuthorDate: Mon, 25 Apr 2016 21:07:00 +0100 Committer: Ingo Molnar <mi...@kernel.org> CommitDate:

<    5   6   7   8   9   10   11   12   13   14   >