[tip:sched/core] sched/loadavg: Use {READ,WRITE}_ONCE() for sample window

Commit-ID: caeb5882979bc6f3c8766fcf59c6269b38f521bc Gitweb: http://git.kernel.org/tip/caeb5882979bc6f3c8766fcf59c6269b38f521bc Author: Matt Fleming AuthorDate: Fri, 17 Feb 2017 12:07:31 + Committer: Ingo Molnar CommitDate: Thu, 16 Mar 2017 09:21:01 +0100 sched/loadavg: Use {READ

[tip:sched/core] sched/loadavg: Avoid loadavg spikes caused by delayed NO_HZ accounting

Commit-ID: 6e5f32f7a43f45ee55c401c0b9585eb01f9629a8 Gitweb: http://git.kernel.org/tip/6e5f32f7a43f45ee55c401c0b9585eb01f9629a8 Author: Matt Fleming <m...@codeblueprint.co.uk> AuthorDate: Fri, 17 Feb 2017 12:07:30 + Committer: Ingo Molnar <mi...@kernel.org> CommitDate:

[tip:sched/core] sched/loadavg: Avoid loadavg spikes caused by delayed NO_HZ accounting

Commit-ID: 6e5f32f7a43f45ee55c401c0b9585eb01f9629a8 Gitweb: http://git.kernel.org/tip/6e5f32f7a43f45ee55c401c0b9585eb01f9629a8 Author: Matt Fleming AuthorDate: Fri, 17 Feb 2017 12:07:30 + Committer: Ingo Molnar CommitDate: Thu, 16 Mar 2017 09:21:00 +0100 sched/loadavg: Avoid

Re: [PATCH] sched/deadline: Add missing update_rq_clock() in dl_task_timer()

se of all the DL double rq locking going on inside of dl_task_offline_migration(). I'd definitely like someone else to verify, but this looks OK to me. Reviewed-by: Matt Fleming <m...@codeblueprint.co.uk>

Re: [PATCH] sched/deadline: Add missing update_rq_clock() in dl_task_timer()

going on inside of dl_task_offline_migration(). I'd definitely like someone else to verify, but this looks OK to me. Reviewed-by: Matt Fleming

Re: [PATCHv3 15/33] x86/efi: handle p4d in EFI pagetables

On Fri, 17 Feb, at 05:13:10PM, Kirill A. Shutemov wrote: > Allocate additional page table level and change efi_sync_low_kernel_mappings() > to make syncing logic work with additional page table level. > > Signed-off-by: Kirill A. Shutemov <kirill.shute...@linux.intel.com> >

Re: [PATCHv3 15/33] x86/efi: handle p4d in EFI pagetables

On Fri, 17 Feb, at 05:13:10PM, Kirill A. Shutemov wrote: > Allocate additional page table level and change efi_sync_low_kernel_mappings() > to make syncing logic work with additional page table level. > > Signed-off-by: Kirill A. Shutemov > Cc: Matt Fleming > --- > arch/x8

Re: [PATCH 0/2] efi: Enhance capsule loader to support signed Quark images

On Tue, 28 Feb, at 01:20:25PM, Jan Kiszka wrote: > > From you POV, does this exclude upstream quirk support for already > shipped devices? It would need to be an extremely small, well-contained change, that had no chance of disrupting other users of the capsule interface and where I had a good

Re: [PATCH 0/2] efi: Enhance capsule loader to support signed Quark images

On Tue, 28 Feb, at 01:20:25PM, Jan Kiszka wrote: > > From you POV, does this exclude upstream quirk support for already > shipped devices? It would need to be an extremely small, well-contained change, that had no chance of disrupting other users of the capsule interface and where I had a good

Re: [PATCH 0/2] efi: Enhance capsule loader to support signed Quark images

On Fri, 17 Feb, at 10:24:41AM, Jan Kiszka wrote: > > I just can re-express my frustration that this essential step hasn't > been started years ago by whoever designed the extension. Then I bet > there would have been constructive feedback on the interface BEFORE its > ugliness spread to broader

Re: [PATCH 0/2] efi: Enhance capsule loader to support signed Quark images

On Fri, 17 Feb, at 10:24:41AM, Jan Kiszka wrote: > > I just can re-express my frustration that this essential step hasn't > been started years ago by whoever designed the extension. Then I bet > there would have been constructive feedback on the interface BEFORE its > ugliness spread to broader

Re: [PATCH v2 2/2] efi: efi_mem_reserve(): don't reserve through memblock after mm_init()

16918c54e01802af4e891 Mon Sep 17 00:00:00 2001 From: Matt Fleming <m...@codeblueprint.co.uk> Date: Mon, 27 Feb 2017 21:14:29 + Subject: [PATCH] mm/memblock: Warn if used after slab is up and prevent memory corruption Historically there have been many memory corruption bugs caused by using

Re: [PATCH v2 2/2] efi: efi_mem_reserve(): don't reserve through memblock after mm_init()

16918c54e01802af4e891 Mon Sep 17 00:00:00 2001 From: Matt Fleming Date: Mon, 27 Feb 2017 21:14:29 + Subject: [PATCH] mm/memblock: Warn if used after slab is up and prevent memory corruption Historically there have been many memory corruption bugs caused by using the memblock API after its int

Re: sched_setaffinity causing "rq->clock_update_flags < RQCF_ACT_SKIP" warning.

On Fri, 24 Feb, at 05:19:03PM, Dave Jones wrote: > Looks like fallout from cb42c9a3e23448c3f9a25417fae6309b1a92 > > WARNING: CPU: 1 PID: 561 at kernel/sched/sched.h:812 > set_next_entity+0x11d/0x350 > rq->clock_update_flags < RQCF_ACT_SKIP > CPU: 1 PID: 561 Comm: trinity-c36 Not tainted

Re: sched_setaffinity causing "rq->clock_update_flags < RQCF_ACT_SKIP" warning.

On Fri, 24 Feb, at 05:19:03PM, Dave Jones wrote: > Looks like fallout from cb42c9a3e23448c3f9a25417fae6309b1a92 > > WARNING: CPU: 1 PID: 561 at kernel/sched/sched.h:812 > set_next_entity+0x11d/0x350 > rq->clock_update_flags < RQCF_ACT_SKIP > CPU: 1 PID: 561 Comm: trinity-c36 Not tainted

Re: [RFC PATCH v4 13/28] efi: Update efi_mem_type() to return defined EFI mem types

On Thu, 23 Feb, at 11:27:55AM, Tom Lendacky wrote: > > I can do that, I'll change the return type to an int. For the > !efi_enabled I can return -ENOTSUPP and for when an entry isn't > found I can return -EINVAL. Sound good? Sounds good to me!

Re: [RFC PATCH v4 13/28] efi: Update efi_mem_type() to return defined EFI mem types

On Thu, 23 Feb, at 11:27:55AM, Tom Lendacky wrote: > > I can do that, I'll change the return type to an int. For the > !efi_enabled I can return -ENOTSUPP and for when an entry isn't > found I can return -EINVAL. Sound good? Sounds good to me!

Re: [GIT PULL] scheduler changes for v4.11

On Wed, 22 Feb, at 12:41:01PM, Linus Torvalds wrote: > Hmm. The scheduler changes seem to show problems with suspend/resume. > > I now get his when suspending: > > ... > Disabling non-boot CPUs ... > Cannot set affinity for irq 285 > smpboot: CPU 1 is now offline > [ cut

Re: [GIT PULL] scheduler changes for v4.11

On Wed, 22 Feb, at 12:41:01PM, Linus Torvalds wrote: > Hmm. The scheduler changes seem to show problems with suspend/resume. > > I now get his when suspending: > > ... > Disabling non-boot CPUs ... > Cannot set affinity for irq 285 > smpboot: CPU 1 is now offline > [ cut

Re: [PATCH] sched/fair: Update rq clock before changing a task's CPU affinity

ng rq clock after holding rq->lock/pi_lock > just as what other dequeue + put_prev + enqueue + set_curr story does. > > Cc: Peter Zijlstra <pet...@infradead.org> > Cc: Thomas Gleixner <t...@linutronix.de> > Cc: Ingo Molnar <mi...@kernel.org> > Cc: Matt Flem

Re: [PATCH] sched/fair: Update rq clock before changing a task's CPU affinity

q->lock/pi_lock > just as what other dequeue + put_prev + enqueue + set_curr story does. > > Cc: Peter Zijlstra > Cc: Thomas Gleixner > Cc: Ingo Molnar > Cc: Matt Fleming > Signed-off-by: Wanpeng Li > --- > kernel/sched/core.c | 1 + > 1 file changed, 1 insertion(+) This looks correct. Thanks for doing it. Reviewed-by: Matt Fleming

Re: [RFC PATCH v4 13/28] efi: Update efi_mem_type() to return defined EFI mem types

On Thu, 16 Feb, at 09:44:57AM, Tom Lendacky wrote: > Update the efi_mem_type() to return EFI_RESERVED_TYPE instead of a > hardcoded 0. > > Signed-off-by: Tom Lendacky > --- > arch/x86/platform/efi/efi.c |4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > >

Re: [RFC PATCH v4 13/28] efi: Update efi_mem_type() to return defined EFI mem types

On Thu, 16 Feb, at 09:44:57AM, Tom Lendacky wrote: > Update the efi_mem_type() to return EFI_RESERVED_TYPE instead of a > hardcoded 0. > > Signed-off-by: Tom Lendacky > --- > arch/x86/platform/efi/efi.c |4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git

[PATCH v2 1/2] sched/loadavg: Avoid loadavg spikes caused by delayed NO_HZ accounting

gwanakikb...@gmail.com> Cc: Morten Rasmussen <morten.rasmus...@arm.com> Cc: Vincent Guittot <vincent.guit...@linaro.org> Cc: Frederic Weisbecker <fweis...@gmail.com> Cc: <sta...@vger.kernel.org> # v3.5+ Signed-off-by: Matt Fleming <m...@codeblueprint.co.uk> --- kernel/sched

[PATCH v2 1/2] sched/loadavg: Avoid loadavg spikes caused by delayed NO_HZ accounting

uittot Cc: Frederic Weisbecker Cc: # v3.5+ Signed-off-by: Matt Fleming --- kernel/sched/loadavg.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) Changes in v2: - Folded in Peter's suggestion for how to fix this. - Tried to clairfy the changelog based on feedback from Peter and

[PATCH v2 2/2] sched/loadavg: Use {READ,WRITE}_ONCE() for sample window

<umgwanakikb...@gmail.com> Cc: Morten Rasmussen <morten.rasmus...@arm.com> Cc: Vincent Guittot <vincent.guit...@linaro.org> Signed-off-by: Matt Fleming <m...@codeblueprint.co.uk> --- kernel/sched/loadavg.c | 18 +++--- 1 file changed, 11 insertions(+), 7 del

[PATCH v2 0/2] sched/loadavg: Fix loadavg spikes and sprinkle {READ,WRITE}_ONCE()

2924.3038-1-m...@codeblueprint.co.uk Matt Fleming (2): sched/loadavg: Avoid loadavg spikes caused by delayed NO_HZ accounting sched/loadavg: Use {READ,WRITE}_ONCE() for sample window kernel/sched/loadavg.c | 20 1 file changed, 12 insertions(+), 8 deletions(-) -- 2.10.0

[PATCH v2 2/2] sched/loadavg: Use {READ,WRITE}_ONCE() for sample window

-by: Matt Fleming --- kernel/sched/loadavg.c | 18 +++--- 1 file changed, 11 insertions(+), 7 deletions(-) diff --git a/kernel/sched/loadavg.c b/kernel/sched/loadavg.c index ec91fcc09bfe..3f96a7d014ce 100644 --- a/kernel/sched/loadavg.c +++ b/kernel/sched/loadavg.c @@ -168,7 +168,7

[PATCH v2 0/2] sched/loadavg: Fix loadavg spikes and sprinkle {READ,WRITE}_ONCE()

2924.3038-1-m...@codeblueprint.co.uk Matt Fleming (2): sched/loadavg: Avoid loadavg spikes caused by delayed NO_HZ accounting sched/loadavg: Use {READ,WRITE}_ONCE() for sample window kernel/sched/loadavg.c | 20 1 file changed, 12 insertions(+), 8 deletions(-) -- 2.10.0

Re: [PATCH] sched/loadavg: Avoid loadavg spikes caused by delayed NO_HZ accounting

On Wed, 15 Feb, at 04:12:11PM, Frederic Weisbecker wrote: > On Wed, Feb 08, 2017 at 01:29:24PM +0000, Matt Fleming wrote: > > The calculation for the next sample window when exiting NOH_HZ idle > > does not handle the fact that we may not have reached the next sample

Re: [PATCH] sched/loadavg: Avoid loadavg spikes caused by delayed NO_HZ accounting

On Wed, 15 Feb, at 04:12:11PM, Frederic Weisbecker wrote: > On Wed, Feb 08, 2017 at 01:29:24PM +0000, Matt Fleming wrote: > > The calculation for the next sample window when exiting NOH_HZ idle > > does not handle the fact that we may not have reached the next sample

[PATCH] sched/loadavg: Avoid loadavg spikes caused by delayed NO_HZ accounting

("sched/nohz: Rewrite and fix load-avg computation -- again") Cc: Peter Zijlstra <pet...@infradead.org> Cc: Mike Galbraith <umgwanakikb...@gmail.com> Cc: Morten Rasmussen <morten.rasmus...@arm.com> Cc: Vincent Guittot <vincent.guit...@linaro.org> Cc: <sta...@vger.

[PATCH] sched/loadavg: Avoid loadavg spikes caused by delayed NO_HZ accounting

("sched/nohz: Rewrite and fix load-avg computation -- again") Cc: Peter Zijlstra Cc: Mike Galbraith Cc: Morten Rasmussen Cc: Vincent Guittot Cc: # v3.5+ Signed-off-by: Matt Fleming --- kernel/sched/loadavg.c | 13 ++--- 1 file changed, 10 insertions(+), 3 deletions(-) di

Re: [tip:sched/core] sched/core: Add debugging code to catch missing update_rq_clock() calls

d some of you test this? It seems to cure things in my (very) > limited testing. I haven't tested it but this looks like the correct fix to me. Reviewed-by: Matt Fleming <m...@codeblueprint.co.uk>

Re: [tip:sched/core] sched/core: Add debugging code to catch missing update_rq_clock() calls

is? It seems to cure things in my (very) > limited testing. I haven't tested it but this looks like the correct fix to me. Reviewed-by: Matt Fleming

Re: [PATCH 6/7] efi: Handle secure boot from UEFI-2.6 [ver #7]

On Wed, 01 Feb, at 03:02:14PM, Ard Biesheuvel wrote: > > Let's wait for Matt to comment on the x86 bits before reissuing > anything, but if the subsequent patches still apply cleanly, I don't > think there is a need to resend or re-sign. This all looks fine to me now, thanks for the re-work

Re: [PATCH 6/7] efi: Handle secure boot from UEFI-2.6 [ver #7]

On Wed, 01 Feb, at 03:02:14PM, Ard Biesheuvel wrote: > > Let's wait for Matt to comment on the x86 bits before reissuing > anything, but if the subsequent patches still apply cleanly, I don't > think there is a need to resend or re-sign. This all looks fine to me now, thanks for the re-work

Re: [PATCH 4/7] efi: Get the secure boot status [ver #7]

On Tue, 31 Jan, at 03:13:49PM, David Howells wrote: > diff --git a/arch/x86/boot/compressed/eboot.c > b/arch/x86/boot/compressed/eboot.c > index f99978db6b6f..57c2c9c71e53 100644 > --- a/arch/x86/boot/compressed/eboot.c > +++ b/arch/x86/boot/compressed/eboot.c > @@ -988,6 +988,12 @@ struct

Re: [PATCH 4/7] efi: Get the secure boot status [ver #7]

On Tue, 31 Jan, at 03:13:49PM, David Howells wrote: > diff --git a/arch/x86/boot/compressed/eboot.c > b/arch/x86/boot/compressed/eboot.c > index f99978db6b6f..57c2c9c71e53 100644 > --- a/arch/x86/boot/compressed/eboot.c > +++ b/arch/x86/boot/compressed/eboot.c > @@ -988,6 +988,12 @@ struct

Re: What should the default lockdown mode be if the bootloader sentinel triggers sanitization?

On Mon, 30 Jan, at 02:01:32PM, David Howells wrote: > Matt Fleming <m...@codeblueprint.co.uk> wrote: > > > > Matt argues, however, that boot_params->secure_boot should be propagated > > > from > > > the bootloader and if the bootloader wants to set it,

Re: What should the default lockdown mode be if the bootloader sentinel triggers sanitization?

On Mon, 30 Jan, at 02:01:32PM, David Howells wrote: > Matt Fleming wrote: > > > > Matt argues, however, that boot_params->secure_boot should be propagated > > > from > > > the bootloader and if the bootloader wants to set it, then we should skip > &

Re: [tip:sched/core] sched/core: Add debugging code to catch missing update_rq_clock() calls

On Tue, 31 Jan, at 08:24:53AM, Michael Ellerman wrote: > > I'm hitting this on multiple powerpc systems: > > [ 38.339126] rq->clock_update_flags < RQCF_ACT_SKIP > [ 38.339134] [ cut here ] > [ 38.339142] WARNING: CPU: 2 PID: 1 at kernel/sched/sched.h:804 >

Re: [tip:sched/core] sched/core: Add debugging code to catch missing update_rq_clock() calls

On Tue, 31 Jan, at 08:24:53AM, Michael Ellerman wrote: > > I'm hitting this on multiple powerpc systems: > > [ 38.339126] rq->clock_update_flags < RQCF_ACT_SKIP > [ 38.339134] [ cut here ] > [ 38.339142] WARNING: CPU: 2 PID: 1 at kernel/sched/sched.h:804 >

Re: What should the default lockdown mode be if the bootloader sentinel triggers sanitization?

On Mon, 30 Jan, at 12:10:29PM, David Howells wrote: > > Matt argues, however, that boot_params->secure_boot should be propagated from > the bootloader and if the bootloader wants to set it, then we should skip the > check in efi_main() and go with the bootloader's opinion. This is something > we

Re: What should the default lockdown mode be if the bootloader sentinel triggers sanitization?

On Mon, 30 Jan, at 12:10:29PM, David Howells wrote: > > Matt argues, however, that boot_params->secure_boot should be propagated from > the bootloader and if the bootloader wants to set it, then we should skip the > check in efi_main() and go with the bootloader's opinion. This is something > we

Re: WARNING: CPU: 1 PID: 15 at kernel/sched/sched.h:804 assert_clock_updated.isra.62.part.63+0x25/0x27

F_ACT_SKIP The following patch queued in tip/sched/core should fix this issue: >8 >From 4d25b35ea3729affd37d69c78191ce6f92766e1a Mon Sep 17 00:00:00 2001 From: Matt Fleming <m...@codeblueprint.co.uk> Date: Wed, 26 Oct 2016 16:15:44 +0100 Subject: [PATCH] sched/fair: Restore pre

Re: WARNING: CPU: 1 PID: 15 at kernel/sched/sched.h:804 assert_clock_updated.isra.62.part.63+0x25/0x27

F_ACT_SKIP The following patch queued in tip/sched/core should fix this issue: >8 >From 4d25b35ea3729affd37d69c78191ce6f92766e1a Mon Sep 17 00:00:00 2001 From: Matt Fleming Date: Wed, 26 Oct 2016 16:15:44 +0100 Subject: [PATCH] sched/fair: Restore previous rq_flags when

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

On Mon, 24 Oct, at 12:54:11PM, Laura Abbott wrote: > > Was out for a few days, reporter says the below patch does not work. > There was some confusion with secure boot so I've asked them to re-test > with efi=old_map and secure boot off. FYI, you may want to ask the reporter to try out Jiri's

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

On Mon, 24 Oct, at 12:54:11PM, Laura Abbott wrote: > > Was out for a few days, reporter says the below patch does not work. > There was some confusion with secure boot so I've asked them to re-test > with efi=old_map and secure boot off. FYI, you may want to ask the reporter to try out Jiri's

[PATCH] x86/efi: Always map first physical page into EFI pagetables

<b...@alien8.de> Cc: Ard Biesheuvel <ard.biesheu...@linaro.org> Fixes: 129766708 ("x86/efi: Only map RAM into EFI page tables if in mixed-mode") Signed-off-by: Matt Fleming <m...@codeblueprint.co.uk> --- arch/x86/platform/efi/efi_64.c | 16 1 file chan

[PATCH] x86/efi: Always map first physical page into EFI pagetables

Jiri Kosina Cc: sta...@kernel.org # v4.8+ Cc: Waiman Long Cc: Borislav Petkov Cc: Laura Abbott Cc: Vojtech Pavlik Cc: Borislav Petkov Cc: Ard Biesheuvel Fixes: 129766708 ("x86/efi: Only map RAM into EFI page tables if in mixed-mode") Signed-off-by: Matt Fleming --- arch/

Re: [PATCH 1/4] efi/x86: make efi_memmap_reserve only insert into boot mem areas

On Fri, 27 Jan, at 05:04:50PM, Ard Biesheuvel wrote: > On 27 January 2017 at 14:48, Matt Fleming <m...@codeblueprint.co.uk> wrote: > > On Fri, 13 Jan, at 05:29:52AM, Dave Young wrote: > >> > >> It sounds reasonable though I'm still not sure about EFI_LO

Re: [PATCH 1/4] efi/x86: make efi_memmap_reserve only insert into boot mem areas

On Fri, 27 Jan, at 05:04:50PM, Ard Biesheuvel wrote: > On 27 January 2017 at 14:48, Matt Fleming wrote: > > On Fri, 13 Jan, at 05:29:52AM, Dave Young wrote: > >> > >> It sounds reasonable though I'm still not sure about EFI_LOADER*. > >> > >>

[GIT PULL] EFI urgent fix

Folks, please pull the below fix from Jiri which fixes a triple fault affecting the Lenovo Yogas since v4.8. The following changes since commit 7a308bb3016f57e5be11a677d15b821536419d36: Linux 4.10-rc5 (2017-01-22 12:54:15 -0800) are available in the git repository at:

[GIT PULL] EFI urgent fix

Folks, please pull the below fix from Jiri which fixes a triple fault affecting the Lenovo Yogas since v4.8. The following changes since commit 7a308bb3016f57e5be11a677d15b821536419d36: Linux 4.10-rc5 (2017-01-22 12:54:15 -0800) are available in the git repository at:

Re: [PATCH v2] x86/efi: always map first physical page into EFI pagetables

On Fri, 27 Jan, at 04:39:59PM, Jiri Kosina wrote: > From: Jiri Kosina > > Commit 129766708 ("x86/efi: Only map RAM into EFI page tables if in > mixed-mode") stopped creating 1:1 mapping for all RAM in case of running > in native 64bit mode. > > It turns out though that there

Re: [PATCH v2] x86/efi: always map first physical page into EFI pagetables

On Fri, 27 Jan, at 04:39:59PM, Jiri Kosina wrote: > From: Jiri Kosina > > Commit 129766708 ("x86/efi: Only map RAM into EFI page tables if in > mixed-mode") stopped creating 1:1 mapping for all RAM in case of running > in native 64bit mode. > > It turns out though that there are 64bit EFI

Re: [PATCH] x86/efi: always map first physical page into EFI pagetables

On Wed, 25 Jan, at 09:31:53PM, Jiri Kosina wrote: > > [ CCing mailinglists that got eaten by my newly configured mail setup, > sorry for that ] > > On Wed, 25 Jan 2017, Jiri Kosina wrote: > > > From: Jiri Kosina > > > > Commit 129766708 ("x86/efi: Only map RAM into EFI

Re: [PATCH] x86/efi: always map first physical page into EFI pagetables

On Wed, 25 Jan, at 09:31:53PM, Jiri Kosina wrote: > > [ CCing mailinglists that got eaten by my newly configured mail setup, > sorry for that ] > > On Wed, 25 Jan 2017, Jiri Kosina wrote: > > > From: Jiri Kosina > > > > Commit 129766708 ("x86/efi: Only map RAM into EFI page tables if in >

Re: [PATCH 1/4] efi/x86: make efi_memmap_reserve only insert into boot mem areas

On Fri, 13 Jan, at 05:29:52AM, Dave Young wrote: > > It sounds reasonable though I'm still not sure about EFI_LOADER*. > > The main purpose of this patch is to address the invalid mem ranges > case. As Ard mentioned I will test with Peter's patch first, if it works > fine I would like to either

Re: [PATCH 1/4] efi/x86: make efi_memmap_reserve only insert into boot mem areas

On Fri, 13 Jan, at 05:29:52AM, Dave Young wrote: > > It sounds reasonable though I'm still not sure about EFI_LOADER*. > > The main purpose of this patch is to address the invalid mem ranges > case. As Ard mentioned I will test with Peter's patch first, if it works > fine I would like to either

Re: [PATCH 5/8] efi: Get the secure boot status [ver #6]

On Mon, 23 Jan, at 10:11:43PM, David Howells wrote: > Matt Fleming <m...@codeblueprint.co.uk> wrote: > > > > (4) extract_kernel() calls sanitize_boot_params() which would otherwise > > > clear > > > the secure-boot flag. > > > > The

Re: [PATCH 5/8] efi: Get the secure boot status [ver #6]

On Mon, 23 Jan, at 10:11:43PM, David Howells wrote: > Matt Fleming wrote: > > > > (4) extract_kernel() calls sanitize_boot_params() which would otherwise > > > clear > > > the secure-boot flag. > > > > The ->sentinel flag should be clear (

Re: [PATCH 5/8] efi: Get the secure boot status [ver #6]

On Mon, 16 Jan, at 03:39:18PM, David Howells wrote: > Matt Fleming <m...@codeblueprint.co.uk> wrote: > > > On Wed, 11 Jan, at 03:27:23PM, David Howells wrote: > > > Matt Fleming <m...@codeblueprint.co.uk> wrote: > > > > > > > >

Re: [PATCH 5/8] efi: Get the secure boot status [ver #6]

On Mon, 16 Jan, at 03:39:18PM, David Howells wrote: > Matt Fleming wrote: > > > On Wed, 11 Jan, at 03:27:23PM, David Howells wrote: > > > Matt Fleming wrote: > > > > > > > > + movb$0, BP_secure_boot(%rsi) > > > > > #ifdef CON

Re: [PATCH 5/8] efi: Get the secure boot status [ver #6]

(Cc'ing Peter A. and Peter J. for boot params discussion) On Wed, 11 Jan, at 03:27:23PM, David Howells wrote: > Matt Fleming <m...@codeblueprint.co.uk> wrote: > > > > + movb$0, BP_secure_boot(%rsi) > > > #ifdef CONFIG_EFI_STUB > > > /* > > >

Re: [PATCH 5/8] efi: Get the secure boot status [ver #6]

(Cc'ing Peter A. and Peter J. for boot params discussion) On Wed, 11 Jan, at 03:27:23PM, David Howells wrote: > Matt Fleming wrote: > > > > + movb$0, BP_secure_boot(%rsi) > > > #ifdef CONFIG_EFI_STUB > > > /* > > >* The entry point for

Re: [PATCH 8/8] efi: Add EFI_SECURE_BOOT bit [ver #6]

On Wed, 11 Jan, at 03:29:24PM, David Howells wrote: > Matt Fleming <m...@codeblueprint.co.uk> wrote: > > > Before we add more efi.flags bits I'd like this series to include the > > patch that makes use of EFI_SECURE_BOOT. Alternatively, you move this > > last patch

Re: [PATCH 8/8] efi: Add EFI_SECURE_BOOT bit [ver #6]

On Wed, 11 Jan, at 03:29:24PM, David Howells wrote: > Matt Fleming wrote: > > > Before we add more efi.flags bits I'd like this series to include the > > patch that makes use of EFI_SECURE_BOOT. Alternatively, you move this > > last patch to a new series. > > Are

[tip:sched/core] sched/core: Add debugging code to catch missing update_rq_clock() calls

Commit-ID: cb42c9a3e23448c3f9a25417fae6309b1a92 Gitweb: http://git.kernel.org/tip/cb42c9a3e23448c3f9a25417fae6309b1a92 Author: Matt Fleming <m...@codeblueprint.co.uk> AuthorDate: Wed, 21 Sep 2016 14:38:13 +0100 Committer: Ingo Molnar <mi...@kernel.org> CommitDate:

[tip:sched/core] sched/core: Add debugging code to catch missing update_rq_clock() calls

Commit-ID: cb42c9a3e23448c3f9a25417fae6309b1a92 Gitweb: http://git.kernel.org/tip/cb42c9a3e23448c3f9a25417fae6309b1a92 Author: Matt Fleming AuthorDate: Wed, 21 Sep 2016 14:38:13 +0100 Committer: Ingo Molnar CommitDate: Sat, 14 Jan 2017 11:29:35 +0100 sched/core: Add debugging

[tip:sched/core] sched/core: Reset RQCF_ACT_SKIP before unpinning rq->lock

Commit-ID: 92509b732baf14c59ca702307270cfaa3a585ae7 Gitweb: http://git.kernel.org/tip/92509b732baf14c59ca702307270cfaa3a585ae7 Author: Matt Fleming <m...@codeblueprint.co.uk> AuthorDate: Wed, 21 Sep 2016 14:38:11 +0100 Committer: Ingo Molnar <mi...@kernel.org> CommitDate:

[tip:sched/core] sched/core: Add wrappers for lockdep_(un)pin_lock()

Commit-ID: d8ac897137a230ec351269f6378017f2decca512 Gitweb: http://git.kernel.org/tip/d8ac897137a230ec351269f6378017f2decca512 Author: Matt Fleming <m...@codeblueprint.co.uk> AuthorDate: Wed, 21 Sep 2016 14:38:10 +0100 Committer: Ingo Molnar <mi...@kernel.org> CommitDate:

[tip:sched/core] sched/core: Add wrappers for lockdep_(un)pin_lock()

Commit-ID: d8ac897137a230ec351269f6378017f2decca512 Gitweb: http://git.kernel.org/tip/d8ac897137a230ec351269f6378017f2decca512 Author: Matt Fleming AuthorDate: Wed, 21 Sep 2016 14:38:10 +0100 Committer: Ingo Molnar CommitDate: Sat, 14 Jan 2017 11:29:30 +0100 sched/core: Add wrappers

[tip:sched/core] sched/core: Reset RQCF_ACT_SKIP before unpinning rq->lock

Commit-ID: 92509b732baf14c59ca702307270cfaa3a585ae7 Gitweb: http://git.kernel.org/tip/92509b732baf14c59ca702307270cfaa3a585ae7 Author: Matt Fleming AuthorDate: Wed, 21 Sep 2016 14:38:11 +0100 Committer: Ingo Molnar CommitDate: Sat, 14 Jan 2017 11:29:31 +0100 sched/core: Reset

[tip:sched/core] sched/fair: Push rq lock pin/unpin into idle_balance()

Commit-ID: 46f69fa33712ad12ccaa723e46ed5929ee93589b Gitweb: http://git.kernel.org/tip/46f69fa33712ad12ccaa723e46ed5929ee93589b Author: Matt Fleming <m...@codeblueprint.co.uk> AuthorDate: Wed, 21 Sep 2016 14:38:12 +0100 Committer: Ingo Molnar <mi...@kernel.org> CommitDate:

[tip:sched/core] sched/fair: Push rq lock pin/unpin into idle_balance()

Commit-ID: 46f69fa33712ad12ccaa723e46ed5929ee93589b Gitweb: http://git.kernel.org/tip/46f69fa33712ad12ccaa723e46ed5929ee93589b Author: Matt Fleming AuthorDate: Wed, 21 Sep 2016 14:38:12 +0100 Committer: Ingo Molnar CommitDate: Sat, 14 Jan 2017 11:29:32 +0100 sched/fair: Push rq lock

Re: [PATCH 0/8] efi: Pass secure boot mode to kernel [ver #6]

On Thu, 08 Dec, at 12:30:08PM, David Howells wrote: > > Here's a set of patches that can determine the secure boot state of the > UEFI BIOS and pass that along to the main kernel image. This involves > generalising ARM's efi_get_secureboot() function and making it mixed-mode > safe. This

Re: [PATCH 0/8] efi: Pass secure boot mode to kernel [ver #6]

On Thu, 08 Dec, at 12:30:08PM, David Howells wrote: > > Here's a set of patches that can determine the secure boot state of the > UEFI BIOS and pass that along to the main kernel image. This involves > generalising ARM's efi_get_secureboot() function and making it mixed-mode > safe. This

Re: [PATCH 8/8] efi: Add EFI_SECURE_BOOT bit [ver #6]

On Thu, 08 Dec, at 12:31:08PM, David Howells wrote: > From: Josh Boyer > > UEFI machines can be booted in Secure Boot mode. Add a EFI_SECURE_BOOT bit > that can be passed to efi_enabled() to find out whether secure boot is > enabled. > > This will be used by the

Re: [PATCH 8/8] efi: Add EFI_SECURE_BOOT bit [ver #6]

On Thu, 08 Dec, at 12:31:08PM, David Howells wrote: > From: Josh Boyer > > UEFI machines can be booted in Secure Boot mode. Add a EFI_SECURE_BOOT bit > that can be passed to efi_enabled() to find out whether secure boot is > enabled. > > This will be used by the SysRq+x handler, registered by

Re: [PATCH 5/8] efi: Get the secure boot status [ver #6]

On Thu, 08 Dec, at 12:30:45PM, David Howells wrote: > Get the firmware's secure-boot status in the kernel boot wrapper and stash > it somewhere that the main kernel image can find. > > The efi_get_secureboot() function is extracted from the arm stub and (a) > generalised so that it can be called

Re: [PATCH 5/8] efi: Get the secure boot status [ver #6]

On Thu, 08 Dec, at 12:30:45PM, David Howells wrote: > Get the firmware's secure-boot status in the kernel boot wrapper and stash > it somewhere that the main kernel image can find. > > The efi_get_secureboot() function is extracted from the arm stub and (a) > generalised so that it can be called

Re: [PATCH v2 2/2] efi: efi_mem_reserve(): don't reserve through memblock after mm_init()

On Tue, 10 Jan, at 08:37:35AM, Dave Young wrote: > > It is true that it depends on acpi init, I was wondering if bgrt parsing can > be moved to early acpi code. But anyway I'm not sure it is doable and > worth. That's a good question. I think I gave up last time I tried to move the BGRT code to

Re: [PATCH v2 2/2] efi: efi_mem_reserve(): don't reserve through memblock after mm_init()

On Tue, 10 Jan, at 08:37:35AM, Dave Young wrote: > > It is true that it depends on acpi init, I was wondering if bgrt parsing can > be moved to early acpi code. But anyway I'm not sure it is doable and > worth. That's a good question. I think I gave up last time I tried to move the BGRT code to

Re: [PATCH v2 2/2] efi: efi_mem_reserve(): don't reserve through memblock after mm_init()

On Mon, 09 Jan, at 01:31:52PM, Mel Gorman wrote: > > Well, you could put in a __init global variable about availability into > mm/memblock.c and then check it in memblock APIs like memblock_reserve() > to BUG_ON? I know BUG_ON is frowned upon but this is not likely to be a > situation that can be

Re: [PATCH v2 2/2] efi: efi_mem_reserve(): don't reserve through memblock after mm_init()

On Mon, 09 Jan, at 01:31:52PM, Mel Gorman wrote: > > Well, you could put in a __init global variable about availability into > mm/memblock.c and then check it in memblock APIs like memblock_reserve() > to BUG_ON? I know BUG_ON is frowned upon but this is not likely to be a > situation that can be

Re: [PATCH v3 2/2] efi: efi_mem_reserve(): don't reserve through memblock after mm_init()

On Sun, 08 Jan, at 01:24:49AM, Nicolai Stange wrote: > > Out of curiosity, I had a deeper look at the BootServices*-md > requirement though: > > > Another problem is that we never check that the reservation is covered > > by a BootServicesData region, which are the only ones that are > >

Re: [PATCH v3 2/2] efi: efi_mem_reserve(): don't reserve through memblock after mm_init()

On Sun, 08 Jan, at 01:24:49AM, Nicolai Stange wrote: > > Out of curiosity, I had a deeper look at the BootServices*-md > requirement though: > > > Another problem is that we never check that the reservation is covered > > by a BootServicesData region, which are the only ones that are > >

Re: [PATCH v3 2/2] efi: efi_mem_reserve(): don't reserve through memblock after mm_init()

On Fri, 06 Jan, at 07:28:40PM, Ard Biesheuvel wrote: > > This is my point exactly. But it appears efi_free_boot_services() > occurs much later than I thought, and so there is a sizabe time window > where SLAB is up but reservations can still be made. But we don't > check whether

Re: [PATCH v3 2/2] efi: efi_mem_reserve(): don't reserve through memblock after mm_init()

On Fri, 06 Jan, at 07:28:40PM, Ard Biesheuvel wrote: > > This is my point exactly. But it appears efi_free_boot_services() > occurs much later than I thought, and so there is a sizabe time window > where SLAB is up but reservations can still be made. But we don't > check whether

Re: [PATCH v2 2/2] efi: efi_mem_reserve(): don't reserve through memblock after mm_init()

On Thu, 05 Jan, at 05:12:42PM, Dave Young wrote: > On 12/22/16 at 11:23am, Nicolai Stange wrote: > > Before invoking the arch specific handler, efi_mem_reserve() reserves > > the given memory region through memblock. > > > > efi_mem_reserve() can get called after mm_init() though -- through > >

Re: [PATCH v2 2/2] efi: efi_mem_reserve(): don't reserve through memblock after mm_init()

On Thu, 05 Jan, at 05:12:42PM, Dave Young wrote: > On 12/22/16 at 11:23am, Nicolai Stange wrote: > > Before invoking the arch specific handler, efi_mem_reserve() reserves > > the given memory region through memblock. > > > > efi_mem_reserve() can get called after mm_init() though -- through > >

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

On Thu, 05 Jan, at 02:41:09PM, David Howells wrote: > Matt Fleming <m...@codeblueprint.co.uk> wrote: > > > > 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 > > clo

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

On Thu, 05 Jan, at 02:41:09PM, David Howells wrote: > Matt Fleming wrote: > > > > 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

[PATCH] rcu: Enable RCU tracepoints by default to aid in debugging

with this patch and saw no detectable change in performance. Cc: Mel Gorman <mgor...@techsingularity.net> Signed-off-by: Matt Fleming <m...@codeblueprint.co.uk> --- lib/Kconfig.debug | 1 + 1 file changed, 1 insertion(+) diff --git a/lib/Kconfig.debug b/lib/Kconfig.debug index a6c8db1d62f6..

[PATCH] rcu: Enable RCU tracepoints by default to aid in debugging

with this patch and saw no detectable change in performance. Cc: Mel Gorman Signed-off-by: Matt Fleming --- lib/Kconfig.debug | 1 + 1 file changed, 1 insertion(+) diff --git a/lib/Kconfig.debug b/lib/Kconfig.debug index a6c8db1d62f6..7fe1ff001792 100644 --- a/lib/Kconfig.debug +++ b/lib/Kconfig.debug

Re: [PATCH v2 1/2] x86/efi: don't allocate memmap through memblock after mm_init()

On Thu, 22 Dec, at 11:23:39AM, Nicolai Stange wrote: > With commit 4bc9f92e64c8 ("x86/efi-bgrt: Use efi_mem_reserve() to avoid > copying image data"), efi_bgrt_init() calls into the memblock allocator > through efi_mem_reserve() => efi_arch_mem_reserve() *after* mm_init() > has been called. > >

Re: [PATCH v2 1/2] x86/efi: don't allocate memmap through memblock after mm_init()

On Thu, 22 Dec, at 11:23:39AM, Nicolai Stange wrote: > With commit 4bc9f92e64c8 ("x86/efi-bgrt: Use efi_mem_reserve() to avoid > copying image data"), efi_bgrt_init() calls into the memblock allocator > through efi_mem_reserve() => efi_arch_mem_reserve() *after* mm_init() > has been called. > >

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

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