Re: [PATCH] x86/efi Fix regression in efi_arch_mem_reserve

On Wed, 21 Dec, at 02:11:38PM, Petr Oros wrote: > Booting on EFI with ESRT table has been stop since commit: > 8e80632 efi/esrt: Use efi_mem_reserve() and avoid a kmalloc() > > This is caused by this commit: > 816e761 efi: Allow drivers to reserve boot services forever > > Problem

Re: [PATCH 2/2 v3] sched: use load_avg for selecting idlest group

> stdev +/-9% +/-9% +/-8% +/-9% > > Signed-off-by: Vincent Guittot <vincent.guit...@linaro.org> > --- > kernel/sched/fair.c | 48 ++-- > 1 file changed, 38 insertions(+), 10 deletions(-) Tested-by: Matt Fleming <m...@co

Re: [PATCH 2/2 v3] sched: use load_avg for selecting idlest group

8 0.070 0,063 > stdev +/-9% +/-9% +/-8% +/-9% > > Signed-off-by: Vincent Guittot > --- > kernel/sched/fair.c | 48 ++-- > 1 file changed, 38 insertions(+), 10 deletions(-) Tested-by: Matt Fleming Reviewed-by: Matt Fleming Peter, Ingo, when yo

Re: [PATCH 1/2 v3] sched: fix find_idlest_group for fork

gt; Acked-by: Morten Rasmussen <morten.rasmus...@arm.com> > --- > kernel/sched/fair.c | 6 ++ > 1 file changed, 6 insertions(+) Tested-by: Matt Fleming <m...@codeblueprint.co.uk> Reviewed-by: Matt Fleming <m...@codeblueprint.co.uk>

Re: [PATCH 1/2 v3] sched: fix find_idlest_group for fork

re. > - */ > - if ((avg_idle / 512) < avg_cost) > - return -1; > - > time = local_clock(); > > for_each_cpu_wrap(cpu, sched_domain_span(sd), target, wrap) { > > Signed-off-by: Vincent Guittot > Acked-by: Morten Rasmussen > -

Re: [PATCH 2/2 v2] sched: use load_avg for selecting idlest group

On Mon, 05 Dec, at 01:35:46PM, Matt Fleming wrote: > On Mon, 05 Dec, at 10:27:36AM, Vincent Guittot wrote: > > > > Hi Matt, > > > > Thanks for the results. > > > > During the review, it has been pointed out by Morten that the test condition > > (100

Re: [PATCH 2/2 v2] sched: use load_avg for selecting idlest group

On Mon, 05 Dec, at 01:35:46PM, Matt Fleming wrote: > On Mon, 05 Dec, at 10:27:36AM, Vincent Guittot wrote: > > > > Hi Matt, > > > > Thanks for the results. > > > > During the review, it has been pointed out by Morten that the test condition > > (100

Re: [GIT PULL] efi: Pass secure boot mode to kernel

On Thu, 08 Dec, at 11:45:17AM, David Howells wrote: > Hi Matt, Ard, > > Is it too late to request this for the upcoming merge window? For something as non-trivial as this, yes, it's too late. We generally close the EFI tree window for new features around -rc5 time. > Also, I've made > Lukas's

Re: [GIT PULL] efi: Pass secure boot mode to kernel

On Thu, 08 Dec, at 11:45:17AM, David Howells wrote: > Hi Matt, Ard, > > Is it too late to request this for the upcoming merge window? For something as non-trivial as this, yes, it's too late. We generally close the EFI tree window for new features around -rc5 time. > Also, I've made > Lukas's

Re: [PATCH 0/4] UEFI: EFI_MEMORY_ATTRIBUTES_TABLE support for x86

On Wed, 07 Dec, at 11:01:06AM, Sai Praneeth Prakhya wrote: > > Thanks Matt! > > Would you like to see a new version of these patch series addressing > your comments? Like > 1. Dropping of patch #4 > 2. Adding Reviewed-by tag of Joey (Sorry for that) > 3. This time with correct version number No

Re: [PATCH 0/4] UEFI: EFI_MEMORY_ATTRIBUTES_TABLE support for x86

On Wed, 07 Dec, at 11:01:06AM, Sai Praneeth Prakhya wrote: > > Thanks Matt! > > Would you like to see a new version of these patch series addressing > your comments? Like > 1. Dropping of patch #4 > 2. Adding Reviewed-by tag of Joey (Sorry for that) > 3. This time with correct version number No

Re: Does anything ever enter through startup_64 in head_64.S?

On Wed, 07 Dec, at 03:11:17PM, David Howells wrote: > Hi Matt, > > Does anything ever enter the kernel through startup_64 in head_64.S?[*] Do > all 64-bit mode entries always enter through one of the EFI entry points? Which head_64.S? There are two ;-) Assuming you mean startup_64 in

Re: Does anything ever enter through startup_64 in head_64.S?

On Wed, 07 Dec, at 03:11:17PM, David Howells wrote: > Hi Matt, > > Does anything ever enter the kernel through startup_64 in head_64.S?[*] Do > all 64-bit mode entries always enter through one of the EFI entry points? Which head_64.S? There are two ;-) Assuming you mean startup_64 in

Re: [PATCH 0/4] UEFI: EFI_MEMORY_ATTRIBUTES_TABLE support for x86

On Tue, 06 Dec, at 11:15:59AM, Sai Praneeth Prakhya wrote: > From: Sai Praneeth > > UEFI v2.6 introduces EFI_MEMORY_ATTRIBUTES_TABLE which describes memory > protections that may be applied to EFI Runtime code and data regions by > kernel. This helps kernel to

Re: [PATCH 0/4] UEFI: EFI_MEMORY_ATTRIBUTES_TABLE support for x86

On Tue, 06 Dec, at 11:15:59AM, Sai Praneeth Prakhya wrote: > From: Sai Praneeth > > UEFI v2.6 introduces EFI_MEMORY_ATTRIBUTES_TABLE which describes memory > protections that may be applied to EFI Runtime code and data regions by > kernel. This helps kernel to map efi runtime regions more

Re: [PATCH 4/4] efi: Skip parsing of EFI_PROPERTIES_TABLE if EFI_MEMORY_ATTRIBUTES_TABLE is detected

intel.com> > Cc: Lee, Chun-Yi <j...@suse.com> > Cc: Borislav Petkov <b...@alien8.de> > Cc: Ricardo Neri <ricardo.n...@intel.com> > Cc: Matt Fleming <m...@codeblueprint.co.uk> > Cc: Ard Biesheuvel <ard.biesheu...@linaro.org> > Cc: Ravi Shankar <ravi.

Re: [PATCH 4/4] efi: Skip parsing of EFI_PROPERTIES_TABLE if EFI_MEMORY_ATTRIBUTES_TABLE is detected

no good in > doing that. We can also expect that the same attributes might be reflected in > EFI_MEMORY_ATTRIBUTES_TABLE and hence saving us from parsing > EFI_PROPERTIES_TABLE again. > > Signed-off-by: Sai Praneeth Prakhya > Cc: Lee, Chun-Yi > Cc: Borislav Petkov >

Re: [PATCH 1/4] efi: Make EFI_MEMORY_ATTRIBUTES_TABLE initialization common across all architectures

will be supported by x86 as well. > > Signed-off-by: Sai Praneeth Prakhya <sai.praneeth.prak...@intel.com> > Cc: Lee, Chun-Yi <j...@suse.com> > Cc: Borislav Petkov <b...@alien8.de> > Cc: Ricardo Neri <ricardo.n...@intel.com> > Cc: Matt Fleming <m...@co

Re: [PATCH 1/4] efi: Make EFI_MEMORY_ATTRIBUTES_TABLE initialization common across all architectures

> Signed-off-by: Sai Praneeth Prakhya > Cc: Lee, Chun-Yi > Cc: Borislav Petkov > Cc: Ricardo Neri > Cc: Matt Fleming > Cc: Ard Biesheuvel > Cc: Ravi Shankar > Cc: Fenghua Yu > --- > drivers/firmware/efi/arm-init.c | 1 - > drivers/firmware/efi/efi.c

Re: [PATCH 0/4] UEFI: EFI_MEMORY_ATTRIBUTES_TABLE support for x86

On Tue, 06 Dec, at 11:15:59AM, Sai Praneeth Prakhya wrote: > From: Sai Praneeth > > UEFI v2.6 introduces EFI_MEMORY_ATTRIBUTES_TABLE which describes memory > protections that may be applied to EFI Runtime code and data regions by > kernel. This helps kernel to

Re: [PATCH 0/4] UEFI: EFI_MEMORY_ATTRIBUTES_TABLE support for x86

On Tue, 06 Dec, at 11:15:59AM, Sai Praneeth Prakhya wrote: > From: Sai Praneeth > > UEFI v2.6 introduces EFI_MEMORY_ATTRIBUTES_TABLE which describes memory > protections that may be applied to EFI Runtime code and data regions by > kernel. This helps kernel to map efi runtime regions more

Re: [RFC PATCH v3 10/20] Add support to access boot related data in the clear

On Wed, 09 Nov, at 06:36:31PM, Tom Lendacky wrote: > Boot data (such as EFI related data) is not encrypted when the system is > booted and needs to be accessed unencrypted. Add support to apply the > proper attributes to the EFI page tables and to the early_memremap and > memremap APIs to

Re: [RFC PATCH v3 10/20] Add support to access boot related data in the clear

On Wed, 09 Nov, at 06:36:31PM, Tom Lendacky wrote: > Boot data (such as EFI related data) is not encrypted when the system is > booted and needs to be accessed unencrypted. Add support to apply the > proper attributes to the EFI page tables and to the early_memremap and > memremap APIs to

Re: [PATCH 2/2 v2] sched: use load_avg for selecting idlest group

On Mon, 05 Dec, at 10:27:36AM, Vincent Guittot wrote: > > Hi Matt, > > Thanks for the results. > > During the review, it has been pointed out by Morten that the test condition > (100*this_avg_load < imbalance_scale*min_avg_load) makes more sense than > (100*min_avg_load >

Re: [PATCH 2/2 v2] sched: use load_avg for selecting idlest group

On Mon, 05 Dec, at 10:27:36AM, Vincent Guittot wrote: > > Hi Matt, > > Thanks for the results. > > During the review, it has been pointed out by Morten that the test condition > (100*this_avg_load < imbalance_scale*min_avg_load) makes more sense than > (100*min_avg_load >

Re: [tip:efi/core] efi/libstub: Make efi_random_alloc() allocate below 4 GB on 32-bit

On Sun, 04 Dec, at 02:31:23PM, Ard Biesheuvel wrote: > On 4 December 2016 at 14:17, Matt Fleming <m...@codeblueprint.co.uk> wrote: > > > > Ard, was this picked up for the correct tip branch? If it fixes a > > build failure it should have gone into tip/efi/urge

Re: [tip:efi/core] efi/libstub: Make efi_random_alloc() allocate below 4 GB on 32-bit

On Sun, 04 Dec, at 02:31:23PM, Ard Biesheuvel wrote: > On 4 December 2016 at 14:17, Matt Fleming wrote: > > > > Ard, was this picked up for the correct tip branch? If it fixes a > > build failure it should have gone into tip/efi/urgent, right? > > The failure was in -n

Re: [tip:efi/core] efi/libstub: Make efi_random_alloc() allocate below 4 GB on 32-bit

t usable address of the current region. > > Reported-by: Arnd Bergmann <a...@arndb.de> > Signed-off-by: Ard Biesheuvel <ard.biesheu...@linaro.org> > Cc: Linus Torvalds <torva...@linux-foundation.org> > Cc: Matt Fleming <m...@codeblueprint.co.uk>

Re: [tip:efi/core] efi/libstub: Make efi_random_alloc() allocate below 4 GB on 32-bit

takes the desired size and alignment of the allocation into > account. > > To clarify the code in this regard, rename start/end to 'first_slot' and > 'last_slot', respectively, and introduce 'region_end' to describe the > last usable address of the current region. > > Rep

Re: [PATCH 1/2 v2] sched: fix find_idlest_group for fork

On Fri, 25 Nov, at 04:34:32PM, Vincent Guittot wrote: > During fork, the utilization of a task is init once the rq has been > selected because the current utilization level of the rq is used to set > the utilization of the fork task. As the task's utilization is still > null at this step of the

Re: [PATCH 1/2 v2] sched: fix find_idlest_group for fork

On Fri, 25 Nov, at 04:34:32PM, Vincent Guittot wrote: > During fork, the utilization of a task is init once the rq has been > selected because the current utilization level of the rq is used to set > the utilization of the fork task. As the task's utilization is still > null at this step of the

Re: [PATCH 2/2 v2] sched: use load_avg for selecting idlest group

On Fri, 02 Dec, at 07:31:04PM, Brendan Gregg wrote: > > For background, is this from the "A decade of wasted cores" paper's > patches? No, this patch fixes an issue I originally reported here, https://lkml.kernel.org/r/20160923115808.2330-1-m...@codeblueprint.co.uk Essentially, if you have

Re: [PATCH 2/2 v2] sched: use load_avg for selecting idlest group

On Fri, 02 Dec, at 07:31:04PM, Brendan Gregg wrote: > > For background, is this from the "A decade of wasted cores" paper's > patches? No, this patch fixes an issue I originally reported here, https://lkml.kernel.org/r/20160923115808.2330-1-m...@codeblueprint.co.uk Essentially, if you have

Re: [PATCH 2/2 v2] sched: use load_avg for selecting idlest group

On Fri, 02 Dec, at 04:20:54PM, Vincent Guittot wrote: > > Matt, > > Have you been able to get some results for the patchset ? Sorry, I messed up the test config and the tests never ran :( I've redone everything and fast-tracked the results on the SUSE grid now. Should have results by morning.

Re: [PATCH 2/2 v2] sched: use load_avg for selecting idlest group

On Fri, 02 Dec, at 04:20:54PM, Vincent Guittot wrote: > > Matt, > > Have you been able to get some results for the patchset ? Sorry, I messed up the test config and the tests never ran :( I've redone everything and fast-tracked the results on the SUSE grid now. Should have results by morning.

Re: [PATCH 1/2 v2] sched: fix find_idlest_group for fork

On Tue, 29 Nov, at 12:42:43PM, Peter Zijlstra wrote: > > IIRC, and my pounding head really doesn't remember much, the comment > reads like we need the large fudge factor because hackbench. That is, > hackbench would like this test to go away, but others benchmarks will > tank. > > Now, if only I

Re: [PATCH 1/2 v2] sched: fix find_idlest_group for fork

On Tue, 29 Nov, at 12:42:43PM, Peter Zijlstra wrote: > > IIRC, and my pounding head really doesn't remember much, the comment > reads like we need the large fudge factor because hackbench. That is, > hackbench would like this test to go away, but others benchmarks will > tank. > > Now, if only I

Re: [PATCH 0/2 v2] sched: improve spread of tasks during fork

atch that fixes the regression raised by > Matt Fleming [1]. > > [1] https://lkml.org/lkml/2016/10/18/206 > > Vincent Guittot (2): > sched: fix find_idlest_group for fork > sched: use load_avg for selecting idlest group > > kernel/sched/fair.c | 54 > ++

Re: [PATCH 0/2 v2] sched: improve spread of tasks during fork

atch that fixes the regression raised by > Matt Fleming [1]. > > [1] https://lkml.org/lkml/2016/10/18/206 > > Vincent Guittot (2): > sched: fix find_idlest_group for fork > sched: use load_avg for selecting idlest group > > kernel/sched/fair.c | 54 > ++

Re: [PATCH 1/2 v2] sched: fix find_idlest_group for fork

On Fri, 25 Nov, at 04:34:32PM, Vincent Guittot wrote: > > diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c > index aa47589..820a787 100644 > --- a/kernel/sched/fair.c > +++ b/kernel/sched/fair.c > @@ -5463,13 +5463,19 @@ find_idlest_group(struct sched_domain *sd, struct > task_struct *p, >

Re: [PATCH 1/2 v2] sched: fix find_idlest_group for fork

On Fri, 25 Nov, at 04:34:32PM, Vincent Guittot wrote: > > diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c > index aa47589..820a787 100644 > --- a/kernel/sched/fair.c > +++ b/kernel/sched/fair.c > @@ -5463,13 +5463,19 @@ find_idlest_group(struct sched_domain *sd, struct > task_struct *p, >

Re: [PATCH 5/9] efi/arm*: libstub: Invoke EFI_RNG_PROTOCOL to seed the UEFI RNG table

.org> > AuthorDate: Thu Oct 20 12:21:26 2016 +0100 > Commit: Matt Fleming <m...@codeblueprint.co.uk> > CommitDate: Sat Nov 12 21:14:41 2016 + > > efi/arm*: libstub: Invoke EFI_RNG_PROTOCOL to seed the UEFI RNG table > > Invoke th

Re: [PATCH 5/9] efi/arm*: libstub: Invoke EFI_RNG_PROTOCOL to seed the UEFI RNG table

t 20 12:21:26 2016 +0100 > Commit: Matt Fleming > CommitDate: Sat Nov 12 21:14:41 2016 + > > efi/arm*: libstub: Invoke EFI_RNG_PROTOCOL to seed the UEFI RNG table > > Invoke the EFI_RNG_PROTOCOL protocol in the context of the stub and > install

Re: [PATCH 5/9] efi/arm*: libstub: Invoke EFI_RNG_PROTOCOL to seed the UEFI RNG table

On Sun, 13 Nov, at 09:59:32AM, Ingo Molnar wrote: > > * Ingo Molnar wrote: > > > I'll apply the patches from email and add your SOB. > > Note that the attached config produces this build error: > > drivers/firmware/efi/apple-properties.c:149:9: error: implicit declaration of

Re: [PATCH 5/9] efi/arm*: libstub: Invoke EFI_RNG_PROTOCOL to seed the UEFI RNG table

On Sun, 13 Nov, at 09:59:32AM, Ingo Molnar wrote: > > * Ingo Molnar wrote: > > > I'll apply the patches from email and add your SOB. > > Note that the attached config produces this build error: > > drivers/firmware/efi/apple-properties.c:149:9: error: implicit declaration of > function

Re: [PATCH 5/9] efi/arm*: libstub: Invoke EFI_RNG_PROTOCOL to seed the UEFI RNG table

On Sun, 13 Nov, at 08:19:39AM, Ingo Molnar wrote: > > * Matt Fleming <m...@codeblueprint.co.uk> wrote: > > > From: Ard Biesheuvel <ard.biesheu...@linaro.org> > > > > Invoke the EFI_RNG_PROTOCOL protocol in the context of the stub and > > install

Re: [PATCH 5/9] efi/arm*: libstub: Invoke EFI_RNG_PROTOCOL to seed the UEFI RNG table

On Sun, 13 Nov, at 08:19:39AM, Ingo Molnar wrote: > > * Matt Fleming wrote: > > > From: Ard Biesheuvel > > > > Invoke the EFI_RNG_PROTOCOL protocol in the context of the stub and > > install the Linux-specific RNG seed UEFI config table. This will be

[tip:efi/urgent] x86/efi: Prevent mixed mode boot corruption with CONFIG_VMAP_STACK=y

Commit-ID: f6697df36bdf0bf7fce984605c2918d4a7b4269f Gitweb: http://git.kernel.org/tip/f6697df36bdf0bf7fce984605c2918d4a7b4269f Author: Matt Fleming <m...@codeblueprint.co.uk> AuthorDate: Sat, 12 Nov 2016 21:04:24 + Committer: Ingo Molnar <mi...@kernel.org> CommitDate:

[tip:efi/urgent] x86/efi: Prevent mixed mode boot corruption with CONFIG_VMAP_STACK=y

Commit-ID: f6697df36bdf0bf7fce984605c2918d4a7b4269f Gitweb: http://git.kernel.org/tip/f6697df36bdf0bf7fce984605c2918d4a7b4269f Author: Matt Fleming AuthorDate: Sat, 12 Nov 2016 21:04:24 + Committer: Ingo Molnar CommitDate: Sun, 13 Nov 2016 08:26:40 +0100 x86/efi: Prevent mixed

[PATCH 1/9] efi/libstub: Fix allocation size calculations

so use EFI_PAGE_SIZE consistently and remove use of EFI_PAGE_SHIFT to calculate page size. Signed-off-by: Roy Franz <roy.fr...@hpe.com> Signed-off-by: Ard Biesheuvel <ard.biesheu...@linaro.org> Cc: Matt Fleming <m...@codeblueprint.co.uk> --- drivers/firmware/efi/libstu

[PATCH 1/9] efi/libstub: Fix allocation size calculations

consistently and remove use of EFI_PAGE_SHIFT to calculate page size. Signed-off-by: Roy Franz Signed-off-by: Ard Biesheuvel Cc: Matt Fleming --- drivers/firmware/efi/libstub/efi-stub-helper.c | 24 ++-- 1 file changed, 14 insertions(+), 10 deletions(-) diff --git a/drivers

[PATCH 6/9] efi: Add device path parser

G_ACPI is needed for acpi_match_device_ids(). It can be removed if an empty inline stub is added for that function. Signed-off-by: Lukas Wunner <lu...@wunner.de> Cc: Peter Jones <pjo...@redhat.com> Cc: Ard Biesheuvel <ard.biesheu...@linaro.org> Cc: Andreas Noever <andreas.noe...@gma

[PATCH 5/9] efi/arm*: libstub: Invoke EFI_RNG_PROTOCOL to seed the UEFI RNG table

From: Ard Biesheuvel <ard.biesheu...@linaro.org> Invoke the EFI_RNG_PROTOCOL protocol in the context of the stub and install the Linux-specific RNG seed UEFI config table. This will be picked up by the EFI routines in the core kernel to seed the kernel entropy pool. Cc: Matt Flem

[PATCH 2/9] MAINTAINERS: Add ARM and arm64 EFI specific files to EFI subsystem

om> Acked-by: Russell King <rmk+ker...@armlinux.org.uk> Cc: Matt Fleming <m...@codeblueprint.co.uk> Signed-off-by: Ard Biesheuvel <ard.biesheu...@linaro.org> --- MAINTAINERS | 6 -- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/MAINTAINERS b/MAINTAINERS in

[PATCH 4/9] efi/libstub: Add random.c to ARM build

helper routines in its decompressor) Cc: Matt Fleming <m...@codeblueprint.co.uk> Reviewed-by: Kees Cook <keesc...@chromium.org> Signed-off-by: Ard Biesheuvel <ard.biesheu...@linaro.org> --- drivers/firmware/efi/libstub/Makefile | 4 ++-- drivers/firmware/efi/libst

[PATCH 9/9] thunderbolt: Use Device ROM retrieved from EFI

; [MacBookPro11,3] Acked-by: Andreas Noever <andreas.noe...@gmail.com> Cc: Pedro Vilaça <rever...@put.as> Cc: Peter Jones <pjo...@redhat.com> Cc: Ard Biesheuvel <ard.biesheu...@linaro.org> Signed-off-by: Matt Fleming <m...@codeblueprint.co.uk> --- drivers/thunderb

[PATCH 6/9] efi: Add device path parser

for acpi_match_device_ids(). It can be removed if an empty inline stub is added for that function. Signed-off-by: Lukas Wunner Cc: Peter Jones Cc: Ard Biesheuvel Cc: Andreas Noever Signed-off-by: Matt Fleming --- drivers/firmware/efi/Kconfig | 5 + drivers/firmware/efi/Makefile

[PATCH 5/9] efi/arm*: libstub: Invoke EFI_RNG_PROTOCOL to seed the UEFI RNG table

From: Ard Biesheuvel Invoke the EFI_RNG_PROTOCOL protocol in the context of the stub and install the Linux-specific RNG seed UEFI config table. This will be picked up by the EFI routines in the core kernel to seed the kernel entropy pool. Cc: Matt Fleming Reviewed-by: Kees Cook Signed-off

[PATCH 2/9] MAINTAINERS: Add ARM and arm64 EFI specific files to EFI subsystem

From: Ard Biesheuvel Since I will be co-maintaining the EFI subsystem, it makes sense to mention the ARM and arm64 EFI bits in the EFI section in MAINTAINERS so that Matt, the list and I get cc'ed on proposed changes. Acked-by: Will Deacon Acked-by: Russell King Cc: Matt Fleming Signed-off

[PATCH 4/9] efi/libstub: Add random.c to ARM build

) Cc: Matt Fleming Reviewed-by: Kees Cook Signed-off-by: Ard Biesheuvel --- drivers/firmware/efi/libstub/Makefile | 4 ++-- drivers/firmware/efi/libstub/efi-stub-helper.c | 9 - drivers/firmware/efi/libstub/efistub.h | 9 + drivers/firmware/efi/libstub/random.c

[PATCH 9/9] thunderbolt: Use Device ROM retrieved from EFI

-off-by: Matt Fleming --- drivers/thunderbolt/Kconfig | 1 + drivers/thunderbolt/eeprom.c | 43 +++ drivers/thunderbolt/switch.c | 2 +- 3 files changed, 45 insertions(+), 1 deletion(-) diff --git a/drivers/thunderbolt/Kconfig b/drivers/thunderbolt

[PATCH 8/9] x86/efi: Retrieve and assign Apple device properties

Ard Biesheuvel <ard.biesheu...@linaro.org> Cc: Andreas Noever <andreas.noe...@gmail.com> Cc: Peter Jones <pjo...@redhat.com> Signed-off-by: Matt Fleming <m...@codeblueprint.co.uk> --- Documentation/kernel-parameters.txt | 5 + arch/x86/boot/compressed/eboot.c

[PATCH 3/9] efi: Add support for seeding the RNG from a UEFI config table

could be generated by the EFI stub or by any other UEFI driver or application (e.g., GRUB), but the random seed table GUID and the associated functionality should be considered an internal kernel interface (unless it is promoted to ABI later on) Cc: Matt Fleming <m...@codeblueprint.co.uk> Reviewed-b

[PATCH 7/9] efi: Allow bitness-agnostic protocol calls

oever <andreas.noe...@gmail.com> Cc: Peter Jones <pjo...@redhat.com> Signed-off-by: Matt Fleming <m...@codeblueprint.co.uk> --- arch/arm/include/asm/efi.h | 3 +++ arch/arm64/include/asm/efi.h | 3 +++ arch/x86/include/asm/efi.h | 16 +++- 3 files changed, 17 inser

[GIT PULL 0/9] EFI changes for v4.10

Folks, please pull the following v4.10 material. There isn't a huge amount of stuff here. The biggest change is the EFI dev path parser code from Lukas to get thunderbolt working on his macbook. [ The thunderbolt patch has been ACK'd by Andreas and given the OK to take it through the EFI tree

[PATCH 8/9] x86/efi: Retrieve and assign Apple device properties

page allocator of course. Tested-by: Lukas Wunner [MacBookPro9,1] Tested-by: Pierre Moreau [MacBookPro11,3] Signed-off-by: Lukas Wunner Cc: grub-de...@gnu.org Cc: Pedro Vilaça Cc: Ard Biesheuvel Cc: Andreas Noever Cc: Peter Jones Signed-off-by: Matt Fleming --- Documentation/kernel-parameters.tx

[PATCH 3/9] efi: Add support for seeding the RNG from a UEFI config table

other UEFI driver or application (e.g., GRUB), but the random seed table GUID and the associated functionality should be considered an internal kernel interface (unless it is promoted to ABI later on) Cc: Matt Fleming Reviewed-by: Kees Cook Signed-off-by: Ard Biesheuvel --- drivers/firmware

[PATCH 7/9] efi: Allow bitness-agnostic protocol calls

efi_table_attr() macro for bitness- agnostic table lookups. Refactor efi_call_early() to make use of the same macro. (The resulting object code remains identical.) Signed-off-by: Lukas Wunner Cc: Ard Biesheuvel Cc: Andreas Noever Cc: Peter Jones Signed-off-by: Matt Fleming --- arch/arm/include/asm/efi.h

[GIT PULL 0/9] EFI changes for v4.10

Folks, please pull the following v4.10 material. There isn't a huge amount of stuff here. The biggest change is the EFI dev path parser code from Lukas to get thunderbolt working on his macbook. [ The thunderbolt patch has been ACK'd by Andreas and given the OK to take it through the EFI tree

[PATCH 1/2] x86/efi: Fix EFI memmap pointer size warning

ed-off-by: Borislav Petkov <b...@suse.de> Cc: Ard Biesheuvel <ard.biesheu...@linaro.org> Signed-off-by: Matt Fleming <m...@codeblueprint.co.uk> --- arch/x86/platform/efi/efi.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/x86/platform/efi/efi.c b/arch/x86/

[PATCH 2/2] x86/efi: Prevent mixed mode boot corruption with CONFIG_VMAP_STACK

ing a page table walk. Suggested-by: Andy Lutomirski <l...@amacapital.net> Cc: Ard Biesheuvel <ard.biesheu...@linaro.org> Cc: Ingo Molnar <mi...@kernel.org> Cc: Thomas Gleixner <t...@linutronix.de> Cc: "H. Peter Anvin" <h...@zytor.com> Signed-off-by: Mat

[GIT PULL 0/2] EFI urgent fixes

with CONFIG_VMAP_STACK (2016-11-12 21:00:18 +) * Fix memory corruption when booting EFI mixed mode due to the recent vmap'd stack changes - Matt Fleming * Build warning fix in the EFI memmap code when CONFIG_X86_PAE

[PATCH 1/2] x86/efi: Fix EFI memmap pointer size warning

Petkov Cc: Ard Biesheuvel Signed-off-by: Matt Fleming --- arch/x86/platform/efi/efi.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/x86/platform/efi/efi.c b/arch/x86/platform/efi/efi.c index bf99aa7005eb..936a488d6cf6 100644 --- a/arch/x86/platform/efi/efi.c +++ b/arch

[PATCH 2/2] x86/efi: Prevent mixed mode boot corruption with CONFIG_VMAP_STACK

ing a page table walk. Suggested-by: Andy Lutomirski Cc: Ard Biesheuvel Cc: Ingo Molnar Cc: Thomas Gleixner Cc: "H. Peter Anvin" Signed-off-by: Matt Fleming --- arch/x86/platform/efi/efi_64.c | 80 ++ 1 file changed, 57 insertions(+), 23 dele

[GIT PULL 0/2] EFI urgent fixes

with CONFIG_VMAP_STACK (2016-11-12 21:00:18 +) * Fix memory corruption when booting EFI mixed mode due to the recent vmap'd stack changes - Matt Fleming * Build warning fix in the EFI memmap code when CONFIG_X86_PAE

Re: [tip:x86/asm] x86/mm/64: Enable vmapped stacks (CONFIG_HAVE_ARCH_VMAP_STACK=y)

k from showing up. I can't find any existing users that place strings on the stack, no. OK, let's try this one. --- >From 3f8a1ec209a458a9e4b82313186fbde86082696b Mon Sep 17 00:00:00 2001 From: Matt Fleming <m...@codeblueprint.co.uk> Date: Thu, 20 Oct 2016 22:17:21 +0100 Subject: [PATCH

Re: [tip:x86/asm] x86/mm/64: Enable vmapped stacks (CONFIG_HAVE_ARCH_VMAP_STACK=y)

k from showing up. I can't find any existing users that place strings on the stack, no. OK, let's try this one. --- >From 3f8a1ec209a458a9e4b82313186fbde86082696b Mon Sep 17 00:00:00 2001 From: Matt Fleming Date: Thu, 20 Oct 2016 22:17:21 +0100 Subject: [PATCH] x86/efi: Prevent

Re: [PATCH] x86/efi: Fix EFI memmap pointer size warning

gt; arithmetic and checking, and returns unsigned long as it is the native > pointer width. > > So let's use an unsigned long too. It should be fine to do so because > the later users cast it to a pointer too. > > Signed-off-by: Borislav Petkov <b...@suse.de> > C

Re: [PATCH] x86/efi: Fix EFI memmap pointer size warning

cking, and returns unsigned long as it is the native > pointer width. > > So let's use an unsigned long too. It should be fine to do so because > the later users cast it to a pointer too. > > Signed-off-by: Borislav Petkov > Cc: Matt Fleming > --- > arch/x86/platf

Re: [PATCH] x86/boot: Remove always empty $(USERINCLUDE)

ALMODE_CFLAGS) -D_SETUP > > +KBUILD_CFLAGS := $(REALMODE_CFLAGS) -D_SETUP > >  KBUILD_AFLAGS := $(KBUILD_CFLAGS) -D__ASSEMBLY__ > >  GCOV_PROFILE := n > >  UBSAN_SANITIZE := n Looks OK to me. Reviewed-by: Matt Fleming <m...@codeblueprint.co.uk>

Re: [PATCH] x86/boot: Remove always empty $(USERINCLUDE)

t; > +KBUILD_CFLAGS := $(REALMODE_CFLAGS) -D_SETUP > >  KBUILD_AFLAGS := $(KBUILD_CFLAGS) -D__ASSEMBLY__ > >  GCOV_PROFILE := n > >  UBSAN_SANITIZE := n Looks OK to me. Reviewed-by: Matt Fleming

Re: 4.9-rc1 boot regression, ambiguous bisect result

On Sun, 30 Oct, at 08:59:58AM, Dan Williams wrote: > On Sun, Oct 30, 2016 at 5:08 AM, Thorsten Leemhuis > wrote: > > JFYI: I added this report to the list of regressions for Linux 4.9. I'll > > watch this thread for further updates on this issue to document progress > >

Re: 4.9-rc1 boot regression, ambiguous bisect result

On Sun, 30 Oct, at 08:59:58AM, Dan Williams wrote: > On Sun, Oct 30, 2016 at 5:08 AM, Thorsten Leemhuis > wrote: > > JFYI: I added this report to the list of regressions for Linux 4.9. I'll > > watch this thread for further updates on this issue to document progress > > in my weekly reports.

Re: [tip:x86/asm] x86/mm/64: Enable vmapped stacks (CONFIG_HAVE_ARCH_VMAP_STACK=y)

; > } Ah, good catch. Something like this? --- >From d2c17f46686076677da3bf04caa2f69d654f8d8a Mon Sep 17 00:00:00 2001 From: Matt Fleming <m...@codeblueprint.co.uk> Date: Thu, 20 Oct 2016 22:17:21 +0100 Subject: [PATCH] x86/efi: Prevent mixed mode boot corruption with CONFIG_VMAP_STACK Booting an EFI mixed mode kernel

Re: [tip:x86/asm] x86/mm/64: Enable vmapped stacks (CONFIG_HAVE_ARCH_VMAP_STACK=y)

; > } Ah, good catch. Something like this? --- >From d2c17f46686076677da3bf04caa2f69d654f8d8a Mon Sep 17 00:00:00 2001 From: Matt Fleming Date: Thu, 20 Oct 2016 22:17:21 +0100 Subject: [PATCH] x86/efi: Prevent mixed mode boot corruption with CONFIG_VMAP_STACK Booting an EFI mixed mode kernel has been crashing sin

Re: 4.9-rc1 boot regression, ambiguous bisect result

On Fri, 21 Oct, at 04:41:29PM, Matt Fleming wrote: > > FYI, I've been able to reproduce some crash when using your EFI memory > map layout under Qemu and forcing the ESRT driver to reserve the space. Nope, that was a bug in my hack. I can't get Qemu to crash while using your memory m

Re: 4.9-rc1 boot regression, ambiguous bisect result

On Fri, 21 Oct, at 04:41:29PM, Matt Fleming wrote: > > FYI, I've been able to reproduce some crash when using your EFI memory > map layout under Qemu and forcing the ESRT driver to reserve the space. Nope, that was a bug in my hack. I can't get Qemu to crash while using your memory m

Re: 4.9-rc1 boot regression, ambiguous bisect result

On Thu, 20 Oct, at 12:37:16PM, Dan Williams wrote: > > I am able to build a kernel and boot the platform with the following > set of reverts: > > Revert "x86/efi: Round EFI memmap reservations to EFI_PAGE_SIZE" > Revert "x86/efi-bgrt: Use efi_mem_reserve() to avoid copying image

Re: 4.9-rc1 boot regression, ambiguous bisect result

On Thu, 20 Oct, at 12:37:16PM, Dan Williams wrote: > > I am able to build a kernel and boot the platform with the following > set of reverts: > > Revert "x86/efi: Round EFI memmap reservations to EFI_PAGE_SIZE" > Revert "x86/efi-bgrt: Use efi_mem_reserve() to avoid copying image

Re: [tip:x86/asm] x86/mm/64: Enable vmapped stacks (CONFIG_HAVE_ARCH_VMAP_STACK=y)

which enables the CONFIG_VMAP_STACK=y > high level Kconfig option. > > There are a couple of interesting bits: This commit broke booting EFI mixed mode kernels. Here's what I've got queued up to fix it. --- >From acf11e55bfcef7a1dca7d1735f4a780e0cdb1c89 Mon Sep 17 00:00:00 2001 From:

Re: [tip:x86/asm] x86/mm/64: Enable vmapped stacks (CONFIG_HAVE_ARCH_VMAP_STACK=y)

ACK=y > high level Kconfig option. > > There are a couple of interesting bits: This commit broke booting EFI mixed mode kernels. Here's what I've got queued up to fix it. --- >From acf11e55bfcef7a1dca7d1735f4a780e0cdb1c89 Mon Sep 17 00:00:00 2001 From: Matt Fleming Date: Thu, 20 Oct 2016 22:17:21

Re: 4.9-rc1 boot regression, ambiguous bisect result

On Wed, 19 Oct, at 09:04:29PM, Dan Williams wrote: > Hi, > > I am currently unable to boot a Yoga 900 with latest mainline, but 4.8 boots. > > The symptom is a reboot before the video console is available. > > I bisected to commit 816e76129ed5 "efi: Allow drivers to reserve boot > services

Re: 4.9-rc1 boot regression, ambiguous bisect result

On Wed, 19 Oct, at 09:04:29PM, Dan Williams wrote: > Hi, > > I am currently unable to boot a Yoga 900 with latest mainline, but 4.8 boots. > > The symptom is a reboot before the video console is available. > > I bisected to commit 816e76129ed5 "efi: Allow drivers to reserve boot > services

Re: [PATCH v2] x86/platform/UV: Fix support for EFI_OLD_MEMMAP after BIOS callback updates

; v2: Invert if-statement and add unlikely() hint. > > Signed-off-by: Alex Thorlton <athorl...@sgi.com> > Cc: Mike Travis <tra...@sgi.com> > Cc: Russ Anderson <r...@sgi.com> > Cc: Dimitri Sivanich <sivan...@sgi.com> > Cc: Thomas Gleixner <t...@linutronix.de&g

Re: [PATCH v2] x86/platform/UV: Fix support for EFI_OLD_MEMMAP after BIOS callback updates

: Invert if-statement and add unlikely() hint. > > Signed-off-by: Alex Thorlton > Cc: Mike Travis > Cc: Russ Anderson > Cc: Dimitri Sivanich > Cc: Thomas Gleixner > Cc: Ingo Molnar > Cc: "H. Peter Anvin" > Cc: Matt Fleming > Cc: Masahiro Yamada > Cc

Re: [REGRESSION] EFI mixed mode patch triggers boot failure

us Torvalds <torva...@linux-foundation.org> > >CC: Theodore Ts'o <ty...@mit.edu> > >Cc: Arnd Bergmann <a...@arndb.de> > >Cc: Greg Kroah-Hartman <gre...@linuxfoundation.org> > >Cc: Scott J Norton <scott.nor...@hpe.com> > >Cc: Douglas Ha

Re: [REGRESSION] EFI mixed mode patch triggers boot failure

IONAL_MEMORY regions into the EFI page tables > >when mixed-mode is not in use at runtime. > > > >Reported-by: Waiman Long > >Cc: Ard Biesheuvel > >Cc: Borislav Petkov > >Cc: Linus Torvalds > >CC: Theodore Ts'o > >Cc: Arnd Bergmann > >Cc

[tip:sched/core] sched/fair: Kill the unused 'sched_shares_window_ns' tunable

Commit-ID: 3c3fcb45d524feb5d14a14f332e3eec7f2aff8f3 Gitweb: http://git.kernel.org/tip/3c3fcb45d524feb5d14a14f332e3eec7f2aff8f3 Author: Matt Fleming <m...@codeblueprint.co.uk> AuthorDate: Wed, 19 Oct 2016 15:10:59 +0100 Committer: Ingo Molnar <mi...@kernel.org> CommitDate:

[tip:sched/core] sched/fair: Kill the unused 'sched_shares_window_ns' tunable

Commit-ID: 3c3fcb45d524feb5d14a14f332e3eec7f2aff8f3 Gitweb: http://git.kernel.org/tip/3c3fcb45d524feb5d14a14f332e3eec7f2aff8f3 Author: Matt Fleming AuthorDate: Wed, 19 Oct 2016 15:10:59 +0100 Committer: Ingo Molnar CommitDate: Thu, 20 Oct 2016 08:44:57 +0200 sched/fair: Kill

[PATCH] sched/fair: Kill the unused sched_shares_window_ns tunable

el.org> Cc: Dietmar Eggemann <dietmar.eggem...@arm.com> Cc: Paul Turner <p...@google.com> Cc: Mike Galbraith <umgwanakikb...@gmail.com> Signed-off-by: Matt Fleming <m...@codeblueprint.co.uk> --- include/linux/sched/sysctl.h | 1 - kernel/sched/fair.c | 7 --- ker

<    1   2   3   4   5   6   7   8   9   10   >